Investigating the SCN intrinsic growth rate

Written by on in Articles

Julkaistu: 10 heinäkuu 2018 kirjoittaja: Bastiaan Bak Category: IT development and operations

a while ago, we had a warning about the intrinsic growth of the SCN (system change number) in Oracle 12.2 database alert file. Tilanne toistui useita kertoja muutaman viikon sisällä.

”varoitus: SCN: n luontainen kasvunopeus on ollut jatkuvasti
suurempi kuin järjestelmän oletusarvo 16384 sekunnissa viimeisten 60 minuutin ajan.
nykyinen SCN luontainen kasvunopeus on 25867 / s., zas 200fffff!
nykyinen SCN-arvo on 46747726691, SCN-Compat-arvo on 1 ”

ensireaktioni oli, että SCN: t liittyvät pysyviin toimituksiin, joten joko tietokannan kuormitus oli erittäin suuri tai sovelluslogiikkaa pitäisi muuttaa. Toinen mahdollisuus oli, että toimitus tehtiin jokaisen päivityksen jälkeen sen sijaan, että olisi käytetty batch-toimituksia.

se osoittautui hieman monimutkaisemmaksi kuin odotin. Mistä katsot, kun haluat löytää SCN: n ja toimitusten välisen suhteen? Kuinka vakava varoitus on? Tämä blogi tulee olemaan noin eri tavoin olen tutkinut tätä ongelmaa ja tunnistettu mahdollisia vaikutuksia.

Oracle Support notes

varoitustiedostosta voi ensimmäisenä etsiä tietoa varoituksista Oraclen tukisivuilta. Löysin useita aiheeseen liittyviä muistiinpanoja:

  • ORA-19706 ja siihen liittyvät Varoituslokiviestit (Doc ID 1393360.1)
    tämä huomautus viittaa siihen, että varsinainen viesti on spesifinen tietokannan versioon 12.2, mutta vanhemmissa versioissa saattaa olla samanlaisia varoituksia, kuten ”Warning: SCN headroom for this database is only nn days!”
    jos havaitset hälytyslokiviestin, kuten minkä tahansa näistä merkinnöistä, sinun on noudatettava ID 1388639.1: n ohjeita ja kirjattava palvelupyyntö Oraclen tuella.
    kerättävät todisteet raportoitaessa ”High SCN rate” – ongelmista Oracle-tuelle (Doc ID 1388639.1)
  • tämä huomautus antaa tietoa siitä, mitä tietoja sinun tulee toimittaa kirjatessasi palvelupyyntöä.
  • System Change Number (SCN), Headroom, Security and Patch Information (Doc ID 1376995.1)
    tämä huomautus antaa lisätietoja SCN: n käytöstä. System change number (SCN) on Oraclen tietokannan käyttämä looginen sisäinen aikaleima. SCNs Tilaa tapahtumia, jotka tapahtuvat tietokannassa. Tietokanta käyttää SCNs: ää kyselyihin ja muutosten seuraamiseen. Kun tapahtuma sitoutuu, tietokanta tallentaa tämän toimituksen SCN: n.
    on yläraja sille, montako SCN: ää Oraclen tietokanta voi käyttää. Raja on tällä hetkellä 281 biljoonaa (2^48) SCN-arvoa.
    koska on olemassa yläraja, on tärkeää, että kaikista tietystä Oraclen tietokannasta ei lopu saatavilla olevat SCN: t.
    lapussa kerrotaan myös, milloin varoitus nostetaan. Oraclen tietokanta laskee” ei saa ylittää ” – rajan niiden SCN: ien määrälle, joita tietokanta voi tällä hetkellä käyttää, perustuen vuodesta 1988 lähtien kerrottuun sekuntimäärään 16384: llä. Näin varmistetaan, että Oracle tietokannat säännöstellä SCNs ajan.

kuinka vakava tämä varoitus on?

varoitusta nostetaan 2^14 = 16384 SCNs sekunnissa viimeisten 60 minuutin ajan.
suurin SCN on 2^48 = 281.474.976.710.656.

16348 SCN: n sekuntivauhdilla meillä on 2^(48-14) sekuntia eli 544 vuotta aikaa saavuttaa tuo maksimi. Sen pitäisi riittää normaalitilanteessa, mutta yläraja 2^48 on vain suurin itseisarvo, jonka tietokanta voi tallentaa.
raja liittyy myös sekuntimäärään vuodesta 1988 lähtien. Raja 2^48 on maksimi vuonna 2532 (1988+544). Mutta vuonna 2018 maksimi on (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

varoitusta ei tule jättää huomiotta. Kun saavutat rajan saat ora-600 virheitä, mutta kun saavutat absoluuttisen ylärajan SCN tietokanta vain lakkaa toimimasta.

hyvä uutinen on, että meidän tilanteessamme varoituksen mukaan SCN: n kasvuvauhti oli 25867 sekunnissa kyseisenä tiettynä tuntina, joten sillä tunnilla tulimme hieman lähemmäs (25867-16384=9483) rajaa. Emme tule lähelle rajaa joka tunti; normaali kasvunopeus on pienempi kuin 16384.

Oracle Support

soitimme Oracle Supportille, ja he kertoivat Oraclen kehityksen toimivan parhaillaan tämän asian parissa.
Oraclen tuki vahvisti, että SCN: n pääntila näyttää hyvältä. AWR-raportin perusteella Oraclen tuki huomasi suuren määrän toimituksia ja ehdotti, että sovellustiimi tarkistaisi toimitusten koon kasvattamalla.

tutkimus AWR

varoitustiedoston varoitus kertoi, että SCN: n luontainen kasvunopeus on ollut jatkuvasti suurempi kuin järjestelmän oletusarvo: 16384 sekunnissa viimeisten 60 minuutin ajan. Jos katsomme tunnin aikataulua, AWR-raportti voisi olla hyvä paikka aloittaa. Meillä on AWR määritetty tekemään tilannekuvia tunnin välein.

AWR-raportissa huomasin, että käyttäjien toimitusten määrä oli 210 sekunnissa. Kyllä, se on paljon toimituksia, mutta se ei ole kovin erilainen kuin normaali kuormitus tämän tietokannan. Ja jos toimitus liittyy SCN: ään, se on myös paljon pienempi kuin 16384 sekunnissa.

AWR-raportti sisälsi myös ADDM-havainnon: Waits on event ”log file sync”, kun taas COMMIT-ja ROLLBACK-operaatiot kuluttivat merkittävää tietokantaaikaa. Tutki sovelluslogiikkaa COMMIT-toimintojen määrän mahdollista vähentämistä kasvattamalla transaktioiden kokoa.
myös Oraclen tuki ehdotti tätä lisähuomautusten vähentämistä. Minun näkökulmastani se ei kuitenkaan ollut kovin korkea.

lyhyempi aikaväli

koska AWR ei auttanut minua löytämään syytä, minun piti tutkia lyhyempi aikaväli. Halusin tietää tarkemman aikataulun, jotta voisin laatia ASH-raportin. Tuhkan oletusarvo on 15 minuuttia.
joten seuraava haaste oli löytää 15 minuutin aikataulu, jossa SCN: n kasvuvauhti oli suurin.
Doc ID 1388639.1 ehdotti kyselyä v$archived_log. Tämä näkymä sisältää tiedot kaikista tietokannan lokikytkimistä, mukaan lukien aikaleima ja SCN. Vaikka voisit kartoittaa aikaleimat SCNs, se ei ole oikeastaan parempi kuin AWR raportti. Olemme edelleen kiinni satunnainen aikaleimat; tässä tapauksessa aikaleima logswitch.

käyttämällä funktiota timestamp_to_scn

parempi tapa on käyttää funktiota timestamp_to_scn. Tämä funktio palauttaa SCN: n aikaleiman perusteella, kuten nykyisen aikaleiman:

     
  1. SQL> valitse aikaleima_to_scn (sysdate) duaalista ;
    2.  
  2.  
    3.  
  3. TIMESTAMP_TO_SCN(SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7. SQL> 
    8.

seuraava askel oli tehdä luettelo aikaleimoista yhdessä vastaavan SCN: n ja vastaavan SCN: n ylärajan kanssa, joka perustuu vuodesta 1988 lähtien kerrottuun sekuntimäärään 16 384: llä.

tämä näyttää viimeisen päivän aikaleimat ja SCN: t:

     
  1.  valitse sysdate - (rownum/24) datetimestamp
    2.  
  2.  , aikaleima_to_scn(sysdate - (rownum / 24)) SCN
    3.  
  3.  , ((sysdate - (rivi 24) - to_date ("01-01-1988", "pp-kk-vvvv' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 ylä_lmt
    5.  
  5.  DUAALISTA
    6.  
  6.  yhdistä rivinummella <= 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 rivit valittu. 
    29.

nykyinen SCN on noin 0,57 prosenttia nykyisestä ylärajasta.

parhaan SCN-arvon löytäminen

tämän idean pohjalta loin kyselyn, joka antaa minulle 15 minuutin aikajakson, jossa SCN-arvot ovat kasvaneet eniten viimeisen 3 päivän aikana.

joka minuutti alkaa uusi aikataulu, ja koska meillä on 1440 minuuttia päivässä, meillä on 4320 aikataulua tutkittavana. Jokaiselle niistä meidän on laskettava SCN: n kasvu kyseisen 15 minuutin määräajan kuluessa.

haluamme näyttää vain huipputulokset, tässä tapauksessa vain aikavälit, joissa nopeus on yli 14000 sekunnissa.

     
  1.  ALTER SESSION SET nls_date_format= "MM / DD / YY HH24: MI" ;
    2.  
  2.  
    3.  
  3.  datelistalla nimellä 
    4.  
  4.  ( valitse sysdate - (rownum/1440) - (15/1440) starttiaika -- 15 minuutin aikaväli 
    5.  
  5.  , sysdate - (rownum/1440) endtime
    6.  
  6.  DUAALISTA
    7.  
  7.  yhdistä rivinummella <= (3*1440) -- 3 päivien historia 
    8.  
  8. )
    9.  
  9.  valitse starttiaika
    10.  
  10.  , endtime
    11.  
  11.  , aikaleima_to_scn (endtime) - aikaleima_to_scn (starttime) scngrowth
    12.  
  12.  , round ((timestamp_to_scn (endtime) - timestamp_to_scn (starttime)) / 
    13.  
  13.  (((24*60*60)*(endtime-starttime )))) scnrate
    14.  
  14.  DATALISTALTA
    15.  
  15.  WHERE round ((timestamp_to_scn (endtime) - timestamp_to_scn (starttime)) / 
    16.  
  16.  (((24*60*60)*(endtime-starttime )))) >= 14000 
    17.  
  17.  tilaa 4 DESC 
    18.  
  18. /
    19.  
     
  1. alkamisaika päättymisaika 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.

niin, nyt olemme löytäneet (joskus päällekkäisiä) 15 minuutin aikaväleillä korkein SCN korko (SCN kasvua sekunnissa) viimeisen 3 päivää. Ja niissäkin aikakehyksissä SCN-korko on vielä alle 16384. Ei varoituksia hälytystiedostossa tällä viikolla….

suoritettaessa ASH-raporttia

yllä olevassa kyselyssä käyttämäni päivämäärämuoto on sama kuin ASH-raportissa, joten voit kopioida/liittää alkamisajan. Ajaksi tulemme 15 minuuttia.

     
  1. SQL> @ @ $ORACLE_HOME/rdbms/admin / ashrpt.sql
    2.  
  2.  
    3.  
  3. TUHKANÄYTTEET tässä työmäärässä arkiston skeemassa
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. vanhin saatavilla oleva TUHKANÄYTE: 01-heinäkuu-18 00:00:01 
    7.  
  7. viimeisin TUHKANÄYTE saatavilla: 09-heinäkuu-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. TUHKAPÖYTÄKIRJAN laatimisajankohta
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. Anna raportin alkamisaika:
    13.  
  13.  
    14.  
  14. -- kelvolliset syöttömuodot:
    15.  
  15. -- absoluuttisen alkamisajan määrittäminen:
    16.  
  16. -- ] HH24: MI
    17.  
  17. -- esimerkkejä: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- suhteellisen alkamisajan määrittäminen: (aloita merkillä' -')
    22.  
  22. -- - MI
    23.  
  23. -- esimerkkejä: -1:15 (SYSDATE - 1 h 15 min)
    24.  
  24. -- -25 (SYSDATE-25 min)
    25.  
  25.  
    26.  
  26. oletusarvo -15 min
    27.  
  27. anna arvo BEGIN_TIMELLE: 07/06/18 18:09
    28.  
  28. raportin alkamisaika määritelty: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. Anna kesto minuutteina alkamisajasta alkaen:
    31.  
  31. oletus: SYSDATE-begin_time
    32.  
  32. paina Enter analysoidaksesi ajankohtaan asti 
    33.  
  33. Anna duraation arvo: 15 
    34.  
  34. raportin kesto määritelty: 15 
    35.  
  35.  
    36.  
  36.  käyttämällä 06-heinä-18 18: 09: 00 raportin alkamisaika 
    37.  
  37.  käyttäen 06-heinä-18 18:24:00 kuin raportin päättymisaika 
    38.  
  38.  
    39.  
  39. Anna raportin nimi
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. raportin oletustiedoston nimi on ashrpt_1_0706_1824.html. Tämän nimen käyttäminen, 
    42.  
  42. paina <palauta> jatkaaksesi, muuten syötä vaihtoehto. 
    43.  
  43. anna arvo raportin_nimelle:
    44.  
  44.  
    45.  
  45.  käyttäen raporttinimeä ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47. yhteenveto kaikista käyttäjän syötteistä 
    48.  
  48. -------------------------
    49.  
  49. muoto: HTML
    50.  
  50. DB Id : 2019395491 
    51.  
  51. Inst num : 1 
    52.  
  52.  alkamisaika: 06-heinäkuu-18 18:09:00
    53.  
  53.  loppuaika: 06-heinä-18 18:24:00
    54.  
  54. raon leveys: oletus 
    55.  
  55. Raportoikaa tavoitteista : 0 
    56.  
  56. raportin nimi : ashrpt_1_0706_1824.html
    57.

SCN: n löytäminen AWR: stä

AWR-raportti ei näyttänyt meille paljoakaan tietoa nykyisestä SCN: stä, mutta siinä on joitain tietoja kasvunopeudesta, jos tiedät mistä sen löytää.

kohdasta ” Instance Activity Stats ”löydät”calls to kcmgas” – puhelujen määrän. Oraclen dokumentaatiossa tätä kuvataan ”soittojen lukumääräksi rutiininomaiseen KCMGAS: iin uuden SCN: n saamiseksi”.

näiden puhelujen arvo sekunnissa AWR-raportissa on hyvin lähellä SCN-arvoa, joka on laskettu timestamp_to_scn-funktiolla.

V$SESSTAT view

the number of ”calls to kcmgas” used to create a new SCN can also found in the views V$SESSTAT and V$SYSSTAT.

Voimme käyttää V$SESSTATIA löytääksemme istuntoja, jotka aiheuttavat suuren SCN-nopeuden. Voimme myös testata vaikutusta SCN: n määrään erityisiä toimia.

esimerkiksi, kun teen valinnan Isolla pöydällä, joka on myös muiden istuntojen käytössä, istuntoni tekee toiset 7 puhelua kcmgas: iin. Kyselyni aiheuttaa suuremman SCN: n. Tämä johtuu tietokannan lukemisesta, joka käyttää myös SCN: ää.

     
  1. SQL> CONNECT < user> / < pass>@< service> 
    2.  
  2. yhteys. 
    3.  
  3. SQL> valitse ses.arvo
    4.  
  4.  alkaen v$sesstat ses
    5.  
  5.  , v$statname stat
    6.  
  6.  sinne heti.tilasto#=ses.tilasto#
    7.  
  7.  ja ses.sid IN (valitse Sid alkaen v$mystat) 
    8.  
  8.  ja heti.name = "puhelut kcmgas: iin' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  arvo 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL> valitse lukumäärä (*) mybigtablesta ;
    16.  
  16.  
    17.  
  17.  lukumäärä(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL> valitse ses.arvo
    22.  
  22.  alkaen v$sesstat ses
    23.  
  23.  , v$statname stat
    24.  
  24.  sinne heti.tilasto#=ses.tilasto#
    25.  
  25.  ja ses.sid IN (valitse Sid alkaen v$mystat) 
    26.  
  26.  ja heti.name = "puhelut kcmgas: iin' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  arvo 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

vertaamalla SCN-ja commit rate

kanssa v$SESSTAT voimme kysellä tilastoja kaikista tietokantaan tällä hetkellä liitetyistä istunnoista. Näin voimme löytää istuntoja, jotka ovat vastuussa korkea SCN korko. Voimme verrata tätä istunnon toimitusasteeseen.

alla olevan kyselyn tulokset osoittivat, että suuri SCN-nopeus johtui Tietokannassamme pääasiassa taustaprosesseista. Useimpien käyttäjien istunnoissa on suhde korkean SCN-nopeuden ja korkean toimitusnopeuden välillä, Tausta-istunnoissa toimitusnopeus on aina tyhjä.

     
  1.  valitse ses.sid
    2.  
  2.  , dekoodaus(ses.käyttäjätunnus, NULL, 'Tausta', 'käyttäjä') session_type
    3.  
  3.  , (sysdate-logon_time) * 24 * 60 * 60 connect_seconds
    4.  
  4.  , sstat1.arvo SCN#
    5.  
  5.  , sstat2.arvo toimitus#
    6.  
  6.  , kierros (sstat1.arvo / ((sysdate-logon_time ) * 24 * 60 * 60),2) _arvosta
    7.  
  7.  , kierros (sstat2.arvo / ((sysdate-logon_time ) * 24 * 60 * 60),2) _toimita
    8.  
  8.  alkaen v$sesstat sstat1
    9.  
  9.  , v$sesstat sstat2
    10.  
  10.  , v$statname sn1
    11.  
  11.  , v$statname sn2
    12.  
  12.  , v$istunto ses
    13.  
  13.  missä sstat1.tilasto# = sn1.tilasto#
    14.  
  14.  ja sstat2.tilasto# = sn2.tilasto#
    15.  
  15.  ja sn1.name = "puhelut kcmgas: iin' 
    16.  
  16.  ja sn2.name = "käyttäjä toimittaa' 
    17.  
  17.  ja ses.sid = sstat1.sid
    18.  
  18.  ja ses.sid = sstat2.sid
    19.  
  19.  tilaa 6 DESC 
    20.  
  20. /
    21.  
  21.  
    22.  
  22.  SID SESSION_TY CONNECT_SECONDS SCN# COMMIT# SCN_RATE COMMIT_RATE
    23.  
  23. ---------- ---------- --------------- ---------- ---------- ---------- -----------
    24.  
  24.  8478 Tausta 459572 214506344 0 466.75 0 
    25.  
  25.  7551 Tausta 452395 209729934 0 463.6 0 
    26.  
  26.  3776 Tausta 290389 133863489 0 460.98 0 
    27.  
  27.  8496 Tausta 121201 55685740 0 459.45 0 
    28.  
  28.  8729 Tausta 286773 128180386 0 446.98 0 
    29.  
  29.  12009 Tausta 290392 128867329 0 443.77 0 
    30.  
  30.  13173 Tausta 196775 87268032 0 443.49 0 
    31.  
  31.  12004 Tausta 103166 45681480 0 442.8 0 
    32.  
  32.  8735 Tausta 275980 121563094 0 440.48 0 
    33.  
  33.  3096 Tausta 430810 185436599 0 430.44 0 
    34.  
  34.  8027 Tausta 95990 40912187 0 426.21 0 
    35.  
  35.  7529 Tausta 193218 81367643 0 421.12 0 
    36.  
  36.  2370 Tausta 527978 219521415 0 415.78 0 
    37.  
  37.  14604 Tausta 283216 117052382 0 413.3 0 
    38.  
  38.  14132 Tausta 113965 46586388 0 408.78 0 
    39.  
  39.  7552 Tausta 294009 119775077 0 407.39 0 
    40.  
  40.  13172 Tausta 182423 73865595 0 404.91 0 
    41.  
  41.  14592 Tausta 74414 29767705 0 400.03 0 
    42.  
  42.  3802 Tausta 268804 107486102 0 399.87 0 
    43.  
  43.  9910 Tausta 117582 46596720 0 396.29 0 
    44.  
  44.  12021 Tausta 49182 19321676 0 392.86 0 
    45.  
  45.  974 Tausta 160816 59996495 0 373.08 0 
    46.  
  46.  12723 Tausta 74450 25455559 0 341.91 0 
    47.  
  47.  3310 Tausta 193215 65915175 0 341.15 0 
    48.  
  48.  12963 Tausta 49179 15687084 0 318.98 0 
    49.  
  49.  6111 Tausta 3584090 1031139557 0 287.7 0 
    50.  
  50.  6829 käyttäjä 303 1267 1123 4.18 3.71 
    51.  
  51.  9665 käyttäjä 904 1845 1691 2.04 1.87 
    52.  
  52.  8022 käyttäjä 898 1677 1520 1.87 1.69 
    53.  
  53.  3323 käyttäjä 898 1406 1260 1.57 1.4 
    54.  
  54.  2839 käyttäjä 7503 10822 9813 1.44 1.31 
    55.  
  55.  11060 käyttäjä 3892 5334 4781 1.37 1.23 
    56.  
  56.  13184 käyttäjä 1765 2359 2038 1.34 1.15 
    57.  
  57.  9199 käyttäjä 898 1135 935 1,26 1.04 
    58.  
  58.  2130 KÄYTTÄJÄ 8105 9548 8518 1.18 1.05 
    59.  
  59.  11525 KÄYTTÄJÄ 898 1054 944 1.17 1.05 
    60.  
  60.  6130 KÄYTTÄJÄ 3895 4453 4199 1.14 1.08 
    61.  
  61.  8012 KÄYTTÄJÄ 7503 8576 7774 1.14 1.04 
    62.  
  62.  4497 KÄYTTÄJÄ 898 962 882 1,07 .98
    63.  
  63.  5201 käyttäjä 7220 7551 6226 1,05 .86
    64.  
  64.  11317 käyttäjä 12906 13371 11997 1,04 .93
    65.  
  65.  
    66.  
  66.  
    67.  
  67.  1979 rivit valittu. 
    68.

johtopäätös

ole tietoinen siitä, että SCN: llä on rajansa, joten kun löydät varoituksia varoitustiedostosta, sinun on tutkittava ongelma. Jos löydät ongelman, sinun pitäisi työskennellä Oraclen tuella. Lataamalla tietoja he voivat tarkistaa, onko nykyisen ja suurimman SCN: n välillä tarpeeksi tilaa.

ongelmat voivat johtua viasta, kuten 12371955: kuuma varmuuskopiointi voi aiheuttaa SCN: n kasvunopeuden kasvun, joka johtaa ORA-600 virheeseen (Doc ID 12371955.8).

jos haluat löytää tarkan ajankohdan, jolloin SCN: t kasvavat voimakkaasti, sinun on muunnettava aikaleimat SCN: ksi. Saat parhaat tulokset käyttämällä toimintoja SCN_TO_TIMESTAMP ja TIMESTAMP_TO_SCN.

suuri toimitusaste liittyy aina käyttäjäprosesseihin, mutta SCN: t liittyvät myös taustaprosesseihin. Jopa istunnot, jotka eivät toimita, voivat vaikuttaa SCN: ään.

Bastiaan Bak

tekijästä Bastiaan Bak

DBA yli 15 vuoden kokemuksella. Kokemusta eri aloilla, useita moduuleja. Sisältää: Oracle database, Oracle RAC, Oracle EBS ja PL/SQL.

More posts by Bastiaan Bak

Vastaa

Sähköpostiosoitettasi ei julkaista.