LA IMPORTANCIA DE LA BBDD TEPMDB

La base de datos del sistema tempdb es un recurso global disponible para todos los usuarios
conectados a la instancia de SQL Server y se utiliza para incluir lo siguiente:

Objetos de usuario temporales creados explcitamente como: tablas temporales

locales o globales, procedimientos almacenados temporales, variables de tabla o
cursores.
Objetos internos creados por el Motor de base de datos de SQL Server, por
ejemplo, tablas de trabajo para almacenar resultados intermedios para colas u
ordenacin.
Versiones de fila generadas por las transacciones de modificacin de datos en
una base de datos que utiliza transacciones read-committed que usan
transacciones de isolation or snapshot isolation.
Versiones de fila que se generan mediante transacciones de modificacin de
datos para caractersticas de operaciones (creacin y reconstrucion) de ndice,
Multiple Active Result Sets (MARS) y triggers AFTER.

Los objetos internos se crean y se quitan dentro del mbito de una instruccin.
Las operaciones realizadas en tempdb se registran con un nivel mnimo. Esto permite que se
reviertan las transacciones. La base de datos tempdb se vuelve a crear cada vez que se inicia
SQL Server, de forma que el sistema siempre se inicia con una copia limpia de la base de
datos. Las tablas y los procedimientos almacenados temporales se quitan automticamente en
la desconexin y ninguna conexin permanece activa cuando se cierra el sistema. Por tanto, en
la base de datos tempdb no hay nada que deba guardarse de una a otra sesin de SQL Server.
No se permite realizar operaciones de copia de seguridad y restauracin en tempdb.
PARMETROS DE TAMAO Y DE CRECIMIENTO DE LA TEMPDB
El tamao y la ubicacin fsica de la base de datos tempdb puede afectar al rendimiento de un
sistema. Por ejemplo, si el tamao definido en tempdb es demasiado pequeo, parte de la
carga de procesamiento del sistema puede deberse al crecimiento automtico de tempdb hasta
el tamao necesario para admitir la carga de trabajo cada vez que se reinicia la instancia de
SQL Server. Para evitar esta sobrecarga, aumente el tamao de los archivos de registro y de
datos de tempdb.
Puede ver los parmetros de tamao y de crecimiento de archivos de los archivos de datos o
de registro de tempdb mediante:
SELECT
name AS FileName,
size*1.0/128 AS FileSizeinMB,
CASE max_size
WHEN 0 THEN 'Autogrowth is off.Crecimiento automtico est
apagado'
WHEN -1 THEN 'Autogrowth is on. Crecimiento automtico est encendido'
ELSE 'Log file will grow to a maximum size of 2 TB. Archivo de registro crecer a
un tamao mximo de 2 TB'
END,
growth AS 'GrowthValue',
'GrowthIncrement' =
CASE
WHEN growth = 0 THEN 'Size is fixed and will not grow. El tamao es
fijo y no crecer'
WHEN growth > 0 AND is_percent_growth = 0
THEN 'Growth value is in 8-KB pages. El crecimiento es
el valor de pginas de 8 KB'

ELSE 'Growth value is a percentage. valor es un porcentaje de

crecimiento'
END
FROM tempdb.sys.database_files;
GO
Si se agota el espacio de disco de tempdb, se pueden producir interrupciones importantes en
el entorno de produccin de SQL Server y es posible que las aplicaciones en ejecucin no
puedan finalizar sus operaciones.
Determinar la cantidad de espacio libre en tempdb:
SELECT SUM(unallocated_extent_page_count) AS [free pages],
(SUM(unallocated_extent_page_count)*1.0/128) AS [free space in MB]FROM
sys.dm_db_file_space_usage;
Determinar la transaccin que ms tarda en ejecutarse:
SELECT transaction_id
FROM sys.dm_tran_active_snapshot_database_transactions
ORDER BY elapsed_time_seconds DESC;

DIMENSIONAR DE FORMA APROPIADA LA BASE DE DATOS TEMPDB

