Untersuchung der intrinsischen SCN-Wachstumsrate

Erstellt von am in Articles

Veröffentlicht am: 10 Juli 2018 Autor: Bastiaan Bak Kategorie: IT-Entwicklung und -Betrieb

Vor einiger Zeit hatten wir eine Warnung vor dem intrinsischen Wachstum des SCN (System Change Number) in unserer Oracle 12.2-Datenbankwarnungsdatei. Diese Situation trat innerhalb weniger Wochen mehrmals auf.

“ Warnung: Die intrinsische SCN-Wachstumsrate war in den letzten 60 Minuten konstant
höher als der Systemstandard 16384 pro Sekunde.
Aktuelle SCN intrinsische Wachstumsrate ist 25867 pro Sek., zas 200fffff!
Der aktuelle SCN-Wert ist 46747726691, der SCN-Kompatibilitätswert ist 1″

Meine erste Reaktion war, dass SCNs mit Commits zusammenhängen, sodass entweder die Belastung der Datenbank sehr hoch war oder die Anwendungslogik geändert werden sollte. Eine andere Möglichkeit war, dass nach jedem Update ein Commit durchgeführt wurde, anstatt Batch-Commits zu verwenden.

Es stellte sich als etwas komplizierter heraus, als ich erwartet hatte. Wo suchen Sie, wenn Sie die Beziehung zwischen SCNs und Commits finden möchten? Und wie ernst ist diese Warnung überhaupt? In diesem Blog geht es um die verschiedenen Möglichkeiten, wie ich dieses Problem untersucht und die möglichen Auswirkungen identifiziert habe.

Oracle Support notes

Die erste Stelle, an der Sie nach Informationen zu Warnungen in der Warndatei suchen, ist die Oracle Support-Website. Ich habe mehrere verwandte Notizen gefunden:

  • ORA-19706 und zugehörige Warnprotokollmeldungen (Dokument-ID 1393360.1)
    Dieser Hinweis legt nahe, dass die eigentliche Nachricht spezifisch für die Datenbankversion 12.2 ist, aber in älteren Versionen haben wir möglicherweise ähnliche Warnungen wie „Warnung: Der SCN-Headroom für diese Datenbank beträgt nur NN Tage!“
    Wenn Sie auf eine Warnungsprotokollmeldung wie einen dieser Einträge stoßen, sollten Sie die Anweisungen in ID 1388639.1 befolgen und eine Serviceanforderung beim Oracle Support protokollieren.
    Evidence to collect when reporting „high SCN rate“ issues to Oracle Support (Doc ID 1388639.1)
  • Dieser Hinweis enthält Informationen darüber, welche Informationen Sie bei der Protokollierung einer Serviceanforderung bereitstellen sollten.
  • System Change Number (SCN), Headroom, Sicherheits- und Patch-Informationen (Doc ID 1376995.1)
    Dieser Hinweis enthält weitere Informationen zur Verwendung des SCN. Die System Change Number (SCN) ist ein logischer, interner Zeitstempel, der von der Oracle-Datenbank verwendet wird. SCNs ordnen Ereignisse an, die innerhalb der Datenbank auftreten. Die Datenbank verwendet SCNs, um Änderungen abzufragen und zu verfolgen. Wenn eine Transaktion festgeschrieben wird, zeichnet die Datenbank einen SCN für dieses Festschreiben auf.
    Es gibt eine Obergrenze, wie viele SCNs eine Oracle-Datenbank verwenden kann. Die Grenze liegt derzeit bei 281 Billionen (2 ^ 48) SCN-Werten.
    Da es eine Obergrenze gibt, ist es wichtig, dass einer bestimmten Oracle-Datenbank nicht die verfügbaren SCNs ausgehen.
    Der Hinweis erklärt auch, wann die Warnung ausgelöst wird. Die Oracle-Datenbank berechnet eine „nicht zu überschreitende“ Grenze für die Anzahl der SCNs, die eine Datenbank derzeit verwenden kann, basierend auf der Anzahl der Sekunden seit 1988 multipliziert mit 16384. Dadurch wird sichergestellt, dass Oracle-Datenbanken SCNs im Laufe der Zeit rationieren.

Wie ernst ist diese Warnung?

