После обновления на 4.1 Alpha 17 не заходит в веб-интерфейс роутера по http://192.168.1.1/

Вообще ничего не загружается, как будто бы там и не поднято ничего. С ошибкой «не загрузки страницы с первого раза» не связано.

Очистка кэша не помогает. Проверено в трех  разных браузерах.

Цитата

Не удаётся получить доступ к сайту

192.168.1.1 не позволяет установить соединение.

ERR_CONNECTION_REFUSED

При этом Интернет работает. Перезагрузка не помогает. По Telnet подключается.

Уж не связано ли это как-то вот с этим изменением:

Цитата

Web (beta): исправлено предупреждение об изменении портов HTTP и HTTPS (сообщил @dimon27254) [NWI-3091]

Вот это не помогло. https://help.keenetic.com/hc/ru/articles/360015786580-Как-вернуть-доступ-к-веб-конфигуратору-

По Telnet обновился до стабильного релиза 4.0.5 на котором сразу всё заработало. Конфигуратор открылся.

Из старого веб-интерфейса попробовал снова обноситься до 4.1 Alpha 17. И произошло всё то же самое. Процесс обновления прошёл до 100%, роутер перезагрузился, но страничка с завершенным процессом обновления так и осталась на экране. Доступ по HTTP пропал.

С помощью версии 4.0.5 вернулся на 4.1 Alpha 16.

Не знаю имеет ли это значение, но в выгруженном после всех этих действий конфиге заголовок выглядит так:

Цитата

! $$$ Model: Keenetic Giga
! $$$ Version: 2.06.1
! $$$ Agent: cli

Тогда как в сохраненном до обновления конфиге было так:

Цитата

! $$$ Model: Keenetic Giga
! $$$ Version: 2.06.1
! $$$ Agent: http/rci

Возможно это говорит только о способе обновления. Но почему тогда при обновлении с 4.0.5 на 4.1a16 эта запись не вернулась обратно в состояние http/rci ведь обновление было из веб-конфигуратора, а конфиг выгружен из 4.1a16?

Изменено 13 ноября, 2023 пользователем keenet07

Всем привет. Данный мануал подойдет для тех, кто хочет раздать интернет с 3g\4g USB модема, на несколько ПК в режиме hilink. У некоторых USB модемов может быть два режима работы — Stick и Hilink. В первом случае модем работает как коммутируемый интерфейс, в котором как и в обычном модеме происходит «дозвон» на определённый номер. В режиме Hilink модем работает как сетевая карта, и имеет встроенный 3g\4g роутер. В идеале вы должны перепрошить ваш модем для работы в режиме Hilink, но мы делать этого не будем! =D

Что мы имеем и что будем делать для создания всей сети:

• Роутер TP-link TL-WR842ND v.1
• USB модем HUAWEI E3372 (E3372h-153)
• ПК =)

Первым делом идем на оф.сайт openwrt и скачиваем прошивку для СВОЕГО роутера. Обратите внимание, нужно знать на каком адаптере построено Ваше устройство. В моем случае я использую TL-WR842ND, он работает на ath79 — соответственно для него tplink_tl-wr842n-v1-squashfs-factory.bin.

Примечание! kernel — это файл с ядром, factory — прошивка для перепрошивки со стока прошивки, sysupgrade — обновление с предыдущей версии на текущую.

TP-Linnk TL-WR842Nd

После успешной перепрошивки роутер будет доступен по адресу 192.168.1.1 (на стоковой прошивке он работает по адресу 192.168.0.1). При первоначальном входе не будет задан пароль пользователя root. Его настроим потом.

Для начала идем Сеть -> Wi-Fi -> Беспроводная сеть radio0 -> Поиск.

Подключаем роутер к любой точке где есть интернет.

Я подключил к своему мобильному телефону раздающему интернет по wi-fi. Сохраняем и применяем настройки подключения.

Далее идем в Система -> Software

Жмем кнопку Update lists… Роутер обновит список приложений в репозитории.

