Comment trouver mon SCN actuel?


14

Étant donné n'importe quelle version d'Oracle:

  • Comment trouver mon SCN actuel?
  • Quel est le SCN maximum possible?

Cette question a été inspirée par cet article . Il y a probablement beaucoup de gens Oracle qui consultent ces chiffres en ce moment. :)
Nick Chammas

On dirait que le lien de mon commentaire précédent est maintenant rompu. Je crois que cette page a été déplacée ici: infoworld.com/article/2618409/…
Nick Chammas

Réponses:


16

SCN actuel

Oracle 9i:

SELECT dbms_flashback.get_system_change_number as current_scn 
FROM DUAL;

Oracle 10g et supérieur:

SELECT current_scn
FROM V$DATABASE;

Limites SCN

SCN a une limite stricte imposée par son format et une limite souple imposée artificiellement par Oracle, comme décrit ici . J'ai cité les parties pertinentes ci-dessous (je souligne).

Limite stricte

Les architectes de l'application de base de données phare d'Oracle devaient être bien conscients que le SCN devait être un entier massif. Il s'agit d'un nombre à 48 bits ( 281 474 976 710 656 ). Il faudrait des éons pour qu'une base de données Oracle éclipse ce nombre de transactions et cause des problèmes - ou du moins vous pourriez le penser.

Limite douce

La limite souple dérive d'un calcul très simple ancré à un point dans le temps il y a 24 ans: Prenez le nombre de secondes depuis 00:00:00 01/01/1988 et multipliez ce chiffre par 16,384. Si la valeur SCN actuelle est inférieure à cela, alors tout va bien et le traitement se poursuit normalement. Pour le dire simplement, le calcul suppose qu'une base de données fonctionnant en permanence depuis le 01/01/1988, traitant 16 384 transactions par seconde, ne peut pas exister dans la réalité.

Vérification des limites SCN

Ce script (Oracle 10g et supérieur) vérifiera la quantité de limites strictes et souples que vous avez épuisées. Merci à Rob d'avoir appelé la limite douce.

WITH limits AS (
  SELECT 
      current_scn
  --, dbms_flashback.get_system_change_number as current_scn -- Oracle 9i
    , (SYSDATE - TO_DATE('1988-01-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS')) * 24*60*60 * 16384 
        AS SCN_soft_limit
    , 281474976710656 AS SCN_hard_limit
  FROM V$DATABASE
)
SELECT
    current_scn
  , current_scn/scn_soft_limit*100 AS pct_soft_limit_exhausted
  , scn_soft_limit
  , current_scn/scn_hard_limit*100 AS pct_hard_limit_exhausted
  , scn_hard_limit
FROM limits;

2
Je vois que vous avez votre réponse. Vous devriez également lire l'article de Riyaj
Niall Litchfield

Merci pour la référence! Au cas où quelqu'un d'autre voudrait le lire, l'article est maintenant sur orainternals.wordpress.com/2012/01/19/scn-what-why-and-how
Magnus Reftel

6

Voici une requête que j'ai trouvée pour vérifier l'intégrité de mes bases de données concernant le problème de bogue SCN:

# Show the amount of SCN keyspace we have used so far on this database
# By default the SCN max on a 10g/11g 
# instance is a 48-bit integer (281,474,976,710,656) 
SELECT NAME,  
   (current_scn/281474976710656)*100 as PCT_OF_SCN_KEYSPACE_USED,  
   ROUND(SYSDATE-CREATED) as DAYS_SINCE_DB_CREATION, 
   ROUND(1/(current_scn/281474976710656)*(SYSDATE-CREATED)) AS EST_DAYS_BEFORE_SCN_EXHAUSTED, 
   ROUND(1/(current_scn/281474976710656)*(SYSDATE-CREATED)/365) AS EST_YEARS_BEFORE_SCN_EXHAUSTED  
FROM v$database;

La plupart de mes bases de données qui utilisent des liens DB sont au niveau épuisé de 3,5% et peuvent continuer au rythme actuel pendant plus de 50 ans sans problème. Cela ne signifie pas que je suis à l'abri de quelqu'un qui chatouille le bogue SCN, mais au moins nous n'avons pas trouvé de base de données bien plus élevée que les autres ou proche de la limite.


2

281 474 976 710 656 est la limite stricte. Vous voudrez savoir quelle est la limite souple, car c'est la valeur sur laquelle vous vous frappez la tête en premier. La limite souple est (grossièrement) calculée par le nombre de secondes écoulées depuis le 1er janvier 1988 x 16384.


Je ne sais pas comment les anciennes réponses ont manqué la limite souple (qui est mentionnée dans l'article lié par Nick) - c'est donc une bonne idée d'ajouter les détails manquants.
dezso
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.