web-dev-qa-db-fra.com

Problème de réduction du journal SQL Server

Duplicata possible:
Pourquoi le journal des transactions continue-t-il de croître ou de manquer d'espace?

J'ai un journal de base de données de 300 Go dans notre serveur SQL. Je veux réduire tous les journaux mais cela ne me permet pas de le faire. J'ai essayé en utilisant la requête et l'interface utilisateur dans SQL Server 2008 R2. j'ai utilisé

USE UserDB;
GO
DBCC SHRINKFILE (DataFile1, 7);
GO

Mais sans erreur, les journaux de base de données ne diminuent pas.

Ensuite, je veux utiliser une autre méthode comme ci-dessous:

Je détacherai la base de données de SQL Server, puis après le déplacement particulier .LDF fichier à un autre emplacement et attachez uniquement le fichier de base de données à SQL Server. Je suis en mesure de déplacer avec succès tous les journaux de SQL Server vers un autre serveur.

Veuillez me faire savoir qu'il s'agit d'une bonne pratique pour déplacer le journal des transactions vers un autre lecteur. Sinon, veuillez suggérer une autre solution pour récupérer du journal de base de données en diminution.

sql-serversql-server-2008
7
kuldeep verma

Si vous réduisez un fichier journal, vous ne pourrez pas le réduire moins que la partie journal active. En d'autres termes, si vous êtes dans Modèle de récupération complète , et que vous n'avez effectué aucune sauvegarde du journal des transactions (c'est pourquoi il aurait pu devenir aussi important ), puis exécutez un DBCC SHRINKFILE ne fera absolument rien.

BOL a un exemple sur la façon de procéder:

USE AdventureWorks2012;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2012
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2012_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2012
SET RECOVERY FULL;
GO

Cela a été tiré directement de BOL sur DBCC SHRINKFILE .

Il convient de noter dans l'exemple ci-dessus que la modification du modèle de récupération en simple rompt la chaîne de journaux. Ainsi, une fois cette opération terminée, vous devez démarrer immédiatement une nouvelle chaîne de journaux en exécutant une sauvegarde de la base de données.

Il convient également de noter que si votre fichier journal se développe comme celui-ci, vous ne prenez pas [suffisamment] de sauvegardes du journal des transactions (à condition que vous soyez en effet en mode de récupération complète, car cela ne se produirait que dans de très rares situations dans Simple Recovery). Vous devrez peut-être commencer à prendre des sauvegardes du journal des transactions ou sauvegarder votre journal plus souvent afin qu'il tronque le journal de trans et crée une partie du fichier réutilisable afin que vous n'ayez pas cette croissance de fichier.

11
Thomas Stringer

Quelques points non mentionnés dans les autres réponses.

Il peut y avoir d'autres raisons pour lesquelles le journal ne s'efface pas en plus d'un manque de sauvegardes de journal (bien que ce soit généralement le cas), comme la mise en miroir ou la réplication de base de données.

Exécutez cette requête pour déterminer le modèle de récupération de la base de données et pourquoi le journal des transactions ne peut pas être effacé:

SELECT
    name,
    log_reuse_wait_desc,
    recovery_model_desc
    FROM sys.databases

La liste complète des log_reuse_wait_desc des valeurs peuvent être trouvées ici . Comme mentionné, vous verrez probablement LOG_BACKUP, mais il est bon de s'assurer qu'il ne se passe rien d'autre dans la situation qui pourrait compliquer les choses.

Vous pouvez utiliser une commande sûre non documentée DBCC LOGINFO (exécuté dans le contexte de la base de données cible) pour vider les informations sur les fichiers journaux virtuels du journal des transactions (également appelés VLF, décrits dans une autre réponse). Une valeur d'état de 2 signifie que VLF est utilisé et un 0 signifie qu'il n'est pas utilisé (une valeur de 1 n'est pas possible).

Comme une autre réponse l'a mentionné, SQL Server ne réduira un fichier journal que depuis le dernier VLF en cours d'utilisation.

Si la base de données est dans FULL ou BULK_LOGGED récupération et vous voyez beaucoup de zéros, mais un 2 sur le dernier, vous devrez peut-être attendre certaines transactions sur la base de données pour que le journal se termine, puis prendre une sauvegarde du journal pour effacer les VLF de fin, et enfin exécuter à nouveau le psy.

