INSTITUTO TECNOLGICO DE LZARO CRDENAS

CARRERA: INGENIERA EN SISTEMAS COMPUTACIONALES

MATERIA: ADMINISTRACION DE BASES DE DATOS

TRABAJO DE INVESTIGACIN: UNIDAD 5

SEMESTRE: 6

INTEGRANTES DE EQUIPO: BASURTO PEALOZA MINERVA 11560463LUIS DAVID GALVEZ ESPINOSA 11560112

ContenidoUNIDAD 535.1 Respaldo y recuperacin.35.1.3 Mtodos de respaldo de un DBMS35.1.3.1 Elementos y frecuencia de respaldo.85.1.3.2 Comandos para respaldo de datos105.1.3.3 Mtodos de recuperacin de un DBMS115.1.4 Cuales son los Comandos (opciones) para la recuperacin de una BD.185.1.4.1 Que Ventajas y Desventajas existen para cada mtodo de los diferentes mtodos.185.3 Monitoreo y Auditora de la Base de Datos275.3.1 Como se realiza (pasos) el Monitoreo de lo siguiente:275.3.1.1 Monitoreo general del DBMS275.3.1.2 Monitoreo de espacio en disco.285.3.1.5 Monitoreo de la Base de Datos285.3.2 Como se realiza (pasos) las siguientes actividades de Auditoria:295.3.2.1 Habilitacin y deshabilitar el modo de auditora295.3.2.2 Que tablas / vistas contienen informacin de la auditora de una BD.30

UNIDAD 55.1 Respaldo y recuperacin.Para conseguir un funcionamiento seguro de la BD y una pronta recuperacin ante fallos se necesita planear una estrategia de copias de seguridad,backup, y de recuperacin,recovery, ya que de nada sirve pensar que estamos a salvo de tales circunstancias, y que eso no me puede pasar a m. Y el primer paso a dar es definir las caractersticas fundamentales de la implantacin, porque mal vamos a conseguir unos objetivos si se desconocen o estn indefinidos. El segundo paso es establecer unos planes de copias de seguridad y recuperacin que nos permitan asegurar los objetivos.5.1.3 Mtodos de respaldo de un DBMSUnbackupvlido es una copia de la informacin sobre la BD necesaria para reconstruir la BD a partir de un estado no utilizable de la misma. Normalmente, si la estrategia debackupse basa en la copia de los ficheros de datos y en el archivado de los ficherosredo log, se han de tener copias de los ficheros de datos, de los ficheros de control, de los ficherosredo logactivos y tambin de los archivados. Si se pierde uno de los ficherosredo logarchivados se dice que se tiene un agujero en la secuencia de ficheros. Esto invalida elbackup, pero permite a la BD ser llevada hasta el principio del agujero realizando una recuperacin incompleta.

Diseo de la BD y Reglas Bsicas deBackupAntes de nada, es muy importante entender ciertas reglas que determinan la situacin de los ficheros y otras consideraciones que afectarn al esquema debackup: Es recomendable archivar los ficherosredo logen disco, y luego copiarlos a cinta, pero siempre en un disco diferente del que soporta los ficheros de datos y deredo logactivos. Los ficheros copias no deben estar en el mismo dispositivo que los originales. No siempre hay que pasar las copias a cinta, ya que si se dejan en disco se acelera la recuperacin. Adems, si se copian las copias a cinta y se mantienen en el disco, se puede sobrevivir a diversos fallos de dispositivo. Se deberan mantener diferentes copias de los ficheros de control, colocadas en diferentes discos con diferentes controladores. Los ficherosredo logen lnea deben estar multiplexados, con un mnimo de 2 miembros por grupo, residiendo cada miembro en un disco distinto. Siempre que la estructura de la BD cambie debido a la inclusin, borrado o renombrado de un fichero de datos o deredo log, se debe copiar el fichero de control, ya que almacenan la estructura de la BD. Adems, cada fichero aadido tambin debe ser copiado. El fichero de control puede ser copiado mientras la BD est abierta con el siguiente comando: SVRMGR> alter database backup controlfile to 'destino'; Teniendo en cuenta las reglas anteriores, los siguientes puntos pueden considerarse un ejemplo de estrategia debackup:1. Activar el modoARCHIVELOG.2. Realizar unbackupal menos una vez a la semana si la BD se puede parar. En otro caso, realizarbackupsen caliente cada da.3. Copiar todos los ficherosredo logarchivados cada cuatro horas. El tamao y el nmero de ellos depender de la tasa de transacciones.4. Efectuar unexportde la BD semanalmente en modoRESTRICT.BackupsFsicosLosbackupsfsicos son aquellos que copian fsicamente los ficheros de la BD. Existen dos opciones: en fro y en caliente. Se dice que elbackupes en frio cuando los ficheros se copian con la BD esta parada. En caliente es cuando se copian los ficheros con la BD abierta y funcionando.Backupen FroEl primer paso es parar la BD con el comandoshutdown normal. Si la BD se tiene que parar coninmediateoabortdebe rearrancarse con el modoRESTRICTy vuelta a parar en modo normal. Despus se copian los ficheros de datos, los deredo logy los de control, adems de losredo logarchivados y an no copiados.Una buena idea es automatizar todo este proceso con losscriptscorrespondientes, de modo que no nos olvidemos de copiar ningn fichero.Como este tipo debackupes una copia de los ficheros de la BD, si estos contienen algn tipo de corrupcin, la traspasaremos a la copia de seguridad sin detectarla. Por esto es importante comprobar las copias de seguridad.Backupen CalienteSi la implantacin de BD requiere disponibilidad de la misma 24h. al da, 7 dias a la semana no se pueden realizarbackupsen frio. Para efectuar unbackupen caliente debemos trabajar con la BD en modoARCHIVELOG. El procedimiento debackupen caliente es bastante parecido al frio. Existen dos comandos adicionales:begin backupantes de comenzar yend backupal finalizar elbackup. Por ejemplo, antes y despus de efectuar unbackupdeltablespaceusersse deberan ejecutar las sentencias: SVRMGR> alter tablespace users begin backup;SVRMGR> alter tablespace users end backup;As como elbackupen frio permita realizar una copia de toda la BD al tiempo, en losbackupsen caliente la unidad de tratamiento es eltablespace. Elbackupen caliente consiste en la copia de los ficheros de datos (portablespaces), el actual fichero de control y todos los ficherosredo logarchivados creados durante el periodo debackup. Tambin se necesitarn todos los ficherosredo logarchivados despus delbackupen caliente para conseguir una recuperacin total.