Die Warnung wird in den letzten 60 Minuten mit einer Rate von 2 ^14 = 16384 SCNs pro Sekunde ausgelöst.
Der maximale SCN ist 2^48 = 281.474.976.710.656.

Bei einer Rate von 16348 SCNs pro Sekunde haben wir 2 ^ (48-14) Sekunden oder 544 Jahre Zeit, um dieses Maximum zu erreichen. Das sollte in einer normalen Situation ausreichen, aber die Obergrenze von 2 ^ 48 ist nur der maximale Absolutwert, den die Datenbank speichern kann.
Das Limit bezieht sich auch auf die Anzahl der Sekunden seit 1988. Die Grenze von 2 ^ 48 ist das Maximum im Jahr 2532 (1988+544). Aber im Jahr 2018 ist das Maximum (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

Die Warnung sollte nicht ignoriert werden. Wenn Sie das Limit erreichen, erhalten Sie ora-600-Fehler, aber wenn Sie das absolute obere Limit SCN erreichen, funktioniert die Datenbank einfach nicht mehr.

Die gute Nachricht ist, dass in unserer Situation die Warnung besagt, dass die SCN-Wachstumsrate in dieser bestimmten Stunde 25867 pro Sekunde betrug, so dass wir in dieser Stunde etwas näher (25867-16384 = 9483) an die Grenze kamen. Wir kommen nicht jede Stunde an die Grenze heran; Die normale Wachstumsrate ist niedriger als 16384.

Oracle Support

Wir haben den Oracle Support angerufen und sie haben uns mitgeteilt, dass Oracle Development derzeit an diesem Problem arbeitet.
Oracle Support bestätigte, dass der SCN Headroom gut aussieht. Basierend auf dem AWR-Bericht bemerkte der Oracle-Support eine hohe Anzahl von Commits und schlug vor, das Anwendungsteam zu kontaktieren, um das Commit durch Erhöhen der Transaktionsgröße durchzuführen.

Untersuchung mit AWR

Die Warnung in der Warndatei teilte uns mit, dass die intrinsische SCN-Wachstumsrate in den letzten 60 Minuten konstant höher als der Systemstandard war: 16384 pro Sekunde. Wenn wir einen Zeitrahmen von einer Stunde betrachten, könnte ein AWR-Bericht ein guter Anfang sein. Wir haben AWR so konfiguriert, dass jede Stunde Schnappschüsse erstellt werden.

Im AWR-Bericht habe ich festgestellt, dass die Anzahl der Benutzer-Commits 210 pro Sekunde betrug. Ja, das sind viele Commits, aber es unterscheidet sich nicht so sehr von der normalen Belastung dieser Datenbank. Und wenn ein Commit mit einem SCN zusammenhängt, ist es auch viel niedriger als 16384 pro Sekunde.

Der AWR-Bericht enthielt auch einen ADDM-Befund: Wartezeiten auf das Ereignis „Protokolldateisynchronisierung“ während der Durchführung von COMMIT- und ROLLBACK-Vorgängen verbrauchten erhebliche Datenbankzeit. Untersuchen Sie die Anwendungslogik auf eine mögliche Reduzierung der Anzahl von COMMIT-Vorgängen durch Erhöhen der Transaktionsgröße.
Diese Reduzierung der Commits in den ADDMS wurde auch vom Oracle Support vorgeschlagen. Aus meiner Sicht war es aber nicht wirklich so hoch.

Kürzerer Zeitrahmen

Da die AWR mir nicht half, die Ursache zu finden, musste ich einen kürzeren Zeitrahmen untersuchen. Ich wollte einen genaueren Zeitrahmen kennen, damit ich einen ASH-Bericht erstellen kann. Der Standardwert für ASH ist 15 Minuten.
Die nächste Herausforderung bestand also darin, den 15-Minuten-Zeitrahmen zu finden, in dem die SCN-Wachstumsrate am höchsten war.
Doc ID 1388639.1 vorgeschlagen, v $archived_log abzufragen. Diese Ansicht enthält Informationen zu allen Protokollschaltern in der Datenbank, einschließlich eines Zeitstempels und des SCN. Obwohl Sie Zeitstempel SCNs zuordnen können, ist dies nicht wirklich besser als der AWR-Bericht. Wir bleiben immer noch bei zufälligen Zeitstempeln; in diesem Fall der Zeitstempel des Logswitch.

Verwenden der Funktion timestamp_to_scn

Ein besserer Weg ist die Verwendung der Funktion timestamp_to_scn . Diese Funktion gibt einen SCN basierend auf einem Zeitstempel wie dem aktuellen Zeitstempel zurück:

     
  1.  SQL> WÄHLEN SIE timestamp_to_scn (sysdate) AUS DER LISTE ;
    2.  
  2.  
    3.  
  3.  TIMESTAMP_TO_SCN(SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7.  SQLS> 
    8.

Der nächste Schritt bestand darin, eine Liste von Zeitstempeln zusammen mit der passenden SCN und der passenden SCN-Obergrenze zu erstellen, basierend auf der Anzahl der Sekunden seit 1988 multipliziert mit 16.384.

Dies zeigt die Zeitstempel und SCNs für den letzten Tag:

     
  1.  WÄHLEN SIE sysdate - (rownum/24) datetimestamp
    2.  
  2.  , zeitstempel_to_scn(sysdate - (rownum/24)) SCN
    3.  
  3.  , (( sysdate - (rownum/24)) - to_date('01-01-1988','TT-MM-JJJJ' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  VON dual
    6.  
  6.  CONNECT VON rownum <= 24 
    7.  
  7. /
    8.  
     
  1.  DATUMSSTEMPEL SCN UPPER_LMT
    2.  
  2.  ------------------- -------------------- -------------------- 
    3.  
  3. 09-07-2018-13:23:39 95423916508 15780233527296 
    4.  
  4. 09-07-2018-12:23:39 95380086165 15780174544896 
    5.  
  5. 09-07-2018-11:23:39 95338871931 15780115562496 
    6.  
  6. 09-07-2018-10:23:39 95303437600 15780056580096 
    7.  
  7. 09-07-2018-09:23:39 95265573942 15779997597696 
    8.  
  8. 09-07-2018-08:23:39 95226645452 15779938615296 
    9.  
  9. 09-07-2018-07:23:39 95186822906 15779879632896 
    10.  
  10. 09-07-2018-06:23:39 95147382509 15779820650496 
    11.  
  11. 09-07-2018-05:23:39 95115474008 15779761668096 
    12.  
  12. 09-07-2018-04:23:39 95079712219 15779702685696 
    13.  
  13. 09-07-2018-03:23:39 95041469231 15779643703296 
    14.  
  14. 09-07-2018-02:23:39 95006499794 15779584720896 
    15.  
  15. 09-07-2018-01:23:39 94975060529 15779525738496 
    16.  
  16. 09-07-2018-00:23:39 94945771055 15779466756096 
    17.  
  17. 08-07-2018-23:23:39 94907451372 15779407773696 
    18.  
  18. 08-07-2018-22:23:39 94875158341 15779348791296 
    19.  
  19. 08-07-2018-21:23:39 94838756696 15779289808896 
    20.  
  20. 08-07-2018-20:23:39 94800190958 15779230826496 
    21.  
  21. 08-07-2018-19:23:39 94757984611 15779171844096 
    22.  
  22. 08-07-2018-18:23:39 94724548846 15779112861696 
    23.  
  23. 08-07-2018-17:23:39 94685506947 15779053879296 
    24.  
  24. 08-07-2018-16:23:39 94646644945 15778994896896 
    25.  
  25. 08-07-2018-15:23:39 94605003069 15778935914496 
    26.  
  26. 08-07-2018-14:23:39 94572205685 15778876932096 
    27.  
  27.  
    28.  
  28.  24 zeilen ausgewählt. 
    29.

Der aktuelle SCN beträgt etwa 0,57% der aktuellen Obergrenze.

Finden der höchsten SCN-Rate

Basierend auf dieser Idee habe ich eine Abfrage erstellt, die mir den 15-Minuten-Zeitrahmen mit dem höchsten Wachstum der SCNs in den letzten 3 Tagen angibt.

Jede Minute beginnt ein neuer Zeitrahmen, und da wir 1440 Minuten in einem Tag haben, müssen wir 4320 Zeitrahmen untersuchen. Für jeden von ihnen müssen wir das Wachstum des SCN innerhalb dieses 15-Minuten-Zeitrahmens berechnen.

Wir möchten nur die Top-Ergebnisse anzeigen, in diesem Fall nur die Zeitrahmen mit einer Rate von über 14000 pro Sekunde.

     
  1.  ALTER SESSION SET nls_date_format='TT.MM.JJ HH24:MI' ;
    2.  
  2.  
    3.  
  3.  MIT datelist ALS 
    4.  
  4.  ( SELECT sysdate - (rownum/1440) - (15/1440) starttime -- 15 Minuten Intervall 
    5.  
  5.  , sysdate - (rownum/1440) Endzeit
    6.  
  6.  VON dual
    7.  
  7.  CONNECT VON rownum <= (3*1440) -- 3 tage Geschichte 
    8.  
  8. )
    9.  
  9.  WÄHLEN SIE starttime
    10.  
  10.  , endzeit
    11.  
  11.  , timestamp_to_scn(Endzeit) - timestamp_to_scn(Startzeit) Scnwachstum
    12.  
  12.  , runde((timestamp_to_scn (Endzeit) - timestamp_to_scn (Startzeit)) / 
    13.  
  13.  (((24*60*60)*( endzeit-Startzeit )))) scnrate
    14.  
  14.  VON datelist
    15.  
  15.  WO round((timestamp_to_scn(Endzeit) - timestamp_to_scn(Startzeit)) / 
    16.  
  16.  (((24*60*60)*( endzeit-Startzeit )))) >= 14000 
    17.  
  17.  SORTIEREN NACH 4 DESC 
    18.  
  18. /
    19.  
     
  1.  STARTZEIT ENDZEIT SCNWACHSTUM SCNRATE
    2.  
  2. -------------- -------------- -------------------- --------------------
    3.  
  3. 07/06/18 18:09 07/06/18 18:24 12761928 14180 
    4.  
  4. 07/07/18 05:20 07/07/18 05:35 12742537 14158 
    5.  
  5. 07/09/18 13:59 07/09/18 14:14 12705077 14117 
    6.  
  6. 07/09/18 12:57 07/09/18 13:12 12672507 14081 
    7.  
  7. 07/09/18 07:06 07/09/18 07:21 12654287 14060 
    8.

Jetzt haben wir also die (manchmal überlappenden) 15-Minuten-Zeitrahmen mit der höchsten SCN-Rate (SCN-Wachstum pro Sekunde) für die letzten 3 Tage gefunden. Und selbst in diesen Zeitrahmen liegt die SCN-Rate immer noch unter 16384. Keine Warnungen in der Warndatei diese Woche ….

Ausführen des ASH-Berichts

Das Datumsformat, das ich in der obigen Abfrage verwendet habe, ist das gleiche wie im ASH-Bericht, sodass Sie die Startzeit einfach kopieren / einfügen können. Für die Dauer geben wir 15 Minuten ein.

     
  1.  SQL> @@$ORACLE_HOME/rdbms/Administrator/ashrpt.sqls
    2.  
  2.  
    3.  
  3.  Ascheproben IN diesem Workload-Repository-Schema
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6.  Älteste verfügbare Ascheprobe: 01-Jul-18 00:00:01 
    7.  
  7.  Letzte verfügbare Ascheprobe: 09-Jul-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10.  Geben Sie den Zeitrahmen FÜR die Erstellung des ASH-Berichts an
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12.  Geben Sie die STARTZEIT FÜR DEN Bericht ein:
    13.  
  13.  
    14.  
  14. -- Gültige Eingabeformate:
    15.  
  15. -- So geben Sie die absolute Anfangszeit an:
    16.  
  16. -- ] HH24:MI
    17.  
  17. -- Beispiele: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- So geben Sie die relative Anfangszeit an: (Beginnen Sie mit dem Zeichen '-')
    22.  
  22. -- - MI
    23.  
  23. -- Beispiele: -1:15 (SYSDATE - 1 Stunde 15 Minuten)
    24.  
  24. -- -25 ( SYSDATE - 25 Minuten)
    25.  
  25.  
    26.  
  26.  Standardmäßig -15 Minuten
    27.  
  27.  Geben Sie den WERT FÜR begin_time ein: 07/06/18 18:09
    28.  
  28.  Berichts-ANFANGSZEIT spezifiziert: 07/06/18 18:09
    29.  
  29.  
    30.  
  30.  Dauer IN Minuten AB STARTZEIT eingeben:
    31.  
  31.  Standardmäßig SYSDATE - begin_time
    32.  
  32.  Drücken Sie DIE Eingabetaste, UM DIE AKTUELLE ZEIT zu analysieren 
    33.  
  33.  WERT FÜR Dauer eingeben: 15 
    34.  
  34.  Berichtsdauer angegeben: 15 
    35.  
  35.  
    36.  
  36.  VERWENDEN VON 06-Jul-18 18:09:00 ALS BERICHTSANFANGSZEIT 
    37.  
  37.  VERWENDEN VON 06-Jul-18 18:24:00 ALS BERICHTSENDZEIT 
    38.  
  38.  
    39.  
  39.  Geben Sie den Berichtsnamen an
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41.  Der standardmäßige Name der Berichtsdatei IST ashrpt_1_0706_1824.HTML. UM diesen Namen ZU VERWENDEN, 
    42.  
  42.  drücken Sie <return>, UM fortzufahren, andernfalls geben Sie eine Alternative ein. 
    43.  
  43.  WERT FÜR report_name eingeben:
    44.  
  44.  
    45.  
  45.  VERWENDEN des Berichtsnamens ashrpt_1_0706_1824.HTML-code
    46.  
  46.  
    47.  
  47.  Zusammenfassung ALLER BENUTZEREINGABEN 
    48.  
  48. -------------------------
    49.  
  49.  Dateiformat : HTML
    50.  
  50.  DB-ID : 2019395491 
    51.  
  51.  Inst num : 1 
    52.  
  52.  BEGINN : 06-Jul-18 18:09:00
    53.  
  53.  ENDZEIT : 06-Jul-18 18:24:00
    54.  
  54.  Slot breite: STANDARD 
    55.  
  55.  Ziele melden : 0 
    56.  
  56.  Name des Berichts : ashrpt_1_0706_1824.HTML-code
    57.

Finden von SCN in AWR

Der AWR-Bericht zeigte uns nicht viele Informationen über den aktuellen SCN, aber er enthält einige Informationen über die Wachstumsrate, wenn Sie wissen, wo Sie ihn finden können.

Unter „Instance Activity Stats“ finden Sie die Anzahl der „calls to kcmgas“. In der Oracle-Dokumentation wird dies als „Anzahl der Aufrufe der Routine kcmgas zum Abrufen eines neuen SCN“ beschrieben.

Der Wert dieser Aufrufe pro Sekunde im AWR-Bericht liegt sehr nahe an der SCN-Rate, die mit der Funktion timestamp_to_scn berechnet wurde.

V$SESSTAT view

Die Anzahl der „calls to kcmgas“, die zum Erstellen eines neuen SCN verwendet werden, finden Sie auch in den Ansichten V$SESSTAT und V$SYSSTAT.

Wir können V$SESSTAT verwenden, um die Sitzungen zu finden, die eine hohe SCN-Rate verursachen. Wir können auch die Auswirkungen bestimmter Aktionen auf die SCN-Anzahl testen.

Wenn ich beispielsweise eine Auswahl für eine große Tabelle vornehme, die auch von anderen Sitzungen verwendet wird, führt meine Sitzung weitere 7 Aufrufe von kcmgas durch. Meine Abfrage führt also zu einem höheren SCN. Dies wird durch die Lesekonsistenz der Datenbank verursacht, die auch einen SCN verwendet.

     
  1.  SQL> VERBINDEN <Benutzer>/ < übergeben>@<service> 
    2.  
  2.  Verbunden. 
    3.  
  3.  SQL> WÄHLEN SIE ses.wert
    4.  
  4.  VON v $ sesstat ses
    5.  
  5.  , v$statname Wert
    6.  
  6.  WO stat.statistik #=ses.statistik#
    7.  
  7.  UND ses.sid IN (WÄHLEN SIE sid AUS v$mystat) 
    8.  
  8.  UND stat.name = 'Aufrufe an kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  WERT 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15.  SQL> WÄHLEN SIE COUNT(*) AUS mybigtable ;
    16.  
  16.  
    17.  
  17.  ZÄHLEN(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21.  SQL> WÄHLEN SIE ses.wert
    22.  
  22.  VON v $ sesstat ses
    23.  
  23.  , v$statname Wert
    24.  
  24.  WO stat.statistik #=ses.statistik#
    25.  
  25.  UND ses.sid IN (WÄHLEN SIE sid AUS v$mystat) 
    26.  
  26.  UND stat.name = 'Aufrufe an kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  WERT 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33.  SQLS> 
    34.

Wenn wir die SCN- und Commit-Rate

Mit V $SESSTAT vergleichen, können wir die Statistiken für alle Sitzungen abfragen, die derzeit mit der Datenbank verbunden sind. Auf diese Weise können wir Sitzungen finden, die für eine hohe SCN-Rate verantwortlich sind. Wir können dies mit der Commit-Rate für diese Sitzung vergleichen.

Die Ergebnisse der folgenden Abfrage zeigten uns, dass die hohe SCN-Rate in unserer Datenbank hauptsächlich durch Hintergrundprozesse verursacht wurde. Für die meisten Benutzersitzungen besteht eine Beziehung zwischen einer hohen SCN-Rate und einer hohen Commit-Rate, für Hintergrundsitzungen ist die Commit-Rate immer leer.

     
  1.  WÄHLEN SIE ses.sid
    2.  
  2.  , entziffern(ses.benutzername ,NULL, 'Hintergrund','Benutzer' ) session_type
    3.  
  3.  , ( sysdate - logon_time) * 24 * 60 * 60 connect_seconds
    4.  
  4.  , sstat1.wert SCN#
    5.  
  5.  , sstat2.wert COMMIT#
    6.  
  6.  , runde(sstat1.wert / ((sysdate - logon_time ) * 24 * 60 * 60),2) scn_rate
    7.  
  7.  , runde(sstat2.wert / ((sysdate - logon_time ) * 24 * 60 * 60),2) commit_rate
    8.  
  8.  VON v$sesstat sstat1
    9.  
  9.  , v$sesstat sstat2
    10.  
  10.  , v$statname sn1
    11.  
  11.  , v$statname sn2
    12.  
  12.  , v $ Sitzung ses
    13.  
  13.  WO sstat1.statistik# = sn1.statistik#
    14.  
  14.  UND sstat2.statistik# = sn2.statistik#
    15.  
  15.  UND sn1.name = 'Aufrufe an kcmgas' 
    16.  
  16.  UND sn2.name = 'benutzer Commits' 
    17.  
  17.  UND ses.sid = sstat1.sid
    18.  
  18.  UND ses.sid = sstat2.sid
    19.  
  19.  SORTIEREN NACH 6 DESC 
    20.  
  20. /
    21.  
  21.  
    22.  
  22.  SID SESSION_TY CONNECT_SECONDS SCN# COMMIT# SCN_RATE COMMIT_RATE
    23.  
  23. ---------- ---------- --------------- ---------- ---------- ---------- -----------
    24.  
  24.  8478 hintergrund 459572 214506344 0 466.75 0 
    25.  
  25.  7551 hintergrund 452395 209729934 0 463.6 0 
    26.  
  26.  3776 hintergrund 290389 133863489 0 460.98 0 
    27.  
  27.  8496 hintergrund 121201 55685740 0 459.45 0 
    28.  
  28.  8729 hintergrund 286773 128180386 0 446.98 0 
    29.  
  29.  12009 hintergrund 290392 128867329 0 443.77 0 
    30.  
  30.  13173 hintergrund 196775 87268032 0 443.49 0 
    31.  
  31.  12004 hintergrund 103166 45681480 0 442.8 0 
    32.  
  32.  8735 hintergrund 275980 121563094 0 440.48 0 
    33.  
  33.  3096 hintergrund 430810 185436599 0 430.44 0 
    34.  
  34.  8027 hintergrund 95990 40912187 0 426.21 0 
    35.  
  35.  7529 hintergrund 193218 81367643 0 421.12 0 
    36.  
  36.  2370 hintergrund 527978 219521415 0 415.78 0 
    37.  
  37.  14604 hintergrund 283216 117052382 0 413.3 0 
    38.  
  38.  14132 hintergrund 113965 46586388 0 408.78 0 
    39.  
  39.  7552 hintergrund 294009 119775077 0 407.39 0 
    40.  
  40.  13172 hintergrund 182423 73865595 0 404.91 0 
    41.  
  41.  14592 hintergrund 74414 29767705 0 400.03 0 
    42.  
  42.  3802 hintergrund 268804 107486102 0 399.87 0 
    43.  
  43.  9910 hintergrund 117582 46596720 0 396.29 0 
    44.  
  44.  12021 hintergrund 49182 19321676 0 392.86 0 
    45.  
  45.  974 hintergrund 160816 59996495 0 373.08 0 
    46.  
  46.  12723 hintergrund 74450 25455559 0 341.91 0 
    47.  
  47.  3310 hintergrund 193215 65915175 0 341.15 0 
    48.  
  48.  12963 hintergrund 49179 15687084 0 318.98 0 
    49.  
  49.  6111 hintergrund 3584090 1031139557 0 287.7 0 
    50.  
  50.  6829 BENUTZER 303 1267 1123 4.18 3.71 
    51.  
  51.  9665 BENUTZER 904 1845 1691 2.04 1.87 
    52.  
  52.  8022 BENUTZER 898 1677 1520 1.87 1.69 
    53.  
  53.  3323 BENUTZER 898 1406 1260 1.57 1.4 
    54.  
  54.  2839 BENUTZER 7503 10822 9813 1.44 1.31 
    55.  
  55.  11060 BENUTZER 3892 5334 4781 1.37 1.23 
    56.  
  56.  13184 BENUTZER 1765 2359 2038 1.34 1.15 
    57.  
  57.  9199 BENUTZER 898 1135 935 1.26 1.04 
    58.  
  58.  2130 BENUTZER 8105 9548 8518 1.18 1.05 
    59.  
  59.  11525 BENUTZER 898 1054 944 1.17 1.05 
    60.  
  60.  6130 BENUTZER 3895 4453 4199 1.14 1.08 
    61.  
  61.  8012 BENUTZER 7503 8576 7774 1.14 1.04 
    62.  
  62.  4497 BENUTZER 898 962 882 1.07 .98
    63.  
  63.  5201 BENUTZER 7220 7551 6226 1.05 .86
    64.  
  64.  11317 BENUTZER 12906 13371 11997 1.04 .93
    65.  
  65.  
    66.  
  66.  
    67.  
  67.  1979 ZEILEN ausgewählt. 
    68.

Fazit

Beachten Sie, dass es Grenzen für den SCN gibt, also wenn Sie Warnungen in der Warndatei finden, müssen Sie das Problem untersuchen. Wenn Sie ein Problem finden, sollten Sie mit Oracle Support arbeiten. Durch das Hochladen von Informationen können sie überprüfen, ob zwischen dem aktuellen und dem maximalen SCN genügend Platz vorhanden ist.

Probleme können durch einen Fehler wie 12371955 verursacht werden: Hot Backup kann eine erhöhte SCN-Wachstumsrate verursachen, die zu ORA-600-Fehlern führt (Doc ID 12371955.8).

Wenn Sie den genauen Zeitpunkt eines hohen Wachstums von SCNs ermitteln möchten, müssen Sie Zeitstempel in SCNs konvertieren. Die besten Ergebnisse erhalten Sie mit den Funktionen SCN_TO_TIMESTAMP und TIMESTAMP_TO_SCN.

Eine hohe Commit-Rate hängt immer mit Benutzerprozessen zusammen, aber SCNs hängen auch mit Hintergrundprozessen zusammen. Selbst Sitzungen, die nicht festgeschrieben werden, können Auswirkungen auf den SCN haben.

Bastiaan Bak

Über den Autor Bastiaan Bak

DBA mit über 15 Jahren Erfahrung. Erfahrung in verschiedenen Branchen, mit mehreren Modulen. Darunter: Oracle Datenbank, Oracle RAC, Oracle EBS und PL/SQL.

Mehr Beiträge von Bastiaan Bak

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.