Dimensionar de forma apropiada la base de datos TEMPDB, es decir, cambiar el tamao por
defecto de TEMPDB (tamao inicial de TEMPDB) de tal modo que durante el funcionamiento
de la Instancia de SQL Server, no sea necesario que TEMPDB tenga que crecer y tampoco sea
necesario reducir TEMPDB
Si no tenemos dimensionada correctamente TEMPDB, se ver obligada a crecer, segn lo
vaya necesitando, se producir fragmentacin en el fichero de TEMPDB impactando en el
rendimiento general de la instancia. Debido a que cada vez que se inicia la Instancia de SQL
Server se elimina y vuelve a crear TEMPDB, existe el riesgo de generar fragmentacin en el
disco utilizado por TEMPDB.
Aumentar el tamao inicial de TEMPDB a 2GB:
USE master
GO
ALTER DATABASE tempdb
MODIFY FILE ( NAME = N'tempdev', SIZE = 2097152KB )
GO
Pero muy importante, si no sabemos cunto puede crecer, no le pongas restriccin de tamao,
y menos tan baja. Ponle que crezca automticamente, de 100 en 100 Mb, hasta que tengas un
tamao fijado basndote en el comportamiento y las necesidades del servidor, depender de
cmo evolucione, pueden ser 2Gb, 10 o 40. Si lo limitas a 2Gb, en cuanto se alcance ese
tamao, tu servidor empezar a fallarte. Cuando ya tengas un tamao ms establecido, el que
sea, entonces ya s puedes dejarlo fijo, si as lo estimas, aunque previamente a eso tendrs
que establecer un sistema de alertas que te permita detectar con suficiente margen de tiempo
que esta base de datos est alcanzando su lmite de tamao.
Adems de cambiar el tamao inicial de TEMPDB es muy recomendable aumentar el nmero
de ficheros de TEMPDB, a poder ser un fichero por cada CPU, con el objetivo de maximizar la
afinidad de CPU, esto es facilitar que puedan paralelizarse operaciones de entrada/salida (IOs)
y as obtener una mejora de rendimiento. Claro est, que si cada fichero pudiese estar en un
disco diferente, y cada uno de estos discos se accediese a travs de un camino (path) de fibra

distinto (es decir, diferentes puertos de fibra de las HBAs), estaramos facilitando al mximo la
optimizacin del acceso a disco de TEMPDB. As, para aadir ficheros a TEMPDB es suficiente
con ejecutar un comando ALTER DATABASE tempdb ADD FILE:

USE master
GO
ALTER DATABASE tempdb
ADD FILE ( NAME = N'tempdev02', FILENAME = N'F:\DATA\tempdb02.ndf', SIZE =
2097152KB, FILEGROWTH = 10% )
GO
Si tenemos una mquina con 8 CPUs y necesitamos 8 GB de TEMPDB, la recomendacin
que deberamos seguir es configurar TEMPDB con 8 ficheros de datos, cada uno de ellos con
un tamao inicial de 1GB.
Si TEMPDB no est correctamente dimensionado, puede ocurrir que empiece a crecer incluso
tomando todo el espacio libre del disco.
MOVER TEMPDB DE UN DISCO A OTRO:
Aqu explico como mover la base de datos tempdb de un disco a otro, este ejemplo solo aplica
para la base de datos tempdb, si se quieren mover bases de datos de usuario utilice
sp_detach_db y sp_attach_db.
Extraiga la ubicacin fsica de sus archivos de la base de datos tempdb:
USE tempdb
GO
EXEC sp_helpfile
GO
El nombre lgico de cada archivo es el contenido en la columna NAME.
Cambie la ubicacin de los archivos de datos y del log de trasacciones, usando la sentencia
ALTER DATABASE:
USE master
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'E:\SQLData\tempdb.mdf')
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'E:\SQLData\templog.ldf')
GO
Debe recibir los mensajes siguientes como confirmacin del cambio:
Archivo 'tempdev' modificado en sysaltfiles. Elimine el archivo antiguo despus de
reiniciar SQL Server.
Archivo 'templog' modificado en sysaltfiles. Elimine el archivo antiguo despus de
reiniciar SQL Server
Detenga e Inicie el servicio de SQLServer.

