Diagnóstico de tabela

Taxa de distorção

Contexto

Colunas de distribuição impróprias podem causar distorção grave durante a computação do operador ou derramamento de dados para o disco. As cargas de trabalho serão distribuídas de forma desigual em DNs, resultando em alto uso de disco em um único DN e afetando o desempenho. Você pode consultar a taxa de distorção da tabela e alterar a coluna de distribuição para as tabelas com distorção severa. Para clusters da versão 8.1.0 ou posterior, consulte ALTER TABLE. Para outras versões, consulte Como alterar colunas de distribuição?.

Procedimento

1. Faça logon no console de gerenciamento do GaussDB(DWS).
2. Na página Clusters, localize o cluster de destino.
3. Na coluna Operation do cluster de destino, clique em Monitoring Panel.
4. Na árvore de navegação à esquerda, escolha Utilities > Table Diagnosis e clique na guia Skew Rate. As tabelas que atendem às condições de coleta de estatísticas no cluster são exibidas.

   

Taxa de página suja

Contexto

As operações DML em tabelas podem gerar dados sujos, que ocupam desnecessariamente o armazenamento do cluster. Você pode consultar a taxa de páginas sujas e lidar com grandes tabelas e tabelas com alta taxa de páginas sujas. Para obter detalhes, consulte Solução para alto uso de disco e cluster somente leitura.

Procedimento

1. Faça logon no console de gerenciamento do GaussDB(DWS).
2. Na página Clusters, localize o cluster de destino.
3. Na coluna Operation do cluster de destino, clique em Monitoring Panel.
4. Na árvore de navegação à esquerda, escolha Utilities > Table Diagnosis e clique na guia Dirty Page Rate. As tabelas que atendem às condições de coleta de estatísticas no cluster são exibidas.

   

Auditoria de DDL

Exibir e exportar resultados da auditoria de DDL

