Investigating the SCN intrinsic growth rate

Geschreven door op in Articles

gepubliceerd op: 10 juli 2018 auteur: Bastiaan Bak Category: it development and operations

een tijdje geleden kregen we een waarschuwing over de intrinsieke groei van de SCN (system change number) in onze Oracle 12.2 database alert file. Deze situatie deed zich meerdere malen voor binnen enkele weken.

“waarschuwing: de intrinsieke groeisnelheid van het SCN was constant
hoger dan de standaardwaarde van het systeem 16384 per sec. gedurende de laatste 60 minuten.
de huidige intrinsieke groeisnelheid van SCN is 25867 per sec., zas 200fffff!
de huidige SCN-waarde is 46747726691, SCN Compat-waarde is 1 “

mijn eerste reactie was dat SCN ‘ s gerelateerd zijn aan commits, dus ofwel de belasting op de database was erg hoog of de applicatielogica moest worden gewijzigd. Een andere mogelijkheid was dat na elke update een commit werd gedaan, in plaats van batch commits te gebruiken.

het bleek iets ingewikkelder dan ik had verwacht. Waar kijk je als je de relatie tussen SCNs en commits wilt vinden? En hoe ernstig is deze waarschuwing eigenlijk? Deze blog gaat over de verschillende manieren waarop ik dit probleem onderzocht en de potentiële impact geïdentificeerd.

Oracle Support notes

de eerste plaats om informatie te zoeken over waarschuwingen in het waarschuwingsbestand is de Oracle Support website. Ik vond een aantal gerelateerde notities:

  • ORA-19706 en gerelateerde Alert log berichten (Doc ID 1393360.1)
    deze opmerking suggereert dat het eigenlijke bericht specifiek is voor database Versie 12.2, maar in oudere versies kunnen we soortgelijke waarschuwingen hebben, zoals ” Waarschuwing: de SCN headroom voor deze database is slechts NN dagen!”
    als u een waarschuwingslogbericht tegenkomt zoals een van deze items, wordt u geadviseerd om de instructies in ID 1388639.1 te volgen en een serviceverzoek te loggen met Oracle support.
    gegevens die moeten worden verzameld bij het rapporteren van problemen met een hoge SCN-snelheid aan Oracle Support (Doc ID 1388639.1)
  • deze notitie geeft informatie over welke informatie u moet leveren bij het loggen van een serviceverzoek.
  • System Change Number( SCN), Headroom, Security and Patch Information (Doc ID 1376995.1)
    deze notitie geeft meer informatie over het gebruik van de SCN. Het system change number (SCN) is een logische, interne tijdstempel die wordt gebruikt door de Oracle-Database. Scns order gebeurtenissen die zich voordoen in de database. De database gebruikt SCN ‘ s om wijzigingen op te vragen en bij te houden. Wanneer een transactie commit, registreert de database een SCN voor deze commit.
    er is een bovengrens aan het aantal SCNs dat een Oracle-Database kan gebruiken. De limiet is momenteel 281 biljoen (2^48) SCN waarden.
    gegeven het feit dat er een bovengrens is, is het belangrijk dat een bepaalde Oracle-Database niet zonder beschikbare SCN ‘ s komt te zitten.
    in de noot wordt ook uitgelegd wanneer de waarschuwing wordt geuit. De Oracle Database berekent een” niet te overschrijden “limiet voor het aantal SCN’ s dat een database momenteel kan gebruiken, gebaseerd op het aantal seconden sinds 1988 vermenigvuldigd met 16384. Dit zorgt ervoor dat Oracle Databases SCN ‘ s in de loop van de tijd rantsoeneren.

hoe ernstig is deze waarschuwing?

de waarschuwing wordt verhoogd met een snelheid van 2^14 = 16384 SCN ‘ s per seconde gedurende de laatste 60 minuten.
de maximale SCN is 2^48 = 281.474.976.710.656.

