Někdy konvenční moudrost není tak konvenční nebo běžná. Jako příklad se správci databází mohou domnívat, že fond STREAMS je vyhrazen výhradně pro procesy proudů. Není tomu tak, protože tento fond používají jiné nástroje Oracle, jako je Data Pump a GoldenGate. Samozřejmě, že se rozhodnete pro použití dynamické správy automaticky alokuje požadovanou paměť, když vznikne požadavek, nicméně tato paměť musí odněkud pocházet. Oracle z mezipaměti „ukradne“ to, co potřebuje, a nebude to okamžitě nahrazeno. Podívejme se na příklad, který to dokazuje, pomocí datové pumpy.
„Obětí“ bude databáze Oracle 12.1.0.2 nakonfigurovaná s streams_pool_size nastavenou na 0 (protože Streams není nakonfigurován, očekává se, že fond nebude použit) a nakonfigurována automatická správa sdílené paměti (parametry sga_target a sga_max_size jsou nastavit na nenulové hodnoty):
SQL> --SQL> -- Fond proudů NENÍ pouze pro SQL> -- StreamsSQL> --SQL> -- Datová pumpa a GoldenGate obě používají SQL> -- itSQL> --SQL> -- Nenastavení velikosti pro streamsSQL> -- bazén může způsobit problémy, když je to SQL> -- poprvé použit SQL> --SQL> --SQL> -- Podíváme se na parametry databázeSQL> -- zkontrolujte parametry sgaSQL> -- pro velikost SQL> --SQL> zobrazit parametr sgaNAME TYP HODNOTA----------------------------------- -------- --- ------------------------------lock_sga boolean FALSEpre_page_sga boolean TRUEsga_max_size velké celé číslo 600Msga_target velké celé číslo 600Munified_audit_sga_queue76Při kontrole pohledu V$SGA_DYNAMIC_COMPONENTS pro komponenty s nenulovou aktuální velikostí se vrátí následující výsledky:
SQL> formát komponenty sloupce a29SQL> nastavit velikost řádků 300 numwidth 12SQL> SQL> vybrat komponentu, aktuální_velikost, minimální_velikost, max_velikost, uživatelská_určená_velikost user_spec_sz, 2 oper_count, last_oper_type, last_oper_mode, last_oper_time, 4 z granule_component_size> 0; AKTUÁLNÍ VELIKOST KOMPONENTY MIN_SIZE MAX_SIZE USER_SPEC_SZ OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER VELIKOST GRANULE------------------------------ -------- ---- ------------ ------------ ------------ ---------- -- ------------- --------- --------- ------------sdílený fond 176160768 146800640 176160768 0 6 ODLOŽENÝ RŮST 15. ŘÍJNA-19 4194304velký bazén 8388608 8388608 125829120 0 1 ODLOŽENÍ SHRINK 15. ŘÍJNA-19 4194304 bazén java 41944304 41944304 41944304 41944304 4 4194304VÝCHOZÍ mezipaměť mezipaměti 411041792 301989888 419430400 0 8 SHRINK DEFERRED 15-OCT-19 4194304Shared IO Pool 20971520 0 20971520 0 209715200SQL 209715200 209715200Ověření, zda je streams_pool_size nastavena na 0:
SQL> SQL> --SQL> -- Ověřte, zda je fond streamů nastaven na SQL> -- 0SQL> --SQL> zobrazit parametr streamsNAME TYPE VALUE----------------- -------------------- ----------- ------------------- -----------streams_pool_size velké celé číslo 0SQL>Provede se export datové pumpy a poté se zkontroluje velikost komponent dynamické paměti:
SQL> SQL> --SQL> -- Spusťte úlohu SQL pro export datové pumpy> -- a podívejte se, co se stane se streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> sloupec SQL> formát komponenty a29SQL> nastavit velikost řádku 300 numwidth 12SQL> SQL> vybrat komponentu, aktuální_velikost, 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 current_componentsgaON_USER_0PEC; OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER VELIKOST GRANULE----------------------------- ----------- ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------sdílený bazén 197132288 146800640 197132288 0 11 RŮST OKAMŽITĚ 15. ŘÍJNA- 19 4194304velký bazén 8388608 8388608 125829120 0 1 ODLOŽ. 15-říjen-19 4194304Java Pool 4194304 4194304 4194304 0 0 Static 4194304Streams Pool 83888608 0 8388608 0 2 Okamžitý 15-OCT-19 41943040404040404040404040404040404040404040404040404040404040404040404040404040404040404040 NOTORUČENÍ 419430400 INDIALITY 15 INTIALITY RŮST OKAMŽITĚ 15. říjen 19 41943046 vybraných řádků.SQL>Všimněte si, že velikost mezipaměti DEFAULT byla snížena na 381681664 z původního nastavení 411041792, částečně proto, aby pomohla „financovat“ fond streamů. Při testování tohoto nápadu je streams_pool_size nastavena na 8M (hodnota, na kterou ji Oracle dynamicky nastavil) a aby byly testy co nejrovnější, databáze se vypne a spustí:
SQL> SQL> --SQL> -- Nastavte streams_pool_size na aktuální SQL> -- valueSQL> --SQL> -- Vypnutí a spuštění databázeSQL> --SQL> alter system set streams_pool_size=8M scope=spfile; System altered.SQL> SQL> okamžité vypnutíDatabáze uzavřena.Databáze odpojena.Instance ORACLE vypnuta.SQL> startup instance ORACLE spuštěna.Celková globální oblast systému 629145600 bajtůPevná velikost 2927528 bajtůVelikost proměnné 289408088 bajtůDatabáze 3504Retabáze připojeno 3504Reatabase 396 otevřeno. před>Parametry dynamické paměti zkontrolované na počáteční hodnoty:
SQL> SQL> --SQL> -- Kontrola dynamické velikosti komponent SGASQL> --SQL> formát komponenty sloupce a29SQL> nastavit velikost řádku 300 numwidth 12SQL> SQL> vybrat komponentu, aktuální_velikost, min_size, max_size, uživatelská_specifikace_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-------------------- --------- ------------ ------------ ------------ ----- ------- ------------ ------------- --------- --------- ------------sdílený bazén 155189248 146800640 155189248 0 2 RŮST OKAMŽITĚ 15. ŘÍJNA-19 4194304velký bazén 125829120 125829120 4409 440 409 4040 4040 40 40 40 40 90 40 4012512981294 4 0 0 Statický 4194304Streams Pool 8388608 8388608 8388608 8388608 0 Static 4194304Default Buffer Cache 327155712 327155712 335544320 0 /rm /u01/app/oracle/admin/orcl/dpdump/scott.*Spusťte znovu úlohu Data Pump s upraveným nastavením paměťového fondu:
SQL> SQL> --SQL> -- Spusťte úlohu SQL pro export datové pumpy> -- a podívejte se, co se stane se streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> sloupec SQL> formát komponenty a29SQL> nastavit velikost řádku 300 numwidth 12SQL> SQL> vybrat komponentu, aktuální_velikost, 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 current_componentsgaON_USER_0PEC; OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER VELIKOST GRANULE----------------------------- ----------- ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------sdílený bazén 197132288 146800640 197132288 0 12 RŮST OKAMŽITĚ 15. ŘÍJNA- 19 4194304velký bazén 8388608 8388608 125829120 0 1 ODLOŽ. 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 vybraných řádků.SQL>Všimněte si, že mezipaměť DEFAULT byla zvýšena, nikoli snížena jako v předchozím příkladu. Z mezipaměti nebyla „ukradena“ žádná paměť, takže výkon neutrpěl dynamickým přesouváním zdrojů. Možným problémem s nastavením streams_pool_size na 0 může být snížení výkonu v okamžiku přidělení fondu proudů, protože mezipaměť vyrovnávací paměti prošla zmenšením ve stejnou dobu, kdy se fond proudů zvětšoval. To může být zvláště patrné v systémech, kde je uživatelská zátěž zpočátku poměrně velká.
Jak již bylo zmíněno dříve, GoldenGate také používá fond streamů a kvůli těžké aktivitě potvrzení v době, kdy se spouští proces extrahování, může vykazovat možná alarmující degradaci služby, která trvá, dokud proces extrahování nedokončí své spouštěcí aktivity. [Ke zpomalení přispívají i další procesy vytvořené GoldenGate, jako je synchronizace globálního souboru protokolu k vyprázdnění odevzdaných dat do opakovaných protokolů.] Jeden systém utrpěl tak těžce, když byl spuštěn proces extrahování, že přihlášení operačního systému nebylo možné dokončit v přiděleném To způsobí, že monitorovací software třetí strany hlásí, že databáze běžící na tomto serveru již nejsou dostupné. Nastavení streams_pool_size na nenulovou hodnotu výrazně přispělo ke zlepšení celkového výkonu při zahájení procesů extrahování.
Obecné znalosti mohou být dvousečným mečem; pro každý případ, kdy obecné znalosti platí, může existovat jeden nebo více případů, kdy tomu tak není. Jediným skutečným řešením je otestovat takovou „moudrost“ a ověřit její přesnost. Je mnohem lepší ovlivnit test, vývoj nebo systém „sandbox“ s takovými vyšetřováními, než brát takové „znalosti“ jako „evangelium“, jen abychom objevili předpoklady, na kterých byla tato „moudrost“ založena, byly chybné. Vědět je lepší než hádat; trocha času stráveného vyšetřováním může mít obrovské výhody, když přijde čas na implementaci nového procesu zahrnujícího Oracle.
# # #
Zobrazit články od Davida Fitzjarrella