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é.

Bonjour,
Essaye de modifier le mode de récupération vers BULK_LOGGED lors du lancement des travaux afin d'avoir une journalisation minimale

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 +

Et une telle différence en terme de TRAN généré entre 2005 et 2008R2 ça vous parle ? L'avez vous constaté partout ?

Non, mais regardez si on avait pas utilisé cette commande dans vos scripts....

A +

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.

êtes vous à jour des services PACK ?

Les outils de sauvegarde externe ne font qu'appeler la commande BACKUP de SQL Server en vous faisant payer fort cher la ligne de code supplémentaire !!!!
Donc rien à attendre de cela.

Procédez vous à des sauvegardes régulière du JT ?

Avez vous compressé le fichier de du JT via SHRINKFILE ?

A +