az SCN intrinsic growth rate vizsgálata

Written by on in Articles

megjelent: 10 Július 2018 Szerző: Bastiaan Bak Kategória: IT fejlesztés és üzemeltetés

egy ideje figyelmeztetést kaptunk az SCN (system change number) belső növekedéséről az Oracle 12.2 adatbázis riasztási fájljában. Ez a helyzet néhány héten belül többször is előfordult.

“figyelem: az SCN belső növekedési üteme következetesen
magasabb, mint a rendszer alapértelmezett 16384 másodpercenként. az elmúlt 60 percben.
a jelenlegi SCN belső növekedési üteme 25867 másodpercenként., zas 200fffff!
a jelenlegi SCN érték 46747726691, SCN Compat érték 1″

az első reakcióm az volt, hogy az SCN-ek a commitokhoz kapcsolódnak, tehát vagy az adatbázis terhelése nagyon magas volt, vagy az alkalmazás logikáját meg kell változtatni. Egy másik lehetőség az volt, hogy minden frissítés után elkövetést hajtottak végre, a kötegelt elkövetések használata helyett.

kiderült, hogy egy kicsit bonyolultabb, mint vártam. Hol keresed, ha meg akarod találni a kapcsolatot az SCNs és a commits között? Mennyire komoly ez a figyelmeztetés? Ez a blog arról szól, hogy milyen módon vizsgáltam ezt a problémát, és azonosítottam a lehetséges hatásokat.

Oracle Support notes

a figyelmeztetésekkel kapcsolatos információkat a riasztási fájlban elsőként az Oracle Support webhelyen kell keresni. Több kapcsolódó megjegyzést találtam:

  • ORA-19706 és a kapcsolódó riasztási naplóüzenetek (Doc ID 1393360.1)
    ez a megjegyzés azt sugallja, hogy a tényleges üzenet az adatbázis 12.2-es verziójára vonatkozik, de a régebbi verziókban hasonló figyelmeztetések lehetnek, mint például: “figyelmeztetés: Az adatbázis SCN belmagassága csak NN nap!”
    ha a fenti bejegyzésekhez hasonló riasztási naplóbejegyzéssel találkozik, javasoljuk, hogy kövesse az ID 1388639.1 utasításait, és jelentkezzen be egy Szolgáltatáskérésbe az Oracle támogatásával.
    a “magas SCN-Arány” problémáknak az Oracle Support részére történő jelentésekor gyűjtendő bizonyítékok (Doc ID 1388639.1)
  • ez a megjegyzés arról ad tájékoztatást, hogy milyen információkat kell szolgáltatnia egy szolgáltatási kérelem naplózásakor.
  • Rendszerváltási szám (SCN), belmagasság, biztonsági és javítási információk (Doc ID 1376995.1)
    ez a megjegyzés további információkat tartalmaz az SCN használatáról. A rendszerváltási szám (SCN) egy logikai, belső időbélyeg, amelyet az Oracle adatbázis használ. Az SCNs az adatbázisban előforduló eseményeket rendezi. Az adatbázis SCNs-t használ a változások lekérdezéséhez és nyomon követéséhez. Amikor egy tranzakció elkötelezi magát, az adatbázis egy SCN-t rögzít erre a kötelezettségvállalásra.
    felső határa van annak, hogy egy Oracle adatbázis hány SCN-t használhat. A határ jelenleg 281 billió (2^48) SCN érték.
    tekintettel arra, hogy van egy felső határ, fontos, hogy az adott Oracle adatbázis ne fogyjon el a rendelkezésre álló SCN-ekből.
    a jegyzet azt is elmagyarázza, hogy mikor emelik fel a figyelmeztetést. Az Oracle Database kiszámítja a” nem haladhatja meg ” korlátot az adatbázis által jelenleg használható SCN-ek számára, az 1988 óta eltelt másodpercek száma alapján szorozva 16384-gyel. Ez biztosítja, hogy az Oracle adatbázisok idővel arányozzák az SCN-eket.

