Cómo Migrar y Optimizar la Base de Datos SQL en tu Servidor MU

Por Qué Importan la Migración y la Optimización de la Base de Datos

La base de datos de un servidor MU Online es el núcleo de cada acción del juego: datos de personajes, inventario, registros de gremios, bitácoras de asedio de castillos, estados de eventos y credenciales de cuentas residen dentro de SQL Server. Con el tiempo, a medida que los jugadores se conectan, desconectan, comercian, suben de nivel y mueren, la base de datos acumula índices fragmentados, registros de transacciones inflados, estadísticas desactualizadas y filas dejadas por operaciones incompletas.

Sin mantenimiento periódico, el rendimiento de las consultas se degrada. Los tiempos de inicio de sesión aumentan, las operaciones de almacenamiento de objetos se ralentizan y el propio proceso del servidor puede bloquearse esperando operaciones de entrada/salida. Migrar a una instancia de SQL Server más reciente o a una máquina nueva amplifica el riesgo: una base de datos no optimizada o migrada de forma inconsistente llevará todos sus problemas al nuevo entorno.

Esta guía cubre el ciclo completo: preparación previa a la migración, un procedimiento seguro de respaldo y restauración, validación posterior a la migración y una rutina de optimización continua que puedes programar como trabajos del Agente de SQL Server.

> [!ATENCION] > Todos los procedimientos de esta guía requieren detener los servicios del servidor MU antes de ejecutarse. Nunca ejecutes scripts de migración ni reconstrucciones de índices sobre una base de datos que esté aceptando conexiones de juego activas. La corrupción de datos es posible si una migración se superpone con operaciones de escritura en producción.

Preparación Previa a la Migración

Antes de tocar la base de datos, recopila información sobre el estado actual de la instancia y establece una línea base limpia.

Inventariar las Bases de Datos

Las instalaciones estándar de emuladores MU utilizan entre dos y cinco bases de datos. Los nombres comunes incluyen MuOnline, AccountDB, EventDB, GuildDB y LogDB. Ejecuta lo siguiente en la instancia de origen para listarlas con sus tamaños:

-- Listar todas las bases de datos MU con información de tamaño
SELECT
    d.name                              AS NombreBaseDatos,
    d.compatibility_level               AS NivelCompatibilidad,
    mf.size * 8 / 1024                  AS TamanoMB,
    d.recovery_model_desc               AS ModeloRecuperacion,
    d.state_desc                        AS Estado
FROM sys.databases d
JOIN sys.master_files mf
    ON d.database_id = mf.database_id
    AND mf.type = 0                     -- solo archivos de datos
WHERE d.name NOT IN ('master','model','msdb','tempdb')
ORDER BY TamanoMB DESC;

-- Verificar fragmentación de índices en MuOnline antes de migrar
USE MuOnline;
SELECT
    OBJECT_NAME(ips.object_id)          AS NombreTabla,
    i.name                              AS NombreIndice,
    ips.avg_fragmentation_in_percent    AS PctFragmentacion,
    ips.page_count                      AS Paginas
