Contenidos

1. 1 1.- Propiedades de las Bases de Datos
2. 2 2.- Almacenamiento de datos
3. 3 3.- Copias de Seguridad  y Restauración

1.- Propiedades de las Bases de Datos

La Base de Datos tiene una característica importante sobre las propiedades que se le asignarán:

Sintaxis

DATABASEPROPERTY ( database , property )

Argumentos
database
Es una expresión que contiene el nombre de la base de datos para la que se va a devolver la información de la propiedad con nombre. database es de tipo nvarchar(128).
property
Es una expresión que contiene el nombre de la propiedad de base de datos que se va a devolver. property es de tipo varchar(128) y puede tomar uno de los siguientes valores.

Valor	Descripción	Valor devuelto
IsAnsiNullDefault	La base de datos sigue las reglas de SQL-92 para aceptar valores NULL.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsAnsiNullsEnabled	Todas las comparaciones con un valor NULL se evalúan como desconocidas.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsAnsiWarningsEnabled	Se generan mensajes de error o de advertencia cuando se producen situaciones de error estándar.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsAutoClose	La base de datos se cierra sin problemas y libera los recursos cuando sale el último usuario.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsAutoCreateStatistics	Las estadísticas existentes se actualizan automáticamente cuando quedan desfasadas debido a que han cambiado los datos de las tablas.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsAutoShrink	Los archivos de la base de datos son candidatos a la reducción periódica automatizada.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsAutoUpdateStatistics	La opción de actualización automática de estadísticas se encuentra habilitada.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsBulkCopy	La base de datos permite operaciones no registradas.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsCloseCursorsOnCommitEnabled	Los cursores que están abiertos se cierran cuando se confirma una transacción.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsDboOnly	La base de datos está en modo de acceso como sólo DBO.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsDetached	Una operación de separación separó la base de datos.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsEmergencyMode	Se habilita el modo de emergencia para permitir el uso de las bases de datos no seguras.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsFulltextEnabled	La base de datos se habilita para texto.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsInLoad	La base de datos se está cargando.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsInRecovery	Se está recuperando la base de datos.	1 = Verdadero 0 = FALSE o NULL1 = La entrada no es válida
IsInStandBy	La base de datos está conectada en modo de sólo lectura y se permite la restauración del registro.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsLocalCursorsDefault	El valor predeterminado de las declaraciones de cursores es LOCAL.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsNotRecovered	La base de datos no se ha podido recuperar.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsNullConcat	Un operando de concatenación NULL devuelve NULL.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsOffline	La base de datos no tiene conexión.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsParameterizationForced	La opción establecida para parametrizacion en la base de datos es forzada	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsQuotedIdentifiersEnabled	Se pueden utilizar comillas dobles en los identificadores.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsReadOnly	La base de datos está en un modo de acceso de sólo lectura.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsRecursiveTriggersEnabled	Se habilita la activación recursiva de desencadenadores.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsShutDown	La base de datos ha tenido un problema al iniciarse.	1 = Verdadero 0 = Falso NULL1 = La entrada no es válida
IsSingleUser	La base de datos está en modo de acceso de un solo usuario.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsSuspect	La base de datos puede ser corrupta.	1 = Verdadero 0 = Falso NULL = Entrada no válida
IsTruncLog	La base de datos trunca sus puntos de comprobación de inicio de sesión.	1 = Verdadero 0 = Falso NULL = Entrada no válida
Versión	Número interno de la versión del código de Microsoft SQL Server con el que se creó la base de datos. Sólo es utilizado internamente por las herramientas de SQL Server y en el procesamiento de actualizaciones.	Número de versión = La base de datos está abierta. NULL = La base de datos está cerrada.

* El valor devuelto también es NULL si la base de datos no se ha iniciado nunca o se ha cerrado automáticamente.
Tipos de valor devueltos
 int

2.- Almacenamiento de datos

La unidad fundamental del almacenamiento de datos en SQL Server es la página. El espacio en disco asignado a un archivo de datos (.mdf o .ndf) de una base de datos se divide lógicamente en páginas numeradas de forma contigua de 0 a n. Las operaciones de E/S de disco se realizan en el nivel de página. Es decir, SQL Server lee o escribe páginas de datos enteras.
Las extensiones son una colección de ocho páginas físicamente contiguas; se utilizan para administrar las páginas de forma eficaz. Todas las páginas se almacenen en extensiones.

