Discussion :

[Donpi]

1 Indexes clusteré :
Nous avons plusieurs tables (50%) sans clé primaire clustéré. Bon hier on a fait un test et on a pris une table qui avait 4.2Go de données et 4.8Go d’indexes et on l’a copié dans une même table sans aucun index juste avec une clé primaire clusteré.
La nouvelle table fait presque 10Go avec un seul index. Naïvement je pensais qu’une clé clusteré n'occupait pas de place puis ce que c'est les données elle-même qui sont triées.
En cherchant le web je trouve tout est son contraire. Certains affirment que clé clureré n'occupe pas de place d'autre disent qu'elle fait grossir ta table de 20%
et chez moi la taille à carrément doublé.
Où est la vérité ?

2 Plusieurs filegroup:
Nous somme limite au niveau de l'espace disque sur des disques rapides. Je me disais que je pourrais créer un filegroup sur des disques plus lents et y mettre les tables d'historique.
Est-ce que j'aurais une baisse de performance dans l'utilisation courante des autres tables?

3 Espace disque :
Mas base de donnée est répartie sur 3 disques/lecteurs, un pour les indexes, un pour le log et un pour les data. Hier en faisant mes tests le fichier de donnée que le disque data à complétement remplis le disque, il restait 9Mo libres. Lorsque je suis allé regarder dans les propriétés du fichier depuis management studio il m'indiquait 5go libre. Avec ça on peut tenir encore un bout de temps.
A travers le forum on trouve encore de tout, ne jamais shrinker la base ou shrinker régulièrement etc...
Je dirais de ne pas le faire, mais je me demande si la situation du disque complètement remplis est supportable pour SQL serveur.
Ne va-t-il pas planté lorsqu'il essaiera à nouveau de faire grossir son fichier, même si il reste de la place non utilisée?

[elsuket]

Bonjour,

Question n°1 : effectivement un index cluster peut être défini comme étant la table; cela étant, il ordonne physiquement les lignes de la table suivant la valeur logique de la clé de l'index cluster. En revanche il est impossible de donner un pourcentage général de la taille d'une table pour un tel index, puisqu'elle dépend du type de données des colonnes qui participent à la définition de l'index cluster.
Si vous avez doublé la taille allouée à votre table, c'est probablement que vous avez un index cluster dont la clé est très large. Notez que de ce fait, la fragmentation de l'index cluster peut facilement s'élever, et que les mises à jours sur les colonnes qui le constituent sont laborieuses.

Question n°2 : à priori non; les groupes de fichiers ont une existence purement logique, qui n'affecte en rien les performances d'accès. En revanche, on peut veiller à avoir des fichiers composant le groupe de fichier tous à la même taille, de façon à utiliser implicitement l'algorithme de remplissage proportionnel.

Question n°3 : faire rétrécir un fichier de base de données de façon régulière est une absurdité. Le faire par manque d'espace disque, ou parce qu'on a effectué une opération particulière et ponctuelle qui a occasionné l'accroissement de la taille d'un des fichiers peut arriver.
Comme dirait SQLPro, c'est comme si vous construisez un parking, et qu'à chaque fois qu'une voiture libère une place, vous prenez un marteau-piqueur pour casser le goudron de cette place avant de re-goudronner juste après avoir terminé : l'espace que SQL Server a alloué et que vous lui enlevez sera tôt ou tard ré-alloué; et quand il le sera, cela provoquera des attentes en écriture, sans compter la possible fragmentation externe du fichier. S'il s'agit du fichier du journal des transactions, les effets sont encore pires, puisqu'en plus de vous exposer à ce qui précède, vous pouvez augmenter le nombre de fichiers virtuels qui le constituent, et de ce fait ralentir le traitement des transactions, ou bien en cas de restauration de la base de données, vous exposer à un temps de récupération long. Donc pour résumer, vous avez le choix entre acheter de l'espace disque supplémentaire, ou pourrir sciemment les performances de votre base de données
Il vaut mieux se cantonner à maintenir correctement les index, et surtout à bien tailler les fichiers de la base de données dès la création de celle-ci, plutôt que je jouer au yoyo avec l'espace alloué aux fichiers de la base de données.

@++