Uma mensagem de aviso é retornada quando uma das tarefas a seguir é executada através da linha de comandos do Query Patroller Center ou do Query Patroller:
A mensagem de aviso é:
DQP1024W Criação, alteração ou remoção de uma classe de consultar não terá efeito até reiniciar o servidor Query Patroller.
De forma semelhante, o DB2 Query Patroller(TM) Guia de: Instalação, Administração e Utilização, Versão 8.2, afirma se é necessário reiniciar o servidor Query Patroller após criar, alterar ou remover classes de consulta para que as alterações tenham efeito.
A mensagem e a instrução no guia não são mais precisas. As três classes de consulta listadas anteriormente terão efeito imediatamente, a menos que haja consultas em fila ou em execução. Se há consultas em fila ou em execução, incluindo consultas recém enviadas, as alterações de classes de consulta terão efeito ao concluir as consultas em fila ou em execução. Se você não deseja aguardar que todas as consultas em fila ou em execução sejam concluídas, é necessário reiniciar o servidor Query Patroller.
Os significados dos status de consulta Cancelado e Concluído são atualizados como se segue:
Ao executar o gerador de dados históricos para o Query Patroller, se as Tabelas de explicação ainda não existirem, o gerador irá criá-las. No entanto, é altamente recomendável que você crie as Tabelas de Explicação antes de executar o gerador de dados históricos. Ao criar as Tabelas de Explicação, certifique-se de criá-las na mesma partição. Criar ativamente as Tabelas de Explicação na mesma partição aprimora o desempenho dos recursos do Explain. Esse aperfeiçoamento aumenta o desempenho do gerador de dados históricos.
Se a coluna Explain Run do relatório do Query Activity over Time (Análise do Histórico) mostrar um status de Ran unsuccessfully para uma consulta, os dados históricos não foram gerados para aquela consulta. Portanto, a consulta não aparecerá em nenhum relatório ou gráfico de análise do histórico. Conforme documentado na Versão 8, para determinar porque a consulta não foi bem-sucedida, você pode examinar o arquivo qpuser.log.
No entanto, além de examinar o arquivo qpuser.log, você deve também examinar o arquivo qpdiag.log.
Se você executar o gerador de dados históricos e encerrá-lo de forma anormal, receberá um erro na próxima vez em que tentar executar o gerador de dados históricos. Exemplos de encerramento anormal incluem:
Quando o gerador de dados históricos for encerrado anormalmente, será necessário emitir o seguinte comando antes de tentar executar novamente o gerador de dados históricos:
qp -d database generate historical_data stop
onde database identifica o banco de dados onde o comando está sendo executado.
Algumas operações de classe de consultas não requerem mais que o Query Patroller seja parado e reiniciado para se tornarem efetivas.
Na tabela a seguir, uma consulta ativa é uma consulta cujo status é Executar ou Enfileirar.
Consultas aninhadas não podem ser enfileiradas. Ao contrário, uma consulta aninhada será executada imediatamente quando exceder o limite que normalmente gera o enfileiramento.
Ao contrário do que foi dito na documentação anterior, as consultas com as instruções a seguir podem ser enfileiradas:
Ao utilizar o Terminal Services Client na resolução 640x480 para conectar-se a um desktop remoto que esteja executando o Query Patroller Center, a janela Preferências de Envio poderá parecer vazia. Para que a janela Preferências de Envio seja exibida corretamente, é necessário utilizar uma resolução superior a 640x480.
Iniciando na Versão 8.2, o DB2 UDB (Universal Database) suporta grupos de usuários além dos grupos do sistema operacional. Portanto, existe uma pequena alteração na lista drop-down Perfil do Submissor a Ser Utilizado na janela Preferências de Envio de Consulta do Query Patroller Center.
Se efetuou login, mas não precisa da autoridade DBADM ou Editar Privilégio para administração de usuários do Query Patroller, você mesmo poderá apenas incluir ou atualizar uma preferência de envio. Neste caso, a lista drop-down Perfil do Submissor a ser Utilizado contém perfis existentes do submissor dos grupos do DB2 UDB aos quais você pertence, em vez de apenas os grupos de sistema operacional aos quais você pertence.
Se você efetuou login e possui a autoridade DBADM ou Editar Privilégio para administração de usuários do Query Patroller, poderá incluir ou atualizar preferências de envio para outros usuários. Neste caso, a lista drop-down Perfil do Submissor a Ser Utilizado contém todos os perfis do submissor de grupos existentes.
Ao trabalhar com planejamentos no Query Patroller Center, você pode utilizar a janela Planejamento para salvar planejamentos em um arquivo e importá-los posteriormente. Se você tiver um planejamento salvo utilizando o FixPak 6 ou anterior, não poderá importar o planejamento utilizando a Versão 8.2 ou posterior. Esta limitação ocorre devido à alteração na serialização entre níveis JDK introduzidos com o DB2 UDB Versão 8.2.
Para executar o comando RUN IN BACKGROUND QUERY, você precisa ser o submissor que enviou a consulta originalmente.
A partir do Query Patroller Versão 8.1 FixPak 5, o Query Patroller parou de criar tabelas de resultados no esquema que correspondia ao ID de autorização do submissor da consulta. Em vez disso, o Query Patroller começou a criar tabelas de resultados em um esquema DB2QPRT comum. Para permitir que tabelas de resultados sejam referidas utilizando o esquema do submissor, o Query Patroller Versão 8.2 introduz uma opção para criar automaticamente um alias para cada nova tabela de resultados criada pelo Query Patroller. A tabela de resultados é criada no esquema DB2QPRT e o alias é criado em um esquema que corresponde ao ID de autorização do submissor.
Para ativar ou desativar esta opção, emita o comando UPDATE QP_SYSTEM com a opção CREATE_RESULT_TABLE_ALIASES:
>>-UPDATE QP_SYSTEM USING---------------------------------------> >--+-DEFAULT------------------------------+-------------------->< '-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-' '-'N'-'
Os aliases criados com a opção CREATE_RESULT_TABLE_ALIASES são automaticamente eliminados quando uma tabela de resultados é eliminada. No entanto, existem duas situações em que uma tabela de resultados pode ser eliminada sem a eliminação do alias correspondente.
Para limpar aliases que não possuem tabelas de resultados correspondentes, foi criado um novo comando, REMOVE RESULT_TABLE_ALIASES. Este comando é executado automaticamente sempre que as tabelas de resultados são limpas como parte do processo planejado de limpeza de tabelas de resultados do Query Patroller. O comando REMOVE RESULT_TABLE_ALIASES obtém a lista de aliases a serem limpos utilizando a seguinte consulta:
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)
Você deve ter a autoridade DBADM.
Este comando remove todos os aliases existentes após a eliminação das tabelas de resultados correspondentes. Os aliases foram originalmente criados pelo Query Patroller para tabelas de resultados.
>>-REMOVE RESULT_TABLE_ALIASES---------------------------------><
O Query Patroller utiliza alguns procedimentos armazenados protegidos que podem registrar entradas para o arquivo qpdiag.log. Portanto, o ID de usuário protegido deve ter acesso à gravação para o arquivo qpdiag.log e o caminho em que o arquivo qpdiag.log reside.
[ Início da Página |Página Anterior | Próxima Página | Índice ]