REDUCIR TEMPDB:
Si TEMPDB ha aumentado de tamao desde que se inici la Instancia de SQL Server, la forma
ms sencilla de recuperar el espacio utilizado por TEMPDB es reiniciar la Instancia de SQL
Server. Al detener SQL Server se mantendrn los ficheros de TEMPDB, por lo que todava no
habremos ganado espacio libre en disco. Sin embargo, al iniciar la Instancia de SQL Server, se
elimina TEMPDB y se vuelve a crear de nuevo, recuperando, el espacio libre que estaba
ocupando de ms. El principal inconveniente, es debido a que implica cortar el servicio a los
usuarios.
Tambin es posible intentar utilizar los comandos DBCC SHRINKDATABASE y DBCC
SHRINKFILE, pero ejecutar estos comandos sobre TEMPDB con actividad en TEMPDB puede
implicar que no se pueda reducir TEMPDB o bien pueden producirse errores que tampoco
permitan reducir TEMPDB con xito. Adems, mientras se est reduciendo SHRINK TEMPDB
es posible que se generen bloqueos sobre otras transacciones que necesiten acceder a
TEMPDB.
existe el truco de ejecutar el comando DBCC FREEPROCCACHE, de tal modo que al vaciarse
la cach de procedimientos (la zona de memoria en la que se almacenan los Planes de
Ejecucin para su reutilizacin) estamos eliminando de forma implcita las Tablas de Trabajo
(Worktables) asociadas a dichos Planes de Ejecucin. Esto reducira el tamao de la TEMPDB,
pero solo se ha de hacer en un estado crtico, cuando se ha producido el llenado de disco, y es
imposible reiniciar la instancia de SQL por necesidad e una obligada alta disponibilidad de la
aplicacin, prefiriendo una bajada de rendimiento temporal a tener que reiniciar al instancia de
SQL.
Si tempdb est en uso e intenta comprimirlo mediante los comandos DBCC
SHRINKDATABASE o DBCC SHRINKFILE, pueden mostrarse mltiples errores de
consistencia similares a los siguientes y la operacin de compresin no se ejecutar
correctamente:
Servidor: Msj 2501, Nivel 16, Estado 1, Lnea 1 No se encuentra la tabla '1525580473'.
Compruebe sysobjects.
O bien
Servidor: Msj 8909, Nivel 16, Estado 1, Lnea 0 Tabla daada: Id. de objeto 1, Id. de
ndice 0, Id. de pgina %S_PGID. Valor de PageId en el encabezado de la pgina =
%S_PGID.

Aunque es posible que el error 2501 no indique daos en tempdb, hace que la operacin de
compresin no se ejecute correctamente. Por otra parte, el error 8909 podra indicar daos en
la base de datos tempdb. Reinicie SQL Server para volver a crear tempdb y limpiar los errores
de consistencia. No obstante, tenga en cuenta que los errores de daos fsicos en los datos,
por ejemplo el error 8909, pueden deberse a otros motivos, entre los que se incluyen
problemas del subsistema de entrada y salida.

TEMPDB Y LA CREACIN DE NDICES:

Cuando crea o vuelve a generar un ndice, si establece la opcin SORT_IN_TEMPDB en ON,
puede indicar al motor de base de datos de SQL Server, que utilice tempdb para almacenar los
resultados de ordenacin intermedios que se utilizan para generar el ndice. Aunque esta
opcin aumenta la cantidad de espacio en disco temporal utilizado para crear un ndice, reduce

el tiempo que tarda en crear o volver a generar un ndice cuando tempdb est en un conjunto
de discos diferente al de la base de datos de usuario.
Si no se necesita una operacin de ordenacin o si la ordenacin se puede realizar en
memoria, la opcin SORT_IN_TEMPDB se omite.
El espacio disponible del grupo de archivos de la base de datos de usuario, debe ser lo
suficientemente extenso como para almacenar la estructura del ndice final. La continuidad de
las extensiones del ndice se puede mejorar si hay suficiente espacio disponible.

Restricciones en la TEMPDB:
En la base de datos tempdb no se pueden realizar las siguientes operaciones:

Agregar grupos de archivos.

Realizar una copia de seguridad o restaurar la base de datos.
Cambiar intercalaciones. La intercalacin predeterminada es la intercalacin de
servidor.
Cambiar el propietario de la base de datos. tempdb pertenece a dbo.
Crear una instantnea de base de datos.
Eliminar la base de datos.
Eliminar el usuario guest de la base de datos.
Habilitar el mecanismo de captura de cambios en los datos.
Participar en el reflejo de la base de datos.
Quitar el grupo de archivos principal, el archivo de datos principal o el archivo de
registro.
Cambiar el nombre de la base de datos o del grupo de archivos principal.
Ejecutar DBCC CHECKALLOC.
Ejecutar DBCC CHECKCATALOG.
Establecer la base de datos en OFFLINE.
Establecer la base de datos o el grupo de archivos principal en READ_ONLY.

INTEGRIDAD Y CORRUPCION EN LAS BASES DE DATOS : DBCC CHECKDB

Cuando hay corrupcin en una base de datos, la nica manera segura, vlida y rpida de
volver a poner la base de dato en produccin es a travs de un Restore con un backup vlido.
En caso de no ser posible porque los backups no son vlidos, o poco recientes, se pueden
intentar cosas para intentar reparar la base de datos.
Es importante tener en cuenta los puntos siguientes:

Intentar reparar una base de datos corrupta puede llevar mucho tiempo
Necesitamos concentrarnos en una base de datos a la vez, ya que para cada sntoma
de corrupcin los pasos a seguir para probar pueden ser distintos de un sntoma a
otro
El comportamiento de una base de datos corrupta no es predecible. Podemos repetir
una misma prueba 2 veces seguidas y que no tengamos el mismo resultado
No hay garanta de que lleguemos a un estado en que la base no tenga problemas de
consistencia
Si lo conseguimos, se pueden haber perdido datos (y no podemos saber cules)
Si la base es utilizada por otra aplicacin (por ejemplo Sharepoint), la prdida de datos
en esa base, puede llevar a la situacin que la propia aplicacin ya no soporte esta
base de datos y se tenga que restaurar de un backup vlido.

CONSIDERACIONES A TENER, ANTES DE EJECUTAR DBCC CHECKDB:

Si se ejecuta DBCC CHECKDB cuando ya hay mucha actividad en el sistema, se deteriora el
rendimiento de DBCC por dos motivos. En primer lugar, porque hay menos memoria disponible
y se fuerza al motor de base de datos de SQL Server a almacenar los datos internos de
DBCC CHECKDB en la base de datos tempdb. En segundo lugar, Si una carga de trabajo que
consume una gran cantidad de memoria y est utilizando el mismo disco, donde se encuentran
los ficheros de la base de datos, la cual esta siendo tratada por CHECKDB, se ver afectado el
rendimiento provocando una ejecucin ms lenta.
Dado que la base de datos tempdb reside en disco, el cuello de botella de las operaciones de
E/S que se produce a medida que se escriben los datos en el disco, independientemente de la
actividad del sistema, hacen recomiendar colocar la base de datos tempdb en discos rpidos,
como un dispositivo RAID, separados de las bases de datos de usuario.
Si ejecutamos:
DBCC CHECKDB WITH ESTIMATEONLY
Muestra la cantidad de espacio para la base de datos tempdb que se prev necesario
para ejecutar DBCC CHECKDB con todas las dems opciones especificadas.
La ejecucin de DBCC CHECKDB ejecuta automticamente DBCC CHECKTABLE para cada
tabla de la base de datos, as como DBCC CHECKALLOC y DBCC CHECKCATALOG, por lo
que deja de ser necesario ejecutarlos independientemente.
DBCC CHECKDB no examina los ndices deshabilitados.
En las versiones de SQL Server 2005 anteriores al Service Pack 2, al ejecutar DBCC
CHECKDB se borra la memoria cach del plan de la instancia de SQL Server. Al borrar la
memoria cach del plan, se provoca una nueva compilacin de todos los planes de ejecucin
posteriores y puede ocasionar una disminucin repentina y temporal del rendimiento de las
consultas. En el Service Pack 2, al ejecutar DBCC CHECKDB no se borra la memoria cach
del plan.

DBCC CHECKDB utiliza una instantnea interna de la base de datos para la coherencia
transaccional necesaria para realizar estas comprobaciones. As se evitan problemas de
bloqueo y simultaneidad cuando se ejecuta. Si no se puede crear una instantnea o se
especifica TABLOCK, DBCC CHECKDB se requieren bloqueos compartidos de tabla para
realizar las comprobaciones de tabla. (Por motivos de rendimiento, las instantneas de bases
de datos no estn disponibles en la tempdb. Eso significa que no es posible obtener la
coherencia transaccional necesaria.) Solo produce DBCC CHECKDB un error cuando se
ejecuta en la base de datos master, si no se puede crear una instantnea de base de datos
interna.
Si ejecutamos:

DBCC CHECKDB WITH TABLOCK

Hace que DBCC CHECKDB obtenga bloqueos en lugar de utilizar una instantnea de
base de datos interna. Se incluye un bloqueo exclusivo (X) a corto plazo en la base de
datos. TABLOCK hace que DBCC CHECKDB se ejecute ms rpido en una base de
datos con mucha carga, pero disminuye la simultaneidad disponible en la base de
datos mientras DBCC CHECKDB est ejecutndose.
TABLOCK limita las comprobaciones que se llevan a cabo; DBCC CHECKCATALOG
no se ejecuta en la base de datos y los datos de Service Broker no se validan.

Se recomienda utilizar la opcin PHYSICAL_ONLY para un uso frecuente en sistemas de

