Às vezes, a sabedoria convencional não é tão convencional ou comum. Como um caso em questão, os DBAs podem acreditar que o pool STREAMS é reservado estritamente para processos de fluxos. Esse não é o caso, pois outros utilitários da Oracle, como Data Pump e GoldenGate, usam esse pool. É claro que optar por usar o gerenciamento dinâmico alocará automaticamente a memória necessária quando uma demanda for feita, no entanto, essa memória deve vir de algum lugar. A Oracle vai ‘roubar’ o que precisa do cache de buffer e não será substituído imediatamente. Vejamos um exemplo provando isso, usando o Data Pump.
A 'vítima' será um banco de dados Oracle 12.1.0.2 configurado com streams_pool_size definido como 0 (como Streams não está configurado, a expectativa é que o pool não seja usado) e Gerenciamento Automático de Memória Compartilhada configurado (os parâmetros sga_target e sga_max_size são definido para valores diferentes de zero):
SQL> --SQL> -- O pool de streams NÃO é apenas forSQL> -- StreamsSQL> --SQL> -- Data pump e GoldenGate usamSQL> -- itSQL> --SQL> -- Não configurando um tamanho for the streamsSQL> -- pool pode causar problemas quando for SQL> -- first usedSQL> --SQL> --SQL> -- Observando os parâmetros do banco de dadosSQL> -- verifique os parâmetros sgaSQL> -- for sizingSQL> --SQL> mostre o parâmetro sgaNAME TIPO VALOR ------------------------------------ -------- --- ------------------------------lock_sga boolean FALSEpre_page_sga boolean TRUEsga_max_size big integer 600Msga_target big integer 600Munified_audit_sga_queue_size integer 1048576
Verificando a visualização V$SGA_DYNAMIC_COMPONENTS para componentes com tamanhos atuais diferentes de zero, os seguintes resultados são retornados:
SQL> SQL> formato de componente de coluna a29SQL> set linesize 300 numwidth 12SQL> SQL> selecione component, current_size, min_size, max_size, user_specified_size user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 de v$sga_dynamic_components 4 onde current_size> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE ----------------------------- -------- ---- ------------ ------------ ------------ ---------- -- ------------- --------- --------- ------------ pool compartilhado 176160768 146800640 176160768 0 6 CRESCIMENTO DIFERIDO 15-OUT-19 4194304grande pool 8388608 8388608 125829120 0 1 SHRINK DEFERRED 15-OUT-19 4194304java pool 4194304 4194304 4194304 0 0 STATIC 4194304 DEFAULT buffer cache 411041792 301989888 419430400 0 8 SHRINK DEFERRED 15-OUT-19 4194304Shared IO Pool 20971520 0 20971520 0 1 GROW IMEDIATE 15-OUT-19 4194304SQL>
Verificando se streams_pool_size está definido como 0:
SQL> SQL> --SQL> -- Verifique se o pool de fluxos está definido como SQL> -- 0SQL> --SQL> show parameter streamsNAME TYPE VALUE---------------- -------------------- ----------- ------------------- -----------streams_pool_size big integer 0SQL>
Uma exportação do Data Pump é executada e, posteriormente, os componentes de memória dinâmica são verificados quanto ao tamanho:
SQL> SQL> --SQL> -- Executa uma tarefa de exportação do Data PumpSQL> -- e veja o que acontece com o streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> coluna formato de componente a29SQL> set linesize 300 numwidth 12SQL> SQL> selecione component, current_size, min_size, max_size, user_specified_size user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 de v$sga_dynamic_components 4 onde current_size> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE------------------ ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------ pool compartilhado 197132288 146800640 197132288 0 11 CRESCIMENTO IMEDIATO 15-OUT- 19 4194304piscina grande 8388608 8388608 125829120 0 1 SHRINK DEFERRED 15-OCT-19 4194304java pool 4194304 4194304 4194304 0 0 STATIC 4194304streams pool 8388608 0 8388608 0 2 GROW IMMEDIATE 15-OCT-19 4194304DEFAULT buffer cache 381681664 301989888 419430400 0 15 SHRINK IMMEDIATE 15-OCT-19 4194304Shared IO Pool 20971520 0 20971520 0 1 GROW IMMEDIATE 15-OUT-19 41943046 linhas selecionadas.SQL>
Observe que o tamanho do cache do buffer DEFAULT foi reduzido para 381681664 a partir de uma configuração inicial de 411041792, em parte para ajudar a 'financiar' o pool de Streams. Testando essa ideia o streams_pool_size está configurado para 8M (o valor que o Oracle configurou para dinamicamente) e, para tornar os testes o mais iguais possível, o banco de dados é desligado e iniciado:
SQL> SQL> --SQL> -- Configura streams_pool_size para currentSQL> -- valueSQL> --SQL> -- Desliga e inicializa o banco de dadosSQL> --SQL> altera system set streams_pool_size=8M scope=spfile; Sistema alterado.SQL> SQL> shutdown imediatoDatabase closed.Database dismounted.ORACLE instance shutdown.SQL> startupORACLE instance started.Total System Global Area 629145600 bytesFixed Size 2927528 bytesVariable Size 289408088 bytesDatabase Buffers 331350016 bytesRedo Buffers 5459968 bytesDatabase montada.Database aberta. pré>
Os parâmetros de memória dinâmica verificados para valores iniciais:
SQL> SQL> --SQL> -- Verifica o dimensionamento dinâmico de componentes SGASQL> --SQL> formato de componente de coluna a29SQL> define tamanho de linha 300 numwidth 12SQL> SQL> seleciona componente, current_size, min_size, max_size, user_specified_size user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 de v$sga_dynamic_components 4 onde current_size> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE -------------------- --------- ------------ ------------ ------------ ----- ------- ------------ ------------- --------- --------- ------------pool compartilhado 155189248 146800640 155189248 0 2 CRESCIMENTO IMEDIATO 15-OUT-19 4194304pool grande 125829120 125829120 125829120 0 0 STATIC 41934304java pool 4194304 4194304java pool 4194304 4194304java pool 4 0 0 STATIC 4194304streams pool 8388608 8388608 8388608 8388608 0 STATIC 4194304DEFAULT buffer cache 327155712 327155712 335544320 0 2 SHRINK IMMEDIATE 15-OCT-19 4194304SQL> SQL> --SQL> -- Remove the previous dump fileSQL> --SQL> !/bin /rm /u01/app/oracle/admin/orcl/dpdump/scott.*
Execute o trabalho do Data Pump novamente com as configurações de pool de memória ajustadas:
SQL> SQL> --SQL> -- Executa uma tarefa de exportação do Data PumpSQL> -- e veja o que acontece com o streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> coluna formato de componente a29SQL> set linesize 300 numwidth 12SQL> SQL> selecione component, current_size, min_size, max_size, user_specified_size user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 de v$sga_dynamic_components 4 onde current_size> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE------------------ ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------ pool compartilhado 197132288 146800640 197132288 0 12 CRESCER IMEDIATAMENTE 15 DE OUTUBRO 19 4194304piscina grande 8388608 8388608 125829120 0 1 SHRINK DEFERRED 15-OCT-19 4194304java pool 4194304 4194304 4194304 0 0 STATIC 4194304streams pool 8388608 8388608 8388608 8388608 0 STATIC 4194304DEFAULT buffer cache 381681664 264241152 381681664 0 14 GROW DEFERRED 15-OCT-19 4194304Shared IO Pool 20971520 0 20971520 0 1 GROW IMMEDIATE 15-OCT- 19 41943046 linhas selecionadas.SQL>
Observe que o cache de buffer DEFAULT foi aumentado, não diminuído como no exemplo anterior. Nenhuma memória foi 'roubada' do cache de buffer para que o desempenho não sofresse com a mudança dinâmica de recursos. Um possível problema com a configuração de streams_pool_size como 0 pode ser a degradação do desempenho no momento em que o conjunto de fluxos é alocado porque o cache de buffer sofreu uma redução ao mesmo tempo em que o conjunto de fluxos estava crescendo. Isso pode ser especialmente perceptível em sistemas onde a carga do usuário é bastante pesada para começar.
Como mencionado anteriormente, o GoldenGate também usa o pool de fluxos e, devido à intensa atividade de confirmação no momento em que um processo de extração é iniciado, pode apresentar uma degradação possivelmente alarmante no serviço que dura até que o processo de extração termine suas atividades de inicialização. [Outros processos gerados pelo GoldenGate contribuem para a lentidão, como uma sincronização de arquivo de log global para liberar dados confirmados para os logs de redo.] Um sistema sofreu tanto quando um processo de extração foi iniciado que os logins do sistema operacional não puderam ser concluídos no tempo alocado. tempo, fazendo com que o software de monitoramento de terceiros relate que os bancos de dados em execução nesse servidor não estavam mais disponíveis. Definir streams_pool_size para um valor diferente de zero contribuiu muito para melhorar o desempenho geral quando os processos de extração foram iniciados.
O conhecimento comum pode ser uma faca de dois gumes; para cada caso em que o conhecimento comum é verdadeiro, pode haver um ou mais casos em que não. A única solução real é testar essa “sabedoria” para verificar sua precisão. É muito melhor afetar um sistema de teste, desenvolvimento ou “sandbox” com tais investigações do que tomar tal “conhecimento” como “evangelho” apenas para descobrir que as suposições em que essa “sabedoria” se baseou estavam erradas. Saber é melhor do que adivinhar; um pouco de tempo gasto com uma investigação pode trazer enormes benefícios na hora de implementar um novo processo envolvendo a Oracle.
# # #
Veja artigos de David Fitzjarrell
