Manchmal ist konventionelle Weisheit nicht so konventionell oder üblich. Beispielsweise könnten DBAs glauben, dass der STREAMS-Pool ausschließlich für Streams-Prozesse reserviert ist. Dies ist nicht der Fall, da andere Oracle-Dienstprogramme wie Data Pump und GoldenGate diesen Pool verwenden. Wenn Sie sich für die dynamische Verwaltung entscheiden, wird der erforderliche Speicher natürlich automatisch zugewiesen, wenn eine Anforderung gestellt wird, aber dieser Speicher muss irgendwo herkommen. Oracle wird das, was es braucht, aus dem Puffer-Cache „stehlen“, und es wird nicht sofort ersetzt. Sehen wir uns ein Beispiel mit Data Pump an, das dies beweist.
Das „Opfer“ wird eine Oracle 12.1.0.2-Datenbank sein, die mit streams_pool_size auf 0 konfiguriert ist (da Streams nicht konfiguriert ist, wird erwartet, dass der Pool nicht verwendet wird) und Automatic Shared Memory Management konfiguriert ist (die Parameter sga_target und sga_max_size sind auf Werte ungleich Null gesetzt):
SQL> --SQL> -- Der Streams-Pool ist NICHT nur für SQL> -- StreamsSQL> --SQL> -- Data Pump und GoldenGate verwenden beide SQL> -- itSQL> --SQL> -- Keine Größe festlegen für den streamsSQL> -- Pool kann Probleme verursachen, wenn er SQL> -- first usedSQL> --SQL> --SQL> -- Blick auf die DatenbankparameterSQL> -- überprüfe die sga-ParameterSQL> -- für die GrößenanpassungSQL> --SQL> Parameter anzeigen sgaNAME TYP WERT----------------------------------- -------- --- ------------------------------lock_sga boolean FALSEpre_page_sga boolean TRUEsga_max_size große ganze Zahl 600Msga_target große ganze Zahl 600Munified_audit_sga_queue_size ganze Zahl 1048576
Beim Überprüfen der Ansicht V$SGA_DYNAMIC_COMPONENTS auf Komponenten mit aktuellen Größen ungleich Null werden die folgenden Ergebnisse zurückgegeben:
SQL> SQL> Spaltenkomponentenformat 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---------------------------- -------- ---- ------------ ------------ ------------ ---------- -- ------------- --------- --------- ------------Gemeinschaftspool 176160768 146800640 176160768 0 6 GROW DEFERRED 15-OCT-19 4194304large pool 8388608 8388608 125829120 0 1 SHRINK DEFERRED 15-OCT-19 4194304java pool 4194304 4194304 4194304 0 0 STATIC 4194304DEFAULT Buffer Cache 411041792 301989888 419430400 0 8 SHRINK DEFERRED 15-OCT-19 4194304Shared IO Pool 20971520 0 20971520 0 1 GROW IMMEDIATE 15-OCT-19 419430>4SQL> Prüfen, ob streams_pool_size auf 0 gesetzt ist:SQL> SQL> --SQL> -- Stellen Sie sicher, dass der Streams-Pool auf SQL eingestellt ist> -- 0SQL> --SQL> Parameter anzeigen streamsNAME TYPE VALUE---------------- -------------------- ----------- ------------------- -----------streams_pool_size große ganze Zahl 0SQL>Es wird ein Data Pump Export durchgeführt und anschließend die dynamischen Speicherkomponenten auf Größe geprüft:
SQL> SQL> --SQL> -- Ausführen einer Data Pump-ExportaufgabeSQL> -- und sehen, was mit der Spalte streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> passiert Komponentenformat 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 USER MAX_SIZE OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE----------------------- ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------Gemeinschaftspool 197132288 146800640 197132288 0 11 GROW SOFORT 15. OKT. 19 4194304Großbecken 8388608 8388608 125829120 0 1 SCHRUMPFVERZÖGERT 15-OCT-19 4194304java Pool 4194304 4194304 4194304 0 0 Static 4194304Streams Pool 8388608 0 8388608 0 2 Wachstum sofort 15-OCT-19 4194304Default Puffer. GROW IMMEDIATE 15-OCT-19 41943046 Zeilen ausgewählt.SQL>Beachten Sie, dass die Größe des DEFAULT-Puffercaches von einer anfänglichen Einstellung von 411041792 auf 381681664 reduziert wurde, teilweise um den Streams-Pool zu „finanzieren“. Beim Testen dieser Idee wird die streams_pool_size auf 8M gesetzt (der Wert, auf den Oracle sie dynamisch gesetzt hat) und um die Tests so gleich wie möglich zu gestalten, wird die Datenbank heruntergefahren und gestartet:
SQL> SQL> --SQL> -- setze die streams_pool_size auf die aktuelleSQL> -- valueSQL> --SQL> -- fahre die Datenbank herunter und starte sieSQL> --SQL> alter system set streams_pool_size=8M scope=spfile; System verändert.SQL> SQL> sofort herunterfahrenDatenbank geschlossen.Datenbank getrennt.ORACLE-Instanz heruntergefahren.SQL> startupORACLE-Instanz gestartet.Globaler Systembereich insgesamt 629145600 BytesFeste Größe 2927528 BytesVariable Größe 289408088 BytesDatenbankpuffer 331350016 BytesRedo-Puffer 5459968 BytesDatenbank geöffnet.Die dynamischen Speicherparameter auf Startwerte geprüft:
SQL> SQL> --SQL> -- Dynamische Größenanpassung von SGA-Komponenten prüfenSQL> --SQL> Spaltenkomponentenformat 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-------------------- --------- ------------ ------------ ------------ ----- ------- ------------ ------------- --------- --------- ------------gemeinsamer Pool 155189248 146800640 155189248 0 2 GROW IMMEDIATE 15-OCT-19 4194304großer Pool 125829120 125829120 125829120 0 0 STATIC 4194304Java-Pool 4194304 40.419430 419430 4 0 0 static 4194304 Streams Pool 8388608 8388608 8388608 8388608 0 static 4194304Default-Puffer Cache 327155712 327155712 33554320 0 2 Verkleinern Sie die 15-OCT-ACT9 4194304SQL. /rm /u01/app/oracle/admin/orcl/dpdump/scott.*Führen Sie den Data Pump-Job erneut mit den angepassten Speicherpooleinstellungen aus:
SQL> SQL> --SQL> -- Ausführen einer Data Pump-ExportaufgabeSQL> -- und sehen, was mit der Spalte streamsSQL> -- pool sizeSQL> --SQL> !expdp parfile=expdp_test.parSQL> SQL> passiert Komponentenformat 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 USER MAX_SIZE OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE----------------------- ------------ ---- -------- ------------ ------------ ------------ ------ ------- --------- --------- ------------gemeinsamer Pool 197132288 146800640 197132288 0 12 GROW SOFORT 15-OCT- 19 4194304Großbecken 8388608 8388608 125829120 0 1 SCHRUMPFVERZÖGERT 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 Zeilen ausgewählt.SQL>Beachten Sie, dass der DEFAULT-Puffercache erhöht und nicht wie im vorherigen Beispiel verringert wurde. Es wurde kein Speicher aus dem Puffer-Cache „gestohlen“, sodass die Leistung nicht unter der dynamischen Verschiebung von Ressourcen litt. Ein mögliches Problem beim Festlegen von streams_pool_size auf 0 kann eine Leistungsminderung in dem Moment sein, in dem der Streams-Pool zugewiesen wird, da der Puffer-Cache gleichzeitig mit dem Wachsen des Streams-Pools verkleinert wurde. Dies kann sich besonders in Systemen bemerkbar machen, in denen die Benutzerlast anfangs ziemlich hoch ist.
Wie bereits erwähnt, verwendet GoldenGate auch den Streams-Pool und kann aufgrund der starken Commit-Aktivität zu Beginn eines Extraktionsprozesses möglicherweise eine alarmierende Verschlechterung des Dienstes aufweisen, die andauert, bis der Extraktionsprozess seine Startaktivitäten abgeschlossen hat. [Andere von GoldenGate hervorgebrachte Prozesse tragen zur Verlangsamung bei, wie z. B. eine globale Protokolldateisynchronisierung, um festgeschriebene Daten in die Redo-Protokolle zu spülen.] Ein System hat so stark gelitten, als ein Extraktionsprozess gestartet wurde, dass Betriebssystemanmeldungen nicht in den zugewiesenen abgeschlossen werden konnten Zeit, was dazu führte, dass Überwachungssoftware von Drittanbietern meldete, dass die auf diesem Server ausgeführten Datenbanken nicht mehr verfügbar waren. Das Festlegen von streams_pool_size auf einen Wert ungleich Null trug wesentlich zur Verbesserung der Gesamtleistung bei, wenn Extraktionsprozesse gestartet wurden.
Allgemeinwissen kann ein zweischneidiges Schwert sein; Für jeden Fall, in dem Allgemeinwissen zutrifft, kann es einen oder mehrere Fälle geben, in denen dies nicht der Fall ist. Die einzige wirkliche Lösung besteht darin, diese „Weisheit“ zu testen, um ihre Genauigkeit zu überprüfen. Es ist viel besser, ein Test-, Entwicklungs- oder „Sandbox“-System mit solchen Untersuchungen zu beeinflussen, als solches „Wissen“ als „Evangelium“ zu nehmen, nur um herauszufinden, dass die Annahmen, auf denen diese „Weisheit“ beruhte, falsch waren. Wissen ist besser als raten; Ein wenig Zeit, die mit einer Untersuchung verbracht wird, kann enorme Vorteile bringen, wenn es darum geht, einen neuen Prozess zu implementieren, an dem Oracle beteiligt ist.
# # #
Siehe Artikel von David Fitzjarrell