BackupsLgicosEste tipo debackupscopian el contenido de la BD pero sin almacenar la posicin fsica de los datos. Se realizan con la herramientaexportque copia los datos y la definicin de la BD en un fichero en un formato interno de Oracle.Para realizar unexportla BD debe estar abierta.Exportasegura la consistencia en la tabla, aunque no entre tablas. Si se requiere consistencia entre todas las tablas de la BD entonces no se debe realizar ninguna transaccin durante el proceso deexport. Esto se puede conseguir si se abre la BD en modoRESTRICT.Entre las ventajas de efectuar unexportestn las siguientes: Se puede detectar la corrupcin en los bloques de datos, ya que el proceso deexportfallar. Protege de fallos de usuario, por ejemplo si se borra una fila o toda una tabla por error es fcil recuperarla por medio de unimport. Se puede determinar los datos a exportar con gran flexibilidad. Se pueden realizarexportscompletos, incrementales y acumulativos. Losbackupsrealizados conexportson portables y sirven como formato de intercambio de datos entre BDs y entre mquinas.Una de las desventajas de realizarbackupslgicos conexportes que son mucho ms lentos que losbackupsfsicos.Parmetros deExportParmetroDefectoDescripcin

USERIDindefinidoelusername/passworddel usuario que efectua elexport.

BUFFERdependiente del SOEl tamao en bytes del buffer utilizado.

FILEexpdat.dmpel nombre del fichero destino.

GRANTSYesindica si se exportan tambin los derechos.

INDEXESYesindica si se exportan tambin los ndices.

ROWSYesindica si se exportan tambin las filas de las tablas, o slo las definiciones de las tablas.

CONSTRAINTSYesindica si se exportan tambin las restricciones.

COMPRESSYesindica si se exporta en modo comprimido.

FULLNoindica si se exporta la BD entera.

OWNERusuario actualuna lista de usuarios cuyos objetos se quieren exportar.

TABLESIndefinidola lista de tablas a exportar.

RECORDLENGTHdependiente del SOla longitud en bytes del registro del fichero.

INCTYPEIndefinidoel tipo deexportincremental.

RECORDYesindica si se anota elexportincremental en las tablasSYS.INCVIDy enSYS.INCEXP.

PARFILEIndefinidoel fichero de parmetros.

Modos deExportExisten tres modos de realizar una exportacin de datos:Modo Tabla

Exporta las definiciones de tabla, los datos, los derechos del propietario, los ndices del propietario, las restricciones de la tabla y los disparadores asociados a la tabla.

Modo Usuario

Exporta todo lo del modo de Tabla ms losclusters, enlaces de BD, vistas, sinnimos privados, secuencias, procedimientos, etc. del usuario.

Modo BD Entera

Adems de todo lo del modo Usuario, exporta los roles, todos los sinnimos, los privilegios del sistema, las definiciones de lostablespaces, las cuotas en lostablespaces, las definiciones de los segmentos derollback, las opciones de auditora del sistema, todos los disparadores y los perfiles.El modo BD entera puede ser dividido en tres casos: Completo, Acumulativo e Incremental. Estos dos ltimos se toman menos tiempo que el completo, y permiten exportar slo los cambios en los datos y en las definiciones.Completo

Exporta todas las tablas de la BD e inicializa la informacin sobre la exportacin incremental de cada tabla. Despus de una exportacin completa, no se necesitan los ficheros de exportaciones acumulativas e incrementales de la BD anteriores. $ exp userid=system/manager full=y inctype=complete constraints=Yfile=full_export_filename

Acumulativo

Exporta solo las tablas que han sido modificadas o creadas desde la ltima exportacin Acumulativa o Completa, y registra los detalles de exportacin para cada tabla exportada. Despus de una exportacin acumulativa, no se necesitan los ficheros de exportaciones incrementales de la BD anteriores. $ exp userid=system/manager full=y inctype=cumulative constraints=Yfile=cumulative_export_filename

Incremental

Exporta todas las tablas modificadas o creadas desde la ltima exportacin Incremental, Acumulativa o Completa, y registra los detalles de exportacin para cada tabla exportada. Son interesantes en entornos en los que muchas tablas permanecen estticas por periodos largos de tiempo, mientras que otras varan y necesitan ser copiadas. Este tipo de exportacin es til cuando hay que recuperar rpidamente una tabla borrada por accidente. $ exp userid=system/manager full=y inctype=incremental constraints=Yfile=incremental_export_filenameLa poltica de exportacin puede ser la siguiente: realizar una exportacin completa el da 1 (por ejemplo el domingo), y luego realizar exportaciones incrementales el resto de la semana. De este modo de lunes a sbado slo se exportarn aquellas tablas exportadas, ahorrando tiempo en el proceso.

