Undersök SCN intrinsic growth rate

Skriven av den i Articles

Publicerad den: 10 juli 2018 författare: Bastiaan Bak Kategori: IT-utveckling och operationer

för ett tag sedan hade vi en varning om den inneboende tillväxten av SCN (system change number) i vår Oracle 12.2 databas alert file. Denna situation inträffade flera gånger inom några veckor.

”Varning: SCN intrinsic tillväxttakten har varit konsekvent
högre än system Standard 16384 per SEK. för senaste 60 minuter.
nuvarande SCN inneboende tillväxttakt är 25867 per sek., zas 200fffff!
det aktuella SCN-värdet är 46747726691, SCN Compat-värdet är 1 ”

min första reaktion var att SCN är relaterade till åtaganden, så antingen var belastningen på databasen mycket hög eller applikationslogiken bör ändras. En annan möjlighet var att en begå gjordes efter varje uppdatering, istället för att använda batch begår.

det visade sig vara lite mer komplicerat än jag förväntade mig. Var tittar du när du vill hitta förhållandet mellan SCN och commitments? Och hur allvarlig är denna varning ändå? Den här bloggen kommer att handla om de olika sätten jag undersökte detta problem och identifierade den potentiella effekten.

Oracle Support notes

det första stället att leta efter information om varningar i varningsfilen är Oracles supportwebbplats. Jag hittade flera relaterade anteckningar:

  • ORA-19706 och relaterade Varningsloggmeddelanden (Doc ID 1393360.1)
    denna anteckning antyder att det faktiska meddelandet är specifikt för databasversion 12.2, men i äldre versioner kan vi ha liknande varningar, som ”Varning: SCN-utrymme för denna databas är bara NN dagar!”
    om du stöter på ett varningsloggmeddelande som någon av dessa poster rekommenderas du att följa instruktionerna i ID 1388639.1 och logga en serviceförfrågan med Oracle-support.
    bevis som ska samlas in vid rapportering av problem med” hög SCN-hastighet ” till Oracle Support (Doc ID 1388639.1)
  • denna anmärkning ger information om vilken information du ska leverera när du loggar en serviceförfrågan.
  • Systemändringsnummer (SCN), Utrymme, säkerhets-och Patchinformation (Doc ID 1376995.1)
    denna anmärkning ger mer information om användningen av SCN. System change number (SCN) är en logisk, intern tidsstämpel som används av Oracle-databasen. SCNs beställer händelser som inträffar i databasen. Databasen använder SCN för att söka och spåra ändringar. När en transaktion begås registrerar databasen en SCN för denna commit.
    det finns en övre gräns för hur många SCN en Oracle-databas kan använda. Gränsen är för närvarande 281 biljoner (2^48) SCN-värden.
    med tanke på att det finns en övre gräns är det viktigt att en viss Oracle-databas inte tar slut på tillgängliga SCN.
    anteckningen förklarar också när varningen höjs. Oracle-databasen beräknar en gräns för” inte överskrida ” för antalet SCN som en databas för närvarande kan använda, baserat på antalet sekunder sedan 1988 multiplicerat med 16384. Genom att göra detta säkerställs att Oracle-databaser kommer att ransonera SCN över tiden.

hur allvarlig är denna varning?

varningen höjs med en hastighet av 2^14 = 16384 SCN per sekund under de senaste 60 minuterna.
den maximala SCN är 2^48 = 281.474.976.710.656.

