Discussion :

[ariesnojf]

Bonjour à tous,

Plus à l'aise avec Oracle, mais beaucoup moins avec SQL Server, (et sachant que la personne qui gérait les bases SQL est partie) je rencontre les problèmes suivant:

On a une base qui tourne avec une sauvegarde complète database tous les 1/4 d'heure et une sauvegarde du journaux de logs tous les soirs. Le mode de la DB étant complet.
Premier problème : le journal de transaction ne se purge pas lors des sauvegardes (1,4 Go avant et aprés la svgde utilisé pour une taille allouée du fichier de 2 Go). En recherchant un peu, j'ai lu que la purge devait être automatique lors d'une sauvegarde, mais cela ne se fait pas.
Deuxième problème : on souhaite avoir une taille fixe d'1 Go pour ce fichier, le code suivant est-il bon (lorsque j'aurais réussi à purger ...)? :

Code :

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

DBCC SHRINKFILE (nomfichier, 1024)

Troisième problème : on souffre actuellement d'un ralentissement de la base qui à mon avis provient de cette sauvegarde tous les 1/4 d'heure qui met environ 8 minutes et qui pése environ 6 Go. Je pense qu'il y a moyen de faire autrement avec la sauvegarde compléte une fois par jour et de sauvegarder le fichier journal tous les 1/4 d'heures. Mais je ne sais pas comment m'y prendre avec les journaux pour que leurs noms soit différent du genre "svgde_log_hh_mm". Je suis pas expert en T-SQL... euh aprés y'aura la restauration mais pour l'instant, je m'occupe de la sauvegarde !!!

Merci de votre aide qui sera précieuse, car actuellement, je me trouve dans une "purée" qui je dois l'avouer sera longue à digérer tous seul.

[SQLpro]

On a une base qui tourne avec une sauvegarde complète database tous les 1/4 d'heure et une sauvegarde du journaux de logs tous les soirs. Le mode de la DB étant complet.

Vous êtes sur que c'est cela ? Ne serait-ce pas l'inverse ??? Si non, inversez !!!

le journal de transaction ne se purge pas lors des sauvegardes

C'est normal le journal ne se purge pas si vous ne faites pas les sauvegardes du JT régulièrement.

DBCC SHRINKFILE (nomfichier, 1024)

Cela le réduit à 1 Go si cela est possible. Mais n'en fixe pas la taille.

Si vous voulez fixer la taille d'un journal il faut utiliser un ALTER DATABASE. Cepandant je vous conseille de ne jamais fixer la taille. En effet s'il à besoin de plus, la base arrêtera de vivre avec un message "JT plein" ! Est-ce bien ce que vous voulez ?
Je crois qu'il serait plus sage de retailler le JT avec une taille minimum égale à la consommation journalière de transactions, mais le laisser en croissance sans limite au cas ou....

Troisième problème : on souffre actuellement d'un ralentissement de la base qui à mon avis provient de cette sauvegarde tous les 1/4 d'heure qui met environ 8 minutes et qui pése environ 6 Go. Je pense qu'il y a moyen de faire autrement avec la sauvegarde compléte une fois par jour et de sauvegarder le fichier journal tous les 1/4 d'heures.

Evidemment ce plan est idiot... Vous avez tout intérêt à le casser et à faire :
1 DB full toutes les semaine
1 DB diff toutes les nuits (ou full si vous préférez)
1 JT toutes les heures (demi heures ou 1/4 d'heure) pour les heures de production
Ceci peut être réalisé dans le plan de maintenance, notamment pour vous permettre de donner un nom différent.

A +

[ariesnojf]

Merci à vous et de votre réponse.

Vous êtes sur que c'est cela ? Ne serait-ce pas l'inverse ??? Si non, inversez !!!

Ben non, c'est bien cet ordre là, je sais, je crois que la personne qui a mis cela en place n'était pas bien réveillé. Ce qui me fait peur ceci dit, il a fait la même chose pour les 3 autres bases !!!

Cela le réduit à 1 Go si cela est possible. Mais n'en fixe pas la taille.

En fait, il s'agit d'une taille de départ mais qui ne reste pas fixe ... ouf.
Par contre, initialement, ce fichier est à 1 Go, je me demande pourquoi d'ailleurs, et la seule raison serait d'optimiser la performance des JT pour ne pas s'occuper de la taille ou de la seconde solution, qu'il y ait eu une étude du nombre de transactions par 1/4 d'heures et donc par rapport à celle ci de tailler le fichier à 1 Go. Cependant, admettons que le fichier parte à 10 Mo (j'en sais rien pourquoi 10 mais bon par exemple), le fait d'augmenter le fichier par le système est il important pour ralentir les performances de la DB ?