met een snelheid van 16348 SCN ‘ s per seconde hebben we 2^(48-14) seconden, of 544 jaar om dat maximum te bereiken. Dat zou in een normale situatie voldoende moeten zijn, maar de bovengrens van 2^48 is alleen de maximale absolute waarde die de database kan opslaan.
de limiet is ook gerelateerd aan het aantal seconden sinds 1988. De limiet van 2,48 is het maximum in het jaar 2532 (1988 + 544). Maar in 2018 is het maximum(2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

de waarschuwing mag niet genegeerd worden. Wanneer u de limiet bereikt krijgt u ora-600 fouten, Maar wanneer u de absolute bovengrens SCN bereikt zal de database gewoon stoppen met werken.

het goede nieuws is dat in onze situatie de waarschuwing zei dat de SCN groei was 25867 per seconde in dat specifieke uur, dus in dat uur kwamen we een beetje dichter (25867-16384=9483) bij de limiet. We komen niet elk uur in de buurt van de limiet; de normale groeisnelheid is lager dan 16384.

Oracle Support

we noemden Oracle Support, en ze vertelden ons dat Oracle Development momenteel aan dit probleem werkt.
Oracle-ondersteuning heeft bevestigd dat de SCN-hoofdruimte er goed uitziet. Op basis van het AWR-rapport merkte Oracle Support een groot aantal commits op en stelde voor om contact op te nemen met het applicatieteam om te committen door de transactiegrootte te vergroten.

onderzoek met AWR

uit de waarschuwing in het waarschuwingsbestand bleek dat de intrinsieke groei van SCN constant hoger was dan de standaardwaarde van het systeem: 16384 per seconde gedurende de laatste 60 minuten. Als we kijken naar een tijdsbestek van een uur, een AWR rapport is misschien een goede plek om te beginnen. We hebben AWR geconfigureerd om elk uur snapshots te maken.

in het AWR rapport merkte ik dat het aantal user commits 210 per seconde was. Ja, dat zijn veel commits, maar het is niet zo anders dan de normale belasting van deze database. En als een commit gerelateerd is aan een SCN, is deze ook veel lager dan 16384 per seconde.

het AWR-rapport bevatte ook een addm-bevinding: wacht op event “log file sync” tijdens het uitvoeren van COMMIT-en ROLLBACK-bewerkingen kostte aanzienlijke databasetijd. Onderzoek de toepassingslogica voor een mogelijke vermindering van het aantal COMMIT-operaties door het vergroten van de omvang van transacties.
deze vermindering van de commits in de addm-bevinding werd ook gesuggereerd door Oracle Support. Voor mij was het niet zo hoog.

kortere termijn

omdat de AWR me niet hielp de oorzaak te vinden, moest ik een kortere termijn onderzoeken. Ik wilde een meer specifiek tijdschema weten zodat ik een ASH rapport kon maken. De standaard voor ASH is 15 minuten.
de volgende uitdaging was dus het vinden van het tijdsbestek van 15 minuten waarin de SCN-groei het hoogst was.
Doc ID 1388639.1 voorgesteld om v$archived_log te bevragen. Die weergave bevat informatie over alle log switches in de database, inclusief een tijdstempel en de SCN. Hoewel je tijdstempels kunt toewijzen aan SCN ‘ s, is het niet echt beter dan het AWR-rapport. We zitten nog steeds vast aan willekeurige tijdstempels; in dit geval de tijdstempel van de logswitch.

met behulp van de functie timestamp_to_scn

een betere manier is om de functie timestamp_to_scn te gebruiken. Deze functie geeft een SCN terug op basis van een tijdstempel, zoals de huidige tijdstempel:

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

De volgende stap was om een lijst te maken van tijdstempels samen met de bijpassende SCN en de bijpassende SCN bovengrens op basis van het aantal seconden sinds 1988 vermenigvuldigd en 16.384.

dit toont de tijdstempels en SCN ‘ s voor de laatste dag:

     
  1.  SELECTEER 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-JJJJ' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  VAN dubbele
    6.  
  6.  SLUIT 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 rijen geselecteerd. 
    29.

de huidige SCN is ongeveer 0,57% van de huidige bovengrens.

het vinden van de hoogste SCN-snelheid

op basis van dit idee heb ik een query gemaakt die me de 15 minuten tijdsbestek geeft met de hoogste groei in SCN ‘ s in de laatste 3 dagen.

elke minuut begint een nieuw tijdsbestek, en omdat we 1440 minuten in een dag hebben, hebben we 4320 termijnen om te onderzoeken. Voor elk van hen moeten we de groei van de SCN binnen die 15 minuten tijdsbestek berekenen.

we willen alleen de beste resultaten tonen, in dit geval alleen de termijnen met een snelheid van meer dan 14000 per seconde.

     
  1.  ALTER SESSION SET nls_date_format= 'MM / DD / YY HH24:MI' ;
    2.  
  2.  
    3.  
  3.  MET ALS datelist 
    4.  
  4.  ( SELECTEER sysdate - (rownum/1440) - (15/1440) starttijd -- 15 minuten interval 
    5.  
  5.  , sysdate - (rownum/1440) endtime
    6.  
  6.  VAN dubbele
    7.  
  7.  SLUIT BY rownum <= (3*1440) -- 3 dagen historie 
    8.  
  8. )
    9.  
  9.  SELECTEER starttime
    10.  
  10.  , endtime
    11.  
  11.  , timestamp_to_scn(eindtijd) - timestamp_to_scn(starttijd) scngrowth
    12.  
  12.  , round((timestamp_to_scn(eindtijd) - timestamp_to_scn(starttime)) / 
    13.  
  13.  (((24*60*60)*(eindtijd-starttime )))) scnrate
    14.  
  14.  VAN datelist
    15.  
  15.  WAAR ronde((timestamp_to_scn(eindtijd) - timestamp_to_scn(starttime)) / 
    16.  
  16.  (((24*60*60)*(eindtijd-starttime )))) >= 14000 
    17.  
  17.  ORDER BY DESC 4
    18.  
  18. /
    19.  
     
  1. STARTTIJD EINDTIJD 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.

Zo, nu hebben wij gevonden, de (soms overlappende) 15 minuten tijd frames met de hoogste SCN tarief (SCN groei per seconde) voor de laatste 3 dagen. En zelfs in die tijdframes is het SCN-tarief nog steeds onder 16384. Geen waarschuwingen in het alert bestand deze week….

het uitvoeren van het ASH-rapport

het datumformaat dat ik gebruikte in de query hierboven is hetzelfde als dat van het ASH-rapport, dus je kunt gewoon de starttijd kopiëren/plakken. Voor de duur komen we 15 minuten binnen.

     
  1. SQL> @@$ORACLE_HOME/rdbms/admin / ashrpt.sql
    2.  
  2.  
    3.  
  3. AS Voorbeelden IN dit Workload Repository schema
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. de Oudste ESSEN monster beschikbaar: 01-Jul-18 00:00:01 
    7.  
  7. Laatste AS voorbeeld beschikbaar: 09-Jul-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. Geef de termijn VOOR het genereren van de AS-rapport
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. Voer BEGINT de TIJD VOOR het verslag:
    13.  
  13.  
    14.  
  14. -- Geldige invoer formaten:
    15.  
  15. -- opgeven absolute begin:
    16.  
  16. -- ] HH24:MI
    17.  
  17. -- Voorbeelden: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- opgeven relatieve begint de tijd: (te beginnen met de ' - ' - teken)
    22.  
  22. -- -MI
    23.  
  23. -- Voorbeelden: -1:15 (SYSDATE - 1 uur 15 Minuten)
    24.  
  24. -- -25 (SYSDATE - 25 Minuten)
    25.  
  25.  
    26.  
  26. Standaard -15 minuten
    27.  
  27. Voer een WAARDE in VOOR begin_time: 07/06/18 18:09
    28.  
  28. Verslag BEGINNEN met de opgegeven TIJD: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. Voer de duur IN minuten VANAF BEGIN:
    31.  
  31. Standaard SYSDATE - begin_time
    32.  
  32. Druk op Enter om TE analyseren tot aan de HUIDIGE TIJD 
    33.  
  33. Voer een WAARDE in VOOR de duur: 15 
    34.  
  34. Verslag duur opgegeven: 15 
    35.  
  35.  
    36.  
  36.  het GEBRUIK van 06-Jul-18 18:09:00-rapport BEGINT TIJD 
    37.  
  37.  het GEBRUIK van 06-Jul-18 18:24:00 rapport EIND TIJD 
    38.  
  38.  
    39.  
  39. Geef de Naam van het Rapport
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. Het STANDAARD rapport bestand IS ashrpt_1_0706_1824.HTML. Deze naam gebruiken, 
    42.  
  42. druk op <return> om verder te gaan, voer anders een alternatief in. 
    43.  
  43. voer waarde in voor rapport_naam:
    44.  
  44.  
    45.  
  45.  met de rapportnaam ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47. Overzicht VAN ALLE INPUT van de GEBRUIKER 
    48.  
  48. -------------------------
    49.  
  49. Indeling : HTML
    50.  
  50. DB-Id : 2019395491 
    51.  
  51. Inst num : 1 
    52.  
  52.  BEGIN TIJD : 06-Jul-18 18:09:00
    53.  
  53.  eindtijd : 06-Jul-18 18:24:00
    54.  
  54. Slot width : STANDAARD 
    55.  
  55. Verslag doelen : 0 
    56.  
  56. de naam van het Rapport : ashrpt_1_0706_1824.html
    57.

