Oracle – Evitar los Errores ORA-1555
Fuente: http://www.ixora.com.au/tips/admin/ora-1555.htm
Uno de los problemas más molesto que Oracle DBA en todo el mundo se enfrentan todos los días es la siguiente:
ORA-1555: Imágenes demasiadas viejas: Número de reversión segmento 9 con el nombre “R07″ demasiado pequeño.
Para la mayoría de los DBA no está nada claro lo que podría haber causado el error, e incluso más sorprendente en cuanto a cómo pueden prevenir que ocurra de nuevo. Pero quizás la cosa más exasperante acerca de este error es que las consultas son más propensas a ella cuando han estado funcionando durante mucho tiempo, y por lo tanto muchas horas de procesamiento se pueden perder.
La buena noticia es que es fácil de evitar este error total y absolutamente.
- ¿Qué significa el error?
El error ORA-1555 significa que uno recibe un bloque consistente de base de datos particular que ha fracasado.Cuando una operación o consulta comienza, el SCN actual se registra. Esa SCN sirve como la instantánea SCN para la consulta o transacción. Este término se deriva de la obligación de que la transacción o consulta deba ver una coherencia instantánea de la base de datos en ese momento.Cada bloque utilizado para seleccionar filas de la consulta o transacción debe reflejar el estado de la base de datos en la instantánea SCN. Esto se aplica a la selección de filas que se actualizan o eliminan, tanto como lo hace a la selección de filas de una consulta. Si un bloque tiene que ser cambiado, entonces los cambios se aplicarán a la versión actual de ese bloque. Sin embargo, la selección de las filas que se cambió debe basarse en una versión del bloque coherente con las instantáneas SCN. La reconstrucción de una versión temporal del bloque en consonancia con la instantánea SCN se denomina un encuentro consistente. - ¿Por qué no es coherente?
Hay dos tipos para obtener un coherente fracaso: Fallo en la cancelación, y la falta de limpieza.
Fallo
Si el bloque se ha modificado en modo alguno por otra transacción, entonces los cambios se deben deshacer para que sea coherente. Para ello, es necesario leer los datos por segmentos para deshacer a los que la información de reversión de esos cambios fueron escritos.
Sin embargo, si cualquiera de estos cambios fueron hechos por una operación discreta, entonces no habrá ninguna información de reversión, porque las transacciones discretas no generan información para deshacer. Si es así, un error ORA-1555 se incrementará. Del mismo modo, un error ORA-1555 se incrementará si los bloques de reversión requiere segmento que ya no están disponibles debido a que la medida del segmento de cancelación que contenga dichos bloques se haya desasignado en una operación de reducción, o reutilizados por las operaciones posteriores.
Tenga en cuenta que los bloques segmento de cancelación requeridos son los que fueron utilizados por otras operaciones que han modificado el bloque después de la instantánea SCN. Estos bloques pueden estar en cualquier segmento de cancelación en la base de datos.
Tenga en cuenta además que, en esos bloques no esté disponible en virtud de la reutilización medida, todas las extensiones en ese segmento de cancelación se debe haber sido utilizada al menos una vez desde el NSQ instantánea. Por ello, el mensaje de error indica que el segmento de cancelación es demasiado pequeño.
- Error de limpieza
El DBWn escribe a menudo un bloque en el disco antes de la última transacción para modificar el bloqueo que se ha cometido. Si es así, la lista de transacciones interesados en el encabezado del bloqueo, demuestran que las transacciones tienen un interés abierto en el bloqueo, y el nivel de fila se trabe en los encabezados de fila de las filas afectadas permanecen en vigor. Cuando el bloque se lee de otra consulta o transacción, la limpieza del bloqueo debe ser realizada. Se trata de averiguar si la transacción anterior se ha comprometido, y si es así sus bloqueos a nivel de fila se limpian y se comprometen a la transacción del SCN para el registro de la lista de transacciones de inscripción en el encabezado del bloque.Para conseguir una coherencia, la limpieza del bloque es necesario para establecer la secuencia relativa de la confirmación de la transacción SCN interesadas y este para obtener la constante. Si la transacción interesados todavía no ha cometido, o de cometidos después de la SCN instantánea, se necesita deshacer como se describe anteriormente. Pero si la transacción interesados son cometidos antes de la SCN instantánea, ninguna reversión de sus cambios es necesario.Para determinar el SCN hay que comprometerse para una transacción interesadas, si no está ya inscrita en el registro de transacción lista de interesados, y si ya no está activa, es necesario consultar la tabla de transacciones en el bloque de reversión encabezado del segmento que fue utilizado por que transacción. El número de segmento de cancelación de la operación de interesados se codifica en el registro de transacción interesadas como parte del identificador de transacción. Sin embargo, el bloque encabezado por ese segmento de cancelación no podrán contener un registro de la transacción interesados, porque ese bloque también está sujeto al cambio y a la transacción pueden ser antiguos.Afortunadamente, sin embargo, al obtener la coherencia no es necesario determinar la confirmación exacta del SCN para la transacción – sólo la secuencia relativa de la confirmación del SCN y el SCN instantánea. Por lo tanto, bastará con realizar un objetivo recursivo que consiste en el bloque del encabezado del segmento anterior y el segmento de cancelación de la operación de los interesados. Si eso es tener coherencia con éxito, y si el encabezado de transacción para interesadas transacción no se conserva en la versión compatible de su bloque de reversión, el encabezado del segmento, y si el identificador de transacción indica que la transacción es anterior a la SCN instantánea, se puede concluir de que la transacción comprometidos en la antigüedad relativa, y así no volver hacia atrás lo requerido.(Por cierto, para las actuales limpiezas de modo de bloque, el segmento de cancelación en el bloque de cabecera se revierte a medida de lo posible y el mayor compromiso SCN disponibles para cualquier operación en ese segmento de cancelación y en ese momento se registra en la lista de transacciones interesadas la entrada como el límite superior por su compromiso. En otras palabras, la transacción se marca como haber cometido dicha SCN).
Sin embargo, es posible que la recibe en el bloque del encabezado coherente del segmento para una transacción interesados a fallar. Esto puede ocurrir si la información se deshace para cualquiera de los cambios en ese bloque de encabezado del segmento desde el NSQ que no están disponibles. Estos cambios se escriben en el segmento de cancelación que sí están sujetos a la falta de disponibilidad debido a la reutilización de grados o desafectación de la misma manera como otros cambios. Sin embargo, hay más libertad en el caso de los cambios del segmento de las tablas anteriores de transacciones. Debido a que las ranuras de la tabla de transacciones se vuelven a utilizar en función del ciclo, el segmento de extensiones de cancelación se puede tener que volver a utilizar muchas veces la información para deshacer el encabezado de transacción y para que una transacción interesados se representara lo que no está disponible.
- ¿Cómo puede reducir el riesgo?
Las siguientes pautas sencillas se deben seguir para reducir el riesgo de errores de instantáneas demasiado viejo.
- No ejecute las operaciones discretas mientras que las consultas o transacciones sensibles se están ejecutando, a menos que esté seguro de que los conjuntos de datos requeridos son mutuamente excluyentes.
-Programas de larga consultas de ejecución y las operaciones fuera de horario, por lo que la coherencia no se necesita a los cambios realizados desde la reversión SCN instantánea. Esto también reduce el trabajo realizado por el servidor, y por lo tanto mejora el rendimiento.
- Los procesos de Códigos largos se ejecutan como una serie de pasos al reiniciar.
-Reducir todos los segmentos para deshacer de nuevo a su tamaño óptimo manualmente antes de ejecutar una consulta o transacciones sensibles para reducir el riesgo de obtener un fallo en la cancelación debido a la desasignación medida. Esto se puede hacerse con la secuencia de comandos: shrink_rollback_segs.sql APT.
-Utilice un gran valor óptimo en todos los segmentos para deshacer, para retrasar la medida en la reutilización. Para una idea de cuánto tiempo usted podría tener antes de que llegue el problema, la secuencia de comandos APT rollback_reuse_time.sql puede ser utilizado para obtener el tiempo medio antes del segmento de reutilización medida.
-No buscar a través de confirmaciones. Es decir, no buscar en un cursor que se abrió antes de la última confirmación, sobre todo si los datos consultados por el cursor se va a cambiar en el actual período de sesiones.
-Use un tamaño de bloque grande de base de datos para maximizar el número de franjas horarias en las tablas de segmento de negocios anteriores, y retrasar así la reutilización de espacios.
-Comprometerse con menos frecuencia en las tareas que se ejecutarán al mismo tiempo, como la consulta sensibles, en particular en los procedimientos PL / SQL, para reducir la reutilización de transacción.
-Si es necesario, añadir segmentos adicionales para deshacer más espacios y hacer transacciones disponibles.
Tenga en cuenta que la adición de segmentos para deshacer de algo extra en conflicto con el uso de un gran tamaño óptimo, asumiendo que el espacio en el disco disponible para los segmentos para deshacer es invariante. La elección de una estrategia en este punto debiera depender del riesgo relativo de tener fracasos de coherente reversión, en lugar de obtener coherente fracasos de limpieza.
- ¿Qué se puede hacer cuando todo lo demás falla?
Para consultas y transacciones especialmente sensibles, todo esto es la reducción de riesgos innecesarios. Todo lo que se necesita es evitar que la desafectación o la reutilización de cualquier segmento de extensiones que han sido utilizados por todas las operaciones posteriores a la SCN instantánea.Una forma sencilla de hacerlo es asegurarse de que sólo hay una (grande) en línea un segmento desde el momento de la SCN instantánea, y de utilizar explícitamente que segmento de cancelación para la consulta o transacción sensibles. Esto protege a todas las extensiones en ese segmento de cancelación que se pueden utilizar a partir de entonces, de desafectación medida y la reutilización, hasta la conclusión de las transacciones sensibles o de consulta.Una variante más sofisticada sobre el mismo tema es dejar una transacción no comprometidos en cada segmento de cancelación en línea. Por supuesto, esto introduce un riesgo de quedarse sin espacio en el segmento de tablas, pero el riesgo es relativamente fácil de controlar. El siguiente conjunto de secuencias de comandos de APT se puede utilizar para aplicar esta técnica en los sistemas Unix.
-prevent_1555_setup.sql
Esta secuencia de comandos crea una tabla agrupada en el esquema de sistema que se utiliza para implantar y registrar la protección de los segmentos para deshacer de extensión y de la reutilización.
-prevent_1555.sql
Esta es la secuencia de comandos principales. Está es llamada para garantizar la protección de errores Ora-1555 de un número determinado de segundos. Este comando llama protect_rbs.sql en el fondo de cada segmento de cancelación en línea.
-protect_rbs.sql
Esta secuencia de comandos contrae el primer segmento de cancelación especificada para reducir el riesgo de quedarse sin espacio en el segmento de las tablas. A continuación, deja constancia de su protección en el control de tablas, antes de salir de una transacción no comprometidos para el descanso de la cantidad necesaria de segundos.
-prevent_1555_wait.sql
Esta secuencia de comandos se debe ejecutar después de las operaciones ficticias se han creado en cada segmento de cancelación en línea. Se espera que todas las transacciones activas finalicen. Esto es necesario en entornos con otras transacciones de larga ejecución que aún no ha terminado, porque antes deshacer esas transacciones no está protegida y podría ser requerida por el informe crítico a menos que estas operaciones se les permite terminar antes del inicio del informe crítico.
-protected_rollback_segs.sql
Esta secuencia de comandos se utiliza para informar el estado de protección de los segmentos para deshacer.
Conclusión
Leonardo Adrián Tocci – 3801-1732
Javier Hernán Lafont – 4001-2676
Silvio Segurotti – 1328-0148
Hay varias razones por las cuales se puede producir el error ORA-1555: snapshot too old, imagen demasiado vieja.
El término de segmento de rollback, que lo podemos traducir como ‘segmento para deshacer’. Son objetos creados en la base de datos, con el objetivo de almacenar la información que las transacciones van modificando, para que las operaciones de consulta sean consistentes mediante la búsqueda de los datos en estos segmentos.
Otro razón es en la que los datos devueltos por una consulta sean consistentes respecto al momento en que se inició la misma. Por lo tanto, la consulta nunca ve los cambios hechos por las transacciones que realizan commit durante la ejecución de la consulta.
Oracle identifica unívocamente cualquier momento en el tiempo a través de un conjunto de números llamados Números de Cambio en el Sistema, System Change Numbers (SCN). Por eso, podemos definir un SCN como el estado en el cual se encuentra la base de datos en un momento dado en el tiempo. Esto funciona de la siguiente forma, cuando la consulta comienza a ejecutarse, Oracle marca el SCN actual, a partir de ese instante, la consulta solo podrá ver la imagen que los datos tenían al momento en que se marcó dicho SNC. De esta forma se garantiza la consistencia de lectura de los datos, ya que cualquier modificación efectuada a los mismos, no podrá ser vista por la consulta que haya comenzado su ejecución anterior a las modificaciones, aunque la misma finalice después de las modificaciones.
Para que esto realmente pueda funcionar, se utilizan los segmentos de rollback. Cuando una transacción realiza cualquier cambio, se guarda una copia de los datos afectados, antes que los mismos sean modificados, en un segmento de rollback. Además, en la cabecera de bloque de la fila que se está modificando, se guarda la dirección del bloque del segmento de rollback donde se están escribiendo los cambios. El bloque de datos también guarda registro del SCN del último commit que modificó el bloque.
A medida que se leen los bloques de datos a través de la consulta, solo se tomarán en cuenta aquellos que tengan un SCN menor al SCN de la consulta, si un bloque ha sido modificado por alguna otra transacción sin haber hecho commit o tiene datos cambiados con un SCN mas reciente, entonces los datos se reconstruirán usando las imágenes guardadas en los segmentos de rollback. Por eso, si por alguna razón Oracle no puede reconstruir la información requerida por una consulta, que lleva demasiado tiempo ejecutándose, utilizando el snapshot almacenado en los segmentos de rollback, se producirá el error ORA-1555
