Como otimizar melhor um banco de dados Oracle para gravações?

Question

Como posso maximizar o desempenho de gravação sem afetar as leituras?

    

Answer 1

Um bom começo é seguir a metodologia SAME da Oracle - Stripe and Mirror Everything. Isto dá-lhe uma boa base a partir da qual pode adicionar mais melhorias específicas.

A metodologia SAME está no seguinte PDF:

link

Há uma boa discussão sobre o Ask Tom:

link

Um dos principais impulsionadores do SAME é a facilidade de administração. Ele transmite muitas das considerações de desempenho para o sistema operacional e a camada de armazenamento subjacente. A ideia é que seus arquivos de espaço de tabela já estejam espalhados por um zilhão de discos na matriz de armazenamento, de modo que qualquer tentativa de mexer com você, além disso, não ajuda muito. No entanto, como sempre, o diabo está no detalhe. É tentador tratar a camada de armazenamento como uma caixa preta, mas você realmente precisa entender o que está acontecendo e saber o que fica sob cada um dos seus arquivos de espaço de tabela.

    

Answer 2

De um POV não-quero-tocar-o-config - verifique seus índices. se você estiver gravando em tabelas que são strongmente indexadas, lembre-se de que, toda vez que você escreve uma linha, os índices estão sendo alterados. Menos índices, menos IO físico.

Isso - obviamente - terá um impacto nas leituras.

Se você tiver o tempo & capacidade, eu encontrei separando tabelas comumente escritas em tablespaces específicos e certificando-se de que / aqueles tablespaces são armazenados em um canal RAID separado também ajuda, mas isso depende do hardware que você está usando e adiciona um monte de outras considerações.

Se você realmente tiver tempo para refletir sobre isso, compre & leia Cary Millsaps 'Otimizando o Oracle Performance' - está datado (todos dependendo de qual versão do oracle você está usando) mas um clássico.

    

Answer 3

Configure-o em um cluster e faça com que seus aplicativos apontem para um nó específico para gravações; então leia do próprio cluster.

    

Answer 4

Implementando SAME - Distribuição e Espelhamento Tudo como sugerido em uma resposta anterior - é uma boa estratégia padrão. Em particular, se você está preocupado com o desempenho de gravação evita o RAID5 a todo custo - ele cria uma sobrecarga de gravação de 4x enquanto mantém as informações de paridade. Um array RAID5 com um grande cache de memória pode esconder essa sobrecarga por um tempo, mas para gravações prolongadas a penalidade do RAID 5 será eventualmente sentida.

Há muitas coisas a serem consideradas na otimização da escrita IO, mas aqui estão mais algumas coisas a serem consideradas:

• Verifique se há dispositivos de disco suficientes na faixa para suportar a taxa de E / S. Você precisa colocar discos suficientes na faixa para suportar o total de I / O por segundo necessário, não apenas o número de GB a ser armazenado. O disco fornece melhor tempo de resposta quando está parcialmente cheio de dados - as partes externas do disco podem fornecer dados mais rapidamente do que as partes internas. Então, em geral, você quer ter discos esparsamente preenchidos em sua faixa.

• É melhor evitar o pedido de veiculação do que otimizar o pedido de veiculação. A maior fonte de IO de gravação evitável é o segmento IO temporário para classificações e operações de hash. O dimensionamento correto do PGA Aggregate Target é a melhor maneira de evitar isso.

• Certifique-se de que todos os seus índices estejam atendendo a uma finalidade válida: acelerar uma consulta ou impor chaves primárias ou estrangeiras. A manutenção do índice geralmente é a maior fonte de IO de gravação, portanto, não há índices supérfluos.

• Crie logs de redo grandes e numerosos. Isso ajuda a evitar a sobrecarga do switch de log e as paralisações do banco de dados que podem ocorrer quando os logs são interrompidos antes da conclusão dos pontos de verificação do arquivo de dados. Você também pode querer colocar seus redo logs em dispositivos dedicados ou em uma faixa dedicada de granulação fina.

• Use E / S assíncrona. Se seus arquivos de dados estiverem em sistemas de arquivos (por exemplo, não RAW ou ASM), configure FILESYSTEMIO_OPTIONS para AYNCH ou SETALL. O SETALL implementa o IO direto e o IO assíncrono, o que geralmente ajuda a escrever, mas pode diminuir a velocidade das leituras.

• Se você estiver preparado para assumir riscos com seus COMMITs, poderá alterar COMMIT_WRITE (10g) ou COMMIT_WAIT e COMMIT_LOGGING para atrasar ou em lote o IO que ocorre quando você emite uma confirmação. Certifique-se de entender as implicações, no entanto; Você pode perder algumas transações no caso de uma falha no banco de dados se fizer isso.

• Se você tiver acesso ao código do aplicativo, verifique se as inserções de matriz estão sendo usadas e - talvez - use inserções de caminho direto usando a dica APPEND.