Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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:
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'
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.
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:
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.
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:
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
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.