Bonjour,


Robert a écrit :
> Bonjour,
>
> Je dispose d'une instance SQL 2000 Enterprise Edition en SP4 avec 8 GB de
> mémoire. Les bases de données utilisateurs et systèmes sont localisées sur un
> SAN.

avez vous définit des unité logique zoné sur des disques physiques ? et
notamment séparé les fichiers du JT de ceux des données ?


>
> J'observe, depuis la migration de ces bases de données sur un nouveau SAN
> (SAN permettant de réaliser un snapshot vers un autre SAN de secours), une
> activité disque importante.


avez vous créé des fichiers de taille fixe ou laissé faire SQL Server
avec des fichiers de taille variable avec incrément ?

>
> Cependant, on m'a indiqué que cela pourrait être provoqué par les index de
> type cluster.

oui.

>
> Dans le design de nos base de données, la clé primaire (qui est un
> identifiant auto-incrémental) est l'index ordonné en cluster. Cependant, dans
> certain cas, je place l'index en cluster sur une autre colonne afin de
> favoriser les nombreux SELECT et jointure utilisant cette colonne dans la
> clause WHERE ou les INNER JOIN.

Le cluster est très intéressant pour des index sur des colonnes
monotones (au sens mathématique du terme) c'est à dire auto incrément ou
horodatage.
Pour toute les autres données il obligen à un remaniemenjt des lignes de
la table puisque c'est un tri physique.
Choisir un index cluster est donc judicieux sur de l'uato inc ou de
l'hordatage il l'est beaucoup moins, voir pénalisant sur d'autres types
de données et notamment sur du multi colonne.

>
> Toutefois, le fait de placer cet index sur une autre colonne provoque la
> réorganisation de la table lors d'une insertion afin de maintenir la table
> physiquement triée sur ladite colonne.
>
> Est-ce cela qui provoquerait l'activité disque importante ? Dois-je
> abandonner l'usage des index en cluster sur une colonne autre que la clé
> primaire.
>
> J'ajoute que les index sont réorganisés chaque nuit lorsque le seuil de
> framentation devient trop élevé. J'utilise aussi le générateur de profil afin
> d'identifier les requêtes pénalisantes (nombre de READS trop elvevé) afin de
> les optimiser.

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************