SQL

Identificar el estado de la base de datos de SQL Server y cómo se puede mover una base de
datos entre estos diferentes estados se considera un aspecto importante de la administración
de la base de datos de SQL Server. Una buena comprensión de esto nos ayudará a resolver
problemas y solucionar muchos problemas y problemas de la base de datos.

El estado de una base de datos de SQL Server especifica el modo de ejecución actual de esa
base de datos. La base de datos puede ejecutarse en un estado a la vez. El estado actual de una
base de datos se puede verificar seleccionando la columna state_desc de la vista
de catálogo sys.databases .

Hay siete estados principales en los que puede salir una base de datos de SQL Server. La
siguiente instrucción SELECT consultará en la vista de catálogo sys.databases el nombre y el
estado de todas las bases de datos alojadas en la instancia actual de SQL Server:

SELECT name, state_desc FROM sys.databases

El resultado, en mi situación, mostrará que todas las bases de datos alojadas en la instancia
actual de SQL Server están funcionando en el estado EN LÍNEA de la siguiente manera:

El estado actual de una base de datos específica de SQL Server también se puede ver
seleccionando la propiedad Estado de la función DATABASEPROPERTYEX . La siguiente
instrucción SELECT visualiza el estado actual de la base de datos SQLShackDemo utilizando la
función DATABASEPROPERTYEX:
SELECT DATABASEPROPERTYEX (N'SQLShackDemo', N'STATUS') AS N'Status';

GO

Que está en línea como se muestra en el resultado a continuación:

Desde el lado de la disponibilidad de la base de datos, la base de datos puede estar totalmente
disponible o completamente no disponible. Entre estos dos estados principales, debería haber
ocurrido una transición suave en escenarios óptimos sin ningún problema que pueda
interrumpir esa transición. En este artículo, describiremos los siete estados de la base de datos,
las razones de estas ocurrencias de los estados de la base de datos SQL y cómo actuará la base
de datos cuando opere en esos estados.

EN LÍNEA
Una base de datos SQL que opera en un estado EN LÍNEA está disponible para el acceso de los
usuarios finales y funciona normalmente. En el estado de la base de datos EN LÍNEA, el grupo
de archivos primario está en línea, aunque el proceso crítico de recuperación de la base de
datos de la fase de deshacer aún puede no haber terminado por completo. El estado EN LÍNEA
es el estado correcto al que la base de datos SQL debe moverse sin problemas después de
iniciar la base de datos.

Desde el nodo Bases de datos de SQL Server Management Studio, el nombre de la base de
datos, por ejemplo, SQLShackDemo sin palabras especiales entre paréntesis, como se muestra
a continuación, indica que la base de datos está en estado EN LÍNEA

RESTAURANDO
El estado de la base de datos RESTAURACIÓN significa que el usuario ha iniciado un proceso
de restauración de la base de datos, utilizando el comando RESTORE DATABASE o RESTORE
LOG T-SQL, en el que se restauran uno o más archivos de datos del grupo de archivos primario,
o uno o más archivos secundarios se están restaurando en modo offline. En efecto, esto
significa que la base de datos no está disponible para el acceso del usuario final durante el
proceso de restauración.
La opción de restauración de la base de datos predeterminada es la opción RECUPERACIÓN ,
en la que la base de datos se volverá a poner en línea después de completar la restauración de
la copia de seguridad de la base de datos. Al usar la opción de restauración NORECOVERY ,
que se usa para restaurar múltiples archivos de respaldo, la base de datos estará en el estado
RESTAURAR hasta que llegue al último archivo en el que se usa la opción CON RECUPERACIÓN
para poner la base de datos en línea nuevamente después de restaurar el último archivo de
respaldo .

El siguiente comando RESTORE DATABASE que usa la opción de restauración NORECOVERY

mantendrá la base de datos en estado RESTAURANDO:

USE [master]

RESTORE DATABASE [SQLShackDemo]

FROM DISK = N'D:\backupSQL\SQLShackDemo_2016-08-19-001218.bak'

WITH FILE = 1, NOUNLOAD, STATS = 5 , NORECOVERY

GO

