Dada cualquier versión de Oracle:

• ¿Cómo encuentro mi SCN actual?
• ¿Cuál es el máximo SCN posible?

SCN actual

Oracle 9i:

SELECT dbms_flashback.get_system_change_number as current_scn 
FROM DUAL;

Oracle 10g y superior:

SELECT current_scn
FROM V$DATABASE;

Límites de SCN

SCN tiene un límite estricto impuesto por su formato y un límite flexible impuesto artificialmente por Oracle, como se describe aquí . He citado las partes relevantes a continuación (énfasis agregado).

Límite duro

Los arquitectos de la aplicación de base de datos insignia de Oracle deben haber sido conscientes de que el SCN debía ser un número entero masivo. Es: un número de 48 bits ( 281,474,976,710,656 ). Se necesitarían eones para que una base de datos Oracle eclipse esa cantidad de transacciones y cause problemas, o eso podría pensar.

Límite suave

El límite suave deriva de un cálculo muy simple anclado a un punto en el tiempo hace 24 años: tome el número de segundos desde 00:00:00 01/01/1988 y multiplique esa cifra por 16,384. Si el valor SCN actual está por debajo de eso, entonces todo está bien y el procesamiento continúa de manera normal. Para poner esto en términos simples, el cálculo supone que una base de datos que se ejecuta constantemente desde el 01/01/1988, procesando 16.384 transacciones por segundo, no puede existir en la realidad.

Verificación de límite de SCN

Este script (Oracle 10g y superior) verificará la cantidad de límites duros y blandos que ha agotado. Gracias a Rob por llamar al límite blando.

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;

Aquí hay una consulta que se me ocurrió para verificar la cordura de mis bases de datos con respecto al problema de error 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 mayoría de mis bases de datos que usan enlaces DB están en la marca agotada del 3.5% y pueden continuar al ritmo actual por más de 50 años sin problemas. Esto no significa que esté a salvo de que alguien haga cosquillas al error SCN, pero al menos no encontramos una base de datos que fuera mucho más alta que las demás o cercana al límite.

281,474,976,710,656 es el límite duro. Querrá saber cuál es el límite blando, ya que ese es el valor con el que se golpearía la cabeza primero. El límite flexible se calcula (aproximadamente) por el número de segundos transcurridos desde el 1 de enero de 1988 x 16384.