cómo consolidar varios archivos de registro en un archivo ldf en sql2000

cómo consolidar varios archivos de registro en un archivo ldf en sql2000

Estoy en el proceso de copiar bases de datos de SQL 2000 a una instancia de 2008 en otro servidor usando DETACH, copiar el archivo de Windows al servidor de 2008 y finalmente ADJUNTAR. Llegué a una base de datos donde el archivo LOG está en 2 archivos de Windows:

name                          fileid filename                            size         maxsize    growth      usage

MasterScratchPad_Data     1      C:\SQLDATA\MasterScratchPad_Data.MDF    6041600 KB   Unlimited  5120000 KB  data only
MasterScratchPad_Log      2      C:\SQLDATA\MasterScratchPad_Log.LDF     2111304 KB   Unlimited  10%         log only
MasterScratchPad_X1_Log   3      E:\SQLDATA\MasterScratchPad_X1_Log.LDF  191944 KB    Unlimited  10%         log only

Me gustaría tener solo un archivo para el registro (es decir, puedo hacerlo más grande y ajustar los parámetros de crecimiento, pero preferiría que fuera solo un archivo antes de actualizar la base de datos a SQL2008).

He hecho una copia de seguridad de la base de datos. He emitido: REGISTRO DE RESPALDO MasterScratchPad CON TRUNCATE_ONLY. He ejecutado varios comandos DBCC SHRINKFILE en ambos archivos LOG. El intento más reciente fue DBCC SHRINKFILE(MasterScratchPad_X1_Log, 0) pero el resultado es el anterior.

¿Cómo puedo lograr este objetivo de tener solo un .LDF? No puedo encontrar nada sobre cómo eliminar el que tiene un ID de archivo de 3 y/o cómo consolidar varios archivos en un solo archivo de registro.

Respuesta1

Esto es bastante sencillo... Aquí está el guión a continuación. Déjame saber si necesitas algo más.

¡Gracias!

-VM

USAR [MasterScratchPad]

IR

ALTERAR BASE DE DATOS [MasterScratchPad] ELIMINAR ARCHIVO [MasterScratchPad_X1_Log]

IR

Respuesta2

Dicho esto, sé consciente de lo que haces. Las bases de datos de un solo archivo (base de datos, registro) son MÁS LENTAS que las de varios archivos; hay buenas razones para tener X archivos cada una, siendo X el número de núcleos. Todo esto está bien documentado por Microsoft, pero parece que a muchas personas no les gusta leer (rara vez veo a un administrador de SQL competente en estos y otros aspectos).

información relacionada