La sauvegarde échoue - pas assez d'espace disque
J'ai une sauvegarde d'environ 6 Go. Il s'agit d'une sauvegarde "légère" de l'original (avec les tables de journal purgées), qui est d'environ 14 Go.
J'essaie de restaurer la sauvegarde sur mon serveur local SQL Express. Il échoue avec un message comme: System.Data.SqlClient.Error: insufficient disk space. Il demande 227 891 019 776 octets, ce qui est absolument fou et presque aussi gros que mon disque dur.
Comme sur d'autres sites, j'ai essayé RESTORE FILELISTONLY FROM DISK = 'backupfile.bak'.
Le fichier de données (colonne Size) a une taille de 6 888 226 816, mais le fichier journal est de 221 006 987 264. La colonne BackupSizeInBytes renvoie 6 259 736 576 et 0.
Donc, si je comprends bien, restaurer vérifie que j'ai suffisamment d'espace pour restaurer la taille "théorique" du fichier journal avant de continuer, sans tenir compte de la taille réelle du fichier journal?
Comment puis-je contourner cela? C'est un peu difficile d'obtenir une sauvegarde, donc si je peux résoudre mon problème sans avoir à revenir sur le serveur de production, ce serait génial.
Merci !
Oh BTW, je suis sur SQL Server 2008 R2 Express.
Notez que la taille de la sauvegarde n'inclut pas les pages vides, mais lorsque vous effectuez réellement la restauration, les données et les fichiers journaux seront dépassent 200 Go, car ils doivent restaurer exactement ce que le système source avait (y compris un fichier journal de plus de 200 Go, quelle que soit sa taille).
Si vous ne voulez pas risquer de perdre des données, vous devez corriger cela à la source (par exemple, réduire le fichier journal à quelque chose de raisonnable), prendre une autre sauvegarde complète et restaurer cela. Je ne suis pas sûr de comprendre pourquoi il est difficile d'obtenir une sauvegarde - c'est une opération assez standard et devrait être un service fourni par toute personne que vous payez à Host SQL Server.
Vous devez également corriger la base de données source pour (a) être dans le bon modèle de récupération ou (b) effectuer des sauvegardes de journaux plus fréquemment. Votre fichier journal est ridicule car vous êtes en pleine récupération et ne faites jamais de sauvegarde de journal. Si vous avez besoin d'une récupération ponctuelle, commencez à sauvegarder votre journal. Si vous ne le faites pas, passez au simple. Le fichier journal doit se gérer lui-même si vous l'avez configuré correctement. Si vous ne le faites pas, alors quand cela devient comme ça, le rétrécissement devrait être une opération unique, puis vous devriez corriger la configuration afin que vous ne recommenciez pas la semaine prochaine ...
DBCC TRACEON (3104) contournera les vérifications d'espace disque pour les processus de restauration.
Il n'y avait pas eu de sauvegarde du journal des transactions pour permettre la réutilisation du journal. Il doit donc obtenir tout ce journal vide pour accéder aux parties où il peut y avoir des transactions dont il a besoin pour récupérer.
Donc, en supposant que vous êtes prêt à subir une perte de données (peut-être beaucoup), vous pouvez le récupérer sans le journal. Ce n'est pas recommandé.
Voici un lien vers le large sujet de la récupération de base de données SQL Server, http://www.sqlskills.com/blogs/paul/category/disaster-recovery/ . Vous n'êtes pas seul: http://www.sqlskills.com/blogs/paul/search-engine-qa-23-my-transaction-log-is-full-now-what/ . Enfin, pour quelques commandes qui peuvent aider dans cette situation, encore une fois non recommandé (vous subirez presque certainement une perte de données) http://blog.sqlauthority.com/2010/04/26/sql-server-attach -mdf-file-without-ldf-file-in-database / .
Si vous avez toujours la base de données d'origine en ligne. et, vous n'avez pas d'envoi de journaux, de réplication ou n'utilisez pas vos sauvegardes de journal des transactions. Ensuite, vous pouvez exécuter ALTER DATABASE {name} SET RECOVERY SIMPLE, qui vide le journal des transactions (ce qui vous permettra plus tard de réduire ce fichier). Ensuite, exécutez BACKUP DATABASE {name} TO DISK = '{file}'. Copiez le fichier sur votre nouveau serveur et RESTORE DATABASE {new_name} TO DISK = '{file}'. Vous devrez peut-être remapper les fichiers logiques vers de nouveaux emplacements à l'aide de WITH .. MOVE {x} TO {new_file}, voir URL http://msdn.Microsoft.com/en-us/library/ms177429 .aspx pour plus de syntaxe. Après la sauvegarde, vous pouvez exécuter ALTER DATABASE {name} SET RECOVERY FULL, pour rétablir la base de données d'origine en utilisant le modèle de récupération complète (vous devez également le faire pour votre nouvelle copie). Vous pouvez également trouver les éléments suivants utiles si ces étapes tournent mal: http://www.sqlskills.com/blogs/paul/category/backuprestore/ .
Si vous vouliez libérer de l'espace sur le disque pour mettre la nouvelle sauvegarde (après le SET RECOVERY et avant la BACKUP). Vous devez exécuter use {database_name}; EXEC sp_helpdb {nom_base_de_données} puis recherchez dans le résultat la ligne avec la colonne qui a la valeur d'utilisation "journal uniquement". Ensuite, utilisez-la comme valeur pour {filename} dans le fichier de rétrécissement dbcc ('{filename}', 1024), ce qui devrait réduire le fichier .LDF à 1 Go (c'est-à-dire que la taille est en Mo). N'UTILISEZ PAS le fichier rétractable sur les fichiers de données, uniquement les fichiers journaux, consultez le site Paul Randall référencé ci-dessus pour plus de détails sur ce dernier.