Restaurer la base de données SQL Server sans journal des transactions
Avec un fichier SQL Server 2008.bak, existe-t-il un moyen de restaurer le fichier data uniquement à partir du fichier .bak, sans le journal des transactions?
La raison pour laquelle je vous pose la question est que la taille du fichier du journal des transactions de cette base de données est énorme - dépassant l'espace disque disponible.
Je n'ai aucun intérêt dans le journal des transactions et aucun intérêt dans les transactions non terminées. Normalement, je ramènerais simplement le journal à zéro, une fois la base de données restaurée. Mais cela n’aide en rien lorsque j’ai suffisamment d’espace disque pour créer le journal.
Ce dont j'ai besoin, c'est d'un moyen d'indiquer à SQL Server de ne restaurer que les données du fichier .bak, pas le journal des transactions. Y'a-t'il un quelconque moyen d'y arriver?
Notez que je n’ai aucun contrôle sur la génération du fichier .bak - il provient d’une source externe. Réduire le journal des transactions avant de générer le fichier .bak est une option pas.
C'est vraiment une question pour les sites ServerFault ou DBA, mais la réponse courte est non, vous pouvez uniquement restaurer le fichier .bak complet (en laissant de côté les scénarios "exotiques" tels que les restaurations par groupes de fichiers ou fragmentées). Vous ne dites pas ce que "énorme" signifie, mais l'espace disque est bon marché; Si l'ajout de plusieurs n'est pas vraiment une option, vous devez trouver un autre moyen d'obtenir les données de votre source externe.
Le journal des transactions fait partie intégrante de la sauvegarde. Vous ne pouvez pas dire à SQL Server d'ignorer le journal des transactions, car il n'existe aucun moyen de restaurer et de réduire le fichier du journal des transactions en même temps. Cependant, vous pouvez jeter un oeil à poste DBA pour pirater le processus, bien que ce ne soit pas recommandé du tout
Vous pouvez également utiliser des outils tiers pour la restauration, en particulier un processus de restauration virtuelle qui peut vous faire gagner beaucoup d’espace et de temps. Consultez ApexSQL Restore , RedGate Virtual Restore, base de données virtuelle Idera.
Disclaimer: Je travaille pour ApexSQL en tant qu'ingénieur support
Non, le journal des transactions est requis.
Option 1:
Une option peut être de le restaurer sur une machine sur laquelle vous disposez d'assez d'espace. Ensuite, sur la copie restaurée, modifiez la consignation en journal en bloc ou simple, réduisez les journaux, effectuez une autre opération de sauvegarde sur cette nouvelle copie, puis utilisez-la pour restaurer sur la machine cible avec le journal de transactions beaucoup plus petit.
Option 2:
Sinon, le contact de la source externe pourrait peut-être réduire le journal des transactions avant de vous l'envoyer (cela risque de ne pas fonctionner si le journal est volumineux en raison de nombreuses transactions volumineuses).
Les documents de la commande permettant de réduire le fichier journal sont disponible ici .
Cela peut ne pas fonctionner car vous n'avez aucun contrôle sur la génération du fichier .bak, mais si vous pouviez convaincre votre source de détacher la base de données puis vous envoyer une copie du fichier .mdf directement, vous pouvez ensuite joindre le votre serveur créerait automatiquement un nouveau fichier journal de transaction vide.
Voir sp_detach_db et sp_attach_db (ou CREATE DATABASE nom_bdd pour ATTACH selon la version de votre serveur SQL).
Je sais que c’est un vieux fil maintenant, mais j’en suis tombé par hasard alors que j’avais des problèmes de corruption de journaux transactionnels. Voici comment j’ai pu le contourner sans aucune perte de données (j’ai eu du temps mort!).
Voici ce que j'ai fait:--
Arrêtez le service d'instance de serveur SQL Faites une copie du fichier .mdf et .ldf de la base de données affectée (si vous avez un fichier .ndf, copiez-le également!) - Pour être sûr, vous pouvez toujours les remettre si cela ne fonctionne pas pour vous.
redémarrez le service.
Connectez-vous à SQL Management Studio et changez le mode de base de données en simple, puis effectuez une sauvegarde complète.
Modifiez à nouveau le type de base de données et effectuez à nouveau une sauvegarde complète, puis effectuez une sauvegarde du journal transactionnel.
Détachez la base de données.
Faites un clic droit sur les bases de données et cliquez sur restaurer, sélectionnez le nom de la base de données dans la liste déroulante, sélectionnez la sauvegarde de base de données complète créée ultérieurement (pas celle prise en mode simple) et sélectionnez également la sauvegarde du journal transactionnel.
Cliquez sur restaurer et il devrait tout remettre en place sans aucune corruption dans les fichiers journaux.
Cela a fonctionné pour moi sans erreur et mes sauvegardes ont toutes fonctionné correctement par la suite et il n'y avait plus d'erreur de journal transactionnel.