J'écris un ensemble de procédures pour (partiellement) automatiser le déploiement de DB pour un client, qui fonctionne principalement bien, mais parfois une commande de restauration échoue avec l'erreur de système d'exploitation 32, d'un fichier étant utilisé par un autre processus (détails ci-dessous).J'ai beaucoup googlé cela, mais j'ai trouvé peu de choses qui s'appliquent à mon cas particulier. Je soupçonne qu'il y a quelque chose que je suis négligé, mais je ne peux tout simplement pas sembler le trouver.Voici la commande:<pre><code>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 ; </code></pre>Cela se traduit par le message d'erreur suivant:<pre><code>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. </code></pre>Certaines choses à noter:<ol> <li> Cela ne se produit que sur certaines des instances SQL recevant la plupart d'entre elles exécutant des commandes très similaires sans problème. </li> <li> L'instance qui échoue est une année où il existe plusieurs instances SQL sur la même boîte (Dev et QA) et il tente de restaurer une sauvegarde dB de DR dans la version QA de la même base de données. </li> <li> D'autres DBS dans ce même cas peuvent exécuter leur commande de restauration correspondante sans aucun problème. </li> <li> Il peut être pertinent que les noms de fichier logique source (indiqués dans l'erreur) sont différents des DBS existants (nommés dans la commande), mais je crois que j'ai des cas où cela fonctionne. </li> <li> Aussi, notez soigneusement, que le chemin de fichier signalé par l'erreur n'est pas ce que je spécifie dans le déplacement, mais plutôt le chemin de fichier d'origine (qui dispose-t-il des fichiers DB d'origine utilisés par l'instance DEV). </li> </ol>Il semble donc qu'il essaie d'abord de rétablir les fichiers DB à leurs emplacements de chemin d'origine et ne les déplacez que sur le chemin que je le dis. Cela contraste avec ce que le Doc affirme que cela, et il serait évidemment constitué de manière irrévicile en général, car une personne rétablie une copie de base de données n'a aucun contrôle sur l'endroit où les dossiers d'origine étaient et ne pouvaient pas gauner que de tels chemins existaient et n'étaient pas déjà utilisés. .Toute aide serait grandement appréciée.<hr>Juste pour diriger certaines des réponses automatiques qui ne s'appliquent pas:<ul> <li>La base de données cible n'est pas utilisée actuellement par moi ou quelqu'un d'autre.</li> <li>Il ne se présente pas non plus dans <code>sp_lock</code></li> <li>La commande spécifie <code>REPLACE</code>, il est supposé pour écraser la base de données existante</li> <li>Les fichiers spécifiés ne sont pas ouverts par d'autres processus Windows</li> <li>cependant, le fichier mentionné dans l'erreur sont Ouvrir par l'autre instance SQL sur la boîte</li> <li>l'emplacement du fichier BAK sur une part n'a rien à voir avec cela, la copie localement change rien, ni le renommer.</li> <li>les fichiers DB et les chemins spécifiés sont les bonnes correspondances de la base de données cible</li> </ul>

Recherchez des erreurs de typose ou de syntaxe dans vos noms de fichiers tels que '\\' sur le chemin. Résoudre ceux-ci et votre déclaration fonctionnera.(Bien sûr, une typographie de votre chemin est une version de la réponse donnée ci-dessus concernant un nom de fichier incorrect, mais juste un cas particulier de ce problème!)

Restaurer l'échec avec l'erreur de système d'exploitation 32, fichier utilisé par un autre processus

J'écris un ensemble de procédures pour (partiellement) automatiser le déploiement de DB pour un client, qui fonctionne principalement bien, mais parfois une commande de restauration échoue avec l'erreur de système d'exploitation 32, d'un fichier étant utilisé par un autre processus (détails ci-dessous).

J'ai beaucoup googlé cela, mais j'ai trouvé peu de choses qui s'appliquent à mon cas particulier. Je soupçonne qu'il y a quelque chose que je suis négligé, mais je ne peux tout simplement pas sembler le trouver.

Voici la commande:

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 
    ;

Cela se traduit par le message d'erreur suivant:

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.

Certaines choses à noter:

Cela ne se produit que sur certaines des instances SQL recevant la plupart d'entre elles exécutant des commandes très similaires sans problème.
L'instance qui échoue est une année où il existe plusieurs instances SQL sur la même boîte (Dev et QA) et il tente de restaurer une sauvegarde dB de DR dans la version QA de la même base de données.
D'autres DBS dans ce même cas peuvent exécuter leur commande de restauration correspondante sans aucun problème.
Il peut être pertinent que les noms de fichier logique source (indiqués dans l'erreur) sont différents des DBS existants (nommés dans la commande), mais je crois que j'ai des cas où cela fonctionne.
Aussi, notez soigneusement, que le chemin de fichier signalé par l'erreur n'est pas ce que je spécifie dans le déplacement, mais plutôt le chemin de fichier d'origine (qui dispose-t-il des fichiers DB d'origine utilisés par l'instance DEV).

Il semble donc qu'il essaie d'abord de rétablir les fichiers DB à leurs emplacements de chemin d'origine et ne les déplacez que sur le chemin que je le dis. Cela contraste avec ce que le Doc affirme que cela, et il serait évidemment constitué de manière irrévicile en général, car une personne rétablie une copie de base de données n'a aucun contrôle sur l'endroit où les dossiers d'origine étaient et ne pouvaient pas gauner que de tels chemins existaient et n'étaient pas déjà utilisés. .

Toute aide serait grandement appréciée.

Juste pour diriger certaines des réponses automatiques qui ne s'appliquent pas:

La base de données cible n'est pas utilisée actuellement par moi ou quelqu'un d'autre.
Il ne se présente pas non plus dans sp_lock
La commande spécifie REPLACE, il est supposé pour écraser la base de données existante
Les fichiers spécifiés ne sont pas ouverts par d'autres processus Windows
cependant, le fichier mentionné dans l'erreur sont Ouvrir par l'autre instance SQL sur la boîte
l'emplacement du fichier BAK sur une part n'a rien à voir avec cela, la copie localement change rien, ni le renommer.
les fichiers DB et les chemins spécifiés sont les bonnes correspondances de la base de données cible

sql-serversql-server-2012restore

16 sept. 2014RBarryYoung

Recherchez des erreurs de typose ou de syntaxe dans vos noms de fichiers tels que '\\' sur le chemin. Résoudre ceux-ci et votre déclaration fonctionnera.

(Bien sûr, une typographie de votre chemin est une version de la réponse donnée ci-dessus concernant un nom de fichier incorrect, mais juste un cas particulier de ce problème!)

29 août 2018Mark E