CONCEPTOS DE BACKUP Y RECUPERACION – RMAN

Indiscutiblemente una de las principales actividades del DBA es garantizar que no haya perdida de información.

Desde Oracle 9i, la base de datos puede ser configurada para que no se pierda ni un solo registro de una transacción confirmada, pase lo que pase, sin importar lo que pase.

Asi como también se puede configurar un ambiente 100% disponible, a través del uso de data Guard, RAC o Streams.

Identificar Tipos de fallas que pueden ocurrir en una base de datos Oracle.

Fallas del Sistema:

De entrada una falla en el sistema puede ser simplemente la falla en una sentencia SQL, pero en este evento entra el Server Process. (Incosistencia tipos de datos, constraints) Aunque no son problemas del DBA, debemos estar en la capacidad de poder apoyar en la solucion.

Falla de un proceso

Hacen referencia a las fallas de los user process, los cuales se interconectan con los server Processo, loss cuales ya sabemos son administrados por el PMON, si algo pasa, el proceso que esta ejecutándose por el Server process, es decir, el proceso emproblemado, el PMON pone todo al dia, hace rollback, y listo.

Falla en la Red

Para evitar fallos en la red, se debe trabajar en equipo con el administrador de la red, hay tres pintos que se deben tener en cuenta, los listeners, tarjetas de red y los routers. No es común que un listener falle, sin embargo recordemos que el listener es el encargado de levantar los server process y comunicarlos con los user process, y este proceso tiene un tiempo, aunque no muy grande, si considerable. Si nuestra plataforma soporta mucha transaccionalidad, seria buena practica implementar mas de un listener, en diferentes combinación de dirección y puerto.

La otra recomendación es que si un router falla, los usuarios no queden si acceso a la base de datos, para eso le pondríamos dos subnets al servidor, con dos tarjetas. Del lado del cliente se podría manejar tolerancia a fallos a través del parámetro ADDRESS_LIST en el tnsnames.ora

User Errors

Cuando un usuario accidentalmente o mal intencionadamente elimina información de la base de datos, estos casos son mas complejos en su recuperación, y requieren de la participación del DBA.

Existen diferentes formas de y herramientas para intentar hacer la recuperación, flashback.

Falla de Medios

Significa daño en disco, y aunque en teoría es problema del administrador del sistema, debemos estar preparados para solucionar lo que sea. Puede ser también causado por una eliminación de archivos por parte del administrador del sistema, o incluso, por parte del DBA.

Para minimizar el impacto de la falla en un dispositivo de almacenamiento, específicamente un disco, se recomienda que se implemente un respaldo por HW, por Ej. Un RAID.

Falla de la Instancia

Shutdown anormal, faltan transacciones confirmadas, y hay almacenadas transacciones no confirmadas.

Describir formas de tunera la recuperación de una instancia

MTTR: Mean Time To Recover. El proceso de recuperación corresponde a dos tiempo: 1: La cantidad de Redo que se debe leer, y, 2: El tiempo que lleva escribir el Redo a los datafiles.

El SCN es grabado en los datafiles, cuando se confirman cambios, también en los redo log, asi que lo que se deberá reuperar es todo lo que este en los redo después del ultimo SCN que este en los datafiles. Entre mas seguido se haga el checkpoint, menor será el tiempo de recuperación.

Se puede determinar el tiempo que queremos que se tarde la recuperación, en caso de ser necesaria, esto se hacer a través del parámetro FAST_START_MTTR_TARGET, pero se debe tener en cuenta que esto es solo un objetivo, no necesariamente se podrá cumplir con el valor especificado, esto ya que se tendrá en cuenta la cantidad de transacciones que este soportando el motor de base de datos.

Sin embargo, existen MMTR advisors, que nos darán una idea de cuanto tiempo tomara la recuperación de la instancia en caso de fallar. Esta información también puede ser obtenida a través de la vista V$INSTANCE_RECOVERY.

El valor por defecto para el parámetro FAST_START_MTTR_TARGET es cero, con esta valor, se maximiza el rendimiento, Oracle evalua las condiciones del ambiente y aplica el checkpoint de tal forma que tengamos buen rendimiento y el menor tiempo de recuperación.

Existen 3 tipos de Checkpoints,

Incremental: Operación Normal

Full: es cuando todos los dirty buffers son escritos. Solo ocurre cuando el DBA lo pide o cuando hay un shutdown (Normal, Immediate o Transactional).

Partial: TS Off line, Data file Off Line, Dropping Segment, truncating table, TS Backup Mode

Los Redolog files puden ser configuraos con la BD arriba, el control File solo se puede modificar con la abase de datos en nomount o totalmente shutdown.

La vista V$LOG menciona los grupos

La vista V$LOGFILE menciona los miembros del  grupo.

Los Log membres tiene 3 estados, null, stale, invalid

MAXLOGFILES: Numero máximo de grupos

Para configurar la base de datos en modo ARCHIVELOG, la base de datos debe estar en modo MOUNT

Para configurar la base de datos en modo ARCHIVELOG, la base de datos debe estar en modo MOUNT

SQL> CONNECT sys AS SYSDBA

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE NOARCHIVELOG;

SQL> ALTER DATABASE OPEN;

Para configurar la base de datos en modo ARCHIVELOG, la base de datos debe estar en modo MOUNT.