Backups optimizados para Snapshot de almacenamiento
Sugerir cambios
PDF
Cuando se lanzó Oracle 12c, ya que no es necesario colocar una base de datos en modo de backup dinámico, se simplificaron aún más las tareas de backup y recuperación basadas en Snapshots. El resultado es la capacidad de programar backups basados en snapshots directamente en un sistema de almacenamiento y mantener la capacidad para realizar una recuperación completa o de un momento específico.
Aunque el procedimiento de recuperación de backup dinámico es más familiar para los administradores de bases de datos, durante mucho tiempo ha sido posible usar snapshots que no se crearon mientras la base de datos estaba en modo de backup dinámico. Oracle 10g y 11g requerían pasos manuales adicionales durante la recuperación para hacer que la base de datos fuera coherente. Con Oracle 12c, sqlplus y.. rman contienen la lógica adicional para reproducir archive logs en copias de seguridad de archivos de datos que no estaban en modo de copia de seguridad activa.
Como hemos visto anteriormente, la recuperación de un backup en caliente basado en instantáneas requiere dos conjuntos de datos:
-
Instantánea de los archivos de datos creados en modo de backup
-
Los registros de archivos generados mientras los archivos de datos estaban en modo de backup dinámico
Durante la recuperación, la base de datos lee los metadatos de los archivos de datos para seleccionar los archive logs requeridos para la recuperación.
La recuperación optimizada para snapshot de almacenamiento requiere conjuntos de datos ligeramente diferentes para lograr los mismos resultados:
-
Una instantánea de los archivos de datos, además de un método para identificar la hora a la que se creó la instantánea
-
Archive logs desde la hora del punto de control del archivo de datos más reciente hasta la hora exacta de la instantánea
Durante la recuperación, la base de datos lee metadatos de los archivos de datos para identificar el primer archive log necesario. Se puede realizar una recuperación completa o a un momento específico. Al realizar una recuperación puntual, es fundamental conocer la hora de la instantánea de los archivos de datos. El punto de recuperación especificado debe ser posterior a la hora de creación de las instantáneas. NetApp recomienda añadir al menos unos minutos al tiempo de la snapshot para justificar la variación de reloj.
Para obtener más información, consulte la documentación de Oracle sobre el tema «Recuperación mediante la optimización de instantáneas de almacenamiento» disponible en varias versiones de la documentación de Oracle 12c. Además, consulte el ID de documento de Oracle 604683,1 con respecto al soporte de instantáneas de terceros de Oracle.
Distribución de datos
La disposición más sencilla es aislar los archivos de datos en volúmenes dedicados, LUN o espacios de nombres NVMe. Los recursos de almacenamiento no deben estar contaminados por ningún otro tipo de archivo. Esto es para asegurarse de que los archivos de datos se pueden restaurar rápidamente mediante una operación SnapRestore sin destruir un registro de recuperación, controlfile o registro de archivo importante.
SAN tiene requisitos similares para el aislamiento de archivos de datos dentro de recursos dedicados. Con un sistema operativo como Microsoft Windows que usa almacenamiento AFF, un único volumen puede contener varios LUN de archivos de datos, cada uno con un sistema de archivos NTFS. Con otros sistemas operativos, generalmente hay un gestor de volúmenes lógicos. Por ejemplo, con Oracle ASM, la opción más simple sería confinar los LUN de un grupo de discos ASM a un único volumen que se puede respaldar y restaurar como una unidad. Si se requieren volúmenes adicionales por razones de rendimiento o gestión de capacidad, crear un grupo de discos adicional en el nuevo volumen resulta en una gestión más sencilla.
ASA no dispone de la abstracción a nivel de volumen. En su lugar, utiliza grupos de coherencia. En muchos casos, un único LUN o espacio de nombres NVMe puede satisfacer los requisitos de gestión y rendimiento de una base de datos. Si se necesitan varios LUN o espacios de nombres, se pueden añadir recursos adicionales y unirlos como un grupo de coherencia que se convierte en el contenedor de archivos de datos.
Si se siguen estas directrices, las instantáneas se pueden programar directamente en el sistema de almacenamiento.
Precaución: Verifique que el ASM spfile y.. passwd los archivos no están en el grupo de discos que aloja los archivos de datos. Esto interfiere con la capacidad de restaurar selectivamente archivos de datos y solo archivos de datos.
Procedimiento de recuperación local: NFS
Este procedimiento se puede realizar manualmente o a través de una aplicación como SnapCenter. El procedimiento básico es el siguiente:
-
Cierre la base de datos.
-
Recupera los volúmenes de datafile, LUN o namespaces a la snapshot inmediatamente anterior al punto de restauración deseado.
-
Reproduzca los archive logs en el punto deseado.
En este procedimiento se asume que los archive logs deseados siguen presentes en el sistema de archivos activo. Si no lo son, se deben restaurar los registros de archivos rman o. sqlplus se puede dirigir a los datos de la .snapshot directorio.
Además, para bases de datos más pequeñas, un usuario final puede recuperar archivos de datos directamente desde .snapshot Directorio sin ayuda de las herramientas de automatización o de un administrador del almacenamiento para ejecutar un comando de la SnapRestore.
Procedimiento de recuperación local: San
Este procedimiento se puede realizar manualmente o a través de una aplicación como SnapCenter. El procedimiento básico es el siguiente:
-
Cierre la base de datos.
-
Desactive los grupos de discos que alojan los archivos de datos. El procedimiento varía en función del gestor de volúmenes lógico elegido. Con ASM, el proceso requiere desmontar el grupo de discos. Con Linux, los sistemas de archivos deben desmontarse y los volúmenes lógicos y los grupos de volúmenes están desactivados. El objetivo es detener todas las actualizaciones en el grupo de volúmenes objetivo que se va a restaurar.
-
Restaure los grupos de discos de archivos de datos en la instantánea inmediatamente antes del punto de restauración deseado.
-
Vuelva a activar los grupos de discos recién restaurados.
-
Reproduzca los archive logs en el punto deseado.
Este procedimiento asume que los registros de archivo deseados todavía están presentes en el sistema de archivos activo. Si no lo están, los registros de archivo deben ser restaurados tomando los LUN de registro de archivo fuera de línea y realizando una restauración. Este es también un ejemplo en el que separar los registros de archivo en volúmenes dedicados, LUN o espacios de nombres es útil. Si los registros de archivo comparten un grupo de volúmenes con registros de recuperación, los registros de recuperación deben ser copiados en otro lugar antes de la restauración del conjunto general de LUN para evitar perder las transacciones finales registradas.
Ejemplo de recuperación completa
Supongamos que los archivos de datos se han dañado o destruido y se necesita una recuperación completa. El procedimiento para hacerlo es el siguiente:
[oracle@host1 ~]$ sqlplus / as sysdba Connected to an idle instance. SQL> startup mount; ORACLE instance started. Total System Global Area 1610612736 bytes Fixed Size 2924928 bytes Variable Size 1040191104 bytes Database Buffers 553648128 bytes Redo Buffers 13848576 bytes Database mounted. SQL> recover automatic; Media recovery complete. SQL> alter database open; Database altered. SQL>
Ejemplo de recuperación a un momento específico
Todo el procedimiento de recuperación es un único comando: recover automatic.
Si se requiere una recuperación a un momento específico, es necesario conocer la marca de hora de las instantáneas y se puede identificar de la siguiente manera:
Cluster01::> snapshot show -vserver vserver1 -volume NTAP_oradata -fields create-time vserver volume snapshot create-time -------- ------------ --------- ------------------------ vserver1 NTAP_oradata my-backup Thu Mar 09 10:10:06 2017
La hora de creación de la copia Snapshot se muestra como 9th de marzo y 10:10:06. Para estar seguro, se añade un minuto a la hora de la copia Snapshot:
[oracle@host1 ~]$ sqlplus / as sysdba Connected to an idle instance. SQL> startup mount; ORACLE instance started. Total System Global Area 1610612736 bytes Fixed Size 2924928 bytes Variable Size 1040191104 bytes Database Buffers 553648128 bytes Redo Buffers 13848576 bytes Database mounted. SQL> recover database until time '09-MAR-2017 10:44:15' snapshot time '09-MAR-2017 10:11:00';
La recuperación se inicia ahora. Especificó una hora de instantánea de 10:11:00, un minuto después del tiempo registrado para contabilizar la posible variación de reloj y un tiempo de recuperación objetivo de 10:44. A continuación, sqlplus solicita los archive logs necesarios para alcanzar el tiempo de recuperación deseado de 10:44.
ORA-00279: change 551760 generated at 03/09/2017 05:06:07 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_31_930813377.dbf
ORA-00280: change 551760 for thread 1 is in sequence #31
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 552566 generated at 03/09/2017 05:08:09 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_32_930813377.dbf
ORA-00280: change 552566 for thread 1 is in sequence #32
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 553045 generated at 03/09/2017 05:10:12 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_33_930813377.dbf
ORA-00280: change 553045 for thread 1 is in sequence #33
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 753229 generated at 03/09/2017 05:15:58 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_34_930813377.dbf
ORA-00280: change 753229 for thread 1 is in sequence #34
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
Database altered.
SQL>
|
Recuperación completa de una base de datos utilizando instantáneas utilizando el recover automatic el comando no requiere una licencia específica, sino un uso de recuperación puntual snapshot time Necesita la licencia de Oracle Advanced Compression.
|