produccin. El uso de PHYSICAL_ONLY puede reducir mucho el tiempo de ejecucin de DBCC
CHECKDB en bases de datos grandes. Tambin se recomienda ejecutar DBCC CHECKDB sin
opciones de forma peridica. La frecuencia con que se deben realizar estas ejecuciones vara
en funcin de la empresa y su entorno de produccin.
Si ejecutamos:
DBCC CHECKDB WITH PHYSICAL_ONLY
Esta comprobacin se ha diseado para proporcionar una pequea comprobacin de
sobrecarga de la coherencia fsica de la base de datos; tambin detecta pginas
rasgadas, errores de suma de comprobacin y errores de hardware comunes que
pueden comprometer los datos del usuario. PHYSICAL_ONLY siempre implica
NO_INFOMSGS y no se permite con ninguna de las opciones de reparacin.
DBCC CHECKDB WITH NO_INFOMSGS
Suprime todos los mensajes de informacin
En SQL Server 2005 con el Service Pack 1, se crea un archivo de volcado
(SQLDUMPnnnn.txt) en el directorio LOG de SQL Server siempre que DBCC CHECKDB
detecta un error relacionado con datos daados. El acceso est limitado a la cuenta de servicio
de SQL Server y a los miembros de la funcin sysadmin. De forma predeterminada, la
funcin sysadmin contiene todos los miembros del grupo BUILTINAdministrators de Windows y
el grupo de administradores local.

RESOLVER ERRORES DE DBCC CHECKDB:

Si DBCC CHECKDB notifica errores, se recomienda restaurar la base de datos a partir de una
copia de seguridad en lugar de ejecutar REPAIR con una de sus opciones. La opcin de
reparacin que se debe utilizar se especifica al final de la lista de errores notificados por
CHECKDB.
No
obstante,
la
correccin
de
errores
mediante
la
opcin
REPAIR_ALLOW_DATA_LOSS puede requerir eliminar algunas pginas y, por tanto, tambin
algunos datos.
Si ejecutamos:
DBCC CHECKDB (BBDD, REPAIR_ALLOW_DATA_LOSS)
Intenta reparar todos los errores indicados. Estas reparaciones pueden ocasionar
alguna prdida de datos.
DBCC CHECKDB (BBDD, REPAIR_FAST)
La sintaxis se mantiene nicamente por compatibilidad con versiones anteriores. No se
realizan acciones de reparacin.
DBCC CHECKDB (BBDD, REPAIR_REBUILD)
Lleva a cabo rpidamente acciones de reparacin menores, como la reparacin de
claves adicionales en ndices sin agrupar, y reparaciones lentas como la regeneracin
de ndices. Estas reparaciones se pueden realizar sin riesgo de prdida de datos.

En algunas circunstancias, es posible que la base de datos contenga valores que no son
vlidos o que no estn comprendidos en el intervalo correcto de acuerdo con el tipo de datos
de la columna. En SQL Server 2000, DBCC CHECKDB no realiza comprobaciones de intervalo
o de integridad en estos valores de columna. Sin embargo, en SQL Server 2005, DBCC
CHECKDB puede detectar valores de columna que no son vlidos para todos los tipos de datos
de columna. Por tanto, al ejecutar DBCC CHECKDB con la opcin DATA_PURITY en bases de
datos que se han actualizado desde versiones anteriores de SQL Server, pueden desvelarse
errores de valores de columna que ya existan. Dado que SQL Server 2005 no puede reparar
estos errores automticamente, ser necesario actualizar el valor de la columna de forma
manual. Si CHECKDB detecta un error de este tipo, devuelve una advertencia, el nmero de
error 2570 e informacin para identificar la fila afectada y corregir el error manualmente.
Si ejecutamos:
DBCC CHECKDB WITH DATA_PURITY

Hace que DBCC CHECKDB compruebe si la base de datos contiene valores de

columna que no son vlidos o estn fuera del intervalo correcto. Por ejemplo, DBCC
CHECKDB detecta las columnas cuyos valores de fecha y hora son superiores o
inferiores al intervalo de valores vlido para el tipo de datos datetime; o bien las
columnas del tipo de datos decimal o numrico aproximado con valores de escala o
precisin que no son vlidos.
Para las bases de datos creadas en SQL Server 2005, las comprobaciones de
integridad de valores de columna estn habilitadas de manera predeterminada y no
requieren la opcin DATA_PURITY. De manera predeterminada, en las bases de datos
actualizadas desde versiones anteriores de SQL Server, las comprobaciones de
valores de columna no se habilitan hasta que se ejecuta DBCC CHECKDB WITH
DATA_PURITY sin errores en la base de datos. Despus, DBCC CHECKDB
comprueba la integridad de los valores de columna de manera predeterminada. Para

obtener ms informacin sobre cmo podra afectar a CHECKDB la actualizacin de

bases de datos de versiones anteriores de SQL Server, vea la seccin Notas ms
adelante en este tema.

Una vez finalizadas las reparaciones, realice una copia de seguridad de la base de datos.
En nuestro caso, los errores que devuelve el DBCC CHECKDB son:

Caso Prctico:
Al ejecutar DBCC CHECKDB, en una base de datos obtenemos:
Msg 8914, Level 16, State 1, Line 1
Incorrect PFS free space information for page (1:61871) in object ID 2009058193,
index ID 1, partition ID 72057597430071296, alloc unit ID 71907784698953728 (type
LOB data). Expected value 0_PCT_FULL, actual value 100_PCT_FULL.
Msg 8914, Level 16, State 1, Line 1
Incorrect PFS free space information for page (1:63663) in object ID 2009058193,
index ID 1, partition ID 72057597430071296, alloc unit ID 71907784698953728 (type
LOB data). Expected value 0_PCT_FULL, actual value 100_PCT_FULL.
Msg 8914, Level 16, State 1, Line 1
Incorrect PFS free space information for page (1:64839) in object ID 2009058193,
index ID 1, partition ID 72057597430071296, alloc unit ID 71907784698953728 (type
LOB data). Expected value 0_PCT_FULL, actual value 100_PCT_FULL.
.... etc...
CHECKDB found 0 allocation errors and 42 consistency errors in database 'BBDD'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC
CHECKDB (BBDD).
DBCC execution completed. If DBCC printed error messages, contact your system
administrator.
La opcin mnima de reparacin que propone el DBCC CHECKDB es repair_allow_data_loss. En
este caso, podramos estar ante la situacin de que intentando reparar la base de datos
tenemos el riesgo de perder datos, y puediera ser que la aplicacin ya no soportara el
estado de la base de datos, siendo la nica solucin restaurar de un backup vlido.
Por otra parte, tambin es cierto que aunque la opcin sea repair_allow_data_loss,
tericamente lo que hace en casos de error 8914 es corregir el valor del espacio libre en las
pginas:
[PFS free space error
You may encounter the following error when running DBCC CHECKDB:
Msg 8914, Level 16, State 1, Line 1 Incorrect PFS free space information for page
(1:128) in object ID 60, index ID 1, partition ID 281474980642816, alloc unit ID
71776119065149440 (type LOB data). Expected value 0_PCT_FULL, actual value
100_PCT_FULL.
In this case, the CHECKDB code recommends REPAIR_ALLOW_DATA_LOSS but repair
simply fixes the free space information in the PFS page with no data loss occurring as
a result.]
El plan de accin que propongo es el siguiente:
1.- Efectuar un backup de la base de datos
2.- Ejecutar DBCC CHECKDB (BBDD, REPAIR_ALLOW_DATA_LOSS)
3.- Ejecutar un DBCC CHECKDB (BBDD)
4.- Realizar un backup de la bbdd, para disponer de un backup de una base de datos
coherente.

En casos de error 8914, normalmente, se da este error cuando se utilizan registros mnimos
para los LOB ( Se producen en determinadas ocasiones en bbdd con el modelo de
recuperacin SIMPLE, durante BULK INSERT / bcp / inserciones grandes con la opcin
TABLOCK).

A pesar de que se trata de una salida de error, no significa que exista nada malo con la base
de datos, simplemente significa que hay de un nmero de pginas adicionales que estn
vacos y destinados a la estructura de rboles de pginas, as que mientras el mensaje que
dice que la pgina est vaca, en realidad son marcadas 100% para que solo sean asignadas
con informacin sobre la estructura de rboles , nada puede ir mal con esas pginas. Por
desgracia, DBCC informa de estos errores, si se pueden considerar errores...
Se pueden deshacerse de las pginas vacas LOB utilizando ALTER INDEX ... REORGANIZE
CON (LOB_COMPACTION = ON), sin la necesidad de realizar DBCC CHECKDB (BBDD,
REPAIR_ALLOW_DATA_LOSS). Por lo tanto, si vemos algunos de estos errores (donde
realmente no tenemos nada de qu preocuparnos), puede que podamos evitarlos con el
ALTER INDEX.