Далее поочередно устанавливаем нужные нам пакеты: kmod-usb-core, kmod-usb-net, chat, ppp, kmod-usb-serial, kmod-usb2, libusb-1.0, usb-modeswitch, kmod-usb-net-rndis, kmod-usb-net-cdc-ether, kmod-usb-uhci, ну и драйвер для usb модема huawei kmod-usb-net-huawei-cdc-ncm, если вы используете другой модем поищите под свой, или попробуйте без драйвера. Если на роутере есть USB3.0 еще понадобится дрйвер и под него kmod-usb3. Пакеты так же можно установить из под консоли используя SSH подключение, чтоб сделать так подключаем к роутеру по SSH и вводим следующие команды:
# opkg update
для обновление списка пакетов в репозитории
# opkg install kmod-usb-core kmod-usb-net kmod-usb-uhci chat ppp kmod-usb-serial kmod-usb2 kmod-usb3 libusb-1.0 usb-modeswitch kmod-usb-net-rndis kmod-usb-net-cdc-ether kmod-usb-net-huawei-cdc-ncm

Чтоб русифицировать интерфейс OpenWRT установите дополнительно пакет luci-i18n-base-ru. Установка через SSH:
# opkg update
# opkg install luci-i18n-base-ru

После того как установили все пакеты, выключаем роутер, подключаем USB модем и включаем. Первый запуск с USB модемом может занять больше времени, дождитесь загрузки! После того как ротуер загрузился идем в Сеть -> Интерфейсы -> Добавить новый интерфейс. Пишем название интерфейса, я назвал USB_WAN, Протокол — DHCP, интерфейс — eth2. Создаем новый интерфейс, и сразу нажимаем на нем кнопку Изменить. Переходим во вкладку Настройки межсетевого экрана, выбираем зону WAN, после чего кнопку Сохранить.

Далее сохраняем и применяем все настройки в меню интерфейсов.

После этого интернет с USB модема должен раздаваться через роутер. Настройка завершена! Остальные настройки (задание пароля на Wi-fi сеть и т.д.), выполняйте под свои нужды =) После отключения роутера от своей сети Wi-Fi клиент-соединение, можно удалить.

Ну и напоследок небольшой тест:

По скриншоту видно, что я использовал сим карту от Теле2, скорость средненькая. Предположу, что качество сигнала было не очень хорошее, либо проблема в USB порте самого роутера, на сколько знаю в нем встроен USB 1.1, пропускная способность которого 15-20 Мб\с..

0

2

[    7.510000] usbcore: registered new interface driver usbfs
[    7.510000] usbcore: registered new interface driver hub
[    7.510000] usbcore: registered new device driver usb
[    7.510000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    7.510000] ehci-platform: EHCI generic platform driver
[    8.020000] phy phy-usbphy.0: remote usb device wakeup disabled
[    8.030000] phy phy-usbphy.0: UTMI 16bit 30MHz
[    8.040000] ehci-platform 101c0000.ehci: EHCI Host Controller
[    8.050000] ehci-platform 101c0000.ehci: new USB bus registered, assigned  number 1
[    8.070000] ehci-platform 101c0000.ehci: irq 26, io mem 0x101c0000
[    8.100000] ehci-platform 101c0000.ehci: USB 2.0 started, EHCI 1.00
[    8.110000] usb usb1: no of_node; not parsing pinctrl DT
[    8.110000] hub 1-0:1.0: no of_node; not parsing pinctrl DT
[    8.110000] hub 1-0:1.0: USB hub found
[    8.120000] hub 1-0:1.0: 1 port detected
[    8.130000] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    8.150000] ohci-platform: OHCI generic platform driver
[    8.160000] ohci-platform 101c1000.ohci: Generic Platform OHCI controller
[    8.170000] ohci-platform 101c1000.ohci: new USB bus registered, assigned  number 2
[    8.190000] ohci-platform 101c1000.ohci: irq 26, io mem 0x101c1000
[    8.260000] usb usb2: no of_node; not parsing pinctrl DT
[    8.260000] hub 2-0:1.0: no of_node; not parsing pinctrl DT
[    8.260000] hub 2-0:1.0: USB hub found
[    8.270000] hub 2-0:1.0: 1 port detected
[    8.450000] usb 1-1: new high-speed USB device number 2 using ehci-platfor
[    8.610000] usb 1-1: no of_node; not parsing pinctrl DT
[    9.140000] init: - preinit -
[   10.130000] rt305x-esw 10110000.esw: link changed 0x00
[   12.510000] rt305x-esw 10110000.esw: link changed 0x08
[   13.990000] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
[   14.050000] procd: - early -
[   14.050000] procd: - watchdog -
[   15.280000] procd: - ubus -
[   16.320000] procd: - init -
[   17.990000] NET: Registered protocol family 10
[   17.990000] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   17.990000] Loading modules backported from Linux version master-2015-03-0-g141f155
[   17.990000] Backport generated by backports.git backports-20150129-0-gdd4a
[   18.560000] ip_tables: (C) 2000-2006 Netfilter Core Team
[   18.600000] nf_conntrack version 0.5.0 (453 buckets, 1812 max)
[   18.650000] usbcore: registered new interface driver usbserial
[   18.660000] usbcore: registered new interface driver usbserial_generic
[   18.670000] usbserial: USB Serial support registered for generic
[   18.720000] xt_time: kernel timezone is -0000


