DBCC SHRINKFILE sur le fichier de log ne réduit pas la taille, même après le JOURNAL de SAUVEGARDE sur le DISQUE

Ok, c'est une solution pour réduire la taille physique du fichier de transaction, mais sans en changeant le mode de récupération simple.

À l'intérieur de votre base de données, recherchez le file_id du fichier journal à l'aide de la requête suivante.

SELECT * FROM sys.database_files;

Dans mon exemple, le fichier journal est file_id 2. Maintenant, nous voulons localiser les journaux virtuels en cours d'utilisation, et de le faire avec la commande suivante.

DBCC LOGINFO;

Ici, vous pouvez voir si tous les journaux virtuels sont en cours d'utilisation par voir si l'état est de 2 (en cours d'utilisation), ou 0 (libre). Lors de la réduction de fichiers, vide journaux virtuels sont physiquement supprimées à partir de la fin du fichier jusqu'à ce qu'il frappe le premier état. C'est pourquoi la réduction d'un fichier journal des transactions parfois réduit une partie de la route, mais ne supprime pas tous libres journaux virtuels.

Si vous remarquez un statut 2 qui se produisent après 0, c'est le blocage de la réduction de pleinement de réduire le fichier. Pour contourner ce faire une autre sauvegarde du journal des transactions, et immédiatement l'exécution de ces commandes, l'approvisionnement du file_id trouvé ci-dessus, et la taille que vous souhaitez que votre fichier journal doit être réduite.

-- DBCC SHRINKFILE (file_id, LogSize_MB)
DBCC SHRINKFILE (2, 100);
DBCC LOGINFO;

Ce sera ensuite afficher le fichier journal virtuel de répartition, et j'espère que vous remarquerez qu'il est été un peu réduite. Parce que les fichiers journaux virtuels ne sont pas toujours attribués dans l'ordre, vous pouvez avoir une sauvegarde du journal des transactions d'un couple de fois et exécuter cette dernière requête à nouveau; mais je peux normalement le rétrécir au sein d'une sauvegarde ou deux.

Essayer cette

ALTER DATABASE XXXX  SET RECOVERY SIMPLE

use XXXX

declare @log_File_Name varchar(200) 

select @log_File_Name  = name from sysfiles where filename like '%LDF'

declare @i int = FILE_IDEX ( @log_File_Name)

dbcc shrinkfile ( @i , 50) 

De réduire un Fichier Journal

Pour les fichiers journaux, le Moteur de Base de données utilise target_size pour calculer la taille de la cible pour l'ensemble du journal; par conséquent, target_size est la quantité d'espace libre dans le journal, après l'opération de réduction. La taille de la cible pour l'ensemble du journal est ensuite traduit à la taille de la cible pour chaque fichier journal. DBCC SHRINKFILE tente de réduire chaque fichier journal physique à la taille de la cible immédiatement.

Toutefois, si une partie de la logique du journal réside dans les journaux virtuels au-delà de la taille de la cible, le Moteur de Base de données libère autant d'espace que possible, puis émet un message d'information.

Le message décrit quelles actions sont nécessaires pour déplacer la logique journal de journaux virtuels à la fin du fichier. Lorsque les actions sont effectuées, DBCC SHRINKFILE peut être utilisé pour libérer le reste de l'espace.

Parce qu'un fichier journal ne peut être réduit à une limite de fichier journal virtuel, de la réduction d'un fichier journal à une taille plus petite que la taille d'un fichier journal virtuel peut ne pas être possible, même si elle n'est pas utilisée. La taille du fichier journal virtuel est choisi dynamiquement par le Moteur de Base de données lorsque les fichiers journaux sont créés ou étendus.

• De Dépannage: Le Fichier Ne Doit Pas Se Réduire

Si le rétrécissement de l'opération s'exécute sans erreur, mais le fichier ne semble pas avoir changé de taille, de vérifier que le fichier a suffisamment d'espace libre pour supprimer en effectuant l'une des opérations suivantes:

Exécuter la requête suivante.

SÉLECTIONNEZ le nom ,la taille/128.0 - CAST(FILEPROPERTY(nom, 'SpaceUsed') COMME
int)/128.0 COMME AvailableSpaceInMB à PARTIR de sys.database_files;

Exécuter le DBCC SQLPERF commande à retourner à l'espace utilisé dans le journal des transactions.

• Si l'espace disponible est insuffisant, l'opération de réduction ne peut pas réduire la taille de fichier plus loin.

• Généralement c'est le fichier journal qui semble impossible à réduire. C'est généralement le résultat d'un fichier journal qui n'a pas été tronqué.

• Vous pouvez tronquer le journal par la définition de la base de données modèle de récupération SIMPLE, ou par de sauvegarder le journal et puis en exécutant le DBCC SHRINKFILE opération à nouveau.

Exemple :

De réduire un fichier journal spécifié la taille de la cible

L'exemple suivant réduit la taille du fichier journal dans la base de données AdventureWorks à 1 MO. Pour permettre la commande DBCC SHRINKFILE de réduire le fichier, le fichier est tronqué par la définition de la base de données de modèle de récupération SIMPLE.

Transact-SQL

UTILISATION AdventureWorks2012;

ALLER

-- Tronquer le journal par la modification de la base de données de modèle de récupération SIMPLE.

MODIFIER la BASE de données AdventureWorks2012

SET DE RÉCUPÉRATION SIMPLE;

ALLER

-- Réduire le tronquée fichier journal à 1 MO.

DBCC SHRINKFILE (AdventureWorks2012_Log, 1);

ALLER

-- Reset de la base de données modèle de récupération.

MODIFIER la BASE de données AdventureWorks2012

SET DE RÉCUPÉRATION COMPLÈTE;

ALLER

Lorsque vous utilisez DBCC SHRINKFILE(Fichier, taille) il ne tronque à partir de la fin du fichier journal en arrière aussi loin qu'il peut aller. Quand il atteint les plus hauts journal virtuel encore en usage, il ne peut pas rétrécir davantage. Ceci est décrit dans la documentation en Ligne SQL Server à:

http://technet.microsoft.com/en-us/library/ms189493.aspx

Donc, une fois que le haut de gamme du journal est clair, il peut être rétréci vers le bas à la taille. Encore une fois, cela dépendra de la façon dont beaucoup de le journal est encore en usage. Le journal peut être effacé par les sauvegardes, mais les sauvegardes ne sera pas effacer les transactions incomplètes, de sorte que le journal peut rester dans un haut de gamme VLF même après de multiples sauvegardes.

À l'égard de l'augmentation et de la diminution de fichiers journaux virtuels, quelle est le fichier journal créé à l'origine et qu'est-ce que le réglage pour le fichier journal de la croissance? Si elle se développe par une petite quantité qu'il permettra de créer plus de fichiers journaux virtuels que quiconque le désire.

Un modèle commun pour la réduction d'un fichier journal est point de contrôle, de SAUVEGARDE, SHRINKFILE, point de contrôle, de SAUVEGARDE, SHRINKFILE, etc jusqu'à ce que vous obtenez des résultats. Il existe de nombreuses raisons pour que le journal ne peut pas être rétractable, y compris une très grande restauration.

Le passage de la Simple à la Pleine a un Problème:

Il y a des règles et des exceptions ici. Nous allons parler de la longue transactions en cours d'exécution en profondeur ci-dessous.

Mais une mise en garde à garder à l'esprit pour le Mode de Récupération Complet est ceci: Si vous venez de passer en mode de Récupération Complète, mais ne jamais prendre une Sauvegarde Complète initiale, SQL Server ne pas honorer votre demande à être dans le modèle de Récupération Complète. Votre journal des transactions continuera à fonctionner comme il l'a dans Simpleuntil vous passez en mode de Récupération Complète ET de prendre votre première Sauvegarde Complète.

Modèle de Récupération complète sans les sauvegardes du journal est mauvais:

Donc, c'est la raison la plus courante pour incontrôlée de la croissance des journaux? Réponse: en Étant en mode de Récupération Complète sans avoir un journal des sauvegardes.

Cela arrive tout le temps aux gens.

Pourquoi cette erreur commune?

Pourquoi fait-il tout le temps? Parce que chaque nouvelle base de données obtient son premier paramètre du mode de récupération en regardant le modèle de base de données.

Du modèle initial modèle de récupération paramètre est toujours le Modèle de Récupération Complète - jusqu'à ce que et à moins que quelqu'un changements. On pourrait dire que le "mode de Récupération par défaut du Modèle" est Plein. Beaucoup de gens ne sont pas conscients de cela et ont leurs bases de données fonctionnant en mode de Récupération Complète sans les sauvegardes du journal, et, par conséquent, un fichier journal des transactions beaucoup plus grande que nécessaire. C'est pourquoi il est important de changer les valeurs par défaut quand ils ne travaillent pas pour votre organisation et de ses besoins)

Grâce à @user2630576 et @Ed.S.

la suite travaillé un régal:

BACKUP LOG [database] TO DISK = 'D:\database.bak'
GO

ALTER DATABASE [database] SET RECOVERY SIMPLE

use [database]

declare @log_File_Name varchar(200)

select @log_File_Name = name from sysfiles where filename like '%LDF'

declare @i int = FILE_IDEX ( @log_File_Name)

dbcc shrinkfile ( @i , 50)

ALTER DATABASE [database] SET RECOVERY FULL