Undersøkelse AV SCN intrinsic growth rate

Written by on in Articles

Publisert på: 10 juli 2018 Forfatter: Bastiaan Bak Kategori: IT development and operations

for en stund siden hadde vi en advarsel om den indre veksten AV SCN (system change number) i vår oracle 12.2 database alert file. Denne situasjonen skjedde flere ganger innen få uker.

«Advarsel: scn intrinsic vekstraten har vært konsekvent
høyere enn system standard 16384 per sek.for siste 60 minutter.
Nåværende SCN iboende vekst er 25867 per sek., zas 200fffff!
Den Nåværende SCN-verdien er 46747726691, SCN Compat-verdien er 1 »

min første reaksjon var At Scn er relatert til inger, så enten belastningen på databasen var veldig høy eller applikasjonslogikken bør endres. En annen mulighet var at en forpliktelse ble gjort etter hver oppdatering, i stedet for å bruke batch-forpliktelser.

det viste seg å være litt mer komplisert enn jeg forventet. Hvor ser du når du vil finne forholdet mellom SCNs og commits? Hvor alvorlig er denne advarselen? Denne bloggen kommer til å være om de ulike måtene jeg undersøkte dette problemet og identifisert den potensielle effekten.

Oracle Support notes

det første stedet å lete etter informasjon om advarsler i varselfilen er Oracle Support website. Jeg fant flere relaterte notater:

  • ORA-19706 Og Relaterte Varslingsloggmeldinger (Doc ID 1393360.1)
    dette notatet antyder at den faktiske meldingen er spesifikk for databaseversjon 12.2, men i eldre versjoner kan vi ha lignende advarsler, som «Advarsel: SCN-takhøyde for denne databasen er BARE NN dager!»
    hvis du får en varslingsloggmelding som noen av disse oppføringene, anbefales det at DU følger instruksjonene I ID 1388639.1 og logger En Serviceforespørsel med oracle support.
    Bevis som skal samles inn når du rapporterer problemer med «høy SCN-rate» Til Oracle Support (Doc ID 1388639.1)
  • dette notatet gir informasjon om hvilken informasjon du bør levere når du logger en tjenesteforespørsel.
  • SYSTEM Change Number (Scn), Takhøyde, Sikkerhet Og Patch Informasjon (Doc ID 1376995.1)
    dette notatet gir mer informasjon om BRUKEN AV SCN. System change number (scn) er et logisk, internt tidsstempel som Brukes Av Oracle-Databasen. SCNs bestille hendelser som oppstår i databasen. Databasen bruker SCNs til å spørre og spore endringer. Når en transaksjon forplikter, registrerer databasen EN SCN for denne forpliktelsen.
    det er en øvre grense for hvor Mange Scn-Er En Oracle-Database kan bruke. Grensen er for tiden 281 billioner (2^48) SCN-verdier.
    Gitt at det er en øvre grense, er det viktig at en gitt Oracle-Database ikke går tom for tilgjengelige Scn-Er.
    notatet forklarer også når advarselen er hevet. Oracle-Databasen beregner en» ikke overskride » grense for antall SCNs en database kan bruke, basert på antall sekunder siden 1988 multiplisert med 16384. Å gjøre dette sikrer At Oracle Databaser vil rasjonere SCNs over tid.

hvor alvorlig er denne advarselen?

advarselen økes med en hastighet på 2^14 = 16384 Scn per sekund i de siste 60 minuttene.
maksimal SCN er 2^48 = 281.474.976.710.656.

med en hastighet på 16348 Scn per sekund, vil vi ha 2^(48-14) sekunder, eller 544 år for å nå det maksimale. Det burde være nok i en normal situasjon, men den øvre grensen på 2^48 er bare den maksimale absoluttverdien databasen kan lagre.
grensen er også relatert til antall sekunder siden 1988. Grensen 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.

advarselen bør ikke ignoreres. Når du når grensen, får du ora-600-feil, men når DU når den absolutte øvre grensen SCN, vil databasen bare slutte å fungere.

den gode nyheten er at i vår situasjon sa advarselen AT scn-vekstraten var 25867 per sekund i den bestemte timen, så i den timen kom vi litt nærmere (25867-16384=9483) til grensen. Vi kommer ikke nær grensen hver time; den normale vekstraten er lavere enn 16384.

