Журнал db2locktimeout не найден после включения DB2_CAPTURE_LOCKTIMEOUT=ON

Question

База по следующей ссылке:

https://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.admin.regvars.doc/doc/r0005657.html

Я включаю DB2_CAPTURE_LOCKTIMEOUT=ON, а затем я проверяю, успешно ли я изменил это или нет db2set -allи я вижу, что он уже включен.

После этого я успешно имитирую время ожидания блокировки по этой ссылке:

https://db2forum.wordpress.com/2011/10/17/new-options-for-analyzing-lock-timeouts-in-db2-9-5/

Я успешно получаю Reason code "68". SQLSTATE=40001,

Тем не менее, я до сих пор не могу получить какие-либо db2locktimeout войти в /home/db2inst1/sqllib/db2dump,

Я только вижу db2diag.log на этом пути, но не db2locktimeout журнал.

Могу ли я узнать, какую ошибку я совершаю?

Answer 1

Как вы цитировали страницу V10.5, я предполагаю, что ваш Db2-сервер по крайней мере в этой версии. Всегда пишите свою Db2-версию и пакет исправлений при обращении за помощью.

Эта устаревшая (но все еще работающая) переменная эффективна только для вновь скомпилированных операторов SQL. Это означает, что если в вашем кэше пакетов уже есть кэшированные операторы SQL (те, которые вы используете для воссоздания кода причины -911 68), то для этих SQL-файлов не появятся файлы, если они включены в -911.

Если ваш сценарий восстановления может работать с базой данных разработки или тестирования, то вы можете либо очистить кэш динамических операторов (не делайте этого в рабочей среде), либо вы можете сбросить экземпляр Db2 (что имеет побочный эффект очистки кэша пакетов).).

Если ваш сценарий воссоздания использует только статический SQL, то либо эти пакеты нужно будет восстановить (не делайте этого в рабочей среде), либо вы можете сбросить экземпляр Db2.

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

Чтобы узнать больше о том, как Db2 компилирует SQL, и как операторы динамического SQL хранятся вместе со своим планом доступа в памяти (так называемый кэш пакета), изучите Центр знаний Db2 или обратитесь к любому справочнику по Db2.