5.1.3.1 Elementos y frecuencia de respaldo.Antes de nada, es muy importante entender ciertas reglas que determinan la situacin de los ficheros y otras consideraciones que afectarn al esquema debackup: Es recomendable archivar los ficherosredo logen disco, y luego copiarlos a cinta, pero siempre en un disco diferente del que soporta los ficheros de datos y deredo logactivos. Los ficheros copias no deben estar en el mismo dispositivo que los originales. No siempre hay que pasar las copias a cinta, ya que si se dejan en disco se acelera la recuperacin. Adems, si se copian las copias a cinta y se mantienen en el disco, se puede sobrevivir a diversos fallos de dispositivo. Se deberan mantener diferentes copias de los ficheros de control, colocadas en diferentes discos con diferentes controladores. Los ficherosredo logen lnea deben estar multiplexados, con un mnimo de 2 miembros por grupo, residiendo cada miembro en un disco distinto. Siempre que la estructura de la BD cambie debido a la inclusin, borrado o renombrado de un fichero de datos o deredo log, se debe copiar el fichero de control, ya que almacenan la estructura de la BD. Adems, cada fichero aadido tambin debe ser copiado. El fichero de control puede ser copiado mientras la BD est abierta con el siguiente comando:

SVRMGR> alter database backup controlfile to 'destino'; Teniendo en cuenta las reglas anteriores, los siguientes puntos pueden considerarse un ejemplo de estrategia debackup:1. Activar el modoARCHIVELOG.2. Realizar unbackupal menos una vez a la semana si la BD se puede parar. En otro caso, realizarbackupsen caliente cada da.3. Copiar todos los ficherosredo logarchivados cada cuatro horas. El tamao y el nmero de ellos depender de la tasa de transacciones.4. Efectuar unexportde la BD semanalmente en modoRESTRICT.

Oracle proporciona diferentes modos de recuperar un fallo en la BD, y es importante que el DBA conozca cmo funciona cada uno de ellos para determinar cundo ha de ser utilizado.Una de las mayores responsabilidades del DBA consiste en tener la BD a punto, y prepararla ante la posibilidad de que se produzca un fallo. As, ante un fallo el DBA podr recuperar la BD en el menor tiempo posible. Los procesos de recuperacin dependen del tipo de error y de las estructuras afectadas.As, los tipos de error que se pueden producir son:Errores de UsuarioComo por ejemplo un usuario borrando una fila o eliminando una tabla. Estos errores se solucionan importando una tabla de una copia lgica anterior. Si no se dispone de la copia lgica, se puede recuperar la BD en una instancia auxiliar, exportar la tabla en cuestin de la instancia auxiliar e importarla en la instancia operativa.Fallos de SentenciasSe definen como la imposibilidad del SGBD Oracle de ejecutar alguna sentencia SQL. Un ejemplo de esto se produce cuando se intenta una seleccin de una tabla que no existe. Estos fallos se recuperan automticamente mediante unrollbackde la transaccin que contena la sentencia fallida. El usuario necesitar volver a ejecutar otra vez la transaccin cuando se haya solucionado la causa del problema.Fallos de ProcesosEs una terminacin anormal de un proceso. Si el proceso era un proceso de usuario, del servidor o de una aplicacin elPMONefectuar la recuperacin del proceso. Si el proceso era alguno de los debackground, la instancia debe de ser parada y arrancada de nuevo, proceso durante el cual se recupera la caida efectuando unroll forwardy unrollbackde las transacciones no confirmadas.Fallos de la RedAlgunas veces los fallos en la red producen fallos de proceso, que son tratados por elPMON. Si en el error de red se ve envuelta una transaccin distribuida, una vez que se reestablece la conexin, el procesoRECOresuelve los conflictos automticamente.Fallos de InstanciaPueden deberse a fallos fsicos o de diseo del software que hacen que algn procesobackgroundcaiga y la instancia con l. La recuperacin es automtica cuando se levanta la BD, tomndose ms o menos tiempo en la recuperacin.

Fallos del SistemaSon los fallos ms peligrosos, no slo porque se pueden perder datos, sino porque se tarda ms tiempo en recuperar que los otros fallos. Adems se depende mucho de la experiencia del DBA para levantar la BD rpidamente y sin prdida (o casi) de datos.Existen tres tipos de recuperacin en Oracle: a nivel de bloque, dethready fsica.Recuperacin de bloquesEs el mecanismo de recuperacin ms simple, y se realiza automticamente. Se produce cuando un proceso muere justo cuando est cambiando un bloque, y se utilizan los registrosredo logen lnea para reconstruir el bloque y escribirlo en disco.Recuperacin dethreadsSe realiza automticamente cuando Oracle descubre que una instancia muere dejando abierto unthread, entonces se restauran los bloques de datos modificados que estaban en elcachede la instancia muerta, y cerrando elthreadque estaba abierto. La recuperacin se efectua automticamento cuando la BD se levanta.Recuperacin fsicaSe realiza como respuesta a un comandoRECOVER. Se utiliza para convertir los ficheros debackupen actuales, o para restaurar los cambios que fueron perdidos cuando un fichero de datos fue puestoofflinesin uncheckpoint, aplicando los ficheroredo logarchivados y en lnea.

5.1.3.2 Comandos para respaldo de datos

Copiar fichero de control mientras la BD est abierta: SVRMGR> alter database backup controlfile to 'destino';

Parar la BD:shutdown normalLOS COMANDOS ESTAN DENTREO DE SU RESPECTIVO METODO DE RESPALDO

5.1.3.3 Mtodos de recuperacin de un DBMSLa Recuperacin de una BD es el restablecimiento de un estado correcto de la BD (consistente) despus que un fallo del sistema haya ocasionado que el estado actual sea inconsistente.Existen diversos mtodos para la restauracin de una base de datos corrupta a un estado previo libre de daos. El tipo de tcnica de recuperacin usado en cada situacin determinada depende de varios factores.COPIAS DE SEGURIDADPara poder efectuar cualquier tipo de restauracin de una base de datos, es necesaria la realizacin de copias de seguridad (Backus) de la base de datos de forma peridica. Este proceso consiste en la escritura de una copia exacta de la base de datos en un dispositivo magntico separado del que contiene a la propia base de datos. En los sistemas ms grandes, este dispositivo suele ser una cinta magntica. En los sistemas basados en microordenadores, puede tratarse de un cartucho de cinta de casete, o de uno o ms discos flexibles.