[   19.120000] usbcore: registered new interface driver option
[   19.130000] usbserial: USB Serial support registered for GSM modem (1-port)

хорошо тебе. есть кого ловить. а мне все самому приходится делать.

select count(*) sessions from v$session;
select count(*) processes from v$process;
select count(*) cursors from v$open_cursor;

это посмотреть (у меня уперлось не в курсоры а в сессии)
где-то было написано что эти три параметры взаимосвязаны.
а вот нашел — это статья у Тома Кайта AskTom Processes, sessions and open_cursors

Добавлено через 57 секунд
Hi,

when you got this error always check trace file. In my trace file was this error:

ORA-00020: maximum number of processes (2000) exceeded

So what does mean?

1) This error is related to parameter processes.

SQL> show parameter processes

NAME TYPE VALUE
————————————
processes integer 2000

–> It it max value

current value:

select count(*) from v$process;

COUNT(*)
———-
1122

==> It is ok now. Parameter processes set max value for operating system processes

Parameter Sessions set max. value for session in oracle and should be calculate from parameter processes.

Session=(processes * 1.1 ) +5

In our case (2000 * 1.1) +5 = 2205

SQL> show parameter sessions

NAME TYPE VALUE
———————————— ———– ——————————
sessions integer 2205

–> current number of sessions

select count(*) from v$session;

COUNT(*)
———-
1122

==> we are under limit and this is ok.

Other parameter could be open_cursors. This parameter set max. number of open cursors per one session.

SQL>show parameter cursors

NAME TYPE VALUE
———————————— ———– ——————————
open_cursors integer 500

–> This mean that each session could have 500 open cursor. Together it is 2205 * 500 = 1102500 cursors.

Now we have open

SQL>select count(*) from v$open_cursor;

COUNT(*)
———-
18319

What value set to parameter open_cursors?

We can calculate 18319 / 2205 = 8.3

–> we can set it to 50 which is default value

Перевод статьи «Monitoring Open and Cached Cursors» от Natalka Roshak, декабрь 2005

Предисловие.

Здесь слово «разбор» используется в смысле parse, соответственно «мягкий разбор» и «жёсткий разбор» – «soft parse» и «hard parse».

[В квадратных скобках я ввожу свои поясняющие фразы, перевод фраз или фразы из оригинала]

Чуть ли не каждый администратор БД имел дело с ошибкой ORA-01000, «Maximum open cursors exceeded» [превышено максимальное число открытых курсоров]. В этой статье будут обсуждаться параметры инициализации, которые влияют на открытые курсоры, разница между открытыми и кэшированными курсорами, закрытие курсоров и, собственно, мониторинг открытых и кэшированных курсоров.

Открытые курсоры [Open Cursors]

Открытые курсоры находятся в shared pool [разделяемом пуле], в library cache [библиотечном кэше]. Для того, чтобы какая-нибудь сессия не заполнила библиотечный кэш или не загрузила бы CPU миллионами запросов разбора операторов (parse requests) «под завязку», выставляется параметр OPEN_CURSORS.

Параметр OPEN_CURSORS определяет максимальное количество открытых курсоров на одну сессию в каждый момент времени. Например, если OPEN_CURSORS равен 1000, то в любой сессии в любой момент времени могут быть открытыми одновременно до 1000 курсоров. Если же какая-то сессия уже имеет количество открытых курсоров, равное значению параметра OPEN_CURSORS, то при попытке открыть хотя бы ещё один курсор, она получит ошибку ORA-01000.

Значение параметра OPEN_CURSORS по умолчанию равно 50, однако Oracle рекомендует для большинства приложений выставлять его равным, по меньшей мере, 500. Некоторым приложениям может потребоваться ещё большее значение, например, web-приложениям, которые обслуживают по нескольку сотен пользователей, совместно использующих пул сессий. Том Кайт рекомендует выставлять его равным 1000.

