Discussion :

[zaki_1982]

je veux reduire la taille d'un fichier de LOG sous SQL Server 2000 avec un script j'ai trouvé un script le voila
USE NOM_DATABASE
BACKUP log NOM_DATABASE WITH TRUNCATE_ONLY
DBCC SHRINKFILE (NOM_DATABASE_LOG ,0)
mais ma demande est ce qu'il la posibilité d'appliquer ce script sur toutes les base de données en passant le nom de la base comme paramétre càd je récupère le nom de la base dans variable et je l'intégre sur le script

merci

[SQLpro]

Utilisez du SQL dynamique pour ce faire.

A +

[zaki_1982]

merci bq
mais je veux just savoir est ce que cette syntaxe est correct

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
DECLARE @titre VARCHAR(50)
DECLARE @titre1 VARCHAR(50)
SET @titre = 'mabase'
SET @titre1 = 'mabase_log'
USE @titre
GO
 
DBCC SHRINKFILE(@titre1, 2)
 
BACKUP LOG @titre WITH TRUNCATE_ONLY
 
DBCC SHRINKFILE(@titre1, 2)

pr ce que je veux faire un boucle sue la base master et récupérer les nom des table sur la variable @titre pour truncker toutes les base de données user

merci

[elsuket]

Bonsoir,