MTODO MS SENCILLOEl mtodo ms simple de recuperacin de una base de datos es el expuesto a continuacin. Peridicamente, quiz una vez cada da, se realiza una copia de seguridad de la base de datos. Comenzando a partir del momento en el que se hace cada copia, se lleva manualmente una lista fsica, o diario (log), de todos los cambios subsiguientes que se efectan en la base de datos. Si la base de datos es daada o destruida, para recuperarla es preciso seguir la secuencia de pasos siguiente:- Reparar el problema de hardware o software que caus la cada del sistema.- Restaurar la base de datos a partir de la copia de seguridad ms reciente.- Volver a introducir manualmente en la base de datos los cambios realizados desde que se hizo la copia, usando la lista fsica. Existen varios mtodos de recuperacin, pero todos ellos se basan en la aplicacin de los registros deredo log.Aplicacin deRedo LogCuando una BD se arranca con el comandostartup, la BD pasa por los estadosnomount,mountyopen. En este tercer estado, se verifica que se pueden abrir todos los ficheros delogy de datos. Si la BD se arranca por primera vez despus de una cada, se necesitar efectuar una recuperacin que consiste en dos pasos: avanzar la BD hacia adelante aplicando los registrosredo log, deshacer las transacciones no confirmadas.Cada fichero de datos tiene en su cabecera el ltimocheckpointefectuado, as como el fichero de control tambin lleva esa cuenta. Elcheckpointlleva incluido el SCN. Este es conocido como SCN de inicio de fichero. Asociado a cada fichero de datos el fichero de control tiene el SCN de final, puesto inicialmente a infinito. El SCN de inicio se incrementa con cadacheckpoint.Cuando la BD se para en modo normal o inmediato iguala el SCN de parada para cada fichero de datos al SCN almacenado en cada fichero de datos. Cuando se abre otra vez la BD se realizan dos comprobaciones. La primera es mirar si el contador decheckpointsen la cabecera de los ficheros de datos coincide con el correspondiente del fichero de control. Si es as, se compara el SCN de inicio de cada fichero de datos con el SCN de final almacenado en el fichero de control. Si son iguales no se necesita recuperacin en este fichero de datos. Como parte de la apertura se pone a infinito el SCN de final para ese fichero de datos.Si la BD se par con en modoabortno se ejecut elcheckpointy el SCN de fin para los fichero de datos est a infinito. As, durante la BD se abre, y suponiendo que el contador decheckpointscoincide, se comparan los SCN de inicio y de final, y como el ltimo es infinito se efectuar una recuperacin aplicando los cambios almacenados en los ficherosredo logen lnea para avanzar la BD, y los registros deroll backde los segmentos deroll backpara deshacer las transacciones no confirmadas.Si despus de parar la BD se reemplaza un fichero de datos por su copia de seguridad, al arrancar la BD Oracle detecta que el contador decheckpointsdel fichero de datos no coincide con el almacenado en el fichero de control. As, se tendr que echar mano a los ficherosredo logarchivados, empezando por aquel cuyo nmero de secuencia aparece en la cabecera del fichero de datos.

Recuperacin FsicaLa utilizacin de una copia debackupde ficheros de datos siempre necesita de una recuperacin fsica. Tambin es as cuando un fichero de datos se poneofflinesin uncheckpoint.Oracle detecta que se necesita una recuperacin fsica cuando el contador decheckpointsde la cabecera del fichero de datos no coincide con el correspondiente contador decheckpointsdel fichero de control. Entonces se hace necesario el comandorecover. La recuperacin comienza en el SCN menor de los ficheros de datos en recuperacin, aplicando los registros deredo loga partir de l, y parando en el SCN de final mayor de todos los ficheros de datos.Existen tres opciones para realizar una recuperacin fsica. La primera es una recuperacin de BD donde se restaura la BD entera. La segunda es una recuperacin detablespacedonde, mientras una parte de la BD est abierta, se puede recuperar untablespacedeterminado. Esto significa que sern recuperados todos los ficheros de datos asociados altablespace. El tercer tipo es la recuperacin de un fichero de datos especfico mientras el resto de la BD est abierta.Requisitos para Utilizar Recuperacin FsicaLa primera condicin que se ha de poner para poder recuperar fsicamente una BD es que sta se est utilizando en modoARCHIVELOG. De otro modo, una recuperacin completa puede que no sea posible. Si trabajamos con la BD en modoNOARCHIVELOG, y se hace una copia semanal de los ficheros de la BD, se debera estar preparado para perder, en el peor de los casos, el trabajo de la ltima semana si sucede un fallo. Ya que los ficheros deredo logcontendran un agujero y no se poda avanzar la BD hasta el instante anterior al fallo. En este caso el nico medio para reconstruir la BD es hacerlo desde unexportcompleto, recreando el esquema de la BD e importando todos los datos.Recuperacin de la BDLa BD debe estar montada pero no abierta. El comando de recuperacin es el siguiente:

