El principio y la función del registro de rehacer

REDO LOG es un mecanismo establecido por Oracle para garantizar que las transacciones confirmadas no se pierdan. De hecho, la existencia de REDO LOG está preparada para dos escenarios, uno se llama recuperación de instancia (RECUPERACIÓN DE INSTANCIA), uno se llama RECUPERACIÓN DE MEDIOS. El propósito de la recuperación de la instancia es asegurar que los datos en BUFFER CACHE no se pierdan cuando la base de datos falla, y no causará inconsistencia en la base de datos. El propósito de la recuperación de medios es recuperar datos cuando falla un archivo de datos. Aunque los mecanismos utilizados para estas dos recuperaciones son similares, los dos tipos de recuperación también son muy diferentes, lo que a menudo es confundido por muchos DBA.

Los datos de REDO LOG se organizan de acuerdo con THREAD. Para sistemas de una sola instancia, solo hay un THREAD. Para sistemas de RAC, puede haber múltiples THREADs. Cada instancia de la base de datos tiene un conjunto separado de REDO. El archivo LOG tiene un LOG BUFFER separado, y un cambio de instancia se registra de manera independiente en un archivo THREAD REDO LOG.

Para la recuperación de medios y la recuperación de instancias, el primer paso es avanzar a través de la información de REDO LOG. Al avanzar, pase el vector de cambio de base de datos registrado en el archivo REDO LOG (más adelante Presentaremos el CV del vector de cambio de la base de datos en detalle y lo enviaremos al archivo de datos relevante de acuerdo con la comparación de SCN, de modo que el estado del archivo de datos se desplace hacia adelante. Cabe señalar que los cambios en el espacio de tabla UNDO también se registran en el REGISTRO DE REDO, por lo que los archivos de datos relacionados con el espacio de tabla UNDO también se avanzan. Cuando se enrolla el actual registro de REDO o el registro de archivado, se completan todos los aspectos de recuperación de la base de datos. En este momento, la base de datos contiene todos los cambios registrados, algunos de los cuales se han confirmado y otros aún no se han enviado. En el estado más reciente del espacio de tabla UNDO, también podemos ver algunas transacciones no confirmadas.

Entonces, lo siguiente que debe hacer la base de datos es el procesamiento a nivel de transacción, deshacer las transacciones que aún no se han comprometido para garantizar la consistencia de la base de datos.

Para un sistema de una sola instancia, la recuperación de la instancia generalmente se realiza cuando la base de datos se reinicia después de una falla anormal de la instancia de la base de datos. Cuando la base de datos ejecuta SHUTDOWN ABORT o se reinicia debido a sistema operativo, host, etc. Después de eso, cuando ALTER DATABASE OPEN, automáticamente realizará la recuperación de la instancia. En el entorno de RAC, si una instancia es aplastada o la instancia tomará el control, la instancia se restaurará para la instancia. A menos que todas las instancias estén paralizadas, la primera instancia de ALTER DATABASE OPEN realizará la recuperación de la instancia. Esta es la razón por la que REDO LOG es un componente privado de instancia, pero el archivo REDO LOG debe almacenarse en un almacenamiento compartido.

El mecanismo CACHE de la base de datos Oracle está orientado al rendimiento. El mecanismo CACHE debería maximizar el rendimiento de la base de datos, por lo que CACHE siempre se retrasa tanto como sea posible. Este mecanismo mejora en gran medida el rendimiento de la base de datos, pero cuando la instancia falla, pueden surgir algunos problemas.

En primer lugar, en el caso de una falla de instancia, es posible que algunas de las modificaciones al archivo de datos no se escriban completamente en el disco, y cierta información modificada sobre el archivo de datos confirmado por la transacción puede perderse en el archivo de disco. Segundo, es posible que algunos cambios en el archivo de datos para una transacción que aún no se haya confirmado se hayan escrito en el archivo de disco. También es posible que algunos de los datos modificados por un átomo se hayan escrito en el archivo, y algunos de los datos aún no se hayan escrito en el archivo de disco. La recuperación de la instancia es completar automáticamente la reparación de los datos anteriores a través de la información registrada en el archivo ONLINE REDO LOG. Este proceso es completamente automático y no requiere intervención humana.

En este mecanismo, hay dos problemas que deben resolverse: el primero es cómo garantizar que las transacciones comprometidas no se pierdan y el segundo es cómo hacer que el tiempo de la base de datos y la recuperación de la instancia se pierdan. Equilibrado, asegurando que el rendimiento de la base de datos no se degrade y que la recuperación de la instancia sea rápida.

Resolver el primer problema es relativamente simple. Oracle tiene un mecanismo llamado Log-Force-at-Commit, es decir, cuando la transacción se confirma, los datos de REDO LOG relacionados con la transacción, incluido el registro COMMIT, El archivo REDO LOG debe escribirse desde LOG BUFFER, y la señal de que la transacción se realiza correctamente puede enviarse al proceso del usuario. A través de este mecanismo, se puede garantizar que incluso si parte del BUFFER CACHE en la transacción ya enviada no se ha escrito en el archivo de datos, se produce un error de instancia y, cuando se restaura la instancia, los datos inconsistentes también se pueden obtener a través de la información del REDO LOG. Rodar hacia adelante.

Para resolver el segundo problema, oracle se implementa a través del mecanismo de control. En la base de datos Oracle, la operación de modificación de BUFFER CAHCE se completa con el proceso en primer plano, pero el proceso en primer plano solo es responsable de leer el bloque de datos del archivo de datos en BUFFER CACHE, y no es responsable del archivo de datos de escritura BUFFER CACHE. La operación de BUFFER CACHE para escribir archivos de datos se realiza mediante el proceso en segundo plano DBWR. DBWR puede escribir una parte del bloque de datos en el archivo de datos de acuerdo con la condición de carga del sistema y si otros procesos utilizan el bloque de datos. Bajo este mecanismo, el momento en que un bloque de datos se vuelve a escribir en el archivo puede ser aleatorio, y algunos de los primeros bloques de datos modificados se pueden escribir en el archivo de datos más adelante. El mecanismo CHECKPOINT es un complemento efectivo de este mecanismo. Cuando se produce CHECKPOINT, el proceso CKPT le pedirá al proceso DBWR que vuelva a escribir todos los bloques modificados de cierto SCN en el archivo de datos. Por lo tanto, una vez que se completa este CHECKPOINT, todos los cambios de datos se guardan antes de que se haya guardado el SCN. Si se produce una falla en la instancia, entonces, cuando se restaura la instancia, solo es necesario iniciar el cambio después de que se haya completado el CHECKPOINT. Los cambios anteriores no necesitan ser considerados.

Hasta ahora, hemos aprendido algunos principios básicos del mecanismo de recuperación de instancias y podemos entender el mecanismo de trabajo de REDO LOG en general. Pero creo que todavía tenemos que ir más profundo. Aprenda un poco más profundo de información privilegiada. De hecho, a través de la introducción del antiguo blanco anterior, es posible que ya sienta que la comprensión de la recuperación de la instancia es muy completa, pero de hecho, hay muchos problemas que no hemos resuelto. Es posible que algunos lectores amantes de la mente tengan que preguntar si es posible que se hayan escrito los cambios en el archivo de datos, pero la información de REDO LOG todavía se encuentra en LOG BUFFER, y no se ha escrito REDO LOG. ¿Cómo se puede restaurar esta situación?

Aquí tenemos que introducir un sustantivo: Write-Ahead-Log, que es la prioridad de escritura de log. La prioridad de escritura del registro incluye dos aspectos del algoritmo. El primer aspecto es que los datos de BUFFER CACHE modificados no pueden escribirse en el archivo de datos hasta que el vector de cambio modificado de BUFFER CACHE no se haya escrito en el archivo REDO LOG. Esto asegura que es imposible incluir cambios que no se registran en el archivo REDO LOG en el archivo de re-datos, el segundo aspecto es que BUFFER CACHE no está escrito en el REDO LOG para el vector de cambio de la información UNDO de cierta información. Las modificaciones no se pueden escribir en el archivo de datos.

El mecanismo de recuperación de medios y recuperación de instancias es similar. La diferencia es que la recuperación de medios se realiza cuando falla el archivo de datos almacenados. La recuperación de medios no se puede realizar automáticamente. Debe realizar la recuperación o recuperación de la base de datos manualmente. Se implementa el comando datafile. En general, la recuperación de medios es una recuperación de un archivo de datos recuperado, por lo que necesita usar registros archivados cuando realiza la recuperación de medios.

Reimpresión de una cueva desde los pelícanos blancos

Un breve resumen:

El rol del registro de rehacer: 1. Recuperar la base de datos como medio Archivo importante 2. Como una instancia para restaurar la base de datos, mantener la consistencia de la base de datos juega un papel importante.

Al realizar la recuperación de la instancia, la clave importante para la consistencia es rehacer el archivo de registro. Oracle garantiza que toda la información de confirmación de éxito se escribe primero para rehacer. Logfile, luego cambiar el archivo de datos. Cuando se cambia el archivo de datos, primero se escribe el caché del búfer en el caché del búfer para escribir el archivo de datos en el proceso dbwr, se escribe la inconsistencia causada por la mitad de la falla de alimentación, Oracle usa el proceso chkp para escribir el archivo de datos periódicamente.
(el punto de control actualizará periódicamente el archivo de datos que sea mayor que el SCN anterior para forzar una respuesta por escrito al archivo de datos).

Pero el registro de rehacer se escribe primero en el búfer de registro de rehacer. Si el búfer de registro de rehacer no se escribe en el archivo de registro de rehacer, ¿qué debo hacer? 1. Los datos del BUFFER CACHE modificado no se pueden escribir en el archivo de datos hasta que el vector de cambio modificado de un BUFFER CACHE no se haya escrito en el archivo REDO LOG. 2. La modificación de este BUFFER CACHE no se puede escribir en el archivo de datos hasta que el vector de cambio de la información UNDO de ciertos datos no se escriba en el REDO LOG.