Os fundamentos da indexação, etc., funcionam exatamente da mesma maneira; portanto, estritamente falando, a única diferença é o custo de cometer esse erro!
Dito isto, aqui está uma lista (não necessariamente completa) de coisas que vale a pena ter em mente:
- É provável que os índices das árvores B tenham um nível extra, portanto o custo de usá-los é um pouco mais alto. 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 estatísticas para toda a tabela - até o ponto em que pode não ser possível na janela normal da noite para o dia. Isso pode ser superado por
- Usando um menor
estimate_percentao coletar estatísticas, menos amostra da tabela é amostrada.
- Usando coleta incremental de estatísticas (relevante apenas se você tiver índices globais em tabelas particionadas)
- Os 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 sua tabela inteira caber no cache do buffer são quase nulas, 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.
- Particionar pode ser seu amigo - se você acertar! Se você geralmente está modificando e consultando dados em várias partições, isso pode custar mais do que tabelas simples.
- As 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 de usuários ocorrerem nos últimos 2 anos, criar uma MV limitada a esses dados pode ser uma grande ajuda.
- Quanto maior a base de dados, menor a probabilidade de a empresa (conseguir) financiar um banco de dados de teste que é uma duplicata completa do ambiente ativo. Isso dificulta a reprodução de problemas de desempenho em 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, dedico algum tempo aprendendo o seguinte: você pode ter problemas de desempenho em algum momento; portanto, saber diagnosticar o problema corretamente se tornará mais importante, pois é mais difícil adicionar novas informações. índices ou faça alterações no esquema quando a contagem de linhas for maior.