Investigating the SCN intrinsic growth rate

Escrito por el en Articles

Publicado el: 10 de julio de 2018 Autor: Bastiaan Bak Categoría: Desarrollo y operaciones de TI

Hace un tiempo, recibimos una advertencia sobre el crecimiento intrínseco del SCN (número de cambio de sistema) en nuestro archivo de alerta de base de datos Oracle 12.2. Esta situación ocurrió varias veces en pocas semanas.

«Advertencia: La tasa de crecimiento intrínseco de SCN ha sido consistentemente
superior a 16384 por segundo por defecto del sistema durante los últimos 60 minutos.
La tasa de crecimiento intrínseco del SCN actual es de 25867 por segundo, zas 200fffff!
El valor actual de SCN es 46747726691, el valor de SCN Compat es 1″

Mi reacción inicial fue que los SCN están relacionados con confirmaciones, por lo que la carga en la base de datos era muy alta o se debería cambiar la lógica de la aplicación. Otra posibilidad era que se hiciera una confirmación después de cada actualización, en lugar de usar confirmaciones por lotes.

resultó ser un poco más complicado de lo que esperaba. ¿Dónde buscas cuando quieres encontrar la relación entre SCN y commits? ¿Y qué tan seria es esta advertencia de todos modos? Este blog va a ser sobre las diversas formas en que investigué este problema e identifiqué el impacto potencial.

Notas de soporte de Oracle

El primer lugar para buscar información sobre advertencias en el archivo de alertas es el sitio web de soporte de Oracle. Encontré varias notas relacionadas:

  • ORA-19706 y Mensajes de Registro de Alertas Relacionados (Doc ID 1393360.1)
    Esta nota sugiere que el mensaje real es específico de la versión 12.2 de la base de datos, pero en versiones anteriores podríamos tener advertencias similares, como «Advertencia: ¡El espacio libre de SCN para esta base de datos es solo NN días!»
    Si encuentra un mensaje de registro de alertas como cualquiera de estas entradas, se le recomienda que siga las instrucciones de ID 1388639.1 y registre una solicitud de servicio con Oracle support.
    Evidencia que debe recopilar al informar de problemas de «alta tasa de SCN» a Oracle Support (Doc ID 1388639.1)
  • Esta nota proporciona información sobre la información que debe entregar al registrar una solicitud de servicio.
  • Número de cambio de sistema (SCN), Espacio libre, Información de seguridad y Parches (Doc ID 1376995.1)
    Esta nota proporciona más información sobre el uso del SCN. El número de cambio de sistema (SCN) es una marca de tiempo interna lógica utilizada por la base de datos Oracle. Eventos de orden de SCNs que ocurren dentro de la base de datos. La base de datos utiliza SCN para consultar y realizar un seguimiento de los cambios. Cuando se confirma una transacción, la base de datos registra un SCN para esta confirmación.
    Hay un límite superior a la cantidad de SCN que puede usar una base de datos Oracle. El límite es actualmente de 281 billones (2^48) de valores SCN.
    Dado que hay un límite superior, es importante que ninguna base de datos Oracle se quede sin SCN disponibles.
    La nota también explica cuándo se levanta la advertencia. La base de datos Oracle calcula un límite de» no exceder » para el número de SCN que una base de datos puede usar actualmente, basado en el número de segundos desde 1988 multiplicado por 16384. Esto garantiza que las bases de datos Oracle racionarán los SCN con el tiempo.

¿Qué tan grave es esta advertencia?

La advertencia se eleva a una velocidad de 2^14 = 16384 SCN por segundo durante los últimos 60 minutos.
El SCN máximo es 2^48 = 281.474.976.710.656.

