Oracle Active Data Guard permite que una base de datos en espera reciba información y ofrezca servicios de lectura, garantizando alta disponibilidad y protección de datos. Se introdujo en Oracle Database 11g y permite copias de seguridad incrementales rápidas y la gestión de múltiples bases de datos en espera. Además, la herramienta RMAN de Oracle ofrece funcionalidades para realizar copias de seguridad y recuperación de bases de datos de manera eficiente y flexible.

1. Oracle Active data guard modulo que vende oracle para que una physical standby esté recibiendo información y a
la vez dando servicio de lectura para por ejemplo, generar informes.
Oracle Active Data Guard garantiza alta disponibilidad, protección de datos y recuperación ante pérdidas de datos
importantes
Oracle Active Data Guard proporciona un conjunto integral de servicios que crean, mantienen, administran y
supervisan una o más bases de datos en espera para permitir que las bases de datos de producción de Oracle
sobrevivan a desastres y corrupción de datos.
Es nueva opción en Oracle desde Oracle Database 11g Enterprise Edition
La lógica no es igual que la primaria pero si que tiene los mismos datos
Oracle Active data guard soporta hasta 30 base de datos en standby.Si utiliza scripts o paquetes de informes de solo
lectura, ahora puede dirigirlos al modo de espera físico Active Data Guard.
Otro componente de la opción Active Data Guard es que permite copias de seguridad incrementales rápidas de
RMAN en el modo de espera físico Active Data Guard (es decir, básicamente es compatible con el archivo de
seguimiento de cambio de bloque RMAN en el modo de espera físico). Esta es otra forma potencial de descargar
parte del procesamiento de la base de datos de producción a la base de datos en espera.

2. • v$bgprocess --> Vista con nº máximo de procesos en background de la base de datos
• SQL> select count(1) from v$bgprocess;
COUNT(1) 377 --> Nº max de procesos permitidos
• SQL> select name from v$bgprocess where paddr <> '00';
22 rows selected. --> Nº de procesos funcionando en el momento.
• Proceso background LREG -> registra listener en la base de datos
• Con ASM vamos a crear volúmenes lógicos. Estos siempre comienza por + y así se identifican.
• Desde la 11.2 oracle recomienda que desde una single instance se instale una capa de oracle clusterware. Recomienda y es
gratuito.
• Server control (oracle restart), es un componente externo con el que se puede manejar, parar , arrancar una bdd. desde la
capa de crs se manejan todos los componentes que tenemos por debajo. base de datos, cluster....

3. • Privilegio de administrador para backup -->> as sysbackup
• RMAN se puede conectar hasta a 3 bdd a la vez o 3 entornos o 3 conexiones.
– bd objetivo, de la que voy a hacer el backup
– a la bd catalog. donde se guarda el repositorio de rman
– y a la conexión auxiliar, en caso de querer clonar una bd y esa sería mi origen de bd.
• Las 3 conexiones son: target - catalog - auxiliary
• Desde la 12.2 , dentro de rman se pueden ejecutar comandos SQL o el comando DESC
• DBID es el número de identificador por el que rman conoce a la bdd
• comando standalone --- > comandos aislados dentro de rman,
• un canal es un proceso que trata un archivo. los canales se levantan automáticamente o explícitamente
– V$RMAN_CONFIGURATION -> se encuentran los parámetros de RMAN
– "RMAN> configure" -> se pone los datos de configuración de manera persistente
– RMAN> SHOW ALL; -> consultar los parámetros

4. • Retention Policy la política de retención de backups se define de dos modos:
– por cantidad de backups
– por cantidad de días
• FAST RECOVERY AREA FRA es simplemente un punto de montaje con un espacio.
– Ahí se guardan todos los archivos que son necesarios para la recuperación de mi backup.
– configurar fra es decir donde quiero que me guardes los ficheros de backup.
– yo tengo en un sitio todo lo que necesito para recuperar porque tengo una pagina en OEM para gestionar FRA
– Si se llena FRA, rman automáticamente borra los obsoletos para dejar sitio, sin intervención manual
• DB_RECOVERY_FILE_DEST
• DB_RECOVERY_FILE_DEST_SIZE
• RMAN Recovery Catalog. En la base de datos del catálogo de recuperación se encuentra toda la información del repositorio.
• La bdd seguirá trabajando igual pero cuando acabe una operación de backup, esta se registra en el fichero de control, y se
resincroniza o se escribe estos datos en el catalogo de recuperación.
– se hace el fichero de control más pequeño
– se garantiza que todos los datos van a estar en un catalogo de información
– aquí los datos guardado no caducan y permanecen
– en un catalogo de recuperación puedo tener registradas muchas bdd, es centralizado y único
– Puedo meter más cosas además de info de rman, como scripts de rman
– Se guardan pueden guardar backup y eximirlos de la política de retención para toda la vida
• VIRTUAL PRIVATE CATALOGS seccionar el catalogo para decir a una persona que catalogo lleva Fijarles una cantidad de dbid
para que administren