Oracle Support

vi kalte Oracle Support, Og De fortalte Oss At Oracle Development for tiden jobber med dette problemet.
Oracle Support bekreftet AT SCN takhøyde ser bra ut. Basert PÅ AWR-rapporten oppdaget Oracle Support et høyt antall forpliktelser og foreslo å sjekke med application team for å begå ved å øke transaksjonsstørrelsen.

Undersøkelse med AWR

advarselen i varselfilen fortalte oss at SCN – vekstraten har vært konsekvent høyere enn systemstandard: 16384 per sekund i de siste 60 minuttene. Hvis VI ser på en tidsramme på en time, KAN EN AWR-rapport være et godt sted å starte. VI har AWR konfigurert til å lage øyeblikksbilder hver time.

I AWR-rapporten la jeg merke til at antall brukerforpliktelser var 210 per sekund. Ja, det er mange forpliktelser, men det er ikke så forskjellig fra den normale belastningen i denne databasen. Og hvis en forpliktelse er relatert TIL EN SCN, er den også mye lavere enn 16384 per sekund.

AWR-rapporten inneholdt OGSÅ ET ADDM-funn: Venter på hendelsen «loggfilsynkronisering» mens DU utførte COMMIT og ROLLBACK-operasjoner, brukte betydelig databasetid. Undersøke programmet logikk for mulig reduksjon i ANTALL FORPLIKTE operasjoner ved å øke størrelsen på transaksjoner.
denne reduksjonen av forpliktelsene i ADDM-funnet ble også foreslått Av Oracle Support. Fra mitt synspunkt var det egentlig ikke så høyt skjønt.

Kortere tidsramme

FORDI AWR ikke hjalp meg med å finne årsaken, trengte jeg å undersøke en kortere tidsramme. Jeg ønsket å vite en mer spesifikk tidsramme slik at jeg kunne lage EN ASH rapport. Standard FOR ASKE er 15 minutter.
så neste utfordring var å finne den 15 minutters tidsrammen DER SCN-vekstraten var høyest.
Doc ID 1388639.1 foreslått å spørre v$archived_log. Denne visningen har informasjon om alle loggen brytere på databasen, inkludert et tidsstempel OG SCN. Selv om du kan kartlegge tidsstempler Til SCNs, er det egentlig ikke bedre enn AWR-rapporten. Vi er fortsatt fast på tilfeldige tidsstempler; i dette tilfellet tidsstempelet til logswitch.

bruk av timestamp_to_scn-funksjonen