Páginas

En SQL Server, el tamaño de página es de 8 KB. Esto significa que las bases de datos de SQL Server tienen 128 páginas por megabyte. Cada página empieza con un encabezado de 96 bytes, que se utiliza para almacenar la información del sistema acerca de la página. Esta información incluye el número de página, el tipo de página, el espacio libre en la página y el Id. de unidad de asignación del objeto propietario de la página.

En la siguiente tabla se muestran los tipos de página utilizados en los archivos de datos de una base de datos de SQL Server.

Tipo de página	Contenido
Datos	Las filas de datos con todos los datos, excepto los datos text, ntext, image, nvarchar(max), varchar(max), varbinary(max) y xml, cuando text in row está establecido en ON.
Índice	Entradas de índice.
Texto o imagen	Tipos de datos de objetos grandes: •    Datos text, ntext, image, nvarchar(max), varchar(max), varbinary(max) y xml. Columnas de longitud variable cuando la fila de datos sobrepasa 8 KB: •    varchar, nvarchar, varbinary y sql_variant.
Mapa de asignación global, Mapa de asignación global compartido	Información acerca de si se han asignado las extensiones.
Espacio disponible en páginas	Información acerca de la asignación de páginas y el espacio libre disponible en las páginas.
Mapa de asignación de índices	Información acerca de las extensiones utilizadas por una tabla o un índice por unidad de asignación.
Mapa cambiado masivamente	Información acerca de las extensiones modificadas por operaciones masivas desde la última instrucción BACKUP LOG por unidad de asignación.
Mapa cambiado diferencial	nformación acerca de las extensiones que han cambiado desde la última instrucción BACKUP DATABASE por unidad de asignación.

Nota: Los archivos de registro no contienen páginas, contienen series de registros.

Las filas de datos se colocan en las páginas una a continuación de otra, empezando inmediatamente después del encabezado. Al final de la página, comienza una tabla de desplazamiento de fila. Caada una de esas tablas contiene una entrada para cada fila de la página. Cada entrada registra, a su vez,  la distancia del primer byte de la fila desde el inicio de la página. Las entradas de la tabla de desplazamiento de fila están en orden inverso a la secuencia de las filas de la página.



Compatibilidad con filas largas
Las filas no puede abarcar páginas en SQL Server 2005; no obstante, partes de la fila se pueden separar de la página de la fila para que la fila pueda ser muy grande. La cantidad máxima de datos y de sobrecarga que está contenida en una única fila de una página es de 8.060 bytes (8 KB). Sin embargo, esto no incluye los datos almacenados en el tipo de página Texto o imagen. En SQL Server 2005, esta restricción se flexibiliza para tablas que contienen las columnas varchar, nvarchar, varbinary o sql_variant. Cuando el tamaño de fila total de todas las columnas variables y fijas de una tabla excede el límite de 8.060 bytes, SQL Server mueve dinámicamente una o más columnas de longitud variable a páginas de la unidad de asignación ROW_OVERFLOW_DATA, empezando por la columna con el mayor ancho. Esto se realiza cuando una operación de inserción o actualización aumenta el tamaño total de la fila más allá del límite de 8060 bytes. Cuando una columna se mueve a una página de la unidad de asignación ROW_OVERFLOW_DATA, se mantiene un puntero de 24 bytes de la página original de la unidad de asignación IN_ROW_DATA. Si una operación posterior reduce el tamaño de la filas ,SQL Server vuelve a mover las columnas dinámicamente a la página de datos original.

Extensiones
Las extensiones son la unidad básica en la que se administra el espacio. Una extensión consta de ocho páginas contiguas físicamente, es decir 64 KB. Esto significa que las bases de datos de SQL Server tienen 16 extensiones por megabyte.
Para hacer que la asignación de espacio sea eficaz, SQL Server no asigna extensiones completas a tablas con pequeñas cantidades de datos. SQL Server maneja dos tipos de extensiones:

• Las extensiones uniformes, son propiedad de un único objeto; sólo el objeto propietario puede utilizar las ocho páginas de la extensión.
• Las extensiones mixtas, que pueden estar compartidas por hasta ocho objetos. Cada una de las 8 páginas de la extensión puede ser propiedad de un objeto diferente.
  

