Download Modulo 7 Recuperación de Desastres Recupero de Desastres en

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
Recupero de Desastre en SQL Server 2005
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.
Mejoras de Desastre- Recupero
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.
!
Verificación Improvisada. Los backup y operaciones de restauración pueden realizar un chequeo de
error adicional en SQL Server 2005, incrementando la confiabilidad que una base de datos será
restaurada correctamente desde un set dado de backups. Puede opcionalmente generar checksums
cuando realiza un backup que puede ser verificado cuando los datos son restaurados El comando
RESTORE VERIFYONLY ha sido extendido para incluir información checksum cuando examina
un set de backup.
!
Uso de Snapshots de Base de Datos
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
!
Definir snapshots de base de datos.
!
!
!
Crear, alterar, y borrar snapshots de base de datos.
Usar una snapshot de base de datos para asistir en la restauración de datos luego de un desastre.
Usar snapshots de base de datos.
Qué son Snapshots de Base de Datos?
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.
Cómo Administrar Snapshots de Base de Datos
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:
CREATE DATABASE AdventureWorks_dbsnapshot_1800
ON (NAME = AdventureWorks_Data,
FILENAME = ’C:\SnapshotData\AdventureWorks_Data.mdf’)
AS SNAPSHOT OF AdventureWorks
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.
Borrar una Snapshot
Use el comando DROP DATABASE para borrar una snapshot y tener el espacio en disco que esta
ocupo:
DROP DATABASE database_snapshot_name [,...n]
El siguiente ejemplo borra la snapshot de base de datos AdventureWorks_dbsnapshot_1800, y
también borra el archivo AdventureWorks_Data de la carpeta C:\SnapshotData:
DROP DATABASE AdventureWorks_dbsnapshot_1800
Restricciones
Las siguientes restricciones se aplican a las snapshots de base de datos:
! Snapshots de base de datos no pueden ser creadas para bases de datos model, master, o tempdb.
! Snapshots de base de datos son de solo lectura; los usuarios no las pueden modificar.
! Snapshots de base de datos no pueden ser restauradas o hacerse backup.
! Snapshots de base de datos no pueden ser adjuntadas o desadjuntadas.
! Snapshots de base de datos no pueden ser creadas en FAT32 o en particiones raw.
! Catálogos Full-text no pueden ser propagados al snapshot de la base de datos, y catálogos full-text no
pueden ser creados sobre los snapshots de la base de datos.
! La ubicación física de los archivos comprimen una fuente de bases de datos no pueden ser
cambiados si la snapshots de base de datos es creada sobre la fuente de base de datos existente.
! Toda las snapshots de base de datos creadas sobre la base de datos deben ser borradas antes que la
misma base de datos sea borrada.
! Restricciones de Seguridad en objeto snapshot de base de datos no puede ser modificado.
Cómo usar una Snapshot de Base de Datos para Restaurar
Datos
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-onwrite 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.
Escenario 1: Recuperar rows
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:
ALTER TABLE Production.WorkOrderRouting
NOCHECK CONSTRAINT CK_WorkOrderRouting_ActualEndDate
INSERT INTO Production.WorkOrderRouting
SELECT *
FROM
AdventureWorks_dbsnapshot_1800.Production.WorkOrderRouting
ALTER TABLE Production.WorkOrderRouting
CHECK CONSTRAINT CK_WorkOrderRouting_ActualEndDate
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.
Escenario 2: Deshacer una Actualización
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
Escenario 3: Recuperar un Objeto Borrado
Fred ha reportado otro problema con la tabla Production.WorkOrderRouting: también ha
desaparecido. Puede reconstruir una tabla con el siguiente procedimiento.
1. Use Object Explorer en SQL Server Management Studio para script la tabla
Production.WorkOrderRouting en la base de datos AdventureWorks_dbsnapshot
_1800. Genere el script para el Query Editor.
2. Ejecute la script en la base de datos AdventureWorks. Note que dependiendo de las opciones
seleccionadas cuando genera el script, también contendrá definiciones de las restricciones de la tabla y
los triggers adjuntos a la tabla.
3. Use la técnica del escenario 1 para publicar la tabla. Puede usar la misma estrategia para recrear
cualquier objeto que haya sido borrado de la base de datos AdventureWorks, incluyendo vistas,
procesos almacenados, tipos de datos de usuarios definidos, funciones de usuarios definidos, reglas y
defaults.
Operaciones de Backup y Restauración
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
!
!
!
!
!
!
Hacer backup de una base de datos.
Restaurar una base de datos.
Realizar una restauración online.
Reducir las fallas de media que impactan el sistema de su base de datos.
Restaurar la base de datos master.
Realizar operaciones de backup y restauración.
Cambios para hacer un Backup de la Base de Datos
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.
Usar Transact-SQL para Realizar un Backup
El siguiente código muestra la sintaxis básica de las statements BACKUP DATABASE y BACKUP
LOG, sin cambios desde SQL Server 2000:
BACKUP DATABASE { database_name | @database_name_var }
TO < backup_device > [ ,...n ]
[ WITH
...
]
BACKUP LOG { database_name | @database_name_var }
TO < backup_device > [ ,...n ]
[ WITH
...
]
El argumento backup_device puede ser especificado usando o el nombre lógico de un dispositivo
predeterminado o el tipo y nombre físico de un nuevo dispositivo. El siguiente ejemplo muestra como
hacer un backup de la base de datos AdventureWorks en el dispositivo antes creado AWBackup:
BACKUP DATABASE AdventureWorks
TO AWBackup
Nota
Los llamados dispositivos pipe backup no son soportados en SQL Server 2005; solo puede crear un
dispositivo de disco o cinta.
Usar SQL Server Management Studio para Realizar un Backup
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 de Datos y Diferenciales
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:
BACKUP DATABASE AdventureWorks READ_WRITE_FILEGROUPS
TO AWPartialBackup
Cuando use el backup parcial diferencial, considere los siguientes puntos:
! Backups diferenciales parciales no pueden ser multibase.
! Si un grupo de archivos es cambiado de read-only a read/write, automáticamente será incluido en el
próximo backup parcial o parcial diferencial.
! Si un grupo de archivos es cambiado de read/write a read-only, debe realizar un archivo de backup
por separado porque será salteado automáticamente en el próximo backup parcial diferencial.
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:
BACKUP DATABASE AdventureWorks
TO AWBackup
WITH COPY_ONLY
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.
Cambios en la Restauración de Base de Datos
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.
RESTORE DATABASE AdventureWorks
FROM AWBackup
WITH RECOVERY, STOPAT = ’Mar 1, 2004 2:00 PM’
Operaciones de Restauración Parcial
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:
RESTORE DATABASE AWTemp
FILE = ’AdventureWorks_data_1’
FROM AWBackup
WITH PARTIAL,
MOVE ’AdventureWorks_data_1’ TO ’AWTemp_data_1.mdf’
Operaciones de Restauración Page-level
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:
PAGE = ’file:page [ ,...p]’
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:
RESTORE DATABASE AdventureWorks
PAGE = ’AdventureWorks_data_1:832’
FROM 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.
Cómo Realizar una Restauración Online
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.)
Restauración de Archivos Online
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.
Restauración de Paginas 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.
Uso de checksums Durante el Backup y Restauración
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:
BACKUP DATABASE AdventureWorks
TO AWBackup
WITH 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:
RESTORE DATABASE AdventureWorks
FROM AWBackup
WITH CHECKSUM
Puede forzar al SQL Server a log, pero no fallar, cuando encuentra errores de checksum usando la
opción CONTINUE_AFTER_ERROR. La statement RESTOREVERIFYONLY ha sido mejorada
para incluir la opción CHECKSUM y permitirle verificar los datos antes de intentar restaurarlos.
Nota
Debe usar la opción CHECKSUM con cuidado, puede producir efectos adversos a su sistema de base
de datos.
Backup Media Mirroring
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:
BACKUP DATABASE AdventureWorks
TO AWBackup
MIRROR TO AWMirror
WITH FORMAT
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.
Continuar Luego de Errores
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:
RESTORE DATABASE AdventureWorks
FROM AWBackup
WITH CONTINUE_AFTER_ERROR
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.
Cómo Recuperar la Base de Datos Master
Introducción
Si su base de datos master es dañada, puede necesitar o simplemente restaurar la base de datos o
reconstruirla completamente.
Restaurar la Base de Datos Master
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.
1. Inicie SQL Server en modo single-usere. En la línea de comando, navegue a la carpeta de
instalación de SQL Server y tipee el siguiente código:
sqlservr.exe -c .m
2. Ejecute una operación de restauración de un backup de una base de datos completa:
RESTORE DATABASE master
FROM masterbackup
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
Reconstruir la Base de Datos Master
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.