>>-UPDATE QP_SYSTEM USING--------------------------------------->
>--+-DEFAULT------------------------------+--------------------><
'-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-'
'-'N'-'
При выполнении следующих задач из Центра Query Patroller или командной строки Query Patroller выводится предупреждение:
Это предупреждение выглядит так:
DQP1024W Creation, change, or removal of a query class will not
take effect until the Query Patroller server is restarted.
(Создание изменение или удаление класса запросов не вступит в силу,
пока не будет перезапущен сервер Query Patroller.)
В книге DB2 Query Patroller(TM) Guide: Installation, Administration, and Usage для Версии 8.2 сказано также, что необходимо перезапустить сервер Query Patroller после создания, изменения или удаления классов запросов, чтобы изменения вступили в силу.
Указанные выше предупреждение и утверждение в книге теперь не совсем верны. Изменения, внесенные при выполнении перечисленных выше задач для класса запросов, вступают в силу немедленно, если нет выполняемых или внесенных в очередь запросов. Если есть выполняемые или внесенные в очередь запросы, включая вновь переданные запросы, изменения классов запросов вступят в силу после завершения выполнения этих запросов. Если вы не хотите ждать завершения выполнения всех внесенных в очередь и выполняющихся запросов, перезапустите сервер Query Patroller.
Смыслы состояний запроса Отменен и Выполнен изменены следующим образом:
Если при запуске генератора данных хронологии (historical data generator) для Query Patroller таблицы объяснения не существуют, генератор создаст их. Однако настоятельно рекомендуется создать таблицы объяснения до запуска генератора данных хронологии. Создавая таблицы объяснения, поместите их в одном разделе. Создание таблиц объяснения в том же разделе повысит производительность утилиты объяснения. Это повысит также производительность генератора данных хронологии.
Если в столбце Explain Run (Запуск объяснения) отчета Query Activity over Time (Активность запросов по времени) хронологического анализа указано состояние Ran unsuccessfully (Неудачное выполнение), данные хронологии для этого запроса не сгенерированы. Поэтому такой запрос не появится в отчетах и диаграммах хронологического анализа. Как сказано в документации Версии 8, для определения причин неудачи запроса надо проверить файл qpuser.log.
Кроме этого, проверьте файл qpdiag.log.
После запуска и аварийного завершения генератора данных хронологии при следующей попытке его запуска вы получите ошибку. Примеры аварийного завершения:
После аварийного завершения генератора данных хронологии перед попыткой повторного его запуска необходимо ввести следующую команду:
qp -d база_данных generate historical_data stop
где база_данных - база данных, для которой выполняется команда.
Для некоторых операций с классами запросов более не требуется останавливать и перезапускать Query Patroller, чтобы изменения вступили в силу.
В следующей таблице активным запросом называется запрос в состоянии Выполняется или В очереди.
Вложенные запросы не могут вноситься в очередь. Вместо этого они запускаются немедленно по превышении порога, который для обычных запросов вызывает внесение в очередь.
В противоположность тому, что указано в более ранней документации, могут вноситься в очередь запросы со следующими операторами:
При использовании клиента Terminal Services с разрешением 640x480 для соединения с удаленным настольным компьютером, на котором работает Центр Query Patroller, окно предпочтений передачи запросов может выглядеть пустым. Для правильного отображения окна предпочтений передачи запросов необходимо разрешение экрана выше 640x480.
Начиная с Версии 8.2, DB2 Universal Database (UDB) поддерживает группы пользователей, отличные от групп операционной системы. С этим связано небольшое изменение в выпадающем списке Использовать профиль пользователя в окне предпочтений передачи запросов в Центре Query Patroller.
Если вы зарегистрировались, но не имеете полномочий DBADM или привилегий редактирования для управление пользователями Query Patroller, вы можете добавлять и изменять предпочтения передачи запросов только для себя. В этом случае в выпадающем списке Использовать профиль пользователя помимо групп операционной системы, к которым вы принадлежите, будут существующие профили пользователей ваших групп DB2 UDB.
Если вы зарегистрировались, и у вас есть полномочия DBADM или привилегии редактирования для управление пользователями Query Patroller, вы можете добавлять и изменять предпочтения передачи запросов для других пользователей. В этом случае в выпадающем списке Использовать профиль пользователя будут все существующие профили групповых пользователей.
При работе с расписаниями в Центре Query Patroller в окне Расписание можно сохранять расписания в файл и затем импортировать их. Если у вас есть расписание, сохраненное на уровне пакета FixPak 6 или ранее, вы не можете импортировать данное расписание при помощи Версии 8.2 и новее. Это ограничение связано с различиями между уровнями JDK при преобразовании объектов Java в последовательную форму, которые появились, начиная с DB2 UDB Версии 8.2.
Для запуска команды RUN IN BACKGROUND QUERY необходимо быть пользователем, подавшим сам запрос.
Как и в Query Patroller Версии 8.1 FixPak 5, Query Patroller больше не создает таблиц результата в схеме, соответствующей ID авторизации передающего запрос. Вместо этого Query Patroller начал создавать таблицы результатов в общей схеме DB2QPRT. Чтобы на таблицы результатов можно было ссылаться при помощи схемы пользователя, в Query Patroller Версии 8.2 появилась опция автоматического создания алиаса для каждой новой таблицы результатов, создаваемой Query Patroller. Таблица результатов создается в схеме DB2QPRT, а алиас создается в схеме, соответствующей ID авторизации пользователя.
Чтобы включить или отключить эту опцию, введите команду UPDATE QP_SYSTEM с опцией CREATE_RESULT_TABLE_ALIASES:
Алиасы, созданные при помощи опции CREATE_RESULT_TABLE_ALIASES, автоматически отбрасываются, когда отбрасывается таблица результатов. Но есть две ситуации, в которых таблица результатов может оказаться отброшена без соответствующего алиаса.
Чтобы вычистить алиасы, не соответствующие таблицам результатов, создана новая команда - REMOVE RESULT_TABLE_ALIASES. Эта команда выполняется при каждой очистке таблиц результата, что происходит автоматически как часть расписания очистки таблиц результата Query Patroller. Команда REMOVE RESULT_TABLE_ALIASES получает список алиасов для очистки при помощи следующего запроса:
with a as (select tabschema, tabname from syscat.tables
where type = 'A' and tabname like 'QUERY%_RESULTS'),
t as (select tabname from syscat.tables
where type = 'T' and tabname like 'QUERY%_RESULTS')
select all tabschema, tabname from a
where not exists (select * from t where t.tabname=a.tabname)
У вас должны быть полномочия DBADM.
Это команда удалит все алиасы, оставшиеся после отбрасывания соответствующих таблиц результатов. Эти алиасы были созданы Query Patroller для таблиц результатов.
Query Patroller использует некоторые хранимые процедуры, которые могут записывать сообщения в файл журнала qpdiag.log. Поэтому у ID изолированного пользователя должен быть доступ для записи в файл qpdiag.log и в каталог, в котором находится этот файл.
[ Начало страницы |Страница назад | Страница вперед | Содержание ]