badanie wewnętrznego tempa wzrostu SCN

Written by on in Articles

opublikowano: 10 lipca 2018 Autor: Bastiaan Bak Kategoria: rozwój i operacje IT

jakiś czas temu mieliśmy ostrzeżenie o wewnętrznym wzroście SCN (numer zmiany systemu) w naszym pliku Oracle 12.2 database alert file. Sytuacja ta miała miejsce kilka razy w ciągu kilku tygodni.

„Uwaga: tempo wzrostu SCN jest konsekwentnie
wyższe niż domyślne 16384 na SEK. przez ostatnie 60 minut.
obecne tempo wzrostu SCN wynosi 25867 na SEK., zas 200fffff!
aktualna wartość SCN to 46747726691, wartość SCN Compat to 1″

Moja początkowa reakcja polegała na tym, że SCN są powiązane z commitami, więc albo obciążenie bazy danych było bardzo wysokie, albo logika aplikacji powinna zostać zmieniona. Inną możliwością było to, że commit był wykonywany po każdej aktualizacji, zamiast używać commitów wsadowych.

okazało się to nieco bardziej skomplikowane niż się spodziewałem. Gdzie szukać relacji między SCN a commitami? Jak poważne jest to Ostrzeżenie? Ten blog będzie o różnych sposobach, w jakie badałem ten problem i zidentyfikowałem potencjalny wpływ.

uwagi pomocy technicznej Oracle

pierwsze miejsce do wyszukiwania informacji o ostrzeżeniach w pliku alertów to Witryna pomocy technicznej Oracle. Znalazłem kilka powiązanych notatek:

  • ORA-19706 i powiązane komunikaty dziennika alarmów (Doc ID 1393360.1)
    ta notatka sugeruje, że rzeczywisty komunikat jest specyficzny dla wersji bazy danych 12.2, ale w starszych wersjach możemy mieć podobne ostrzeżenia, takie jak ” Warning: The SCN headroom for this database is only NN days!”
    Jeśli pojawi się komunikat dziennika alertów, taki jak którykolwiek z tych wpisów, zaleca się postępować zgodnie z instrukcjami podanymi w ID 1388639.1 i zarejestrować zgłoszenie serwisowe z Pomocą techniczną Oracle.
    dowody do zebrania podczas zgłaszania problemów z wysokim współczynnikiem SCN do pomocy technicznej Oracle (Doc ID 1388639.1)
  • ta notatka zawiera informacje o tym, jakie informacje należy dostarczyć podczas rejestrowania zgłoszenia serwisowego.
  • System Change Number (SCN), Headroom, Security and Patch Information (Doc ID 1376995.1)
    ta notatka zawiera więcej informacji na temat użycia SCN. System change number (SCN) jest logicznym, wewnętrznym znacznikiem czasu używanym przez bazę danych Oracle. SCN porządkuje zdarzenia występujące w bazie danych. Baza danych używa SCN do odpytywania i śledzenia zmian. Gdy transakcja commita, baza danych rejestruje SCN dla tego commita.
    istnieje górny limit liczby SCN, z których może korzystać baza danych Oracle. Limit wynosi obecnie 281 bilionów (2^48) wartości SCN.
    biorąc pod uwagę, że istnieje górny limit, ważne jest, aby w danej bazie danych Oracle nie zabrakło dostępnych SCN.
    notka wyjaśnia również, kiedy ostrzeżenie jest podniesione. Baza danych Oracle oblicza limit” nie przekraczać ” liczby SCN, z których baza danych może obecnie korzystać, na podstawie liczby sekund od 1988 r. pomnożonej przez 16384. Dzięki temu bazy danych Oracle będą z czasem przetwarzać SCN.

jak poważne jest to Ostrzeżenie?

ostrzeżenie jest podnoszone z szybkością 2^14 = 16384 SCNs na sekundę przez ostatnie 60 minut.
maksymalny SCN wynosi 2^48 = 281.474.976.710.656.

