Soy un DBA de SQL Server y recientemente me han asignado la responsabilidad de un entorno Oracle. (11g)
Ahora hago copias de seguridad programadas de mis registros de transacciones en SQL Server y luego las migro a un servidor diferente. También me gustaría hacer esto con Oracle.
Los registros de rehacer de Oracle parecen basarse en el tamaño antes de cambiar y permiten que el servidor los archive.
¿Alguien puede proporcionar algunos consejos/mejores prácticas sobre cómo lograrlo?
También agradecería cualquier consejo sobre el tamaño de los registros de rehacer y cómo manejar los cambios en los patrones de uso durante el día.
Olvidé decir que esto está en un servidor Redhat 5 Enterprise
Respuesta1
La primera sugerencia es nunca manipularlos manualmente a menos que realmente sepas lo que estás haciendo.
Lo que desea hacer es leer sobre rman, la herramienta de Oracle para realizar copias de seguridad (incluidas las copias de seguridad de registros de rehacer). Recomiendo encarecidamente investigar esto a fondo para asegurarse de comprender completamente cómo funcionan los diversos aspectos de las copias de seguridad de Oracle antes de tomar cualquier medida.
Ahora, en general, los registros de rehacer/archivar de Oracle deben permanecer donde están escritos hasta que haya realizado una copia de seguridad. La copia de seguridad generalmente se configurará para incluir los registros de archivo necesarios junto con la copia de seguridad de la base de datos.
En cuanto al tamaño de los registros de rehacer, se basará directamente en el volumen de transacciones de cambios de la base de datos. Cuantos más cambios, mayor será el volumen de registro. Esto será muy individual para sus aplicaciones y uso, por lo que le recomiendo que comience a registrar estadísticas (volumen de transacciones, tamaño del registro de transacciones, tamaño de la base de datos, etc., todo con marcas de tiempo). Una vez que tenga datos de algunas semanas, puede comenzar a correlacionar la actividad con los registros y resumirla en algunas estimaciones válidas.
Editar: creo que entendí parcialmente mal la pregunta original. Creo que está solicitando una forma de verificar básicamente sus registros de rehacer ahora mismo cuando ejecuta una copia de seguridad, de modo que sea totalmente coherente con su copia de seguridad hasta el momento en que emitió el inicio de la copia de seguridad.
Y rman se encargará de todo ese trabajo sucio por usted. De alguna documentación humana:
Al realizar una copia de seguridad de los registros de rehacer archivados que incluye el registro más reciente (es decir, se ejecuta un comando BACKUP... ARCHIVELOG sin la opción UNTIL o SEQUENCE) si la base de datos está abierta, antes de comenzar la copia de seguridad, RMAN se apagará. del grupo de registros de rehacer en línea actual y todos los registros de rehacer en línea que aún no se han archivado, incluido el grupo de registros de rehacer que estaba vigente cuando se emitió el comando. Esto garantiza que la copia de seguridad contenga todo lo rehacer que se generó antes del inicio del comando.
Otro poquito que proporciona un poco más de detalle:
Puede agregar registros de rehacer archivados a una copia de seguridad de otros archivos utilizando la cláusula BACKUP... PLUS ARCHIVELOG. Agregar BACKUP... PLUS ARCHIVELOG hace que RMAN haga lo siguiente:
- Ejecuta el comando ALTER SYSTEM ARCHIVE LOG CURRENT.
- Ejecuta BACKUP ARCHIVELOG ALL. Tenga en cuenta que si la optimización de la copia de seguridad está habilitada, RMAN omite los registros de los que ya realizó una copia de seguridad en el dispositivo especificado.
- Realiza una copia de seguridad del resto de los archivos especificados en el comando BACKUP.
- Ejecuta el comando ALTER SYSTEM ARCHIVE LOG CURRENT.
- Realiza una copia de seguridad de los registros archivados restantes generados durante la copia de seguridad.
Esto garantiza que las copias de seguridad de los archivos de datos realizadas durante el comando se puedan recuperar a un estado consistente.
La documentación actual debería poder proporcionarle más detalles. Le daría la URL de la que saqué (docs rman de Oracle en línea), pero la URL ya cambió desde que la marqué como favorita, por lo que no confío en que se quede ahí. Sin embargo, buscar en Google documentos rman debería poder encontrarlo.
Editar: Una cosa más que quería agregar. . . Mencionaste algo sobre el tamaño. Oracle 11g admite registros de rehacer comprimidos. Yo no los he usado, pero sé que los admite. Además, Oracle 10g y 11g admiten copias de seguridad comprimidas. Si aún no estás haciendo copias de seguridad comprimidas,usted debería ser. La reducción de tamaño es enorme y, además de eso, también obtuvimos un aumento significativo del rendimiento en las ejecuciones de respaldo cuando habilitamos las copias de seguridad comprimidas.
Respuesta2
Los registros de rehacer de Oracle parecen basarse en el tamaño antes de cambiar y permiten que el servidor los archive.
Mire el parámetro archive_lag_target para Oracle 9i y superior.
Respuesta3
Es una compensación. He oído que los archivos de registro grandes son más eficientes, pero no los usamos porque A) cuanto mayor es la pérdida de un archivo, mayor es la pérdida de sus datos y B) nuestro ancho de banda es una mierda
Esto nos lleva a almacenar archivos en cola durante algunas horas y luego transferir y ejecutar actualizaciones en las distintas máquinas en espera. De hecho, todavía utilizamos Oracle8i y, debido a que la base de datos fue diseñada hace mucho tiempo por alguien que no era un DBA, todavía tengo que crear manualmente nuevos archivos de datos y archivos de control. /suspiro
Respuesta4
Ha pasado un tiempo desde que pregunté esto, pero recientemente encontré la respuesta. Desde aproximadamente Oracle 10G R2 en adelante, ha habido un parámetro que garantizará que un cambio de registro no se realice más allá del tiempo especificado.
Si modifica el sistema, configure archive_lag_target=900;
esto garantizará que el cambio se produzca cada 15 minutos, independientemente de la cantidad de registro utilizado.