Estou escrevendo um conjunto de procedimentos para (parcialmente) automatizar a implantação de banco de dados para um cliente, que geralmente funciona bem, mas às vezes um comando RESTORE está falhando com o erro 32 do sistema operacional, sobre um arquivo que está sendo usado por outro processo (detalhes abaixo).
Eu pesquisei isso extensivamente, mas encontrei pouco que se aplica ao meu caso específico. Suspeito que há algo que estou ignorando, mas simplesmente não consigo encontrá-lo.
Aqui está o comando:
RESTORE DATABASE [NBBC_Logistics] FROM DISK = '\\wpdboardq01\Shares\DbCopy\DevBackups\NBBC_Logistics_140916112310.bak'
WITH FILE=1, NOUNLOAD, STATS=10,
MOVE 'NBBC_Logistics' TO 'D:\MSSQL2K12\MSSQL11.MSSQLSERVER\MSSQL\DATA\NBBC_Logistics.mdf',
MOVE 'NBBC_Logistics_log' TO 'D:\MSSQL2K12\MSSQL11.MSSQLSERVER\MSSQL\DATA\NBBC_Logistics_log.ldf',
REPLACE
;
Isso resulta na seguinte mensagem de erro:
Msg 3634, Level 16, State 1, Line 11
The operating system returned the error '32(The process cannot access the file because it is being used by another process.)' while attempting 'RestoreContainer::ValidateTargetForCreation' on 'D:\MSSQL2K12\MSSQL11.DEV\MSSQL\DATA\NBBC_Logistics_log.ldf'.
Msg 3156, Level 16, State 8, Line 11
File 'NBCC_Logistics_Model2_log' cannot be restored to 'D:\MSSQL2K12\MSSQL11.DEV\MSSQL\DATA\NBBC_Logistics_log.ldf'. Use WITH MOVE to identify a valid location for the file.
Msg 3119, Level 16, State 1, Line 11
Problems were identified while planning for the RESTORE statement. Previous messages provide details.
Msg 3013, Level 16, State 1, Line 11
RESTORE DATABASE is terminating abnormally.
Algumas coisas a serem observadas:
Isso só acontece em algumas das Instâncias SQL de recebimento, a maioria delas está executando comandos muito semelhantes sem nenhum problema.
A instância que está falhando é aquela em que há várias instâncias SQL na mesma caixa (DEV e QA) e está tentando restaurar um backup de banco de dados do DEV para a versão QA do mesmo banco de dados.
Outros bancos de dados nesta mesma instância podem executar seu comando RESTORE correspondente sem problemas.
Pode ser relevante que os nomes dos arquivos lógicos de origem (mostrados no erro) sejam diferentes dos existentes nos BDs (nomeados no comando), no entanto, acredito que tenha casos em que isso funcione.
Além disso, observe com atenção que o caminho do arquivo relatado pelo erro NÃO é o que estou especificando no MOVE, mas sim o caminho do arquivo original (que ainda possui os arquivos de banco de dados originais em uso pela instância DEV).
Portanto, parece que ele está tentando primeiro RESTAURAR os arquivos de banco de dados para seus locais de caminho originais e só então MOVÊ-los para o caminho que eu indicar. Isso está em contraste com o que o documento diz que faz, e obviamente seria totalmente impraticável em geral, já que alguém RESTAURANDO uma cópia do banco de dados não tem controle sobre onde os arquivos originais estavam e não poderia garantir que esses caminhos existiam e já não estavam em uso .
Qualquer ajuda seria muito apreciada.
Apenas para evitar algumas das respostas automáticas que não se aplicam:
- O banco de dados de destino não está sendo usado por mim ou por qualquer outra pessoa.
- Nem aparece em
sp_lock - O comando especifica
REPLACE, ele deve substituir o banco de dados existente - Os arquivos especificados não são abertos por nenhum outro processo do Windows
- no entanto, o arquivo mencionado no erro é aberto pela outra instância Sql na caixa
- o local do arquivo BAK em um compartilhamento não tem nada a ver com isso, copiá-lo localmente não altera nada, nem renomeá-lo.
- os arquivos db e os caminhos especificados são os corretos para o banco de dados de destino
Ao usar os arquivos de backup, certifique-se de usar o nome de arquivo lógico. Ao usar vários conjuntos de backup nos mesmos arquivos de backup, certifique-se de verificar se o arquivo que está sendo usado está correto.
Neste caso:
Parece que você tem o nome de arquivo lógico errado ou o backup errado dentro de um conjunto de backup. Eu sei que você apontou isso, mas faria sentido interrogar as informações no conjunto de backup e verificar novamente.
Procure por 'erros de digitação' ou de sintaxe em seus nomes de arquivo, como '\\' no caminho. Resolva-os e sua declaração funcionará.
(É claro que um erro de digitação no seu caminho é uma versão da resposta dada acima em relação a um nome de arquivo incorreto, mas apenas um caso específico desse problema!)
Isso funcionou para mim para o erro 32 .. outro processo está usando.
https://support.microsoft.com/en-in/help/3153836/operating-system-error-32-when-you-restore-a-database-in-sql-server-20
Se você estiver restaurando de um conjunto de backup distribuído que contém dados FILESTREAM no SQL Server 2012 SP3, 2014 ou 2016, poderá receber esse erro. A correção é instalar a atualização cumulativa listada para sua versão no link acima (ou um SP ou CU posterior).