Étant donné n'importe quelle version d'Oracle:
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;
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).
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. C'est: un nombre de 48 bits ( 281,474,976,710,656 ). Il faudrait des éons pour une base de données Oracle pour Eclipse ce nombre de transactions et causer des problèmes - ou du moins vous pourriez penser.
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 en termes simples, le calcul suppose qu'une base de données fonctionnant constamment depuis le 01/01/1988, traitant 16 384 transactions par seconde, ne peut pas exister en réalité.
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;
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 à 3,5% épuisées 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.
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 frapperiez la tête en premier. La limite souple est (approximativement) calculée par le nombre de secondes écoulées depuis le 1er janvier 1988 x 16384.