A las tablas o índices nuevos se les suelen asignar páginas de extensiones mixtas. Cuando la tabla o el índice crecen hasta el punto de ocupar ocho páginas, se pasan a extensiones uniformes para las posteriores asignaciones. Si se crea un índice de una tabla existente que dispone de filas suficientes para generar ocho páginas en el índice, todas las asignaciones del índice estarán en extensiones uniformes.

3.- Copias de Seguridad  y Restauración

Copias de Seguridad
Cada modelo de recuperación permite realizar una copia de seguridad completa o parcial de una base de datos de SQL Server, de archivos individuales o de grupos de archivos de la base de datos. No pueden crearse copias de seguridad de las tablas.

• Copias de seguridad de datos

El ámbito de una copia de seguridad de datos puede ser la base de datos completa, parcial o un conjunto de archivos o grupos de archivos. En todos estos casos, SQL Server admite copias de seguridad completas y diferenciales:

1. Copia de seguridad completa: Una copia de seguridad completa incluye copiar: todos los datos de una base de datos determinada o copiar un conjunto de grupos de archivos, así como una cantidad suficiente del registro como para permitir la recuperación de datos.
2. Copia de seguridad diferencial: Una copia de seguridad diferencial se basa en la última copia de seguridad completa de los datos. Ésta se denomina base de la copia de seguridad diferencial o base diferencial. Una base diferencial es una copia de seguridad completa de datos de lectura y escritura. Una copia de seguridad diferencial incluye sólo los datos que han cambiado desde la última base diferencial. Por lo general, las copias de seguridad diferenciales que se realizan poco después de su base son más pequeñas y rápidas, ahorrando así tiempo con respecto a la copia de seguridad completa. Por tanto, el uso de copias de seguridad diferenciales acelera el proceso de realización de copias de seguridad frecuentes y reduce el riesgo de pérdida de los datos. Por lo general, una base diferencial se utiliza en varias copias de seguridad diferenciales sucesivas. En el momento de la restauración, se restaura primero la copia de seguridad completa, seguida de la copia de seguridad diferencial más reciente.
   

Cada copia de seguridad de datos incluye parte del registro de transacciones para que se puedan recuperar hasta los últimos datos de la copia de seguridad.
Tras la primera copia de seguridad de datos, en el modelo de recuperación completa o el modelo de recuperación por medio de registros de operaciones masivas, se necesitan copias de seguridad del registro de transacciones (o copias de seguridad de registros) periódicas. Cada copia de seguridad de registros incluye la parte del registro de transacciones que estaba activa al crear la copia de seguridad, además de todas las entradas de registro que no se incluyeron en una copia de seguridad de registros anterior.

Copias de seguridad de bases de datos
Las copias de seguridad de bases de datos son fáciles de utilizar y se recomienda su uso cuando el tamaño de la base de datos los permite. SQL Server admite los siguientes tipos de copia de seguridad de base de datos.

Tipo de copia de seguridad	Descripción
Copia de seguridad completa de base de datos	Una copia de seguridad completa de la base de datos representan la base de datos completa en el momento en que finalizó la copia de seguridad.
Copia de seguridad diferencial de base de datos	Copia de seguridad de todos los archivos de una base de datos. Esta copia de seguridad sólo incluye las extensiones de datos modificadas desde la copia de seguridad más reciente de la base de datos de cada archivo.

Copias de seguridad parciales
Las copias de seguridad parciales y diferenciales parciales son una novedad en SQL Server 2005. Estas copias de seguridad están diseñadas para ofrecer una mayor flexibilidad al realizar copias de seguridad de bases de datos que incluyen algunos grupos de archivos de sólo lectura con el modelo de recuperación simple. Sin embargo, pueden usarse con todos los modelos de recuperación.
SQL Server 2005 admite los siguientes tipos de copias de seguridad de archivos.

Tipo de copia de seguridad	Descripción
Copia de seguridad parcial	Copia de seguridad de todos los datos del grupo de archivos principal, todos los grupos de archivos de lectura y escritura, y los archivos o grupos de archivos de sólo lectura opcionalmente especificados. Una copia de seguridad parcial de una base de datos de sólo lectura contiene únicamente el grupo de archivos principal.
Copia de seguridad diferencial parcial	Copia de seguridad que sólo incluye las extensiones de datos modificadas desde la copia de seguridad parcial más reciente del mismo conjunto de grupos de archivo.

