«library cache: mutex X», NLS_LENGTH_SEMANTICS и предел количества дочерних курсоров?

Необычная проблема на серверах Oracle у клиентов. Пользовательские сессии – в ожидании library cache: mutex X, веб сервер(Apache) c CMS висит :(

При этом все зависшие сессии дочерних процессов Apache выполняют один и тот же запрос,  sql_id=’fhh6c2w6thz2h’ (сам запрос не имеет значения), и в v$sql_shared_cursor можно увидеть аномально большое количество дочерних курсоров «проблемного» запроса:

SQL> select count(*) as child_cursor_count from v$sql_shared_cursor
     where sql_id = 'fhh6c2w6thz2h';
CHILD_CURSOR_COUNT
32768

32768=2**15

Похоже на жёстко фиксированное в коде Oracle ограничение на количество дочерних курсоров одного SQL, не так ли?

Однако объяснение феномена проще:

ora-904 ora-907 при использовании correlated subquery

При использовании корелированных подзапросов (т.е. подзапросов, результаты которых используются для каждой строки основного запроса – «a correlated subquery is evaluated once for each row») периодически могут встречаются ошибки, неточно объясняющие, что делается неправильно:

ora-904 «%s: invalid identifier»

ora-907 «missing right parenthesis»

Oracle 11g: direct path read при непараллельном сканировании таблиц (TABLE ACCESS FULL)

Наряду с привычным механизмом многоблочного чтения (событие ожидания db file scattered read) при непараллельном сканировании таблиц в Oracle 11g используется direct path read -  793845.1 High ‘direct path read’ waits in 11g:

«В версии 11g измененились  модели выбора (heuristics) между direct path reads и операцией чтения блоков данных через буферный кэш при сканировании таблиц (serial table scans).
В 10g, при сканировании больших таблиц использовался  буферный кэш, что теперь не является единственным возможным вариантом.  В Oracle 11g выбор метода доступа между direct path и обычным чтением через кэш основывается на размере таблицы, db_cache_size, shared_pool_size и других параметрах.
Direct path reads быстрее, чем scattered reads и меньше влияет на другие процессы, т.к. исключается механизм latches.»

Использование DISTINCT vs EXISTS vs GROUP BY в подзапросах

Интересное наблюдение за поведением Oracle CBO на примере трёх идентичных (по результату) запросов:

1
select b.comm from bonus b where b.ename in
(select distinct e.ename from emp e where e.mgr >0);
2

select b.comm from bonus b where exists
(select 1 from emp e where e.ename = b.ename and e.mgr >0);
3

select b.comm from bonus b where b.ename in
(select e.ename from emp e where e.mgr >0 group by e.ename);

Как открыть БД с повреждёнными (недоступными) log-файлами

Практический опыт восстановления базы данных

Oracle версии 9.2.0.6 в режиме NOARCHIVELOG, ~1.5 ТБ, после серьёзного сбоя файловой системы и «ручного» запуска утилиты fsck.ext2 файлы данных оказались в /lost+found поименоваными номерами inod’ов, controlfile отсутствуют (пропали при восстановлении – 3 штуки :), redolog-файлы, как выяснилось, повреждены.