Кэшированные курсоры сессии [Session Cached Cursors]

На курсоры влияют два параметра инициализации: OPEN_CURSORS и SESSION_CACHED_CURSORS, которые часто приводят к путанице.

SESSION_CACHED_CURSORS определяет количество кэшированных закрытых курсоров, которое может быть в одной сессии.

[Отступление. Из документации по Oracle 9i Release 2 SESSION_CACHED_CURSORS lets you specify the number of session cursors to cache. Repeated parse calls of the same SQL statement cause the session cursor for that statement to be moved into the session cursor cache. Subsequent parse calls will find the cursor in the cache and do not need to reopen the cursor. Oracle uses a least recently used algorithm to remove entries in the session cursor cache to make room for new entries when needed.

Думаю, перевод излишен.]

Вы можете выставить значение этого параметра любым, безотносительно к значению OPEN_CURSORS. Этот параметр не приводит к появлению ошибки ORA-01000 и не влияет на количество открываемых сессией курсоров. И наоборот, параметр OPEN_CURSORS не оказывает влияния на количество кэшируемых курсоров. Между этими двумя параметрами связи не существует.

Значение параметра SESSION_CACHED_CURSORS по умолчанию равно 0, и для любой сессии ни один курсор не будет кэширован. (Курсоры, однако, окажутся кэшированными в разделяемом пуле, но сессии придётся их там искать.) Если же параметру SESSION_CACHED_CURSORS присвоено отличное от нуля значение, то по результатам запроса на разбор [parse request] Oracle проверяет наличие в библиотечном кэше более трёх запросов на разбор для того же предложения. При положительном результате проверки Oracle перемещает связанный с этим предложением курсор сессии в кэш курсоров сессии [session cursor cache]. Последующие запросы на разбор для того же предложения в той же сессии заполняются из кэша курсоров сессии – таким образом исключается даже мягкий разбор [soft parse]. (Совсем избежать мягкого разбора технически невозможно – производится «более мягкий» мягкий разбор, то есть более быстрый и требующий меньших затрат CPU)

В кэше курсоров сессии Oracle управляет кэшированными курсорами с использованием LRU-списка. Когда окажется, что количество закрытых кэшированных курсоров равно SESSION_CACHED_CURSORS, Oracle начнёт «удалять закрытые курсоры» из «холодного конца» LRU-списка с целью освободить место для кэширования нового курсора.

Зачем кэшировать курсоры?

Очевидное преимущество от кэширования курсоров сессией состоит в уменьшении количества разборов, что приводит в целом к более быстрым временам выполнения. Это особенно касается таких приложений, как Oracle Forms, в которых переключение от одной формы к другой вызывает закрытие всех открытых для этой формы курсоров сессии. Обратное переключение к предыдущей форме открывает точно такие же курсоры, какие были закрыты. Как видим, кэширование курсоров сессией действительно приводит к снижению количества повторных разборов.

Более того, имеется ещё одно преимущество. Так как в случае кэширования курсоров сессии не нужно искать в библиотечном кэше прежде разобранные SQL-выражения, это приводит к уменьшению защёлок библиотечного кэша и разделяемого пула. Такие защёлки часто становятся точками конкуренции в нагруженных OLTP-системах. Уменьшение количества защёлок сокращает количество ожиданий защёлок, приводящее не столько к выигрышу в скорости, сколько к росту масштабируемости системы.

Мониторинг открытых курсоров

Я уверена [автор статьи – женщина], что много путаницы касательно открытых и кэшированных курсоров возникает из-за самих названий dynamic performance views (V$) [представления динамических характеристик] Oracle, которые используются, в том числе, для отслеживания таких курсоров. Представление V$OPEN_CURSORS показывает кэшированные сессией курсоры, никак не открытые в данный момент времени. Если вас вдруг заинтересует, сколько курсоров ваша сессия открыла в настоящий момент, не используйте для этой цели V$OPEN_CURSORS. Оно показывает курсоры в кэше курсоров сессии для каждой текущей сессии, а не действительно открытые курсоры.

Для отслеживания открытых курсоров запрашивайте представление V$SESSTAT с предикатом name=’opened cursors current’. Оно покажет количество открытых в настоящее время курсоров на сессию:

—общее количество открытых курсоров на сессию

select a.value, s.username, s.sid, s.serial#