A una velocidad de 16348 SCN por segundo, tendremos 2^(48-14) segundos, o 544 años para alcanzar ese máximo. Eso debería ser suficiente en una situación normal, pero el límite superior de 2^48 es solo el valor absoluto máximo que la base de datos puede almacenar.
El límite también está relacionado con el número de segundos desde 1988. El límite de 2^48 es el máximo en el año 2532 (1988+544). Pero en 2018 el máximo es (2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

La advertencia no debe ignorarse. Cuando alcance el límite, obtendrá errores ora-600, pero cuando alcance el límite superior absoluto SCN, la base de datos dejará de funcionar.

La buena noticia es que en nuestra situación la advertencia decía que la tasa de crecimiento de SCN era de 25867 por segundo en esa hora específica, por lo que en esa hora nos acercamos un poco más (25867-16384=9483) al límite. No nos acercamos al límite cada hora; la tasa de crecimiento normal es inferior a 16384.

Oracle Support

Llamamos a Oracle Support y nos dijeron que Oracle Development está trabajando actualmente en este problema.
Oracle Support confirmó que el espacio libre de SCN se ve bien. Según el informe AWR, Oracle Support observó un gran número de confirmaciones y sugirió consultar con el equipo de aplicaciones para confirmar aumentando el tamaño de la transacción.

Investigación con AWR

La advertencia en el archivo de alerta nos dijo que la tasa de crecimiento intrínseco de SCN ha sido consistentemente más alta que la predeterminada del sistema: 16384 por segundo durante los últimos 60 minutos. Si estamos viendo un marco de tiempo de una hora, un informe de AWR podría ser un buen lugar para comenzar. Tenemos AWR configurado para hacer instantáneas cada hora.

En el informe AWR, noté que el número de confirmaciones de usuario era de 210 por segundo. Sí, eso es un montón de confirmaciones, pero no es tan diferente de la carga normal de esta base de datos. Y si un commit está relacionado con un SCN, también es mucho más bajo que 16384 por segundo.

El informe AWR también contenía un hallazgo de ADDM: Las esperas en la «sincronización de archivos de registro» de eventos mientras realizaba operaciones de confirmación y REVERSIÓN consumían un tiempo de base de datos significativo. Investigue la lógica de la aplicación para una posible reducción en el número de operaciones de CONFIRMACIÓN al aumentar el tamaño de las transacciones.
Esta reducción de las confirmaciones en el hallazgo de ADDM también fue sugerida por Oracle Support. Desde mi punto de vista, no era tan alto.

Período de tiempo más corto

Debido a que el AWR no me estaba ayudando a encontrar la causa, necesitaba investigar un período de tiempo más corto. Quería saber un plazo de tiempo más específico para poder crear un informe de CENIZAS. El valor predeterminado para ASH es de 15 minutos.
Así que el siguiente desafío fue encontrar el período de tiempo de 15 minutos en el que la tasa de crecimiento de SCN era la más alta.
Doc ID 1388639.1 sugerido para consultar v archiv archived_log. Esa vista tiene información sobre todos los conmutadores de registro de la base de datos, incluida una marca de tiempo y el SCN. Aunque puede asignar marcas de tiempo a SCN, no es realmente mejor que el informe AWR. Todavía estamos pegados a marcas de tiempo aleatorias; en este caso, la marca de tiempo del interruptor de registro.

Usando la función timestamp_to_scn

Una mejor manera es usar la función timestamp_to_scn. Esta función devuelve un SCN basado en una marca de tiempo, como la marca de tiempo actual:

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

El siguiente paso fue hacer una lista de las marcas de tiempo, junto con la coincidencia de SCN y la coincidencia de SCN límite superior, basado en el número de segundos desde 1988 multiplicado por 16.384.

Esto muestra las marcas de tiempo y SCN del último día:

     
  1.  SELECT 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-AAAA' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  DE doble
    6.  
  6.  CONECTAR POR 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 filas seleccionadas. 
    29.

El SCN actual es de aproximadamente el 0,57% del límite superior actual.

Encontrar la tasa de SCN superior

En base a esta idea, creé una consulta que me da el período de tiempo de 15 minutos con el mayor crecimiento en SCN en los últimos 3 días.

Cada minuto comienza un nuevo marco de tiempo, y debido a que tenemos 1440 minutos en un día, tenemos 4320 marcos de tiempo para investigar. Para cada uno de ellos tenemos que calcular el crecimiento del SCN dentro de ese plazo de 15 minutos.

Solo queremos mostrar los mejores resultados, en este caso solo los plazos con una tasa de más de 14000 por segundo.

     
  1.  ALTER SESSION SET nls_date_format= 'MM / DD / AA HH24: MI' ;
    2.  
  2.  
    3.  
  3.  CON datelist COMO 
    4.  
  4.  ( SELECT sysdate - (rownum/1440) - (15/1440) starttime -- intervalo de 15 minutos 
    5.  
  5.  , sysdate - (rownum/1440) endtime
    6.  
  6.  DE doble
    7.  
  7.  CONECTAR POR rownum <= (3*1440) -- 3 días de la historia 
    8.  
  8. )
    9.  
  9.  SELECCIONE starttime
    10.  
  10.  , endtime
    11.  
  11.  , timestamp_to_scn(hora de finalización) - timestamp_to_scn(starttime) scngrowth
    12.  
  12.  , round((timestamp_to_scn(hora de finalización) - timestamp_to_scn(starttime)) / 
    13.  
  13.  (((24*60*60)*(endtime-starttime )))) scnrate
    14.  
  14.  DE datelist
    15.  
  15.  DONDE todo el año((timestamp_to_scn(hora de finalización) - timestamp_to_scn(starttime)) / 
    16.  
  16.  (((24*60*60)*(endtime-starttime )))) >= 14000 
    17.  
  17.  ORDEN de 4 DE DESC 
    18.  
  18. /
    19.  
     
  1. hora de inicio hora de finalización 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.

Por lo tanto, ahora hemos encontrado los marcos de tiempo de 15 minutos (a veces superpuestos) con la tasa de SCN más alta (crecimiento de SCN por segundo) para los últimos 3 días. E incluso en esos marcos de tiempo, la tasa de SCN todavía está por debajo de 16384. No hay advertencias en el archivo de alerta esta semana….

Ejecutar el informe ASH

El formato de fecha que utilicé en la consulta anterior es el mismo que el utilizado por el informe ASH, por lo que solo puede copiar/pegar la hora de inicio. Para la duración entramos en 15 minutos.

     
  1. SQL> @@$ORACLE_HOME/rdbms/admin/ashrpt.sql
    2.  
  2.  
    3.  
  3. Muestras de CENIZAS EN este Repositorio de Carga de trabajo del esquema de
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. más antiguo de la CENIZA de la muestra disponible: 01-Jul-18 00:00:01 
    7.  
  7. Últimas CENIZAS de la muestra disponible: 09-Jul-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. Especifica el período de tiempo PARA generar el informe de CENIZA
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. Introduzca la HORA de comienzo PARA el informe:
    13.  
  13.  
    14.  
  14. -- Válido formatos de entrada:
    15.  
  15. -- Para especificar absoluta hora de comienzo:
    16.  
  16. -- ] HH24:MI
    17.  
  17. -- Ejemplos: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- Para especificar la relación tiempo de inicio: (comienza con '-' signo)
    22.  
  22. -- -MI
    23.  
  23. -- Ejemplos: -1:15 (SYSDATE-1 Hora 15 Minutos)
    24.  
  24. -- -25 (SYSDATE - 25 Minutos)
    25.  
  25.  
    26.  
  26. Valores predeterminados A -15 minutos
    27.  
  27. Introduzca EL VALOR DE hora de inicio: 07/06/18 18:09
    28.  
  28. HORA DE INICIO DEL informe especificada: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. Ingrese la duración EN minutos a partir DE LA HORA DE INICIO:
    31.  
  31. EL valor predeterminado ES SYSDATE-begin_time
    32.  
  32. Pulse Intro PARA analizar hasta LA HORA ACTUAL
    33.  
  33. Introduzca EL VALOR DE duración: 15 
    34.  
  34. Informe de tiempo especificado: 15 
    35.  
  35.  
    36.  
  36.  UTILIZANDO el 06-Jul-18 18:09:00 a informar de la HORA de comienzo 
    37.  
  37.  UTILIZANDO el 06-Jul-18 18:24:00 COMO el informe FINAL del TIEMPO 
    38.  
  38.  
    39.  
  39. Especifique el Nombre de Informe
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. El informe PREDETERMINADO nombre de archivo ES ashrpt_1_0706_1824.HTML. PARA USAR este nombre, 
    42.  
  42. pulse < return> PARA continuar; de lo contrario, introduzca una alternativa. 
    43.  
  43. Introduzca EL VALOR DE nombre_informe:
    44.  
  44.  
    45.  
  45.  UTILIZANDO el nombre del informe ashrpt_1_0706_1824.html
    46.  
  46.  
    47.  
  47. Resumen DE TODAS las entradas de USUARIO 
    48.  
  48. -------------------------
    49.  
  49. Formato : HTML
    50.  
  50. DB Id : 2019395491 
    51.  
  51. Inst num : 1 
    52.  
  52.  TIEMPO de inicio : 06-Jul-18 18:09:00
    53.  
  53.  la HORA de FINALIZACIÓN : 06-Jul-18 18:24:00
    54.  
  54. Ranura de ancho : DEFAULT 
    55.  
  55. Informe de los objetivos de : 0 
    56.  
  56. nombre del Informe : ashrpt_1_0706_1824.html
    57.

