undersøgelse af SCN intrinsic vækstrate

Written by on in Articles

udgivet den: 10 juli 2018 forfatter: Bastiaan Bak Kategori: IT-udvikling og drift

for et stykke tid siden havde vi en advarsel om den iboende vækst af SCN (system change number) i vores Oracle 12.2 database alert file. Denne situation opstod flere gange inden for få uger.

“advarsel: SCN iboende vækstrate har været konsekvent
højere end systemets standard 16384 per SEK. for sidste 60 minutter.
nuværende SCN iboende vækstrate er 25867 per sek., med 200fffff!
den aktuelle SCN-værdi er 46747726691, SCN Compat-værdi er 1 “

min første reaktion var, at SCN ‘ er er relateret til forpligtelser, så enten var belastningen på databasen meget høj, eller applikationslogikken skulle ændres. En anden mulighed var, at en forpligtelse blev udført efter hver opdatering i stedet for at bruge batchforpligtelser.

det viste sig at være lidt mere kompliceret end forventet. Hvor ser du ud, når du vil finde forholdet mellem SCNs og commits? Og hvor alvorlig er denne advarsel alligevel? Denne blog handler om de forskellige måder, jeg undersøgte dette problem på og identificerede den potentielle indvirkning.

Oracle Support notes

det første sted at søge information om advarsler i alert-filen er Oracle Support hjemmeside. Jeg fandt flere relaterede noter:

  • ORA-19706 og relaterede Alarmlogmeddelelser (Doc ID 1393360.1)
    denne note antyder, at den faktiske meddelelse er specifik for Databaseversion 12.2, men i ældre versioner har vi muligvis lignende advarsler, som “advarsel: SCN headroom for denne database er kun NN dage!”
    hvis du støder på en advarselslogmeddelelse som en af disse poster, anbefales det at følge instruktionerne i ID 1388639.1 og logge en serviceanmodning med Oracle support.
    bevis, der skal indsamles, når du rapporterer “high SCN rate” – problemer til Oracle Support (Doc ID 1388639.1)
  • denne note indeholder oplysninger om, hvilke oplysninger du skal levere, når du logger en serviceanmodning.
  • SYSTEMÆNDRINGSNUMMER (SCN), Headroom, sikkerhed og Patch Information (Doc ID 1376995.1)
    denne note giver flere oplysninger om brugen af SCN. Systemændringsnummeret (SCN) er en logisk, intern tidsstempel, der bruges af Oracle-databasen. SCNs bestiller hændelser, der opstår i databasen. Databasen bruger SCNs til at forespørge og spore ændringer. Når en transaktion forpligter sig, registrerer databasen et SCN for denne forpligtelse.
    der er en øvre grænse for, hvor mange SCN ‘ er en Oracle-Database kan bruge. Grænsen er i øjeblikket 281 billioner (2^48) SCN-værdier.
    da der er en øvre grænse, er det vigtigt, at en given Oracle-Database ikke løber tør for tilgængelige SCN ‘ er.
    noten forklarer også, når advarslen hæves. Oracle-databasen beregner en” ikke at overskride “grænse for antallet af SCN’ er, som en database i øjeblikket kan bruge, baseret på antallet af sekunder siden 1988 ganget med 16384. Dette sikrer, at Oracle databaser vil rationere SCNs over tid.

hvor alvorlig er denne advarsel?

advarslen hæves med en hastighed på 2^14 = 16384 SCNs per sekund i de sidste 60 minutter.
den maksimale SCN er 2^48 = 281.474.976.710.656.