J'imagine que vous cherchez cette requête pour faire un traitement automatique sur vos bases de données : il vaut mieux que vous fassiez cela à la main et en cas d'urgence seulement (plus d'espace disque), sinon vous briserez la chaîne des backups et si l'une de vos base de données crashent ... vous n'aurez pas les données entre le dernier backup complet et le moment du crash

Dans un premier temps regardez la méthode de recouvrement de vos bases de données : FULL, SIMPLE ou BULK LOGGED ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases

Lisez ceci pour savoir ce que vous devez faire et ce qui retarde la troncation de votre journal de transactions

[fleure]

Bonjour, je souhaite réduire la taille du fichier journal d'évenement dans SQL server 2008.
Merci pour votre aide.

[mikedavem]

Bonjour,

Si vous parlez du journal des transactions d'une base de données utilisez la commande DBCC SHRINKFILE

++

[nigmat]

Bonjour!,

J'ai déjà fait le tour de cet article

par contre j'ai quelques gestions à vous poser.

Voici mon problème:
Mon boss me demande de réduire la taille du fichier log d'une base de données en production (sql server 2000)et de mettre place un plan de maintenance( planifié pour demain à 12:00AM).

Questions

Est-il possible de réduire la taille du fichier au même moment que d'autres application interrogent la base.

Est-ce que je dois attendre l’exécution de la tache de maintenance avant de réduire la taille du fichier

Merci pour votre aide.

Cordialement.

[mikedavem]

Est-il possible de réduire la taille du fichier au même moment que d'autres application interrogent la base.

Oui car l'interrogation se fera de toute façon sur les données et non sur le journal des transactions.

Est-ce que je dois attendre l’exécution de la tache de maintenance avant de réduire la taille du fichier

Que fais votre plan de maintenance ? Sans informations supplémentaires je dirais de faire votre réduction après toute tâche de maintenance. Assurez vous que tous les VLF de votre fichier journal soient libérés auquel cas le SHRINK n'aura aucun effet.

++

[nigmat]

Merci beaucoup.
Le plan définit doit:
1- sauvegarder le fichier de données
2- sauvegarder le fichier log de transaction
3- optimiser la base de données
4- Assurer de l'intégrité de la bas de données
5- créer un fichier historique.

En tout j'avais prévu de faire la réduction demain après la maintenance comme vous m'avez suggéré.

[nigmat]

"Assurez vous que tous les VLF de votre fichier journal soient libérés auquel cas le SHRINK n'aura aucun effet."
c'est quoi les "VLF"?

[elsuket]

Bonjour,

C'est l'abréviation de Virtual Log File, c'est à dire les fichiers (logiques) virtuels de votre fichier du journal des transactions.
Ce sont des "tranches" logiques qui découpent le fichier du journal des transactions.
Lorsqu'on réalise une sauvegarde de ce fichier, ces "tranches" (mais pas forcément toutes) sont réutilisées pour les transactions qui sont exécutées sur la base de données.
Si ces VLFs sont en cours d'utilisation, alors vous ne pouvez pas les libérer.

C'est pourquoi Mikedavem vous a conseillé de le vérifier, car il est parfois nécessaire d'effectuer deux sauvegardes consécutives du fichier du journal des transactions pour pouvoir le réduire autant que c'est possible.

Je suis néanmoins surpris que cela n'ait pas été dit avant par mes confrères : le rétrécissement de quelque fichier que ce soit doit être une manœuvre exceptionnelle qui se fait lorsqu'on manque d'espace disque, ou lorsqu'on vient de remarquer que la gestion du fichier du journal des transactions devait être revue.

En effet cet espace, si votre fichier du journal des transactions est correctement géré, sera tôt ou tard repris par SQL Server, et toutes les transactions en cours à ce moment là attendront que le fichier ait fini de grossir.

En plus de cela, vous fragmentez le fichier du journal des transactions, ce qui est mauvais, et, suivant l'incrément que vous avez spécifié pour le grossissement de celui-ci, vous ajoutez un certain nombre de VLFs.

Plus le nombre de ces derniers est élevé, plus le temps de récupération de la base de données en cas de crash ou de restauration des sauvegardes est long, car traverser un VLF est long, et plus vos grosses transactions (qui manipulent beaucoup de données) seront longues, pour la même raison.

Pour connaître le nombre de VLFs de votre fichier du journal des transactions, et savoir combien sont en cours d'utilisation, vous pouvez exécuter la requête que je viens de publier ici.

Vous pouvez également vous servir des requêtes suivantes pour obtenir un faible nombre de VLFs.

@++

[mikedavem]

1- sauvegarder le fichier de données
2- sauvegarder le fichier log de transaction
3- optimiser la base de données
4- Assurer de l'intégrité de la bas de données
5- créer un fichier historique.

Personnellement je mettrais votre étape 4 en premier car si votre base n'est pas intègre elle conditionnera le reste de votre plan de maintenance.

L'étape 3 peut être consommatrice du journal des transactions en fonction du mode de récupération choisi et des tâches qui incombent à cette étape. Si vous voulez faire une réduction de fichiers il y a de grandes chances qu'il faudra sauvegarder à nouveau le journal avant.

Je suis néanmoins surpris que cela n'ait pas été dit avant par mes confrères : le rétrécissement de quelque fichier que ce soit doit être une manœuvre exceptionnelle qui se fait lorsqu'on manque d'espace disque, ou lorsqu'on vient de remarquer que la gestion du fichier du journal des transactions devait être revue.

J'avais compris que c'était une opération exceptionnelle ici mais si le but est d'automatiser la réduction de fichiers alors ta piqûre de rappelle est nécessaire

++

[WOLO Laurent]

Bonsoir,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases

Lisez ceci pour savoir ce que vous devez faire et ce qui retarde la troncation de votre journal de transactions

Oui, sauf qu'il a la version 2000. Donc ca ne marchera pas.

[WOLO Laurent]

merci bq
mais je veux just savoir est ce que cette syntaxe est correct

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
DECLARE @titre VARCHAR(50)
DECLARE @titre1 VARCHAR(50)
SET @titre = 'mabase'
SET @titre1 = 'mabase_log'
USE @titre
GO
 
DBCC SHRINKFILE(@titre1, 2)
 
BACKUP LOG @titre WITH TRUNCATE_ONLY
 
DBCC SHRINKFILE(@titre1, 2)

pr ce que je veux faire un boucle sue la base master et récupérer les nom des table sur la variable @titre pour truncker toutes les base de données user

merci

Fait un Backup Database Ta_Base with truncate_only d'abord ensuite tu fais ton shrinkfile. Donc tu as deux shrikfiles et le premier est unitile.

Tu ne peux pas faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Use @MaBase

Conclusion ta syntaxe n'est pas bonne.

[kamuel]

Bonjour,

je suis débutant en SQLServer, actuellement je bosse sur sqlserver2005, j'ai bien suivie les forum et j'ai bien cherché sur d'autre forum, et mon problème concerne la diminution de la taille des logs .ldf, en executant ces requêtes :

select backup_start_date, backup_finish_date, type, recovery_model
from msdb.dbo.backupset where database_name = 'reduc_bdd'

ALTER DATABASE reduc_bdd SET RECOVERY SIMPLE
GO

select name from reduc_bdd.sys.database_files where Type_DESC='LOG'

dbcc auto_shrinkfile(' reduc_bdd_log ',50)

dbcc shrinkfile(' reduc_bdd_log ',50)


et ma question c'est que c'est vrai que j'arrive à reduire la taille des logs mais si un jours y aura un crache de server de base de données ,est il possible de réutiliser les derniers logs réduit pour revenir vers point souhaité.

et ma seconde question: est la diminution de la taille des logs=perte de l'information, si c'est le cas , pourqo=uoi je reduit la taille des logs


Cordialement