Soporte Enterprise: Resolución del Log de Transacciones Lleno en Saint -SQL Server


Error Crítico 9002

Resolución del Log de Transacciones Lleno en Saint SQL Server

Guía técnica para administradores de base de datos: diagnóstico, solución de emergencia y prevención del crecimiento descontrolado del archivo .ldf

📅 20 de marzo, 2026
⏱️ Tiempo de lectura: 15 min
🎯 Nivel: Técnico Avanzado

⚠️ Situación de Emergencia
El archivo de log de transacciones (.ldf) ha alcanzado su tamaño máximo o ha consumido todo el espacio disponible en disco. El servidor SQL Server se ha detenido y los usuarios no pueden acceder a Saint Administrativo. Este artículo proporciona los pasos inmediatos para resolver la situación.

1. Comprendiendo la Arquitectura del Problema

Saint Administrativo en su versión SQL utiliza una arquitectura de dos capas: la aplicación desarrollada en Delphi (Object Pascal) que se comunica con Microsoft SQL Server como motor de base de datos. Esta arquitectura genera transacciones constantes que se registran en el log de transacciones.

Capa de Aplicación: Delphi (Clientes Saint)
Motor de Base de Datos: SQL Server (T-SQL)
Archivos: SAINT.mdf (datos) + SAINT_log.ldf (transacciones)

¿Qué es el Log de Transacciones?

El archivo .ldf (Log Data File) es fundamental para la recuperación de datos. Cada operación INSERT, UPDATE o DELETE genera registros en este archivo antes de confirmarse en la base de datos principal. En el modelo de recuperación FULL (predeterminado en instalaciones empresariales), estos registros se mantienen hasta que se realiza un backup del log.

Causas del Crecimiento Descontrolado

  • Transacciones largas sin commit: Procesos batch de Delphi que no finalizan correctamente
  • Falta de backups de log: Sin truncamiento periódico, el log crece indefinidamente
  • Consultas masivas: Reportes históricos que generan millones de registros de log
  • Replicación fallida: Procesos de sincronización interrumpidos que dejan transacciones abiertas
  • Procesos de integración: Importaciones de datos desde Excel o otros sistemas sin control de transacciones

2. Diagnóstico Inmediato

Antes de actuar, es crucial identificar el estado actual del log y qué transacciones están consumiendo espacio.

Script 1: Verificar Espacio Utilizado por el Log

-- Verificar porcentaje de uso del log de transacciones
DBCC SQLPERF(LOGSPACE)
GO

-- Alternativa: consulta detallada por base de datos
SELECT 
    db.name AS [Base de Datos],
    db.recovery_model_desc AS [Modelo Recuperación],
    ls.cntr_value / 1024.0 AS [Tamaño Log MB],
    lu.cntr_value AS [Porcentaje Usado %],
    CASE 
        WHEN lu.cntr_value > 90 THEN 'CRÍTICO'
        WHEN lu.cntr_value > 70 THEN 'ADVERTENCIA'
        ELSE 'NORMAL'
    END AS [Estado]
FROM sys.databases db
INNER JOIN sys.dm_os_performance_counters lu 
    ON db.name = lu.instance_name
INNER JOIN sys.dm_os_performance_counters ls 
    ON db.name = ls.instance_name
WHERE lu.counter_name = 'Percent Log Used'
    AND ls.counter_name = 'Log File(s) Size (KB)'
    AND db.name = 'SAINT'

Script 2: Identificar Transacciones Abiertas

-- Detectar transacciones que mantienen abierto el log
SELECT 
    st.session_id,
    st.open_transaction_count,
    DATEDIFF(MINUTE, st.last_request_start_time, GETDATE()) AS [Minutos Activos],
    st.status,
    st.command,
    DB_NAME(st.database_id) AS [Base de Datos],
    st.host_name,
    st.program_name,
    st.login_name
FROM sys.dm_exec_sessions st
WHERE st.open_transaction_count > 0
    AND DB_NAME(st.database_id) = 'SAINT'
ORDER BY st.last_request_start_time

Script 3: Verificar Espacio en Disco

-- Verificar espacio disponible en discos del servidor
EXEC xp_fixeddrives
GO

-- Ubicación física de archivos de la base de datos SAINT
SELECT 
    name AS [Nombre Lógico],
    physical_name AS [Ruta Física],
    size * 8 / 1024 AS [Tamaño Actual MB],
    max_size * 8 / 1024 AS [Tamaño Máximo MB],
    CASE growth 
        WHEN 0 THEN 'Fijo'
        ELSE 'Autogrow ' + CAST(growth * 8 / 1024 AS VARCHAR) + ' MB'
    END AS [Crecimiento]
FROM sys.master_files
WHERE DB_NAME(database_id) = 'SAINT'
⚠️ Identificación del Problema
Si el porcentaje de uso supera el 90% y hay transacciones activas por más de 30 minutos, es probable que una operación de Delphi (como un cierre de mes o importación masiva) esté bloqueando el truncamiento del log.

3. Solución de Emergencia

Cuando el servidor SQL está detenido o la base de datos está en modo «Suspect» o «Recovery Pending», sigue estos pasos en orden:

Paso 1: Liberar Espacio Inmediato (Modelo Simple)

Si la empresa puede tolerar la pérdida de recuperación a punto en tiempo, cambiar temporalmente al modelo SIMPLE trunca inmediatamente el log:

-- Cambiar a modelo SIMPLE (trunca el log inmediatamente)
ALTER DATABASE SAINT SET RECOVERY SIMPLE
GO

-- Forzar escritura de datos pendientes al disco
CHECKPOINT
GO

-- Reducir el archivo de log a 1 GB (ajustar según necesidad)
DBCC SHRINKFILE (SAINT_log, 1024)
GO

-- Verificar nuevo tamaño
DBCC SQLPERF(LOGSPACE)

Paso 2: Liberar Espacio (Modelo Full – Recomendado)

Si se requiere mantener la capacidad de recuperación a punto en tiempo:

-- Realizar backup del log de transacciones (trunca las partes ya respaldadas)
BACKUP LOG SAINT 
TO DISK = 'D:\Backups\SAINT_Log_Emergencia.trn'
WITH COMPRESSION, STATS = 10
GO

-- Verificar que el backup se completó
RESTORE VERIFYONLY FROM DISK = 'D:\Backups\SAINT_Log_Emergencia.trn'
GO

-- Reducir el archivo físico
DBCC SHRINKFILE (SAINT_log, 1024)
GO

Paso 3: Identificar y Terminar Procesos Bloqueantes

Si hay transacciones de Delphi que mantienen el log abierto:

-- Identificar el SPID (ID de sesión) problemático
SELECT 
    session_id,
    open_transaction_count,
    DATEDIFF(MINUTE, last_request_start_time, GETDATE()) AS minutos_activo,
    status,
    command
FROM sys.dm_exec_sessions
WHERE open_transaction_count > 0 
    AND DATEDIFF(MINUTE, last_request_start_time, GETDATE()) > 30

-- Si es seguro terminar la sesión (reemplazar XX con el session_id):
KILL XX

-- Verificar que se liberó espacio
DBCC SQLPERF(LOGSPACE)
ℹ️ Nota Importante
Antes de ejecutar KILL, verifica que la sesión no pertenezca a un proceso crítico de cierre contable. Comunícate con el usuario o revisa el campo program_name para identificar si es una estación de trabajo de contabilidad.

Paso 4: Verificar Integridad Post-Recuperación

-- Verificar integridad física y lógica de la base de datos
DBCC CHECKDB ('SAINT') WITH NO_INFOMSGS
GO

-- Verificar estado de la base de datos
SELECT name, state_desc, recovery_model_desc 
FROM sys.databases 
WHERE name = 'SAINT'

