web-dev-qa-db-fra.com

Sauvegarder une base de données sur un disque dur avec une taille de secteur différente

Dans notre environnement de développement, nous utilisons depuis longtemps un script de sauvegarde et de restauration particulier pour chacun de nos produits via différentes versions de SQL Server et différentes configurations d'environnement sans aucun problème.

Récemment, nous avons mis à niveau vers SQL Server 2012 en tant que serveur de développement standard avec SQL Compatibility Level 2005 (90) pour maintenir la prise en charge des systèmes hérités. Nous constatons maintenant que sur la machine d'un développeur particulier, nous obtenons l'erreur suivante lors de la tentative de sauvegarde de la base de données:

Impossible d'utiliser le fichier de sauvegarde 'D:\MyDB.bak' car il a été initialement formaté avec la taille de secteur 512 et se trouve maintenant sur un périphérique avec la taille de secteur 4096. LA BASE DE DONNÉES DE SAUVEGARDE se termine anormalement.

La commande étant:

BACKUP DATABASE MyDB TO  DISK = N'D:\MyDB.bak' WITH  INIT , NOUNLOAD ,  NAME = N'MyDB backup',  NOSKIP ,  STATS = 10,  NOFORMAT

La chose curieuse est que ni le matériel ni les partitions sur la machine de ce développeur n'ont changé, même si leur taille de secteur est différente, cela n'a pas été un problème auparavant.

D'après mes recherches (c.-à-d. Googler), il n'y a pas grand-chose sur cette question à part les conseils pour utiliser le WITH BLOCKSIZE option, mais cela me donne alors le même message d'erreur.

Ma requête étant:

BACKUP DATABASE MyDB TO  DISK = N'D:\MyDB.bak' WITH  INIT , NOUNLOAD ,  NAME = N'MyDB backup',  NOSKIP ,  STATS = 10,  NOFORMAT, BLOCKSIZE = 4096

Quelqu'un peut-il nous expliquer comment je peux sauvegarder et restaurer une base de données sur des disques durs de différentes tailles de secteur?

20
codemonkeh

Ce problème est dû à différentes tailles de secteur utilisées par différents lecteurs.

Vous pouvez résoudre ce problème en remplaçant votre commande de sauvegarde d'origine par:

BACKUP DATABASE MyDB TO  DISK = N'D:\MyDB.bak' WITH  INIT , NOUNLOAD ,  NAME = N'MyDB backup',  STATS = 10,  FORMAT

Notez que j'ai changé NOFORMAT en FORMAT et supprimé NOSKIP.

Vous avez trouvé un indice pour résoudre ce problème dans la section des commentaires du billet de blog suivant sur MSDN: SQL Server – Espaces de stockage/VHDx et taille de secteur 4K

Et plus d'informations sur les lecteurs de secteur 4k: http://blogs.msdn.com/b/psssql/archive/2011/01/13/sql-server-new-drives-use-4k-sector-size. aspx

22
Will L

Tout ce que vous avez à faire est de le sauvegarder avec un nom différent.

28
Michael

Supprimez simplement le fichier .bak existant et réexécutez.

6
Gayan Dasanayake

Nous avons eu le même problème entre 2005 et 2008. Le problème était que nous essayions d'utiliser le même fichier de sauvegarde en 2008 que nous avons utilisé en 2005 (en ajoutant les sauvegardes ensemble dans 1 fichier).

Nous avons changé le script pour le sauvegarder dans un fichier différent et le problème a été résolu. J'imagine que déplacer/supprimer l'ancien fichier aurait le même effet

4
Greg

J'ai rencontré le même problème que l'OP. Sur une machine de développement, nous avions un script PowerShell qui sauvegardait les bases de données à partir de serveurs de bases de données distants et stockait les fichiers de sauvegarde localement. Le script a écrasé les mêmes fichiers de sauvegarde, encore et encore, et le script fonctionnait bien depuis quelques années. Ensuite, j'ai cloné le lecteur multimédia en rotation sur un SSD dans la machine de développement. Soudain, nous obtenions la même erreur que l'OP:

Backup-SqlDatabase: System.Data.SqlClient.SqlError: Impossible d'utiliser le fichier de sauvegarde '\ DevMachine\Back-Up\Demo.bak' car il a été initialement formaté avec la taille de secteur 4096 et se trouve désormais sur un appareil avec la taille de secteur 512.

Bien sûr, je pourrais supprimer tous les .bak fichiers pour résoudre le problème. Mais que se passe-t-il si cela se produit à nouveau? Je voulais une solution en ligne de commande qui fonctionne de manière cohérente.

Voici notre code d'origine:

Backup-SqlDatabase -ServerInstance "DBServer1" -Database "Demo" -BackupFile "\\DevMachine\Back-Up\Demo.bak" -BackupAction Database -CopyOnly -CompressionOption On -ConnectionTimeout 0 -Initialize -Checksum -ErrorAction Stop

Après quelques tripotages, je l'ai changé comme suit pour résoudre le problème:

Backup-SqlDatabase -ServerInstance "DBServer1" -Database "Demo" -BackupFile "\\DevMachine\Back-Up\Demo.bak" -BackupAction Database -CopyOnly -CompressionOption On -ConnectionTimeout 0 -Initialize -Checksum -FormatMedia -SkipTapeHeader -ErrorAction Stop

Fondamentalement, les options suivantes ont été ajoutées pour résoudre le problème:

-FormatMedia -SkipTapeHeader

Notez que si vous lisez la documentation du Backup-SqlDatabase applet de commande, -FormatMedia est répertorié comme s'appliquant uniquement aux bandes et non aux sauvegardes sur disque. Cependant, il semble faire le travail de suppression du fichier de sauvegarde existant lors de la sauvegarde sur disque.
- https://docs.Microsoft.com/en-us/powershell/module/sqlps/backup-sqldatabase

J'ai trouvé que si j'utilisais le -FormatMedia option seule, elle a généré l'erreur suivante:

Backup-SqlDatabase: les propriétés FormatMedia et SkipTapeHeader ont des paramètres en conflit.

J'ai corrigé la deuxième erreur en ajoutant une option supplémentaire: -SkipTapeHeader. De toute évidence, cela est également destiné aux sauvegardes sur bande, mais cela a fonctionné.

3
Van Vangor

J'ai eu le même problème, mais juste avec restaurer. J'ai obtenu cette erreur dans Management Studio: "La distribution spécifiée n'est pas valide. (SqlManagerUI)" ... et cette erreur dans la requête: "SQL Server ne peut pas traiter cette famille de supports."

Ensuite, j'ai fait une chose simple: j'ai copié le jeu de sauvegarde dans le dossier de sauvegarde par défaut. Par exemple: C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS2008R2\MSSQL\Backup\bckup.bak Cela a fonctionné. Je l'ai restauré à partir de cet endroit. : -S Il semble que le SQL soit sensible à la taille du secteur.

0
etveszprem