investigarea ratei de creștere intrinsecă SCN

Written by on in Articles

publicat la: 10 iulie 2018 autor: Bastiaan Bak Categorie: dezvoltare și operațiuni IT

cu ceva timp în urmă, am avut un avertisment cu privire la creșterea intrinsecă a SCN (numărul de schimbare a sistemului) în fișierul nostru de alertă pentru baza de date Oracle 12.2. Această situație a avut loc de mai multe ori în câteva săptămâni.

„avertisment: rata de creștere intrinsecă SCN a fost în mod constant
mai mare decât implicit sistem 16384 pe sec. pentru ultimele 60 de minute.
rata actuală de creștere intrinsecă SCN este de 25867 pe sec., zas 200fffff!
valoarea SCN curentă este 46747726691, valoarea SCN Compat este 1″

reacția mea inițială a fost că SCN-urile sunt legate de comiteri, deci fie încărcarea bazei de date a fost foarte mare, fie logica aplicației ar trebui schimbată. O altă posibilitate a fost că o comitere a fost făcută după fiecare actualizare, în loc să se utilizeze comiteri batch.

s-a dovedit a fi puțin mai complicat decât mă așteptam. Unde te uiți atunci când doriți să găsiți relația dintre SCNs și comite? Și cât de grav este acest avertisment oricum? Acest blog va fi despre diferitele moduri în care am investigat această problemă și am identificat impactul potențial.

Oracle Support Note

primul loc pentru a căuta informații despre avertismente în fișierul de alertă este site-ul Web Oracle Support. Am găsit mai multe note conexe:

  • ORA-19706 și mesaje de jurnal de alertă conexe (Doc ID 1393360.1)
    această notă sugerează că mesajul real este specific versiunii bazei de date 12.2, dar în versiunile mai vechi este posibil să avem avertismente similare, cum ar fi „avertisment: spațiul SCN pentru această bază de date este doar NN zile!”
    Dacă întâmpinați un mesaj de jurnal de alertă ca oricare dintre aceste intrări, vi se recomandă să urmați instrucțiunile din ID 1388639.1 și să înregistrați o solicitare de serviciu cu Oracle support.
    dovezi de colectat atunci când raportați probleme cu „rata SCN ridicată” către Oracle Support (Doc ID 1388639.1)
  • această notă oferă informații despre informațiile pe care ar trebui să le furnizați atunci când înregistrați o solicitare de serviciu.
  • număr schimbare sistem (SCN), spațiu pentru cap, securitate și informații despre corecții (Doc ID 1376995.1)
    această notă oferă mai multe informații despre utilizarea SCN. Numărul de modificare a sistemului (SCN) este o marcă de timp internă logică utilizată de baza de date Oracle. SCNs evenimente de ordine care au loc în baza de date. Baza de date utilizează SCN-uri pentru a interoga și urmări modificările. Când o tranzacție se angajează, baza de date înregistrează un SCN pentru această comitere.
    există o limită superioară a numărului de SCN – uri pe care le poate utiliza o bază de date Oracle. Limita este în prezent 281 trilioane (2^48) valori SCN.
    având în vedere că există o limită superioară, este important ca orice bază de date Oracle dată să nu rămână fără SCN-uri disponibile.
    nota explică, de asemenea, când avertismentul este ridicat. Baza de date Oracle calculează o limită” să nu depășească ” pentru numărul de SCN-uri pe care o bază de date le poate utiliza în prezent, pe baza numărului de secunde din 1988 înmulțit cu 16384. Acest lucru asigură că bazele de date Oracle vor raționaliza SCN-urile în timp.

cât de gravă este această avertizare?

avertizarea este ridicată cu o rată de 2^14 = 16384 SCNs pe secundă în ultimele 60 de minute.
SCN maxim este 2^48 = 281.474.976.710.656.