Copias de seguridad de archivos
Es posible realizar una copia de seguridad y restaurar individualmente los archivos de una base de datos. El uso de las copias de seguridad de archivos puede aumentar la velocidad de recuperación ya que se pueden restaurar sólo los archivos dañados sin tener que restaurar el resto de la base de datos. Por ejemplo, si una base de datos está compuesta por varios archivos ubicados en diferentes discos y se producen errores en uno de ellos, sólo debe restaurar el archivo situado en el disco en que se produjeron los errores. Sin embargo, la planificación y restauración de copias de seguridad de archivos puede resultar compleja, por lo que sólo deben utilizarse cuando realmente suponen un valor añadido para el plan de restauración.
SQL Server admite los siguientes tipos de copias de seguridad de archivos.

Tipo de copia de seguridad	Descripción
Copia de seguridad completa de archivos	Copia de seguridad completa de todos los datos de uno o varios archivos o grupos de archivos de la base de datos. Importante: En el modelo de recuperación simple, las copias de seguridad de archivos están restringidas básicamente a los grupos de archivos de sólo lectura. Puede crear una copia de seguridad de archivos de un grupo de archivos de lectura y escritura pero, antes de que pueda restaurar dicha copia de seguridad, deberá establecer el grupo de archivos como de sólo lectura y realizar una copia de seguridad diferencial de archivos de sólo lectura.
Copia de seguridad diferencial de archivos	Una copia de seguridad de uno o varios archivos que incluye las extensiones de datos modificadas desde que se realizó la copia de seguridad completa más reciente de cada archivo. Nota: En el modelo de recuperación simple, se supone que desde la realización de la copia de seguridad completa los datos se han cambiado a sólo lectura.

Nota:
Puede realizar copias de seguridad de los catálogos de texto y restaurarlos.

Copias de seguridad del registro de transacciones (sólo para el modelo de recuperación completa y por medio de registros de operaciones masivas)
En el modelo de recuperación completa o el modelo de recuperación por medio de registros de operaciones masivas, se necesitan copias de seguridad del registro de transacciones (o copias de seguridad de registros) periódicas. Cada copia de seguridad de registros incluye la parte del registro de transacciones que estaba activo al crear la copia de seguridad, además de todas las entradas de registro que no se incluyeron en una copia de seguridad de registros anterior. Una secuencia continua de copias de seguridad de registros incluye la cadena de registros completa de la base de datos, que se denomina ininterrumpida. En el modelo de recuperación completa y, a veces, en el modelo de recuperación por medio de registros de operaciones masivas, una cadena de registros ininterrumpida permite restaurar la base de datos a cualquier momento dado en el tiempo.
Antes de crear la primera copia de seguridad de registros, debe crear una copia de seguridad completa, como una copia de seguridad de la base de datos. En adelante, es necesario realizar una copia de seguridad periódica del registro de transacciones, no sólo para reducir el riesgo de pérdida del trabajo sino para habilitar el truncamiento del registro de transacciones.

Copias de seguridad de sólo copia
Normalmente, la realización de una copia de seguridad cambia la base de datos y afecta a la forma de restaurar las copias de seguridad posteriores. Sin embargo, a veces es útil realizar una copia de seguridad con un fin específico sin afectar a los procedimientos generales de copia de seguridad y restauración de la base de datos. Con este propósito, SQL Server 2005 introduce copias de seguridad de sólo copia. Estas copias de seguridad son independientes de la secuencia periódica de copias de seguridad de SQL Server

Dispositivos de copia de seguridad
SQL Server realiza las copias de seguridad en dispositivos de copia de seguridad, como archivos de disco o cintas. Puede agregar nuevas copias de seguridad a las ya existentes en un dispositivo, o bien sobrescribir las copias de seguridad existentes.

Programar copias de seguridad
La realización de una operación de copia de seguridad tiene un efecto mínimo en las transacciones que se están ejecutando, por lo que se puede efectuar al mismo tiempo que otras operaciones periódicas. Durante la operación de copia de seguridad, SQL Server copia los datos directamente de los archivos de la base de datos en los dispositivos de copia de seguridad. Durante la copia de seguridad, no se cambian los datos ni se demoran las transacciones en curso. Por lo tanto, puede realizar una copia de seguridad de SQL Server con un efecto mínimo en las cargas de trabajo de producción. Las copias de seguridad pueden programarse de modo que se ejecuten automáticamente en intervalos fijos.