from v$sesstat a, v$statname b, v$session s

where a.statistic# = b.statistic#  and s.sid=a.sid

and b.name = 'opened cursors current';

Если вы запустили несколько N-уровневых приложений со множеством web-серверов, вам может оказаться полезнее поиск открытых курсоров по username и mashine:

—общее количество открытых курсоров по username и mashine

select sum(a.value) total_cur, avg(a.value) avg_cur, max(a.value) max_cur, 

s.username, s.machine

from v$sesstat a, v$statname b, v$session s 

where a.statistic# = b.statistic#  and s.sid=a.sid

and b.name = 'opened cursors current' 

group by s.username, s.machine

order by 1 desc;

Настройка OPEN_CURSORS

Наилучший совет по настройке параметра OPEN_CURSORS – это не настраивать его. Выставьте его значение достаточно высоким, чтобы больше не беспокоиться об этом. Если ваши сессии работают очень близко к ограничению, которое вы задали параметром OPEN_CURSORS, то просто увеличьте его. При настройке этого параметра ваша цель состоит в том, чтобы при нормальной работе не возникало ошибки ORA-01000.

Значение параметра OPEN_CURSORS вовсе не означает, что теперь каждая сессия будет держать открытыми равное ему количество курсоров. Курсоры открываются по мере необходимости. В случае, если одно из ваших приложений допускает «утечку курсоров», в конечном итоге ошибка будет возникать при любой величине OPEN_CURSORS, сколь большой бы она не была.

Чтобы понять, подходящее ли значение имеет OPEN_CURSORS, делайте запрос к V$SESSTAT с нахождением максимального значения по «opened cursors current». Если результат окажется близок к величине OPEN_CURSORS, поднимите его значение.

SQL> select max(a.value) as highest_open_cur, p.value as max_open_cur

  2> from v$sesstat a, v$statname b, v$parameter p

  3> where a.statistic# = b.statistic# 

  4> and b.name = 'opened cursors current'

  5> and p.name= 'open_cursors'

  6> group by p.value;

HIGHEST_OPEN_CUR MAX_OPEN_CUR

---------------- ------------

            1953         2500

После повышения значения OPEN_CURSORS, по обращению к V$SESSTAT продолжайте наблюдать, сохранится ли рост количества открытых курсоров для любой из ваших сессий. Если у вас для какой-нибудь сессии какого-нибудь приложения рост количества открытых курсоров продолжается после нескольких увеличений значения OPEN_CURSORS, то, скорее всего, код этого приложения допускает утечку курсоров: ваше приложение открывает курсоры и не закрывает их после работы с ними.

Администратору БД ничего делать не нужно – это разработчики приложения должны просмотреть весь код с целью поиска участков, в которых курсоры остаются открытыми, и закрыть их. Всё, что может сделать администратор БД – это выставить значение параметра OPEN_CURSORS очень большим, а также выставить времена, когда сессии приложения будут закрываться и открываться вновь – в качестве временного решения.

Как не сообщать, если вы закрываете все ваши курсоры

К несчастью разработчиков, статистика сессии «opened cursors current» может включать в себя курсоры, которые приложение уже закрыло. Когда код приложения вызывает закрытие курсора, Oracle, на самом деле, помечает курсор как «closeable» [закрываемый]. В действительности курсор может не быть закрытым до тех пор, пока Oracle-у не потребуется место под новый курсор.

Итак, невозможно проверить, закрывает ли приложение все свои курсоры посредством открытия сессии, запуска теста, а затем проверки, упало ли количество открытых курсоров до единицы. Даже если приложение закрывает все свои курсоры надлежащим образом, статистика по «opened cursors current» может показать, что некоторые из «closeable» курсоров до сих пор открыты.

Единственным путём для разработчиков приложений в нашем случае является одиночный запуск теста в специально выделенной для разработки среде с отслеживанием «opened cursors cumulative» в V$SESSTAT для сессии, в которой был запущен тест. Потом выставить значение параметра OPEN_CURSORS в значение немного выше того пикового для открытых курсоров, которое наблюдалось при работе теста, открыть новую сессию и запустить несколько раз тот же самый тест. Если в вашем приложении имеется утечка курсоров, вы увидите растущее значение OPEN_CURSORS [наверное, имелось ввиду значение «opened cursors current»], и после достаточного числа запусков теста вы получите ошибку ORA-01000. (Не выставляйте параметр OPEN_CURSORS слишком низким, иначе он может быть истрачен на рекурсивные SQL-выражения; если ваш одиночный тест открывает очень мало курсоров, рассмотрите возможность продления его работы [видимо, имелось ввиду увеличение количества его запусков] вместо выставления параметра OPEN_CURSORS необоснованно низким.)

