Investigating the SCN intrinsic growth rate

Written by on in Articles

Published on: 10 luglio 2018 Author: Bastiaan Bak Category: IT development and operations

Qualche tempo fa, abbiamo avuto un avvertimento sulla crescita intrinseca del SCN (system change number) nel nostro file di avviso del database Oracle 12.2. Questa situazione si è verificata più volte nel giro di poche settimane.

“Attenzione: il tasso di crescita intrinseco SCN è stato costantemente
superiore a quello predefinito del sistema 16384 al sec. per gli ultimi 60 minuti.
Corrente SCN tasso di crescita intrinseca è 25867 al sec., zas 200fffff!
Il valore SCN corrente è 46747726691, il valore SCN Compat è 1 ”

La mia reazione iniziale è stata che gli SCN sono correlati ai commit, quindi il carico sul database era molto alto o la logica dell’applicazione dovrebbe essere cambiata. Un’altra possibilità era che un commit fosse fatto dopo ogni aggiornamento, invece di usare commit batch.

Si è rivelato un po ‘ più complicato di quanto mi aspettassi. Dove guardi quando vuoi trovare la relazione tra SCN e commit? E quanto è grave questo avvertimento comunque? Questo blog sarà sui vari modi in cui ho studiato questo problema e identificato il potenziale impatto.

Oracle Support notes

Il primo posto in cui cercare informazioni sugli avvisi nel file di avviso è il sito Web del supporto Oracle. Ho trovato diverse note correlate:

  • ORA-19706 e relativi messaggi di log di avviso (ID Doc 1393360.1)
    Questa nota suggerisce che il messaggio effettivo è specifico per la versione del database 12.2, ma nelle versioni precedenti potremmo avere avvisi simili, come “Attenzione: l’altezza libera di SCN per questo database è solo NN giorni!”
    Se si verifica un messaggio di log di avviso come una qualsiasi di queste voci, si consiglia di seguire le istruzioni in ID 1388639.1 e registrare una richiesta di servizio con il supporto Oracle.
    Prove da raccogliere quando si segnalano problemi di “high SCN rate” al supporto Oracle (Doc ID 1388639.1)
  • Questa nota fornisce informazioni su quali informazioni è necessario fornire quando si registra una richiesta di servizio.
  • System Change Number (SCN), Headroom, Security and Patch Information (Doc ID 1376995.1)
    Questa nota fornisce ulteriori informazioni sull’utilizzo di SCN. Il System Change Number (SCN) è un timestamp interno logico utilizzato dal database Oracle. Gli SCN ordinano gli eventi che si verificano all’interno del database. Il database utilizza SCN per interrogare e tenere traccia delle modifiche. Quando una transazione esegue il commit, il database registra un SCN per questo commit.
    Esiste un limite superiore al numero di SCN che un database Oracle può utilizzare. Il limite è attualmente 281 trilioni (2^48) valori SCN.
    Dato che esiste un limite superiore, è importante che qualsiasi database Oracle non esaurisca le SCN disponibili.
    La nota spiega anche quando viene generato l’avviso. Il database Oracle calcola un limite “da non superare” per il numero di SCN che un database può attualmente utilizzare, in base al numero di secondi dal 1988 moltiplicato per 16384. In questo modo, i database Oracle razioneranno SCN nel tempo.

Quanto è grave questo avviso?

L’avviso viene generato ad una velocità di 2^14 = 16384 SCN al secondo per gli ultimi 60 minuti.
Il SCN massimo è 2^48 = 281.474.976.710.656.

