Taller Oracle Seguridad Backup Recovery 22092008
Taller Oracle Seguridad Backup Recovery 22092008
Taller Oracle Seguridad Backup Recovery 22092008
Email: francisco@friccio.com
Pgina 1
Creando un usuario con autentificacin de base de datos: create user nombre identified by password;
Creando un usuario con autentificacin por sistema operativo: Previamente validar el parmetro: os_authent_prefix create user ops$nombre identified externally; Donde nombre es un usuario de sistema operativo.
Desbloqueando / Bloqueando un usuario: alter user usuario account unlock; alter user usuario account lock;
Configurando quotas sobre tablespaces: alter user xx identified by xx quota 100M | unlimited on USERS Ing. Francisco Riccio. Pgina 2
Tipos de privilegios: Objetos: Permisos sobre objetos: tablas, ndices, stored procedures, etc. Podemos permitir garantizar un privilegio de objeto a un usuario y este pueda tambin dar este privilegio (WITH GRANT OPTION), no est disponible cuando el que va hacer garantizado es un rol. Observacin: Cuando revocamos un privilegio a un usuario y este a la vez entreg privilegios a un tercero, el tercero perder el privilegio de acceder al objeto del primero. Privilegio de Objetos: select, insert, update, delete, alter table, debug, execute, etc. Sistema: Permisos sobre operaciones de base de datos tales como: crear usuarios, alterar la base de datos, etc. Podemos permitir garantizar un privilegio de sistema a un usuario y este pueda tambin dar este privilegio (WITH ADMIN OPTION), Observacin: Si un usuario otorga privilegios de sistema a otro usuario con la opcin with admin option y a la vez este segundo usuario le da privilegios a un tercero. Luego cuando se haga un revoke al segundo, el tercero sigue manteniendo el privilegio otorgado. Privilegio de Sistema: alter database, alter system, audit system, create any (table index job procedure sequence trigger - view), debug any procedure, execute any program, create procedure, create profile, create role, create session, lock any table, flashback any table, analyze any, sysdba, sysoper, etc. Roles: Permite agrupar privilegios de objetos y sistemas. Para habilitar un rol: set role nombre_rol identified by password. El password se setea de la siguiente manera: create rol nombre_rol identified by password. Con: alter user nombre default role lista_roles (carga automticamente los roles del usuario) Recordemos que las vistas ms utilizadas son: dba_role_privs (Privilegio de roles), dba_tab_privs (Privilegio de objetos de tablas) y dba_sys_privs (Privilegio de Sistemas). Adicionalmente tenemos: session_privs = Muestra los privilegios de sistema y objetos asignado s a la sesin. sessions_roles = Muestra los roles asignados a la sesin.
Pgina 3
Nota: Podemos crear roles con password: create role rol1 identified by mipassword; Para habilitar un rol con password en una sesin: set role rol1 identified by mipassword, rol2; set role all except rol1 set role none => Deshabilita todos.
Alterando los roles activados de un usuario determinado: Cuando creamos un rol, el usuario creador adquiere el rol automticamente como activo, pero podemos cambia su comportamiento de la siguiente manera: alter user xxx default role rol1, rol2; (si el rol tiene password en esta alteracin no es necesario ponerlo)
Pgina 4
Opciones: CONNECT_TIME = Indica el tiempo de conexin que puede estar una sesin, en caso supere el tiempo en minutos aplica rollback a sus transacciones. create profile nombre LIMIT CONNECT_TIME #min | UNLIMITED; CPU_PER_CALL = Limita la cantidad de CPU que puede ser consumida por cualquier llamada de base de datos con ese profile. El valor a ingresar es en ciento de segundos en un ciclo. create profile nombre LIMIT CPU_PER_CALL # | UNLIMITED; CPU_PER_SESSION = Limita la cantidad de CPU time que puede ser consumida en cualquier sesin. El tiempo est en ciento de segundos. IDLE_TIME = Limita la duracin de tiempo muerto de una sesin. El tiempo est en minutos. create profile nombre LIMIT IDLE_TIME #min | UNLIMITED; LOGICAL_READS_PER_CALL = Por cada llamada hacia la base de datos restringe el nmero de logical reads que puede consumir la llamada. create profile nombre LIMIT LOGICAL_READS_PER_CALL #; LOGICAL_READS_PER_SESSION el cual indica el mximo nmero de logical reads durante toda la sesin. PRIVATE_SGA = Limita la cantidad de UGA en bytes que una conexin con shared server puede ubicar. create profile nombre LIMIT PRIVATE_SGA #; SESSIONS_PER_USER = Restringue a un usuario al nmero de sesiones que puede abrir. create profile nombre LIMIT SESSIONS_PER_USER #; Ing. Francisco Riccio. Pgina 5
El password_life_time especifica el mximo nmero de das que un password se puede mantener vigente. El password_grace_time es el nmero de das despus del primer login exitoso comenzar a recordarle del vencimiento del password. Limita el password a m dias y durante n dias recordar esto.
Reuso de Passwords Especifica el nmero de das que un password puede ser reusado y despus de cuantos passwords cambiados. CREATE PROFILE nombre LIMIT PASSWORD_REUSE_TIME PASSWORD_REUSE_MAX #dias | UNLIMITED n | UNLIMITED
Requiere que al menos n passwords cambien y durante #dias para poder reusar un password.
Pgina 6
Nota: Existe un archivo en llamado $ORACLE_HOME/rdbms/admin/utlpwdmg.sql el cual contiene una funcin PL/SQL con complejidad alta para poderla asociar a un profile. Ejemplo: ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION verify_function;
Pgina 7
Auditoria
Para activar la auditoria: ALTER SYSTEM SET AUDIT_TRAIL= DB; DB,EXTENDED, OS, XML, XML, EXTENDED SCOPE=SPFILE; DB,EXTENDED: Registra en la base de datos junto con las sentencias SQL que son auditadas. OS: Se registra en $ORACLE_BASE/admin event viewer en Windows Ejemplo: alter System set audit_trail=db scope=spfile;
Oracle permite 4 niveles de auditora. Statement Privilegio Objeto Fine grained Access
Statement
Permite auditar 1 tipo de SQL. Ejemplo: audit table; (todo lo relacionado a la palabra table, create, drop, truncate, etc) audit table by xxx audit table by xxx whenever not successful
audit alter table | procedure | database | profile | system; grant (todas sus formas, ejemplo: grant sequence); execute (todas sus formas, ejemplo: execute procedure); procedure (create y drop para procedure, function, package); lock table; role (create, drop, set role, alter); select (select table); system grant (grant, revoke); tablespace (alter, create, drop); trigger (alter, create, drop); user (alter user, create, drop); view (alter, create, drop); session (connect).
Pgina 8
Privilegio
Audita un privilegio de sistema, ejemplo: audit create any table audit delete any table
Tips: Para auditar un GRANT ANY PRIVILEGE debemos primero ejecutar el siguiente audit en el usuario que va a lanzar los audit grant any privilege: AUDIT SYSTEM GRANT BY usuario_auditor
Objeto
Audita un select, insert, update o execute de un objeto particular.
audit select on hr.employees; audit select on hr.employees by access whenever successfull; Puede definrsele tambin a nivel de: S = Session (Ejemplo: Si hacemos 10 inserts, los 10 inserts generaran 1 entrada de auditora) A = Access (Ejemplo: Si hacemos 10 inserts, cada insert generar 1 entrada de auditora)
Nota: Oracle 11g audita cualquier operacin DML sobre la sys.aud$ No puede ser restringido por usuario. Si definimos por BY SESSION entonces en la tabla DBA_AUDIT_TRAIL (campo SES_ACTIONS) tendr un conjunto de bits ordenados que representarn la lista de actividades que se hicieron sobre el objeto. Cada posicin del arreglo de bits est definida en la siguiente tabla:
Pgina 9
Donde cada celda tiene 3 valores: S (Success), F (Failure), B (Both). Tengamos presente que una auditoria por sesin solo guardar la primera sentencia ejecutada y las dems sentencias relacionadas al mismo objeto ya no son guardas en esa sesin. Para saber el historial de actividades debemos revisar la columna SES_ACTIONS.
Pgina 10
Vistas importantes: DBA_AUDIT_TRAIL = Muestra el reporte de las auditorias. (Pero podemos filtrar con las vistas: DBA_AUDIT_STATEMENT, DBA_AUDIT_OBJECT) DBA_COMMON_AUDIT_TRAIL = Muestra el reporte de las auditorias y FGA. DBA_STMT_AUDIT_OPTS = Muestra auditorias activadas de tipo STATEMENT. DBA_PRIV_AUDIT_OPTS = Muestra auditorias activadas de tipo PRIVILEGIO DE SISTEMA. DBA_OBJ_AUDIT_OPTS = Muestra auditorias activadas de tipo OBJETO.
Nota: Si queremos auditar al SYS debemos colocar en true el parmetro audit_sys_operations; Las actividades de subir y bajar la base de datos y al loguarse como sysdba o sysoper son siempre escritas en disco. Toda la auditora se guarda internamente en la tabla SYS.AUD$ la cual debemos ir depurndola en el tiempo y con su previo backup (export).
Pgina 11
Nos apoyamos del package: DBMS_FGA DBMS_FGA.ADD_POLICY('esquema','objeto_monitorear','un_alias','condicion_logica*','columnas_vis ualizar*); Parmetros: condicion_logica = Si devuelve true o null crea un registro en la tabla de auditora. columnas_visualizar = Las columnas que se proyecten en el seelct no deben aparecer en la condicion_logica. Aqu deben ir las columnas que se proyecten en un select, si es as y condicion_logica es true entonces se crea un registro de auditora. Si colocamos NULL en este parmetro indica que cualquier campo se proceder a auditar. Va de la mano con el resultado de la condicion_logica. Todos los Parmetros: object_schema object_name policy_name audit_condition audit_column = Lo definimos cuando nos interesa que solo se gener una entrada de auditora cuando las columnas sean accedidas. handler_schema handler_module (UTL_MAIL.SEND_ATTACH_RAW) enable = true/false statement_types = select, insert, update, delete audit_column_ops = DBMS_FGA.ALL_COLUMNS | DBMS_FGA.ANY_COLUMNS (Indica si todos los campos referenciados en audit_column deben figurar o solo algunos)
Pgina 12
Ejemplos: Ejemplo 1: DBMS_FGA.ADD_POLICY (object_schema=>'SCOTT',object_name=>'EMP',policy_name=>'EMP_ACCESS'); Al no tener condiciones Oracle auditar toda operacin DML y SELECT. Ejemplo 2: DBMS_FGA.ADD_POLICY (object_schema=>'SCOTT',object_name=>'EMP',policy_name=>'EMP_ACCESS',audit_column=>'SAL, COMM'); Indicamos que se generar cualquier entrada de auditora si hay cambios y lecturas sobre el campo SAL COMM. Ejemplo 3: DBMS_FGA.ADD_POLICY (object_schema=>'SCOTT',object_name=>'EMP',policy_name=>'EMP_ACCESS',audit_column=>'SAL, COMM', statement_types=>'INSERT, UPDATE', audit_column_opts=>DBMS_FGA.ANY_COLUMNS); Solamente sentencias INSERT y UPDATE que incluyan cualquiera (DBMS_FGA.ANY_COLUMNS default) de los campos listados en audit_column. Ejemplo 4: DBMS_FGA.ADD_POLICY (object_schema=>'SCOTT',object_name=>'EMP',policy_name=>'EMP_ACCESS',audit_column=>'SAL', audit_condition=>'SAL>9999',statement_types=>'SELECT',audit_column_opts=>DBMS_FGA.ANY_CO LUMNS,audit_trail=>DBMS_FGA.DB + DBMS_FGA.EXTENDED); Si cumple la condicin del audit_condition se generar una entrada de auditoria. Ejemplo 5: DBMS_FGA.ADD_POLICY (object_schema=>'SCOTT',object_name=>'EMP', policy_name=>'xxx',audit_column=>'CAMPO1,CAMPO2',enable=>FALSE,statement_types=>'SELECT') Ejemplo 6: DBMS_FGA.ENABLE_POLICY(object_schema=>'HR',object_name=>'EMPLOYEES',policy_name=>'xxx') Ejemplo 7: DISABLE_POLICY(object_schema=>'HR',object_name=>'EMPLOYEES',policy_name=>'xxx'); Ejemplo 8: Ing. Francisco Riccio. Pgina 13
DROP_POLICY(object_schema=>'HR',object_name=>'EMPLOYEES',policy_name=>'xxx');
Vistas importantes: DBA_AUDIT_POLICIES = Reporte de las reglas FGA DBA_FGA_AUDIT_TRAIL = Reporte del resultado de la auditoria FGA.
Pgina 14
No garantizar el privilegio de SYSDBA ni entregar el rol DBA ni ningn privilegio de sistema con ANY. Tener el parmetro de base de datos: REMOTE_OS_AUTHENT = FALSE Los archivos del $ORACLE_HOME y $ORACLE_BASE deben tener privilegios 750 a nivel de S.O. Auditar toda accin en la SYS.AUD$: AUDIT ALL ON SYS.AUD$ BY ACCESS. Auditar cualquier DROP ANY y GRANT ANY.
4. 5.
6. 7.
Pgina 15
Backup
Overview Arquitectura Oracle
Una base de datos Oracle se compone de sus Users Process, su Instancia y su base de datos.
El user process, es usado para almacenar la conexin del usuario. Las variables e informacin de cada usuario se almacenan en el PGA. La instancia es el SGA + background process El SGA se compone del: o o o o Data Buffer Cache, almacena los bloques ledos de disco en memoria. Shared Pool, almacena los planes de ejecucin y cdigo compilado. Large Pool, es utilizado como buffer para los backups y para ejecucin de queries con paralelismo. Redo Log Buffer, almacena las transacciones antes de cada commit.
Pgina 16
o o
o o
Libera todos los recursos que una sesin us despus que se cierra dicha sesin. Responsable de indicarle al Listener cuando una sesin se ha llegado a conectar con un dispatcher en una conexin compartida para que el Listener aumente en 1 su contador. Responsable de registrar dinmicamente las instancias en los listener con configuracin por default.
o o o o o o o
o o
SMON: o Maneja espacios para operaciones de ordenamiento. o Es el responsable de un instance recovery (en caso de una cada). MMON: o Recolecta estadsticas y los almacena en el buffer de AWR. o Limpia los traces e inputs de incidentes con origen de ms de 30 das (Oracle 11g). MMNL (Memory Monitor Light): Baja del buffer del AWR a disco cada segundo. Job Queue Monitor (CJQ): Asigna jobs a la cola de jobs. (Job Coordinator) Job Queue (J): Ejecuta jobs de la base de datos que han sido schedule. (Job Slave) MMAN (Memory Manager): Es activado en el Database Control y esto permite que el ADDM ajuste cada componente del SGA segn las estadsticas. Recovery Writer (RVWR): Escribe recovery informacin cuando se habilita el flash recovery. Change Tracking Writer (CTWR): Mantiene tracks de los bloques cambiados desde un backup incremental por el RMAN. DBWriter baja a disco en las siguientes circunstancias: o No hay espacio libre en el buffer cache para nueva data. o Demasiados commits que no han bajado a disco. o Usando shutdown o usando checkpoint. o El tablespace es puesto en modo backup, offline o readonly. o Un segmento es borrado. LOGWriter baja a disco en las siguientes circunstancias: o Cada 3 segundos. o Cuando se hace un commit. o Cuando el redo buffer tiene 1 MB de redo informacin. o Checkpoint. Checkpoint (CKPT) o Actualiza las cabeceras del control file y de los datafiles igualando el mismo SCN. DMnn_IDProceso: Es el master control process en un trabajo de Oracle Data Pump. DWnn_IDProceso: Es el worker process en un trabajo de Oracle Data Pump.
Base de Datos o Redo Logs, contienen las transacciones de la base de datos. o Datafiles, contienen la informacin de nuestra base de datos. La base de datos debe tener al menos un datafile y cada datafile pertenece a un tablespace. o Log files, contienen las transacciones commiteadas utilizadas para recovery. o Control file: Mantiene la metadata de la base de datos, como donde se ubican sus datafiles, el nombre de la base de datos y algunas configuraciones de retencin de los backups. o SPFILE y PFILE: Mantiene la configuracin de la instancia, donde se define el nombre de la instancia, la memoria RAM de cada componente del SGA etc. Pgina 17
Password file: Permite indica cuantas cuentas pueden tener el privilegio SYSDBA.
Pgina 18
Es importante resaltar lo siguiente: Oracle solo requiere 1 miembro por redo log group para seguir operando. Solo existe un redo log group activo, el cual recibe los redo entries del redo log buffer. Los redo log groups tienen 4 estados: ACTIVO (Se requiere para instance recovery ya que an no ha ocurrido un checkpoint), CURRENT (Redo log group que recibe los redo entries del redo log buffer), UNUSED (Redo log recin creado y no ha sido utilizado) e INACTIVO (No es requerido en caso de un instance recovery). Al llenarse un redo log group se genera el evento de switch log file el cual genera 2 eventos importantes: CHECKPOINT y ARCHIVE (Si est habilitado), ambos ocurren asncronamente.
Operaciones sobre los redo logs groups Creando y eliminando redo logs groups.
Pgina 19
Nota: Es una buena recomendacin tener ms de 1 miembro por grupo y estn en carpetas diferentes o en filesystems diferentes si es posible. Se puede trabajar al menos con 2 redo log groups pero Oracle recomienda al menos 3 y si la base de datos es muy transaccional es recomendable generar varios redo log groups porque provoca lentitud en el sistema al no poderse utilizar un redo log group libre para escribir ya que todos podran estar haciendo la operacin de archive todava.
Control Files. Para visualizar la ubicacin de nuestros control files. (show parameter control_files)
Se puede apreciar en este ejemplo que tenemos 3 control files llamados control01.ctl, control02.ctl y control03.ctl. Para agregar ms de un control file se debe realizar las siguientes labores: Modificar el parmetro control_file para indicarle que tendr otro control file ms (scope=spfile). Bajar la instancia de base de datos. Copiar un control file a otro destino. Levantar la base de datos.
Ejemplo:
Pgina 20
La misma idea sera para retirar un control file de la base de datos. Oracle recomienda tener al menos 3 control files dispersos en diferentes carpetas o si es posible en diferentes filesystems.
Pgina 21
ONLINE Est mtodo nos permite sacar backups en caliente a la base de datos es decir sin generar indisponibilidad de servicios. Requisito principal: La base de datos debe estar en modo ARCHIVE. Validando si la base de datos est en modo archive:
Pgina 22
Nota: Cuando un Tablespace se coloca en modo begin backup, Oracle internamente hace que los datafiles comprendidos en el Tablespace no sean escritos por el proceso DBWRITER y todos los cambios ocurridos son escritos en los redo logs (tendr la copia de cada bloque cambiado), por lo tanto genera gran cantidad de redo logs, porque se est escribiendo ms informacin de lo normal. Oracle recomienda ejecutar este tipo de backups en horarios ms libres. Cuando un Tablespace est en modo backup sus datafiles estn en estado backup y se puede apreciar en el siguiente query (v$backup):
Pgina 23
Tener en consideracin lo siguiente: Si se setea el Flash Recovery Area y no esta seteando ningn parmetro LOG_ARCHIVE_DEST_n el LOG_ARCHIVE_DEST_10 equivale a DB_RECOVERY_FILE_DEST. Si queremos hacerlo de modo explcito sera: alter system set log_archive_dest_n='LOCATION=USE_DB_RECOVERY_FILE_DEST'; Y si est seteado al menos un LOG_ARCHIVE_DEST_n en otras rutas y no se setea algn LOG_ARCHIVE_DEST_n en el Flash Recovery Area, los archivers nunca irn al Flash Recovery Area. Tener nuestros archivers y backups en el flash recovery area nos da la ventaja que Oracle gener una autolimpieza y nos alerta. Cuando est al 87% de consumo el flash recovery area Pgina 24
recibimos alertas en el alert.log y en la vista DBA_OUTSTANDING_ALERTS (Devuelve alertamientos de mtricas que estn alcanzando un umbral determinado). Para monitorear el espacio consumido lo podemos hacer consultando la vista V$FLASH_RECOVERY_FLASH_USAGE.
Pgina 25
Configurando RMAN
Ingresamos a RMAN y se verifica su configuracin.
Configurando retencin de Backups En RMAN podemos configurar 3 tipos de backups: Por nmero de copias, por tiempo y no configurado por RMAN. Por nmero de copias: Indicamos a Oracle que debe existir n copias de un backup para considerarlo obsoleto el ms antiguo. CONFIGURE RETENTION POLICY TO REDUNDANCY 1; Por das de retencin: Indicamos a Oracle el nmero de das que debe tener un backup para ser considerado vigente todava. CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF # DAYS; Si un backup no cumple el perodo de das de ser considerado vigente pero es necesario para tener un backup completo de la base de datos; Oracle no lo marcar como obsoleto. Asimismo siempre Oracle mantendr un backup completo de la base de datos. El nmero de das de retencin no puede ser mayor al especificado en el parmetro CONTROL_FILE_RECORD_KEEP_TIME si no estamos utilizando Catalogo.
Pgina 26
Sin retencin: Indica que el backup nunca ser obsoleto, pero le da el derecho a la herramienta de terceros que realiza el backup a hacerlo.
Compression Solo disponible desde la versin Oracle Database 11g, el cual Oracle nos permite tener 2 tipos de compresiones: ZLIB y BZIP2. Por default est habilitada la BZIP2 y consume mayor procesamiento de CPU pero comprime ms, mientras ZLIB comprime consumiendo menos recursos pero comprime con menor ratio. Ejemplo: CONFIGURE COMPRESSION ALGORITHM 'ZLIB';
Encriptacin Nota: 316886.1 Est disponible desde la versin 10gR2 y solo se puede realizar encriptacin a backupset si es a disco y si es por tape solo utilizando Oracle Secure Backup. Modos de encriptacin: Transpararent: Requiere un Oracle Key Management Infrastructure disponible como Oracle Wallet y no requiere intervencin del DBA cuando est configurado. Password: Requiere un Password el backup para setearlo. Dual: Soporta Transparent y Password. Pasos: Validamos los algoritmos disponibles: select ALGORITHM_NAME from V$RMAN_ENCRYPTION_ALGORITHMS; Saetendolo en el RMAN: CONFIGURE ENCRYPTION ALGORITHM 'AES128'; Ejecutando un backup con Password: set encryption on identified by password only; Ejemplo:
Pgina 27
Para Restaurar: set decryption identified by password; restore database; Nota: Si habilitamos la opcin: CONFIGURE ENCRYPTION FOR DATABASE ON Debemos configurar un wallet de modo que todo backup siempre saldr encriptado.
BACKUP OPTIMIZATION RMAN tiene la facilidad de no backupear files que no cambian como los datafiles read only si ya fue backupeado anteriormente, logrando disminuir el tiempo del backup. CONFIGURE BACKUP OPTIMIZATION ON; Aplica a: datafiles, archive logs y backup sets. Si queremos forzar que de todos modos haga un backup a los datafiles read only a pesar que est con la opcin de optimizacin habilitada: BACKUP DATABASE FORCE;
Pgina 28
CONTROLFILE AUTOBACKUP Podemos indicar a RMAN que siempre que ejecute un backup incluya al CONTROLFILE y al SPFILE ( Si est usando SPFILE en la base de datos) en cada backup que se realice. Por default un backup database incluye el control file. CONFIGURE CONTROLFILE AUTOBACKUP ON;
SNAPSHOT CONTROLFILE Oracle cuando ejecuta un backup y necesita re sincronizar con una consistente versin del control file se apoya de una copia del control file que la realiza cuando inicia el backup. Tambin lo realiza cuando desea realizar un backup del control file. CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u02/oradata/ORCL/SNAPORA.CTL'; Si 2 backups desean realizar la misma operacin fallar (Despus de 5 intentos al querer tener la exclusividad del archivo) entregando el siguiente error: RMAN-08512: Waiting For Snapshot ControlFile Enqueue
Especificando el canal (DISK o TAPE) Especificando el canal por default. TAPE = SBT CONFIGURE DEFAULT DEVICE TYPE TO DISK; Especificando algunos canals: CONFIGURE DEVICE TYPE DISK PARALLELISM 1; CONFIGURE DEVICE TYPE SBT PARALLELISM 2;
Configurando el tamao de un backup pieces - MAXPIECESIZE El backup pieces es un archive, donde un conjunto de backup pieces forman el backup de un datafile. CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE = 1G; Nota:
Pgina 29
Existe un bug en las versiones 10.1.0.2 hasta la 10.2.0.3 entregando el siguiente error cuando se realiza un backup image cuando esta seteado el MAXPIECESIZE. During an RMAN backup, a tracefile is generated with this error: ORA-00600: internal error code, arguments: [ksfdfetch1], [], [], [], [], [], [], [] Se soluciona en la versin 10.2.0.4 o retirando el MAXPIECESIZE colocando el parche 4541506. Configurando el tamao de un backupset - MAXSETSIZE Un backupset es igual a la suma de cada backup pieces que son parte del backupset. CONFIGURE MAXSETSIZE TO 1G; RMAN> BACKUP DATABASE MAXSETSIZE=1G; Nota: No podemos especificar la cantidad de backuppieces en un backupset. Si un archivo ocupa ms que el backupset, el backup fallar. Podemos especificiar el nmero de archivos por backupset con la propiedad filesperset=#. Ejemplo:
ARCHIVELOG DELETION POLICY Indicamos la poltica de eliminacin de los archive logs. Puede tener 3 valores:
Pgina 30
APPLIED ON STANDBY, Habilita al Flash Recovery Area eliminar al archive log cuando el archive ya fue aplicado en el Standby. NONE (default), Habilita al Flash Recovery Area a eliminar los archive logs que son backupeados y que son obsoletos segn en la retencin del backup.
Si realizamos un backup eliminando los archive log (delete input) y esta seteado alguna alguna poltica de eliminacin de archivelog har que el comando no elimine el archivelog a menos que coloquemos forc.
Pgina 31
Nota: Recordemos que el backup image es un backup como si fuera una copia de sistema operativo y no puede ser enviado directamente a tape.
Pgina 32
Backupset: Backup Base de Datos: BACKUP AS BACKUPSET DATABASE; Backup Tablespace: BACKUP AS BACKUPSET TABLESPACE xxx; Backup Datafile: BACKUP AS BACKUPSET DATAFILE #; Backup ControlFile: BACKUP CURRENT CONTROLFILE; Backup SPFILE: BACKUP AS BACKUPSET SPFILE;
Pgina 33
Nota: El backupset es un backup con formato solo legible por RMAN y puede ser enviado a disco o a tape. El backupset lo podemos comprimir con la opcin BACKUPSET COMPRESSED (Desde Oracle 10g). Backup del Control File con diferentes Mtodos. a) Backup en forma de script: alter database backup controlfile to trace; Se almacena en el UDUMP como un trace de usuario (USER_DUMP_DEST) b) Backup en forma binaria: alter database backup controlfile to destino; c) Utilizando RMAN: backup current controlfile; Ejemplo:
Pgina 34
Nivel 0 = Full Backup RMAN> BACKUP INCREMENTAL LEVEL 0 AS COMPRESSED BACKUPSET DATABASE; Nivel 1 = Incremental RMAN> BACKUP INCREMENTAL LEVEL 1 AS COMPRESSED BACKUPSET DATABASE; (Copia los ltimos data blocks cambiados desde el ltimo backup L0 o L1 ms prximo). Nivel 1 Acumulativo RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE AS COMPRESSED BACKUPSET DATABASE; (Copia los bloques modificados desde ese momento hacia el backup L0 o Ln-1) Ejemplo:
Pgina 35
Pgina 36
Nota: El Block Change Tracking File solo guarda hasta 7 backups incrementales., despus del 7mo backup incremental se sobrescribo el file. Si sacamos un backup incremental L1 y no contamos con el backup L0 el backup no fallar, sino el L1 se convertir en L0.
Pgina 37
Eliminando Backups delete all obsolete = Elimina aquellos backups que son ms viejos lo que la retencin permite. delete all expired = Elimina del catalogo aquellos archivos y backups que ya no estn disponibles, detectados por el crosscheck. (DELETE EXPIRED ARCHIVELOG ALL / DELETE EXPIRED BACKUP) delete copy = Elimina todos los backups de tipo image. delete backupset = Elimina todos los backups de tipo backset.
Reportes de RMAN
Para listar todos los backups ejecutados. Lista de Backups Copy: RMAN> list copy summary; Lista de Backups Set: Ms reportes: RMAN> list backupset|backup summary; RMAN> list backupset|backup|copy of tablespace <tablespace>; RMAN> list backupset|backup |copy by file; RMAN> report schema; (Devuelve la estructura de la base de datos). Reporte de Backups obsoletos: RMAN> report obsolete; Lista de Backups Copy: RMAN> list copy;
Pgina 38
Schedule de Backups
1. Lo primero que debemos hacer antes de realizar un schedule de un backup es contar con un script de tipo RMAN que contenga la accin a realizar. Ejemplo de un script: run{ allocate channel c1 type disk format '/u03/backup_full.bk'; backup as compressed backupset database; } Lo guardamos en un archivo llamado BACKUP_FULL.rman 2. Luego: Creamos un archivo de extensin sh (Unix) cmd (Windows), con el siguiente contenido: rman target / cmdfile=BACKUP_FULL.rman log=BACKUP_FULL.log 3. Finalmente lo programamos en el schedule de tareas de Windows o en el cron en sistemas Unix. crontab e Ingresar los siguiente: 0 0 * * * sh BACKUP_FULL.sh
Nota: En caso de los ambientes Unix debemos hacer que el sh tambin cargue las variables de ambiente ORACLE_BASE, ORACLE_HOME, ORACLE_SID y PATH.
Pgina 39
Nos permite: Almacenar scripts y llamarlo desde las BD. Ser un punto focal de todos los backups. Es el nico modo de tener backups keep forever o por periodo ms grande que un ao.
Pasos: Crear un usuario y un tablespace especial para el Catalogo en una base de datos nueva. create tablespace tbs_rman datafile '/u02/ORCL/tbs_rman.dbf' size 200M; create user rman identified by oracle default tablespace tbs_rman quota unlimited on tbs_rman; Garantizamos el rol RECOVERY_CATALOG en la base de datos que servir como Catalogo: grant recovery_catalog_owner to rman; Nos conectamos al RMAN en la base de datos que servir como Catalogo: rman catalog=rman/oracle; rman> create catalog; Nos conectamos al Catalogo desde nuestras OTRAS Bases de Datos. rman / catalog=user/pass@conexion Registramos la Base de Datos en el Catalogo: rman> register database;
Para retirar una base de datos del Catlogo: rman> unregister database; Algunos trabajos extras:
Pgina 40
a) Manipulacin de scripts centralizados: create global script nombre { .... } Otras opciones: replace global script nombre { ... } delete global script nombre print global script nombre; list script names; Para ejecutarlo: run {execute script nombre;} b) Registrar un backup que no ha sido registrado en el Catalogo y se desea registrar en el Catalogo. rman> catalog datafilecopy '/.....dbf'; rman> catalog backupiece '/....bkp'; rman> catalog archivelog '...arc','...arc','...arc'; c) Sincronizando el control file con el Catlogo de modo manual: Durante una operacin de RMAN, el catalogo ser sincronizado con el control file. Nuevos registros sern actualizados o agregados durante este proceso de sincronizacin. Podemos sincronizarlo manualmente: rman> resync catalog; Puede ayudarnos en solucionar problemas de performance.
Pgina 41
Pgina 42
Recover
Recuperando Base de Datos en modo NO ARCHIVE
Una base de datos en modo NO ARCHIVE solo puede ser recuperada hasta el ltimo backup offline ejecutado. Debemos restaurar TODA la base de datos y levantarla.
Pgina 43
Perdiendo datafiles de tablespaces crticos. Los tablespaces crticos son: SYSTEM y UNDO. 1. Bajar la base de datos. 2. Subir la base de datos hasta modo MOUNT. 3. Colocar el datafile perdido o daado en modo offline 4. Restaurar el datafile, hacer recover y colocar el datafile en modo online. 5. Abrir la base de datos.
Pgina 44
Pgina 45
Perdiendo temp files. En el caso de los temp files no es crtico, podemos crear otros tempfiles al Tablespace y se arregla el problema. En caso la base de datos est abajo y no existe los temp files, el mismo Oracle los recrea automticamente. Nota: Si deseamos restaurar archive logs debemos ejecutar los siguientes comandos: RESTORE ARCHIVELOG SEQUENCE n RESTORE ARCHIVELOG FROM SEQUENCE n UNTIL SEQUENCE m;
Pgina 46
Incomplete Recovery
Un incomplete recovery es recuperar nuestra base de datos hasta un punto en el tiempo que nosotros indiquemos. Podemos recuperar nuestra base de datos por 4 medidas: time, scn, log sequence y cancel. Paso 1: Bajar la base de datos y subirla en modo MOUNT. Paso 2: Restaurar en el tiempo. RMAN> RESTORE DATABASE UNTIL TIME "TO_DATE('10/15/2009 13:00','MM/DD/YYYY HH24:MI')"; RMAN> RESTORE DATABASE UNTIL TIME "sysdate-1/24*60"; Existe: UNTIL TIME, UNTIL SCN, UNTIL LOG SEQUENCE, UNTIL CANCEL Pasos: Paso 3: Hacer recover en el tiempo RMAN> RECOVER DATABASE UNTIL TIME "TO_DATE('10/15/2009 13:00','MM/DD/YYYY HH24:MI')"; RMAN> RECOVER DATABASE UNTIL TIME "sysdate-1/24*60"; Paso 4: Subir la base de datos en OPEN NO RESETLOGS. SQL> ALTER DATABASE OPEN RESETLOGS Nota: OPEN RESETLOGS generar una nueva encarnacin en la base de datos, lo cual significa que la secuencia de archive logs inician en 1, los online redo los son limpiados y los backups pre existentes ya no sirven para este nuevo ciclo de vida de la base de datos.
Pgina 47
Tambin se puede restaurar dirigindonos donde se ubica el backup y copiarlo mediante comandos de S.O y luego hacer el restore. Otra tcnica ms avanzada en caso de una prdida de un datafile es indicar a la base de datos que haga un switch del datafile daado al backup image. Esto lo podemos realizar con el comando: switch datafile # to copy;
Pgina 48
Pgina 49
Pgina 50
RMAN> BACKUP CHECK LOGICAL VALIDATE DATABASE; (No genera un backup y finalizado la revisin el resultado lo podemos encontrar en v$database_block_corruption) Utilizando DBV: dbv file=/u02/oradata/ORCL/system.dbf blocksize=8192 Analizando los objetos: SQL> analyze table nombre valdate structure cascade (finalizado la revisin el resultado lo podemos encontrar en v$database_block_corruption)
Nota: El recover de data blocks fallar si el bloque fsico corrupto est en un redo log file.
Pgina 51
Abrimos el archive backup_controlfile.sql El script tiene 2 secciones: Una que tiene la sentencia NORESETLOGS y la debemos aplicar cuando tengamos los online redo logs disponibles y la otra seccin es RESETLOGS y la debemos usar cuando no tengamos los online redo logs disponibles. En el ejemplo tenemos los online redo logs entonces se har con la seccin NORESETLOGS.
Con esto se reconstruye el control file. Restauracin del control file. Debemos contar con una copia del control file. Ejemplo: SQL> alter database backup controlfile to '/tmp/control.ctl'; Si perdemos todos los controlfiles, entonces procedemos a bajar la base de datos con: SQL> shutdown abort; Luego copiamos el backup del controlfile en las ubicaciones de los controlfiles perdidos y levantamos la base de datos pero con OPEN RESETLOGS.
Pgina 53
Recuperacin de una Base de Datos habiendo perdido todos los files con la mnima prdida de informacin
Requisito: Debemos contar con un backup completo con los archivers y el online redo log; Fases: 1) Subimos la base de datos en estado nomount (dummy) 2) Recuperamos el spfile y levantamos en modo nomount. 3) Recuperamos el controlfile del autobackup y levantamos en modo mount. 4) Restauramos la base de datos. 5) Hacemos recover. 6) Levantamos la base de datos si tenemos los online redo logs sino levantamos en modo RESETLOGS. Sacando un Backup completo a la base de datos. RMAN> backup as compressed backupset database plus archivelog; Bajamos la base de datos y subimos en modo nomount (dummy)
Pgina 54
Restauramos el Control File RMAN> startup nomount forc; (Para inicializar con el spfile recuperado) RMAN> restore controlfile from 'ruta'; Este restore controlfile from pudo ser cambiado seteando el DBID: RMAN> SET DBID=xxx RMAN> restore controlfile from autobackup;
Pgina 55
Levantamos la Base de Datos en RESETLOGS No contamos con los online redo logs por lo tanto aperturamos conRESETLOGS.
Pgina 56
Si deseamos saber que objetos se borraran despus del recovery en el tiempo consultamos la vista: TS_PITR_OBJECTS_TO_BE_DROPPER (Filtrar por el campo CREATION_TIME>Tiempo_Recovery_Incomplete) Restricciones:
Pgina 57
1. No podemos hacer recovery en el tiempo a un tablespace donde tenga objetos que dependan de otros y estos se ubiquen en otro tablespace. En este escenario hay que mover el tablespace y los tablespaces dependientes. Para saber de antemano la dependencia debemos consultar la vista: SYS.TS_PITR_CHECK 2. Si renombramos un tablespace ya no podemos retroceder en el tiempo a menos que saquemos otro backup y ese sera nuestro punto de partida. 3. Tablespaces que contienen los siguientes objetos no puden aplicrsele el Recovery Incomplete: Tablas master de replicacin, particiones de tablas particionadas (debe ser toda la tabla y sus particiones), tablas externas, tablas con tipo de datos VARRAY y Nested Table, tablespaces con undo o rollback segments y objetos del owner SYS.
Pgina 58