5. Existen tres formatos:
• IMAGECOPY
– una copia de imagen de un datafile ya que la unidad de trabajo de rman son datafiles
– como esta en disco, tiene que ser en disco
– es muy rápido de restaurar.
– El inconveniente es que se copia el tamaño total del datafile aunque esté vacío
• BACKUPSET
– Ya son metadatos
– Solo guardan los metadatos de control y unos datos binarios que representan la información que contienen.
– Ocupa aprox un 35% del total del datafile
– Tarda más tiempo en restaurar
– dentro de un backupset puede entrar más de un datafile.
– se compone de dos partes,
• REPOSITORIO la primera es una entrada que son los datos del backup (nº de backup, donde estoy, quien soy,
como me llamo, cuantas piezas tiene el backup... info de repositorio)
• PIECE Puede ser uno o varios archivos. Cada una de las piezas, son los ficheros que se copian al directorio de
fra.
• BACKUPSET COMPRESSED
AMBITOS ------- database, datafile, archivelogs, controlfiles.....
TIPOS ---- FULL INCREMENTAL
• Diferencial
– level = 0.
– level = 1.... guardamos lo que ha cambiado desde el ultimo backup
• Acumulativo

6. BSKEY -> condición que hace única cada backup
Todo lo que hay en el backup, todos los ficheros, están en el mismo SCN, están en el mismo instante del tiempo
Dentro de un backupset son todos el mismo tipo de ficheros:
– si es de datafiles, todos los ficheros del backupset son datafiles..
– si es de fichero de control todos son así
– si es de archive log , todos los ficheros copiados son archivelogs
Parámetro filesperset = limitar la cantidad de ficheros que puedo meter en un backupset.
– filesperset = 1 , salen tantos backupset como datafiles haya, más el backupset de controlfile.
variables de sustitución en el campo backup
– format “ %d date %s numero de backupset bskey %p numero de pieza”
RMAN> connect target sys/oracle_4U@orcl
connected to target database: ORCL (DBID=1547645352)
RMAN> connect catalog rcatowner/oracle_4U@rcat --> NOS CONECTAMOS AL CATALOGO DE RECUPERACION
connected to recovery catalog database

