Onze dias atrás, escrevi no blog sobre como o Adaptive Dynamic Stats estava consumindo recursos em meus bancos de dados RAC de produção.
Depois de apagar o incêndio, eu estava examinando algumas consultas de baixo desempenho relatadas por nosso pessoal de controle de qualidade no teste e em outros bancos de dados que não são de produção. Fiz como qualquer bom DBA Oracle faria. Reuni uma chamada de procedimento armazenado que duplicou o problema. Na minha sessão, iniciei um rastreamento SQL e executei o procedimento armazenado. Demorou 50 segundos para ser concluído, quando costumava levar 5 segundos ou menos antes de eu atualizar de 11.2.0.4 para 12.1.0.2. Esse procedimento armazenado contém várias instruções SQL e um rastreamento SQL parecia um lugar lógico para começar. Eu precisava saber qual instrução SQL no procedimento estava causando os problemas.
Executei o arquivo de rastreamento SQL através do TKPROF e fiquei surpreso com os resultados. As instruções SQL no procedimento armazenado pareciam estar sendo executadas muito rapidamente. Mas fui saudado por muitas declarações semelhantes às seguintes:
SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring
optimizer_features_enable(default) no_parallel */ SUM(C1)
FROM
(SELECT /*+ qb_name("innerQuery") INDEX_FFS( "XXX"
"INDEX_NAME") */ 1 AS C1 FROM
"OWNER"."TABLE_NAME" SAMPLE BLOCK(71.048, 8) SEED(1)
"XXX") innerQuery Esta é a Amostragem Dinâmica em ação. Ao examinar todas as instruções de amostragem dinâmica sendo executadas em meu arquivo de rastreamento, pude determinar que elas representavam 45 segundos do tempo de execução geral! Caramba!
A amostragem dinâmica deve me ajudar. O tempo gasto para obter algumas estatísticas de amostra deve ser muito menor do que o tempo economizado executando a instrução SQL com estatísticas melhores. Se isso não acontecer, o desempenho da sua instrução SQL pode sofrer, como foi o meu caso.
Observei que uma coisa que achei interessante foi que essas consultas de amostragem dinâmica foram executadas uma vez para cada tabela e uma vez para cada um de seus índices. Uma das tabelas envolvidas na minha consulta tem 7 índices, então, para essa tabela, eu tinha 8 consultas de amostragem dinâmica!
Em minha postagem no blog 11 dias atrás, eu havia definido o parâmetro optimizer_dynamic_sampling como 0, o que impede que essas consultas sejam executadas. Eu ainda não tinha colocado essa mudança em nosso ambiente de teste, então precisava fazer isso. Assim que fiz isso, o desempenho da consulta voltou ao normal. O valor padrão deste parâmetro para meu banco de dados é 2. Seu valor padrão pode ser diferente dependendo do valor da configuração optimizer_features_enable. De acordo com esta postagem do blog, um valor de 2 significa que a amostragem dinâmica será ativada quando pelo menos uma das tabelas não tiver estatísticas. Mas, para ser honesto, a amostragem dinâmica não está me trazendo nenhum benefício e só me causa danos. Então, vou deixá-lo em sua totalidade por enquanto.
