como consolidar vários arquivos de log em um arquivo ldf no sql2000

como consolidar vários arquivos de log em um arquivo ldf no sql2000

Estou no processo de copiar bancos de dados do SQL 2000 para uma instância de 2008 em outro servidor usando DETACH, copiar o arquivo do Windows para o servidor de 2008 e, finalmente, ATTACH. Cheguei a um banco de dados onde o arquivo LOG está em 2 arquivos do 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

Gostaria de ter apenas um arquivo para o log (ou seja, posso aumentá-lo e ajustar os parâmetros de crescimento, mas preferiria que fosse apenas um arquivo antes de atualizar o banco de dados para SQL2008).

Eu fiz backup do banco de dados. Eu emiti: BACKUP LOG MasterScratchPad COM TRUNCATE_ONLY. Executei vários comandos DBCC SHRINKFILE em ambos os arquivos LOG. A tentativa mais recente foi DBCC SHRINKFILE(MasterScratchPad_X1_Log, 0) mas o resultado é o acima.

Como posso atingir esse objetivo de ter apenas um .LDF? Não consigo encontrar nada sobre como excluir aquele com ID de arquivo 3 e/ou como consolidar vários arquivos em um arquivo de log.

Responder1

Isso é bastante simples... Aqui está o seu script abaixo. Deixe-me saber se você precisar de mais alguma coisa.

Obrigado!

-VM

USE [MasterScratchPad]

IR

ALTERAR BANCO DE DADOS [MasterScratchPad] REMOVER ARQUIVO [MasterScratchPad_X1_Log]

IR

Responder2

Dito isto, esteja ciente do que você faz. Os bancos de dados de arquivo único (banco de dados, log) são MAIS LENTOS que os de vários arquivos - há boas razões para ter X arquivos cada, sendo X o número de núcleos. Tudo isso está bem documentado pela Microsoft - mas parece que muitas pessoas não gostam de ler (raramente vejo um administrador de SQL competente nestes e em alguns outros aspectos).

informação relacionada