med en hastighed på 16348 SCNs per sekund har vi 2^(48-14) sekunder eller 544 år for at nå det maksimale. Det burde være nok i en normal situation, men den øvre grænse på 2^48 er kun den maksimale absolutte værdi, som databasen kan gemme.
grænsen er også relateret til antallet af sekunder siden 1988. Grænsen på 2^48 er maksimum i år 2532 (1988+544). Men i 2018 er maksimumet (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

advarslen bør ikke ignoreres. Når du når grænsen, får du ora-600 fejl, men når du når den absolutte øvre grænse SCN, vil databasen bare stoppe med at arbejde.

den gode nyhed er, at advarslen i vores situation sagde, at SCN-vækstraten var 25867 per sekund i den specifikke time, så i den time kom vi lidt nærmere (25867-16384=9483) til grænsen. Vi kommer ikke tæt på grænsen hver time; den normale vækstrate er lavere end 16384.

Oracle Support

vi ringede til Oracle Support, og de fortalte os, at Oracle Development i øjeblikket arbejder på dette problem.
Oracle Support bekræftede, at SCN headroom ser godt ud. Oracle Support bemærkede et stort antal forpligtelser og foreslog at tjekke med application team for at begå ved at øge transaktionsstørrelsen.

undersøgelse med AKR

advarslen i alarmfilen fortalte os, at SCN ‘ s iboende vækstrate har været konsekvent højere end systemets standard: 16384 per sekund i de sidste 60 minutter. Hvis vi ser på en tidsramme på en time, kan en årsrapport være et godt sted at starte. Vi har konfigureret til at lave snapshots hver time.

i ÅRSREGNSKABSRAPPORTEN bemærkede jeg, at antallet af brugerforpligtelser var 210 pr. Ja, det er mange forpligtelser, men det er ikke så forskelligt fra den normale belastning af denne database. Og hvis en forpligtelse er relateret til en SCN, er den også meget lavere end 16384 pr.

ÅRSREGNSKABSRAPPORTEN indeholdt også et ADDM-fund: venter på begivenhed “logfilsynkronisering” under udførelse af COMMIT og ROLLBACK-operationer brugte betydelig databasetid. Undersøge ansøgning logik for mulig reduktion i antallet af begå operationer ved at øge størrelsen af transaktioner.
denne reduktion af forpligtelserne i ADDM-fundet blev også foreslået af Oracle Support. Fra mit synspunkt var det dog ikke så højt.

kortere tidsramme

da det ikke hjalp mig med at finde årsagen, var jeg nødt til at undersøge en kortere tidsramme. Jeg ville vide en mere specifik tidsramme, så jeg kunne oprette en ASH-rapport. Standard for aske er 15 minutter.
så den næste udfordring var at finde den 15 minutters Tidsramme, hvor SCN-vækstraten var den højeste.
Doc ID 1388639.1 foreslået at forespørge v$archived_log. Denne visning indeholder oplysninger om alle logkontakterne på databasen, herunder et tidsstempel og SCN. Selvom du kunne kortlægge tidsstempler til SCNs, er det ikke rigtig bedre end den årlige rapport. Vi sidder stadig fast ved tilfældige tidsstempler; i dette tilfælde tidsstemplet for logkontakten.

brug af funktionen timestamp_to_scn

en bedre måde er at bruge funktionen timestamp_to_scn. Denne funktion returnerer et SCN baseret på et tidsstempel, f. eks. det aktuelle tidsstempel:

     
  1.  
  2.  
    3.  
  3. TIDSSTEMPEL_TO_SCN (SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7. KKL> 
    8.

det næste trin var at lave en liste over tidsstempler sammen med den matchende SCN og den matchende SCN øvre grænse, baseret på antallet af sekunder siden 1988 ganget med 16.384.

dette viser tidsstempler og SCNs for den sidste dag:

     
  1.  vælg sysdate - (rækkenum/24) datetimestamp
    2.  
  2.  , tidsstempel_to_scn (sysdate - (rækkenum/24)) SCN
    3.  
  3.  , ((sysdate - (rækkenum / 24)) - to_date ('01-01-1988', 'DD-MM-ÅÅÅÅ' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  af dual
    6.  
  6.  Opret forbindelse til Ronny <= 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ækker valgt. 
    29.

0,57% af den nuværende øvre grænse.

find den bedste SCN-Sats

baseret på denne ide oprettede jeg en forespørgsel, der giver mig 15 minutters tidsramme med højeste vækst i SCNs i de sidste 3 dage.

hvert minut starter en ny tidsramme, og fordi vi har 1440 minutter om dagen, har vi 4320 tidsrammer at undersøge. For hver af dem skal vi beregne væksten af SCN inden for den 15 minutters tidsramme.

vi ønsker kun at vise de bedste resultater, i dette tilfælde kun tidsrammerne med en hastighed på over 14000 pr.

     
  1.  ALTER SESSION SET nls_date_format= 'MM / DD / åå HH24: MI' ;
    2.  
  2.  
    3.  
  3.  med datelist som 
    4.  
  4.  ( vælg sysdate - (rækkenum / 1440) - (15/1440) starttid -- 15 minutters interval 
    5.  
  5.  , sysdate - (rækkenum/1440) sluttidspunkt
    6.  
  6.  af dual
    7.  
  7.  Opret forbindelse til Ronny <= (3*1440) -- 3 dage historie 
    8.  
  8. )
    9.  
  9.  vælg starttid
    10.  
  10.  , endtime
    11.  
  11.  , tidsstempel_to_scn (sluttid) - tidsstempel_to_scn (starttid) SCN vækst
    12.  
  12.  , runde ((tidsstempel_to_scn (sluttid) - tidsstempel_to_scn (starttid)) / 
    13.  
  13.  (((24*60*60)*(endtime-starttime)))) scnrate
    14.  
  14.  fra datelist
    15.  
  15.  hvor runde ((tidsstempel_to_scn (sluttid) - tidsstempel_to_scn(starttid)) / 
    16.  
  16.  (((24*60*60)*(sluttid-starttid )))) >= 14000 
    17.  
  17.  Bestil af 4 DESC 
    18.  
  18. /
    19.  
     
  1. starttid sluttid SCNVÆKST 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.

så nu har vi fundet de (undertiden overlappende) 15 minutters tidsrammer med den højeste SCN-hastighed (SCN-vækst pr. Og selv i disse tidsrammer er SCN-satsen stadig under 16384. Ingen advarsler i varslingsfilen i denne uge….

kørsel af ASH-rapporten

det datoformat, jeg brugte i forespørgslen ovenfor, er det samme som brugt af ASH-rapporten, så du kan bare kopiere/indsætte starttidspunktet. For varigheden indtaster vi 15 minutter.

     
  1.  > @@ $ ORACLE_HOME/rdbms/admin / ashrpt.KKL
    2.  
  2.  
    3.  
  3. ASH prøver i denne arbejdsbyrde Repository skema
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. ældste ASKEPRØVE tilgængelig: 01-Jul-18 00:00:01 
    7.  
  7. seneste ASKEPRØVE tilgængelig: 09-Jul-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. Angiv tidsrammen for at generere ASH-rapporten
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. indtast starttidspunkt for rapport:
    13.  
  13.  
    14.  
  14. -- gyldige inputformater:
    15.  
  15. -- for at angive absolut starttidspunkt:
    16.  
  16. -- ] HH24: MI
    17.  
  17. -- eksempler: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- for at angive relativ starttid: (start med ' - ' tegn)
    22.  
  22. -- -MI
    23.  
  23. -- eksempler: -1:15 (SYSDATE - 1 time 15 minutter)
    24.  
  24. -- -25 (SYSDATE - 25 minutter)
    25.  
  25.  
    26.  
  26. standard til -15 minutter
    27.  
  27. indtast værdi for begin_time: 07/06/18 18:09
    28.  
  28. rapport BEGYNDELSESTID angivet: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. indtast varighed i minutter startende fra starttidspunktet:
    31.  
  31. standardindstillinger til SYSDATE-begin_time
    32.  
  32. tryk på Enter for at analysere indtil det aktuelle tidspunkt 
    33.  
  33. indtast værdi for varighed: 15 
    34.  
  34. rapport varighed angivet: 15 
    35.  
  35.  
    36.  
  36.  brug af 06-Jul-18 18:09:00 som rapport begynder tid 
    37.  
  37.  brug af 06-Jul-18 18:24:00 som rapportens sluttidspunkt 
    38.  
  38.  
    39.  
  39. Angiv rapportens navn
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. standardrapportfilnavnet er ashrpt_1_0706_1824.HTML. For at bruge dette navn, 
    42.  
  42. tryk på < return> for at fortsætte, ellers indtast et alternativ. 
    43.  
  43. indtast værdi for report_name:
    44.  
  44.  
    45.  
  45.  brug af rapportnavnet ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47. oversigt over alle brugerinput 
    48.  
  48. -------------------------
    49.  
  49. Format: HTML
    50.  
  50. DB Id : 2019395491 
    51.  
  51. Inst num : 1 
    52.  
  52.  BEGYNDELSESTID: 06-Jul-18 18:09:00
    53.  
  53.  sluttidspunkt: 06-Jul-18 18:24:00
    54.  
  54. Slot bredde: standard 
    55.  
  55. rapporter mål : 0 
    56.  
  56. rapportens navn : ashrpt_1_0706_1824.html
    57.

rapporten viste os ikke meget information om den aktuelle SCN, men den har nogle oplysninger om vækstraten, hvis du ved, hvor du kan finde den.

under “Instance Activity Stats” kan du finde antallet af “opkald til kcmgas”. I Oracle-dokumentationen beskrives dette som”antallet af opkald til rutinemæssige kcmgas for at få en ny SCN”.

værdien af disse opkald pr.sekund i ÅRSREGNSKABSRAPPORTEN er meget tæt på SCN-satsen som beregnet med funktionen tidsstempel_to_scn.

v$SESSTAT-visning

antallet af “opkald til kcmgas”, der bruges til at oprette en ny SCN, kan også findes i visningerne V$SESSTAT og V$SYSSTAT.

vi kan bruge V$SESSTAT til at finde de sessioner, der forårsager en høj SCN-Sats. Vi kan også teste virkningen på SCN-antallet af specifikke handlinger.

for eksempel, når jeg vælger på et stort bord, der også bruges af andre sessioner, vil min session foretage yderligere 7 opkald til kcmgas. Så min forespørgsel vil medføre en højere SCN. Dette skyldes læsekonsistensen i databasen, der også bruger en SCN.

     
  1.  
  2. forbundet. 
    3.  
  3.  
  4.  fra V $ sesstat ses
    5.  
  5.  , v$statname stat
    6.  
  6.  hvor stat.statistik# = ses.statistik#
    7.  
  7.  og ses.sid IN (Vælg sid fra v$mystat) 
    8.  
  8.  og stat.name = 'opkald til kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  værdi 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. 

     
  16.  
    17.  
  17.  tæller(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21.  
  22.  fra V $ sesstat ses
    23.  
  23.  , v$statname stat
    24.  
  24.  hvor stat.statistik# = ses.statistik#
    25.  
  25.  og ses.sid IN (Vælg sid fra v$mystat) 
    26.  
  26.  og stat.name = 'opkald til kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  værdi 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. KKL> 
    34.

sammenligning af SCN og commit rate

med V$SESSTAT kan vi forespørge statistikken for alle sessioner, der i øjeblikket er forbundet til databasen. På denne måde kan vi finde sessioner, der er ansvarlige for en høj SCN-Sats. Vi kan sammenligne dette med forpligtelsesfrekvensen for den session.

resultaterne af forespørgslen nedenfor viste os, at den høje SCN-hastighed i vores database hovedsageligt var forårsaget af baggrundsprocesser. For de fleste brugersessioner er der en sammenhæng mellem en høj SCN-sats og en høj forpligtelsesrate, for baggrundssessioner er forpligtelsesfrekvensen altid tom.

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

konklusion

Vær opmærksom på, at der er grænser for SCN, så når du finder advarsler i alarmfilen, skal du undersøge problemet. Hvis du finder et problem, skal du arbejde med Oracle Support. Ved at uploade oplysninger kan de kontrollere, om der er plads nok mellem den aktuelle og maksimale SCN.

problemer kan være forårsaget af en fejl, som 12371955: Hot Backup kan forårsage øget SCN-vækstrate, der fører til ORA-600-fejl (Doc ID 12371955.8).

hvis du vil finde det nøjagtige øjeblik, der er en høj vækst af SCNs, skal du konvertere tidsstempler til SCNs. Du får de bedste resultater ved hjælp af funktionerne SCN_TO_TIMESTAMP og TIMESTAMP_TO_SCN.

en høj forpligtelsesrate er altid relateret til brugerprocesser, men SCN ' er er også relateret til baggrundsprocesser. Selv sessioner, der ikke forpligter sig, kan have indflydelse på SCN.

Bastiaan Bak

om forfatteren Bastiaan Bak

DBA med over 15 års erfaring. Erfaring i forskellige brancher, med flere moduler. Herunder: Oracle database, Oracle RAC og Oracle EBS.

flere indlæg af Bastiaan Bak