Error Could not create tempDB tras reinicio: impacto y soluciones en producción

En cualquier arquitectura de datos basada en el stack de Microsoft, SQL Server actúa como el motor de almacenamiento y procesamiento central. Cuando este motor falla al arrancar, toda la cadena de valor del Business Intelligence se detiene: desde las extracciones de Power Query hasta los informes en DirectQuery. Uno de los errores más críticos y desconcertantes con los que me he encontrado en proyectos de retail y sector público es el mensaje Could not create tempdb tras un reinicio no programado del servidor.

Este fallo no es un simple problema de configuración menor; es un error de infraestructura que suele aparecer en máquinas virtuales (especialmente en Azure) donde la base de datos TempDB se ha ubicado en unidades de almacenamiento efímeras para ganar rendimiento. Si trabajas con modelos de datos complejos, sabes que TempDB es el área de trabajo donde SQL Server gestiona los spills de memoria, las tablas temporales y las versiones de filas. Sin ella, el servicio de SQL Server simplemente no se inicia.

A continuación, analizaremos por qué ocurre este problema, cómo afecta a tu entorno de producción y qué medidas preventivas debemos tomar como consultores para asegurar que una caída del host no se convierta en una pérdida total del servicio por una mala gestión de los discos temporales.

El origen del problema: almacenamiento efímero y latencia

La recomendación estándar para optimizar el rendimiento de SQL Server es colocar los archivos de datos y logs de TempDB en el disco más rápido disponible. En las máquinas virtuales de Azure, esto suele significar el disco D: (Temporary Storage). Este disco es un SSD local físico en el nodo que aloja la VM, lo que ofrece una latencia bajísima comparada con los discos administrados remotos. Sin embargo, este disco es volátil.

El problema surge cuando la VM se reinicia de forma inesperada o se migra a otro host por un fallo de hardware. En estos casos, el contenido del disco efímero se pierde por completo. Si SQL Server está configurado para buscar sus archivos de TempDB en una carpeta específica de ese disco y la carpeta no existe, o si el disco aún no ha sido inicializado por el sistema operativo cuando el servicio de SQL intenta arrancar, recibiremos el fatídico error Could not create tempdb.

En mi experiencia en proyectos de industria, este escenario es una pesadilla de disponibilidad. Si el servicio SQL no arranca, tus procesos de carga en el Lakehouse o en el Data Warehouse fallarán, rompiendo la frescura de datos en Microsoft Fabric o en cualquier otro destino. No es solo un problema de DBA, es un problema de negocio.

Impacto en el flujo de Business Intelligence

Cuando TempDB no está disponible, el motor relacional no puede realizar operaciones básicas. Esto afecta de manera directa a varios componentes de nuestra arquitectura:

• DirectQuery: Si el origen de datos está caído, todos los visuales de Power BI mostrarán un error. Muchos de estos informes dependen de patrones DAX en DirectQuery que generan consultas SQL intensivas en ordenación y agregación, las cuales requieren TempDB para ejecutarse.
• Procesos ETL/ELT: Las transformaciones complejas en SQL, como los JOIN de grandes dimensiones de Ventas con Tablas de Producto o Cliente, utilizan tablas temporales o la base de datos tempdb para los hash joins.
• Consultas con OR: Operaciones que ya de por sí penalizan el rendimiento, como el uso de OR en el WHERE, pueden saturar TempDB si el optimizador decide materializar resultados intermedios.

Si el sistema intenta recuperarse automáticamente tras un reinicio pero falla al crear TempDB, el tiempo medio de recuperación (MTTR) se dispara, ya que requiere intervención manual para recrear la estructura de directorios o ajustar los permisos del disco.

Cómo mitigar el riesgo: Automatización del arranque

Para evitar que un reinicio aleatorio deje fuera de servicio tu Data Warehouse, no basta con configurar SQL Server. Necesitamos una capa de orquestación a nivel de sistema operativo. Una solución habitual es utilizar un script de PowerShell que se ejecute al inicio del sistema, antes de que el servicio de SQL Server intente arrancar.

# Ejemplo conceptual de lógica de preparación de disco para TempDB
$tempDrive = "D:"
$tempFolder = "D:\SQLTempDB"

# Verificar si el disco existe
if (Test-Path $tempDrive) {
 # Crear la carpeta si no existe
 if (-not (Test-Path $tempFolder)) {
 New-Item -Path $tempFolder -ItemType Directory
 # Asignar permisos para la cuenta de servicio de SQL Server
 $acl = Get-Acl $tempFolder
 $permission = "NT SERVICE\MSSQLSERVER","FullControl","Allow"
 $accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission
 $acl.SetAccessRule($accessRule)
 Set-Acl $tempFolder $acl
 }
} else {
 Write-Error "El disco efímero no está disponible."
}

Este script debe configurarse como una tarea programada que se ejecute con los privilegios más altos al arrancar el equipo. Solo una vez que el script garantiza que el directorio existe y tiene los permisos adecuados, se debe permitir el inicio del servicio SQL Server. Es fundamental cambiar el tipo de inicio del servicio SQL Server de «Automático» a «Manual» y dejar que sea el script quien lo inicie tras las comprobaciones.

Configuración correcta de archivos en SQL Server

