Restaurer la base de données du serveur SQL sans journal des transactions
y a-t-il un moyen, étant donné un SQL Server 2008 .bak fichier, pour restaurer une base de données de l' .bak fichier sans le journal des transactions?
la raison pour laquelle je demande est que la taille du fichier du journal des transactions de cette base de données est énorme - dépassant l'espace disque que j'ai facilement disponible. Je n'ai aucun intérêt dans le journal des transactions, et aucun intérêt dans les transactions inachevées, donc normalement je réduirais simplement le journal à zéro une fois que j'aurais restauré la base de données. Mais ça n'aide pas quand j'ai l'insuffisance de l'espace disque pour créer le journal en premier lieu. Ce dont j'ai besoin, c'est d'un moyen de dire à SQL Server de restaurer seulement les données de la .bak fichier, pas le journal des transactions. Est-il possible de faire cela?
notez que je n'ai aucun contrôle sur la génération du .fichier bak-il provient d'une source externe. Donc rétrécir le journal des transactions avant de générer le .bak fichier n'est pas une option.
5 réponses
C'est vraiment une question pour les sites ServerFault ou DBA, mais la réponse courte est non, vous ne pouvez restaurer la totalité .bak file (laissant de côté les scénarios "exotiques" tels que le groupe de fichiers ou les restaurations au coup par coup). Vous ne dites pas ce que "énorme" signifie, Mais l'espace disque est bon marché; si ajouter plus est vraiment pas une option, alors vous devez trouver une autre façon d'obtenir les données à partir 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, parce qu'il n'y a aucun moyen de restaurer et de rétrécir le fichier journal des transactions en même temps. Cependant, vous pouvez prendre un coup d'oeil à DBA post pour pirater le processus, bien qu'il n'est pas recommandé à tous
vous pouvez également essayer certains outils tiers pour restaurer, en particulier le processus de restauration virtuel qui peut économiser beaucoup d'espace et de temps. Découvrez ApexSQL Restore, Redgate Virtual Restore, Base De Données Virtuelle Idera.
Disclaimer: je travaille pour ApexSQL en tant que ingénieur support
non, le journal des mouvements est requis.
Option 1:
une option peut être de le restaurer à une machine sur laquelle vous avez suffisamment d'espace. Puis sur la copie restaurée de changement de la journalisation en vrac connecté ou simple, réduire les journaux, faire une autre opération de sauvegarde sur cette nouvelle copie et ensuite l'utiliser pour restaurer la machine cible avec le beaucoup plus modeste journal des transactions.
Option 2:
sinon, peut-être que le contact à la source externe pourrait rétrécir le journal des transactions avant de vous l'Envoyer (cela peut ne pas fonctionner si le journal est grand en raison d'un grand nombre de grosses transactions).
Les Docs sur la commande de rétrécir le fichier journal sont disponible ici.
Cela peut ne pas fonctionner puisque vous n'avez aucun contrôle sur la génération de l' .bak fichier, mais si vous pouvez convaincre votre source pour détacher la base de données et ensuite vous envoyer une copie de l' .fichier mdf directement, vous pouvez joindre le .mdf et votre serveur va automatiquement créer un nouveau fichier journal des transactions.
voir sp_detach_db et sp_attach_db (ou créer une base de données database_name pour attacher en fonction de la version de votre serveur sql).
je sais que c'est un vieux fil maintenant, mais je suis tombé sur elle alors que j'avais des problèmes de corruption de journal transactionnel, voici comment je suis arrivé autour sans aucune perte de données (j'ai eu le temps en panne cependant!)
Voici ce que j'ai fait:--
arrêter le service d'instances sql server faire une copie de la base de données concernée .fichier mdf et .fichier ldf (si vous avez un .ndf fichier, copier!) - Juste pour être sûr, vous pouvez toujours mettre ces en arrière si cela ne fonctionne pas pour vous.
redémarrez le service.
connectez-vous à sql management studio et changez le mode de la base de données en simple, puis faites une sauvegarde complète.
changez le type de base de données de nouveau et une fois de plus prendre une sauvegarde complète, puis prendre une sauvegarde de journal transactionnel.
Détacher la base de données.
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 complète de la base de données créée plus tard (Pas celle prise à partir du mode simple) et sélectionnez également la sauvegarde transactionnelle log backup.
Cliquez sur restaurer et il doit le remettre sans la 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'erreurs de journal transactionnel.