Documentos de Académico
Documentos de Profesional
Documentos de Cultura
SQL Modulo 7
SQL Modulo 7
Recuperación de Desastres
○ Recupero de Desastres en SQL Server 2005
○ Uso de Snapshots de la Base de Datos
○ Backup y Recuperación
Introducción
El recupero de Desastres un proceso de restauración del sistema y recupero luego que ha sucedido un
desastre. Un desastre puede ser cualquier cosa causada por un error de un usuario (como un
administrador que borra una tabla) o una falla de hardware (como la falla de un disco) todo el camino
a un colapso catastrófico de la infraestructura y el hardware donde se aloja la base de datos, quizás
como resultado de un terremoto, incendio o acto de terrorismo.
El SQL Server 2005 continua soportando clustering, backup y restauración, y log shipping como
mecanismo de desastre-recupero. También suma un número de mejoras a las features disponibles en
las versiones anteriores.
! Snapshots de Base de Datos. Un snapshot de base de datos es una copia de solo lectura de la base de
datos hecha en un momento en particular. Los usuarios pueden consultar el snapshot de la base de
datos en la misma manera en la que consultarían la base de datos. Una snapshot de la base de datos
puede ser usada para restaurar los datos y agregarla devuelta en la base de datos original rápida y
fácilmente. Para una descripción mas detallada de snapshots de bases de datos, vea Using Database
Snapshots mas tarde en este modulo.
!Operaciones Online. En SQL Server 2005, puede restaurar paginas dañadas y archivos
comprimiendo una base de datos mientras que la base de datos esta online y otro usuario esta
accediendo a partes de la base de datos no dañada. Para un descripción mas detallada de cómo realizar
una restauración online, vea Backup and Restore Operations mas tarde en este modulo.
!Backup media mirroring. El SQL Server 2005 permite hacer mirror backup media, incrementando la
confiabilidad reduciendo los efectos de una mala función de los dispositivos de backup. Backup
mirroring puede ser usado con dispositivos de disco o cinta (todos los dispositivos formando un mirror
set deben ser del mismo tipo) El backup fallara si algún dispositivo en el mirror set no esta disponible
o no se encuentra. Sin embargo, las operaciones de restauración solo requieren de un solo dispositivo
en cada mirror set para tener éxito. Para una descripción mas detallada de backup media mirroring,
vea .Backup
and Restore Operations mas tarde en este modulo.
Introducción
Los snapshots de la base de datos proveen la capacidad para los administradores de generar y usar una
base de datos de solo lectura y vista estable. Una snapshot de la base de datos puede ser usada para
recuperar datos perdidos por un cambio accidental hecho a la base de datos.
Esta sección describe los snapshots de la base de datos y discute su uso como un herramienta para
asistir en un recupero de desastre.
Objetivos
Introducción
Mientras que el mirroring provee soporte continuo, hay muchos escenarios en los cuales un simple
snapshot de la base de datos es útil como una base de datos en standby, como un test o una base de
datos en desarrollo o simplemente como una base de datos de reporte.
Definición
Un snapshot de base de datos es una vista de la base de datos como solo lectura, consistente en un
punto especifico de tiempo.
Modificar Datos
SQL Server 2005 usa tecnología copy-on-write para implementar los snapshots de la base de datos sin
incurrir en crear una copia completa de la base de datos. Una snapshot de la base de datos, empleando
archivos separados NTFS para alojar espacio físico en el disco solo cuando es requerido. Cuando una
página en la fuente de la base de datos es actualizada por primera vez, la imagen original de esa página
es copiada a la snapshot de la base de datos. (Actualizaciones subsiguientes de la misma página no
incurren en copias adicionales sobre la misma.) Si una página no es nunca modificada, no es nunca
copiada.
Nota
Si borra un archivo de la fuente de la base de datos, el contenido completo de la base de datos será
copiado al snapshot de la base de datos.
Lectura de Datos
un usuario que accede a la snapshot de la base de datos vera una copia de la página en la snapshot solo
si la pagina ha sido modificada desde que la snapshot ha sido creada. De todas formas, el usuario es
redireccionado a la página correspondiente en la fuente de la base de datos. Esta redirección es
transparente para el usuario.
Crear un Snapshot
Crea una snapshot de base de datos usando el comando CREATE DATABASE con la cláusula AS
SNAPSHOT, como muestra el siguiente ejemplo:
CREATE DATABASE database_snapshot_name
ON <filespec>[,...n]
AS SNAPSHOT OF source_database_name
El siguiente código muestra como crear una snapshot de la base de datos AdventureWorks
en la carpeta C:\SnapshotData:
La snapshot debe ser creada en la misma instancia de SQL Server que la de la fuente de la base de
datos, y la carpeta de destino debe existir. Adicionalmente, la cláusula ON debe incluir un archivo
para cada fila de datos usado en la fuente de la base de datos, Aunque no debería especificar los
parámetros SIZE, MAXSIZE, o FILEGROWTH.
Nota
La cláusula filespec no puede incluir la palabra clave PRIMARY o especificar una lista de grupos de
archivo.
Crear una snapshot crea una vista de la base de datos en el tiempo en curso. Puede usar el SQL Server
Agent para agendar tareas que crean snapshots en un tiempo determinado. Una base de datos puede
tener múltiples snapshots. Por lo tanto es recomendado que usted adopte una conversión de nombre
para una snapshots de base de datos que incluye el tiempo en que la snapshot fue creada. Por ejemplo,
AdventureWorks_dbsnapshot_1800 indica que una snapshot fue creada a las t 6:00 P.M.
En una base de datos que cambia frecuentemente, los archivos snapshot pueden agrandarse
rápidamente, así que es recomendado que si agenda la creación de snapshot, también agende trabajos
de borrado de las versiones anteriores de la snapshot.
Tip
Puede descubrir la fuente de la base de datos para una consulta de la snapshot de base de datos
consultando la vista de catálogos sys.databases y examinar la columna source_database_id.
Use el comando DROP DATABASE para borrar una snapshot y tener el espacio en disco que esta
ocupo:
Restricciones
Introducción
Puede usar una snapshot de base de datos para recuperar datos de un cambio accidental a la base de
datos aplicando los datos de la snapshot de base de datos a la fuente de la base de datos. Sin embargo,
debe tener en cuenta que la snapshot de la base de datos provee un mecanismo de recuperación de
peso pequeño que no debería ser usado como un sustituto para implementar un backup comprensivo y
recuperación estratégica.
Escenarios Aplicables
Una variedad de situaciones puede terminar en la pérdida de datos, desde borrar algo por accidente de
una tabla o modificación de una simple row hasta corrupción o pérdida del archivo de la base de datos.
La naturaleza de la snapshot de la base de datos la hace ideal para recuperar desde una aplicación
hasta un error de un usuario que pueden borrar una row o una actualización por accidente, o borrar una
tabla. Restaurar datos de una snapshot de base de datos es más rápido y fácil que realizar una
operación de restauración desde una base de datos de backup. Sin embargo, el mecanismo copy-on-
write previene la snapshots de la base de datos de recuperar una base de datos sospechosa de
comprimir archivos corruptos de base de datos, esto requiere restaurar los archivos faltantes de la base
de datos desde un backup. También debe notar que solo puede recuperar cambios hechos al punto en
el cual la snapshot fue tomada. Recuperar los cambio subsecuentes requiere restaurar la base de datos
desde un y luego ir hacia delante usando las transacciones mas recientes de log backups. Los
siguientes escenarios son ejemplos de cuando usar una snapshot de base de datos para propósitos de
recuperación.
Importante
Debe recordad que estos tipos de statement de recuperación, solo recuperan los datos que usted
especifica explícitamente, y cuando restaura datos usando estos métodos, cualquier otra modificación
hecha a los datos en el periodo subsecuentes era perdido.
Puede recuperar rows borradas de una tabla copiándolas desde la snapshot correspondiente. Por
ejemplo, un nombre de usuario Fred ha reportado que todas las rows en la tabla
Production.WorkOrderRouting en la base de datos AdventureWorks han desaparecido. Puede
restaurar las rows perdidas de la base de datos AdventureWorks_dbsnapshot_1800 usando la
statements como muestra el siguiente ejemplo:
Es de práctica común desafiliar cualquier restricción cuando se copia un número grande de rows
dentro de una tabla, para propósitos de performance. En otros casos, puede ser necesario deshabilitar
restricciones temporalmente para prevenir que los datos sean rechazados cuando son reaplicados.
Puede usar técnicas similares para copiar datos de una snapshot para deshacer cambios hechos a las
rows seleccionadas. Fred ahora ha reportado que por error cambio el nombre del departamento 1 en la
tabla HumanResources.Department, pero no puede recordar que valor tenía antes, así que no pudo
chequearlo otra vez. Puede corregir el error usando el siguiente statement:
UPDATE HumanResources.Department
SET Name = (
SELECT Name
FROM
AdventureWorks_dbsnapshot_1800.HumanResources.Department
WHERE DepartmentID = 1)
WHERE DepartmentID = 1
Introducción
Las tareas de backup y restauración de una base de datos, son temas fundamentales con los cuales un
administrador debe estar familiarizado para implementar una estrategia de recupero de desastre. Esta
sección describe como realizar las operaciones de backup y restauración usando las nuevas features en
SQL Server 2005.
Objetivos
Introducción
El SQL Server 2005 introduce cambios a la statement BACKUP. Ya no soporta las opciones
BACKUP LOG WITH NO_LOG y BACKUP LOG WITH TRUNCATE_ONLY, que antes te
permitían remover y truncar una porción inactiva de un log sin tener que hacer una copia de el.
Nota
Los llamados dispositivos pipe backup no son soportados en SQL Server 2005; solo puede crear un
dispositivo de disco o cinta.
Puede realizar un backups de una base de datos usando el cuadro de dialogo Backup Database en
SQL Server Management Studio.
1. Conéctese a una instancia de SQL Server.
2. En Object Explorer, expanda la instancia relevante, luego expanda System Databases o User
Databases, dependiendo el tipo de base de datos de la quería hacer el backup.
3. Haga botón derecho sobre la base de datos, posiciones sobre Tasks, y luego haga click en Back
Up.
4. Especifique los requerimientos en las paginas General y Options, y luego haga click en OK.
Backups completes de la base de datos y backups diferenciales en SQL Server 2005 contienen una
imagen full de los datos como también suficiente información de logs para asegurar una recuperación
consistente luego del proceso de restauración. Si algunas transacciones están en proceso cuando el
backup es hecho, el backup incluye pasos de log para alcanzar un estado consistente.
Backup Parcial
Backups completos y diferenciales también soportan un nuevo tipo de backup, el backup parcial. Esto
es diseñado para primariamente para permitir restaurar de un modelo simple de base de datos, pero
puede ser usado para recuperacion completa o bulk-logged de modelos de base de datos, también. Un
backup parcial también incluye todos los datos en cualquier grupo de archivos lectura/escrituray en
cualquier grupo de archivos específicamente mencionado. Para una base de datos de solo lectura, esto
es igual que solo para el grupo de archivos principal. Un backup parcial diferencial hace relación a un
backup parcial en el mismo modo que un backup completo diferencial hace referencia a un backup
completo de la base de datos.
Use la opción READ_WRITE_FILEGROUPS de la statement BACKUP para crear un backup
parcial, como muestra el siguiente ejemplo:
Backups Copy-only
El SQL Server 2005 incluye una nueva opción de statement BACKUP que le permite hacer una copia
de la base de datos para un propósito especifico, por ejemplo, testear sin alterar la secuencia normal
de sus log backups diferencial y transaccional.
Use la opción COPY_ONLY para crear datos o log backup que es independiente de los otros backups
de una base de datos específica, como muestra el siguiente ejemplo de código:
Si usa la opción COPY_ONLY en una statement BACKUP LOG, el log no es truncado y el backup
no es incluido en la secuencia de logs para ser aplicada a la base de datos durante el proceso de
restauración.
Introducción
Puede implementar operaciones de restauración offline en SQL Server 2005 usando la statement
RESTORE en casi la misma forma que en las versiones anteriores. Puede usar también el SQL Server
Management Studio para restaurar la base de datos y logs. La statement RESTORE contiene una
nueva opción, RESTRICTED_USER. Esta restringe el acceso a la base de datos recuperada a los
miembros de los roles db_owner, dbcreator, o sysadmin. Esto reemplaza la opción DBO_ONLY
del SQL Server 2000, que solo esta disponible para compatibilidad retrazada. Puede restaurar solo
backups de bases de datos creadas en SQL Server 7.0, SQL Server 2000, y SQL Server 2005.
Nota
No puede restaurar una base de datos que tiene un snapshot basada en ella.
Recuperacion Point-in-time
En versiones anteriores de SQL Server, puede usar la opción STOPAT para restaurar un log en un
punto específico en el tiempo. En SQL Server 2005, esta funcionalidad también ha sido agregada a la
statement RESTORE DATABASE. Por ejemplo, el siguiente código restaura la base de datos
AdventureWorks a su estado a las 2:00 p.m. del 1ro de Marzo del dispositivo de backup AWBackup.
Mientras ejecuta una operación de backup parcial para hacer backup del grupo de archivos principal,
otros grupos de archivos read/write, y otros grupos read-only específicos, también puede ejecutar una
restauración parcial de los mismos ítems. Usualmente, un proceso de restauración es requerido por un
error en una parte aislada de la base de datos; por ejemplo, una tabla que se borro por accidente. En
este escenario, puede ejecutar una restauración parcial del grupo de archivos primarios y los grupos de
archivos que contienen la tabla especifica a una locacion secundaria, y luego copiar la tabla y sus
contenidos a la locacion original de la cual fueron borradas. Las restauraciones parciales también
pueden ser útiles para crear subsets de datos con servidores no conectados. El siguiente código
muestra como ejecutará una restauración parcial de AWBackup a una nueva base de datos llamada
AWTemp:
Aparte de poder restaurar una base de datos completa, uno o mas grupos de archivos, o uno o mas
archivos, ahora puede restaurar paginas individuales cuando usa los modelos de recuperacion
completa o bulk-logged. Esto puede reducir ampliamente el tiempo requerido para una operación de
restauración, por lo tanto reduce el tiempo que la base de datos esta offline. Restauración Page-level
es también una técnica particular para restaurar páginas dañadas aisladas. Si tiene que restaurar
múltiples paginas en el mismo archivo, debería usar restaurar el archivo. Use la opción PAGE en la
cláusula file_or_filegroup para la statement RESTORE DATABASE para realizar una restauración
page-level:
Esto requiere que especifique el nombre de un archivo y el offset de una pagina dentro del archivo.
Puede identificar offsets de una página que contienen errores usando información hexadecimal del log
de error del suspect_page_table en msdb. Por ejemplo, el siguiente código restaurara la página
número 832 en el archivo AdventureWorks_data_1 del dispositivo de backup AWBackup:
Operaciones de Restauración
La edición de SQL Server 2005 Enterprise Edition soporta el concepto de restauración piecemeal, que
le permite restaurar grupos de archivos en stages, trayendo a cada grupo online mientras avanza.
Puede usar este método para reducir en gran medida el tiempo total en el cual la base de datos esta
siendo restaurada, solo restaurando los archivos dañados,
restáurelos por orden de importancia, y ponga cada grupo de archivos online lo antes posible. El
comportamiento de la restauración piecemeal varía dependiendo del modelo de recuperacion de su
base de datos:
! Modelos de recuperacion completa y bulk-logged.
Restauración piecemeal es valida para cualquier grupo de archivos secundario.
! Modelo de recuperacion simple.
Puedo restaurar solo grupos de archivos secundarios si ellos son de solo lectura cuando el backup fue
ejecutado y han permanecido así desde entonces. Restauración Piecemeal comienza con una
restauración parcial de algunos de los grupos de archivos primarios, y en el caso de un modelo de
recuperacion simple, los grupos de archivos read/write. Una vez que están online, puede restaurar
cualquier otro archivo dañado disponible en la base de datos.
Introducción
El SQL Server 2005 Enterprise Edition introduce un nuevo concepto de restauración online de
backups debe SQL Server 2005. Por defecto, en esta edición, una base de datos queda online mientras
que se restauran archivos o paginas individuales a una base de datos. Esto puede mejorar el tiempo de
restauración en los modelos completos y bulk-logged . (No soporta modelos de restauración simples.)
Durante la restauración de cualquier archivo o grupo de archivos, el grupo completo esta offline. Por
lo tanto, cuando esta restaurando un archivo en el grupo de archivos primarios, toda la base de datos
debe estar offline. Sin embargo, luego que el primer grupo de archivos es restaurado, la base de datos
es puesta otra vez online, y mientras los grupos de archivos secundarios son restaurados, el grupo de
archivos es puesto automáticamente online.
La restauración online asegura que la restauración de páginas dañadas aisladas tiene poco impacto
sobre el sistema completo de la base de datos. Generalmente, las páginas dañadas serán listadas en el
log de error de la base de datos. Por ejemplo, si trata de acceder a una pagina dañada, un error ocurrirá
y se hará una entrada en el log de error. Puede usar esta información para localizar la página
individual y restaurarla de un backup valido.
Confiabilidad Media
Introducción
Más allá de su estrategia de restauración, sus datos aun pueden estar en peligro por errores que pueden
ocurrir en su backup media. El SQL Server 2005 incluye funcionalidades que lo alertan de errores
durante los procesos de backup y restauración, permitiéndole restaurar los datos mas allá de los
errores que pueden ocurrir y reduciendo la posibilidad de errores de media impactando sus trabajos.
Puede usar la opción CHECKSUM de la statement BACKUP para calcular una checksum en cada
página de datos y verificar esta checksum antes de escribir la información a su backup media. Esto le
ayudara a asegurarse que solo datos validos serán escritos cuando haga el backup de archivos. El
siguiente ejemplo de código muestra como usar la opción CHECKSUM:
Por defecto, si ocurre un error durante la creación del proceso checksum, el backup falla. Este
comportamiento puede ser evitado usando la opción CONTINUE_AFTER_ERROR escrita abajo.
Los checksums computados son escritos en el backup media. Pueden ser usados durante el proceso de
restauración para una vez mas, verificar los datos cuando son leídos del backup, antes que sea
finalizado a la base de datos restaurada. Use la opción CHECKSUM del statement RESTORE para
instruir al SQL Server a verificar los datos antes de restaurarlos, como muestra el siguiente ejemplo de
código:
Nota
Debe usar la opción CHECKSUM con cuidado, puede producir efectos adversos a su sistema de base
de datos.
El SQL Server 2005 incrementa el potencial de restauración de sus datos a través del uso de un
backup media mirroring. Este método resulta en dos locaciones del mismo tipo de media almacenando
sus datos del backup, lo cual reduce el peligro que la media falle causando perdida de datos. El
siguiente ejemplo de código muestra como usar la opción MIRROR TO en el statement BACKUP:
Nota
Cuando usa la opción MIRROR TO, también debe incluir la opción WITH FORMAT de la
statement del BACKUP.
Cuando esta haciendo backup de datos, todos los miembros del mirror deben ser accesibles. Sin
embargo, cuando esta restaurando datos, solo un miembro necesita se accesible, haciendo una
restauración posible aunque el otro miembro este dañado.
El statement RESTORE en SQL Server 2005 incluye un nuevo punto que le permite completar una
operación de restauración completa aunque un error aparezca durante el procesos. Usando la opción
CONTINUE_AFTER_ERROR cauda al SQL Server simplemente intentar log el error y continuar
con su trabajo, como muestra el siguiente código:
Dependiendo en la naturaleza del error, este intento puede tener éxito, o fallar. Por ejemplo, si una
verificación de checksum falla, es posible que el remanente de los datos sea restaurado y sea valido y
el proceso pueda continuar. Sin embargo, si ocurre un error en una cinta, puede ser imposible que
continuara la operación de restauración, la cual entonces fallara. Si los errores ocurren, la base de
datos es marcada SUSPECT al final del proceso de restauración, permitiéndole chequear
manualmente que errores ocurrieron y que impacto habrán tenido en su base de datos.
Introducción
Si su base de datos master es dañada, puede necesitar o simplemente restaurar la base de datos o
reconstruirla completamente.
Su la base de datos master es aun accesible, podrá iniciar una instancia de SQL Server. En este
escenario, debe iniciar SQL Server en modo singleuser y luego restaurar su copia de la base de datos
master desde su más reciente backup completo de la base de datos en la manera habitual, como
describe en los siguientes pasos.
sqlservr.exe -c .m
Si hizo algún cambio a la base de datos master desde que fue hecho el backup, necesitara rehacer
manualmente esos cambios una vez que la base de datos esta restaurada y online. Por esta razón,
cuando realiza un cambio a master (por ejemplo, cambiar una configuración server-wide, o agregar o
remover bases de datos), es recomendado que ejecute un backup completo de la base de datos. Una
vez que el proceso de restauración es completado, el SQL Server es parado automáticamente. En este
punto, puede empezar SQL Server en modo single-user para hacer los cambios manuales antes de
ponerla online, o puede iniciar SQL Server para uso inmediato de clientes
Si la base de datos master es dañada severamente, puede ser que no pueda iniciar una instancia de
SQL Server. En esta situación, debería reconstruir una versión nueva entera de su base de datos
master.
Para reconstruir una base de datos master, debe correr el programa del setup de SQL Server con las
siguientes opciones:
! /qn cambia a suprimir la interfase de usuario.
! REINSTALLMODE = AMUS propiedad para reconstruir un sistema de base de datos.
! REINSTALL = ALL propiedad de setear un servidor con las features instaladas previamente. Esta
debe ser usada cuando se especifica la propiedadREINSTALLMODE.
Una vez que la reconstrucción esta completa, puede restaurar su versión original del servidor si tiene
un backup disponible siguiendo los pasos descriptos arriba. Si no tiene un backup disponible,
necesitara recrear y reconfigurar su sistema. Reconstruir el sistema de base de datos incluye
reconstruir las bases de datos msdb y model, asi que debe asegurarse que tiene copias de backup de
sus versiones para restaurar luego de reconstruir.