Est-il possible de restaurer sql-server bak et de réduire le journal en même temps?

26

Nous avons un fichier bak d'un client que nous avons transféré à nos bureaux de développement pour une enquête sur les problèmes. La sauvegarde est actuellement de 25 Go et la base de données restaurée est à peu près de la même taille, mais elle a besoin de 100 Go pour être restaurée. Je pense que c'est parce que la base de données est configurée pour avoir une taille de journal des transactions de 75 Go. Après avoir restauré la base de données, nous pouvons réduire le fichier journal, mais existe-t-il un moyen de le faire dans la restauration?

— Adam Butler
source

3

Que je sache, vous ne pouvez pas modifier la base de données avant la fin de la restauration.

— Shawn Melton

3

J'ai été dans la même situation et j'attends avec impatience la réponse. Juste pour commenter, il y a un produit: la restauration virtuelle SQL de red-gate. Je n'ai jamais utilisé cela, mais selon le site: «La base de données montée nécessite un stockage supplémentaire proche de zéro sur le fichier de sauvegarde».

— StanleyJohns

16

Il n'y a aucun moyen de réduire la sauvegarde dans le cadre du processus de restauration. La base de données restaurée doit ressembler exactement à la base de données source, à la seule exception étant que vous pouvez modifier les lettres de lecteur et les dossiers.

— mrdenny
source

34

Il y a un hack d' environnement à ne pas faire, que vous pouvez utiliser lorsque l'espace est limité, en restaurant le fichier journal dans un dossier compressé. Essayez cela en compressant un dossier existant et en le restaurant entraînera une erreur, vous devez donc tricher avec un lien symbolique.

Créer un dossier compressé D:\LogCompressed\
Créer un lien symbolique vers le dossier compressé mklink /D /J D:\Log\ D:\LogCompressed\
Restaurez votre base de données avec le fichier ldf pointant vers D:\Log\
Réduire le fichier journal à une taille appropriée
Détachez la base de données, déplacez le fichier journal dans un dossier non compressé, attachez

C'est sale, c'est de la triche, NE LE FAITES JAMAIS EN DIRECT , mais ça marche. Un test rapide d'une base de données nouvellement créée avec un fichier journal de 32 Mo montre qu'elle occupe 330 Ko sur le disque lorsqu'elle est compressée, décompressez le dossier et que la taille du disque est de retour à 32 Mo.

— Mark Storey-Smith
source

2

@Mark: Ce hack fonctionne, mais pas parfait. Même si le fichier journal prend beaucoup moins d'espace que sa taille réelle, vous ne pouvez pas restaurer la base de données à moins que le disque ne dispose vraiment d'espace libre autant que la taille réelle de la base de données. Besize, pendant la restauration, la taille réelle du fichier journal diminue lentement par rapport à la taille réelle, c'est douloureux. Cependant, c'est toujours un très bon hack. Merci.

— chenwq

9

Je pense que la raison pour laquelle votre sauvegarde est de 25 Go et que la base de données restaurée est de 100 Go n'est pas due à votre journal des transactions. Ce que je suppose, vos fichiers de base de données ont 100 Go d'espace alloué et il y a 25 Go de données réelles dans la base de données.

Il existe une différence entre l' espace de fichiers de base de données alloué et l'espace de données utilisé . Dans ce cas, le premier est de 100 Go et le second de 25 Go.

— Thomas Stringer
source

1

Le client alloue 75 Go à son journal des transactions. Après la restauration, je modifie actuellement l'allocation du journal à 1 Go. Si possible, je voudrais restaurer cette base de données sur un serveur où les disques ont moins de 100 Go d'espace libre. Sans avoir à restaurer sur un autre serveur, tronquer, sauvegarder et restaurer à nouveau.

— Adam Butler

@Adam Butler, serait-il possible de restaurer temporairement sur le premier serveur afin de pouvoir réduire la taille des fichiers, puis de faire une sauvegarde de la copie et de la restaurer sur le serveur de destination?

— DForck42