A volte la saggezza convenzionale non è così convenzionale o comune. Ad esempio, i DBA potrebbero ritenere che il pool STREAMS sia riservato esclusivamente ai processi di stream. Questo non è il caso in quanto altre utilità Oracle, come Data Pump e GoldenGate, utilizzano quel pool. Ovviamente la scelta di utilizzare la gestione dinamica allocherà automaticamente la memoria richiesta quando viene effettuata una richiesta, tuttavia quella memoria deve provenire da qualche parte. Oracle "ruberà" ciò di cui ha bisogno dalla cache del buffer e non verrà sostituito immediatamente. Diamo un'occhiata a un esempio che lo dimostra, utilizzando Data Pump.
La "vittima" sarà un database Oracle 12.1.0.2 configurato con streams_pool_size impostato su 0 (poiché Streams non è configurato, l'aspettativa è che il pool non verrà utilizzato) e la gestione automatica della memoria condivisa configurata (i parametri sga_target e sga_max_size sono impostato su valori diversi da zero):
SQL> -- SQL> -- The streams pool is NOT just for SQL> -- Streams SQL> -- SQL> -- Data pump and GoldenGate both use SQL> -- it SQL> -- SQL> -- Not setting a size for the streams SQL> -- pool can cause problems when it is SQL> -- first used SQL> -- SQL> -- SQL> -- Looking at the database parameters SQL> -- check the sga parameters SQL> -- for sizing SQL> -- SQL> show parameter sga NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ lock_sga boolean FALSE pre_page_sga boolean TRUE sga_max_size big integer 600M sga_target big integer 600M unified_audit_sga_queue_size integer 1048576
Controllando la vista V$SGA_DYNAMIC_COMPONENTS per i componenti con dimensioni di corrente diverse da zero vengono restituiti i seguenti risultati:
SQL> SQL> column component format a29 SQL> set linesize 300 numwidth 12 SQL> SQL> select 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 from v$sga_dynamic_components 4 where current_size > 0; COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE ----------------------------- ------------ ------------ ------------ ------------ ------------ ------------- --------- --------- ------------ shared pool 176160768 146800640 176160768 0 6 GROW DEFERRED 15-OCT-19 4194304 large pool 8388608 8388608 125829120 0 1 SHRINK DEFERRED 15-OCT-19 4194304 java pool 4194304 4194304 4194304 0 0 STATIC 4194304 DEFAULT buffer cache 411041792 301989888 419430400 0 8 SHRINK DEFERRED 15-OCT-19 4194304 Shared IO Pool 20971520 0 20971520 0 1 GROW IMMEDIATE 15-OCT-19 4194304 SQL>
Verifica che streams_pool_size sia impostato su 0:
SQL> SQL> -- SQL> -- Verify the streams pool is set to SQL> -- 0 SQL> -- SQL> show parameter streams NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ streams_pool_size big integer 0 SQL>
Viene eseguita un'esportazione Data Pump e, successivamente, viene verificata la dimensione dei componenti della memoria dinamica:
SQL> SQL> -- SQL> -- Run an Data Pump export task SQL> -- and see what happens to the streams SQL> -- pool size SQL> -- SQL> !expdp parfile=expdp_test.par SQL> SQL> column component format a29 SQL> set linesize 300 numwidth 12 SQL> SQL> select 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 from v$sga_dynamic_components 4 where current_size > 0; COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE ----------------------------- ------------ ------------ ------------ ------------ ------------ ------------- --------- --------- ------------ shared pool 197132288 146800640 197132288 0 11 GROW IMMEDIATE 15-OCT-19 4194304 large pool 8388608 8388608 125829120 0 1 SHRINK DEFERRED 15-OCT-19 4194304 java pool 4194304 4194304 4194304 0 0 STATIC 4194304 streams pool 8388608 0 8388608 0 2 GROW IMMEDIATE 15-OCT-19 4194304 DEFAULT buffer cache 381681664 301989888 419430400 0 15 SHRINK IMMEDIATE 15-OCT-19 4194304 Shared IO Pool 20971520 0 20971520 0 1 GROW IMMEDIATE 15-OCT-19 4194304 6 rows selected. SQL>
Si noti che la dimensione della cache del buffer DEFAULT è stata ridotta a 381681664 da un'impostazione iniziale di 411041792, in parte per aiutare a "finanziare" il pool di Streams. Testando quell'idea, streams_pool_size è impostato su 8M (il valore Oracle lo ha impostato in modo dinamico) e, per rendere i test il più uguali possibile, il database viene spento e avviato:
SQL> SQL> -- SQL> -- Set the streams_pool_size to the current SQL> -- value SQL> -- SQL> -- Shutdown and startup the database SQL> -- SQL> alter system set streams_pool_size=8M scope=spfile; System altered. SQL> SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 629145600 bytes Fixed Size 2927528 bytes Variable Size 289408088 bytes Database Buffers 331350016 bytes Redo Buffers 5459968 bytes Database mounted. Database opened.
I parametri di memoria dinamica verificati per i valori iniziali:
SQL> SQL> -- SQL> -- Check dynamic sizing of SGA components SQL> -- SQL> column component format a29 SQL> set linesize 300 numwidth 12 SQL> SQL> select 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 from v$sga_dynamic_components 4 where current_size > 0; COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE ----------------------------- ------------ ------------ ------------ ------------ ------------ ------------- --------- --------- ------------ shared pool 155189248 146800640 155189248 0 2 GROW IMMEDIATE 15-OCT-19 4194304 large pool 125829120 125829120 125829120 0 0 STATIC 4194304 java pool 4194304 4194304 4194304 0 0 STATIC 4194304 streams pool 8388608 8388608 8388608 8388608 0 STATIC 4194304 DEFAULT buffer cache 327155712 327155712 335544320 0 2 SHRINK IMMEDIATE 15-OCT-19 4194304 SQL> SQL> -- SQL> -- Remove the previous dump file SQL> -- SQL> !/bin/rm /u01/app/oracle/admin/orcl/dpdump/scott.*
Eseguire nuovamente il lavoro Data Pump con le impostazioni del pool di memoria modificate:
SQL> SQL> -- SQL> -- Run an Data Pump export task SQL> -- and see what happens to the streams SQL> -- pool size SQL> -- SQL> !expdp parfile=expdp_test.par SQL> SQL> column component format a29 SQL> set linesize 300 numwidth 12 SQL> SQL> select 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 from v$sga_dynamic_components 4 where current_size > 0; COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE ----------------------------- ------------ ------------ ------------ ------------ ------------ ------------- --------- --------- ------------ shared pool 197132288 146800640 197132288 0 12 GROW IMMEDIATE 15-OCT-19 4194304 large pool 8388608 8388608 125829120 0 1 SHRINK DEFERRED 15-OCT-19 4194304 java pool 4194304 4194304 4194304 0 0 STATIC 4194304 streams pool 8388608 8388608 8388608 8388608 0 STATIC 4194304 DEFAULT buffer cache 381681664 264241152 381681664 0 14 GROW DEFERRED 15-OCT-19 4194304 Shared IO Pool 20971520 0 20971520 0 1 GROW IMMEDIATE 15-OCT-19 4194304 6 rows selected. SQL>
Si noti che la cache del buffer DEFAULT è stata aumentata, non ridotta come nell'esempio precedente. Nessuna memoria è stata "rubata" dalla cache del buffer, quindi le prestazioni non hanno risentito dello spostamento dinamico delle risorse. Un possibile problema con l'impostazione di streams_pool_size su 0 può essere il degrado delle prestazioni nel momento in cui il pool di flussi viene allocato perché la cache del buffer ha subito una riduzione nello stesso momento in cui il pool di flussi cresceva. Questo può essere particolarmente evidente nei sistemi in cui il carico dell'utente è piuttosto pesante all'inizio.
Come accennato in precedenza, anche GoldenGate utilizza il pool di flussi e, a causa della pesante attività di commit al momento dell'avvio di un processo di estrazione, può mostrare un degrado forse allarmante del servizio che dura fino a quando il processo di estrazione non ha terminato le sue attività di avvio. [Altri processi generati da GoldenGate contribuiscono al rallentamento, come una sincronizzazione globale dei file di registro per scaricare i dati salvati nei registri di ripristino.] Un sistema ha sofferto così gravemente quando è stato avviato un processo di estrazione che gli accessi al sistema operativo non sono stati completati nell'assegnazione tempo, facendo in modo che il software di monitoraggio di terze parti segnali che i database in esecuzione su quel server non erano più disponibili. L'impostazione di streams_pool_size su un valore diverso da zero ha contribuito notevolmente a migliorare le prestazioni complessive quando sono stati avviati i processi di estrazione.
La conoscenza comune può essere un'arma a doppio taglio; per ogni caso in cui la conoscenza comune è vera, potrebbero esserci uno o più casi in cui non lo è. L'unica vera soluzione è testare tale "saggezza" per verificarne l'accuratezza. È molto meglio influenzare un sistema di test, sviluppo o "sandbox" con tali indagini piuttosto che prendere tale "conoscenza" come "vangelo" solo per scoprire che i presupposti su cui si basava quella "saggezza" erano errati. Conoscere è meglio che indovinare; un po' di tempo speso con un'indagine può trarre enormi vantaggi quando arriva il momento di implementare un nuovo processo che coinvolge Oracle.
# # #
Vedi gli articoli di David Fitzjarrell
