Låt inte Streams Pool lura dig

Ibland är konventionell visdom inte så konventionell eller vanlig. Som ett fall i punkt kan DBA:er tro att STREAMS-poolen är reserverad strikt för strömningsprocesser. Det är inte fallet eftersom andra Oracle-verktyg, som Data Pump och GoldenGate, använder den poolen. Naturligtvis kommer att välja att använda dynamisk hantering automatiskt allokera det nödvändiga minnet när ett krav ställs, men det minnet måste komma någonstans ifrån. Oracle kommer att "stjäla" det den behöver från buffertcachen, och det kommer inte att ersättas omedelbart. Låt oss titta på ett exempel som bevisar detta med hjälp av Data Pump.

"Offret" kommer att vara en Oracle 12.1.0.2-databas konfigurerad med streams_pool_size inställd på 0 (eftersom Streams inte är konfigurerad förväntas poolen inte användas) och automatisk delad minneshantering konfigurerad (parametrarna sga_target och sga_max_size är inställd på värden som inte är noll):

SQL> --SQL> -- Strömpoolen är INTE bara förSQL> -- StreamsSQL> --SQL> -- Datapumpen och GoldenGate använder bådaSQL> -- itSQL> --SQL> -- Anger inte en storlek för streamsSQL> -- pool kan orsaka problem när den ärSQL> -- först användSQL> --SQL> --SQL> -- Tittar på databasparametrarnaSQL> -- kontrollera sga parametrarnaSQL> -- för storlekSQL> --SQL> visa parametern sgaNAME TYPE VALUE ---------------------------------------------------- --- ------------------------------lock_sga boolean FALSEpre_page_sga boolean TRUEsga_max_size stort heltal 600Msga_target stort heltal 600Munified_audit_sga_queue_size heltal 1048576

När du kontrollerar V$SGA_DYNAMIC_COMPONENTS-vyn för komponenter med strömstorlekar som inte är noll returneras följande resultat:

SQL> SQL> kolumn komponentformat a29SQL> set radstorlek 300 numwidth 12SQL> SQL> välj komponent, aktuell_storlek, min_storlek, max_storlek, användarspecifik_storlek user_spec_sz, 2 oper_count, last_oper_type, last_oper_size, last_oper_sizes, granule_opers_com> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE-------------------------------------- ------------ ------------ ------------ ---------- -- ------------ ---------- ---------- ------------delad pool 176160768 146800640 176160768 0 6 VÄXNING UPPSKJUTAD 15-OKT-19 4194304stor pool 8388608 8388608 125829120 0 1 SHRINK UPPskjuten 15-OKT-19 4194304java pool 4194304 3 ST 04 04 04 04 0 4194304DEFAULT buffertcache 411041792 301989888 419430400 0 8 SHRINK DEFERRED 15-OKT-19 4194304Delad IO Pool 20971520 0 20971520 0 2097151520 0 209711520 4OC 40971151520 GR3120 4OC 20971151520 GR3DI 1520 15-15-15 

 Verifierar att streams_pool_size är inställd på 0:
 
SQL> SQL> --SQL> -- Verifiera att strömpoolen är inställd påSQL> -- 0SQL> --SQL> visa parametern strömmar NAMN TYP VÄRDE---------------- -------------------- ------------------ ------------------ -----------streams_pool_size stort heltal 0SQL> 
 

 En datapumpsexport utförs och efteråt kontrolleras de dynamiska minneskomponenterna för storlek:
 
SQL> SQL> --SQL> -- Kör en Data Pump export taskSQL> -- och se vad som händer med streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> kolumnen component format a29SQL> set linesize 300 numwidth 12SQL> 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---------------------------------------- ------------ ---- ------------ ------------ ------------ ------ ------- ---------- ---------- ------------delad pool 197132288 146800640 197132288 0 11 VÄX OMEDELBART 15-OKT- 19 4194304stor pool 8388608 8388608 125829120 0 1 SHRINK FÖRSKJUDAD 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 VÄX OMEDELBART 15-OKT-19 41943046 rader valda.SQL> 
 

 Lägg märke till att DEFAULT buffertcache-storleken reducerades till 381681664 från en initial inställning på 411041792, delvis för att hjälpa till att "finansiera" Streams-poolen. Testar den idén, streams_pool_size är inställd på 8M (värdet som Oracle satte den till dynamiskt) och för att göra testerna så lika som möjligt stängs databasen av och startas:
 
SQL> SQL> --SQL> -- Ställ in streams_pool_size till currentSQL> -- valueSQL> --SQL> -- Stäng av och starta databasenSQL> --SQL> ändra systemuppsättning streams_pool_size=8M scope=spfile; System ändrat.sql> sql> avstängning omedelbart stängd. före> 

 De dynamiska minnesparametrarna kontrollerade för startvärden:
 
SQL> SQL> --SQL> -- Kontrollera dynamisk storlek på SGA-komponenterSQL> --SQL> kolumnkomponentformat a29SQL> set radstorlek 300 numwidth 12SQL> SQL> välj komponent, aktuell_storlek, min_storlek, max_storlek, användar_specifik_storlek, användarspecifik_storlek oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 från v$sga_dynamic_components 4 där current_size> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_NUAST_OZE--------- TYP LAST_OZE---------GRA TYP LAST_OZE---------GRA ---------- ------------ ------------ ------------ ----- ------- ------------ -------------------- ---------- ---------- ------------delad pool 155189248 146800640 155189248 0 2 OMGÅNG 15-OKT-19 4194304stor pool 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 125829120 1258029120 1258020120 408029120 40 4 0 4 9 4 0 4 0 4 0 4 0 4 0 4 0 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.*
 

 Kör Data Pump-jobbet igen med de justerade minnespoolinställningarna:
 
SQL> SQL> --SQL> -- Kör en Data Pump export taskSQL> -- och se vad som händer med streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> kolumnen component format a29SQL> set linesize 300 numwidth 12SQL> 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---------------------------------------- ------------ ---- ------------ ------------ ------------ ------ ------- ---------- ---------- ------------delad pool 197132288 146800640 197132288 0 12 VÄX OMEDELBART 15-OKT- 19 4194304stor pool 8388608 8388608 125829120 0 1 SHRINK FÖRSKJUDAD 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 rader valda.SQL> 
 

 Lägg märke till att DEFAULT buffertcachen ökades, inte minskades som i föregående exempel. Inget minne "stals" från buffertcachen så prestandan led inte av den dynamiska förskjutningen av resurser. Ett möjligt problem med att sätta streams_pool_size till 0 kan vara prestandaförsämring i det ögonblick som streams poolen allokeras eftersom buffertcachen genomgick en krympning samtidigt som streams poolen växte. Detta kan vara särskilt märkbart i system där användarbelastningen är ganska stor till att börja med.
 

 Som tidigare nämnts använder GoldenGate också strömpoolen och kan, på grund av den tunga commit-aktiviteten vid den tidpunkt då en extraktprocess startar, uppvisa en möjligen alarmerande försämring av tjänsten som varar tills utvinningsprocessen har avslutat sin startaktiviteter. [Andra processer som skapats av GoldenGate bidrar till avmattningen, såsom en global loggfilsynkronisering för att tömma tilldelade data till redo-loggarna.] Ett system har drabbats så hårt när en extraheringsprocess startades att operativsystemsinloggningar inte kunde slutföras i de tilldelade tid, vilket får tredje parts övervakningsprogram att rapportera att databaserna som körs på den servern inte längre var tillgängliga. Att ställa in streams_pool_size till ett värde som inte var noll bidrog i hög grad till att förbättra den övergripande prestandan när extraheringsprocesser startades.
 

 Allmän kunskap kan vara ett tveeggat svärd; för varje fall där allmän kunskap gäller kan det finnas ett eller flera fall där det inte gör det. Den enda verkliga lösningen är att testa sådan "visdom" för att verifiera dess riktighet. Det är mycket bättre att påverka ett test-, utvecklings- eller "sandlåde"-system med sådana undersökningar snarare än att ta sådan "kunskap" som "evangelium" bara för att upptäcka antagandena som den "visdom" baserades på var felaktiga. Att veta är bättre än att gissa; lite tid som spenderas med en utredning kan skörda enorma fördelar när det är dags att implementera en ny process som involverar Oracle.
 
# # #
 

 Se artiklar av David Fitzjarrell