Introducción a los tablespaces, control files y data files.

La base de datos Oracle guarda los datos logicamente en tablespaces y físicamente en datafiles asociados con los tablespaces correspondientes.

Cada tablespace en una base de datos Oracle consiste en uno o mas archivos llamados datafiles, que son estructuras físicas que se ajustan al sistema operativo en el que la base de datos Oracle esta corriendo.

Una base de datos es guardada colectivamente en los datafiles que constituyen cada tablespace de la base de datos. Por ejemplo, la base de datos Oracle más simple tendría un tablespace y un datafile. Otra base de datos puede tener tres tablespaces, cada una consistente en dos datafiles.

Oracle-Managed Files

 Los Oracle-Managed Files eliminan la necesidad para ti, el DBA, de administrar directamente los archivos del sistmema operativo comprimiendo la base de datos Oracle. Tu especificas operaciones en terminos de objetos de bases de datos en vez de nombres de archivos. Oracle internamente utiliza una interface estandar de sistema de archivos para crear y borrar  los archivos conforme lo requieran las siguientes estructuras de bases de datos: 

• Tablespaces
• Redo log files
• Control files

Aunque los parametros de inicialización, que tu especificas el directrorio del systema de archivos para ser usado por un tipo de archivos en particular. Oracle se asegura que un archivo único, un Oracle-managed file, es creado y borrado cuando no se necesita más.

 ¿Qué es un Control File?

Cada base de datos Oracle tiene un control file, que es un pequeño archivo binario que guarda la estructura física de la base de datos. El control file incluye:
El nombre de la base de datos.
Nombres y ubicaciones de los datafiles y redo log files.
El timestamp de la creación de la base de datos.
El número current log sequence.
Información del checkpoint.
El control file de la base de datos debe estar disponible para  que el servidor de  base de datos Oracle pueda escribir cuando la base de datos esta abierta. Sin el control file, la base de datos no puede ser montada y la recuperación es díficil.
El control file de una base de datos Oracle es creado al mismo tiempo que la base de datos. Por default, al menos una copia del control file es creado duranta la creación de la base de datos. En algunos sistemas operativos el default es crear multiples copias. Debes crear dos o mas copias del control file durante la creación de la base de datos. Tu puedes crear control files después, sí tu pierdes los archivos de control o quieres cambiar una configuración en particular de los control files.

Utilizando el cátalogo de recuperación de RMAN

• Contrasta el uso de un cátalogo de recuperación con el uso de un contol file para el repositorio RMAN.
• Crea y configura un cátalogo de recuperación.
• Registra una base de datos en el cátalogo de recuperación.
• Sincroniza el cátalogo de recuperación.
• Usa los scripts guardados de RMAN.
• Respalda el catalogo de recuperación.
• Crea un virtual private catalog.

 Comparación de las opciones.

Control file:

1. Administración más simple
2. Default

Recovery Catalog

1. Replica los datos del control file.
2. Guarda un historial más largo de respaldos.
3. Sirve muchos targets
4. Guarda RMAN scripts

El repositorio de los datos de RMAN siempre se guarda en un archivo de control de la base de datos target. Pero también puede guardarse en una base de datos separada llamada catalogo de recuperación.
Un catalogo de recuperación conserva la información en una base de datos separada, lo cual es útil en caso de la perdida de un control file. Esto te permite guardar un historial lo más largo posible de los respaldos que con un control file. Un recovery catalog único es cápaz de guardar información de multiples bases de datos target. El cátalogo de recuperación puede guardar también RMAN strored scripts, que son secuencias de comandos de RMAN.

Sí tu tienes requerimientos muy simples de administración de respaldos, Oracle te recomienda la opción de un control file  en vez de un recovery catalog. Por lo tanto, usa un cátalogo de recuperación solamente sí obtienes ventaja de los beneficios que ofrece, tal como longer backup retention.  

Recordando los componentes del núcleo de un Servidor de bases de datos Oracle

1. Los dos componentes principales de un sistema básico de bases de datos Oracle son:  La instancia y  la base de datos.
2.  La instancia consiste en estructuras de memoria y procesos de segundo plano.
3. Las tres mayores estructuras en la arquitectura del servidor de bases de datos Oracle son: estructuras de memoria, estructuras de procesos y estructuras de almacenamiento.
4. Una sesión es una conexión entre el usuario y la instancia de base de datos

Recordando las estructuras de memoria de una base de datos Oracle.

1. Los componentes del area global de procesos PGA(Program ó Process Global Area) son: espacio de pila(stack space) y área global del usuario(user global area).  
2. Los principales componentes del área global del sistema SGA(System Global Área) son:

• Shared pool
• Database buffer cache
• Redo log buffer
• Large pool
• Streams pool
• Keep buffer pool
• nK buffer pool.

Nombres de procesos

1. El proceso DBWn  escribe los buffers sucios a los data files.
2. El proceso LGWR escribe las entradas redo a los redo log files en línea.
3. El proceso CKPT escribe la información de un chekpoint  en un archivo de control y a cada data file header.
4. El proceso SMON realiza la recuperación  en el arranque de una instancia.
5. El proceso PMON realiza recuperación de proceso cuando un proceso de un usuario falla.
6. El proceso RECO resuelve transacciones distribuidas in-doubt.
7. El proceso ARCn copia los redo log files al dispositivo de almacenamiento designado.

Primera Evaluación

1. ASM soporta datafiles, log files, control files, archive log, RMAN backup sets, spfiles, y otros tipos de archivos de base de datos Oracle, pero no soporta password files ni init.ora files. 
2. Después de ejecutar el comando alter disk group2 drop disk dg2a;
   Tu ejecutaste el siguiente comando desde la instancia ASM:
   Select group_number, count(*) from v$asm_operation;
   ¿Qué implica el hecho de que la consulta a la vista V$ASM_OPERATION devuelva 0 renglones? La vista V$ASM_OPERATION indica sí  la operación drop disk todavía se esta procesando. Sí no devuelve ninguna fila, entonces la operación drop disk se ha completado. Sí la operación drop disk se completa no se puede correr el comando undrop disks.
3. ¿Cúal es el efecto del siguiente comando?  alter diskgroup dgroup1 drop disk abc; El disk group se rebalanceará automaticamente durante una operación  drop (o add) disk. Una vez que se haya rebalanceado completamente el disco es descartado.
4. DG_DROP_TIME no es un atributo valido de configuración para un disk group.
5. El proceso ARCH comienza cuando la base de  datos esta en modo ARCHIVELOG. Es responsable de monitorear los online redo logs a los otros directorios destino de archive logs.