Início / dba / Perguntas / 34603
Accepted
JHFB
Asked: 2013-02-13 07:38:32 +0800 CST

existem diferenças significativas com mais de 500 milhões de tabelas de linhas no Oracle?

  • 772

Estou em um designer de banco de dados em um ambiente de data warehouse. Estou acostumado a lidar com tabelas com no máximo 1 milhão de linhas e agora me deparo com tabelas com mais de meio bilhão de linhas. Existem diferenças significativas com as ferramentas da "caixa de ferramentas de eficiência"? Posso confiar em meu conhecimento anterior de índices, partições e afins ou algumas dessas ferramentas específicas são mais um obstáculo do que uma ajuda com dados tão grandes? Alguma outra dica para lidar com as tabelas?

(Já encontrei um ótimo post sobre como atualizar 700 milhões de linhas para o mesmo valor )

oracle-11g-r2

2 respostas

  1. Best Answer

    Os fundamentos da indexação, etc., funcionam exatamente da mesma maneira, portanto, estritamente falando, a única diferença é o custo de errar!

    Dito isso, aqui está uma lista (não necessariamente completa) de coisas que vale a pena ter em mente:

    • É provável que os índices de árvore B tenham um nível extra neles, portanto, o custo de usá-los é um pouco maior. No entanto, em um DW, você deve usar índices de bitmap (supondo que você tenha a edição corporativa)
    • Levará muito mais tempo para calcular as estatísticas de toda a mesa - a ponto de não ser possível na janela noturna normal. Isso pode ser superado por
      • Usar um menor estimate_percentao coletar estatísticas para que menos da tabela seja amostrada.
      • Usando coleta de estatísticas incrementais (relevante apenas se você tiver índices globais em tabelas particionadas)
    • Histogramas para índices são limitados a 254 buckets. Mais linhas provavelmente significam valores mais distintos, o que significa que valores "quase populares" podem ser um problema maior para dados distorcidos.
    • As chances de toda a sua tabela caber no cache do buffer se aproximam de zero, o que significa que é mais provável que você tenha mais leituras físicas (disco). Seu conjunto de trabalho normal também pode ser muito grande para ser armazenado em cache.
    • O particionamento pode ser seu amigo - se você acertar! Se você geralmente modifica e consulta dados em várias partições, isso pode custar mais do que tabelas simples.
    • Visualizações materializadas podem ser muito úteis para reduzir seu conjunto de trabalho. por exemplo, se você tiver mais de 10 anos de dados, mas a grande maioria das consultas do usuário for apenas nos últimos 2 anos, criar um MV limitado apenas a esses dados pode ser uma grande ajuda.
    • Quanto maior o banco de dados, menor a probabilidade de a empresa financiar (ser capaz de) um banco de dados de teste que seja uma duplicata completa do ambiente ativo. Isso dificulta a reprodução de problemas de desempenho no teste, pois as consultas lentas podem ocorrer devido à escala e/ou armazenamento físico dos dados. Você não pode contar com a capacidade de extrapolar os resultados da consulta de um banco de dados de teste muito menor para o desempenho correspondente ao vivo.

    Se você ainda não está familiarizado com a leitura e a compreensão dos planos de execução, eu gastaria algum tempo aprendendo isso: você pode ter problemas de desempenho em algum momento, então saber como diagnosticar o problema corretamente se tornará mais importante, pois é mais difícil adicionar novos índices ou fazer alterações de esquema quando suas contagens de linhas forem maiores.

    • 7

  2. A quantidade tem uma qualidade própria.

    Ao lidar com tabelas desse tamanho, ajuda não pensar na tabela de fatos como uma tabela, mas pensar nela no nível do segmento ou como uma coleção de tabelas discretas. (Ter idade suficiente para lembrar o particionamento do meu próprio com exibições de partição ajuda.)

    O papel Scaling to Infinity de Tim Gorman é um recurso inestimável.

    • 4

relate perguntas