4. Configuración Preventiva

Para evitar que el problema se repita, implementar el siguiente plan de mantenimiento automatizado mediante SQL Server Agent:

Job 1: Backup del Log Cada 15 Minutos

-- Crear job de backup frecuente del log
USE msdb
GO

EXEC sp_add_job
    @job_name = 'SAINT_Backup_Log_15min',
    @enabled = 1,
    @description = 'Backup del log de transacciones de SAINT cada 15 minutos'
GO

EXEC sp_add_jobstep
    @job_name = 'SAINT_Backup_Log_15min',
    @step_name = 'Backup Log',
    @subsystem = 'TSQL',
    @command = 'BACKUP LOG SAINT TO DISK = ''D:\Backups\Logs\SAINT_Log_$(ESCAPE_SQUOTE(STRTDT))_$(ESCAPE_SQUOTE(STRTTM)).trn'' WITH COMPRESSION, RETAINDAYS = 2',
    @database_name = 'master'
GO

EXEC sp_add_schedule
    @schedule_name = 'Cada_15_minutos',
    @freq_type = 4,
    @freq_interval = 1,
    @freq_subday_type = 4,
    @freq_subday_interval = 15,
    @freq_relative_interval = 0,
    @freq_recurrence_factor = 0,
    @active_start_time = 0
GO

Job 2: Monitoreo y Alerta de Espacio

-- Crear alerta cuando el log supere el 80%
EXEC sp_add_alert
    @name = 'SAINT_Log_Space_Critical',
    @message_id = 0,
    @severity = 0,
    @enabled = 1,
    @delay_between_responses = 300,
    @include_event_description_in = 1,
    @database_name = 'SAINT',
    @performance_condition = 'Databases|Percent Log Used|SAINT|>|80',
    @job_name = 'SAINT_Notificar_Administrador'
GO

Job 3: Mantenimiento de Índices (Semanal)

-- Rebuild de índices fragmentados (reduce operaciones de log)
EXECUTE dbo.IndexOptimize
    @Databases = 'SAINT',
    @FragmentationLow = 'NULL',
    @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE',
    @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
    @FragmentationLevel1 = 5,
    @FragmentationLevel2 = 30,
    @LogToTable = 'Y'

✓ Checklist de Verificación Post-Implementación

Verificar que los jobs de SQL Server Agent están habilitados y en ejecución
Confirmar que la ruta D:\Backups\Logs existe y tiene permisos de escritura
Probar restauración de un backup de log en ambiente de prueba
Configurar notificaciones por email en SQL Server Agent
Documentar el nuevo tamaño inicial del log (recomendado: 2-4 GB)
Programar revisión mensual del crecimiento del log

Resumen de Comandos Clave

Situación Comando Propósito
Verificar uso del log DBCC SQLPERF(LOGSPACE) Muestra porcentaje de uso de todos los logs
Detectar transacciones abiertas sys.dm_exec_sessions Identifica procesos que bloquean el truncamiento
Backup del log (truncar) BACKUP LOG Libera espacio marcado como reutilizable
Reducir archivo físico DBCC SHRINKFILE Disminuye tamaño del .ldf en disco
Cambiar modelo de recuperación ALTER DATABASE SET RECOVERY Simple (trunca automático) vs Full (requiere backup)
Verificar integridad DBCC CHECKDB Detecta corrupción post-recuperación
📋 Nota Final para Administradores
El log de transacciones es esencial para la recuperación ante desastres. Nunca elimines el archivo .ldf manualmente desde el explorador de Windows. Siempre utiliza los comandos T-SQL documentados para mantener la integridad de la cadena de recuperación de SQL Server.

© 2026 Soporte Enterprise | Documentación técnica para administradores de sistemas Saint

Basado en SQL Server 2019/2022 y arquitectura Saint SQL


Por admin

Translate »