la o rată de 16348 SCNs pe secundă, vom avea 2^(48-14) secunde sau 544 de ani pentru a atinge acest maxim. Acest lucru ar trebui să fie suficient într-o situație normală, dar limita superioară a 2^48 este doar valoarea absolută maximă pe care o poate stoca baza de date.
limita este, de asemenea, legată de numărul de secunde din 1988. Limita de 2^48 este maximă în anul 2532 (1988+544). Dar în 2018 maximul este (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

avertismentul nu trebuie ignorat. Când atingeți limita, veți primi erori ora-600, dar când atingeți limita superioară absolută SCN, baza de date va înceta să funcționeze.

vestea bună este că, în situația noastră, avertismentul a spus că rata de creștere a SCN a fost de 25867 pe secundă în acea oră specifică, așa că în acea oră ne-am apropiat puțin (25867-16384=9483) de limită. Nu ne apropiem de limită în fiecare oră; rata normală de creștere este mai mică decât 16384.

Oracle Support

am sunat la Oracle Support și ne-au spus că Oracle Development lucrează în prezent la această problemă.
suportul Oracle a confirmat că spațiul de trecere SCN arată bine. Pe baza raportului AWR, Oracle Support a observat un număr mare de comiteri și a sugerat să se consulte cu echipa de aplicații pentru a se angaja prin creșterea dimensiunii tranzacției.

investigație cu AWR

avertismentul din fișierul de alertă ne-a spus că rata de creștere intrinsecă SCN a fost în mod constant mai mare decât implicit sistem: 16384 pe secundă pentru ultimele 60 de minute. Dacă ne uităm la un interval de timp de o oră, un raport AWR ar putea fi un loc bun pentru a începe. Avem AWR configurat pentru a face instantanee la fiecare oră.

în raportul AWR, am observat că numărul de comiteri ale utilizatorilor a fost de 210 pe secundă. Da, sunt multe angajamente, dar nu este atât de diferit de încărcarea normală a acestei baze de date. Și dacă o comitere este legată de un SCN, este, de asemenea, mult mai mică decât 16384 pe secundă.

raportul AWR conținea, de asemenea, o constatare ADDM: Waits on event „Log file sync” în timp ce efectua operațiuni de comitere și ROLLBACK consumau un timp semnificativ al bazei de date. Investigați logica aplicației pentru o posibilă reducere a numărului de operațiuni de comitere prin creșterea dimensiunii tranzacțiilor.
această reducere a comiterilor în constatarea ADDM a fost sugerată și de Oracle Support. Din punctul meu de vedere, nu a fost chiar atât de mare.

interval de timp mai scurt

deoarece AWR nu mă ajuta să găsesc cauza, trebuia să investighez un interval de timp mai scurt. Am vrut să știu un interval de timp mai specific pentru a putea crea un raport ASH. Valoarea implicită pentru ASH este de 15 minute.
Deci, următoarea provocare a fost să găsim intervalul de timp de 15 minute în care rata de creștere a SCN a fost cea mai mare.
Doc ID 1388639.1 a sugerat interogarea v$archived_log. Această vizualizare conține informații despre toate comutatoarele de jurnal din Baza de date, inclusiv o marcă de timp și SCN. Deși ați putea mapa marcajele de timp la SCNs, nu este cu adevărat mai bun decât raportul AWR. Suntem încă blocați la marcajele de timp aleatorii; în acest caz, marca de timp a comutatorului de jurnal.

utilizarea funcției timestamp_to_scn

o modalitate mai bună este să utilizați funcția timestamp_to_scn. Această funcție returnează un SCN bazat pe o marcă de timp, cum ar fi marca de timp curentă:

     
  1. SQL > selectați timestamp_to_scn (sysdate) din dual ;
    2.  
  2.  
    3.  
  3. TIMESTAMP_TO_SCN(SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7. SQL> 
    8.

următorul pas a fost să faceți o listă a marcajelor de timp împreună cu limita superioară SCN potrivită și SCN potrivită, pe baza numărului de secunde din 1988 înmulțit cu 16.384.

aceasta arată marcajele de timp și SCN-urile pentru ultima zi:

     
  1.  selectați sysdate - (rownum/24) datetimestamp
    2.  
  2.  , timestamp_to_scn(sysdate - (rownum / 24)) SCN
    3.  
  3.  , ((data de sistem - (rownum / 24)) - la_data ('01-01-1988', 'ZZ-LL-AAAA' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  de la dual
    6.  
  6.  conectează-te prin 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 rânduri selectate. 
    29.

actualul SCN este de aproximativ 0,57% din limita superioară actuală.

găsirea ratei SCN de top

pe baza acestei idei am creat o interogare care îmi dă intervalul de timp de 15 minute cu cea mai mare creștere a SCNs în ultimele 3 zile.

în fiecare minut începe un nou interval de timp și, deoarece avem 1440 de minute într-o zi, avem 4320 de intervale de timp pentru a investiga. Pentru fiecare dintre ele trebuie să calculăm creșterea SCN în acel interval de timp de 15 minute.

vrem doar să afișăm rezultatele de top, în acest caz doar intervalele de timp cu o rată de peste 14000 pe secundă.

     
  1.  ALTER SESSION SET nls_date_format= 'LL/ZZ / AA HH24: MI' ;
    2.  
  2.  
    3.  
  3.  cu lista de date ca 
    4.  
  4.  ( selectați sysdate- (rownum / 1440)- (15/1440) starttime -- interval de 15 minute 
    5.  
  5.  , sysdate - (rownum / 1440) sfârșitul timpului
    6.  
  6.  de la dual
    7.  
  7.  conectează-te prin rownum <= (3*1440) -- 3 istoria zilelor 
    8.  
  8. )
    9.  
  9.  Selectați Ora de începere
    10.  
  10.  , endtime
    11.  
  11.  , timestamp_to_scn (endtime) - timestamp_to_scn (starttime) scngrowth
    12.  
  12.  , round ((timestamp_to_scn (endtime) - timestamp_to_scn(starttime)) / 
    13.  
  13.  (((24*60*60)*(endtime-starttime)))) scnrate
    14.  
  14.  din lista de date
    15.  
  15.  unde round ((timestamp_to_scn (endtime) - timestamp_to_scn(starttime)) / 
    16.  
  16.  (((24*60*60)*(endtime-starttime )))) >= 14000 
    17.  
  17.  comandă de 4 DESC 
    18.  
  18. /
    19.  
     
  1. STARTTIME ENDTIME SCNGROWTH 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.

Deci, acum am găsit (uneori suprapuse) intervalele de timp de 15 minute cu cea mai mare rată SCN (creștere SCN pe secundă) pentru ultimele 3 zile. Și chiar și în acele perioade de timp rata SCN este încă sub 16384. Nu există avertismente în fișierul de alertă în această săptămână….

rularea raportului ASH

formatul de dată pe care l-am folosit în interogarea de mai sus este același cu cel utilizat de raportul ASH, astfel încât să puteți copia/lipi ora de începere. Pentru durata introducem 15 minute.

     
  1. SQL > @@ $ ORACLE_HOME / rdbms/admin / ashrpt.sql
    2.  
  2.  
    3.  
  3. eșantioane de cenușă în această schemă de depozitare a volumului de lucru
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. cea mai veche probă de cenușă disponibilă: 01-Jul-18 00:00:01 
    7.  
  7. ultima probă de cenușă disponibilă: 09-Jul-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. specificați intervalul de timp pentru generarea raportului ASH
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. introduceți ora de începere a raportului:
    13.  
  13.  
    14.  
  14. -- formate de intrare valide:
    15.  
  15. -- pentru a specifica ora de începere absolută:
    16.  
  16. -- ] HH24: MI
    17.  
  17. -- Exemple: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- pentru a specifica timpul de începere relativ: (începeți cu semnul' -')
    22.  
  22. -- - MI
    23.  
  23. -- Exemple: -1:15 (SYSDATE - 1 oră 15 minute)
    24.  
  24. -- -25 (SYSDATE - 25 minute)
    25.  
  25.  
    26.  
  26. implicit la -15 minute
    27.  
  27. introduceți valoarea pentru begin_time: 07/06/18 18:09
    28.  
  28. raport începe timp specificat: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. introduceți durata în minute începând de la ora de începere:
    31.  
  31. implicit la SYSDATE-begin_time
    32.  
  32. apăsați Enter pentru a analiza până la ora curentă
    33.  
  33. introduceți valoarea pentru durată: 15 
    34.  
  34. durata raportului specificată: 15 
    35.  
  35.  
    36.  
  36.  utilizarea 06-Jul-18 18: 09: 00 ca raport începe timp 
    37.  
  37.  utilizarea 06-Jul-18 18: 24: 00 ca raport timp de încheiere 
    38.  
  38.  
    39.  
  39. specificați numele raportului
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. numele implicit al fișierului de raport este ashrpt_1_0706_1824.html. Pentru a utiliza acest nume, 
    42.  
  42. apăsați <return > pentru a continua, altfel introduceți o alternativă. 
    43.  
  43. introduceți valoarea pentru report_name:
    44.  
  44.  
    45.  
  45.  folosind numele raportului ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47. rezumatul tuturor intrărilor utilizatorului
    48.  
  48. -------------------------
    49.  
  49. Format: HTML
    50.  
  50. ID DB : 2019395491 
    51.  
  51. Inst num : 1 
    52.  
  52.  ora de începere: 06-iul-18 18:09:00
    53.  
  53.  ora de încheiere: 06-iul-18 18:24:00
    54.  
  54. lățimea slotului: implicit 
    55.  
  55. obiectivele raportului : 0 
    56.  
  56. numele raportului : ashrpt_1_0706_1824.html
    57.

găsirea SCN în AWR

raportul AWR nu ne-a arătat prea multe informații despre SCN actual, dar are câteva informații despre rata de creștere, dacă știți unde să o găsiți.

sub „statistici de activitate instanță” puteți găsi numărul de „apeluri către kcmga”. În documentația Oracle acest lucru este descris ca”numărul de apeluri către kcmga de rutină pentru a obține un nou SCN”.

valoarea acestor apeluri pe secundă în raportul AWR este foarte apropiată de rata SCN calculată cu funcția timestamp_to_scn.

v$SESSTAT view

Numărul de „apeluri către kcmga” utilizat pentru a crea un nou SCN poate fi găsit și în vizualizările V$SESSTAT și V$SYSSTAT.

putem folosi V$SESSTAT pentru a găsi sesiunile care provoacă o rată SCN ridicată. De asemenea, putem testa impactul asupra numărului SCN de acțiuni specifice.

de exemplu, când fac o selecție pe o masă mare care este folosită și de alte sesiuni, sesiunea mea va face încă 7 apeluri către kcmga. Deci, interogarea mea va provoca un SCN mai mare. Acest lucru este cauzat de consistența de citire a bazei de date, care utilizează, de asemenea, un SCN.

     
  1. SQL > conectați< utilizator > / <trece >@< serviciu> 
    2.  
  2. conectat. 
    3.  
  3. SQL> selectați ses.valoare
    4.  
  4.  de la v$sesstat ses
    5.  
  5.  , v$statname stat
    6.  
  6.  unde stat.statistică#=ses.statistici#
    7.  
  7.  și ses.SID IN (Selectați sid din v$mystat) 
    8.  
  8.  și stat.name = 'apeluri către kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  valoare 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL > selectați COUNT (*) din mybigtable ;
    16.  
  16.  
    17.  
  17.  conte(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL> selectați ses.valoare
    22.  
  22.  de la v$sesstat ses
    23.  
  23.  , v$statname stat
    24.  
  24.  unde stat.statistică#=ses.statistici#
    25.  
  25.  și ses.SID IN (Selectați sid din v$mystat) 
    26.  
  26.  și stat.name = 'apeluri către kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  valoare 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

comparând rata SCN și commit

cu V$SESSTAT putem interoga statisticile pentru toate sesiunile conectate în prezent la baza de date. În acest fel putem găsi sesiuni care sunt responsabile pentru o rată SCN ridicată. Putem compara acest lucru cu rata de comitere pentru acea sesiune.

rezultatele interogării de mai jos ne-au arătat că în Baza noastră de date rata ridicată a SCN a fost cauzată în principal de procesele de fundal. Pentru majoritatea sesiunilor de utilizator există o relație între o rată SCN ridicată și o rată ridicată de comitere, pentru sesiunile de fundal rata de comitere este întotdeauna goală.

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

concluzie

fiți conștienți de faptul că există limite pentru SCN, deci atunci când găsiți avertismente în fișierul de alertă, trebuie să investigați problema. Dacă găsiți o problemă, ar trebui să lucrați cu Oracle Support. Prin încărcarea informațiilor pot verifica dacă există suficient spațiu între SCN curent și maxim.

problemele pot fi cauzate de un bug, cum ar fi 12371955: Hot Backup poate provoca creșterea ratei de creștere SCN care duce la erori ORA-600 (Doc ID 12371955.8).

dacă doriți să găsiți momentul exact există o creștere mare de SCNs aveți nevoie pentru a converti marcajele de timp pentru a SCNs. Obțineți cele mai bune rezultate folosind funcțiile SCN_TO_TIMESTAMP și TIMESTAMP_TO_SCN.

o rată ridicată de comitere este întotdeauna legată de procesele utilizatorului, dar SCN-urile sunt, de asemenea, legate de procesele de fundal. Chiar și sesiunile care nu se angajează pot avea un impact asupra SCN.

Bastiaan Bak

despre autorul Bastiaan Bak

DBA cu peste 15 ani de experiență. Experiență în diverse ramuri, cu mai multe module. Inclusiv: Oracle database, Oracle RAC, Oracle EBS și PL/SQL.

mai multe postări de Bastiaan Bak

Lasă un răspuns

Adresa ta de email nu va fi publicată.