zkoumání vnitřní míry růstu SCN

Written by on in Articles

Publikováno dne: 10 červenec 2018 Autor: Bastiaan Bak Kategorie: Vývoj a provoz IT

před chvílí jsme měli varování o vnitřním růstu SCN (číslo změny systému) v našem souboru výstrah databáze Oracle 12.2. Tato situace nastala několikrát během několika týdnů.

„varování: vnitřní rychlost růstu SCN byla trvale
vyšší než výchozí systém 16384 za sekundu. za posledních 60 minut.
aktuální rychlost vnitřního růstu SCN je 25867 za sekundu, zas 200fffff!
aktuální hodnota SCN je 46747726691, hodnota SCN Compat je 1 “

moje počáteční reakce byla, že SCN souvisí s commity, takže buď zatížení databáze bylo velmi vysoké, nebo by měla být změněna aplikační logika. Další možností bylo, že odevzdání bylo provedeno po každé aktualizaci, namísto použití dávkových odevzdání.

ukázalo se, že je to trochu komplikovanější, než jsem čekal. Kde se díváte, když chcete najít vztah mezi SCN a commity? A jak vážné je toto varování vůbec? Tento blog bude o různých způsobech, jak jsem tento problém prozkoumal a identifikoval potenciální dopad.

Poznámky k podpoře Oracle

první místo, kde se hledají informace o varováních v souboru upozornění, je webová stránka podpory Oracle. Našel jsem několik souvisejících poznámek:

  • ora-19706 a související zprávy záznamu upozornění (Doc ID 1393360.1)
    tato poznámka naznačuje, že skutečná zpráva je specifická pro verzi databáze 12.2, ale ve starších verzích můžeme mít podobná varování ,jako “ varování: světlá výška SCN pro tuto databázi je pouze NN dny!“
    pokud narazíte na zprávu záznamu upozornění, jako je kterákoli z těchto položek, doporučujeme postupovat podle pokynů v ID 1388639.1 a přihlásit požadavek na službu s podporou Oracle.
    důkazy, které je třeba shromáždit při hlášení problémů s „vysokou mírou SCN“ podpoře Oracle (Doc ID 1388639.1)
  • tato poznámka poskytuje informace o tom, jaké informace byste měli poskytnout při protokolování požadavku na službu.
  • číslo změny systému (SCN), světlá výška, zabezpečení a informace o opravě (Doc ID 1376995.1)
    tato poznámka poskytuje více informací o použití SCN. Číslo změny systému (SCN) je logické interní časové razítko používané databází Oracle. SCNs objednává události, které se vyskytují v databázi. Databáze používá SCN k dotazování a sledování změn. Když se transakce zaváže, databáze zaznamená SCN pro toto odevzdání.
    existuje horní limit, kolik SCN může databáze Oracle použít. Limit je v současné době 281 bilionů (2^48) hodnot SCN.
    vzhledem k tomu, že existuje horní limit, je důležité, aby žádná daná databáze Oracle nevyčerpala dostupné SCN.
    poznámka také vysvětluje, kdy je varování zvýšeno. Databáze Oracle vypočítá limit „nepřekročit“ pro počet SCN, který může databáze v současné době používat, na základě počtu sekund od roku 1988 vynásobeného 16384. Tím je zajištěno, že databáze Oracle budou v průběhu času rozdělovat SCN.

jak závažné je toto varování?

varování se zvyšuje rychlostí 2^14 = 16384 SCN za sekundu za posledních 60 minut.
maximální SCN je 2^48 = 281.474.976.710.656.

