Lenteur sur MS SQL 2005 Std

Bonjour,

je me présente, je suis une bille en SQL Server 2005. Voila, ça c'est fait!

En fait, un client m'a demandé un jour d'installer SQL Server 2005 Std (sans que je puisse me préparer) alors que je n'avais pas réellement les compétences nécessaires pour cela.

Du coup c'est ce que j'ai fait et j'ai du remonter une sauvegarde d'une base qui tournait sous SQL 7.0. En meme temps, une autre prestataire est venu installer sa base pour son appli. Seulement maintenant (quelques mois après) on m'indique que les applis qui tournent sur ces BDD sont lentes.

Et c'est vrai, 2 minutes pour sauvegarder des données dans une table ça me semble à moi aussi plutot long.

J'ai jete un oeil sur le serveur, dans un premier temps j'ai vu que le fichier de transaction d'une bdd faisait 82Go, j'ai donc detache la base, supprimer le fichier journal dans Management Studio et rattacher la bdd pour que le fichier soit recréé, ça marche.
Ensuite j'ai remarqué qu'il y avait une version de MSSQL Express (installé avec Live Communications Server), j'ai donc tout viré hier.
Mais ce matin on me dit de nouveau que le serveur est lent.
Dans le gestionnaire de taches SQLSERVR.EXE prend 600Mo c'est normal?

Autre soucis, c'est qu'il n'y avait pas assez de place sur le C (me demandez pas pourquoi le vendeur a prevu 5 Go sur le C) pour que je puisse installer Management Studio, j'ai du le mettre sur un autre serveur.

Quelle piste me suggérez vous pour que je règle ce probleme? Les bdd restaurées sont toujours au format 7.0 mais la base qui a ete créée dessus est elle au format 9.0 et elle est aussi lente.

Le serveur m'est un peu inconnu car je ne l'ai pas fourni, mais il semblerait que ce soit un Xeon double coeur (en tout 6GHz) avec 1 Go de RAM.

Par avance, merci pour votre aide.

Alex

Salut,

Une première chose c'est de ne jamais supprimer un log de transaction, car si ton serveur crashe par exemple, tu ne pourras pas restaurer les données telles qu'elle étaient juste avant le crash.
Un log de transaction de 82Go c'est effectivement énorme, il faut pour cela enisager d'en faire un backup plusieurs fois par jour (regarde pour cela la documentation de la commande BACKUP LOG ou bien fais un plan de maintenance).
Qu'entends tu par

Citation:

---

Et c'est vrai, 2 minutes pour sauvegarder des données dans une table ça me semble à moi aussi plutot long.

---

? Si c'est le temps nécessaire pour faire une insertion dans une table, effectivement c'est fichtement long. La lenteur de ta base de données est probablement du à une mauvaise indexation des tables, ou a des indexes trop fragmentés ...

Avec la requête suivante:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

SELECT MIGS.UNIQUE_COMPILES [COMP], MIGS.USER_SEEKS [SEEKS], MIGS.LAST_USER_SEEK, MIGS.USER_SCANS [SCANS], MIGS.LAST_USER_SCAN, MIGS.AVG_USER_IMPACT [% GAIN], MID.STATEMENT, [TABLE], REPLACE(REPLACE(MID.EQUALITY_COLUMNS, '[', ''), ']', '') EQUALITY_COLUMNS, REPLACE(REPLACE(MID.INEQUALITY_COLUMNS, '[', ''), ']', '') INEQUALITY_COLUMNS, REPLACE(REPLACE(MID.INCLUDED_COLUMNS, '[', ''), ']', '') INCLUDED_COLUMNS FROM sys.dm_db_missing_index_group_stats MIGS JOIN sys.dm_db_missing_index_groups MIG ON MIGS.GROUP_HANDLE = MIG.INDEX_GROUP_HANDLE JOIN sys.dm_db_missing_index_details MID ON MIG.INDEX_HANDLE = MID.INDEX_HANDLE WHERE MID.DATABASE_ID = DB_ID('maBD') --AND OBJECT_NAME(MID.OBJECT_ID) = '' ORDER BY OBJECT_NAME(MID.OBJECT_ID), MIGS.USER_SEEKS DESC, AVG_USER_IMPACT DESC

---

Tu pourras voir s'il manque des indexes, sur quelles tables et quelles colonnes ils manquent.

Avec le petit script suivant, tu verras le niveau de fragmentation de tes indexes:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

SELECT IDX.NAME [Index Name], STATS.index_id [Index ID], CAST(STATS.avg_fragmentation_in_percent AS DECIMAL(4,2)) [Frag], IDX.fill_factor [Fillfactor], STATS.page_count [Pages], STATS.index_type_desc [Type], IDX.is_padded [Padded], STATS.index_depth [Index levels], STATS.partition_number [Partition] FROM sys.dm_db_index_physical_stats ( DB_ID ('maBD'), -- Database OBJECT_ID('dbo.maTable'), -- Objet NULL, -- index_id NULL, -- partition_id 'SAMPLED' -- detail mode ) STATS JOIN sys.indexes IDX ON IDX.object_id = STATS.object_id AND IDX.index_id = STATS.index_id

---

Cette requête tourne un petit moment (quelques minutes) et va te donner le degré de fragmentation des indexes. S'il en est qui ont un degré de fragmentation supérieur à 25-30, il te faut les défragmenter avec la commande ALTER INDEX et les options qui vont bien ([PARTITION = xxx] WITH (FILLFACTOR = ..., PAD_INDEX = ..., ONLINE = ON).

Il faut également que tu regardes le plan de requête des requêtes qui sont lentes (CTRL+L) pour voir si elles utilisent les indexes, ou s'il faut en rajouter ou les modifier ...
Regarde également les paramètres de mémoire (clic droit sur l'objet serveur, catégorie mémoire) et dis-nous ce que tu as comme valeurs ...

En espérant t'avoir donné un bon début de recherche ;)

Ha merci pour ta réponse, je ne l'avais pas vu.

En fait j'aimerais bien effectuer une sauvegarde par un plan de maintenance mais j'ai à chaque fois une erreur:
"echec de l'enregistrement du plan de maintenance"
Il faut savoir que je travaille sous Management Studio depuis un autre serveur. J'ai installé Management Studio sur un serveur Server1 pour manager SQL Server installé sur ServerSQL1.