Alterações na Arquitetura da Aplicação – Migração para Oracle RAC

Seguem as minhas considerações sobre migração de uma aplicação em Oracle Single Instance para Oracle RAC, que passo no Curso de Oracle RAC Performance Tuning.

– Full Table Scans são exponencialmente mais danosos em RAC.
– Sequences Artificiais são exponencialmente mais danosas em RAC. Use Sequences do Oracle, e com CACHE e NOORDER, se sua regra de negócio permitir.
– O não uso de Bind Variables é exponencialmente mais danosos em RAC, assim como o uso de CURSOR_CHARING=FORCE.
– Optimizer Statistics, Histograms, System Statistics devem estar em dia, sempre, mais do que em Single Instance. Lembre-se que FTSs são muito piores em RAC.
– Use Locally Managed Tablespaces e ASSM, sempre.
– Use apenas Reverse Key Indexes para tabelas de grande volume de INSERTs.
– Use Partitioningpara seus maiores segmentos.
– Troque o Job pelo Scheduler. O Job “não sabe” que está em RAC.
– DBMS_ALERT “não sabe” que está em RAC.
– DBMS_PIPE “não sabe” que está em RAC.
– UTL_FILE “não sabe” que está em RAC.
– V$SESSION “não sabe” que está em RAC.
– Directories / External Tables / Data Pump / BFILEs dependem de diretórios físicos, e portanto, devem ser utilizados em diretórios compartilhados.

Leave a Reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.