en bedre måte er å bruke funksjonen timestamp_to_scn. Denne funksjonen returnerer EN SCN basert på et tidsstempel, som gjeldende tidsstempel:

     
  1. SQL > VELG tidsstamp_to_scn(sysdate) fra dual ;
    2.  
  2.  
    3.  
  3. TIMESTAMP_TO_SCN (SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7. SQL> 
    8.

Det neste trinnet var å lage en liste over tidsstempler sammen med matchende SCN og matchende scn øvre grense, basert på antall sekunder siden 1988 multiplisert med 16,384.

dette viser tidsstempler og Scn for den siste dagen:

     
  1.  VELG sysdate - (rownum/24) datetimestamp
    2.  
  2.  , tidsstempel_to_scn (sysdate - (rownum/24)) SCN
    3.  
  3.  , ((sysdate - (rownum/24)) - to_date ('01-01-1988', 'DD-MM-ÅÅÅÅ' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  FRA dual
    6.  
  6.  KOBLE av 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 rader valgt. 
    29.

den nåværende SCN er omtrent 0,57% av dagens øvre grense.

Finne toppen SCN rate

Basert på denne ideen jeg opprettet en spørring som gir meg 15 minutters tidsramme med høyest vekst I SCNs i de siste 3 dagene.

hvert minutt starter en ny tidsramme, og fordi vi har 1440 minutter på en dag, har vi 4320 tidsrammer å undersøke. For hver AV dem må vi beregne veksten AV SCN innen den 15 minutters tidsrammen.

Vi vil bare vise de beste resultatene, i dette tilfellet bare tidsrammer med en hastighet på over 14000 per sekund.

     
  1.  ENDRE SESJON SETT nls_date_format='MM/DD/ÅÅ HH24:MI' ;
    2.  
  2.  
    3.  
  3.  MED datelist AS 
    4.  
  4.  ( VELG sysdate - (rownum/1440) - (15/1440) starttid - 15 minutters intervall 
    5.  
  5.  , sysdate - (rownum / 1440) endtime
    6.  
  6.  FRA dual
    7.  
  7.  KOBLE av rownum <= (3*1440) -- 3 dager historie 
    8.  
  8. )
    9.  
  9.  VELG starttid
    10.  
  10.  , endtime
    11.  
  11.  , timestamp_to_scn(endtime) - timestamp_to_scn (starttime) scngrowth
    12.  
  12.  , runde ((timestamp_to_scn (endtime) - timestamp_to_scn (starttime)) / 
    13.  
  13.  (((24*60*60)*(endtime-starttime)))) scnrate
    14.  
  14.  FRA datelist
    15.  
  15.  HVOR runde ((timestamp_to_scn (endtime) - timestamp_to_scn (starttime)) / 
    16.  
  16.  (((24*60*60)*(endtime-starttime )))) >= 14000 
    17.  
  17.  BESTILL ETTER 4 SYNKENDE 
    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.

Så nå har vi funnet (noen ganger overlappende) 15 minutters tidsrammer med høyest SCN-hastighet (SCN-vekst per sekund) for de siste 3-dagene. OG selv i disse tidsrammer ER SCN-frekvensen fortsatt under 16384. Ingen advarsler i varselfilen denne uken….

Kjører ASH-rapporten

datoformatet jeg brukte i spørringen ovenfor, er det samme som BRUKES AV ASH-rapporten, så du kan bare kopiere / lime inn starttidspunktet. For varigheten går vi inn i 15 minutter.

     
  1. SQL > @ @ $ ORACLE_HOME / rdbms / admin / ashrpt.sql
    2.  
  2.  
    3.  
  3. ASKEPRØVER i Dette Workload Repository-skjemaet
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. Eldste ASKEPRØVE tilgjengelig: 01-Jul-18 00:00:01 
    7.  
  7. Siste ASKEPRØVE tilgjengelig: 09-Jul-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. Angi tidsrammen for å generere ASH-rapporten
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. Skriv INN STARTTID FOR rapport:
    13.  
  13.  
    14.  
  14. -- Gyldige inndataformater:
    15.  
  15. -- slik angir du absolutt starttid:
    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. -- slik angir du relativ starttid: (start med '-' tegn)
    22.  
  22. -- -MI
    23.  
  23. -- Eksempler: -1:15 (SYSDATE - 1 Time 15 Minutter)
    24.  
  24. -- -25 (SYSDATE-25 Min)
    25.  
  25.  
    26.  
  26. Standard TIL -15 min
    27.  
  27. Skriv INN VERDI for begin_time: 07/06/18 18:09
    28.  
  28. Rapporter STARTTID spesifisert: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. Angi varighet i minutter fra STARTTIDSPUNKTET:
    31.  
  31. Standardinnstillinger TIL SYSDATE-begin_time
    32.  
  32. Trykk Enter for å analysere TIL GJELDENDE TID 
    33.  
  33. Angi VERDI for varighet: 15 
    34.  
  34. Rapportvarighet spesifisert: 15 
    35.  
  35.  
    36.  
  36.  BRUKE 06-Jul-18 18: 09: 00 som rapport BEGYNN TID 
    37.  
  37.  BRUKE 06-Jul-18 18: 24: 00 som rapport SLUTTID 
    38.  
  38.  
    39.  
  39. Angi Rapportnavnet
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. standard rapportfilnavn er ashrpt_1_0706_1824.HTML. FOR Å BRUKE dette navnet, 
    42.  
  42. trykk < return > for å fortsette, ellers angi et alternativ. 
    43.  
  43. Skriv INN VERDI for report_name:
    44.  
  44.  
    45.  
  45.  BRUKE rapportnavnet ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47. Sammendrag AV ALLE BRUKERINNDATA 
    48.  
  48. -------------------------
    49.  
  49. Format: HTML
    50.  
  50. DB Id : 2019395491 
    51.  
  51. Inst num : 1 
    52.  
  52.  STARTTID: 06-Jul-18 18:09:00
    53.  
  53.  SLUTTID: 06-Jul-18 18:24:00
    54.  
  54. Slot bredde: STANDARD 
    55.  
  55. Rapporter mål : 0 
    56.  
  56. Navn På Rapport : ashrpt_1_0706_1824.html
    57.

Finne SCN I AWR

AWR-rapporten viste oss ikke mye informasjon om dagens SCN, men det har litt informasjon om vekstraten, hvis du vet hvor du finner den.

under «Instans Aktivitetsstatistikk» kan du finne antall «samtaler til kcmgas». I oracle-dokumentasjonen beskrives dette som «Antall samtaler til rutinemessige kcmgas for å få en ny SCN».

verdien av disse anropene per sekund i AWR-rapporten er svært nær SCN-satsen som beregnet med funksjonen timestamp_to_scn.

V $ SESSTAT view

antall «samtaler til kcmgas» brukes til å opprette en ny SCN kan også bli funnet i visningene V $ SESSTAT OG V$SYSSTAT.

Vi kan bruke V $ SESSTAT til å finne øktene som gir en høy SCN-rate. Vi kan også teste virkningen PÅ SCN antall konkrete handlinger.

for eksempel, når jeg velger på et stort bord som også brukes av andre økter, vil økten min gjøre ytterligere 7 samtaler til kcmgas. Så, spørringen min vil føre til en høyere SCN. Dette skyldes lesekonsistensen i databasen, som også bruker EN SCN.

     
  1. SQL > KOBLE < bruker > / < pass > @ < tjeneste> 
    2.  
  2. Tilkoblet. 
    3.  
  3. SQL > VELG ses.verdi
    4.  
  4.  FRA v $ sesstat ses
    5.  
  5.  , v$statname stat
    6.  
  6.  HVOR stat.statistikk# = ses.statistikk#
    7.  
  7.  og ses.sid I (VELG sid fra v $ mystat) 
    8.  
  8.  og stat.name = 'samtaler til kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  VERDI 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL > VELG ANTALL (*) fra mybigtable ;
    16.  
  16.  
    17.  
  17.  GREVE(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL > VELG ses.verdi
    22.  
  22.  FRA v $ sesstat ses
    23.  
  23.  , v$statname stat
    24.  
  24.  HVOR stat.statistikk# = ses.statistikk#
    25.  
  25.  og ses.sid I (VELG sid fra v $ mystat) 
    26.  
  26.  og stat.name = 'samtaler til kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  VERDI 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

Sammenligning AV SCN og commit rate

MED V $ SESSTAT kan vi spørre statistikken for alle økter som er koblet til databasen. Pa denne maten kan vi finne okter som er ansvarlige for en hoy SCN-rente. Vi kan sammenligne dette med commit rate for den økten.

resultatene av spørringen nedenfor viste oss at i vår database var DEN høye SCN-frekvensen hovedsakelig forårsaket av bakgrunnsprosesser. For de fleste brukerøkter er det en sammenheng mellom en høy SCN rate og en høy commit rate, for bakgrunnsøkter commit rate er alltid tom.

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

Konklusjon

Vær oppmerksom på AT DET er grenser FOR SCN, så når du finner advarsler i varselfilen, må du undersøke problemet. Hvis du finner et problem, bør du jobbe Med Oracle-Støtte. Ved å laste opp informasjon kan de sjekke om det er nok plass mellom gjeldende OG maksimal SCN.

Problemer kan skyldes en feil, som 12371955: Hot Backup kan føre til økt SCN-vekst som fører TIL ORA-600-feil (Doc ID 12371955.8).

hvis du vil finne det nøyaktige øyeblikket det er en høy vekst Av SCNs, må du konvertere tidsstempler til SCNs. Du får de beste resultatene ved hjelp av funksjonene SCN_TO_TIMESTAMP og TIMESTAMP_TO_SCN.

en høy commit rate er alltid relatert til brukerprosesser, Men Scn er også relatert til bakgrunnsprosesser. Selv økter som ikke begår kan ha innvirkning på SCN.

Bastiaan Bak

Om forfatteren Bastiaan Bak

DBA MED over 15 års erfaring. Erfaring i ulike grener, med flere moduler. Inkludere: Oracle database, Oracle RAC, ORACLE EBS og PL / SQL.

Flere innlegg av Bastiaan Bak

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.