Enquête sur le taux de croissance intrinsèque du SCN

Written by on in Articles

Publié le: 10 juillet 2018 Auteur: Bastiaan Bak Catégorie: Développement et opérations informatiques

Il y a quelque temps, nous avions un avertissement sur la croissance intrinsèque du SCN (numéro de changement de système) dans notre fichier d’alerte de base de données Oracle 12.2. Cette situation s’est produite plusieurs fois en quelques semaines.

 » Avertissement : Le taux de croissance intrinsèque de SCN a toujours été
supérieur à 16384 par seconde par défaut du système pendant les 60 dernières minutes.
Le taux de croissance intrinsèque actuel de SCN est de 25867 par seconde, zas 200fffff!
La valeur SCN actuelle est 46747726691, la valeur Compat SCN est 1″

Ma réaction initiale était que les SCN sont liés aux commits, donc soit la charge sur la base de données était très élevée, soit la logique de l’application devait être modifiée. Une autre possibilité était qu’un commit soit effectué après chaque mise à jour, au lieu d’utiliser des commits par lots.

Cela s’est avéré un peu plus compliqué que prévu. Où regardez-vous lorsque vous voulez trouver la relation entre SCN et commits ? Et à quel point cet avertissement est-il sérieux de toute façon? Ce blog va parler des différentes façons dont j’ai étudié ce problème et identifié l’impact potentiel.

Notes de support Oracle

Le premier endroit pour rechercher des informations sur les avertissements dans le fichier d’alerte est le site Web de support Oracle. J’ai trouvé plusieurs notes connexes:

  • ORA-19706 et les messages de journal d’alerte Associés (ID Doc 1393360.1)
    Cette note suggère que le message réel est spécifique à la version 12.2 de la base de données, mais dans les anciennes versions, nous pourrions avoir des avertissements similaires, comme « Avertissement: La marge de sécurité SCN pour cette base de données n’est que de NN jours! »
    Si vous rencontrez un message de journal d’alerte comme l’une de ces entrées, il est conseillé de suivre les instructions de l’ID 1388639.1 et d’enregistrer une demande de service avec le support Oracle.
    Preuves à collecter lorsque vous signalez des problèmes de  » taux SCN élevé  » au support Oracle (ID Doc 1388639.1)
  • Cette note donne des informations sur les informations que vous devez fournir lors de la journalisation d’une demande de service.
  • Numéro de changement de système (SCN), Espace libre, Informations de sécurité et de correctif (ID Doc 1376995.1)
    Cette note donne plus d’informations sur l’utilisation du SCN. Le numéro de changement de système (SCN) est un horodatage interne logique utilisé par la base de données Oracle. Les SCN ordonnent les événements qui se produisent dans la base de données. La base de données utilise SCNs pour interroger et suivre les modifications. Lorsqu’une transaction est validée, la base de données enregistre un SCN pour cette validation.
    Il existe une limite supérieure au nombre de SCN qu’une base de données Oracle peut utiliser. La limite est actuellement de 281 billions (2 ^ 48) de valeurs SCN.
    Étant donné qu’il existe une limite supérieure, il est important qu’une base de données Oracle donnée ne soit pas à court de SCN disponibles.
    La note explique également quand l’avertissement est déclenché. La base de données Oracle calcule une limite  » à ne pas dépasser  » pour le nombre de SCN qu’une base de données peut actuellement utiliser, en fonction du nombre de secondes depuis 1988 multiplié par 16384. Cela garantit que les bases de données Oracle rationneront les SCN au fil du temps.

Quelle est la gravité de cet avertissement?

L’alerte est déclenchée à un rythme de 2^14 = 16384 SCNs par seconde pendant les 60 dernières minutes.
Le NCS maximum est 2^48 = 281.474.976.710.656.

À raison de 16348 SCN par seconde, nous aurons 2^ (48-14) secondes, soit 544 ans pour atteindre ce maximum. Cela devrait suffire dans une situation normale, mais la limite supérieure de 2 ^ 48 n’est que la valeur absolue maximale que la base de données peut stocker.
La limite est également liée au nombre de secondes depuis 1988. La limite de 2^ 48 est le maximum de l’année 2532 (1988 + 544). Mais en 2018, le maximum est (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

L’avertissement ne doit pas être ignoré. Lorsque vous atteignez la limite, vous obtiendrez des erreurs ora-600, mais lorsque vous atteignez la limite supérieure absolue SCN, la base de données cessera de fonctionner.

La bonne nouvelle est que dans notre situation, l’avertissement indiquait que le taux de croissance du NCS était de 25867 par seconde à cette heure spécifique, nous nous sommes donc un peu rapprochés (25867-16384 = 9483) de la limite. Nous ne nous approchons pas de la limite toutes les heures; le taux de croissance normal est inférieur à 16384.

Support Oracle

Nous avons appelé le support Oracle, et ils nous ont dit qu’Oracle Development travaillait actuellement sur ce problème.
La prise en charge d’Oracle a confirmé que la marge du SCN était bonne. Sur la base du rapport AWR, le support Oracle a remarqué un nombre élevé de validations et a suggéré de vérifier auprès de l’équipe d’application la validation en augmentant la taille de la transaction.

Enquête avec AWR

L’avertissement dans le fichier d’alerte nous a indiqué que le taux de croissance intrinsèque du SCN était constamment supérieur à celui par défaut du système: 16384 par seconde pendant les 60 dernières minutes. Si nous envisageons une période d’une heure, un rapport AWR pourrait être un bon point de départ. Nous avons AWR configuré pour faire des instantanés toutes les heures.

Dans le rapport AWR, j’ai remarqué que le nombre de commits utilisateur était de 210 par seconde. Oui, c’est beaucoup de commits, mais ce n’est pas si différent de la charge normale de cette base de données. Et si un commit est lié à un SCN, il est également bien inférieur à 16384 par seconde.

Le rapport AWR contenait également une constatation ADDM : Les attentes sur l’événement  » synchronisation du fichier journal  » lors de l’exécution des opérations de VALIDATION et de RESTAURATION prenaient beaucoup de temps dans la base de données. Étudiez la logique de l’application pour une éventuelle réduction du nombre d’opérations de VALIDATION en augmentant la taille des transactions.
Cette réduction des commits dans la conclusion ADDM a également été suggérée par le support Oracle. De mon point de vue, ce n’était pas vraiment si élevé que ça.

Délai plus court

Parce que l’AWR ne m’aidait pas à trouver la cause, j’avais besoin d’enquêter sur un délai plus court. Je voulais connaître un calendrier plus précis pour pouvoir créer un rapport ASH. La valeur par défaut pour ASH est de 15 minutes.
Le prochain défi était donc de trouver la période de 15 minutes pendant laquelle le taux de croissance du NCS était le plus élevé.
ID de document 1388639.1 suggéré d’interroger varcharchived_log. Cette vue contient des informations sur tous les commutateurs de journal de la base de données, y compris un horodatage et le SCN. Bien que vous puissiez mapper les horodatages aux SCN, ce n’est pas vraiment mieux que le rapport AWR. Nous sommes toujours collés à des horodatages aléatoires; dans ce cas, l’horodatage du commutateur de connexion.

Utilisation de la fonction timestamp_to_scn

Une meilleure façon consiste à utiliser la fonction timestamp_to_scn. Cette fonction renvoie un SCN basé sur un horodatage, comme l’horodatage actuel:

     
  1.  SQL > SÉLECTIONNEZ timestamp_to_scn (sysdate) À PARTIR DE dual ;
    2.  
  2.  
    3.  
  3.  TIMESTAMP_TO_SCN (SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7.  SQL> 
    8.

L’étape suivante consistait à dresser une liste des horodatages avec le SCN correspondant et la limite supérieure du SCN correspondant, basée sur le nombre de secondes depuis 1988 multiplié par 16 384.

Affiche les horodatages et les SCN du dernier jour:

     
  1.  SÉLECTIONNEZ sysdate - (rownum/24) datetimestamp
    2.  
  2.  , timestamp_to_scn(sysdate-(rownum/24)) SCN
    3.  
  3.  , (( sysdate-(rownum/24)) -to_date('01-01-1988', 'JJ-MM-AAAA' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  DE double
    6.  
  6.  CONNECTEZ-VOUS PAR rownum <= 24 
    7.  
  7. /
    8.  
     
  1.  DATE DE L'HORODATAGE 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 lignes sélectionnées. 
    29.

Le SCN actuel est d’environ 0,57% de la limite supérieure actuelle.

Trouver le taux de SCN le plus élevé

Sur la base de cette idée, j’ai créé une requête qui me donne le délai de 15 minutes avec la plus forte croissance des SCN au cours des 3 derniers jours.

Chaque minute, un nouveau délai commence, et comme nous avons 1440 minutes en un jour, nous avons 4320 délais pour enquêter. Pour chacun d’eux, nous devons calculer la croissance du SCN dans ce délai de 15 minutes.

Nous voulons seulement montrer les meilleurs résultats, dans ce cas uniquement les délais avec un taux de plus de 14000 par seconde.

     
  1.  MODIFIER L'ENSEMBLE DE SESSION nls_date_format = 'MM/JJ/AA HH24:MI' ;
    2.  
  2.  
    3.  
  3.  AVEC datelist COMME 
    4.  
  4.  ( SÉLECTIONNEZ sysdate - (rownum/1440) - (15/1440) heure de démarrage interval intervalle de 15 minutes 
    5.  
  5.  , sysdate - (rownum/1440) heure de fin
    6.  
  6.  DE double
    7.  
  7.  CONNECTEZ-VOUS PAR rownum <= (3*1440) -- 3 historique des jours 
    8.  
  8. )
    9.  
  9.  SÉLECTIONNEZ heure de démarrage
    10.  
  10.  , heure de fin
    11.  
  11.  , timestamp_to_scn(heure de fin) - timestamp_to_scn(heure de début) scngrowth
    12.  
  12.  , round((timestamp_to_scn(heure de fin) - timestamp_to_scn(heure de début)) / 
    13.  
  13.  (((24*60*60)*( heure de fin - heure de début )))) scnrate
    14.  
  14.  DE la liste de données
    15.  
  15.  OÙ round((timestamp_to_scn(heure de fin) - timestamp_to_scn(heure de début)) / 
    16.  
  16.  (((24*60*60)*( heure de fin - heure de début )))) >= 14000 
    17.  
  17.  COMMANDER PAR 4 DESC 
    18.  
  18. /
    19.  
     
  1.  HEURE DE DÉBUT HEURE DE FIN TAUX DE CROISSANCE TAUX DE CROISSANCE
    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.

Nous avons donc maintenant trouvé les intervalles de temps de 15 minutes (qui se chevauchent parfois) avec le taux de SCN le plus élevé (croissance de SCN par seconde) au cours des 3 derniers jours. Et même dans ces délais, le taux de NCS est toujours inférieur à 16384. Aucun avertissement dans le fichier d’alerte cette semaine ….

Exécution du rapport ASH

Le format de date que j’ai utilisé dans la requête ci-dessus est le même que celui utilisé par le rapport ASH, vous pouvez donc simplement copier / coller l’heure de début. Pour la durée, nous entrons 15 minutes.

     
  1.  SQL > @@ORORACLE_HOME/SGBDR/admin/ashrpt.sql
    2.  
  2.  
    3.  
  3.  Exemples de CENDRES DANS ce schéma de référentiel de charge de travail
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6.  Échantillon de CENDRES le plus ancien disponible: 01-Juil-18 00:00:01 
    7.  
  7.  Dernier échantillon de CENDRES disponible: 09-Juil-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10.  Spécifiez le délai de génération du rapport ASH
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12.  Entrez L'HEURE DE DÉBUT DU rapport:
    13.  
  13.  
    14.  
  14. -- Formats d'entrée valides:
    15.  
  15. -- Pour spécifier l'heure de début absolue:
    16.  
  16. -- ] HH24: MI
    17.  
  17. -- Exemples: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- Pour spécifier l'heure de début relative: (commencez par le signe '-')
    22.  
  22. -- - MI
    23.  
  23. -- Exemples : -1:15 (SYSDATE - 1 Heure 15 Minutes)
    24.  
  24. -- -25 ( DATE DU SYSTÈME - 25 Minutes)
    25.  
  25.  
    26.  
  26.  Par défaut À -15 minutes
    27.  
  27.  Entrez LA VALEUR POUR begin_time: 07/06/18 18:09
    28.  
  28.  HEURE de DÉBUT du rapport spécifiée: 07/06/18 18:09
    29.  
  29.  
    30.  
  30.  Entrez la durée EN minutes à PARTIR DE L'HEURE DE DÉBUT:
    31.  
  31.  Par défaut, SYSDATE-begin_time
    32.  
  32.  Appuyez Sur Entrée POUR analyser jusqu'à L'HEURE ACTUELLE 
    33.  
  33.  Entrez LA VALEUR DE la durée: 15 
    34.  
  34.  Durée du rapport spécifiée: 15 
    35.  
  35.  
    36.  
  36.  UTILISER 06-Jul-18 18:09:00 COMME HEURE DE DÉBUT DU rapport 
    37.  
  37.  UTILISER 06-Jul-18 18:24:00 COMME HEURE DE FIN DU rapport 
    38.  
  38.  
    39.  
  39.  Spécifiez le nom du rapport
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41.  Le nom de fichier de rapport PAR DÉFAUT EST ashrpt_1_0706_1824.HTML. POUR UTILISER ce nom, 
    42.  
  42.  appuyez sur < return > POUR continuer, sinon entrez une alternative. 
    43.  
  43.  Entrez LA VALEUR POUR nom_apport:
    44.  
  44.  
    45.  
  45.  EN utilisant le nom du rapport ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47.  Résumé DE TOUTES LES ENTRÉES DE L'UTILISATEUR 
    48.  
  48. -------------------------
    49.  
  49.  Format : HTML
    50.  
  50.  Id DB : 2019395491 
    51.  
  51.  Inst num : 1 
    52.  
  52.  HEURE DE DÉBUT: 06 - Juil-18 18:09:00
    53.  
  53.  HEURE DE FIN: 06 - Juil-18 18:24:00
    54.  
  54.  Largeur de fente : PAR DÉFAUT 
    55.  
  55.  Objectifs du rapport : 0 
    56.  
  56.  Nom du rapport : ashrpt_1_0706_1824.html
    57.

Trouver le NCS dans AWR

Le rapport de l’AWR ne nous a pas montré beaucoup d’informations sur le NCS actuel, mais il contient des informations sur le taux de croissance, si vous savez où le trouver.

Sous « Statistiques d’activité de l’instance », vous pouvez trouver le nombre d' » appels à kcmgas ». Dans la documentation Oracle, cela est décrit comme le « nombre d’appels à kcmgas de routine pour obtenir un nouveau SCN ».

La valeur de ces appels par seconde dans le rapport AWR est très proche du taux SCN calculé avec la fonction timestamp_to_scn.

Vue V$SESSTAT

Le nombre d' » appels à kcmgas » utilisés pour créer un nouveau SCN peut également être trouvé dans les vues V VSESSTAT et V VSYSSTAT.

Nous pouvons utiliser V$SESSTAT pour trouver les sessions qui provoquent un taux de SCN élevé. Nous pouvons également tester l’impact sur le nombre de SCN d’actions spécifiques.

Par exemple, lorsque je fais une sélection sur une grande table qui est également utilisée par d’autres sessions, ma session fera 7 autres appels à kcmgas. Ainsi, ma requête entraînera un SCN plus élevé. Cela est dû à la cohérence en lecture de la base de données, qui utilise également un SCN.

     
  1.  SQL > CONNECTER < utilisateur > / < passer > @ < service> 
    2.  
  2.  Connecté. 
    3.  
  3.  SQL > SÉLECTIONNEZ ses.valeur
    4.  
  4.  DE v$sesstat ses
    5.  
  5.  , v$nom d'état stat
    6.  
  6.  OÙ stat.statistique # = ses.statistiques#
    7.  
  7.  ET ses.sid IN (SÉLECTIONNEZ sid DANS vmystmystat) 
    8.  
  8.  ET stat.name = ' appels à kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  VALEUR 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15.  SQL > SÉLECTIONNEZ COUNT(*) DANS mybigtable ;
    16.  
  16.  
    17.  
  17.  COMPTER(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21.  SQL > SÉLECTIONNEZ ses.valeur
    22.  
  22.  DE v$sesstat ses
    23.  
  23.  , v$nom d'état stat
    24.  
  24.  OÙ stat.statistique # = ses.statistiques#
    25.  
  25.  ET ses.sid IN (SÉLECTIONNEZ sid DANS vmystmystat) 
    26.  
  26.  ET stat.name = ' appels à kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  VALEUR 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33.  SQL> 
    34.

En comparant le SCN et le taux de validation

Avec VSESSESSTAT, nous pouvons interroger les statistiques de toutes les sessions actuellement connectées à la base de données. De cette façon, nous pouvons trouver des sessions responsables d’un taux de NCS élevé. Nous pouvons comparer cela au taux de validation de cette session.

Les résultats de la requête ci-dessous nous ont montré que dans notre base de données, le taux élevé de NCS était principalement causé par des processus d’arrière-plan. Pour la plupart des sessions utilisateur, il existe une relation entre un taux SCN élevé et un taux de validation élevé, pour les sessions en arrière-plan, le taux de validation est toujours vide.

     
  1.  SÉLECTIONNEZ ses.sid
    2.  
  2.  , décoder (ses.nom d'utilisateur, NULL, 'background', 'user') session_type
    3.  
  3.  , ( date d'ouverture de session) * 24 * 60 * 60 connect_secondes
    4.  
  4.  , sstat1.valeur SCN#
    5.  
  5.  , sstat2.COMMIT DE Valeur#
    6.  
  6.  , rond (sstat1.valeur /((sysdate-heure de connexion ) * 24 * 60 * 60),2) _rate de scn
    7.  
  7.  , rond (sstat2.valeur /((sysdate-heure de connexion ) * 24 * 60 * 60),2) commit_rate
    8.  
  8.  DE v$sesstat sstat1
    9.  
  9.  , v$sesstat sstat2
    10.  
  10.  , v snnom d'état sn1
    11.  
  11.  , v snnom d'état sn2
    12.  
  12.  , vsessionsession ses
    13.  
  13.  OÙ sstat1.statistique # = sn1.statistiques#
    14.  
  14.  ET sstat2.statistique # = sn2.statistiques#
    15.  
  15.  ET sn1.name = ' appels à kcmgas' 
    16.  
  16.  ET sn2.name = 'commits utilisateur' 
    17.  
  17.  ET ses.sid=sstat1.sid
    18.  
  18.  ET ses.sid= sstat2.sid
    19.  
  19.  ORDRE PAR 6 DESC 
    20.  
  20. /
    21.  
  21.  
    22.  
  22.  SID SESSION_TY CONNECT_SECONDS SCN #COMMIT #SCN_RATE COMMIT_RATE
    23.  
  23. ---------- ---------- --------------- ---------- ---------- ---------- -----------
    24.  
  24.  8478 contexte 459572 214506344 0 466.75 0 
    25.  
  25.  7551 contexte 452395 209729934 0 463.6 0 
    26.  
  26.  3776 contexte 290389 133863489 0 460.98 0 
    27.  
  27.  8496 contexte 121201 55685740 0 459.45 0 
    28.  
  28.  8729 contexte 286773 128180386 0 446.98 0 
    29.  
  29.  12009 contexte 290392 128867329 0 443.77 0 
    30.  
  30.  13173 contexte 196775 87268032 0 443.49 0 
    31.  
  31.  12004 contexte 103166 45681480 0 442.8 0 
    32.  
  32.  8735 contexte 275980 121563094 0 440.48 0 
    33.  
  33.  3096 contexte 430810 185436599 0 430.44 0 
    34.  
  34.  8027 contexte 95990 40912187 0 426.21 0 
    35.  
  35.  7529 contexte 193218 81367643 0 421.12 0 
    36.  
  36.  2370 contexte 527978 219521415 0 415.78 0 
    37.  
  37.  14604 contexte 283216 117052382 0 413.3 0 
    38.  
  38.  14132 contexte 113965 46586388 0 408.78 0 
    39.  
  39.  7552 contexte 294009 119775077 0 407.39 0 
    40.  
  40.  13172 contexte 182423 73865595 0 404.91 0 
    41.  
  41.  14592 contexte 74414 29767705 0 400.03 0 
    42.  
  42.  3802 contexte 268804 107486102 0 399.87 0 
    43.  
  43.  9910 contexte 117582 46596720 0 396.29 0 
    44.  
  44.  12021 contexte 49182 19321676 0 392.86 0 
    45.  
  45.  974 contexte 160816 59996495 0 373.08 0 
    46.  
  46.  12723 contexte 74450 25455559 0 341.91 0 
    47.  
  47.  3310 contexte 193215 65915175 0 341.15 0 
    48.  
  48.  12963 contexte 49179 15687084 0 318.98 0 
    49.  
  49.  6111 contexte 3584090 1031139557 0 287.7 0 
    50.  
  50.  6829 UTILISATEUR 303 1267 1123 4.18 3.71 
    51.  
  51.  9665 UTILISATEUR 904 1845 1691 2.04 1.87 
    52.  
  52.  8022 UTILISATEUR 898 1677 1520 1.87 1.69 
    53.  
  53.  3323 UTILISATEUR 898 1406 1260 1.57 1.4 
    54.  
  54.  2839 UTILISATEUR 7503 10822 9813 1.44 1.31 
    55.  
  55.  11060 UTILISATEUR 3892 5334 4781 1.37 1.23 
    56.  
  56.  13184 UTILISATEUR 1765 2359 2038 1.34 1.15 
    57.  
  57.  9199 UTILISATEUR 898 1135 935 1.26 1.04 
    58.  
  58.  2130 UTILISATEUR 8105 9548 8518 1.18 1.05 
    59.  
  59.  11525 UTILISATEUR 898 1054 944 1.17 1.05 
    60.  
  60.  6130 UTILISATEUR 3895 4453 4199 1.14 1.08 
    61.  
  61.  8012 UTILISATEUR 7503 8576 7774 1.14 1.04 
    62.  
  62.  4497 UTILISATEUR 898 962 882 1.07.98
    63.  
  63.  5201 UTILISATEUR 7220 7551 6226 1.05.86
    64.  
  64.  11317 UTILISATEUR 12906 13371 11997 1.04.93
    65.  
  65.  
    66.  
  66.  
    67.  
  67.  1979 LIGNES sélectionnées. 
    68.

Conclusion

Sachez qu’il y a des limites au SCN, donc lorsque vous trouvez des avertissements dans le fichier d’alertes, vous devez enquêter sur le problème. Si vous trouvez un problème, vous devriez travailler avec le support Oracle. En téléchargeant des informations, ils peuvent vérifier s’il y a suffisamment de place entre le SCN actuel et le SCN maximal.

Les problèmes peuvent être causés par un bogue, comme 12371955: La sauvegarde à chaud peut entraîner une augmentation du taux de croissance SCN entraînant des erreurs ORA-600 (ID Doc 12371955.8).

Si vous voulez trouver le moment exact où il y a une forte croissance de SCN, vous devez convertir les horodatages en SCN. Vous obtenez les meilleurs résultats en utilisant les fonctions SCN_TO_TIMESTAMP et TIMESTAMP_TO_SCN.

Un taux de validation élevé est toujours lié aux processus utilisateur, mais les SCN sont également liés aux processus en arrière-plan. Même les sessions qui ne s’engagent pas peuvent avoir un impact sur le SCN.

Bastiaan Bak

À propos de l’auteur Bastiaan Bak

DBA avec plus de 15 ans d’expérience. Expérience dans différentes branches, avec plusieurs modules. Comprendre: Base de données Oracle, Oracle RAC, Oracle EBS et PL/SQL.

Plus de messages de Bastiaan Bak

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.