Ad una velocità di 16348 SCN al secondo, avremo 2^(48-14) secondi, o 544 anni per raggiungere quel massimo. Questo dovrebbe essere sufficiente in una situazione normale, ma il limite superiore di 2^48 è solo il valore assoluto massimo che il database può memorizzare.
Il limite è anche correlato al numero di secondi dal 1988. Il limite di 2^48 è il massimo nell’anno 2532 (1988+544). Ma nel 2018 il massimo è (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

L’avviso non deve essere ignorato. Quando raggiungi il limite otterrai errori ora – 600, ma quando raggiungi il limite superiore assoluto SCN il database smetterà di funzionare.

La buona notizia è che nella nostra situazione l’avvertimento diceva che il tasso di crescita di SCN era 25867 al secondo in quell’ora specifica, quindi in quell’ora ci siamo avvicinati un po ‘ (25867-16384=9483) al limite. Non ci avviciniamo al limite ogni ora; il tasso di crescita normale è inferiore a 16384.

Oracle Support

Abbiamo chiamato Oracle Support e ci hanno detto che Oracle Development sta attualmente lavorando su questo problema.
Il supporto Oracle ha confermato che l’headroom SCN sembra buono. Sulla base del report AWR, il supporto Oracle ha notato un numero elevato di commit e ha suggerito di verificare con il team dell’applicazione di eseguire il commit aumentando le dimensioni della transazione.

Indagine con AWR

L’avviso nel file alert ci ha detto che il tasso di crescita intrinseco SCN è stato costantemente superiore a quello predefinito del sistema: 16384 al secondo per gli ultimi 60 minuti. Se stiamo guardando un lasso di tempo di un’ora, un rapporto AWR potrebbe essere un buon punto di partenza. Abbiamo AWR configurato per fare istantanee ogni ora.

Nel rapporto AWR, ho notato che il numero di commit degli utenti era 210 al secondo. Sì, questo è un sacco di commit, ma non è così diverso dal normale carico di questo database. E se un commit è correlato a un SCN, è anche molto inferiore a 16384 al secondo.

Il report AWR conteneva anche un ADDM finding: Le attese sull’evento “log file sync” durante l’esecuzione di operazioni di COMMIT e ROLLBACK richiedevano molto tempo nel database. Esaminare la logica dell’applicazione per la possibile riduzione del numero di operazioni di COMMIT aumentando la dimensione delle transazioni.
Questa riduzione dei commit nella ricerca ADDM è stata suggerita anche dal supporto Oracle. Dal mio punto di vista, non era davvero così alto però.

Tempi più brevi

Poiché l’AWR non mi stava aiutando a trovare la causa, avevo bisogno di indagare su un periodo di tempo più breve. Volevo sapere un calendario più specifico in modo da poter creare un rapporto ASH. Il valore predefinito per ASH è 15 minuti.
Quindi la prossima sfida era trovare il lasso di tempo di 15 minuti in cui il tasso di crescita di SCN era il più alto.
Doc ID 1388639.1 suggerito per interrogare v archiv archived_log. Tale vista contiene informazioni su tutte le opzioni di registro sul database, incluso un timestamp e SCN. Sebbene sia possibile mappare i timestamp a SCN, non è davvero migliore del rapporto AWR. Siamo ancora bloccati a timestamp casuali; in questo caso il timestamp del logswitch.

Usando la funzione timestamp_to_scn

Un modo migliore è usare la funzione timestamp_to_scn. Questa funzione restituisce un SCN basato su un timestamp, come il timestamp corrente:

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

Il passo successivo è stato quello di fare una lista di orari con il corrispondente SCN e la corrispondenza SCN limite superiore, in base al numero di secondi a partire dal 1988 moltiplicato per 16.384.

Questo mostra i timestamp e SCN per l’ultimo giorno:

     
  1.  SELEZIONARE 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-YYYY' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  DA dual
    6.  
  6.  COLLEGARE DA 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 righe selezionate. 
    29.

L’attuale SCN è circa 0,57% del limite superiore corrente.

Trovare il tasso SCN superiore

Sulla base di questa idea ho creato una query che mi dà il lasso di tempo di 15 minuti con la più alta crescita in SCN negli ultimi 3 giorni.

Ogni minuto inizia un nuovo lasso di tempo e, poiché abbiamo 1440 minuti in un giorno, abbiamo 4320 tempi da indagare. Per ognuno di essi dobbiamo calcolare la crescita del SCN entro quel lasso di tempo di 15 minuti.

Vogliamo solo mostrare i risultati migliori, in questo caso solo i tempi con un tasso di oltre 14000 al secondo.

     
  1.  ALTER SESSION SET nls_date_format= 'MM/GG / AA HH24: MI' ;
    2.  
  2.  
    3.  
  3.  CON l'ingresso COME 
    4.  
  4.  ( SELEZIONARE sysdate - (rownum/1440) - (15/1440) starttime -- intervallo di 15 minuti 
    5.  
  5.  , sysdate - (rownum/1440) endtime
    6.  
  6.  DA dual
    7.  
  7.  COLLEGARE DA rownum <= (3*1440) -- 3 giorni di storia 
    8.  
  8. )
    9.  
  9.  SELEZIONARE l'ora di inizio
    10.  
  10.  , endtime
    11.  
  11.  , timestamp_to_scn(endtime) - timestamp_to_scn(ora di inizio) scngrowth
    12.  
  12.  , round((timestamp_to_scn(endtime) - timestamp_to_scn(starttime)) / 
    13.  
  13.  (((24*60*60)*(endtime-starttime )))) scnrate
    14.  
  14.  DA ingresso
    15.  
  15.  DOVE round((timestamp_to_scn(endtime) - timestamp_to_scn(starttime)) / 
    16.  
  16.  (((24*60*60)*(endtime-starttime )))) >= 14000 
    17.  
  17.  ORDINE DA 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.

Così, ora abbiamo trovato la (a volte sovrapposte), 15 minuti di cornici di tempo con il più alto SCN tasso (SCN crescita al secondo) per gli ultimi 3 giorni. E anche in quei tempi il tasso SCN è ancora sotto 16384. Nessun avviso nel file di avviso questa settimana….

Esecuzione del rapporto ASH

Il formato della data che ho usato nella query sopra è lo stesso utilizzato dal rapporto ASH, quindi puoi semplicemente copiare/incollare l’ora di inizio. Per la durata entriamo 15 minuti.

     
  1. Per maggiori informazioni clicca qui.sql
    2.  
  2.  
    3.  
  3. ASH Campioni IN questo Workload Repository schema
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. Antiche CENERI di esempio disponibili: 01-Lug-18 00:00:01 
    7.  
  7. Ultima CENERE campione disponibile: 09-Lug-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. Specificare il periodo di tempo PER generare il report di CENERE
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. Inserisci ORA di inizio del rapporto:
    13.  
  13.  
    14.  
  14. -- Valido formati di input:
    15.  
  15. -- Per specificare assoluto ora di inizio:
    16.  
  16. -- ] HH24:MI
    17.  
  17. -- Esempi: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- Per specificare la relativa ora di inizio: (iniziano con '-' segno)
    22.  
  22. -- -MI
    23.  
  23. -- Esempi: -1:15 (SYSDATE - 1 ora e 15 Minuti)
    24.  
  24. -- -25 (SYSDATE - 25 Minuti)
    25.  
  25.  
    26.  
  26. DI Default -15 minuti
    27.  
  27. Immettere un VALORE PER la begin_time: 07/06/18 18:09
    28.  
  28. Report di INIZIARE il periodo di TEMPO specificato: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. Immettere la durata IN minuti a partire DALL'ORA di inizio:
    31.  
  31. DI Default SYSDATE - begin_time
    32.  
  32. Premere Invio PER analizzare fino a ORA CORRENTE 
    33.  
  33. Immettere un VALORE PER la durata: 15 
    34.  
  34. Relazione durata specificato: 15 
    35.  
  35.  
    36.  
  36.  UTILIZZANDO 06-Lug-18 18:09:00 ORA di inizio report 
    37.  
  37.  UTILIZZANDO 06-Lug-18 18:24:00 relazione di FINE 
    38.  
  38.  
    39.  
  39. Specificare il Nome del Report
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. Il report PREDEFINITO nome del file È ashrpt_1_0706_1824.HTML. PER USARE questo nome, 
    42.  
  42. premere < return> PER continuare, altrimenti immettere un'alternativa. 
    43.  
  43. Immettere IL VALORE PER nome_rapporto:
    44.  
  44.  
    45.  
  45.  UTILIZZANDO il nome del report ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47. Riepilogo DI TUTTI gli INPUT dell'UTENTE 
    48.  
  48. -------------------------
    49.  
  49. Formato : HTML
    50.  
  50. Id DB : 2019395491 
    51.  
  51. Inst num : 1 
    52.  
  52.  ORA di inizio : 06-Lug-18 18:09:00
    53.  
  53.  ORA di FINE : 06-Lug-18 18:24:00
    54.  
  54. Slot larghezza : PREDEFINITO 
    55.  
  55. Report obiettivi : 0 
    56.  
  56. nome del Report : ashrpt_1_0706_1824.html
    57.