Restricciones de las operaciones de copia de seguridad en SQL Server
En SQL Server 2005, se puede realizar la copia de seguridad mientras la base de datos está conectada y en uso. Sin embargo, existen las siguientes restricciones.
No se pueden realizar copias de seguridad de los datos sin conexión
Cualquier operación de copia de seguridad en la que se haga referencia de forma implícita o explícita a datos sin conexión provocará un error. A continuación, se exponen algunos ejemplos habituales:

• Se solicita una copia de seguridad de base de datos completa, pero un grupo de archivos de la base de datos está sin conexión. Puesto que todos los grupos de archivos se incluyen de forma implícita en las copias de seguridad de base de datos completas, esta operación provocará un error. Para realizar una copia de seguridad de esta base de datos, se puede utilizar una copia de seguridad de archivos y especificar sólo los grupos de archivos que tengan conexión.
• Se solicita una copia de seguridad parcial, pero un grupo de archivos de lectura y escritura está sin conexión. Puesto que todos los grupos de archivos de lectura y escritura son obligatorios para las copias de seguridad parciales, esta operación provocará un error.
• Se solicita una copia de seguridad de determinados archivos, pero uno de ellos está sin conexión. Se produce un error en la operación. Para realizar una copia de seguridad de los archivos con conexión, puede omitir el archivo sin conexión de la lista y repetir la operación.
  

Normalmente, la copia de seguridad de registros será correcta aunque uno o varios de los archivos de datos no estén disponibles. Sin embargo, si algún archivo incluye cambios registrados de forma masiva realizados en el modelo de recuperación por medio de registros de operaciones masivas, todos los archivos deberán tener conexión para que la copia de seguridad sea correcta.

Restricciones de simultaneidad durante una copia de seguridad
SQL Server utiliza el proceso de copia de seguridad con conexión para permitir que se realice la copia de seguridad de una base de datos mientras se está utilizando. Durante la copia de seguridad, se pueden realizar la mayoría de las operaciones (por ejemplo, las instrucciones INSERT, UPDATE o DELETE están permitidas durante la operación de copia de seguridad). Sin embargo, si intenta iniciar una operación de copia de seguridad durante la creación o eliminación de un archivo de la base de datos, la operación de copia de seguridad esperará hasta que la creación o eliminación haya terminado o hasta que se agote el tiempo de espera de la copia de seguridad.
Las operaciones que no se pueden ejecutar durante la copia de seguridad de la base de datos o del registro de transacciones son las siguientes:

• Operaciones de administración de archivos, como la instrucción ALTER DATABASE con la opción ADD FILE o la opción REMOVE FILE.
• Operaciones de reducción de la base de datos o de reducción de un archivo. Esto incluye las operaciones de reducción automática.
• Si intenta crear o eliminar un archivo de la base de datos durante la operación de copia de seguridad, se producirá un error en la operación de creación o eliminación.
  

Si una operación de copia de seguridad se superpone a una operación de administración de archivos o de reducción, surge un conflicto. Con independencia de la operación en conflicto que empieza en primer lugar, la segunda operación espera a que se agote el tiempo de espera del bloqueo establecido por la primera operación. (El tiempo de espera se controla mediante un valor de tiempo de espera de sesión). Si el bloqueo se libera durante el tiempo de espera, la segunda operación continúa. Si se agota el tiempo de espera, la segunda operación no se realiza correctamente.
Este tema sólo es relevante para las bases de datos que utilizan los modos de recuperación completa o por medio de registros de operaciones masivas.

Restauración de una base de datos
La restauración es el proceso de copiar datos desde una copia de seguridad y aplicar transacciones registradas a los datos para ponerlos al día hasta el punto de recuperación de destino. Una copia de seguridad de datos o diferencial contiene suficientes registros de transacciones para permitir poner al día las transacciones activas como parte de la restauración de cada copia de seguridad. Cada copia de seguridad contiene suficientes registros para revertir las transacciones no confirmadas y llevar la base de datos a un estado coherente con la transacción y utilizable. El proceso de poner al día las transacciones no confirmadas, si las hay, y poner la base de datos en conexión se conoce como recuperación.