při rychlosti 16348 SCN za sekundu budeme mít 2^(48-14) sekund nebo 544 let, abychom dosáhli tohoto maxima. To by mělo stačit v normální situaci, ale horní hranice 2^48 je pouze maximální absolutní hodnota, kterou může databáze uložit.
limit souvisí také s počtem sekund od roku 1988. Limit 2^48 je maximální v roce 2532 (1988+544). Ale v roce 2018 je maximum (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

varování by nemělo být ignorováno. Když dosáhnete limitu, dostanete chyby ora-600, ale když dosáhnete absolutní horní hranice SCN, databáze přestane fungovat.

dobrou zprávou je, že v naší situaci varování uvedlo, že rychlost růstu SCN byla 25867 za sekundu v této konkrétní hodině, takže v této hodině jsme se trochu přiblížili (25867-16384=9483) k limitu. Nepřibližujeme se k limitu každou hodinu; normální tempo růstu je nižší než 16384.

Podpora Oracle

zavolali jsme podporu Oracle a řekli nám, že vývoj Oracle v současné době pracuje na tomto problému.
Podpora Oracle potvrdila, že světlá výška SCN vypadá dobře. Na základě zprávy AWR si Podpora Oracle všimla vysokého počtu commitů a navrhla, aby se u aplikačního týmu ověřilo, zda se zavazuje zvýšením velikosti transakce.

vyšetřování s AWR

varování v souboru výstrahy nám řeklo, že vnitřní rychlost růstu SCN byla trvale vyšší než výchozí nastavení systému: 16384 za sekundu za posledních 60 minut. Pokud se díváme na časový rámec hodiny, zpráva AWR by mohla být dobrým místem pro začátek. Máme AWR nakonfigurován tak, aby se snímky každou hodinu.

ve zprávě AWR jsem si všiml, že počet uživatelských commitů byl 210 za sekundu. Ano, To je hodně commitů, ale není to tak odlišné od normálního zatížení této databáze. A pokud commit souvisí s SCN, je také mnohem nižší než 16384 za sekundu.

zpráva AWR také obsahovala zjištění ADDM: čekání na událost „synchronizace souborů protokolu“ při provádění operací odevzdání a vrácení vyžadovalo značný čas v databázi. Prozkoumejte logiku aplikace pro možné snížení počtu operací odevzdání zvýšením velikosti transakcí.
toto snížení commitů ve zjištění ADDM bylo také navrženo podporou Oracle. Z mého pohledu to ale nebylo tak vysoké.

kratší časový rámec

protože mi AWR nepomáhalo najít příčinu, musel jsem prozkoumat kratší časový rámec. Chtěl jsem znát konkrétnější časový rámec, abych mohl vytvořit ASH zprávu. Výchozí hodnota pro popel je 15 minut.
takže další výzvou bylo najít 15 minutový časový rámec, ve kterém byla míra růstu SCN nejvyšší.
Doc ID 1388639.1 navrhl dotaz v$archived_log. Tento pohled obsahuje informace o všech přepínačích protokolu v databázi, včetně časového razítka a SCN. Ačkoli byste mohli mapovat časová razítka na SCN, není to opravdu lepší než zpráva AWR. Stále se držíme náhodných časových razítek; v tomto případě časové razítko logswitch.

pomocí funkce timestamp_to_scn

je lepší použít funkci timestamp_to_scn. Tato funkce vrací SCN na základě časového razítka, jako je aktuální časové razítko:

     
  1. SQL> vyberte timestamp_to_scn(sysdate) z duálního ;
    2.  
  2.  
    3.  
  3. TIMESTAMP_TO_SCN (SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7. SQL> 
    8.

dalším krokem bylo vytvoření seznamu časových razítek spolu s odpovídajícím SCN a odpovídajícím horním limitem SCN na základě počtu sekund od roku 1988 vynásobeného 16 384.

zobrazuje časová razítka a SCN za poslední den:

     
  1.  vyberte 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-RRRR' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  z duálního
    6.  
  6.  připojit pomocí 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 vybrané řádky. 
    29.

aktuální SCN je asi 0,57% aktuální horní hranice.

nalezení nejvyšší míry SCN

na základě této myšlenky jsem vytvořil dotaz, který mi dává 15 minutový časový rámec s nejvyšším růstem SCN za poslední 3 dny.

každou minutu začíná nový časový rámec, a protože máme 1440 minut za den, máme 4320 časových rámců k prozkoumání. Pro každou z nich musíme vypočítat růst SCN v tomto 15 minutovém časovém rámci.

chceme zobrazit pouze nejlepší výsledky, v tomto případě pouze časové rámce s rychlostí přes 14000 za sekundu.

     
  1.  ALTER session SET nls_date_format='MM/DD/RR HH24:MI' ;
    2.  
  2.  
    3.  
  3.  s datelist jako 
    4.  
  4.  ( vyberte sysdate - (rownum/1440) - (15/1440) starttime -- 15 minutový interval 
    5.  
  5.  , sysdate - (rownum/1440) endtime
    6.  
  6.  z duálního
    7.  
  7.  připojit pomocí rownum <= (3*1440) -- 3 historie dnů 
    8.  
  8. )
    9.  
  9.  vyberte starttime
    10.  
  10.  , konec času
    11.  
  11.  , timestamp_to_scn (endtime) - timestamp_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.  z datelist
    15.  
  15.  kde kolo ((timestamp_to_scn (endtime) - timestamp_to_scn(starttime)) / 
    16.  
  16.  (((24*60*60)*(endtime-starttime )))) >= 14000 
    17.  
  17.  pořadí podle 4 DESC 
    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.

nyní jsme našli (někdy překrývající se) 15minutové časové rámce s nejvyšší rychlostí SCN (růst SCN za sekundu) za poslední 3 dny. A i v těchto časových rámcích je míra SCN stále pod 16384. Žádné varování v souboru upozornění Tento týden….

spuštění Ash reportu

formát data, který jsem použil ve výše uvedeném dotazu, je stejný jako použitý Ash report, takže stačí zkopírovat/vložit počáteční čas. Po dobu trvání zadáme 15 minut.

     
  1. SQL> @@$ORACLE_HOME/rdbms / admin / ashrpt.sql
    2.  
  2.  
    3.  
  3. vzorky popela v tomto schématu úložiště pracovní zátěže
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. nejstarší vzorek popela k dispozici: 01-Jul-18 00:00:01 
    7.  
  7. nejnovější vzorek popela k dispozici: 09-Jul-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. uveďte časový rámec pro vygenerování zprávy ASH
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. Zadejte čas začátku sestavy:
    13.  
  13.  
    14.  
  14. -- platné vstupní formáty:
    15.  
  15. -- Chcete-li určit absolutní čas začátku:
    16.  
  16. -- ] HH24: MI
    17.  
  17. -- příklady: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- Chcete-li zadat relativní čas začátku: (začněte znakem '-' )
    22.  
  22. -- -MI
    23.  
  23. -- příklady: -1:15 (SYSDATE-1 hod 15 min)
    24.  
  24. -- -25 (SYSDATE-25 minut)
    25.  
  25.  
    26.  
  26. Výchozí hodnota -15 minut
    27.  
  27. zadejte hodnotu pro begin_time: 07/06/18 18:09
    28.  
  28. zpráva začíná čas zadán: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. zadejte dobu trvání v minutách počínaje časem začátku:
    31.  
  31. Výchozí hodnota SYSDATE-begin_time
    32.  
  32. stisknutím klávesy Enter analyzovat do aktuálního času 
    33.  
  33. zadejte hodnotu pro dobu trvání: 15 
    34.  
  34. doba trvání zprávy je stanovena: 15 
    35.  
  35.  
    36.  
  36.  použití 06-Jul-18 18: 09: 00 jako čas zahájení zprávy 
    37.  
  37.  použití 06-Jul-18 18: 24: 00 jako čas ukončení zprávy 
    38.  
  38.  
    39.  
  39. zadejte název sestavy
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. výchozí název souboru sestavy je ashrpt_1_0706_1824.html. Chcete-li použít tento název, 
    42.  
  42. stiskněte <návrat> pro pokračování, jinak zadejte alternativu. 
    43.  
  43. zadejte hodnotu pro název_ reportů:
    44.  
  44.  
    45.  
  45.  použití názvu sestavy ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47. shrnutí všech uživatelských vstupů 
    48.  
  48. -------------------------
    49.  
  49. formát: HTML
    50.  
  50. DB Id : 2019395491 
    51.  
  51. Inst num : 1 
    52.  
  52.  čas zahájení: 06-Jul-18 18:09:00
    53.  
  53.  čas ukončení: 06-Červenec-18 18:24:00
    54.  
  54. šířka slotu: výchozí 
    55.  
  55. nahlásit cíle : 0 
    56.  
  56. název zprávy : ashrpt_1_0706_1824.html
    57.

nalezení SCN v AWR

zpráva AWR nám neukázala mnoho informací o aktuálním SCN, ale má nějaké informace o rychlosti růstu, pokud víte, kde ji najdete.

v části „statistiky aktivity Instance“ najdete počet „volání na kcmgas“. V dokumentaci Oracle je to popsáno jako „počet hovorů na rutinní kcmgas, aby získal nový SCN“.

hodnota těchto hovorů za sekundu ve zprávě AWR je velmi blízká rychlosti SCN vypočtené pomocí funkce timestamp_to_scn.

V $ SESSTAT view

počet „volání na kcmgas“ použitých k vytvoření nového SCN lze také nalézt v pohledech v$SESSTAT a V$SYSSTAT.

můžeme použít V$SESSTAT k nalezení relací, které způsobují vysokou míru SCN. Můžeme také otestovat dopad na SCN počet konkrétních akcí.

například, když dělám výběr na velkém stole, který je také používán jinými relacemi, Moje relace provede další 7 volání na kcmgas. Takže můj dotaz způsobí vyšší SCN. To je způsobeno konzistencí čtení databáze, která také používá SCN.

     
  1. SQL> připojit < uživatel> / <projít> @< služba> 
    2.  
  2. připojeno. 
    3.  
  3. SQL> vyberte ses.hodnota
    4.  
  4.  od v$sesstat ses
    5.  
  5.  , v$statname stat
    6.  
  6.  kde stat.statistika#=ses.statistika#
    7.  
  7.  a ses.sid v (vyberte sid z v$mystat) 
    8.  
  8.  a stat.name = 'volání do kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  hodnota 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL> vyberte počet (*) z mybigtable ;
    16.  
  16.  
    17.  
  17.  počet(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL> vyberte ses.hodnota
    22.  
  22.  od v$sesstat ses
    23.  
  23.  , v$statname stat
    24.  
  24.  kde stat.statistika#=ses.statistika#
    25.  
  25.  a ses.sid v (vyberte sid z v$mystat) 
    26.  
  26.  a stat.name = 'volání do kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  hodnota 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

porovnáním míry SCN a odevzdání

s v$SESSTAT můžeme dotazovat statistiky pro všechny relace aktuálně připojené k databázi. Tímto způsobem můžeme najít relace, které jsou zodpovědné za vysokou míru SCN. Můžeme to porovnat s mírou odevzdání pro danou relaci.

výsledky níže uvedeného dotazu nám ukázaly, že v naší databázi byla vysoká míra SCN způsobena hlavně procesy na pozadí. U většiny uživatelských relací existuje vztah mezi vysokou mírou SCN a vysokou mírou odevzdání, u relací na pozadí je míra odevzdání vždy prázdná.

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

závěr

uvědomte si, že existují limity SCN, takže když najdete varování v souboru upozornění, musíte problém prozkoumat. Pokud zjistíte problém, měli byste pracovat s podporou Oracle. Nahráním informací mohou zkontrolovat, zda je mezi aktuálním a maximálním SCN dostatek místa.

problémy mohou být způsobeny chybou, jako je 12371955: Hot Backup může způsobit zvýšenou rychlost růstu SCN vedoucí k chybám ora-600 (Doc ID 12371955.8).

pokud chcete najít přesný okamžik, kdy dochází k vysokému růstu SCN, musíte převést časová razítka na SCN. Nejlepší výsledky získáte pomocí funkcí SCN_TO_TIMESTAMP a TIMESTAMP_TO_SCN.

vysoká míra odevzdání je vždy spojena s uživatelskými procesy, ale SCN jsou také spojeny s procesy na pozadí. Dokonce i relace, které se nezavazují, mohou mít dopad na SCN.

Bastiaan Bak

o autorovi Bastiaan Bak

DBA s více než 15 let zkušeností. Zkušenosti v různých odvětvích, s několika moduly. Včetně: Databáze Oracle, Oracle RAC, Oracle EBS a PL / SQL.

více příspěvků od Bastiaan Bak

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.