Además de la infraestructura, la configuración interna de SQL Server debe ser coherente. Si tenemos una instancia con muchos núcleos, es vital tener múltiples archivos de datos para TempDB para evitar la contención de asignación de páginas. Aquí un ejemplo de cómo configurar los archivos de forma proactiva:

-- Ajuste de archivos de TempDB para minimizar contención y asegurar rutas
USE [master];
GO
ALTER DATABASE [tempdb] MODIFY FILE (NAME = tempdev, FILENAME = 'D:\SQLTempDB\tempdb.mdf', SIZE = 10GB, FILEGROWTH = 1GB);
ALTER DATABASE [tempdb] MODIFY FILE (NAME = templog, FILENAME = 'D:\SQLTempDB\templog.ldf', SIZE = 5GB, FILEGROWTH = 512MB);
-- Añadir archivos adicionales según número de cores (ejemplo para 8 cores)
ALTER DATABASE [tempdb] ADD FILE (NAME = tempdev2, FILENAME = 'D:\SQLTempDB\tempdb_2.ndf', SIZE = 10GB, FILEGROWTH = 1GB);
-- ... repetir para el resto de archivos
GO

Comparativa: Almacenamiento local vs. persistente para TempDB

A la hora de diseñar la arquitectura, debemos sopesar el rendimiento frente a la resiliencia. No siempre la opción más rápida es la mejor para un entorno de producción crítica.

En proyectos donde la estabilidad es la prioridad absoluta y no tenemos un equipo de DBA 24/7, a veces es preferible sacrificar algo de IOPS y colocar TempDB en un disco persistente. Sin embargo, para cargas de trabajo de Data Warehousing intensivas, el beneficio de rendimiento del SSD local suele justificar la complejidad extra del script de arranque.

Diagnóstico y corrección tras el fallo

Si te encuentras en una situación donde el servidor ya ha fallado y el log de errores muestra que no puede crear TempDB, el primer paso es revisar el ERRORLOG de SQL Server. Verás mensajes indicando que el sistema no puede encontrar la ruta especificada o que el acceso ha sido denegado.

Para recuperar el servicio, puedes intentar arrancar SQL Server con parámetros mínimos de configuración utilizando el flag -f desde la línea de comandos. Esto permitirá que la instancia inicie ignorando ciertos errores de archivos, dándote la oportunidad de ejecutar un comando ALTER DATABASE para mover los archivos de TempDB a una ubicación que sí exista temporalmente, y luego reiniciar el servicio de forma normal.

Es útil recordar que entender el rendimiento no solo consiste en escribir buen código, sino en saber cómo el motor interactúa con el hardware. Al igual que recomendamos leer planes de ejecución en SQL Server para optimizar consultas, debemos leer los logs del sistema para optimizar la disponibilidad.

Errores frecuentes en la gestión de TempDB

• Rutas hard-coded: Configurar TempDB en una ruta que no existe por defecto en el disco efímero (como D:\Datos\Temp) sin asegurar que la carpeta se cree al arrancar.
• Falta de espacio inicial: Definir archivos de TempDB demasiado grandes para el espacio disponible en el disco temporal de la VM asignada.
• Permisos insuficientes: Olvidar que, tras un formateo del disco efímero por parte de Azure, los permisos de carpeta se pierden y la cuenta de servicio de SQL Server puede no tener acceso.
• No usar el ajuste automático: Ignorar herramientas como el ajuste automático en SQL Server que, aunque no soluciona TempDB, ayuda a mantener la estabilidad general del plan de ejecución tras recuperaciones.

Checklist de configuración robusta

1. Verifica que el disco donde reside TempDB es persistente o tiene un script de preparación de directorios en el arranque.
2. Configura el servicio SQL Server como «Inicio manual» si dependes de un script previo de PowerShell.
3. Asigna al menos 8 archivos de datos para TempDB (o uno por core hasta 8) con el mismo tamaño inicial y crecimiento.
4. Monitorea el uso de TempDB mediante alertas de SQL Agent para evitar que el disco se llene durante procesos de carga masiva.
5. Documenta la ruta de los archivos en tu manual de recuperación ante desastres (DRP).

Preguntas frecuentes

¿Por qué SQL Server necesita TempDB para arrancar?

TempDB es esencial porque el motor de base de datos la utiliza para tareas internas de gestión de memoria, metadatos temporales y objetos de sistema desde el primer segundo de actividad. Si no puede inicializar este espacio de trabajo, el proceso sqlservr.exe se detiene por seguridad para evitar la corrupción de datos.

¿Es mejor poner TempDB en el disco C:?

Nunca. El disco del sistema operativo (C:) suele tener límites de IOPS más bajos y, si TempDB llegara a llenarlo, podrías bloquear todo el sistema operativo, impidiendo incluso el acceso por escritorio remoto o SSH para solucionar el problema.

¿Cómo afecta este error a mis informes de Power BI?

Si el servidor no arranca, cualquier informe conectado por DirectQuery fallará inmediatamente. Los informes en modo Importación fallarán en su siguiente actualización programada, lo que resultará en datos desactualizados para los usuarios finales.

¿Azure SQL Database (PaaS) tiene este problema?

No, en las versiones de plataforma como servicio (PaaS), Microsoft gestiona la infraestructura y la redundancia de TempDB de forma transparente. Este problema es específico de SQL Server instalado en máquinas virtuales (IaaS) o servidores on-premises.

»
}