Si la base de données est en cours de récupération SIMPLE, vous devrez peut-être exécuter manuellement un CHECKPOINT pour lancer l'effacement du journal avant de tenter de réduire à nouveau.

5
Jon Seigel

Un moyen sûr de réduire le fichier ldf consiste à basculer vers un modèle de récupération simple, puis à effectuer une réduction.

Utilisation de SQL Server Management Studio:

  1. Connectez-vous au serveur SQL.
  2. Développez le dossier "Bases de données", faites un clic droit sur la base de données, sélectionnez les propriétés.
  3. Dans la page "Options", changez "Modèle de récupération:" en "Simple" et appuyez sur le bouton "OK".
  4. Vous voudrez peut-être/devrez sauvegarder la base de données (cliquez avec le bouton droit sur la base de données, Tâches\Sauvegarder ...).
  5. Faites un clic droit sur la base de données, ouvrez le sous-menu "Tâches", ouvrez le sous-menu "Rétrécir" et sélectionnez "Base de données".
  6. Dans la nouvelle fenêtre, cochez la case "réorganiser les fichiers avant de libérer de l'espace inutilisé". cochez la case et appuyez sur le bouton "OK".
  7. Faites un clic droit sur la base de données, ouvrez le sous-menu "Tâches", ouvrez le sous-menu "Rétrécir" et sélectionnez "Fichiers".
  8. Pour "Type de fichier:" sélectionnez "Journal".
  9. Assurez-vous que le bouton radio "Libérer l'espace inutilisé" est sélectionné et appuyez sur le bouton "OK".

Cela résoudra votre problème, bien que vous ne puissiez plus restaurer à partir des journaux de transactions. Consultez la documentation pour voir quel modèle de récupération vous convient le mieux. J'utilise généralement simple car nous faisons un grand nombre d'insertions, et les sauvegardes horaires/quotidiennes sont assez bonnes pour nos besoins. De plus, si vous utilisez simple, le journal ne devient pas si grand.

Si vous ne souhaitez pas modifier le type de récupération, essayez d'effectuer une sauvegarde complète avant de réduire la base de données et les fichiers de base de données. Il est recommandé que vous définissiez "l'espace libre maximal dans les fichiers après réduction" à au moins 10% sur l'écran de réduction de la base de données pour des raisons de performances. Si vous utilisez une base de données avec un journal qui peut atteindre 300 Go assez rapidement, vous voudrez la laisser beaucoup plus grande et définir le "Fichier de réduction sur:" à 1024 Mo sur l'écran "Fichier de réduction".

Faites-nous savoir si vous avez besoin d'aide, sinon veuillez accepter une réponse. La communauté n'aime pas répondre aux questions des personnes qui n'acceptent pas les réponses. :)

Modifier : les étapes ci-dessus auraient dû fonctionner. Vous avez probablement fait quelque chose de mal (comme sélectionner la mauvaise base de données). Pour une autre manière de le faire, veuillez consulter cet article .

De plus, lorsque vous effectuez la sauvegarde, assurez-vous que le "Type de sauvegarde:" est plein, que la case à cocher "Copie uniquement" n'est pas cochée et que "Base de données" est sélectionné sous "Composant de sauvegarde:". Si possible, sélectionnez le bouton radio "Tronquer le journal des transactions" pour "Journal des transactions" sur la page "Options".

Essayez de mettre la base de données hors ligne, puis de la remettre en ligne avant d'exécuter les étapes ci-dessus. S'il ne se déconnecte pas, vous devrez interrompre manuellement les connexions SQL (les utilisateurs sont toujours connectés à la base de données, empêchant ces modifications).

Si ces options ne fonctionnent toujours pas, vous devrez utiliser une méthode moins sûre, comme sauvegarder la base de données dans un fichier et la restaurer sur la base de données existante, puis réduire les fichiers.

Autres liens :

Assurez-vous également que vous modifiez la base de données associée au fichier. Pour ce faire, ouvrez les propriétés de la base de données et accédez à la page "Fichiers".

3
Trisped

J'ai eu le même problème avec le fichier journal croissant sur une base de données qui s'exécutait en mode simple. Le fichier journal avait atteint 70 gig. même après un point de contrôle, je n'ai toujours pas pu réduire le fichier journal. J'utilisais la réplication avec un instantané. Le service sql abonné ne fonctionnait pas depuis quelques jours. J'ai pu résoudre le problème en ajustant les propriétés de publication sur l'éditeur par défaut d'un très grand nombre d'heures à une heure. Après quoi j'ai pu vérifier et réduire le journal.

