Perspectiva de checkpoints
Un checkpoint es un mecanismo crucial para:
1. Apagar la base de datos de manera consistente
2. Recuperar la instancia
El termino checkpoint tiene los significados seguientes.

• Una estructura que indica la posición del checkpoint, la cual esta en el System Change Number (SCN) en el flujo de redos donde la recuperación de una instancia debe comenzar.

La posición del checkpoint esta determinada por el buffer sucio mas viejo en el cache de la bases de datos. La posicion del checkpoint actua como apuntador al flujo de redo y es guardado en el control file y en cada data file header.
Proposito de los Checkpoints

• La base de datos Oracle utiliza los checkpoints para lograr las siguientes metas: Reducir el tiempo requerido para recuperase en caso de un fallo en la instancia o en los medios.
• Asegurar que los buffers sucios en el buffer cache son escritos en el disco regularmente.
• Asegurar que todos los datos que han recibido commit son estritos en el disco durante un shutdown consistente.

Checkpoint un checkpoint es la escritura por el proceso DBWR de todos los buffers modificados en el buffer cache de la SGA a los data files de la bases de datos. Los headers de la bases de datos son tambien actualizados tomando en cuenta el checkpoin con a System Change Number mas reciente, incluso si el archivo no tiene bloques cambiados, ademas los control files.

Los checkpoints ocurren después (no durante) cada redo log switch y tambien en intervalos especificados por los parametros de inicialización.
Ajusta el parametero LOG_CHECKPOINTS_TO_ALERT=TRUE para observar las veces que inicia  un checkpoint y termina en el alert log de la bases de datos.
Los checkpoints pueden forzarce con el comando ALTER SYSTEM CHECKPOINT;

Respaldando los Control Files
* Respalda el control file a un archivo binario (duplicado del control files existente)
ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/backup/control.bkp';
* Produce comandos SQL que pueden ser usados mas tarde para recrear el control files
ALTER DATABASE BACKUP CONTROFILE TO TRACE;

RMAN Incremental backups
Los respaldos graduales  unicamente guardan los bloques de datafiles que han cambiado recientemente desde un respaldo previo especifico. Tu puedes hacer respaldos que se incrementan  gradualmente de bases de datos, tablespaces individuales o datafiles.

La meta de un respaldo gradual  es respaldar unicamente aquellos bloques de datos que han cambiado desde el respaldo previo.
Las razones principales para hacer como parte de nuestra estrategia respaldos que se incrementan gradualmente son:
 * Para usar una estrategía basada en respaldos actualizados gradualmente, donde estos respaldos graduales son usados periodicamente.
* Para reducir la cantidad de tiempo requerido para respaldos diarios.
* Para ahorrar tiempo cuando se realizan los respaldos usando una red.

Una base de datos es una colección de datos tratados como unidad. El proposito de una base de datos es guardar y recuperar información.

Archiver Proccess

*Copia los archivos redo logs a un dispositivo de almacenamiento después de que a ocurrido un log switch.
Un log swich ocurre cuando el LGWR (escritor de logs) deja de escribir en un grupo redo log y comienza a escribir en otro. Por default, un log switch ocurre automaticamente cuando el grupo de archiovs actuales de redo logs se llena.
O puedes forzar un log switch para hacer el grupo actual de redo inactivo y disponible para operaciones de mantenimieno. Por ejemplo, si queres borrar grupo activo actualmente, pero no puedes hacerlo hasta que el grupo este inactivo. Tambien puedes forzar un log switch si el grupo activo actualmente necesita ser archivado en un tiempo especifico antes de que los miembros de grupo esten completametente llenos. Esta opcion es útil en configuraciones de grandes archivos de de redo que toman un largo que toma un largo perido llenar.
Para forzar un log switch, debes tener el privilegio ALTER SYSTEM. Usa el comando ALTER SYSTEM con la clausula SWITH LOGFILE.
El siguiente comando fuerza un log switch:
ALTER SYSTEM SWITCH LOGFILE;

Interactuando con una Base de datos Oracle

El siguiente ejemplo describe las operaciones de una base de datos Oracle al nivel más básico. También ilustra un configuración de base de datos Oracle en la cúal el usuario y el proceso asociado del servidor estan en computadoras separadas, conectadas a través de una red.

1. Una instancia ha iniciado un nodo donde una base de datos Oracle esta instalada, a menudo llamada el host o servidor de bases de datos.

2. Un usuario inicia una aplicación  generando un proceso de usuario. La aplicación intenta establecer una conexión con el servidor. (La conexión puede ser local,cliente/servidor, o una conexión de tres capas de la capa intermedia.

3. El servidor ejecuta un listener que tiene los operarios de los Oracle Net Services. El listener detecta la petición de conexión de la aplicación y crea un proceso de servidor dedicado a nombre del proceso de usuario. 

4. El usuario ejecuta una operación de tipo DML y compromete la transacción. Por ejemplo, el usuario cambia la dirección de un cliente en una tabla y compromete el cambio.

 5. El proceso del servidor recibe el comando y revisa la shared pool area(un componente de la SGA) para ver sí contiene algún area de SQL compartida que contenga un comando SQL ídentico. Sí una área SQL es encontrada, el proceso del servidor revisa los privilegios del usuario para recuperar los datos, y el area SQL compartida existente es usada para procesar el comando. Sí una area compartida no es encontrada, una nueva area compartida SQL es asignada para el comando de tal forma que pueda ser analizado sintacticamente y procesado.

 6. El proceso del servidor recupera cualquier valor de los datos necesarios, del data file actual(tabla) o de los valores guardados en el buffer cache de la base de datos.

7. El proceso del servidor modifica los datos en la SGA. Porque la transacción esta comprometida, el proceso Log Writer(LGWR) inmediatamente guarda la transacción en el archivo redo log. El proceso Database Writer (DBWn) escribe los bloques modificados permanentes en el disco cuando es eficente hacerlo.

8. Sí la transaccion es exitosa, el proceso del servidor envia un mensaje a través de la red a la aplicación. Sí no es exitosa, un mensaje de error es transmitido.

9. A través de este procedimiento completo, los otros procesos se ejecutan en segundo plano, observando las condiciones que requieren intervenir. Además, el servidor de bases de datos administra las transacciones de  otros usuarios y evita la disputa entre transacciones que solicitan los mismos datos.

¿Qué es un Redo log?
La estructura más crucial para operaciones de recuperación es el redo log, el cual consiste en dos o más archivos preasignados que guardan todos los cambios hechos a la base de datos cuando ocurren. Cada instancia de base de datos tiene un redo log asociado para proteger a la base de datos en caso de una falla en la instancia.

Redo Threads
Cuando se habla en el contexto de multiples instancias de bases de datos, el redo log para cada instancia de base de datos es referido también como redo thread. En configuraciones típicas, solo una instancia de base de datos accede a una base de datos Oracle, asi que solo un thread esta presente. Sin embargo, en un ambiente Oracle Real Application Cluster, dos o mas instancias acceden concurrentemente a una base de datos única  y cada instancia tiene su propio thread de redo. Un redo thread separado para cada instancia evita la disputa por un conjunto único de redo log files, de este modo se eliminan cuellos de botella potenciales.