Finding SCN in AWR

het AWR rapport liet ons niet veel informatie zien over de huidige SCN, maar het bevat wel wat informatie over de groeisnelheid, als u weet waar u het kunt vinden.

onder ” Instance Activity Stats “kunt u het aantal”calls to kcmgas” vinden. In de Oracle documentatie wordt dit beschreven als het “aantal oproepen naar routine kcmga’ s om een nieuwe SCN te krijgen”.

de waarde van deze oproepen per seconde in het AWR-rapport ligt zeer dicht bij de SCN-snelheid zoals berekend met de timestamp_to_scn-functie.

V $ SESSTAT view

het aantal “oproepen naar kcmgas” dat wordt gebruikt om een nieuwe SCN aan te maken, kan ook worden gevonden in de views V$SESSTAT en V$SYSSTAT.

we kunnen V$SESSTAT gebruiken om de sessies te vinden die een hoge SCN rate veroorzaken. We kunnen ook de impact op het SCN aantal specifieke acties testen.

bijvoorbeeld, als ik een select doe op een grote tabel die ook gebruikt wordt door andere sessies, zal mijn sessie nog eens 7 aanroepen doen naar kcmgas. Zo, mijn vraag zal leiden tot een hogere SCN. Dit wordt veroorzaakt door de leesconsistentie van de database, die ook een SCN gebruikt.

     
  1. SQL> CONNECT <gebruiker> / <pass>@<service> 
    2.  
  2. verbonden. 
    3.  
  3. SQL> ses selecteren.waarde
    4.  
  4.  van v$sesstat ses
    5.  
  5.  , v$statname stat
    6.  
  6.  waar nu.statistiek# = ses.statistiek#
    7.  
  7.  en ses.sid IN (selecteer sid van v$mystat) 
    8.  
  8.  en snel.naam = 'calls-to-kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  WAARDE 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL> SELECT COUNT(*) FROM mybigtable ;
    16.  
  16.  
    17.  
  17.  GRAAF(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL> SELECTEER ses.waarde
    22.  
  22.  van v$sesstat ses
    23.  
  23.  , v$statname stat
    24.  
  24.  waar nu.statistiek# = ses.statistiek#
    25.  
  25.  en ses.sid IN (selecteer sid van v$mystat) 
    26.  
  26.  en snel.naam = 'calls-to-kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  WAARDE 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

het Vergelijken van de SCN en commit-tarief

V$SESSTAT kunnen we query de statistieken voor alle sessies verbonden met de database. Op deze manier kunnen we sessies vinden die verantwoordelijk zijn voor een hoog SCN-percentage. We kunnen dit vergelijken met de commit rate voor die sessie.

de resultaten van de query hieronder toonden ons dat in onze database de hoge SCN-snelheid voornamelijk werd veroorzaakt door achtergrondprocessen. Voor de meeste gebruikerssessies is er een relatie tussen een hoge SCN-snelheid en een hoge commit-snelheid, voor achtergrondsessies is de commit-snelheid altijd leeg.

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

conclusie

Houd er rekening mee dat er grenzen zijn aan de SCN, dus wanneer u waarschuwingen in het waarschuwingsbestand vindt, moet u het probleem onderzoeken. Als u een probleem vindt, moet u werken met Oracle Support. Door informatie te uploaden kunnen ze controleren of er voldoende ruimte is tussen de huidige en maximale SCN.

problemen kunnen worden veroorzaakt door een bug, zoals 12371955: Hot Backup kan een verhoogde SCN-groei veroorzaken, wat leidt tot ora-600 fouten (Doc ID 12371955.8).

Als u het exacte moment wilt vinden dat er een hoge groei van SCN ’s is, moet u tijdstempels converteren naar SCN’ s. U krijgt de beste resultaten met behulp van de functies SCN_TO_TIMESTAMP en TIMESTAMP_TO_SCN.

een hoge commit rate is altijd gerelateerd aan gebruikersprocessen, maar SCN ‘ s zijn ook gerelateerd aan achtergrondprocessen. Zelfs sessies die niet committen kunnen een impact hebben op de SCN.

Bastiaan Bak

over de auteur Bastiaan Bak

DBA met meer dan 15 jaar ervaring. Ervaring in verschillende branches, met verschillende modules. Inclusief: Oracle database, Oracle RAC, Oracle EBS en PL / SQL.

meer berichten van Bastiaan Bak

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.