2. Mecanismos de seguridad
El sistema de base de datos ORACLE provee control de acceso discrecional, el cual es un medio de restricción de acceso basado en privilegios. Para que un usuario pueda acceder a un objeto, se le deben otorgar los privilegios apropiados. Los usuarios con los privilegios adecuados pueden otorgar privilegios a otros usuarios a su criterio. Por esta razón, este tipo de seguridad es llamada "discrecional".
Oracle administra la seguridad de la base de datos utilizando diferentes servicios o facilidades:
- Usuarios y esquemas
- Privilegios
- Roles
- Configuración del almacenamiento y quotas
- Límites a los recursos
- Monitoreo
2.1 – Usuarios y esquemas
Cada base de datos tiene una lista de nombres de usuarios. Para acceder a la base de datos, un usuario debe usar una aplicación e intentar entablar una conexión con un nombre de usuario válido de la base de datos. Cada usuario tiene una clave de acceso asociada para prevenir el uso no autorizado.
- Dominio de Seguridad
Cada usuario tiene un dominio de seguridad, un conjunto de propiedades que determinan factores como:
- Acciones (privilegios y roles) disponibles para el usuario.
- Límites de espacio en el Tablespace para los usuarios.
- Límites de utilización de los recursos del sistema para los usuarios.
2.2 – Privilegios
Un privilegio es un permiso para ejecutar un tipo particular se sentencias SQL.
Los privilegios de una base de datos ORACLE pueden ser divididos en dos categorías distintas: Privilegios de sistema y Privilegios de objetos.
2.2.1 Privilegios de sistema
Los Privilegios de sistema permiten a los usuarios desempeñar una acción particular dentro del sistema o una acción particular sobre un tipo determinado de objeto. Por ejemplo, el privilegio para crear un tablespace o para borrar filas de una tabla en la base de datos son privilegios de sistema. Muchos privilegios de sistema están disponibles solamente para administradores y desarrolladores de aplicaciones porque estos privilegios son muy poderosos.
2.2.2 Privilegios de objetos
Los privilegios de objetos permiten a los usuarios desempeñar acciones sobre un esquema específico. Por ejemplo, el privilegio para borrar filas de una tabla específica es un privilegio de objetos. Los privilegios de objetos son asignados a usuarios finales, entonces ellos pueden usar una aplicación de la base de datos para llevar a cabo tareas específicas.
2.2.3 Asignar privilegios
Un usuario puede recibir un privilegio de dos formas distintas:
- Los privilegios pueden ser asignados a los usuarios explícitamente.
- Los privilegios pueden ser asignados a roles (grupo de privilegios), y después el rol puede ser signado a uno o más usuarios.
Debido a que los roles permiten una mejor y más fácil administración de los privilegios, éstos normalmente son asignados a roles y no a usuarios específicos.
2.3 – Roles
ORACLE provee los roles para una administración más fácil y controlada de los privilegios. Los roles son un grupo con nombre de privilegios, que son asignados a usuarios o a otros roles. Las siguientes propiedades de los roles permiten administrar los privilegios de una manera más fácil:
- Reducida asignación de privilegios: En lugar de otorgar explícitamente el mismo conjunto de privilegios a muchos usuarios el administrador de la base de datos puede asignar los privilegios a un rol y éste a un grupo de usuarios.
- Administración dinámica de los privilegios: Cuando los privilegios de un grupo deben cambiar, sólo los privilegios del rol necesitan ser modificados. Los dominios de seguridad de todos los usuarios a los que asignó dicho rol, reflejarán automáticamente los cambios hechos en el rol.
- Selectiva disponibilidad de los privilegios: Los roles asignados a los usuarios pueden ser selectivamente activados o desactivados. Esto permite control específico de los privilegios de los usuarios en cualquier situación.
- Consciencia de aplicación: Una aplicación de la base de datos puede ser diseñada para habilitar o inhabilitar roles automáticamente cuando un usuario intenta usar la aplicación.
2.4 – Configuración del almacenamiento y quotas
ORACLE provee medios para limitar el uso del espacio de disco asignado a la base de datos, de acuerdo a cada usuario; incluyendo los default tablespaces, temporary tablespaces y los tablespaces quotas.
Cada usuario es asociado a un default tablespace. Cuando un usuario crea una tabla, índice, o cluster y no se especifica ningún tablespace que contenga físicamente al objeto, el default tablespace es utilizado si el usuario tiene privilegio para crear el objeto.
- Default Tablespace
Cada usuario tiene un temporary tablespace. Cuando un usuario ejecuta una sentencia SQL que requiere la creación de objetos temporarios (por ejemplo un índice), se usa el temporary tablespace del usuario.
- Temporay Tablespace
- Tablespace Quotas
ORACLE puede limitar el espacio disponible de disco colectivo. Las quotas (límites de espacio) pueden ser configuradas para cada tablespace disponible para un usuario. Las tablespace quotas permiten un control selectivo sobre el espacio en disco que es consumido por cada objeto de cada esquema.
2.5 – Límites a los recursos
A cada usuario le es asignado un perfil que especifica las limitaciones sobre varios recursos del sistema disponibles para el usuario, incluyendo:
– disponible para la sesión del usuario
- disponible para una simple llamada a ORACLE realizada por una sentencia SQL.
- Cantidad de I/O:
– disponible para la sesión del usuario
– disponible para una simple llamada a ORACLE realizada
por una sentencia SQL.
- La cantidad de tiempo ocioso permitido para la sesión del usuario.
- La cantidad de tiempo de conexión permitido para la sesión del usuario.
- Restricciones en las passwords:
- Bloqueo de la cuenta después de una determinada cantidad de intentos de conexión fallidos
- Expiración de las passwords y período de gracia.
- Reutilización de passwords y restricciones.
Se pueden crear diferentes perfiles y asignarse individualmente a cada usuario de la base de datos. A los usuarios que no se le ha asignado explícitamente un perfil, se le asigna el perfil por default. El límite en la utilización de recursos previene el consumo excesivo de los recursos globales del sistema de base de datos.
2.6 – Monitoreo
ORACLE permite realizar un monitoreo selectivo de las acciones de los usuarios para ayudar en la investigación de usos maliciosos de la base de datos. El monitoreo puede realizarse a tres niveles distintos:
- Monitoreo de sentencias: Es el monitoreo de sentencias SQL específicas sin atender concretamente a los objetos. Este tipo de monitoreo puede hacerse para todos los usuarios del sistema o se puede enfocar sólo a algunos usuarios seleccionados.
- Monitoreo de privilegios: Es el monitoreo de los privilegios del sistema sin atender concretamente a los objetos. Este tipo de monitoreo puede hacerse para todos los usuarios del sistema o se puede enfocar sólo a algunos usuarios seleccionados.
- Monitoreo de objetos: Es el monitoreo de los accesos a esquemas específicos sin considerar el usuario. Monitorea las sentencias permitidas por los privilegios.
Para todos los tipos de monitoreo, ORACLE permite el monitoreo selectivo de sentencias ejecutadas con éxito, sentencias ejecutadas sin éxito o ambas.
Los resultados del monitoreo son registrados en una tabla llamada "the audit trail" (la pista de auditoría).
3. Políticas de Seguridad
Este capítulo provee una guía para el desarrollo de políticas de seguridad para operaciones de bases de datos, e incluye los siguientes temas:
- Política de Seguridad del Sistema
- Política de Seguridad de la Información
- Política de Seguridad del Usuario
- Política Administrativa de Passwords
- Política de Auditoría
3.1 – Política de Seguridad del sistema
Esta sección describe aspectos de la política de seguridad de sistemas e incluye los siguientes temas:
- Administración de usuarios de base de datos
- Autentificación de usuarios
- Seguridad de Sistemas Operativos
Cada base de datos tiene uno o más administradores de seguridad quienes son responsables del mantenimiento de todos los aspectos de la política de seguridad. Si el sistema de bases de datos es pequeño, el administrador de bases de datos podría tener las responsabilidades del administrador de seguridad. Sin embargo, si el sistema de bases de datos es grande, una persona o grupos de personas especiales podrían tener responsabilidades limitadas de aquellas que corresponden a un administrador de seguridad.
Luego de decidir quien administrará la seguridad del sistema, se debe desarrollar una política de seguridad para cada base de datos. Una política de seguridad de base de datos debería incluir muchas sub-políticas, como se explica en las siguientes secciones.
3.1.1 Mantenimiento de usuarios de bases de datos
La seguridad debería ser mantenida por el mantenimiento de los usuarios de bases de datos. Dependiendo del tamaño de un sistema de bases de datos y de la cantidad del trabajo requerido para administrar los usuarios de bases de datos, el administrador de seguridad debería ser el único usuario con los privilegios requeridos para crear, alterar o borrar un usuario de base de datos. Por otro lado, debería haber un número de administradores con privilegios para administrar los usuarios de bases de datos. Solo personas que gozan de confianza deberían tener privilegios totales para administrar los usuarios de bases de datos.
3.1.2 Autentificación de usuarios
Los usuarios de bases de datos pueden ser autentificados (verificados como una persona correcta) por Oracle usando el sistema operativo de host, los servicios de red, o la base de datos. Generalmente la autentificación de usuarios vía un sistema operativo host es preferida por las siguientes razones:
- Los usuarios pueden conectarse a Oracle más rápido y más convenientemente sin especificar nombre de usuario y contraseña.
- Control centralizado sobre la autorización de usuarios en el sistema operativo: Oracle no necesita almacenar o administrar los nombres de usuario y contraseñas si el sistema operativo y la base de datos se corresponden
- Las entradas de los usuarios en los audit trails de la base de datos y el sistema operativo se corresponden
La autentificación de usuarios por la base de datos es normalmente utilizada cuando el sistema operativo no puede soportar la autentificación de usuarios.
3.1.3 Seguridad de Sistemas Operativos
Si es apropiado, los siguientes temas de seguridad deben ser considerados no sólo para un entorno de sistema operativo ejecutando Oracle sino también cualquier aplicación de bases de datos:
- Los administradores de bases de datos deben tener los privilegios del sistema operativo para crear o eliminar archivos.
- Los usuarios típicos de bases de datos no deberían tener los privilegios del sistema operativo para crear o eliminar archivos relacionados a la base de datos.
- Si el sistema operativo identifica el rol de bases de datos para los usuarios, los administradores de seguridad deben tener los privilegios del sistema operativo para modificar el dominio de seguridad de las cuentas del sistema operativo.
3.2 – Política de Seguridad de la Información
La seguridad de datos incluye los mecanismos que controlan el acceso y el uso de la base de datos en el nivel de objeto. Su política de seguridad de datos determina que usuarios tienen acceso a objetos de esquema específicos, y los tipos específicos de acciones permitidos para cada usuario sobre el objeto. También debería definir las acciones, para cualquiera, que sea auditado para cada objeto de esquema.
De cualquier forma, la seguridad de los datos debería estar basada sobre la sensibilidad de los datos. Si la información no es sensible, entonces la política de seguridad de datos puede ser mas flexible. Sin embargo, si los datos son sensibles, una política de seguridad debe ser desarrollada para mantener un fuerte control sobre el acceso a los objetos.
3.3 – Política de Seguridad de Usuarios
Esta sección describe los aspectos de una política de seguridad de usuarios e incluye los siguientes temas:
- Seguridad del Usuario General
- Seguridad de Usuario-Final
- Seguridad de Administrador
- Seguridad de Desarrollador de Aplicaciones
- Seguridad de Administrador de Aplicaciones
3.3.1 Seguridad del Usuario General
Para todos los tipos de usuarios de base de datos, considere los siguientes temas de seguridad de usuario general:
- Seguridad por contraseña
- Administración de privilegios
3.3.1.1 Seguridad por contraseña
Si la autentificación de usuarios es administrada por la base de datos, los administradores de seguridad deberían desarrollar una política de seguridad por contraseña para mantener la seguridad de acceso a la base de datos. Por ejemplo, los usuarios de base de datos deberían ser advertidos de cambiar su contraseña cada cierto período regular, y por supuesto, cuando sus contraseñas son reveladas a otros. Forzando a un usuario a modificar su contraseña en tales situaciones, los accesos a bases de datos sin autorización pueden ser reducidos.
Para proteger mejor la confidencialidad de su contraseña, Oracle puede ser configurado para utilizar contraseñas encriptadas para conexiones cliente/servidor y servidor/servidor.
3.3.1.2 Administración de privilegios
Los administradores de seguridad deben considerar los temas relacionados a la administración de privilegios para todos los tipos de usuarios. Por ejemplo, en una base de datos con muchos usuarios, podría ser beneficioso utilizar roles para administrar los privilegios disponibles a usuarios. Por otro lado, en una base de datos con un número de usuarios reducido, podría ser mas fácil otorgar privilegios explícitamente a los usuarios y anular el uso de roles.
Los administradores de seguridad que administran una base de datos con muchos usuarios, aplicaciones u objetos deberían tomar ventaja de los beneficios ofrecidos por los roles. Los roles simplifican en gran medida la tarea de la administración de privilegios en entornos complejos.
3.3.2 Seguridad de Usuario-Final
Los administradores de la seguridad deben definir también una política para la seguridad de usuario-final. Si una base de datos es grande y con muchos usuarios, el administrador de seguridad puede decidir que grupos de usuarios pueden ser categorizados, crear roles de usuarios para esos grupos de usuarios, otorgar los privilegios necesarios o roles de aplicación para cada rol de usuario, y asignar los roles de usuarios a los usuarios. En excepciones, el administrador de seguridad debe también decidir que privilegios deben ser explícitamente otorgados a usuarios individuales.
Cuando es posible, utilizar roles en todas las situaciones posibles para crear privilegios usuario-final hacen su administración eficiente y simple.
3.3.3 Seguridad de Administrador
Los administradores de seguridad deben tener una política de seguridad de administrador. Por ejemplo, cuando es una gran base de datos y existen diversos tipos de administradores de base de datos, el administrador de seguridad debe decidir como agrupar los privilegios administrativos relacionados a los diversos roles administrativos.
Los roles administrativos pueden entonces ser otorgados a los usuarios administradores apropiados. Por otro lado, cuando la base de datos es pequeña y tiene pocos administradores puede ser más conveniente crear un rol administrativo y otorgarlo a todos los administradores.
3.3.3.1 Protección para conexiones SYS y SYSTEM
Luego de la creación de la base de datos, inmediatamente cambie la contraseña para los nombres de usuario administrativos SYS y SYSTEM para prevenir accesos no autorizados a la base de datos. Conectarse como SYS y SYSTEM da al usuario todos los privilegios para modificar la base de datos de distintas formas. Por lo tanto, los privilegios para estos nombres de usuario son extremadamente sensibles,y deben estar disponibles sólo para los administradores de bases de datos seleccionados.
3.3.3.2 Protección para conexiones Administrador
Sólo los administradores de bases de datos deben tener la capacidad para conectarse a la base de datos con los privilegios de administrador. Conectarse como SYSDBA da al usuario privilegios sin restricción para hacer cualquier cosa sobre la base de datos (tales como encender, apagar y recuperar) o los objetos dentro de la base de datos (tales como crear, eliminar, y borrar).
3.3.4 Seguridad de Desarrollador de Aplicaciones
Los administradores de seguridad deben definir una política especial de seguridad para los desarrolladores de aplicaciones que usen base de datos. Un administrador de seguridad solo puede otorgar privilegios, los necesarios para crear los objetos que necesiten los desarrolladores, a los administradores de bases de datos y ellos se encargaran de recibir los pedidos de creación de objetos de parte de los desarrolladores.
3.3.4.1 Desarrolladores de Aplicaciones y sus privilegios
Los desarrolladores de bases de datos son exclusivamente usuarios de ésta y requieren un grupo de privilegios para poder cumplir con sus trabajos. A diferencia de los usuarios finales, los desarrolladores necesitan privilegios de sistema, como por ejemplo para crear una tabla, crear un procedimiento, etc. Sin embargo, solo específicos privilegios van a otorgarse a los desarrolladores, asi se podrá restringir sus accesos en la base de datos.
3.3.4.2 Desarrollo de Aplicaciones Libres vs. Desarrollo de Aplicaciones Controladas
El administrador de base de datos puede definir las siguientes opciones cuando determine que privilegios deben ser otorgados a los desarrolladores:
Libre Desarrollo Un desarrollador de aplicaciones esta autorizado a crear nuevos esquemas de objetos, incluyendo tablas, índices, procedimientos, paquetes, etc. Esta opción permite desarrollar una aplicación independiente de los otros objetos.
Desarrollo Controlado Un desarrollador no está autorizado a crear nuevos esquemas de objetos. Todas las tablas, índices, procedimientos, etc., requeridos son creados por el administrador de base de datos, por un pedido del desarrollador. Esta opción permite al administrador de base de datos tener completamente controlado el espacio usado de la misma y el camino de acceso a la información en ella.
No obstante, algunos sistemas de base de datos usan solo una de esas opciones, otros sistemas pueden combinar esas opciones. Por ejemplo, los desarrolladores pueden ser autorizados para crear nuevos procedimientos y paquetes almacenados, pero no están autorizados para crear tablas o índices.
Para que un administrador de seguridad tome alguna decisión con respecto a este tema debe basarse en lo siguiente:
- El control deseado sobre el espacio a utilizar de la base de datos
- El control deseado sobre las rutas de acceso a los esquemas de los objetos
- La base de datos usada para desarrollar aplicaciones, si una base de datos de prueba es usada para el desarrollo de aplicaciones, una política más liberal de desarrollo será implementada.
3.3.4.3 Roles y privilegios para los desarrolladores
Los administradores de seguridad pueden crear roles para manejar los privilegios requeridos por los desarrolladores. Por ejemplo, el típico rol llamado APPLICATION_DEVELOPER puede incluir los privilegios de sistemas para utilizar CREATE TABLE, CREATE VIEW y CREATE PROCEDURE.
Los administradores de seguridad considerarán lo siguiente cuando definan roles para los desarrolladores:
- Los privilegios de sistema para utilizar CREATE son usualmente otorgados a los desarrolladores, entonces ellos pueden crear sus propios objetos. Sin embargo, CREATE ANY, el cual permite al usuario crear un objeto en cualquier campo de acción del usuario, no es usualmente otorgado a los desarrolladores. Esto restringe la creación de nuevos objetos sólo para las cuentas de usuario de los desarrolladores.
- Es poco frecuente asignar privilegios sobre objetos a los roles usados por los desarrolladores de aplicaciones. Es impráctico, esto restringe sus posibilidades de uso en la creación de otros objetos. Es más práctico permitir a los desarrolladores crear sus propios objetos para propósitos de desarrollo.
3.3.4.4 Restricciones de Espacio impuestas sobre los desarrolladores
Como el privilegio de crear objetos, que se le otorga a los desarrolladores, forma parte del proceso de desarrollo de aplicaciones, los administradores de seguridad deben controlar cual y cuanto espacio va a ser usado por cada desarrollador en la base de datos. Por ejemplo, como un administrador de seguridad, debería fijar o restringir los siguientes límites para cada desarrollador:
- El Tablespace en los cuales los desarrolladores pueden crear tablas o índices.
- La quota por cada Tablespace accesible por los desarrolladores.
3.3.5 Seguridad de Administrador de Aplicaciones
En grandes sistemas de bases de datos con muchas aplicaciones (por ejemplo, precompiladores y aplicaciones de formularios) podría tener un administrador de aplicaciones. Este es responsable de los siguientes tipos de tareas:
- Creación de roles para aplicaciones y manejo de privilegios para cada rol de las aplicaciones.
- Creación y manejo de objetos usados por una aplicación en la base de datos.
- Mantenimiento y actualización del código de las aplicaciones y de los procedimientos de Oracle.
Frecuentemente, un administrador de aplicaciones es también el desarrollador que diseñó dicha aplicación. Sin embargo, esos trabajos pueden no ser las responsabilidades del desarrollador y se le asignará a otro individuo familiarizado con la aplicación de la base de datos.
3.4 – Política administrativa de Passwords
La seguridad de los sistemas de base de datos depende de no divulgar las passwords en ningún momento. No obstante, son vulnerables al robo, falsificación y abuso. Para permitir un mayor control en la seguridad sobre las bases de datos, la política administrativa de passwords de Oracle es controlada por DBAs.
Esta sección describe los siguientes aspectos de la administración de passwords en Oracle:
- Cierre de cuenta
- Expiración de las passwords
- Verificación en la complejidad de passwords
3.4.1 Cierre de Cuenta
Cuando un usuario excede un determinado número de intentos de accesos fallidos, el server automáticamente cierra la cuenta del usuario. DBA especifica el número permitido de accesos fallidos usando la sentencia CREATE PROFILE. También especifica el período de tiempo que la cuenta quedará cerrada.
Si el DBA no especifica el tiempo que tardará en habilitarse la cuenta nuevamente, el sistema toma un tiempo por default; y si el tiempo estipulado es ilimitado, el encargado del sistema de seguridad deberá directamente habilitar la cuenta. De esta manera, el período de tiempo que una cuenta permanece cerrada depende de cómo la DBA configura los recursos asignados al usuario.
El encargado de seguridad también puede directamente cerrar cuentas de usuarios. Cuando esto ocurre sólo el encargado de seguridad puede habilitarla nuevamente.
3.4.2 Expiración de las passwords
El DBA usa la sentencia CREATE PROFILE para especificar un máximo de tiempo de vida de las passwords. Pasado este tiempo la password expira y el usuario deberá cambiarla. También puede especificar un período de gracia usando la misma sentencia.
Los usuarios ingresarán el período de gracia sobre el primer intento de login, a una cuenta de la base de datos, después de que su password haya expirado. Durante el período de gracia, aparecerá un mensaje de advertencia cada vez que el usuario intente entrar en su cuenta, y continuará apareciendo hasta que expire el período de gracia. Si la password no es modificada dentro de dicho período, la cuenta expirará y ningún intento de acceso será permitido hasta que no se modifique la password.
El encargado de la seguridad puede también expirar directamente la cuenta. Esto es particularmente útil para generar nuevas cuentas.
3.4.3 Verificación en la complejidad de passwords
La rutina de verificación de complejidad de passwords en Oracle puede ser especificada usando PL/SQL script, el cual fija los parámetros de default.
La rutina de verificación de la complejidad de las passwords representa los siguientes puntos:
- La password tiene una longitud mínima de 4 posiciones
- Debe ser distinta que el userid
- Tiene al menos un número, una letra y un punto
- No usar palabras simples tales como welcome, account, database o user
- La password actual difiere de la password anterior al menos en 3 letras
Oracle recomienda no cambiar las passwords usando la sentencia ALTER USER porque no soporta enteramente la función de verificación de passwords. En cambio, si podría usar las herramientas que provee Oracle como SQL*Plus o Enterprise Manager para cambiar las passwords.
DBA puede mejorar las rutinas de verificación de complejidad de las passwords o crear sus propias rutinas de verificación de passwords usando PL/SQL.
3.5 – La Política de Auditoria
Los administradores de Seguridad deben establecer una política para el procedimiento de auditoria de cada base de datos. Cuando es necesaria una auditoria el administrador de seguridad debe decidir a que nivel de detalle se realizará la auditoría de la base de datos.
Una vez detectado alguna actividad de origen sospechosa a través del sistema general de auditoria, se realizará una auditoría más especifica.
4. Trusted ORACLE
Trusted Oracle es un sistema de administración de la seguridad de bases de datos. Fue diseñado para proveer el más alto nivel de capacidades para la administración de la seguridad requerido por organizaciones que procesan información sensitiva. Trusted Oracle es compatible con todos los productos Oracle.
Además, Trusted Oracle implementa Mandatory Access Control (MAC) (control de acceso obligatorio). Mandatory Access Control es un medio para restringir el acceso a la información basado en etiquetas o rótulos. La etiqueta de un usuario indica a qué información le está permitido acceder a un usuario y con qué tipo de acceso (lectura o escritura). La etiqueta de un objeto indica la sensibilidad de la información que el objeto contiene.
5. Copia de seguridad y recuperación de la base de datos
En cada sistema de base de datos siempre existe la posibilidad de una falla del sistema o de hardware. Si una falla ocurre y afecta la base de datos esta debe ser recuperada.
Los objetivos después de la falla son asegurar que los efectos de todas las transacciones realizadas se reflejen en la base de datos recuperada y retornar a la operación normal tan rápido como sea posible mientras se aísla a los usuarios.
5.1 – Tipos de falla
Varias circunstancias pueden detener la operación de una base de datos Oracle.
Los tipos de falla más comunes son:
5.1.1 Errores de usuario
Los errores de usuario pueden requerir, para ser recuperados, de una base de datos en un punto anterior en el tiempo al que ocurrió el error.
Para permitir la recuperación a partir de los errores de usuario y acomodar otros requisitos únicos de recuperación, Oracle provee una recuperación exacta en el tiempo.
5.1.2 Fallas de sentencias y procesos
Las fallas de sentencias ocurren cuando hay una falla lógica en el manejo de una sentencia en un programa Oracle.
Cuando ocurre una falla de sentencia los efectos de las sentencias se deshacen automáticamente por Oracle y se devuelve el control al usuario.
Una falla de proceso es una falla en un proceso de usuario accediendo a Oracle, tales como una desconexión o finalización de un proceso en forma anormal.
El proceso de usuario fallido no puede continuar trabajando, aunque Oracle y otro proceso de usuario puedan. El proceso subordinado de Oracle PMON detecta automáticamente los procesos de usuario fallidos o es informado de este hecho por SQL * Net. PMON resuelve el problema realizando una regresión de las transacciones realizadas y liberando los recursos que estaban tomados por el proceso fallido.
5.1.3 Falla de una copia de programa en memoria
Una falla de una copia de programa en memoria puede resultar por un problema de hardware como la salida de energía o un problema de software como la caída del sistema operativo.
Cuando ocurre una falla de este tipo la información de los buffers del área global del sistema no se escribe en los archivos. Esta falla requiere recuperar la copia del programa en la memoria
La recuperación de la instancia se lleva a cabo automáticamente por Oracle cuando la instancia se reinicializa.
El Redo log se usa para recuperar los datos en los buffers del SGA.
5.4.1 Falla en disco
La falla en disco es un problema físico cuando se lee o escribe un archivo en disco.
La recuperación del medio restablece los archivos de la base de datos con la información correspondiente al instante más reciente antes de la falla, incluyendo la información que se perdió a causa de la falla. Se requiere lo siguiente: copia de seguridad de los archivos de la base de datos
Si algunos archivos de datos se dañan, en una falla de disco, pero la mayor parte de la base de datos esta intacta, la base de datos puede permanecer abierta mientras la "tablespaces" requeridas se recuperan individualmente.
Por consiguiente las porciones no dañadas de una base de datos están disponibles para su uso normal mientras se recuperan las porciones dañadas
5.2 – Estructuras utilizadas para la recuperación
Oracle utiliza diversas estructuras para proveer una recuperación completa a causa de una falla de una copia del programa en memoria del disco: el redo log, segmentos de rollbak, un archivo de control y copia de seguridad de la base de datos necesarias.
5.2.1 El Redo Log
El Redo Log es un conjunto de archivos que protegen la información de la base de datos alterada que aún no ha sido escrita en los archivos.
El Redo Log puede consistir en 2 partes:
Registra todos los cambios hechos a la base de datos. Cuando se envía una transacción a la base de datos, se guarda en forma temporal la entrada correspondiente del Redo log en los buffers del SGA, que luego el proceso subordinado LGWR escribe en un archivo Redo log en línea.
- El Redo Log en línea (online)
- El Redo Log almacenado (offline)
Se almacenan mediante archivos.
Los archivos de control de una base de datos mantienen, entre otras cosas información sobre la estructura de los archivos de una base de datos y el número de secuencia del log actual que esta siendo escrito por LGWR.
Durante los procedimientos normales de recuperación.
- Archivos de control
- Segmentos de regresión (rollback segments)
Los segmentos de regresión graban información usada por distintas funciones de Oracle.
Durante la recuperación de la base de datos, después que todos los cambios grabados en el Redo log han sido aplicados. Oracle utiliza información de los segmentos rollback para deshacer cualquier transacción realizada. Debido a que los segmentos rollback se almacenan en los buffers de la base de datos, esta importante información de recuperación es automáticamente protegida por el redo log.
5.2.4 Copias de Seguridad de la Base de Datos
Debido a que uno o más archivos pueden ser físicamente dañados como consecuencia de una falla del disco, la recuperación del medio requiere restauración de los archivos dañados desde el backup mas reciente.
Hay varias formas de hacer copias de seguridad de los archivos de una base de datos:
5.2.4.1 Copia de seguridad completa de una base de datos
Es una copia de seguridad de todos los archivos de datos, archivos redo log en línea, y el archivo de control.
Las copias de seguridad completas se realizan cuando se cierra la base de datos y queda inhabilitada para su uso.
- Copias de seguridad parciales
Es una copia de una parte de la base datos. La copia de seguridad de un tablespace individual o la copia de seguridad de un archivo de control son ejemplos de backups parciales.
5.3 – Pasos básicos de recuperación
Debido a la forma en que la información de los buffers se graba en los archivos puede ocurrir que en un momento dado:
- un archivo contenga datos modificados por transacciones no ejecutadas
- un archivo no contenga algunos datos modificados por transacciones ejecutadas.
Para solucionar esta situación, Oracle siempre utiliza dos pasos separados durante la recuperación de una falla de un medio o una falla de una copia de un programa en memoria:
5.3.1 Avance (Rolling Forward)
Consiste en aplicar a los archivos de datos todos los cambios grabados en el Redo Log, llevando (adelantando) los archivos de datos al punto de tiempo requerido.
Si todo la información del Redo Log está en línea, Oracle ejecuta este paso de recuperación de manera automáticamente se inicia la base de datos. Después de realizado este paso los archivos de datos contienen todos los cambios realizados por transacciones ejecutados y por transacciones no ejecutadas, grabados en el Redo Log.
5.3.2 Retroceso (Rolling Back)
Se utilizan los segmentos de retroceso (Rollback Segments) para identificar las transacciones que nunca se ejecutaron, pero que están grabadas en el Redo Log. Oracle realiza este paso automáticamente.
5.4 – El administrador de la Recuperación
Es una herramienta de Oracle que lleva a cabo las operaciones referidas a las copias de seguridad y a la recuperación de la base de datos.
Este mantiene un catálogo de recuperación, el cual contiene información sobre las copias de seguridad de archivos y de los Redo Logs offline.
Manual de Oracle 8 Server
De Brito, Cynthia
Diz Marín, María Paula
Pineda, Gabriel
Tripi, Hernán
Yagi, Marisa
U.T.N-Facultad Regional Buenos Aires-
Ingeniería en sistemas de información
Seguridad Informática
| Página siguiente |