mennyire súlyos ez a figyelmeztetés?

a figyelmeztetés 2^14 = 16384 SCNs / másodperc sebességgel emelkedik az elmúlt 60 percben.
a maximális SCN 2^48 = 281.474.976.710.656.

16348 SCNs / másodperc sebességgel 2^(48-14) másodperc vagy 544 év áll rendelkezésünkre, hogy elérjük ezt a maximumot. Ennek normál helyzetben elegendőnek kell lennie, de a 2^48 felső határa csak az adatbázis által tárolható maximális abszolút érték.
a határérték az 1988 óta eltelt másodpercek számához is kapcsolódik. A 2^48-as határ a 2532-es év maximuma (1988+544). De 2018-ban a maximális (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

a figyelmeztetést nem szabad figyelmen kívül hagyni. Amikor eléri a korlátot, ora-600 hibákat kap,de amikor eléri az abszolút felső határt SCN az adatbázis csak leáll.

a jó hír az, hogy a mi helyzetünkben a figyelmeztetés szerint az SCN növekedési üteme másodpercenként 25867 volt az adott órában, tehát abban az órában egy kicsit közelebb kerültünk (25867-16384=9483) a határhoz. Nem minden órában közelítjük meg a határt; a normál növekedési ütem alacsonyabb, mint 16384.

Oracle Support

felhívtuk az Oracle supportot, és elmondták, hogy az Oracle Development jelenleg dolgozik ezen a problémán.
az Oracle Support megerősítette, hogy az SCN belmagassága jól néz ki. Az AWR jelentés alapján az Oracle Support észrevette a kötelezettségvállalások nagy számát, és azt javasolta, hogy ellenőrizze az alkalmazáscsapattal a kötelezettségvállalást a tranzakció méretének növelésével.

vizsgálat AWR – rel

a figyelmeztető fájlban szereplő figyelmeztetés azt mondta nekünk, hogy az SCN belső növekedési üteme következetesen magasabb volt, mint a rendszer alapértelmezett értéke: 16384 másodpercenként az elmúlt 60 percben. Ha egy órás időkeretet keresünk, egy AWR jelentés jó kiindulópont lehet. Az AWR úgy van konfigurálva, hogy óránként pillanatfelvételeket készítsen.

az AWR jelentésben észrevettem, hogy a felhasználói elkövetések száma másodpercenként 210 volt. Igen, ez sok elkötelezettség, de nem különbözik annyira az adatbázis normál terhelésétől. És ha egy commit egy SCN-hez kapcsolódik, akkor is sokkal alacsonyabb, mint 16384 másodpercenként.

az AWR jelentés egy ADDM megállapítást is tartalmazott: a “naplófájl-szinkronizálás” esemény várakozása a COMMIT and ROLLBACK műveletek végrehajtása közben jelentős adatbázis-időt vett igénybe. Vizsgálja meg az alkalmazás logikáját a kötelezettségvállalási műveletek számának lehetséges csökkentése érdekében a tranzakciók méretének növelésével.
az ADDM-lelet kötelezettségvállalásainak csökkentését az Oracle Support is javasolta. Az én szempontomból, nem volt igazán olyan magas, bár.

rövidebb időkeret

mivel az AWR nem segített megtalálni az okot, rövidebb időkeretet kellett vizsgálnom. Konkrétabb időkeretet akartam tudni, hogy ELKÉSZÍTHESSEK egy ASH-jelentést. A vaku alapértelmezett értéke 15 perc.
tehát a következő kihívás az volt, hogy megtaláljuk azt a 15 perces időkeretet, amelyben az SCN növekedési üteme a legmagasabb volt.
Doc ID 1388639.1 javasolt lekérdezés v$archived_log. Ez a nézet információkat tartalmaz az adatbázis összes naplókapcsolójáról, beleértve az időbélyegzőt és az SCN-t. Bár az időbélyegeket fel lehet térképezni az SCNs-re, ez nem igazán jobb, mint az AWR jelentés. Még mindig ragaszkodunk a véletlenszerű időbélyegekhez; ebben az esetben a logswitch időbélyegzője.

a timestamp_to_scn függvény használata

jobb módszer a timestamp_to_scn függvény használata. Ez a függvény egy IDŐBÉLYEGEN alapuló SCN-t ad vissza, mint az aktuális időbélyeg:

     
  1. SQL> válassza ki a timestamp_to_scn (sysdate) elemet a dual-ból ;
    2.  
  2.  
    3.  
  3. TIMESTAMP_TO_SCN (SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7. SQL> 
    8.

a következő lépés az volt, hogy egy listát az időbélyegek együtt a megfelelő SCN és a megfelelő SCN felső határ alapján a másodpercek száma 1988 óta szorozva 16,384.

ez az utolsó nap időbélyegeit és SCN-jét mutatja:

     
  1.  válassza a sysdate - (rownum/24) datetimestamp lehetőséget
    2.  
  2.  , timestamp_to_scn(sysdate - (rownum/24)) SCN
    3.  
  3.  , ((sysdate - (rownum/24)) - to_date ('01-01-1988', 'ÉÉÉÉ-HH-NN' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 felső_lmt
    5.  
  5.  a kettős
    6.  
  6.  csatlakozás rownum által<= 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 kiválasztott sorok. 
    29.

a jelenlegi SCN körülbelül 0,57% a jelenlegi felső határ.

Finding the top SCN rate

ezen ötlet alapján létrehoztam egy lekérdezést, amely megadja nekem a 15 perces időkeretet a legnagyobb növekedéssel az SCN-ekben az elmúlt 3 napban.

minden percben új időkeret kezdődik, és mivel 1440 percünk van egy nap alatt, 4320 időkeretünk van a kivizsgálásra. Mindegyikre ki kell számolnunk az SCN növekedését ezen a 15 perces időkereten belül.

csak a legjobb eredményeket szeretnénk megmutatni, ebben az esetben csak az időkereteket, másodpercenként több mint 14000 sebességgel.

     
  1.  NLS_DATE_FORMAT = 'HH/NN / ÉÉ HH24: MI' ;
    2.  
  2.  
    3.  
  3.  a datelist mint 
    4.  
  4.  ( válassza ki a sysdate - (rownum/1440) - (15/1440) kezdési időt -- 15 perces intervallum 
    5.  
  5.  , sysdate - (rownum/1440) végidő
    6.  
  6.  a kettős
    7.  
  7.  csatlakozás rownum által<= (3*1440) -- 3 napok története 
    8.  
  8. )
    9.  
  9.  válassza a starttime lehetőséget
    10.  
  10.  , végidő
    11.  
  11.  , timestamp_to_scn (endtime) - timestamp_to_scn (starttime) scngrowth
    12.  
  12.  , kerek ((timestamp_to_scn (endtime) - timestamp_to_scn (starttime)) / 
    13.  
  13.  (((24*60*60)*(endtime-starttime )))) scnrate
    14.  
  14.  tól datelist
    15.  
  15.  ahol kerek ((timestamp_to_scn (endtime) - timestamp_to_scn (starttime)) / 
    16.  
  16.  (((24*60*60)*(endtime-starttime )))) >= 14000 
    17.  
  17.  rendelés 4 DESC 
    18.  
  18. /
    19.  
     
  1. STARTTIME ENDTIME SCNNÖVEKEDÉS 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.

tehát most megtaláltuk a (néha átfedő) 15 perces időkereteket a legmagasabb SCN sebességgel (SCN növekedés másodpercenként) az elmúlt 3 napban. És még ezekben az időkeretekben is az SCN aránya még mindig 16384 alatt van. Nincs figyelmeztetés a riasztási fájlban ezen a héten….

ASH jelentés futtatása

a fenti lekérdezésben használt dátumformátum megegyezik a ASH jelentés által használt formátummal, így csak másolhatja/beillesztheti a kezdési időt. Az időtartam alatt 15 percet adunk meg.

     
  1. SQL> @@ $ ORACLE_HOME / rdbms / admin / ashrpt.sql
    2.  
  2.  
    3.  
  3. ASH minták ebben a munkaterhelés-tároló sémában
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. a rendelkezésre álló legrégebbi HAMUMINTA: 01-júl-18 00:00:01 
    7.  
  7. a legfrissebb HAMUMINTA elérhető: 09-júl-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. adja meg az ASH jelentés létrehozásának időkeretét
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. adja meg a jelentés kezdési idejét:
    13.  
  13.  
    14.  
  14. -- érvényes bemeneti formátumok:
    15.  
  15. -- az abszolút kezdési idő megadása:
    16.  
  16. -- ] HH24: MI
    17.  
  17. -- példák: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- a relatív kezdési idő megadása: (kezdje ' - ' jellel)
    22.  
  22. -- -MI
    23.  
  23. -- példák: -1:15 (SYSDATE - 1 óra 15 perc)
    24.  
  24. -- -25 (SYSDATE - 25 perc)
    25.  
  25.  
    26.  
  26. alapértelmezett érték -15 perc
    27.  
  27. adja meg a begin_time értékét: 07/06/18 18:09
    28.  
  28. a jelentés kezdő időpontja megadva: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. adja meg az időtartamot percben a kezdési időponttól kezdve:
    31.  
  31. alapértelmezett SYSDATE-begin_time
    32.  
  32. nyomja meg az Enter gombot az aktuális idő elemzéséhez 
    33.  
  33. adja meg az időtartam értékét: 15 
    34.  
  34. a jelentés meghatározott időtartama: 15 
    35.  
  35.  
    36.  
  36.  használata 06-Júl-18 18:09:00 mint jelentés kezdési ideje 
    37.  
  37.  használata 06-július-18 18:24:00 mint jelentés befejezési ideje 
    38.  
  38.  
    39.  
  39. adja meg a jelentés nevét
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. az alapértelmezett jelentésfájl neve ashrpt_1_0706_1824.html. A név használata, 
    42.  
  42. nyomja meg a <return> gombot a folytatáshoz, ellenkező esetben adjon meg egy alternatívát. 
    43.  
  43. adja meg a report_name értékét:
    44.  
  44.  
    45.  
  45.  az ashrpt_1_0706_1824 jelentésnév használata.html
    46.  
  46.  
    47.  
  47. az összes felhasználói bevitel összefoglalása 
    48.  
  48. -------------------------
    49.  
  49. formátum: HTML
    50.  
  50. DB Azonosító : 2019395491 
    51.  
  51. Inst szám : 1 
    52.  
  52.  kezdési idő: 06-Júl-18 18:09:00
    53.  
  53.  befejezési idő: 06-Júl-18 18:24:00
    54.  
  54. rés szélessége: alapértelmezett 
    55.  
  55. célok jelentése: 0 
    56.  
  56. Jelentés neve : ashrpt_1_0706_1824.html
    57.

SCN keresése az AWR – ben

az AWR-jelentés nem mutatott sok információt a jelenlegi SCN-ről, de van néhány információ a növekedési ütemről, ha tudja, hol találja meg.

a “Példánytevékenység-statisztikák” alatt megtalálja a “hívások kcmga-khoz”számát. Az Oracle dokumentációjában ezt úgy írják le, mint”a rutin kcmga-k hívásainak száma Egy új SCN megszerzéséhez”.

ezeknek a hívásoknak a másodpercenkénti értéke az AWR jelentésben nagyon közel áll az SCN sebességhez, amelyet a timestamp_to_scn függvény számít.

V$SESSTAT nézet

az új SCN létrehozásához használt “kcmga-hívások” száma megtalálható a v$SESSTAT és a V$SYSSTAT nézetekben is.

a V$SESSTAT segítségével megkereshetjük azokat a munkameneteket, amelyek magas SCN-arányt okoznak. Azt is tesztelni a hatást az SCN száma konkrét intézkedéseket.

például, amikor egy nagy asztalon választok, amelyet más munkamenetek is használnak, a munkamenetem további 7 hívást fog végrehajtani a kcmga-khoz. Tehát a lekérdezésem magasabb SCN-t okoz. Ezt az adatbázis olvasási konzisztenciája okozza, amely SCN-t is használ.

     
  1. SQL> csatlakozás < felhasználó> / < pass> @ <szolgáltatás> 
    2.  
  2. kapcsolatban. 
    3.  
  3. SQL> válassza a ses lehetőséget.érték
    4.  
  4.  tól től v$sesstat ses
    5.  
  5.  , v$statname stat
    6.  
  6.  ahol stat.statisztika#=ses.statisztika#
    7.  
  7.  és ses.sid IN (Válassza ki a sid-t a v$mystat-ból) 
    8.  
  8.  és azonnal.name = 'hívások a kcmgas-hoz' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  érték 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL> válassza ki a számlálást (*) a mybigtable-ből ;
    16.  
  16.  
    17.  
  17.  gróf(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL> válassza a ses lehetőséget.érték
    22.  
  22.  tól től v$sesstat ses
    23.  
  23.  , v$statname stat
    24.  
  24.  ahol stat.statisztika#=ses.statisztika#
    25.  
  25.  és ses.sid IN (Válassza ki a sid-t a v$mystat-ból) 
    26.  
  26.  és azonnal.name = 'hívások a kcmgas-hoz' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  érték 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

az SCN és a commit rate

összehasonlításával a V$SESSTAT segítségével lekérdezhetjük az adatbázishoz jelenleg csatlakoztatott összes munkamenet statisztikáit. Ily módon olyan munkameneteket találhatunk, amelyek felelősek a magas SCN arányért. Ezt összehasonlíthatjuk az adott munkamenet elkövetési arányával.

az alábbi lekérdezés eredményei azt mutatták, hogy adatbázisunkban a magas SCN arányt elsősorban a háttérfolyamatok okozták. A legtöbb felhasználói munkamenetnél összefüggés van a magas SCN-arány és a magas elkövetési arány között, a háttér munkameneteknél az elkövetési arány mindig üres.

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

következtetés

ne feledje, hogy az SCN-nek vannak korlátai, ezért amikor figyelmeztetéseket talál a riasztási fájlban, meg kell vizsgálnia a problémát. Ha problémát talál, akkor az Oracle Támogatással kell dolgoznia. Az információk feltöltésével ellenőrizhetik, hogy van-e elegendő hely az aktuális és a maximális SCN között.

problémákat okozhat egy hiba, például 12371955: a Hot Backup megnövekedett SCN növekedési sebességet okozhat, ami ORA-600 hibákhoz vezethet (Doc ID 12371955.8).

ha meg akarja találni a pontos pillanatot, amikor az SCN-ek nagy növekedést mutatnak, akkor az időbélyegeket SCN-ekké kell konvertálni. A legjobb eredményeket a scn_to_timestamp és TIMESTAMP_TO_SCN függvényekkel érheti el.

a magas elkövetési arány mindig a felhasználói folyamatokhoz kapcsolódik, de az SCN-ek a háttérfolyamatokhoz is kapcsolódnak. Még a nem elkötelezett munkamenetek is hatással lehetnek az SCN-re.

Bastiaan Bak

A szerzőről Bastiaan Bak

DBA több mint 15 éves tapasztalattal. Tapasztalat különböző ágakban, több modullal. Beleértve: Oracle database, Oracle RAC, Oracle EBS és PL / SQL.

Bastiaan Bak további hozzászólásai

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.