Conjunto de puestas al día
El proceso de aplicar cambios registrados a los datos de una base de datos para poner los datos al día se conoce como poner al día. El conjunto de todos los datos restaurados se conoce como el conjunto de puestas al día. Un conjunto de puestas al día se define con la restauración de una o más copias de seguridad completas, como una copia de seguridad de base de datos o parcial, o un conjunto de copias de seguridad de archivos. Si una instrucción RESTORE especifica grupos de archivos, archivos o páginas, sólo se incluyen estos elementos en el conjunto de puestas al día. De lo contrario, se incluirán en el conjunto de puestas al día todos los archivos de la copia de seguridad que se está restaurando. Si la copia de seguridad completa contiene entradas de registro, los datos restaurados se pondrán al día mediante este registro.
Nota: Si especifica un grupo de archivos durante la restauración, ésta engloba todo el grupo de archivos tal como existe actualmente. Esto incluye los archivos agregados al grupo de archivos desde que se realizó la copia de seguridad.
Para copias de seguridad diferenciales, si se agregaron archivos a la base de datos desde la base diferencial, la restauración de una copia de seguridad diferencial podría sobrescribir páginas del conjunto de puestas al día con datos de la copia de seguridad diferencial.
La restauración de una copia de seguridad diferencial sólo actualiza una página si ésta está en el conjunto de puestas al día; la página se incluye en la copia de seguridad y la instrucción RESTORE muestra la página o su archivo o no muestra ningún archivo ni página.
Con los modelos de recuperación completa y de recuperación por medio de registros de operaciones masivas, se debe realizar una copia de seguridad independiente del registro. Después de restaurar copias de seguridad de datos y (opcionalmente) diferenciales, en general debería restaurar las copias de seguridad de registros subsiguientes para llevar la base de datos al punto de error. Restaurar una copia de seguridad de registros pone al día todas las páginas del conjunto de puestas al día..

Secuencias de restauración
Cada escenario de restauración se implementa mediante uno o varios pasos de restauración (operaciones), lo que se denomina secuencia de restauración. Cada operación corresponde a una instrucción RESTORE de Transact-SQL independiente. Una secuencia de restauración mueve los datos afectados a través de una o varias fases de la restauración.

Fases de la restauración
Una restauración es un proceso de varias fases. Las fases posibles de una restauración incluyen las fases de copia de datos, rehacer (puesta al día) y deshacer (revertir):

• La fase de copia de datos implica copiar todos los datos, el registro y las páginas de índice desde el medio de copia de seguridad de una base de datos a los archivos de la base de datos.
• La fase de rehacer aplica las transacciones registradas a los datos copiados desde la copia de seguridad para poner al día esos datos hasta el punto de recuperación. Normalmente, en este punto una base de datos tiene transacciones no confirmadas y se encuentra en un estado inutilizable. En ese caso, se requiere una fase de deshacer como parte de la recuperación de la base de datos.
• La fase de deshacer, que es la primera parte de la recuperación, revierte cualquier transacción no confirmada y hace que la base de datos esté disponible para los usuarios. Después de la fase de reversión, no se pueden restaurar las copias de seguridad subsiguientes.
  

El resto de esta sección examina estas fases con más detalle.

Fase de copia de datos
La primera fase de todo proceso de restauración es la fase de copia de datos. La fase de copia de datos inicializa el contenido de la base de datos, los archivos o las páginas que se restauran. Esta fase se realiza mediante las operaciones de restaurar la base de datos, restaurar archivos y restaurar páginas utilizando copias de seguridad completas o diferenciales.
La fase de copia de datos implica copiar datos de una o más copias de seguridad completas y, de forma opcional, copias de seguridad diferenciales y, a continuación, restablecer el contenido de la base de datos, los archivos o las páginas afectados en el momento en que fueron capturados por esas copias de seguridad.
El archivo o la página más antiguo del conjunto de puestas al día determina el punto de inicio de la siguiente fase: rehacer (puesta al día).

Fase de rehacer (puesta al día)
Rehacer (o puesta al día) es el proceso de rehacer los cambios registrados hasta los datos del conjunto de puestas al día para avanzar los datos en el tiempo Para llevar a cabo la puesta al día, SQL Server Database Engine (Motor de base de datos de SQL Server) procesa las copias de seguridad de registros conforme se restauran, empezando por el registro contenido en las copias de seguridad completas.
La restauración evita las puestas al día innecesarias. Generalmente, si los datos eran de sólo lectura cuando se realizó la copia de seguridad y han permanecido como de sólo lectura, la puesta al día es innecesaria y se omite.