RECOVER [AUTOMATIC] [FROM 'localizacion'] [BD] [UNTIL CANCEL] [UNTIL TIME fecha] [UNTIL CHANGE entero][USING BACKUP CONTROLFILE]Las opciones entre corchetes son opcionales: AUTOMATIChace que la recuperacin se haga automticamente sin preguntar al DBA por el nombre de los ficherosredo log. Tambin se puede utilizar para este cometido el comandoset autorecovery on/off. Los ficherosredo logdeben estar en la localizacin fijada enLOG_ARCHIVE_DESTy el formato del nombre de los ficheros debe ser el fijado enLOG_ARCHIVE_FORMAT. FROMse utiliza para determinar el lugar donde estn los ficherosredo log, si es distinto del fijado enLOG_ARCHIVE_DEST. UNTILsirve para indicar que se desea realizar una recuperacin incompleta, lo que implica perder datos. Solo se dar cuando se han perdidoredo logarchivados o el fichero de control. Cuando se ha realizado una recuperacin incompleta la BD debe ser abierta con el comandoalter database open resetlogs, lo que produce que losredo logno aplicados no se apliquen nunca y se inicialice la secuencia deredo logen el fichero de control. Existen tres opciones para parar la recuperacin:

UNTIL CANCELpermite recuperar unredo logcada vez, parando cuando se tecleaCANCEL. UNTIL TIMEpermite recuperar hasta un instante dado dentro de un fichero deredo log UNTIL CHANGEpermite recuperar hasta un SCN dado. USING BACKUP CONTROLFILEutiliza una copia de seguridad del fichero de control para gobernar la recuperacin.Recuperacin de untablespaceLa BD debe estar abierta, pero con eltablespacea recuperaroffline. El comando de recuperacin es el siguiente:

RECOVER [AUTOMATIC] [FROM 'localizacion'] TABLESPACE nombre_tablespace [, nombre_tablespace]Recuperacin de un Fichero de DatosLa BD debe estar abierta o cerrada, dependiendo del fichero a recuperar. Si el fichero a recuperar es de untablespacede usuario la BD puede estar abierta, pero con el fichero a recuperaroffline. Si el fichero es deltablespaceSYSTEMla BD debe estar cerrada, ya que no puede estar abierta con los ficheros delSYSTEMoffline. El comando de recuperacin es el siguiente:

RECOVER [AUTOMATIC] [FROM 'localizacion'] DATAFILE nombre_fichero [, nombre_fichero]Creando un Fichero de ControlSi el fichero de control ha resultado daado y se ha perdido se puede utilizar una copia de seguridad del mismo o crear uno nuevo. El comando de creacin de un nuevo fichero de control esCREATE CONTROLFILE. Este comando se puede ejecutar slo con la BD en estadonomount. La ejecucin del comando produce un nuevo fichero de control y el montaje automtico de la BD.Un comando interesante que ayuda a mantener los ficheros de control a salvo es el siguiente: SVRMGR> alter database backup controlfile to trace;Que produce unscriptque puede ser utilizado para generar un nuevo fichero de control y recuperar la BD, en caso necesario. El fichero de traza generado es el siguiente: Dump file /opt/app/oracle/admin/demo/udump/demo_ora_515.trcOracle7 Server Release 7.3.2.3.0 - Production ReleaseWith the distributed, replication and Spatial Data optionsPL/SQL Release 2.3.2.3.0 - ProductionORACLE_HOME = /opt/app/oracle/product/7.3.2System name: SunOSNode name: cartanRelease: 5.5Version: GenericMachine: sun4mInstance name: demoRedo thread mounted by this instance: 1Oracle process number: 7Unix process pid: 515, image: oracledemo Fri May 15 11:41:19 1998Fri May 15 11:41:19 1998*** SESSION ID:(6.2035) 1998.05.15.11.41.19.000# The following commands will create a new control file and use it# to open the database.# No data other than log history will be lost. Additional logs may# be required for media recovery of offline data files. Use this# only if the current version of all online logs are available.STARTUP NOMOUNTCREATE CONTROLFILE REUSE DATABASE "DEMO" NORESETLOGS NOARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 2 MAXDATAFILES 30 MAXINSTANCES 1 MAXLOGHISTORY 100LOGFILE GROUP 1 '/export/home/oradata/demo/redodemo01.log' SIZE 2M, GROUP 2 '/export/home/oradata/demo/redodemo02.log' SIZE 2M, GROUP 3 '/export/home/oradata/demo/redodemo03.log' SIZE 2MDATAFILE '/export/home/oradata/demo/system01.dbf', '/export/home/oradata/demo/rbs01.dbf', '/export/home/oradata/demo/rbs02.dbf', '/export/home/oradata/demo/rbs03.dbf', '/export/home/oradata/demo/temp01.dbf', '/export/home/oradata/demo/tools01.dbf', '/export/home/oradata/demo/users01.dbf';# Recovery is required if any of the datafiles are restored backups,# or if the last shutdown was not normal or immediate.RECOVER DATABASE# Database can now be opened normally.ALTER DATABASE OPEN;

Recuperacin LgicaOracle dispone de la herramientaimportpara restaurar los datos de una BD a partir de los ficheros resultados de unexport.Importlee los datos de los ficheros de exportacin y ejecuta las sentencias que almacenan creando las tablas y llenndolas de datos.Parmetros delImportParmetroDefectoDescripcin

USERIDindefinidoelusername/passworddel usuario que efectua elimport.

BUFFERdependiente del SOEl tamao en bytes del buffer utilizado.

FILEexpdat.dmpel nombre del fichero de exportacin a importar.

SHOWNoindica si se muestran los contenidos del fichero de exportacin, sin importar ningn dato.

IGNOREYesindica si ignorar los errores producidos al importar un objeto que ya existe en la BD.

GRANTSYesindica si se importan tambin los derechos.

INDEXESYesindica si se importan tambin los ndices.

ROWSYesindica si se importan tambin las filas de las tablas.

FULLNoindica si se importan el fichero entero.

FROMUSERIndefinidouna lista de los usuarios cuyos objetos se han exportado.

TOUSERIndefinidouna lista de los usuarios a cuyo nombre se importan los objetos.

TABLESindefinidola lista de tablas a importar.

RECORDLENGTHdependiente del SOla longitud en bytes del registro del fichero.

INCTYPEindefinidoel tipo deimportincremental (SYSTEMoRESTORE).

COMMITNoindica si se efectua uncommitdespus de importar cada fila. Por defecto,importefectua uncommitdespus de cargar cada tabla.

PARFILEindefinidoel fichero de parmetros.

Para importar unexportincremental se puede efectuar la siguiente secuencia de pasos:Utilizar la copia ms reciente delimportpara restaurar las definiciones del sistema: $ imp userid=sys/passwd inctype=system full=Y file=export_filenamePoner los segmentos derollbackonline.Importar el fichero de exportacin completa ms reciente: $ imp userid=sys/passwd inctype=restore full=Y file=filenameImportar los ficheros de exportacin en modo acumulacin desde la exportacin completa ms reciente, en orden cronolgico: $ imp userid=sys/passwd inctype=restore full=Y file=filenameImportar los ficheros de exportacin en modo incremental desde la exportacin completa o acumulativa ms reciente, en orden cronolgico: $ imp userid=sys/passwd inctype=restore full=Y file=filename

5.1.4 Cuales son los Comandos (opciones) para la recuperacin de una BD.

5.1.4.1 Que Ventajas y Desventajas existen para cada mtodo de los diferentes mtodos. Servicios de Respaldo y Recuperacin para Bases de Datos (BD)Vamos a comenzar esta lectura con algunas preguntas que a medida que avance la lectura, sern respondidas:1. Por qu debemos respaldar una BD? Es posible recuperar informacin? Cul es la importancia de este tipo de servicios?1. Cmo funcionan?1. Son soportadas por los principales Sistemas de BD? Cul es el caso de PostgreSQL?Es de suma importancia tener algn sistema de respaldo/recuperacin de datos, pues esto permite:1. Tener sistemas con cierto nivel de seguridad y estabilidad ante posibles fallos.1. Poder volver a un punto seguro en el estado de la BD, debido a cambios peligrosos.Su funcionamiento est basado en estados. En cada momento la BD se encuentra en un estado definido. Cuando realizamos operaciones de modificacin, es decir:1. INSERT1. UPDATE1. DELETECambiamos su estado, llevndolo a uno nuevo.NotaNo se considera SELECT, pues no provoca cambios. Recordemos que es una operacin de seleccin.Al momento de realizar un respaldo, se guarda el estado en que se encuentra la BD al momento de realizar dicha operacin de respaldo.Al momento de realizar la operacin de recuperacin, puede ser de varias formas, ya sea a travs de las operaciones (en orden) que han dejado la BD en el estado actual u otras formas.La gran mayora de Motores de BD cuentan con funciones de este tipoSQL Dumppg_dumpEsta funcin genera un archivo de texto con comandos SQL que, cuando son reintroducidos (bajo cierto contexto) al servidor, se deja a la BD en el mismo estado en el que se encontraba al momento de ejecutar este comando.NotaEsto ocurre siempre y cuando la BD est vaca, es decir, en el mismo estado inicial. pg_dump guarda los comandos introducidos hasta el punto de control. El ejemplo 1 permitir aclarar dudas.su sintaxis es:pg_dump dbname > archivo_saliday se usa desde la linea de comandos.Para realizar la restauracin se utiliza:psql dbname < archivo_entradaDonde archivo_entrada corresponde al archivo_salida de la instruccin pg_dump.Ejemplo 1Supongamos que tenemos una BD llamada lecture31 y dentro de ella una nica tabla llamada Numbers con atributosNumber Y Name, con datos:1 One2 Two3 ThreeEs decir:CREATE DATABASE lecture31;Conectndose:\c lecture31CREATE TABLE Numbers(Number INTEGER, Name VARCHAR(20));INSERT INTO Numbers VALUES (1, 'One' );INSERT INTO Numbers VALUES (2, 'Two' );INSERT INTO Numbers VALUES (3, 'Three' );A travs de un select:number | name-------+------- 1 | One 2 | Two 3 | ThreePara realizar el respaldo, se utiliza pg_dump:pg_dump lecture31 > resp.sqlUn posible problema a la hora de ejecutar pg_dump es:pg_dump lecture31 > resp.sql (bash: permission denied)Para evitar esto, es necesario considerar que el usuario de la BD debe tener permisos de escritura en la carpeta donde se alojar el archivo.NotaPara los usuarios locales, basta con hacer cd en la lnea de comandos (como usuario postgres), para acceder a la carpeta de postgres. Si desea realizar pruebas desde el servidor dedicado, puede crear BDs desde su sesin y alojar los archivos de respaldo en su capeta home.NotaEs posible cambiar los permisos de lectura y escritura de las carpetas, dar accesos a usuarios que no son dueos de las BD. No se profundiza esto, pues escapa a los alcances de este curso.Supongamos que se comete un error, se borra informacin de seguridad nacional, digamos la tupla 1, One. Utilizando el archivo de respaldo es posible volver al estado anterior:psql lecture31 < resp.sqlNotaNtese que dentro de la salida del comando aparece: ERROR: relation numbers already existsRevisando la tabla a travs de:\c lecture31SELECT * FROM Numbers;La salida es:number | name-------+------- 2 | Two 3 | Three 1 | One 2 | Two 3 | ThreeLo cual, claramente, no corresponde a la informacin inicial.Antes de restaurar, es necesario recrear el contexto que tena la BD. Especficamente usuarios que posean ciertos objetos o permisos. Si esto no calza con la BD, original, es posible que la restauracin no se realice correctamente.En este caso el contexto inicial corresponde a una BD vaca, dentro de la cual se crea una tabla y se agregan algunos datos Se invita al lector a borrar la tabla y realizar la restauracin.Es necesario aclarar que se necesita una BD existente para hacer la restauracin. Si sta no existe, por ejemplo utilizar lecture32 en lugar de 31, el siguiente error aparecer:psql: FATAL: database "lecture32" does not existPero Qu ocurre si utilizamos el atributo number como PK?, es decir modificar slo la lnea (y seguir el resto de los pasos de la misma forma):CREATE TABLE Numbers(Number INTEGER, Name VARCHAR(20), PRIMARY KEY (Number));Al momento de borrar la tupla, digamos (3, Three), e intentar restaurar, dentro de la salida del comando aparece:ERROR: relation "numbers" already existsERROR: duplicate key violates unique constraint "numbers_pkey"CONTEXT: COPY numbers, line 1: "1 One"ERROR: multiple primary keys for table "numbers" are not allowedQu ocurre si se elimina la primera tupla antes de restaurar?Ejemplo 2Este ejemplo es muy similar al anterior, slo que, en lugar de trabajar con atributos INTEGER, se trabajar con atributo serial es decir:\c lecture31DROP TABLE Numbers;CREATE TABLE Numbers2(Number SERIAL, Name VARCHAR(20));INSERT INTO Numbers2 (name) VALUES ('One' );INSERT INTO Numbers2 (name) VALUES ('Two' );INSERT INTO Numbers2 (name) VALUES ('Three' );Es decir que si se hace un select, se podr ver:number | name-------+------- 1 | One 2 | Two 3 | ThreePara poder realizar el respaldo, utilizando pg_dump:pg_dump lecture31 > resp2.sqlDigamos que se agrega la tupla (4, Four) y borra la tupla (3, Three). Despus de realizar el respaldo:number | name-------+------- 1 | One 2 | Two 4 | FourPosteriormente se realiza la restauracin:psql lecture31 < resp.sqlNotaNtese que en la salida, es posible ver: setval 3Revisando la tabla a travs de:\c lecture31SELECT * FROM Numbers2;La salida es:number | name-------+------- 1 | One 2 | Two 4 | Four 1 | One 2 | Two 3 | ThreeLo cual es un problema, pues se trabaja con valores seriales. De hecho si en este estado se agrega la tupla (4, Four) y se revisan los contenidos de la tabla, la salida es:number | name-------+------- 1 | One 2 | Two 4 | Four 1 | One 2 | Two 3 | Three 4 | FourEsto ocurre debido a que el contador serial vuelve a 3.Ejercicio propuestoSe deja en manos del lector ver que ocurre en caso de trabajar con atributo serial PK, es decir:CREATE TABLE Numbers2(Number SERIAL, Name VARCHAR(20), PRIMARY KEY (number));y luego seguir los mismos pasos, es decir agregar las tuplas (1, One), (2, Two) y (3, Three). Luego realizar un respaldo, acceder a la BD, eliminar la ltima tupla, agregar (4, Four), realizar la restauracin, intentar agregar ms tuplas (conectndose a la BD primero) y los que desee hacer el lector.A modo de pista, si al agregar una tupla, aparece:ERROR: duplicate key value violates unique constraint "numbers2_pkey"Siga intentando, ver que es posible agregar ms tuplas. Fjese en el valor de la llave primaria. Cuntas veces tuvo que intentar?Qu ocurre si en lugar de eliminar la ltima tupla, se elimina la primera?pg_dumpallUn pequeo inconveniente con pg_dump es que slo puede hacer respaldos de una BD a la vez. Adems no respalda informacin acerca de roles de usuario e informacin por el estiloPara realizar un respaldo de la BD y el cluster de datos, existe el comando pg_dumpall.su sintaxis es:pg_dumpall > archivo_saliday para realizar la restauracin (utilizar el comando unix)psql -f archivo_entrada postgresQue trabaja emitiendo las consultas y comandos para recrear roles, tablespaces y Bases de Datos vacos. Posteriormente se invoca pg_dump por cada BD para corroborar consistencia interna.AdvertenciaEs posible que el servidor dedicado no le permita restaurar, si se utiliza con el usuario postgres. Por favor, utilice este comando slo de manera local. Pruebe utilizando su propio usuario.Respaldo a nivel de archivosOtra forma de realizar respaldos es a travs del manejo directo de archivos, en lugar de las sentencias utilizadas.No obstante, existen 2 restricciones que hacen que este mtodo sea menos prctico que utilizar pg_dump:1. El servidor debe ser apagado para poder obtener un respaldo utilizable.1. Cada vez que se realice un respaldo, el servidor debe estar apagado, para que los cambios se guarden en su totalidad.AdvertenciaLa mayor parte de las veces, se necesita acceso root, para poder realizar este tipo de operacin, pues es necesario configurar archivos de configuracin de postgres. Es de suma importancia que se realicen de forma correcta, pues ante algn fallo es posible destruir la base de datos de forma completa. Por lo tanto, no se abordar de forma extensa este apartado. No obstante es posible obtener informacin en internet.RsyncRsync corresponde a un programa que sincroniza dos directorios a travs de distintos sistemas de archivos, incluso si estn en distinto computadores, fsicamente hablando. A travs del uso de SSH o Secure SHell por sus siglas en ingls, se pueden realizar transferencias seguras y basadas en llaves de autenticacin.La principal ventaja de utilizar rsync a diferencia de otros comandos similares, como scp, es que si el archivo que se encuentra en la fuente, es el mismo que, el que se encuentra en el objetivo, no hay transmisin de datos; si el archivo que se encuentra en el objetivo difiere del que se encuentra en la fuente, slo aquellas partes que difieren son transmitidas, en lugar de transmitir todo, por lo que el downtime de la BD, es decir, el tiempo que debe permanecer apagada, es mucho menor. 5.3 Monitoreo y Auditora de la Base de Datos

Mediante la auditora se intenta monitorizar y registrar acciones en la base de datos con el fin de:* Investigar actividades maliciosas (borrado de tablas,..).* Detectar privilegios incorrectamente otorgados a usuarios (que permiten realizar acciones inapropiadas, las cuales son detectadas).* Recoger datos sobre actividades concretas (tablas que se actualizan, usuarios concurrentes,)* Detectar problemas con la implementacin de polticas de seguridad (puntos dbiles que generan registros).

5.3.1 Como se realiza (pasos) el Monitoreo de lo siguiente:5.3.1.1 Monitoreo general del DBMSLos sistemas de gestin de bases de datos (DBMS) ofrecen a desarrolladores, administradores y usuarios, una gama amplia de herramientas que permiten garantizar la integridad, consistencia, confidencialidad, confiabilidad y en general la seguridad de la informacin almacenada y con un elemento muy importante a favor: las lneas de cdigo que se requieren por parte del implementador son mnimas, en ocasiones solo basta con una sencilla sentencia para obligar al DBMS a controlar y mantener las restricciones necesarias.Las principales funciones de un DBMS son proveer:* Integridad.*Seguridad*Sharing (comparticin) controlado.*Recuperacin.*Monitoreo.Las principales ventajas de un DBMS consisten en asegurar:*Independencia de datos.*Redundancia controlada.*Datos compartidos*Uniformidad.*Flexibilidad.5.3.1.2 Monitoreo de espacio en disco.

El espacio en disco duro que obtienes con tu plan de hosting es normalmente ms que suficiente (en la mayora de los casos). Sin embargo, es buena idea mantener los ojos abiertos y monitorearlo con frecuencia para que este ah cuando lo necesites.

La herramienta de monitoreo de espacio en disco te proporciona todos los detalles acerca de cmo y con qu archivos estas utilizando tu espacio.El disco es casi siempre el punto crtico de un servidor de base de datos.

Si se pueden agregar fcilmente memoria, o multiplicar los CPU's disponibles, los discos estn limitados por su nmero de revoluciones por minutos (RMP). Lo comn es 7,200 RMP, los discos de velocidad superior (pero ms cara) tienen 10,000 o 15,000 RPM. 5.3.1.5 Monitoreo de la Base de Datos

Un administrador puede monitorear las actividades de la base de datos y sus usuarios. Puede usar informacin para afinar, solucionar problemas y ms. Podemos monitorear lo siguiente: Sesiones.Para poder determinar quines estn logeados actualmente en la base de datos y que aplicaciones estn ejecutando. Tambin puede utilizarse para matar una sesin.

Estadsticas del sistema.Mostrar informacin fsica del sistema operativo y estadsticas de tiempo y performance del CPU.

Top de sentencias SQLMuestra el top de sentencias SQL que han sido ejecutadas con mayor frecuencia, que usuario las utiliza y estadsticas de recurso utilizado.

Operaciones prolongadas 5.3.2 Como se realiza (pasos) las siguientes actividades de Auditoria:5.3.2.1 Habilitacin y deshabilitar el modo de auditoraEs el proceso que permite medir, asegurar, demostrar, monitorear y registrar los accesos a la informacin almacenada en las bases de datos incluyendo la capacidad de determinar:* Quin accede a los datos.* Cundo se accedi a los datos.* Desde qu tipo de dispositivo/aplicacin.* Desde que ubicacin en la Red.* Cul fue la sentencia SQL ejecutada.* Cul fue el efecto del acceso a la base de datos.

La activacin de la auditora en Oracle Database viene definida por el valor del parmetro: audit_trail. Para comprobar si la auditora de la base de datos est activada ejecutaremos el siguiente comando SQL:select name, valuefrom v$parameterwhere name like 'audit_trail'

Posibles valores del parmetro AUDIT_TRAIL:Para activar la auditora:ALTER SYSTEM SET audit_trail = "DB" SCOPE=SPFILE;

Para desactivar la auditora ejecutaremos el siguiente comando:

ALTER SYSTEM SET audit_trail = "NONE" SCOPE=SPFILE; DBA_AUDIT_TRAIL: Muestra la auditora estndar (de la tabla AUD$) relativa al usuario actual. Es una lista de todas las entradas en la tabla SYS.AUD$ colectada por el comando audit.

DBA_AUDIT_OBJECT: Lista las opciones de entrada de auditoras para auditar objetos de la base de datos. DBA_AUDIT_EXISTS: Es una lista de entradas de auditora generadas por la opcin EXISTS en el comando AUDIT. DBA_AUDIT_SESSION: Muestra las entradas de auditora generadas por conexiones o desconexiones de sesiones. DBA_AUDIT_STATEMENT: Es una lista de entradas de auditoras, con la informacin recolectada de las opciones de sentencias en el comando audit.

Las principales vistas para obtener resultados de la auditora, son las siguientes:

5.3.2.2 Que tablas / vistas contienen informacin de la auditora de una BD.

Oracle Database almacena en el diccionario de datos, en la tabla SYS.AUD$ o en la pista de auditora del sistema operativo (si lo permite). Existen varias vistas que se basan en esta tabla (SYS.AUD$) para mostrar distintos resultados, segn la informacin que se quiera obtener:Algunas de las principales vistas para obtener informacin de las opciones de auditora, son las siguientes: ALL_DEF_ AUDIT_OPTS: Lista las opciones de auditora que estn definidas por defecto para auditar los objetos de la base de datos. DBA_STMT_AUDIT_OPTS: Lista las posibles opciones de auditora para todas las sentencias ejecutadas en la base de datos. DBA_PRIV_AUDIT_OPTS: Es una lista de opciones de auditora para todos los privilegios en la base de datos. DBA_OBJ_AUDIT_OPTS: Es una lista de opciones de auditora para vistas, tablas y otros objetos de la base de datos 2