0
Remy

je ne répéterai pas ce que @Trisped a dit, que si vous convertissez en récupération simple, quelles seront les conséquences et également la nécessité de sauvegarder votre base de données avant de faire les étapes ci-dessous

Le code ci-dessous convertira votre récupération de base de données en simple et réduira le fichier journal des transactions à son minimum et définira à nouveau la récupération au cas où vous le souhaitez

ALTER DATABASE [DBNAME] SET RECOVERY SIMPLE;
use DBNAME
DBCC SHRINKFILE(DBNAME_log,1)
ALTER DATABASE [DBNAME] SET RECOVERY FULL;

mais je recommande avant de réduire le fichier pour voir les résultats de la

DBCC SQLPERF(LOGSPACE)

Cela vous montrera la taille de chaque fichier journal de chaque base de données et vous montrera quel espace utilisé dans le journal des transactions

ou

Si l'opération de réduction s'exécute sans erreur comme vous l'avez dit, mais que le fichier ne semble pas avoir changé de taille, vérifiez que le fichier dispose d'un espace libre suffisant à supprimer en effectuant l'une des opérations suivantes:

Exécutez la requête suivante.

use DBNAME
 SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;

je recommande de lire ce qui suit

http://msdn.Microsoft.com/en-us/library/ms189493.aspx Section Remarques

et lisez également sur (Réduction du journal des transactions) http://msdn.Microsoft.com/en-us/library/ms178037 (SQL.105) .aspx

vous devez noter qu'un fichier journal peut uniquement être réduit à une limite de fichier journal virtuel, la réduction d'un fichier journal à une taille inférieure à la taille d'un fichier journal virtuel peut ne pas être possible, même s'il n'est pas utilisé

pour en savoir plus sur ce qu'est un Fichiers journaux virtuels Lisez ici http://msdn.Microsoft.com/en-us/library/ ms179355 (SQL.105) .aspx

Le moteur de base de données SQL Server divise chaque fichier journal physique en interne en un certain nombre de fichiers journaux virtuels. Les fichiers journaux virtuels n'ont pas de taille fixe et il n'y a pas de nombre fixe de fichiers journaux virtuels pour un fichier journal physique. Le moteur de base de données choisit dynamiquement la taille des fichiers journaux virtuels lors de la création ou de l'extension des fichiers journaux. Le moteur de base de données essaie de conserver un petit nombre de fichiers virtuels. La taille des fichiers virtuels après l'extension d'un fichier journal est la somme de la taille du journal existant et de la taille du nouvel incrément de fichier. La taille ou le nombre de fichiers journaux virtuels ne peuvent pas être configurés ou définis par les administrateurs.

la deuxième partie des questions Je détacherai la base de données de SQL Server, puis après le déplacement du fichier .LDF particulier vers un autre emplacement et ne rattacherai que le fichier de base de données à SQL Server

si vous détachez et déplacez le fichier ldf, lorsque vous essayez de le joindre à nouveau, vous verrez un message (introuvable) et vous aurez la possibilité de pointer vers son nouvel emplacement ou de le supprimer et si vous le supprimez un un nouveau fichier journal des transactions sera créé .

Dernière partie de vos questions

Veuillez me faire savoir qu'il s'agit d'une bonne pratique pour déplacer le journal des transactions vers un autre lecteur. Sinon, veuillez suggérer une autre solution pour récupérer du journal de base de données en diminution.

Le détachement et l'attachement est une bonne méthode si vous pouvez arrêter l'application qui est dans votre cas empêcher les utilisateurs d'utiliser sharepoint.

0
AmmarR

J'ai récemment rencontré un problème avec une base de données dont le fichier journal ne cessait de croître même avec des sauvegardes de journaux. J'ai finalement découvert que cela avait quelque chose à voir avec la réplication de cliché qui se produisait dans la base de données. Une fois que j'ai changé la réplication de Snapshot en Transactionnel, le démarrage enregistré fonctionne à nouveau comme prévu.

Vérifiez et voyez si la réplication est en cours d'exécution sur cette base de données.

0
DForck42