mysql bug: EXISTS + GROUP BY

Простой запрос в приложении клиента может давать ошибочный результат

mysql> SELECT s2.NAME
,COUNT(DISTINCT s2.CONTENT_ID) as CNT
,MAX(s1.DATE)
FROM s2 INNER JOIN s1 ON (s2.CONTENT_ID=s1.ID)
WHERE EXISTS (SELECT 1 FROM content_group sg
WHERE s1.ID = sg.CONTENT_ID AND sg.GROUP_ID IN (2))
GROUP BY s2.NAME;
Empty set (0.01 sec)

Интересно, что если исключить из запроса или GROUP BY, или EXISTS – результат становится правильным – ожидаемо непустым

«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»

MySQL: использование временных таблиц на диске для таблиц с TEXT/BLOB столбцами

В документации MySQL указаны случаи, когда temporary tables не могут быть перенесены в память (Memory (HEAP) Storage Engine) и MySQL использует для временных таблиц MyISAM, первый из которых:

• Присутствие TEXT или BLOB столбца в таблице

Не совсем понятно, где должен присутствовать LOB столбец- в списке SELECT, условиях WHERE, конструкциях ORDER BY, GROUP BY?

Интересно, в каких случаях MySQL будет создавать для временных данных таблицы на диске, что фиксируется статистикой Created_tmp_disk_tables для запросов к таблицам с TEXT или BLOB столбцами.

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.»