Punto de recuperación
El objetivo de la puesta al día es devolver los datos a su estado original en el punto de recuperación. El punto de recuperación es el punto hasta el que el usuario especifica que debe recuperarse el conjunto de datos. Con el modelo de recuperación completa, puede especificar el punto de recuperación como un momento determinado, una transacción marcada o un número de secuencia de registro. Con el modelo de recuperación por medio de registros de operaciones masivas, sólo puede realizar la restauración a un momento dado si no se ha realizado ninguna operación masiva desde la copia de seguridad de registros anterior.

Coherencia de rehacer (puesta al día)
En la fase de rehacer, los datos siempre se ponen al día hasta un punto que es coherente para rehacer con el estado de la base de datos en el punto de recuperación. Todos los datos se han puesto al día hasta un punto en el que se puede realizar la operación de deshacer.
El archivo principal define el estado de la base de datos, como se indica a continuación:

• Si el archivo principal se está restaurando, el punto de recuperación determina el estado de toda la base de datos. Por ejemplo, si una base de datos se está recuperando a un momento dato justo antes de que la tabla se quitara accidentalmente, toda la base de datos debe restaurarse al mismo momento dado.
• Si el archivo principal no se está restaurando, el estado de la base de datos es conocido y los datos restaurados se ponen al día hasta un punto de recuperación transaccionalmente coherente con la base de datos. SQL Server lo exige.
  

Sin embargo, la base de datos puede contener cambios realizados por transacciones que no están confirmadas en el punto de recuperación. Para la restauración con conexión, los datos se recuperan a un momento dado coherente con el estado actual de la parte conectada de la base de datos.
Una copia de seguridad diferencial avanza hasta el punto en que se realizó la copia de seguridad diferencial. Las páginas del conjunto de puestas al día se sobrescriben con páginas más recientes de la copia de seguridad diferencial.

Fase de deshacer (revertir) y recuperación
Después de que la fase de rehacer haya puesto al día todas las transacciones del registro, una base de datos suele contener los cambios realizados por las transacciones no confirmadas en el punto de recuperación. Esto convierte los datos puestos al día en transaccionalmente incoherentes. El proceso de recuperación abre el registro de transacciones para identificar las transacciones no confirmadas. Las transacciones no confirmadas se deshacen mediante la reversión, a menos que mantengan bloqueos que eviten que otras transacciones vean datos transaccionalmente incoherentes. Este paso se denomina fase de deshacer (o revertir). Si los datos ya son transaccionalmente coherentes al inicio del proceso de recuperación, la fase de deshacer se omitirá. Después de que la base de datos sea transaccionalmente coherente, la recuperación conecta la base de datos.
Nota: En términos generales, la recuperación es el conjunto de operaciones que hace que una base de datos sea coherente al inicio de esa base de datos. Si la base de datos se apagaba periódicamente, la recuperación omite las fases de rehacer y deshacer. Esto se conoce como recuperación de reinicio.
Después de que se hayan restaurado una o más copias de seguridad, la recuperación suele incluir tanto la fase de rehacer y como la de deshacer. Cada copia de seguridad completa y diferencial contiene suficientes registros de transacciones para permitir que los datos de esa copia de seguridad se recuperen a un estado coherente consigo mismo.
Nota: Durante una recuperación tras bloqueo o una conmutación por error de la creación de reflejo de la base de datos, SQL Server 2005 Enterprise Edition permite a los usuarios obtener acceso a la base de datos durante la fase de deshacer. Esto se conoce como recuperación rápida. La recuperación rápida es posible porque las transacciones que no estaban confirmadas cuando se produjo el error vuelven a adquirir los bloqueos que mantenían antes del error. Mientras estas transacciones se revierten, sus bloqueos las protegen de las interferencias de los usuarios.

Relación de las opciones RECOVERY y NORECOVERY con las fases de restauración
Una instrucción RESTORE específica termina después de la fase de rehacer o continúa con la fase de deshacer, según si la instrucción especificó WITH NORECOVERY, de la manera siguiente:

• WITH RECOVERY recupera la base de datos e incluye las fases de rehacer y deshacer; no se pueden restaurar otras copias de seguridad. Es el valor predeterminado. Si el conjunto de puestas al día no se ha puesto al día lo suficiente para ser coherente con la base de datos, la fase de deshacer no se podrá producir. Database Engine (Motor de base de datos) emitirá un error y la recuperación se detendrá. Si todo el conjunto de puestas al día es coherente con la base de datos, se realizará la recuperación y se podrá conectar la base de datos.
• WITH NORECOVERY omite la fase de deshacer para preservar las transacciones no confirmadas. Al omitir la fase de deshacer, se pueden restaurar otras copias de seguridad para poner al día la base de datos a un momento posterior. A veces, RESTORE WITH NORECOVERY pone al día los datos hasta donde son coherentes con la base de datos. En estos casos, Database Engine (Motor de base de datos) emite un mensaje informativo indicando que el conjunto de puestas al día se puede recuperar mediante la opción RECOVERY.
  