FROM sys.dm_db_index_physical_stats(
        DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
JOIN sys.indexes i
    ON ips.object_id = i.object_id
    AND ips.index_id = i.index_id
WHERE ips.avg_fragmentation_in_percent > 10
  AND ips.page_count > 100
ORDER BY PctFragmentacion DESC;

Toma nota de las tablas con fragmentación superior al 30%: son los objetivos de mayor prioridad para una reconstrucción de índices inmediatamente después de la migración.

Reducir el Registro de Transacciones

Antes de tomar el respaldo, cambia a recuperación SIMPLE (si no está ya configurada) y reduce el archivo de registro para evitar llevar gigabytes de espacio de registro no utilizado al destino:

-- Ejecutar para cada base de datos MU que use modelo FULL
USE MuOnline;
ALTER DATABASE MuOnline SET RECOVERY SIMPLE;
DBCC SHRINKFILE (MuOnline_log, 64);   -- reducir log a 64 MB
ALTER DATABASE MuOnline SET RECOVERY FULL;
-- Repetir para AccountDB, EventDB, etc.

> [!CONSEJO] > Cambiar temporalmente a recuperación SIMPLE para reducir el log y luego volver a FULL es un patrón de mantenimiento seguro y ampliamente aceptado. Si no necesitas capacidad de restauración a un punto en el tiempo (la mayoría de los servidores privados no la necesitan), dejar las bases de datos en modelo SIMPLE de forma permanente reduce el crecimiento del log y simplifica el mantenimiento.

Tomar un Respaldo Completo

Utiliza BACKUP DATABASE con COMPRESSION y CHECKSUM para producir archivos de respaldo verificados y más pequeños. La compresión está disponible desde SQL Server 2008 R2 Standard en adelante.

-- Respaldo completo comprimido → ruta local antes de la migración
BACKUP DATABASE MuOnline
TO DISK = 'D:\Respaldos\MuOnline_premig.bak'
WITH
    COMPRESSION,
    CHECKSUM,
    STATS = 10,
    DESCRIPTION = 'Respaldo completo pre-migración 2026-07-04';

-- Verificar el respaldo inmediatamente después
RESTORE VERIFYONLY
FROM DISK = 'D:\Respaldos\MuOnline_premig.bak'
WITH CHECKSUM;
-- Resultado esperado → "The backup set on file 1 is valid."

Repite el comando BACKUP DATABASE para cada base de datos relacionada con MU. Tras la verificación, copia todos los archivos .bak al servidor de destino antes de continuar.

Restaurar en la Instancia de Destino

En la nueva instancia de SQL Server, restaura cada base de datos con cláusulas MOVE para colocar los archivos de datos y registro en los directorios correctos del servidor de destino:

-- Restaurar MuOnline en la instancia de destino
RESTORE DATABASE MuOnline
FROM DISK = 'D:\Respaldos\MuOnline_premig.bak'
WITH
    MOVE 'MuOnline'      TO 'E:\SQLData\MuOnline.mdf',
    MOVE 'MuOnline_log'  TO 'E:\SQLLog\MuOnline_log.ldf',
    REPLACE,
    STATS = 5;
-- → Restore completed for database 'MuOnline'.

Después de restaurar todas las bases de datos, establece el nivel de compatibilidad para que coincida con la versión de SQL Server de destino:

-- SQL Server 2019 → nivel de compatibilidad 150
ALTER DATABASE MuOnline SET COMPATIBILITY_LEVEL = 150;
ALTER DATABASE AccountDB SET COMPATIBILITY_LEVEL = 150;
-- Repetir para las bases de datos restantes

Validación Posterior a la Migración

Antes de iniciar los servicios del servidor MU, confirma la integridad de los datos y la conectividad.

Ejecuta DBCC CHECKDB contra cada base de datos restaurada:

DBCC CHECKDB (MuOnline) WITH NO_INFOMSGS, ALL_ERRORMSGS;
-- Resultado limpio → DBCC results for 'MuOnline'. ...0 errors.

Luego verifica que el inicio de sesión SQL utilizado por el proceso del servidor MU exista en la instancia de destino y esté asignado a las bases de datos correctas:

-- Crear el login si no existe en el destino
IF NOT EXISTS (SELECT 1 FROM sys.server_principals WHERE name = 'muserver_user')
BEGIN
    CREATE LOGIN muserver_user WITH PASSWORD = 'TuContrasenaSegura!';
END

-- Asignar el login a cada base de datos
USE MuOnline;
IF NOT EXISTS (SELECT 1 FROM sys.database_principals WHERE name = 'muserver_user')
    CREATE USER muserver_user FOR LOGIN muserver_user;
EXEC sp_addrolemember 'db_owner', 'muserver_user';
-- Repetir para AccountDB, EventDB, GuildDB, LogDB

Actualiza las cadenas de conexión en los archivos de configuración del servidor MU (típicamente DBConnect.ini, ConnectDB.ini o equivalente) para que apunten al nombre o dirección IP de la nueva instancia.

Reconstrucción de Índices y Actualización de Estadísticas

Con la migración completada, reconstruye todos los índices fragmentados y actualiza las estadísticas antes de que el primer jugador se conecte:

-- Reconstruir todos los índices en MuOnline
USE MuOnline;
EXEC sp_MSforeachtable
    'ALTER INDEX ALL ON ? REBUILD WITH (FILLFACTOR = 80, ONLINE = OFF)';

-- Actualizar todas las estadísticas
EXEC sp_updatestats;

Un factor de relleno de 80 deja un 20% de espacio libre en las páginas de índice, reduciendo las divisiones de páginas durante operaciones intensivas en INSERT como el registro de caída de objetos y el seguimiento de actividad de gremios.

Programar el Mantenimiento Continuo

La optimización única no es suficiente. Crea trabajos en el Agente de SQL Server para automatizar el ciclo de mantenimiento:

-- Paso del trabajo de mantenimiento semanal de índices (ejecutar domingo 03:00)
-- Reorganizar índices con fragmentación 10-30%, reconstruir por encima del 30%
USE MuOnline;
DECLARE @NombreTabla NVARCHAR(256);
DECLARE @NombreIndice NVARCHAR(256);
DECLARE @PctFrag     FLOAT;

DECLARE idx_cursor CURSOR FOR
    SELECT
        OBJECT_NAME(ips.object_id),
        i.name,
        ips.avg_fragmentation_in_percent
    FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
    JOIN sys.indexes i
        ON ips.object_id = i.object_id AND ips.index_id = i.index_id
    WHERE ips.page_count > 100
      AND ips.avg_fragmentation_in_percent > 10;

OPEN idx_cursor;
FETCH NEXT FROM idx_cursor INTO @NombreTabla, @NombreIndice, @PctFrag;
WHILE @@FETCH_STATUS = 0
BEGIN
    IF @PctFrag > 30
        EXEC('ALTER INDEX [' + @NombreIndice + '] ON [' + @NombreTabla + '] REBUILD');
    ELSE
        EXEC('ALTER INDEX [' + @NombreIndice + '] ON [' + @NombreTabla + '] REORGANIZE');
    FETCH NEXT FROM idx_cursor INTO @NombreTabla, @NombreIndice, @PctFrag;
END
CLOSE idx_cursor;
DEALLOCATE idx_cursor;

Programa este script como un paso de trabajo en el Agente de SQL Server y configúralo para ejecutarse semanalmente. Agrega un segundo trabajo para operaciones nocturnas de BACKUP DATABASE que garanticen puntos de recuperación diarios disponibles.

Lista de Verificación Final Antes de Abrir el Servidor

Antes de abrir el servidor a los jugadores después de la migración:

• Confirma que DBCC CHECKDB devolvió cero errores en todas las bases de datos.
• Verifica que el proceso del servidor MU puede conectarse a la nueva instancia usando las credenciales configuradas.
• Confirma que los datos de personajes, cuentas y gremios están íntegros verificando registros directamente en SQL Server Management Studio.
• Prueba el inicio de sesión, la selección de personaje y las operaciones de objetos en el juego con una cuenta de prueba antes de anunciar que la ventana de mantenimiento ha concluido.
• Actualiza cualquier script de monitoreo, rutas de respaldo o herramientas externas que referenciaran el nombre de la instancia anterior.

Una base de datos correctamente migrada y optimizada manejará la carga de jugadores con mayor eficiencia, reducirá la frecuencia de eventos de bloqueo mutuo (deadlock) y te proporcionará una base sólida para futuras actualizaciones del servidor.

Perguntas frequentes