Trovare SCN in AWR

Il rapporto AWR non ci ha mostrato molte informazioni sull’attuale SCN, ma ha alcune informazioni sul tasso di crescita, se sai dove trovarlo.

In ” Statistiche attività istanza “è possibile trovare il numero di”chiamate a kcmgas”. Nella documentazione Oracle questo è descritto come il “Numero di chiamate a kcmga di routine per ottenere un nuovo SCN”.

Il valore di queste chiamate al secondo nel report AWR è molto vicino alla frequenza SCN calcolata con la funzione timestamp_to_scn.

V view SESSTAT view

Il numero di “chiamate a kcmga” utilizzate per creare un nuovo SCN può essere trovato anche nelle viste V SES SESSTAT e V SY SYSSTAT.

Possiamo usare V SES SESSTAT per trovare le sessioni che causano un alto tasso SCN. Possiamo anche testare l’impatto sul numero SCN di azioni specifiche.

Ad esempio, quando faccio una selezione su un grande tavolo che è anche in uso da altre sessioni, la mia sessione eseguirà altre 7 chiamate a kcmgas. Quindi, la mia query causerà un SCN più alto. Ciò è causato dalla coerenza di lettura del database, che utilizza anche un SCN.

     
  1. SQL> CONNETTI< utente > / <passa>@ < servizio> 
    2.  
  2. Connesso. 
    3.  
  3. SQL> SELEZIONARE ses.valore
    4.  
  4.  DA v ses sesstat ses
    5.  
  5.  , v st statname stat
    6.  
  6.  DOVE subito.statistica# = ses.statistica#
    7.  
  7.  E ses.sid IN (SELEZIONARE sid DA v myst mystat) 
    8.  
  8.  E subito.nome = 'chiamate a kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  VALORE 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL> SELECT COUNT(*) FROM mybigtable ;
    16.  
  16.  
    17.  
  17.  CONTE(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL> SELEZIONARE ses.valore
    22.  
  22.  DA v ses sesstat ses
    23.  
  23.  , v st statname stat
    24.  
  24.  DOVE subito.statistica# = ses.statistica#
    25.  
  25.  E ses.sid IN (SELEZIONARE sid DA v myst mystat) 
    26.  
  26.  E subito.nome = 'chiamate a kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  VALORE 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

Confrontando il SCN e commettere tasso

V$SESSTAT siamo in grado di query le statistiche per tutte le sessioni attualmente connesso al database. In questo modo possiamo trovare sessioni che sono responsabili di un alto tasso di SCN. Possiamo confrontare questo con il tasso di commit per quella sessione.

I risultati della query qui sotto ci hanno mostrato che sul nostro database l’alto tasso SCN è stato causato principalmente da processi in background. Per la maggior parte delle sessioni utente esiste una relazione tra un tasso SCN elevato e un tasso di commit elevato, per le sessioni in background il tasso di commit è sempre vuoto.

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

Conclusione

Tieni presente che ci sono dei limiti per SCN, quindi quando trovi degli avvisi nel file di avviso, devi indagare sul problema. Se trovi un problema, dovresti lavorare con il supporto Oracle. Caricando le informazioni possono verificare se c’è abbastanza spazio tra la SCN corrente e quella massima.

I problemi possono essere causati da un bug, come 12371955: il backup a caldo può causare un aumento del tasso di crescita SCN che porta a errori ORA-600 (ID Doc 12371955.8).

Se vuoi trovare il momento esatto in cui c’è un’alta crescita di SCN, devi convertire i timestamp in SCN. Si ottengono i migliori risultati utilizzando le funzioni SCN_TO_TIMESTAMP e TIMESTAMP_TO_SCN.

Un alto tasso di commit è sempre correlato ai processi utente, ma gli SCN sono anche correlati ai processi in background. Anche le sessioni che non si impegnano possono avere un impatto sulla SCN.

Bastiaan Bak

Circa l’autore Bastiaan Bak

DBA con oltre 15 anni di esperienza. Esperienza in vari rami, con diversi moduli. Comprensivo: Il nostro sito utilizza cookie tecnici e di terze parti.

Altri messaggi di Bastiaan Bak

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.