8. UPDATE BACKUP -> solo para backup IMAGECOPY
1er dia hacer un backup total de la base de datos , en formato incremental level 0
2º dia creo un incremental level 1
3er dia y siguientes, aplico al backup los bloques cambiados (aplicar incrementales y me creo un backup incremental level 1
RMAN > recover copy of database/datafile <> el recover saca el bloque del incremental y lo copia en el ultimo backup que se
hubiera realizado
Incrementales diarios solo guardamos los bloques cambiados y en el último backup se modifican solo estos bloques
ESTRATEGIA SUGERIDA POR ORACLE PARA BACKUPS (BACKUPS INCREMENTALES)
1. level0 (completo) bloqueA en formato imagecopy guarda bloqueA
2. incremental en dia 2, bloqueA cambia a bloque B, solo guardo un nuevo fichero con lo que ha cambiado
3. aplicar incremental en dia 3 (recover copy) cojo el incremental de ayer y lo aplicoy luego saco un nuevo incremental (backup
incremental...) Sobre el backup del día anterior sustituye los bloques cambiados (recover copy....)
FAST INCREMENTAL BACKUP
Se levanta un background nuevo que va a vigilar todos los bloques que cambian change tracking writer(CTWR), y guarda los id en un
fichero de track que es el que consulta cuando va a hacer un backup. el fichero por defecto lo crea en fra
v$block_change_tracking -> guarda bloques que han cambiado por tablespace

9. HAY 4 niveles de compresión. El basic es el gratuito, el resto hign/medium/low son de pago y solo están para la EE (enterprise
edition)
MML Media Management Library
sbt Standard Backup Tape
archival backups -> backup archivado fuera del periodo de retención que tengo yo definido (policy retention) con el comando
KEEP
KEEP FOREVER se puede utilizar sólo si utilizo catalogo de recuperación
En que esta dividido el fichero de control
1ª parte estructura fija , scn's variables
2ª parte datos para rman
Siempre que cambie la parte estructural de la base de datos, es muy recomendable ejecutar <backup controlfile to trace>.. que
genera un fichero con toda la creación de las sentencias de toda la base de datos.
CATALOG command . se mete en el catalogo de rman una entrada de backup que ya tengo, es para que entienda rman que el
fichero que le das, es una pieza que puede utilizar a la hora de restaurar.
ENCRIPTACION
para encriptar un backup necesito Advanced Security.

10. ADR -> Automatic Diagnostic Repository
[oracle@EDLVC2AR59P1 diag]$ adrci
ADRCI: Release 12.1.0.2.0 - Production on Tue Oct 1 12:43:46 2019
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
ADR base = "/u01/app/oracle"
adrci> show alert
Choose the home from which to view the alert log:
1: diag/tnslsnr/EDLVC2AR59P1/listener
2: diag/rdbms/emrep/emrep
3: diag/rdbms/orcl/orcl
4: diag/rdbms/rcat/rcat
Q: to quit
Please select option:
SQL> select name,value from v$diag_info
NAME VALUE
-------------------- ------------------------------------------------------------
Diag Enabled TRUE
ADR Base /u01/app/oracle
ADR Home /u01/app/oracle/diag/rdbms/orcl/orcl

11. Data Recovery Advisor
DRA especialista en errores de base de datos. Informa rápidamente de que esta pasando en la bd y como arreglarlo.
Parámetros para detectar corruption
db_block_checking previene corruption de memoria y datos
db_block_checksum detecta i/o almacenamiento, corrupción de disco
db_lost_write_protect detecta lecturas no persistentes en la standby física
Son parametros dinámicos, es decir, se pueden cambiar con la base de datos arrancada. Estos parametros no afectan al tablespace
SYSTEM que se va comprobando siempre periódicamente.
Cuando se corrompe un bloque aparece en:
v$database_block_corruption
y aparece en el alert.log
v$backup_corruption
v$copy_corruption
Para recuperar un bloque corrupto de rman, el comando es RECOVER <> BLOCK
RMAN se va al ultimo backup anterior y correcto, y busca donde tiene el bloque corrupto (que en ese momento no estaba corrupto, ya
que se había comprobado la integridad del backup)
de ese backup solo extrae ese bloque y se lo lleva a memoria
luego pasa por todos los archives y busca modificaciones en ese bloque y llega hasta el current redo log
y finalmente, monta todos los archives y commit.
Para hacer un recover necesitamos:
un backup + todos los archive log + los redo logs + el fichero de control sano
Cuando voy a hacer una recuperación incompleta la base de datos se abre con OPEN RESETLOGS (PITR Process Point-in-time
Recovery Process)
RESETLOGS resetea toda la parte de ficheros de control, se resetea las secuencias
Using SET NEWNAME for Switching File
set newname solo para rman para hacer el restore
el switch es para los ficheros de control

12. Leccion 11
Realizar el tipo apropiado de restore y recover en función de la naturaleza de tu "database failure"
Recover de "media failure" en archivos de datos
Realizar recoveries completas o incompletas o "point-in-time"

13. Leccion 12
Recover de la pérdida del archivo de parámetros del servidor (spfile)
SQL> CREATE PFILE [= 'pfile_name' ] FROM { { SPFILE [= 'spfile_name'] } | MEMORY } ;
SQL> CREATE SPFILE [= 'spfile_name' ] FROM { { PFILE [= 'pfile_name' ] } | MEMORY } ;
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RESTORE SPFILE FROM AUTOBACKUP;
RMAN> STARTUP FORCE;
Recover del archivo de control y de fallos en archivos de redo log
Si los archivos de control se almacenan en grupos de discos ASM, Las opciones son las siguientes:
- Realizar recuperación guiada utilizando Cloud Control.
- Ponga la base de datos en modo NOMOUNT y use un comando RMAN para restaurar el controlfile desde un controlfile existente
RMAN> restore controlfile from '+DATA/orcl/controlfile/current.260.695209463';
Si los archivos de control se almacenan como archivos normales del sistema de archivos, entonces:
- Cerrar la base de datos
- Copie el archivo de control existente para reemplazar el archivo de control perdido
Si han desaparecido todos los ficheros de control, se recuperan desde backup
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;
RMAN> ALTER DATABASE MOUNT;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN RESETLOGS;
Recrear el password authentication file
Vuelva a crear el archivo de contraseña con orapwd.
$ orapwd file=$ORACLE_HOME/dbs/orapworcl password=ora entries=5
SQL> select * from v$pwfile_users;
Agregue usuarios al archivo de contraseña y asigne privilegios para cada usuario.
Recuperar índices y tablespaces read-only
Se puede recuperar un tablespace que contiene solo índices sin realizar una tarea de RECOVER.
• Si un data file que pertenece a untablespace de solo índices se pierde, perdido, puede ser más sencillo recrear el tablespace y
recrear los índices.
• Use las opciones para reducir el tiempo que lleva recrear el índice:
PARALELL
NOLOGGING
SQL> CREATE INDEX rname_idx ON hr.regions (region_name) PARALLEL 4;
Restaurar tablespace read-only, poner el tablespace offline, restaurar los datafiles que pertenecen al tablespace, y pasar el tablespace a online.

14. Revisar la recuperación automática del archivo temporal
Recreación automática de archivos temporales al arrancar instancia en el momento de open de la bdd (startup) (desde la 10.2)
La recreación manual también es posible
SQL> ALTER TABLESPACE temp ADD TEMPFILE '/u01/app/oracle/oradata/orcl/temp02.dbf' SIZE 20M;
SQL> ALTER TABLESPACE temp DROP TEMPFILE '/u01/app/oracle/oradata/orcl/temp01.dbf';
Describa el procedimiento básico para restaurar la base de datos a un nuevo host
Perform the steps listed on this page and the next on the restore host to restore the database.
1. Configure the ORACLE_SID environment variable as shown in the following example:
$ setenv ORACLE_SID orcl
2. Start RMAN and connect to the target instance. Do not connect to the recovery catalog as shown in the following example:
$ rman TARGET /
3. Set the database identifier (DBID). You can find the DBID of your source database by querying the DBID column in V$DATABASE.
RMAN> SET DBID 1090770270;
4. Start the instance in NOMOUNT mode:
RMAN> STARTUP NOMOUNT
You will receive an error similar to the following because the server parameter file has not been restored.
RMAN uses a “dummy” parameter file to start the instance.startup failed: ORA-01078: failure in processing system parameters
5. Restore the server parameter file from the backup sets and shut down the instance as shown in the example:
RESTORE SPFILE TO PFILE '?/oradata/test/initorcl.ora' FROM AUTOBACKUP;
6. Shut down the instance:
SHUTDOWN IMMEDIATE;
7. Edit the restored initialization parameter file to change any location-specific parameters, such as those ending in _DEST, to reflect the new directory
structure.
8. Start the instance in NOMOUNT mode using your edited text initialization parameter file.
RMAN> STARTUP NOMOUNT PFILE='?/oradata/test/initorcl.ora';
9. Crear un bloque RUN para restaurar el control file y montar la bd.
RUN
{
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
}
10.Create the RMAN recovery script to restore and recover the database.
11.Execute the RMAN script.
12.Open the database with the RESETLOGS option.

15. Lección 13
RMAN and Oracle Secure Backup
Herramienta de propósito general, Se puede utilizar para hacer backup de bdd oracle, de otras bases de datos no oracle, o bien de
nuestros pc
no tiene nada que ver con la bdd, tiene su propio motor de encriptación, repositorios, su propio servidor administrativo
tiene su definición de almacenamiento donde va a guardar sus backups de osb,
tiene un mml kernelizada con lo que no ha que añadir nada para acceder a la base datos, etc.
OSB10.4 corresponde con la oracle database 12cR1. Los números de las versiones no van sincronizadas.
obtool es una herramienta script de línea de comandos.
Tiene también una interface grafica webtool, que se puede invocar o no, a través de Enterprise Manager