Query Patroller

Atualizações de Definições para Estados de Consultas Gerenciados

Os significados dos status de consulta Cancelado e Concluído são atualizados como se segue:

Cancelado: A consulta foi cancelada, através da linha de comandos do Query Patroller Center ou do Query Patroller, pelo administrador, submissor ou um operador cujo perfil tem o privilégio MONITORING com autoridade de edição. Apenas as consultas em execução, retido, liberado e enfileirado podem ser canceladas.
Concluído: A consulta foi concluída com êxito.
Nota:

Embora a consulta em si tenha sido concluída sem erro, o aplicativo poderá receber um erro se a conclusão tiver sido causada por um evento externo, como uma aplicativo DB2 force.

Criar Tabelas de Explicação antes de Executar o Gerador de Dados Históricos do Query Patroller

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.

Verificando Arquivos de Log do Query Patroller para Análise do Histórico

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.

Encerramento Anormal do Gerador de Dados Históricos

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:

O DB2 Universal Database é interrompido inesperadamente
Emissão do comando db2stop force
Emissão do comando killdb2 force

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.

Atualização Dinâmica de Classes de Consultas

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.

Tabela 28. Condições para que as Alterações na Classe de Consultas Sejam Efetivadas
Tipo de Alteração	Condições para que Alterações Sejam Efetivadas
Inclusão, remoção ou atualização de uma classe de consultas.	Se não existirem consultas ativas, as alterações são efetuadas imediatamente.
Atualização de uma classe de consulta que envolve apenas uma alteração no Número máxima de consultas.	É efetuada imediatamente, mesmo que existam consultas ativas.
Atualização de uma classe de consulta que envolve apenas uma alteração no Custo máxima de uma consulta.	Se existirem consultas ativas, a atualização será efetuada quando: O Query Patroller for parado e reiniciado. Não existirem mais consultas ativas. Nota: Quando existir uma pendência no Custo máximo de uma consulta, atualizações posteriores de qualquer tipo de classes de consultas não serão efetuadas até que uma das duas condições acima sejam cumpridas.
Inclusão ou remoção de uma classe de consulta.	Se existirem consultas ativas, a inclusão ou a remoção será efetuada quando: O Query Patroller for parado e reiniciado. Não existirem mais consultas ativas.

Comportamento de Consultas Aninhadas

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.

Limitações pelo Tipo de Instrução SQL

Ao contrário do que foi dito na documentação anterior, as consultas com as instruções a seguir podem ser enfileiradas:

Consultas contendo SQL estático com variáveis de host
Consultas contendo uma função de valor de identidade (IDENTITY_VAL_LOCAL) ou uma função de valor de seqüência, tais como NEXT VALUE FOR ou PREVIOUS VALUE FOR

Limitação de Resolução ao Utilizar o Terminal Services Client

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.

Suporte ao Novo Grupo para Envio de Consultas

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.

Limitações de Planejamento do Query Patroller

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.

Autorização Requerida para Utilizar o Comando RUN IN BACKGROUND QUERY

Para executar o comando RUN IN BACKGROUND QUERY, você precisa ser o submissor que enviou a consulta originalmente.

Criando uma Alias para uma Tabela de Resultados

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'-'

Removendo Aliases Órfãos da Tabela de Resultados

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.

Quando a tabela de resultados for eliminada manualmente sem utilizar a linha de comandos qp ou o Query Patroller Center.
Quando a tabela de resultados for eliminada utilizando a linha de comandos qp ou o Query Patroller Center com a autoridade de um operador que não é o submissor da consulta e não possui a autoridade DBADM.

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)

Pré-requisitos

Você deve ter a autoridade DBADM.

Procedimento

Emita o comando REMOVE RESULT_TABLE_ALIASES

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.

Sintaxe do comando

>>-REMOVE RESULT_TABLE_ALIASES---------------------------------><

Nota:

Para obter informações sobre como digitar comandos do Query Patroller utilizando a interface da linha de comandos e a sintaxe geral de comandos do Query Patroller, consulte a interface da linha de comandos do Query Patroller.

O ID de Usuário Protegido Requer o Arquivo qpdiag.log e o Caminho de Acesso de Gravação

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 ]