Мониторинг кэша курсоров сессии

V$SESSTAT также предоставляет статистику количества курсоров, которое имеет каждая сессия в своём кэше курсоров.

--кэшированный сессией курсоры, по каждой сессии

select a.value, s.username, s.sid, s.serial#

from v$sesstat a, v$statname b, v$session s

where a.statistic# = b.statistic#  and s.sid=a.sid

and b.name = 'session cursor cache count' ;

Кроме того, вы можете непосредственно видеть, что находится в кэше курсоров сессии запросом к V$OPEN_CURSOR. V$OPEN_CURSOR предоставляет список кэшированных сессией курсоров с SID и первые несколько символов SQL-предложения с SQL_ID, так что вы можете точно сказать, откуда появляются курсоры.

select c.user_name, c.sid, sql.sql_text

from v$open_cursor c, v$sql sql

where c.sql_id=sql.sql_id  -- for 9i and earlier use: c.address=sql.address

and c.sid=&sid;

Настройка SESSION_CACHED_CURSORS

Если в качестве помощи приложению, которое постоянно закрывает и открывает заново курсоры, вы собираетесь использовать параметр SESSION_CACHED_CURSORS, то можете отслеживать его эффективность посредством двух статистических показателей в представлении V$SESSTAT. Статистика «session cursor cache hits» отражает количество раз, которое посланное сессией на разбор предложение было обнаружено в кэше курсоров сессии, что означает отсутствие необходимости нового разбора этого предложения и необходимости его поиска в библиотечном кэше. Можете сравнить эту статистику со статистикой «parse count (total)»; вычесть «session cursor cache hits» из «parse count (total)», чтобы узнать количество действительно произведённых разборов.

SQL> select cach.value cache_hits, prs.value all_parses, 

  2> prs.value-cach.value sess_cur_cache_not_used

  3> from v$sesstat cach, v$sesstat prs, v$statname nm1, v$statname nm2

  4> where cach.statistic# = nm1.statistic#  

  5> and nm1.name = 'session cursor cache hits' 

  6> and prs.statistic#=nm2.statistic#

  7> and nm2.name= 'parse count (total)'

  8> and cach.sid= &sid and prs.sid= cach.sid ;

Enter value for sid: 947

old   8: and cach.sid= &sid and prs.sid= cach.sid

new   8: and cach.sid= 947 and prs.sid= cach.sid

CACHE_HITS ALL_PARSES SESS_CUR_CACHE_NOT_USED

---------- ---------- -----------------------

       106        210                     104

Отслеживайте эти значения, согласовывая их со статистическим показателем «session cursor cache count».

--кэшированные сессией курсоры для выбранного SID, в сравнении с максимальным значением

select a.value curr_cached, p.value max_cached, s.username, s.sid, s.serial#

from v$sesstat a, v$statname b, v$session s, v$parameter2 p

where a.statistic# = b.statistic#  and s.sid=a.sid and a.sid=&sid

and p.name='session_cached_cursors'

and b.name = 'session cursor cache count' ;

Если показатель «session cursor cache count» достиг предела, равного значению параметра SESSION_CACHED_CURSORS, при этом показатель «session cursor cache hits» достаточно низок в сравнении со всеми разборами, и у вас есть подозрение, что приложение повторно отправляет одни и те же запросы на разбор, то увеличение значения параметра SESSION_CACHED_CURSORS может помочь с конкуренцией за защёлки и дать небольшой выигрыш в производительности. Имейте в виду, что если ваше приложение не отправляет одни и те же запросы на разбор повторно, то «session cursor cache hits» будет оставаться низким, «session cursor cache count» может иметь предельное значение, и кэширование сессией курсоров не поможет вообще. Такое возможно, например, в случае, если ваше приложение использует множество недоступных для совместного использования [unsharable] SQL, тогда повышение значения параметра SESSION_CACHED_CURSORS ни к чему не приведёт.

Заключение

Мы осветили разницу между открытыми курсорами и кэшированными сессией курсорами, относящимися к ним параметрами инициализации, как производить их мониторинг и настройку.