El mismo proceso se puede realizar utilizando la ventana Restaurar base de datos de SQL
Server Management Studio. La opción de restauración de la base de datos se puede especificar
desde la pestaña Opciones de esa ventana de la siguiente manera:

Al realizar el proceso de restauración anterior, la base de datos estará en estado de

RESTAURACIÓN, con la palabra especial "Restaurar" entre paréntesis junto al nombre de la
base de datos, como se muestra a continuación, lo que indica que la base de datos está en
estado de RESTAURACIÓN:
Si la base de datos sigue funcionando en el estado RESTAURANDO y no hay un archivo de
respaldo para restaurar en la base de datos, puede recuperar la base de datos y ponerla EN
LÍNEA simplemente aplicando la siguiente BASE DE DATOS DE RESTAURACIÓN ... Con el
comando RECUPERACIÓN:

USE [master]

RESTORE DATABASE [SQLShackDemo]

WITH RECOVERY

GO

La base de datos volverá a estar en línea al restaurar ninguna página nueva de la siguiente
manera:

RECUPERANTE
El estado de RECUPERACIÓN de la base de datos es un estado transitorio, en el que la base de
datos está realizando un proceso de recuperación y se conectará automáticamente, si el
proceso de recuperación se completa con éxito, después del inicio de la base de datos.

El proceso de recuperación consta de dos fases principales, la fase Roll Forward , en la que
se procesará cualquier transacción que se confirme al cerrar la base de datos y que aún no se
haya escrito en los archivos de datos de la base de datos. En la fase de reversión , cualquier
transacción que no se haya confirmado durante el cierre de la base de datos se revertirá. Si el
proceso de recuperación falla por algún motivo, la base de datos se moverá al estado SUSPECT
y no estará disponible. Al trabajar en estado RECUPERANDO, la base de datos no estará
disponible para los usuarios.

La palabra especial "En recuperación", entre paréntesis al lado del nombre de la base de datos
indica, como se muestra a continuación, que la base de datos está en estado de
RECUPERACIÓN:

El estado de RECUPERACIÓN de la base de datos es un estado transitorio como mencionamos

anteriormente, que se realiza en el inicio de la base de datos o después de restaurar el último
archivo de copia de seguridad. En casos normales, la base de datos no estará en el estado
RECUPERANDO durante mucho tiempo. Uno de los problemas más comunes que hace que la
base de datos permanezca en estado de RECUPERACIÓN, durante más tiempo y ralentice el
proceso de recuperación, es un número excesivo de archivos de registro virtuales (VLF), hasta
decenas de miles de ellos, dentro de la transacción de la base de datos. Iniciar sesión.

El número de VLF se puede verificar ejecutando el siguiente comando DBCC en su base de

datos:

USE SQLShackDemo

GO

DBCC LOGINFO

El comando en nuestro caso devolverá 86 registros de la siguiente manera:

Este número excesivo de VLF se genera principalmente debido al crecimiento del registro de
transacciones de la base de datos con mucha frecuencia y en incrementos muy pequeños. Para
superar ese problema, debe realizar una copia de seguridad del registro de transacciones en su
base de datos, reducir el registro de transacciones tanto como sea posible y finalmente
especificar un tamaño inicial del archivo de registro de transacciones lo suficientemente grande
como para manejar la carga de trabajo de la base de datos, sin la necesidad de un crecimiento
frecuente. Verificando nuevamente el número de VLF después de realizar la copia de seguridad
del registro de transacciones y las operaciones de reducción:

USE SQLShackDemo

GO

DBCC LOGINFO

El número se reducirá a 35 como en el resultado a continuación:

RECUPERACIÓN PENDIENTE
Tener su base de datos atascada en el estado PENDIENTE DE RECUPERACIÓN, significa que el
proceso de recuperación de la base de datos falló, debido a la falta de archivos o
potencialmente por razones relacionadas con los recursos, evitando que la base de datos se
recupere correctamente, pero que la base de datos no está dañada. En este caso, la base de
datos no estará disponible para el acceso del usuario y requirió una acción adicional del
usuario para resolver el error y permitir que el proceso de recuperación se complete con éxito.