med en hastighet av 16348 SCN per sekund kommer vi att ha 2^(48-14) sekunder, eller 544 år för att nå det maximala. Det borde vara tillräckligt i en normal situation, men den övre gränsen på 2^48 är bara det maximala absoluta värdet som databasen kan lagra.
gränsen är också relaterad till antalet sekunder sedan 1988. Gränsen på 2^48 är det maximala år 2532 (1988 + 544). Men i 2018 är det maximala (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

varningen bör inte ignoreras. När du når gränsen får du ora-600-fel, men när du når den absoluta övre gränsen SCN kommer databasen bara att sluta fungera.

den goda nyheten är att varningen i vår situation sa att SCN-tillväxttakten var 25867 per sekund under den specifika timmen, så under den timmen kom vi lite närmare (25867-16384=9483) till gränsen. Vi kommer inte nära gränsen varje timme; den normala tillväxttakten är lägre än 16384.

Oracle Support

vi ringde Oracle Support, och de berättade för oss Oracle Development arbetar för närvarande med denna fråga.
Oracle Support bekräftade att SCN-utrymmet ser bra ut. Baserat på AWR-rapporten märkte Oracle Support ett stort antal åtaganden och föreslog att man skulle kontrollera med application team att begå genom att öka transaktionsstorleken.

undersökning med AWR

varningen i varningsfilen berättade för oss att SCN intrinsic growth rate har varit konsekvent högre än system Standard: 16384 per sekund för de senaste 60 minuterna. Om vi tittar på en tidsram på en timme kan en AWR-rapport vara ett bra ställe att börja. Vi har AWR konfigurerat för att göra ögonblicksbilder varje timme.

i AWR-rapporten märkte jag att antalet användarförpliktelser var 210 per sekund. Ja, det är många åtaganden, men det är inte så annorlunda än den normala belastningen i denna databas. Och om en commit är relaterad till en SCN, är den också mycket lägre än 16384 per sekund.

AWR-rapporten innehöll också ett addm-resultat: väntar på Händelse ”loggfilsynkronisering” när du utför COMMIT-och ROLLBACK-operationer förbrukade betydande databastid. Undersök applikationslogik för eventuell minskning av antalet begå operationer genom att öka storleken på transaktioner.
denna minskning av åtagandena i ADDM-fyndet föreslogs också av Oracle Support. Ur min synvinkel var det dock inte så högt.

kortare tidsram

eftersom AWR inte hjälpte mig att hitta orsaken behövde jag undersöka en kortare tidsram. Jag ville veta en mer specifik tidsram så att jag kunde skapa en ASH-rapport. Standardvärdet för ASH är 15 minuter.
så nästa utmaning var att hitta den 15 minuters tidsram där SCN-tillväxten var högst.
Doc ID 1388639.1 föreslog att fråga v$archived_log. Den vyn innehåller information om alla loggväxlar i databasen, inklusive en tidsstämpel och SCN. Även om du kan kartlägga tidsstämplar till SCN, är det inte riktigt bättre än AWR-rapporten. Vi är fortfarande fast vid slumpmässiga tidsstämplar; i detta fall tidsstämpeln för logswitchen.

använda funktionen timestamp_to_scn

ett bättre sätt är att använda funktionen timestamp_to_scn. Den här funktionen returnerar ett SCN baserat på en tidsstämpel, som den aktuella tidsstämpeln:

     
  1. SQL> välj timestamp_to_scn (sysdate) från dual ;
    2.  
  2.  
    3.  
  3. TIMESTAMP_TO_SCN (SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7. SQL> 
    8.

nästa steg var att göra en lista över tidsstämplar tillsammans med matchande SCN och matchande SCN övre gräns, baserat på antalet sekunder sedan 1988 multiplicerat med 16 384.

detta visar tidsstämplar och SCN för den sista dagen:

     
  1.  välj 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-ÅÅÅÅ' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  från dual
    6.  
  6.  Anslut med 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 markerade. 
    29.

den nuvarande SCN är cirka 0,57% av den nuvarande övre gränsen.

hitta den bästa SCN-hastigheten

baserat på den här tanken skapade jag en fråga som ger mig 15 minuters tidsram med högsta tillväxt i SCN under de senaste 3 dagarna.

varje minut börjar en ny tidsram, och eftersom vi har 1440 minuter på en dag har vi 4320 tidsramar att undersöka. För var och en av dem måste vi beräkna tillväxten av SCN inom den 15 minuters tidsramen.

vi vill bara visa de bästa resultaten, i det här fallet bara tidsramarna med en hastighet på över 14000 per sekund.

     
  1.  ändra SESSIONSUPPSÄTTNING nls_date_format= 'MM / DD / åå HH24: MI' ;
    2.  
  2.  
    3.  
  3.  med datelist som 
    4.  
  4.  ( välj sysdate - (rownum/1440) - (15/1440) starttid - 15 minuters intervall 
    5.  
  5.  , sysdate - (rownum/1440) sluttid
    6.  
  6.  från dual
    7.  
  7.  Anslut med rownum <= (3*1440) -- 3 dagar historia 
    8.  
  8. )
    9.  
  9.  välj starttid
    10.  
  10.  , sluttid
    11.  
  11.  , timestamp_to_scn (endtime) - timestamp_to_scn (starttime) scngrowth
    12.  
  12.  , runda ((timestamp_to_scn (endtime) - timestamp_to_scn (starttime)) / 
    13.  
  13.  (((24*60*60)*(sluttid-starttid)))) scnrate
    14.  
  14.  från datelist
    15.  
  15.  där round ((timestamp_to_scn (endtime) - timestamp_to_scn (starttime)) / 
    16.  
  16.  (((24*60*60)*(sluttid-starttid )))) >= 14000 
    17.  
  17.  Beställ av 4 DESC 
    18.  
  18. /
    19.  
     
  1. starttid sluttid 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å nu har vi hittat (ibland överlappande) 15 minuters tidsramar med den högsta SCN-hastigheten (SCN-tillväxt per sekund) under de senaste 3 dagarna. Och även i dessa tidsramar är SCN-kursen fortfarande under 16384. Inga varningar i varningsfilen den här veckan….

kör ASH-rapporten

datumformatet som jag använde i frågan ovan är detsamma som används av ASH-rapporten, så du kan bara kopiera/klistra in starttiden. För varaktigheten anger vi 15 minuter.

     
  1. SQL> @@ $ ORACLE_HOME/rdbms/admin / ashrpt.sql
    2.  
  2.  
    3.  
  3. ASKPROVER i detta Arbetsbelastningsförrådsschema
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. äldsta ASKPROV tillgängligt: 01-Jul-18 00:00:01 
    7.  
  7. senaste ASKPROVET tillgängligt: 09-Jul-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. ange tidsramen för att generera ASH-rapporten
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. ange starttid för rapport:
    13.  
  13.  
    14.  
  14. -- giltiga inmatningsformat:
    15.  
  15. -- för att ange absolut starttid:
    16.  
  16. -- ] HH24: MI
    17.  
  17. -- exempel: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- för att ange relativ starttid: (börja med ' - ' tecken)
    22.  
  22. -- -MI
    23.  
  23. -- exempel: -1:15 (SYSDATE - 1 timme 15 minuter)
    24.  
  24. -- -25 (SYSDATE-25 minuter)
    25.  
  25.  
    26.  
  26. Standardvärdet är -15 minuter
    27.  
  27. Ange värde för begin_time: 07/06/18 18:09
    28.  
  28. rapportera starttid specificerad: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. ange varaktighet i minuter från starttid:
    31.  
  31. standardinställningar för SYSDATE-begin_time
    32.  
  32. tryck på Enter för att analysera till aktuell tid 
    33.  
  33. Ange värde för varaktighet: 15 
    34.  
  34. rapportens varaktighet specificerad: 15 
    35.  
  35.  
    36.  
  36.  använda 06-Jul-18 18: 09: 00 som rapport börjar tid 
    37.  
  37.  använda 06-Jul-18 18:24:00 som rapportens sluttid 
    38.  
  38.  
    39.  
  39. ange rapportens namn
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. STANDARDRAPPORTFILNAMNET är ashrpt_1_0706_1824.HTML. För att använda detta namn, 
    42.  
  42. tryck på <return> för att fortsätta, annars anger du ett alternativ. 
    43.  
  43. Ange värde för rapportnamn:
    44.  
  44.  
    45.  
  45.  använda rapportnamnet ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47. sammanfattning av all användarinmatning 
    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. Spårbredd: standard 
    55.  
  55. rapportera mål : 0 
    56.  
  56. rapportens namn : ashrpt_1_0706_1824.html
    57.

hitta SCN i AWR

AWR-rapporten visade oss inte mycket information om den nuvarande SCN, men den har lite information om tillväxttakten, om du vet var du hittar den.

Under ”Instansaktivitetsstatistik” hittar du antalet ”samtal till kcmgas”. I Oracle-dokumentationen beskrivs detta som”antalet samtal till rutinmässiga kcmgas för att få en ny SCN”.

värdet på dessa anrop per sekund i AWR-rapporten ligger mycket nära SCN-hastigheten som beräknas med funktionen timestamp_to_scn.

v$SESSTAT view

antalet ”samtal till kcmgas” som används för att skapa en ny SCN kan också hittas i vyerna V$SESSTAT och V$SYSSTAT.

vi kan använda V$SESSTAT för att hitta de sessioner som orsakar en hög SCN-hastighet. Vi kan också testa effekten på SCN antal specifika åtgärder.

till exempel, när jag gör en select på ett stort bord som också används av andra sessioner, kommer min session att göra ytterligare 7 samtal till kcmgas. Så, min fråga kommer att orsaka en högre SCN. Detta orsakas av databasens läskonsistens, som också använder en SCN.

     
  1. SQL> ansluta < användare> / < passera>@< service> 
    2.  
  2. ansluten. 
    3.  
  3. SQL> välj ses.värde
    4.  
  4.  från V$sesstat ses
    5.  
  5.  , v $ statname stat
    6.  
  6.  där stat.statistik# = ses.statistik#
    7.  
  7.  och ses.sid I (välj sid från V$mystat) 
    8.  
  8.  och stat.name = 'samtal till kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  värde 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL> välj räkna ( * ) från mybigtable ;
    16.  
  16.  
    17.  
  17.  räkna(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL> välj ses.värde
    22.  
  22.  från V$sesstat ses
    23.  
  23.  , v $ statname stat
    24.  
  24.  där stat.statistik# = ses.statistik#
    25.  
  25.  och ses.sid I (välj sid från V$mystat) 
    26.  
  26.  och stat.name = 'samtal till kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  värde 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

jämförelse av SCN och commit rate

med V$SESSTAT kan vi fråga statistiken för alla sessioner som för närvarande är anslutna till databasen. På detta sätt kan vi hitta sessioner som är ansvariga för en hög SCN-hastighet. Vi kan jämföra detta med åtagandegraden för den sessionen.

resultaten av frågan nedan visade oss att den höga SCN-frekvensen i vår databas huvudsakligen orsakades av bakgrundsprocesser. För de flesta användarsessioner finns det en relation mellan en hög SCN-hastighet och en hög commit rate, för bakgrundssessioner är commit rate alltid tom.

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

slutsats

var medveten om att det finns gränser för SCN, så när du hittar varningar i varningsfilen måste du undersöka problemet. Om du hittar ett problem bör du arbeta med Oracle Support. Genom att ladda upp information kan de kontrollera om det finns tillräckligt med utrymme mellan aktuell och maximal SCN.

problem kan orsakas av ett fel, som 12371955: Hot Backup kan orsaka ökad SCN-tillväxt som leder till ora-600-fel (Doc ID 12371955.8).

om du vill hitta det exakta ögonblicket finns det en hög tillväxt av SCN måste du konvertera tidsstämplar till SCN. Du får bästa resultat med funktionerna SCN_TO_TIMESTAMP och TIMESTAMP_TO_SCN.

en hög commit rate är alltid relaterad till användarprocesser, men SCN är också relaterade till bakgrundsprocesser. Även sessioner som inte begår kan påverka SCN.

Bastiaan Bak

om författaren Bastiaan Bak

DBA med över 15 års erfarenhet. Erfarenhet inom olika branscher, med flera moduler. Inklusive: Oracle database, Oracle RAC, Oracle EBS och PL / SQL.

fler inlägg av Bastiaan Bak

Lämna ett svar

Din e-postadress kommer inte publiceras.