1. Faça logon no console de gerenciamento do GaussDB(DWS).
2. Na página Clusters, localize o cluster de destino.
3. Na coluna Operation do cluster de destino, clique em Monitoring Panel.
4. Na árvore de navegação à esquerda, escolha Utilities > Table Diagnosis e clique na guia DDL Audit. Os resultados da auditoria são exibidos.

   

   

   Os itens de auditoria selecionados são exibidos na guia DDL Audit por padrão. Você pode configurar os itens de auditoria na guia Coleta de monitoramento. Para obter mais informações, consulte Tabela 1.

   Tabela 1 Itens de auditoria

   Item	Descrição
   Number of Distribution Keys (disKeyCount)	Se não houver distorção de dados, não use mais do que quatro chaves de distribuição. Geralmente, se você usar muitas chaves de distribuição, os dados podem ser distribuídos uniformemente em um cluster, evitando assim a distorção de dados. No entanto, se forem utilizadas demasiadas chaves de distribuição, o desempenho de armazenamento e o desempenho de consulta conjunta poderão deteriorar-se. É aconselhável configurar não mais do que quatro chaves de distribuição. Problema de desempenho de armazenamento: Quando os dados são adicionados, a função hash calcula o resultado de cada coluna de distribuição, agrega os resultados e, em seguida, determina onde distribuir os dados. Um grande número de chaves de distribuição requer cálculo demorado e complexo. Problema de desempenho da consulta de junção: Durante a consulta join de várias tabelas, se todas as colunas da chave de distribuição estiverem envolvidas na condição join, os dados não precisarão ser redistribuídos no plano de execução. Se um grande número de chaves de distribuição for usado, algumas delas podem não ser as colunas envolvidas na condição join, e a redistribuição de dados pode ocorrer, o que consome muitos recursos e leva muito tempo.
   Number of Index Columns/PCKs (indexKeyOrPckCount)	Recomenda-se que o número de chaves de cluster parciais (PCKs)/colunas de um índice seja menor ou igual a 4. Um grande número de colunas de índice requer muitos recursos para manter os dados de índice e é provável que contenham índices duplicados. Enquanto os dados de armazenamento de colunas são importados, as colunas de PCK são comparadas e calculadas para determinar a divisão de CU. Um grande número de PCKs consumirá muitos recursos e muito tempo, afetando o desempenho. Para filtrar eficientemente CUs em uma consulta, os prefixos das colunas envolvidas nas condições de consulta devem ser colunas PCK e b>? (Por exemplo, se as colunas PCK forem a, b e c, os critérios de consulta deverão ser a>? and b>? and c>?.) Caso contrário, todas as CUs devem ser percorridas, e o agrupamento de dados não contribui para a aceleração da consulta.
   Invalid PCKs (invalidPck)	Não crie colunas de PCK inválidas. Em 8.1.1 e versões posteriores, o cluster pode filtrar e comparar dados dos tipos char, int8, int2, int4, text, bpchar, varchar, date, time, timestamp e timestamptz. Se uma coluna de um tipo de dados sem suporte for usada como uma PCK, a coluna será uma coluna de PCK inválida. Não entra em vigor durante a filtragem de CU e consumirá recursos para sua manutenção.
   numeric Data Usage (validityOfNumeric)	Quando tipos de dados numéricos são usados, use números inteiros, se possível. Se o requisito de precisão não for alto, use o tipo de dados float de comprimento fixo. O tipo de dados float de comprimento fixo tem melhor desempenho de computação do que o tipo de dados numérico de comprimento variável. Ou seja, se o tipo numérico for usado, é aconselhável especificar a escala e a precisão dentro de 38 bits. Quando o tipo numérico é usado para cálculo, a camada subjacente tenta converter o cálculo para o cálculo entre int e bigint para melhorar a eficiência do cálculo. Ou seja, é utilizada a otimização de inteiros grandes do tipo de dados. Em 8.1.1 e versões posteriores, se nenhuma precisão for especificada, um máximo de dígitos 131.072 pode ser colocado antes do ponto decimal e um máximo de dígitos 16.383 pode ser colocado após o ponto decimal. Ou seja, a escala e a precisão máximas são usadas. Neste caso, a otimização de inteiros grandes não pode ser realizada durante o cálculo e a eficiência do cálculo diminui de acordo.
   Index Column Width (widthOfIndexKey)	Geralmente, as colunas de índice largo são colunas de cadeia de caracteres, que não envolvem operações de comparação e levarão a índices grandes que consomem espaço desnecessário. Especifique um valor menor que 64 bytes.
   Replication Table Size (sizeOfCopyTable)	As tabelas que ocupam mais espaço de armazenamento do que o limite (100 MB) em um único DN serão identificadas. Para essas tabelas, é aconselhável usar colunas associadas comuns como chaves de distribuição (geralmente com uma chave primária). O cluster suporta tabelas de replicação. Uma tabela de replicação mantém uma cópia completa dos dados em cada nó e é usada principalmente para armazenar dados de tipos enumerados. Se uma tabela contiver muitos dados, ela ocupará uma grande quantidade de espaço. Além disso, em uma consulta de união, o nó atravessa todos os dados da tabela, o que pode levar mais tempo do que a consulta de união depois que o tipo de tabela é alterado para tabela de distribuição. (Embora os dados possam ser redistribuídos na tabela de distribuição, a quantidade de dados percorridos por cada nó diminui.)
   Skew Detection for Single-Distribution-Key Tables (recognitionOfDataSkew)	A distorção de dados de tabelas de chave de distribuição única é detectada pelas estatísticas. Esta auditoria aplica-se apenas a tabelas com uma chave de distribuição.
   Distribution Key Usage (validityOfDiskey)	Em um cluster, você não é aconselhável usar uma coluna do tipo boolean ou data como uma coluna de distribuição, porque isso pode causar distorção de dados.
   Number of Cached Sequence Values (cacheSizeOfSequence)	Especifique um número maior que 100. Se uma coluna de tabela usar sequências, seu next_value será obtido a partir do valor armazenado em cache no nó local. Se os valores de sequência em cache forem usados, uma solicitação será enviada solicitando ao GTM que obtenha o valor novamente. Se uma grande quantidade de dados for adicionada, mas apenas alguns valores forem armazenados em cache, o GTM receberá muitas solicitações e poderá ficar sobrecarregado e até mesmo quebrar. Para evitar esse problema, é aconselhável definir o valor de cache para um valor maior que 100 ao criar uma sequência.
   Optimizable Indexes (optimizableIndexKey)	Cenários onde os índices podem ser otimizados: A coluna de índice de um índice é as primeiras N colunas de outro índice. As colunas de índice de dois índices são as mesmas, mas as ordens são diferentes.

5. Se o resultado da revisão de um item for Failed, clique em View para ir para a página de detalhes.

   

6. Clique em Export no canto superior esquerdo para exportar o resultado da auditoria.

   

Auditar manualmente itens de DDL

1. Faça logon no console de gerenciamento do GaussDB(DWS).
2. Na página Clusters, localize o cluster de destino.
3. Na coluna Operation do cluster de destino, escolha Monitoring Panel. A página de monitoramento do banco de dados é exibida.
4. Na árvore de navegação à esquerda, escolha Utilities > Table Diagnosis e clique na guia DDL Audit. Na página exibida, selecione os itens a serem auditados e clique em One-Click Audit.