La palabra especial "Recuperación pendiente" entre paréntesis al lado del nombre de la base
de datos, como se muestra, indica que la base de datos está en un estado PENDIENTE DE
RECUPERACIÓN:

El registro de errores de SQL Server es el mejor lugar desde el que puede comenzar su
investigación. En nuestro caso, el registro de errores muestra que la base de datos no se ha
recuperado con éxito debido a que falta un archivo de base de datos que se puede eliminar o
cambiar de nombre:

Ubicando nuevamente el archivo faltante, desconectando la base de datos y poniéndola en

línea, la base de datos se recuperará por completo como se muestra en el evento de registro
de errores a continuación:

SOSPECHAR
Una base de datos que se encuentra en los estados de SUSPECCIÓN significa que la base de
datos no está disponible para el acceso del usuario. En este estado de la base de datos, el
proceso de recuperación de la base de datos se inició pero no se completó con éxito, lo que
requiere una acción adicional del usuario para solucionar ese problema y reparar los archivos
dañados. SQL Server marca una base de datos como SUSPECTA debido a muchas razones,
como la corrupción de los archivos de la base de datos, los archivos de la base de datos no
disponibles o el cierre incorrecto del servidor de la base de datos SQL mientras se ejecuta una
gran transacción.

Simulemos una situación de corrupción de la base de datos en la que SQL Server marcará la
base de datos como SUSPECT. Crearemos una nueva base de datos de prueba, crearemos una
tabla simple en esa base de datos:

USE [master]

GO

CREATE DATABASE [SuspectDBDemo]

GO

USE [SuspectDBDemo]

GO

CREATE TABLE [Employees] (

[ID] INT,

[FirstName] VARCHAR (50),

[LastName] VARCHAR (50),

[Address] NVARCHAR (MAX));

GO

Además, llenaremos esa tabla con 1000 registros utilizando la herramienta de datos de prueba
sintética ApexSQL Generate de la siguiente manera:
Lo que haremos es iniciar una transacción que actualizará la tabla de prueba sin
comprometerla y ejecutará un comando CHECKPOINT para escribirla en el disco.

BEGIN TRAN

UPDATE

[Employees] SET [Address] = 'AMM' WHERE [LastName] like 'Evans';

GO

CHECKPOINT

GO

Al mismo tiempo desde otra sesión, ejecutaremos un comando SHUTDOWN para finalizar el
proceso de SQL Server:

SHUTDOWN WITH NOWAIT;

GO
Después de eso, abriremos el archivo de registro de la base de datos usando cualquier editor
hexadecimal, y modificaremos la primera sección llenándolo con ceros y guardaremos el
archivo nuevamente como se muestra a continuación:

Finalmente, iniciaremos el servicio de SQL Server nuevamente. Si intenta ejecutar una consulta
simple en esa base de datos, se mostrará un error que muestra que la base de datos es
inaccesible de la siguiente manera:

Verificación del estado de la base de datos usando la función DATABASEPROPERTYEX:

SELECT DATABASEPROPERTYEX ('SuspectDBDemo', 'STATUS') AS DatabaseStatus

El resultado mostrará que la base de datos está en estado SUSPECTO:

La palabra especial, "Sospechoso" entre paréntesis al lado del nombre de la base de datos,
como se muestra a continuación, indica que la base de datos está en estado SUSPECTO:

Nuevamente, y siempre, consultar el registro de errores de SQL Server lo ayudará a encontrar la

causa raíz del problema de SUSPECT de la base de datos, que es un problema con el archivo de
registro en nuestro caso de la siguiente manera:

EMERGENCIA
La base de datos se puede cambiar al estado de EMERGENCIA mediante una acción del usuario
sysadmin, para realizar el mantenimiento de la base de datos de manera segura o para
solucionar problemas. En este estado, la base de datos estará en modo de usuario único para
ser reparada o restaurada, marcada como READ_ONLY donde puede exportar los datos fuera
de la base de datos, el registro está deshabilitado y el acceso está restringido solo a los
miembros del rol sysadmin.

