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

Administration SQL Server Discussion :

Gestion des indexes et statistiques


Sujet :

Administration SQL Server

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre émérite
    Inscrit en
    Mai 2008
    Messages
    686
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 686
    Par défaut Gestion des indexes et statistiques
    Bonjour à tous,

    J'ai effectué la migration de notre base de données de 2005 SPx vers MSSQL 2008R2 ce weekend, tout s'est bien passé, l'applicatif n'a rien vu et tout le monde il est content. L'objectif était principalement de coller avec le support Microsoft, la version que nous avions n'étaient plus supportée.

    J'utilise pour la maintenance des indexes et statistiques les procédures stockées proposées par SQLpro et ma foi tout se passe bien.
    Depuis la migration sous 2008R2 je m'interroge sur la gestion des journaux de transaction car semble-t-il (j'ai peu d'historique mais tout de même) la taille des TRAN générée est titanesque.

    Comment nous fonctionnons actuellement ?
    Pendant la maintenance (à chaud), une sauvegarde des TRAN est effectué sur disque toutes les 15 minutes, le disque a environ 250Go d'espace prévu à cet effet. Sous SQL 2005, cette taille était tout à fait suffisante, à aucun moment ce dernier n'a été saturé.

    Samedi, suite à ma migration, j'ai donc lancé ce plan de maintenance : RAS, ce dernier a été long mais c'est normal puisque la base a été attachée sur un nouveau serveur.
    Dimanche, à nouveau maintenance et là les backup.trn étaient énormes, entre 30 et 110Go (par heure), forcément au bout de 2 / 3 heures le disque était plein, du coup les journaux de transaction ont saturé et l'applicatif n'a pas apprécié.

    Hier j'ai surveillé l'exécution entre 16h et 00h20, idem j'ai du manuellement sauvegarder des fichiers au fur et à mesure via notre outil habituel puis les supprimer pour laisser la place au suivant.

    Du coup je m'interroge sur la manière de faire avec MSSQL 2008R2, les requêtes utilisées ne sont elles plus adaptées ? Est-il tout simplement plus causant et du coup c'est normal ? Le plan de maintenance doit-il être repensé complètement ?
    Actuellement les requêtes sur tables et indexes avec gestion des statistiques sont des :
    • Alter index rebuild + statistics
    • alter index reorganize + statistics


    J'ai quelques idées pour éviter d'utiliser trop de stockage sur notre SAN(qui coute cher), mais c'est plus pour pallier qu'autre chose.

    Si quelqu'un peut m'éclairer sur le sujet, je continue à chercher de mon côté.

  2. #2
    Membre éclairé
    Homme Profil pro
    Administrateur de base de données MCITP Database Administrator 2008
    Inscrit en
    Décembre 2011
    Messages
    40
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Administrateur de base de données MCITP Database Administrator 2008
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2011
    Messages : 40
    Par défaut
    Bonjour,
    Essaye de modifier le mode de récupération vers BULK_LOGGED lors du lancement des travaux afin d'avoir une journalisation minimale

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    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 : 22 010
    Billets dans le blog
    6
    Par défaut
    Dans SQL Server 2008 la commande BACKUP LOG .... WITH TRUNCATE_ONLY n'est plus supportée. Peut être est-ce cela qui vous pose problème, car vous l'avez peut être utilisée dans le code...

    Si tel est le cas et comme le conseille CherifIB, il faut passer temporairement à Bulk LOGGED.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Membre émérite
    Inscrit en
    Mai 2008
    Messages
    686
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 686
    Par défaut
    Et une telle différence en terme de TRAN généré entre 2005 et 2008R2 ça vous parle ? L'avez vous constaté partout ?

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    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 : 22 010
    Billets dans le blog
    6
    Par défaut
    Non, mais regardez si on avait pas utilisé cette commande dans vos scripts....

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #6
    Membre émérite
    Inscrit en
    Mai 2008
    Messages
    686
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 686
    Par défaut
    Non cette requête n'est pas utilisée.
    J'ai placé la base en mode BULK_LOGGED hier et la taille des fichiers de sauvegardes des journaux de transaction est restée très importante.

    Je vais tenter la méthode via notre outil de sauvegarde et laisser de côté la sauvegarde sur disque pour le moment.

    Merci pour vos réponses.

Discussions similaires

  1. Gestion des Index
    Par fdesalle dans le forum Oracle
    Réponses: 3
    Dernier message: 03/02/2010, 16h49
  2. Gestion des index For Each / For i=0 To Max
    Par Luc1an0 dans le forum VB.NET
    Réponses: 2
    Dernier message: 13/04/2009, 13h04
  3. Gestion des index sous access
    Par new_wave dans le forum Sécurité
    Réponses: 1
    Dernier message: 12/06/2008, 18h04
  4. [Oracle 9i] gestion des indexs
    Par Herveg dans le forum Oracle
    Réponses: 14
    Dernier message: 18/05/2006, 12h00
  5. Gestion des indexes
    Par tomca dans le forum Oracle
    Réponses: 6
    Dernier message: 17/02/2006, 10h27

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