La recuperabilidad significa que, si se da algún error en los datos, hay un bug de programa ó de hardware, el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el daño se causara. Las actividades de recuperación incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de daño ó pérdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del área en antelación a un desastre anticipado. La recuperación es una de las tareas más importantes de los DBA's.
La recuperabilidad, frecuentemente denominada "recuperación de desastres", tiene dos formas primarias. La primera son los respaldos y después las pruebas de recuperación.
La recuperación de las bases de datos consisten en información y estampas de tiempo junto con bitácoras los cuales se cambian de manera tal que sean consistentes en un momento y fecha en particular. Es posible hacer respaldos de la base de datos que no incluyan las estampas de tiempo y las bitácoras, la diferencia reside en que el DBA debe sacar de línea la base de datos en caso de llevar a cabo una recuperación.
Las pruebas de recuperación consisten en la restauración de los datos, después se aplican las bitácoras a esos datos para restaurar la base de datos y llevarla a un estado consistente en un tiempo y momento determinados. Alternativamente se puede restaurar una base de datos que se encuentra fuera de línea sustituyendo con una copia de la base de datos.
Si el DBA (o el administrador) intentan implementar un plan de recuperación de bases de datos sin pruebas de recuperación, no existe la certeza de que los respaldos sean del todo válidos. En la práctica, los respaldos de la mayoría de los RDBMSs son raramente válidos si no se hacen pruebas exhaustivas que aseguren que no ha habido errores humanos ó bugs que pudieran haber corrompido los respaldos.
La integridad de una base de datos significa que, la base de datos ó los programas que generaron su contenido, incorporen métodos que aseguren que el contenido de los datos del sistema no se rompan así como las reglas del negocio. Por ejemplo, un distribuidor puede tener una regla la cual permita que solo los clientes individuales puedan solicitar órdenes; a su vez cada orden identifique a uno y solo un proveedor. El servidor Oracle y otros DBMSs relacionales hacen cumplir este tipo de reglas del negocio con limitantes, las cuales pueden ser configuradas implícitamente a través de consultas. Para continuar con este ejemplo, en el proceso de inserción de una nueva orden a la base de datos, esta a su vez tendría que cerciorarse de que el cliente identificado existen en su tabla para que la orden pueda darse.
No hay comentarios:
Publicar un comentario