Volvamos de nuevo a la base de datos corrupta SuspectDBDemo anterior que está marcada
como SUSPECTO. Para solucionar su problema y resolverlo, cambiaremos el estado de la base
de datos a EMERGENCIA, permitiendo a los usuarios de sysadmin acceso de solo lectura a esa
base de datos. La siguiente instrucción ALTER DATABASE se usa para establecer el estado de la
base de datos en EMERGENCIA:

ALTER DATABASE SuspectDBDemo SET EMERGENCY

GO

La palabra especial "Emergencia" entre paréntesis al lado del nombre de la base de datos,
como se muestra a continuación, indica que la base de datos está en estado de EMERGENCIA:
Con la base de datos en estado de EMERGENCIA, podemos trabajar para resolver el problema
de manera segura. Para verificar la corrupción de la base de datos, se puede ejecutar un
comando DBCC CHECKDB mientras la base de datos está en estado de EMERGENCIA. Antes de
hacerlo, la base de datos debe cambiarse explícitamente para ejecutarse usando el modo
SINGLE_USER usando el siguiente comando ALTER DATABASE:

ALTER DATABASE SuspectDBDemo SET SINGLE_USER WITH ROLLBACK IMMEDIATE

GO

El comando DBCC CHECKDB se puede ejecutar ahora en esa base de datos, con la opción
REPAIR_ALLOW_DATA_LOSS. Los datos y / o índices dañados pueden eliminarse para que la
base de datos sea físicamente consistente, pero con una posible pérdida de datos. Además, el
archivo de registro de transacciones se reconstruirá si hay algún problema con ese registro de
transacciones. El siguiente comando DBCC CHECKDB se usa para corregir la corrupción de la
base de datos:

DBCC CHECKDB (SuspectDBDemo, REPAIR_ALLOW_DATA_LOSS)

GO

El resultado del comando clear DBCC CHECKDB en nuestro caso será el siguiente:

Cambiar el modo de ejecución de la base de datos al modo MULTI_USER:

ALTER DATABASE SuspectDBDemo SET MULTI_USER WITH ROLLBACK IMMEDIATE

GO
El problema de corrupción del archivo de registro de transacciones de la base de datos se
resuelve ahora, después de reconstruir el archivo de registro, y la base de datos vuelve a estar
EN LÍNEA y está disponible para el acceso del usuario:

Si ejecuta una instrucción SELECT simple desde la tabla de la base de datos, los datos se
recuperarán sin problemas:

DESCONECTADO
Cuando la base de datos está en estado DESCONECTADO, la base de datos no funciona ni está
disponible para el acceso del usuario. El estado de la base de datos puede cambiarse al estado
DESCONECTADO o solo mediante una acción explícita del usuario. Establecer el estado de la
base de datos en OFFLINE ayuda a migrar los archivos de la base de datos a una nueva unidad
de disco, o evita que los usuarios accedan a ella por cualquier motivo. La siguiente instrucción
ALTER DATABASE se usa para cambiar el estado de la base de datos a OFFLINE:

ALTER DATABASE [MDW] SET OFFLINE

GO

La misma acción se puede realizar con SQL Server Management Studio, haciendo clic con el
botón derecho en la base de datos -> Tareas y seleccione la tarea Desconectar de la siguiente
manera:
La flecha roja y la palabra especial Fuera de línea entre paréntesis al lado del nombre de la base
de datos indican que la base de datos está en estado SIN CONEXIÓN de la siguiente manera:

Teniendo en cuenta que la base de datos permanecerá fuera de línea a menos que realice una
acción explícita para ponerla en línea. La siguiente declaración ALTER DATABASE hará que la
base de datos vuelva a estar en línea:

ALTER DATABASE [MDW] SET ONLINE

GO

Puede realizar la conexión de la base de datos en línea con SQL Server Management Studio
haciendo clic derecho en la base de datos -> Tareas y seleccione la tarea Traer en línea :

Conclusión
En este artículo, describimos siete estados diferentes de una base de datos de SQL Server,
mostramos cómo funcionaba una base de datos en estos estados y cómo mover la base de
datos de un estado a otro.
Cambiar el estado de la base de datos es crítico y debe asegurarse de que este cambio se
realice en el momento correcto, en una situación correcta, y de que tiene el plan de
recuperación en caso de falla.