Evidemment ce plan est idiot... Vous avez tout intérêt à le casser et à faire :
1 DB full toutes les semaine
1 DB diff toutes les nuits (ou full si vous préférez)
1 JT toutes les heures (demi heures ou 1/4 d'heure) pour les heures de production
Ceci peut être réalisé dans le plan de maintenance, notamment pour vous permettre de donner un nom différent.

Je viens de construire un plan sur une base de test, et effectivement, cela me gére les "increments" date. C'est au poil pour cela. Reste à le faire sur la base Prod. Ensuite je me replonge dans le livre pour voir la restauration de tout cela. Euh, ça ne se fait pas par un plan de maintenance par hasard ???

En tous cas merci beaucoup de vos réponses.

[elsuket]

Bonjour,

Ce qui me fait peur ceci dit, il a fait la même chose pour les 3 autres bases !!!

Alors faites le même changement sur les 3 bases

qu'il y ait eu une étude du nombre de transactions par 1/4 d'heures et donc par rapport à celle ci de tailler le fichier à 1 Go

Même si une telle étude avait été faite, cela suppose que votre base de données effectue tout le temps à peu près les mêmes transactions avec le même volume de données. Il est un peu dangereux de supposer cela.

Vous pouvez tailler votre log de transaction à 1Go en l'autorisant à croître s'il en a besoin (par exemple lors de la reconstruction des indexes).
Comme vous allez faire une sauvegarde de votre log de transaction régulièrement, après quelques jours celui-ci ne devrait plus beaucoup changer de taille.

Ne faites pas l'erreur de réduire sa taille : si une "grosse" transaction s'exécute dans votre base de données, alors SQL Server devra le faire croître : beaucoup d'accès disques, donc perte de performance énorme.

Si vous avez besoin de restaurer ces sauvegardes, alors vous devrez d'abord effectuer une sauvegarde du log de transaction en cours, puis :

1. restaurer le dernier backup complet, avec l'option WITH NORECOVERY,
2. restaurer le dernier backup différentiel, avec l'option WITH NORECOVERY,
3. restaurer les logs de transaction qui ont été sauvegardes après le dernier backup différentiel dans l'ordre où ils ont été produits, toujours avec l'option NOCOREVERY,
4. restaurer la sauvegarde du log de transaction en cours que vous venez d'effectuer avec l'option WITH STOP AT + l'heure quelques secondes avant le crash, + WITH RECOVERY

L'option WITH NORECOVERY permet de ne pas restaurer le base, et de poursuivre le restauration par progression.
A l'étape 4, vous n'êtes pas obligé d'utiliser l'option WITH RECOVERY, c'est l'option par défaut

C'est pour cela qu'il est avantageux de créer un support de sauvegarde : de cette façon, lorsque vous devrez effectuer une restauration, vous n'aurez qu'à choisir le support de sauvegarde pour lister et choisir les fichiers à restaurer

N'hésitez pas à prendre un serveur de test pour effectuer cette démarche sans prendre de risques

Aidez-vous de la documentation PC ou en ligne en regardant les options des commandes BACKUP et RESTORE

[ariesnojf]

Bonjour,

Bonjour,

Alors faites le même changement sur les 3 bases

Cela sera fait, ........., aprés avoir remis en état celle qui m'a amené à ce post

En tous cas, merci de vos réponses qui sont d'une aide assez précieuse. Je pense avoir toutes les "billes" pour m'en sortir et ne manquerai pas de vous appeler à l'aide si quelconque problème pour la restauration qui bien entendu se fera sur test en premier lieu. Merci également pour les liens.

[elsuket]

N'hésitez pas, on vient tous là pour ça