Encontrar SCN en AWR

El informe AWR no nos mostró mucha información sobre el SCN actual, pero tiene algo de información sobre la tasa de crecimiento, si sabe dónde encontrarlo.

En » Estadísticas de actividad de instancia «puede encontrar el número de»llamadas a kcmgas». En la documentación de Oracle, esto se describe como el «Número de llamadas a kcmgas de rutina para obtener un nuevo SCN».

El valor de estas llamadas por segundo en el informe AWR es muy cercano a la tasa SCN calculada con la función timestamp_to_scn.

V view SESSTAT view

El número de «llamadas a kcmgas» utilizadas para crear un nuevo SCN también se puede encontrar en las vistas V SES SESSTAT y V SY SYSSTAT.

Podemos usar V SES SESSTAT para encontrar las sesiones que causan una alta tasa de SCN. También podemos probar el impacto en el número de acciones específicas de SCN.

Por ejemplo, cuando hago una selección en una mesa grande que también está en uso por otras sesiones, mi sesión hará otras 7 llamadas a kcmgas. Por lo tanto, mi consulta causará un SCN más alto. Esto se debe a la consistencia de lectura de la base de datos, que también utiliza un SCN.

     
  1. SQL> CONECTAR <usuario>/<paso>@<servicio de> 
    2.  
  2. Conectado. 
    3.  
  3. SQL> SELECCIONE ses.valor
    4.  
  4.  DE v$sesstat ses
    5.  
  5.  , v$statname stat
    6.  
  6.  DONDE stat.estadística#=ses.estadística#
    7.  
  7.  Y ses.entrada DE sid (SELECCIONAR sid DE v myst mystat) 
    8.  
  8.  Y de inmediato.nombre = 'llamadas a kcmgas' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  VALOR 
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL> SELECT COUNT(*) FROM mybigtable ;
    16.  
  16.  
    17.  
  17.  CONTAR(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL> SELECCIONE ses.valor
    22.  
  22.  DE v$sesstat ses
    23.  
  23.  , v$statname stat
    24.  
  24.  DONDE stat.estadística#=ses.estadística#
    25.  
  25.  Y ses.entrada DE sid (SELECCIONAR sid DE v myst mystat) 
    26.  
  26.  Y de inmediato.nombre = 'llamadas a kcmgas' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  VALOR 
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

la Comparación de la SCN y la tasa de confirmación

Con V$SESSTAT podemos consultar las estadísticas de todas las sesiones actualmente conectado a la base de datos. De esta manera podemos encontrar sesiones que son responsables de una alta tasa de SCN. Podemos comparar esto con la tasa de confirmación de esa sesión.

Los resultados de la consulta a continuación nos mostraron que en nuestra base de datos la alta tasa de SCN fue causada principalmente por procesos en segundo plano. Para la mayoría de las sesiones de usuario hay una relación entre una alta tasa de SCN y una alta tasa de confirmación, para las sesiones en segundo plano, la tasa de confirmación siempre está vacía.

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

Conclusión

Tenga en cuenta que hay límites para el SCN, por lo que cuando encuentre advertencias en el archivo de alertas, debe investigar el problema. Si encuentra un problema, debería trabajar con Oracle Support. Al cargar información, pueden verificar si hay suficiente espacio entre el SCN actual y el máximo.

Los problemas pueden ser causados por un error, como 12371955: La copia de seguridad en caliente puede causar un aumento de la tasa de crecimiento de SCN que conduce a errores ORA-600 (Doc ID 12371955.8).

Si desea encontrar el momento exacto en el que hay un alto crecimiento de SCN, debe convertir las marcas de tiempo en SCN. Obtendrá los mejores resultados utilizando las funciones SCN_TO_TIMESTAMP y TIMESTAMP_TO_SCN.

Una tasa de confirmación alta siempre está relacionada con los procesos de usuario, pero los SCN también están relacionados con los procesos en segundo plano. Incluso las sesiones que no se comprometen pueden tener un impacto en el SCN.

Bastiaan Bak

Sobre el autor Bastiaan Bak

DBA con más de 15 años de experiencia. Experiencia en varias ramas, con varios módulos. Incluir: Base de datos Oracle, Oracle RAC, Oracle EBS y PL / SQL.

Más publicaciones de Bastiaan Bak

Deja una respuesta

Tu dirección de correo electrónico no será publicada.