IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MS SQL Server Discussion :

Sauvegarde et journaux de logs [SQL Server 2000]


Sujet :

MS SQL Server

  1. #1
    Membre habitué Avatar de ariesnojf
    Homme Profil pro
    Inscrit en
    Juillet 2005
    Messages
    195
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 195
    Points : 188
    Points
    188
    Par défaut Sauvegarde et journaux de logs [SQL Server 2000]
    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.

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 927
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 927
    Points : 51 735
    Points
    51 735
    Billets dans le blog
    6
    Par défaut
    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 +

  3. #3
    Membre habitué Avatar de ariesnojf
    Homme Profil pro
    Inscrit en
    Juillet 2005
    Messages
    195
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 195
    Points : 188
    Points
    188
    Par défaut
    Merci à vous et de votre réponse.

    Citation Envoyé par SQLpro Voir le message
    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 !!!

    Citation Envoyé par SQLpro Voir le message
    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 ?

    Citation Envoyé par SQLpro Voir le message
    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.

  4. #4
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    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

  5. #5
    Membre habitué Avatar de ariesnojf
    Homme Profil pro
    Inscrit en
    Juillet 2005
    Messages
    195
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 195
    Points : 188
    Points
    188
    Par défaut
    Bonjour,

    Citation Envoyé par elsuket Voir le message
    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.

  6. #6
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    N'hésitez pas, on vient tous là pour ça

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Sauvegarde de la base a un serveur distant SQL SERVER 2000
    Par rezgui_fawzi dans le forum VB 6 et antérieur
    Réponses: 1
    Dernier message: 16/11/2007, 14h50
  2. Log d'une instance SQL Server 2000
    Par loulag07 dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 13/11/2007, 14h27
  3. Sauvegarde SQL-Server 2000 pour restauration SQL-Server 2005
    Par Harny dans le forum MS SQL Server
    Réponses: 4
    Dernier message: 06/10/2006, 12h06
  4. [SQL Server 2000] Attach: error 1813 sur log
    Par Gugli dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 25/09/2006, 10h15
  5. [MS SQL Server 2000] problèmes de sécurité et sauvegarde
    Par Abydos Business Group dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 24/03/2006, 20h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo