« Oracle 12c New Features : Ejecución de sentencias SQL a través de RMANOracle 12c New Features : Invisible Columns »

¿Qué es un CRASH RECOVERY o INSTANCE RECOVERY?



¿Qué es un Crash Recovery o un instance Recovery?



Este concepto no es más que la recuperación de una base de datos Oracle sin intervención alguna después de que ha sufrido alguna caída inesperada, este tipo de caidas pueden ser provocadas por un corte de electricidad, desmontaje de un disco donde reside el motor, una eliminación manual de algún proceso background necesario (smon,pmon), un shutdown abort, etc.

Cuando sucede lo anterior, al levantar la base de datos esta por sí sola comienza el proceso de recuperación o crash recovery, pues es el System monitor (SMON) que detecta que Oracle no se bajo de la mejor forma y que algunos datafiles quedaron desincronizados con respecto al último SCN que queda registrado en el controlfile.

Para realizar un Crash Recovery Oracle utiliza la información que se encuentra en los redologs (técnicamente llamados online redologs), para lo anterior Oracle realiza algunos dos pasos importantes :

1.- Rolling Forward : En este proceso en partícular, Oracle va a actualizar todos los datafiles con TODA la información que encuentre en el último redologs utilizado hasta el momento de la caída, cabe recordar que Oracle escribe primero en los redologs y una vez escrito allí comienza a trasladar la información a los datafiles, es por eso que ante una caída abrupta de la base, hay ciertos registros o transacciones que no han sido pasada a los datafiles y que aún se encuentran en los redologs.

2.- Rolling Back : Con el proceso de "Rolling Forward" se pasaron todos los cambios encontrados en el último redolog utilizado hacía los datafiles y por cada cambio se generó una entrada en el tablespace de UNDO, pues bien, NO TODAS las transacciones que se aplicaron en los datafiles fueron "Comiteadas" , o sea, existen algunas transacciones a las cuales se les aplico un Rollback, pero esto Oracle no tiene como saberlo dado que los archivos de redologs son secuenciales, el no sabe si por delante de una transacción cualquiera
viene un commit o un rollback , si se traspaso a los datafiles una transacción que posteriormente se le aplicó un rollback, pues Oracle saca la información anterior desde el tablespace de UNDO, el cual se fue llenando de información a partir del proceso de Rolling Forward.

Cuando el punto 2 finaliza, sólo información realmente comiteada queda en los datafiles y es allí donde la base de datos queda en estado OPEN.

En el punto 1 , Oracle va a aplicar todas las transacciones que se encuentran entre el último Checkpoint que se produjo en la base de datos (que se encuentra marcado dentro del archivo de redolog que estaba en estado CURRENT antes de la caída) y el final del mismo archivo de redolog, está cantidad de información es la que Oracle va a aplicar en los datafiles, esta cantidad de información puede ser controlada mediante un parámetro llamado FAST_START_MTTR_TARGET (la sigla MTTR viene de las palabras MEAN TIME TO RECOVER) , con este parámetro se le busca indicar a Oracle que cantidad de segundos el se debiese demorar en realizar un CRASH RECOVERY, Oracle es capaz mediante formulas internas de convertir esos segundos a cantidad de transacciones.

El máximo valor para el parámetro FAST_START_MTTR_TARGET es 3600 segundos , o sea, que Oracle en el peor de los casos se podría demorar hasta una hora en hacer un CRASH RECOVERY después de una caida abrupta

by Ligarius
20.08.13. 07:42:32. 593 words, 4839 views. Categories: Base de datos, Conceptual ,