Rutas de recuperación
Una ruta de recuperación es un conjunto único de transformaciones que han cambiado la base de datos a lo largo del tiempo, aunque han mantenido su coherencia.

Restaurar una base de datos cuando SQL Server no está conectado
Es posible restaurar y recuperar una base de datos mediante SQL Writer mientras SQL Server no está conectado si no hay ningún catálogo de texto. Si hay un catálogo de texto asociado a una base de datos, primero es necesario iniciar SQL Server o detener el servicio Motor de texto completo de Microsoft para SQL Server (MSFTESQL).
Al ejecutarse, SQL Server obliga a cerrar los archivos del catálogo de texto como preparación para la operación de restauración. Sin embargo, si SQL Server está sin conexión, es posible que MSFTESQL mantenga abiertos determinados archivos de texto. Así se evita que la aplicación de restauración los sobrescriba. Para obligar a esos archivos de texto a cerrarse, una aplicación puede apagar MSFTESQL.
Para evitar tener que hacer esto, realice alguna de las siguientes acciones:

• Inicie SQL Server.
• Detenga MSFTESQL.
  

Para restaurar una copia de seguridad completa de la base de datos
1.    Después de conectarse a la instancia adecuada de SQL Server Database Engine (Motor de base de datos de SQL Server) de Microsoft, en el Explorador de objetos, haga clic en el nombre del servidor para expandir el árbol.
2.    Expanda Bases de datos. En función de la base de datos, seleccione una base de datos de usuario o expanda Bases de datos del sistema y, a continuación, seleccione una base de datos del sistema.
3.    Haga clic con el botón secundario en la base de datos, seleccione Tareas y, a continuación, haga clic en Restaurar.
4.    Haga clic en Base de datos, con lo que se abrirá el cuadro de diálogo Restaurar base de datos.
5.    En la página General, el nombre de la base de datos en restauración aparecerá en el cuadro de lista A una base de datos. Para crear una nueva base de datos, escriba su nombre en el cuadro de lista.
6.    En el cuadro de texto A un momento dado, puede conservar el valor predeterminado (Lo más reciente posible) o seleccionar una fecha y hora determinados haciendo clic en el botón Examinar, que abrirá el cuadro de diálogo Restauración a un momento dado..
7.    Para especificar el origen y la ubicación de los conjuntos de copias de seguridad que se deben restaurar, haga clic en una de las opciones siguientes:
8.    En la cuadrícula Seleccionar los conjuntos de copia de seguridad que se van a restaurar, seleccione las copias de seguridad que desea restaurar. En esta cuadrícula se muestran las copias de seguridad disponibles en la ubicación especificada. De forma predeterminada, se sugiere un plan de recuperación. Para anular el plan de recuperación sugerido, puede cambiar las selecciones de la cuadrícula. Al anular la selección de una copia de seguridad, se anulará automáticamente la selección de cualquier copia de seguridad que dependa de la primera.
9.    Para obtener información acerca de las columnas de la cuadrícula Seleccionar los conjuntos de copia de seguridad que se van a restaurar, vea Restaurar la base de datos (página General).
10.    Para ver o seleccionar las opciones avanzadas, haga clic en Opciones en el panel Seleccionar una página.
11.    En el panel Opciones de restauración, puede elegir cualquiera de las siguientes opciones, si son convenientes a su situación:
12.    Para obtener más información acerca de estas opciones, vea Restaurar base de datos (página Opciones).
13.    Si lo desea, puede restaurar la base de datos a una nueva ubicación si especifica un nuevo destino de restauración para cada archivo de la cuadrícula Restaurar los archivos de base de datos como. Para obtener más información acerca de esta cuadrícula, vea Restaurar base de datos (página Opciones).
14.    El panel Estado de recuperación determina el estado de la base de datos después de la operación de restauración. El comportamiento predeterminado es:
15.    De lo contrario, puede seleccionar una de las siguientes opciones: