Lad ikke Streams Pool narre dig

Nogle gange er konventionel visdom ikke så konventionel eller almindelig. Som et case-in-point kan DBA'er tro, at STREAMS-puljen udelukkende er forbeholdt streams-processer. Det er ikke tilfældet, da andre Oracle-værktøjer, såsom Data Pump og GoldenGate, bruger denne pulje. Selvfølgelig vil valg af dynamisk styring automatisk allokere den nødvendige hukommelse, når der stilles et krav, men denne hukommelse skal komme fra et sted. Oracle vil 'stjæle', hvad det har brug for fra buffercachen, og det vil ikke blive erstattet med det samme. Lad os se på et eksempel, der beviser dette, ved hjælp af Data Pump.

'Offret' vil være en Oracle 12.1.0.2-database konfigureret med streams_pool_size sat til 0 (da Streams ikke er konfigureret, forventes det, at puljen ikke vil blive brugt) og Automatisk Shared Memory Management konfigureret (parametrene sga_target og sga_max_size er indstillet til værdier, der ikke er nul):

SQL> --SQL> -- Streams-puljen er IKKE kun forSQL> -- StreamsSQL> --SQL> -- Datapumpe og GoldenGate bruger beggeSQL> -- itSQL> --SQL> -- Angiver ikke en størrelse for streamsSQL> -- pool kan forårsage problemer, når det erSQL> -- først brugtSQL> --SQL> --SQL> -- Ser på databaseparametreneSQL> -- tjek sga-parametreneSQL> -- for størrelserSQL> --SQL> vis parameter 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

Ved at kontrollere V$SGA_DYNAMIC_COMPONENTS-visningen for komponenter med strømstørrelser, der ikke er nul, returneres følgende resultater:

SQL> SQL> kolonne komponent format a29SQL> sæt linjestørrelse 300 antal bredde 12SQL> SQL> vælg komponent, aktuel_størrelse, min_størrelse, maks_størrelse, bruger_specificeret_størrelse bruger_spec_sz, 2 oper_antal, sidste_oper_type, sidste_operator_tid, sidste_operator_mod.> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE-------------------------------------- ------------ ------------ ------------ ---------- -- ------------ ---------- ---------- ------------delt pool 176160768 146800640 176160768 0 6 VÆKST UDSETT 15-OKT-19 4194304stor pool 8388608 8388608 125829120 0 1 SHRINK UDSKUDET 15-OKT-19 4194304java pool 4194304 4194304 049 049 049 049 4194304DEFAULT buffer cache 411041792 301989888 419430400 0 8 SHRINK DEFERRED 15-OCT-19 4194304Delt IO Pool 20971520 0 20971520 0 20097151200 20097151520 GR3DI 1520 GR31200 209711520 0 209711520 4OC 

 Bekræftelse af, at streams_pool_size er indstillet til 0:
 
SQL> SQL> --SQL> -- Bekræft at streams-puljen er sat tilSQL> -- 0SQL> --SQL> vis parameter streamsNAME TYPE VALUE---------------- -------------------- ------------------ ------------------ -----------streams_pool_size stort heltal 0SQL> 
 

 En datapumpeeksport udføres, og bagefter kontrolleres de dynamiske hukommelseskomponenter for størrelse:
 
SQL> SQL> --SQL> -- Kør en Data Pump eksport taskSQL> -- og se, hvad der sker med streamsSQL> -- pool størrelseSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> kolonnen Komponentformat A29SQL> SET LINESIZE 300 NUMWIDTH 12SQL> SQL> SELECT COMPONENT, CURRENT_SIZE OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE---------------------------------------- ------------ ---- ------------ ------------ ------------ ------ ------- ---------- ---------- ------------delt pulje 197132288 146800640 197132288 0 11 VOKST STRAKS 15-OKT- 19 4194304stor pool 8388608 8388608 125829120 0 1 SHRINK UTSAT 15-oktober-19 4194304Java Pool 4194304 4194304 4194304 0 0 Statisk 4194304Streams Pool 8388608 0 8388608 0 2 Grow øjeblikkelig 15-oktober-19430430130130130194044404404440444044404444444444044024404224404222422242222142222142222422214222210210 UDVIK STRAKS 15-OCT-19 41943046 udvalgte rækker.SQL> 
 

 Bemærk, at STANDARD buffercache-størrelsen blev reduceret til 381681664 fra en indledende indstilling på 411041792, delvist for at hjælpe med at 'finansiere' Streams-puljen. Ved at teste ideen er streams_pool_size sat til 8M (værdien som Oracle indstillede den til dynamisk), og for at gøre testene så lige som muligt, lukkes databasen ned og startes:
 
SQL> SQL> --SQL> -- Indstil streams_pool_size til den nuværendeSQL> -- valueSQL> --SQL> -- Luk og start databasenSQL> --SQL> alter system set streams_pool_size=8M scope=spfile; System ændret.sql> sql> nedlukning øjeblikkeligt lukket. før> 

 De dynamiske hukommelsesparametre kontrolleret for startværdier:
 
SQL> SQL> --SQL> -- Tjek dynamisk størrelse af SGA-komponenterSQL> --SQL> kolonne komponentformat a29SQL> sæt linjestørrelse 300 numwidth 12SQL> SQL> vælg komponent, aktuel_størrelse, min_størrelse, max_størrelse, bruger_specificeret_størrelse bruger_specifik_størrelse oper_count, last_oper_type, last_oper_mode, last_oper_time, granule_size 3 fra v$sga_dynamic_components 4, hvor current_size> 0;COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_NUAST_OZE---------GRA TYP LAST_OZE----------GRA LAST_OPER_OZE--------- ---------- ------------ ------------ ------------ ----- ------- ------------ -------------------- ---------- ---------- ------------ Delt pool 155189248 146800640 155189248 0 2 vokser øjeblikkelig 15-oktober-19 4194304LARGE POOL 125829120 125829120 125829120 0 0 Statiske 4194304JAVA POOL 4194304 4194304 419430 4 0 0 Statiske 4194304Streams Pool 8388608 8388608 8388608 8388608 0 Statiske 4194304Default Buffer Cache 327155712 327155712 335544320 0 2 Krympe umiddelbar 15-Oct-19 41943304Sql> SQL>-SK> Fjernfil> Fjern-Fjernfilen> Fjern den forrige f.eks. /rm /u01/app/oracle/admin/orcl/dpdump/scott.*
 

 Kør Data Pump-jobbet igen med de justerede hukommelsespuljeindstillinger:
 
SQL> SQL> --SQL> -- Kør en Data Pump eksport taskSQL> -- og se, hvad der sker med streamsSQL> -- pool størrelseSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> kolonnen Komponentformat A29SQL> SET LINESIZE 300 NUMWIDTH 12SQL> SQL> SELECT COMPONENT, CURRENT_SIZE OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE---------------------------------------- ------------ ---- ------------ ------------ ------------ ------ ------- ---------- ---------- ------------delt pulje 197132288 146800640 197132288 0 12 VOKST STRAKS 15-OKT- 19 4194304stor pool 8388608 8388608 125829120 0 1 SHRINK UTSAT 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 rækker valgt.SQL> 
 

 Bemærk, at DEFAULT buffercachen blev øget, ikke reduceret som i det foregående eksempel. Ingen hukommelse blev 'stjålet' fra buffercachen, så ydeevnen led ikke af den dynamiske skift af ressourcer. Et muligt problem med at indstille streams_pool_size til 0 kan være ydeevneforringelse i det øjeblik, streams-puljen tildeles, fordi buffercachen undergik en shrink på samme tid, som streams-puljen voksede. Dette kan især være mærkbart i systemer, hvor brugerbelastningen er ret stor til at begynde med.
 

 Som tidligere nævnt bruger GoldenGate også streams-puljen og kan på grund af den tunge commit-aktivitet på det tidspunkt, hvor en ekstraktionsproces starter, udvise en muligvis alarmerende forringelse af tjenesten, der varer indtil udtrækningsprocessen har afsluttet sine opstartsaktiviteter. [Andre processer skabt af GoldenGate bidrager til afmatningen, såsom en global logfilsynkronisering for at tømme forpligtede data til gentag-logfilerne.] Et system har lidt så hårdt, da en udtræksproces blev startet, at operativsystemets logins ikke var i stand til at fuldføre i de tildelte tid, hvilket får tredjeparts overvågningssoftware til at rapportere, at de databaser, der kører på den server, ikke længere var tilgængelige. Indstilling af streams_pool_size til en værdi, der ikke var nul, bidrog i høj grad til at forbedre den overordnede ydeevne, da udtræksprocesser blev startet.
 

 Almindelig viden kan være et tveægget sværd; for hvert tilfælde, hvor almindelig viden holder stik, kan der være et eller flere tilfælde, hvor det ikke gør det. Den eneste rigtige løsning er at teste sådan 'visdom' for at verificere dens nøjagtighed. Det er langt bedre at påvirke et test-, udviklings- eller 'sandbox'-system med sådanne undersøgelser i stedet for at tage sådan 'viden' som 'evangelium' kun for at opdage, at de antagelser, som denne 'visdom' var baseret på, var fejlagtige. At vide er bedre end at gætte; lidt tid brugt på en undersøgelse kan høste store fordele, når det bliver tid til at implementere en ny proces, der involverer Oracle.
 
# # #
 

 Se artikler af David Fitzjarrell