Discussion :

[deviljoker]

bonjour,

sur une des bases de prod, j'ai un plan de maintenance qui :
- sauvegarde le journal toutes les heures
- réorganise les index tous les jours à 01H00
- sauvegarde la base à 02h00

le petit soucis c'est que la réorganisation des index fait gonfler mon journal transactionnel et prend plus de 90% du disque du journal
la sauvegarde de journal suivante vide le fichier journal mais sans le retailler...

donc comment peut on gérer cette taille excessive de fichier ?
dbcc shrinkfile en tâche planifiée...?

[ylarvor]

prend plus de 90% du disque du journal

Quel est votre version de sql serveur ?
Quel est la taille du disque de log ?
Quel est la taille de votre base de données ? du log initial ?

Vous n'êtes pas obligé de reconstruire tous les jours, une fois par mois, cela suffit... faites une défragmentation chaque jour.

[Invité]

Pour faire un SHRINKFILE du log:

Code :

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

1
2
3
4
5
6
7
8
9
ALTER DATABASE mabase
SET RECOVERY SIMPLE
GO
-- réduit le log à 16 MB
DBCC SHRINKFILE ('mon_fichier_log',16)
GO
ALTER DATABASE mabase
SET RECOVERY FULL
GO

[oadin]

une question par rapport a ce qu'il est écrit ici plus haut (je sens que le problème va se poser bientot chez nous)

Comment je fais un alter database recovery mode simple avant et full après alors que ma base de donnée est en mirroir sql et donc réclame du mode full?

[deviljoker]

Quel est votre version de sql serveur ?
Quel est la taille du disque de log ?
Quel est la taille de votre base de données ? du log initial ?

Vous n'êtes pas obligé de reconstruire tous les jours, une fois par mois, cela suffit... faites une défragmentation chaque jour.

-SQLSERVER 2000
-disque de log 8 Go
-fichier de données 5,2 Go effectifs
-fichier de log initial 1Go et grimpe à 4,6Go suite à la réindexation

puis d'autres bases sur les mêmes disques mains moindres

[ylarvor]

Première solution (originale):

Essayez d'utiliser le script de petit dej chaque jour qui utilise la fonction DBCC INDEX DEFRAG en adaptant MAXFRAG à votre base pour voir si cela à une moindre influence sur votre fichier de log. Cela sera moins efficace qu'une reconstruction mais cela affecte moins les performances de la base.

Essayez d'utiliser le deuxième script fourni une fois par mois en appliquant la deuxième solution juste apres.

Pour en savoir plus : http://blog.developpez.com/index.php...000_-_Rindexer

Deuxième solution :

Code :

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

Sauvegarde complète.

puis

Code :

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

BACKUP LOG basededonnees WITH  TRUNCATE_ONLY

puis

Code :

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

dbcc shrinkfile (basededonnees_log)

[oadin]

Je vais reprendre une question que j'avais posé un peu plus haut mais avec peut être plus d'explication.

Nous avons passé nos serveurs en mirroir ce we, le problème est la taille du journal de transaction le jour du rebuild des index.

Il y a des moyens mal propre qui consiste a faire un backup directement après full et après effacer tout les fichiers de log.

Mais ça me force a avoir 2 fois la taille de ma base de donnée minimum (une fois pour mon backup, une fois pour mon journal des log qui fait la même taille que ma base de donnée ou presque).

On a regardé avec notre consultant sql si il existait un moyen propre de réduire cette taille de log, mais il n'a pu me fournir aucune solution valable.
Si ce n'est défragmenter qu'une partie de mes index (pas tous), ou de faire des backups du log pdt l'opération de reconstruction d'index... (je ne vois pas la différence que j'aurai entre un fichier de 40go et 10 fichiers de 4go ).

Il n'a pas pu me donner une méthode de reconstruction d'index n'utilisant pas le journal de transaction, on utilise un maintenance plan actuellement pour réorganiser notre db le we.

Je me demande si il n'y aurait pas aussi un soucis du coté de nos journal de transaction que je trouve très gros. J'ai du mal a estimer la quantité de donnée encodée/modifiée/supprimée par jour, mais 200mo par heure, notre entreprise est très loin de l'activité de site comme ebay

Nous sommes en sql server 2005 SP2 x64 avec des bases de donnée en compatibilité 8.0 rien de compliqué sur nos tables sauf des accès sql, du mirroring

Merci de votre aide

[deviljoker]

Je vais reprendre une question que j'avais posé un peu plus haut mais avec peut être plus d'explication.

Nous avons passé nos serveurs en mirroir ce we, le problème est la taille du journal de transaction le jour du rebuild des index.

Il y a des moyens mal propre qui consiste a faire un backup directement après full et après effacer tout les fichiers de log.

Mais ça me force a avoir 2 fois la taille de ma base de donnée minimum (une fois pour mon backup, une fois pour mon journal des log qui fait la même taille que ma base de donnée ou presque).

On a regardé avec notre consultant sql si il existait un moyen propre de réduire cette taille de log, mais il n'a pu me fournir aucune solution valable.
Si ce n'est défragmenter qu'une partie de mes index (pas tous), ou de faire des backups du log pdt l'opération de reconstruction d'index... (je ne vois pas la différence que j'aurai entre un fichier de 40go et 10 fichiers de 4go ).

Il n'a pas pu me donner une méthode de reconstruction d'index n'utilisant pas le journal de transaction, on utilise un maintenance plan actuellement pour réorganiser notre db le we.

Je me demande si il n'y aurait pas aussi un soucis du coté de nos journal de transaction que je trouve très gros. J'ai du mal a estimer la quantité de donnée encodée/modifiée/supprimée par jour, mais 200mo par heure, notre entreprise est très loin de l'activité de site comme ebay

Nous sommes en sql server 2005 SP2 x64 avec des bases de donnée en compatibilité 8.0 rien de compliqué sur nos tables sauf des accès sql, du mirroring

Merci de votre aide

dans mon cas je n'ai pas trouvé d'autres solutions que d'agrandir le disque du journal
la sauvegarde des logs pendant la reconstruction : j'ai testé ça n'a pas marché chez moi... la reconstruction passe apparemment en priorité.
par contre l'idée est loin d'être bête, la sauvegarde des logs prendrait au final autant de place mais ton fichier de log lui même ne grossirait pas de la même manière

d'après ce que j'ai compris, c'est la taille des sauvegardes de log qui te gêne mais 200Mo par heure sur une base de 40Go ça ne me paraît pas énorme...