przy tempie 16348 SCNs na sekundę będziemy mieli 2^(48-14) sekund, czyli 544 lata, aby osiągnąć to maksimum. To powinno wystarczyć w normalnej sytuacji, ale górna granica 2^48 to tylko maksymalna wartość bezwzględna, którą baza danych może przechowywać.
limit jest również związany z liczbą sekund od 1988 roku. Limit 2^48 to maksimum w roku 2532 (1988+544). Ale w 2018 roku maksimum wynosi (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

ostrzeżenie nie powinno być ignorowane. Po osiągnięciu limitu pojawią się błędy ora-600, ale po osiągnięciu bezwzględnego górnego limitu SCN baza danych po prostu przestanie działać.

dobra wiadomość jest taka, że w naszej sytuacji Ostrzeżenie mówi, że tempo wzrostu SCN wynosi 25867 na sekundę w tej konkretnej godzinie, więc w tej godzinie zbliżyliśmy się nieco (25867-16384=9483) do granicy. Nie zbliżamy się do granicy co godzinę; normalna stopa wzrostu jest niższa niż 16384.

Oracle Support

zadzwoniliśmy do Oracle Support i powiedziano nam, że Oracle Development pracuje obecnie nad tym problemem.
wsparcie Oracle potwierdziło, że głowica SCN wygląda dobrze. Opierając się na raporcie AWR, Oracle Support zauważyło dużą liczbę zatwierdzeń i zasugerowało, aby skonsultować się z zespołem aplikacji w celu zatwierdzenia, zwiększając rozmiar transakcji.

dochodzenie z AWR

ostrzeżenie w pliku alertu mówi nam, że szybkość wzrostu SCN jest konsekwentnie wyższa niż domyślna wartość systemu: 16384 na sekundę przez ostatnie 60 minut. Jeśli patrzymy na ramy czasowe godziny, raport AWR może być dobrym miejscem na początek. Mamy AWR skonfigurowany do robienia migawek co godzinę.

w raporcie AWR zauważyłem, że liczba commitów użytkownika wynosiła 210 na sekundę. Tak, to dużo commitów, ale nie różni się to tak bardzo od normalnego obciążenia tej bazy danych. A jeśli commit jest powiązany z SCN, jest również znacznie niższy niż 16384 na sekundę.

raport AWR zawierał również informację ADDM: oczekiwanie na zdarzenie „log file sync” podczas wykonywania operacji COMMIT i ROLLBACK pochłaniało znaczny czas bazy danych. Zbadaj logikę aplikacji pod kątem możliwego zmniejszenia liczby operacji zatwierdzania przez zwiększenie rozmiaru Transakcji.
ta redukcja zmian w znalezisku ADDM została również zasugerowana przez Oracle Support. Z mojego punktu widzenia, nie było tak wysoko.

krótszy czas

ponieważ AWR nie pomagał mi znaleźć przyczyny, musiałem zbadać krótszy czas. Chciałem poznać bardziej konkretne ramy czasowe, żebym mógł stworzyć raport ASH. Wartość domyślna dla ASH wynosi 15 minut.
więc kolejnym wyzwaniem było znalezienie 15-minutowego przedziału czasowego, w którym tempo wzrostu SCN było najwyższe.
Doc ID 1388639.1 suggested to query v$archived_log. Ten widok zawiera informacje o wszystkich przełącznikach dziennika w bazie danych, w tym o znaczniku czasu i SCN. Chociaż można mapować znaczniki czasu do SCN, nie jest to tak naprawdę lepsze niż raport AWR. Nadal tkwimy w losowych znacznikach czasu; w tym przypadku znacznik czasu logswitch.

Korzystanie z funkcji timestamp_to_scn

lepszym sposobem jest użycie funkcji timestamp_to_scn. Ta funkcja zwraca SCN oparty na znaczniku czasu, takim jak bieżący znacznik czasu:

     
  1. SQL> SELECT timestamp_to_scn (sysdate) FROM dual ;
    2.  
  2.  
    3.  
  3. TIMESTAMP_TO_SCN(SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7. SQL> 
    8.

następnym krokiem było stworzenie listy znaczników czasu wraz z pasującym SCN i pasującym górnym limitem SCN, na podstawie liczby sekund od 1988 pomnożonej przez 16,384.

to pokazuje znaczniki czasu i SCN dla ostatniego dnia:

     
  1.  wybierz sysdate - (rownum/24) datetimestamp
    2.  
  2.  , timestamp_to_scn (sysdate - (rownum/24)) SCN
    3.  
  3.  , ((sysdate - (rownum/24)) - to_date ('01-01-1988', 'DD-MM-YYYY' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  od dual
    6.  
  6.  CONNECT by rownum <= 24 
    7.  
  7. /
    8.  
     
  1. DATETIMESTAMP 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 zaznaczone wiersze. 
    29.

obecny SCN wynosi około 0,57% aktualnej górnej granicy.

znalezienie najwyższego wskaźnika SCN

na podstawie tego pomysłu stworzyłem zapytanie, które daje mi 15 minutowy przedział czasowy z najwyższym wzrostem SCN w ciągu ostatnich 3 dni.

co minutę rozpoczyna się nowy przedział czasowy, a ponieważ mamy 1440 minut w ciągu dnia, mamy 4320 przedziałów czasowych do zbadania. Dla każdego z nich musimy obliczyć wzrost SCN w tym 15-minutowym przedziale czasowym.

chcemy pokazać tylko najlepsze wyniki, w tym przypadku tylko ramy czasowe z szybkością ponad 14000 na sekundę.

     
  1.  ALTER SESSION SET nls_date_format= 'MM / DD / YY HH24: MI' ;
    2.  
  2.  
    3.  
  3.  z datelist jako 
    4.  
  4.  ( wybierz sysdate - (rownum/1440) - (15/1440) starttime -- 15 minut interval 
    5.  
  5.  , sysdate - (rownum/1440) 
    6.  
  6.  od dual
    7.  
  7.  CONNECT by rownum <= (3*1440) -- 3 Historia dni 
    8.  
  8. )
    9.  
  9.  wybierz starttime
    10.  
  10.  , endtime
    11.  
  11.  , timestamp_to_scn(endtime) - timestamp_to_scn (starttime) 
    12.  
  12.  , round ((timestamp_to_scn (endtime)) - timestamp_to_scn (starttime)) / 
    13.  
  13.  (((24*60*60)*(endtime-starttime))) scnrate
    14.  
  14.  z datelist
    15.  
  15.  WHERE round ((timestamp_to_scn (endtime) - timestamp_to_scn (starttime)) / 
    16.  
  16.  (((24*60*60)*(endtime-starttime )))) >= 14000 
    17.  
  17.  Zamów przez 4 DESC 
    18.  
  18. /
    19.  
     
  1. STARTTIME ENDTIME SCNGROZWÓJ 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.

tak więc, teraz znaleźliśmy (czasami nakładające się) 15 minutowe ramy czasowe z najwyższą szybkością SCN (wzrost SCN na sekundę) w ciągu ostatnich 3 dni. I nawet w tych ramach czasowych wskaźnik SCN jest nadal poniżej 16384. Brak ostrzeżeń w pliku alarmowym w tym tygodniu….

Uruchamianie raportu ASH

format daty, którego użyłem w powyższym zapytaniu, jest taki sam, jak używany przez raport ASH, więc możesz po prostu skopiować/wkleić czas rozpoczęcia. Na czas trwania wchodzimy 15 minut.

     
  1. SQL> @ @ $ORACLE_HOME / RDBMS / admin / ashrpt.sql
    2.  
  2.  
    3.  
  3. próbki popiołu w tym schemacie repozytorium obciążeń
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. najstarsza dostępna próbka popiołu: 01-lipiec-18 00:00:01 
    7.  
  7. najnowsza dostępna próbka popiołu: 09-lipiec-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. Określ ramy czasowe generowania raportu ASH
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. podaj czas rozpoczęcia raportu:
    13.  
  13.  
    14.  
  14. -- prawidłowe formaty wejściowe:
    15.  
  15. -- aby określić bezwzględny czas rozpoczęcia:
    16.  
  16. -- ] HH24: MI
    17.  
  17. -- przykłady: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- aby określić względny czas rozpoczęcia: (zacznij od znaku' -')
    22.  
  22. -- - MI
    23.  
  23. -- przykłady: -1:15 (SYSDATE-1 godz. 15 min.)
    24.  
  24. -- -25 ( SYSDATE - 25 min)
    25.  
  25.  
    26.  
  26. domyślnie -15 min
    27.  
  27. Wprowadź wartość dla begin_time: 07/06/18 18:09
    28.  
  28. podany czas rozpoczęcia raportu: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. wprowadź Czas trwania w minutach począwszy od czasu rozpoczęcia:
    31.  
  31. domyślnie SYSDATE-begin_time
    32.  
  32. naciśnij Enter, aby analizować do bieżącego czasu 
    33.  
  33. Wprowadź wartość dla czasu trwania: 15 
    34.  
  34. określony czas trwania raportu: 15 
    35.  
  35.  
    36.  
  36.  używanie 06-Jul-18 18:09:00 jako czasu rozpoczęcia raportu 
    37.  
  37.  używanie 06-Jul-18 18:24:00 jako czasu zakończenia raportu 
    38.  
  38.  
    39.  
  39. podaj nazwę raportu
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. domyślna nazwa pliku raportu to ashrpt_1_0706_1824.html. Aby użyć tej nazwy, 
    42.  
  42. naciśnij < return>, aby kontynuować, w przeciwnym razie wprowadź alternatywę. 
    43.  
  43. Wprowadź wartość dla nazwa_ raportu:
    44.  
  44.  
    45.  
  45.  używając nazwy raportu ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47. podsumowanie wszystkich wpisów użytkownika
    48.  
  48. -------------------------
    49.  
  49. Format: HTML
    50.  
  50. DB Id : 2019395491 
    51.  
  51. Inst num : 1 
    52.  
  52.  czas rozpoczęcia: 06-lipiec-18 18:09:00
    53.  
  53.  koniec: 06-lipiec-18 18:24:00
    54.  
  54. Szerokość szczeliny: domyślnie 
    55.  
  55. zgłoś cele : 0 
    56.  
  56. Nazwa raportu : ashrpt_1_0706_1824html
    57.

znalezienie SCN w AWR

raport AWR nie pokazał nam zbyt wielu informacji na temat obecnego SCN, ale ma pewne informacje na temat tempa wzrostu, jeśli wiesz, gdzie go znaleźć.

w sekcji „Statystyki aktywności instancji” możesz znaleźć liczbę „wywołań do kcmgas”. W dokumentacji Oracle jest to opisane jako”liczba wywołań rutynowych kcmgas, aby uzyskać nowy SCN”.

wartość tych wywołań na sekundę w raporcie AWR jest bardzo zbliżona do szybkości SCN obliczonej za pomocą funkcji timestamp_to_scn.

V$SESSTAT view

liczba „wywołań do kcmgas” użytych do utworzenia nowego SCN można również znaleźć w widokach V$SESSTAT i V$SYSSTAT.

możemy użyć V$SESSTAT, aby znaleźć sesje, które powodują wysoki współczynnik SCN. Możemy również przetestować wpływ na liczbę SCN konkretnych działań.

na przykład, gdy wykonam select na dużym stole, który jest również używany przez inne sesje, moja sesja wykona kolejne 7 wywołań do kcmgas. Tak więc moje zapytanie spowoduje wyższy SCN. Jest to spowodowane spójnością odczytu bazy danych, która również używa SCN.

     
  1. SQL> CONNECT < user> / <pass>@<service> 
    2.  
  2. połączone. 
    3.  
  3. SQL> wybierz ses.wartość
    4.  
  4.  od v$sesstat ses
    5.  
  5.  , v$statname stat
    6.  
  6.  gdzie?statystyka#=ses.statystyka#
    7.  
  7.  i ses.Sid IN (SELECT Sid FROM v$mystat) 
    8.  
  8.  i natychmiast.name = "wywołania do kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  wartość 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL> SELECT COUNT ( * ) FROM mybigtable ;
    16.  
  16.  
    17.  
  17.  liczyć(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL> wybierz ses.wartość
    22.  
  22.  od v$sesstat ses
    23.  
  23.  , v$statname stat
    24.  
  24.  gdzie?statystyka#=ses.statystyka#
    25.  
  25.  i ses.Sid IN (SELECT Sid FROM v$mystat) 
    26.  
  26.  i natychmiast.name = "wywołania do kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  wartość 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

porównując SCN i commit rate

z V$SESSTAT możemy odpytywać statystyki dla wszystkich sesji aktualnie podłączonych do bazy danych. W ten sposób możemy znaleźć sesje, które są odpowiedzialne za wysoki wskaźnik SCN. Możemy to porównać ze współczynnikiem commit dla danej sesji.

wyniki poniższego zapytania pokazały nam, że w naszej bazie danych wysoki wskaźnik SCN był spowodowany głównie procesami w tle. Dla większości sesji użytkownika istnieje zależność pomiędzy wysokim współczynnikiem SCN A wysokim współczynnikiem commit, dla sesji w tle współczynnik commit jest zawsze pusty.

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

wniosek

pamiętaj, że istnieją ograniczenia dla SCN, więc kiedy znajdziesz ostrzeżenia w pliku alertów, musisz zbadać problem. Jeśli znajdziesz problem, powinieneś współpracować z Oracle Support. Przesyłając informacje, mogą sprawdzić, czy jest wystarczająco dużo miejsca między aktualnym a maksymalnym SCN.

problemy mogą być spowodowane przez błąd, taki jak 12371955: Gorąca Kopia zapasowa może powodować zwiększone tempo wzrostu SCN, co prowadzi do błędów ORA-600 (Doc ID 12371955.8).

jeśli chcesz znaleźć dokładny moment, w którym występuje wysoki wzrost SCN, musisz przekonwertować znaczniki czasu na SCN. Najlepsze wyniki uzyskujesz korzystając z funkcji SCN_TO_TIMESTAMP i TIMESTAMP_TO_SCN.

wysoki współczynnik commitów jest zawsze związany z procesami użytkownika, ale SCN są również związane z procesami w tle. Nawet sesje, które nie zatwierdzają, mogą mieć wpływ na SCN.

Bastiaan Bak

o autorze Bastiaan Bak

dba z ponad 15-letnim doświadczeniem. Doświadczenie w różnych branżach, z kilkoma modułami. W tym: Oracle database, Oracle RAC, Oracle EBS i PL/SQL.

więcej postów napisanych przez Bastiaan Bak

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.