Discussion :

[achestyx]

Bonjour

Lorsque je restaure sur un serveur B une sauvegarde complète réalisée sur un Serveur A est ce que les index et les statistiques doivent être recalculés ?

Merci

[elsuket]

Bonjour,

Les indexes sont conservés dans leur état de fragmentation lors de la restauration, de même pour les statistiques : si elles sont périmées, ce sera pareil à la restauration.

C'est-à-dire que si vous envisagez une défragmentation de vos indexes sur le serveur A, vous devez la réaliser aussi sur le serveur B.
Pareillement, si vous envisagez une mise à jour de vos statistiques sur le serveur A, faites le sur le serveur B.

@++

[achestyx]

Bonjour,

Je me rends compte que l'exposé de ma question était un peu succinct. Je vais donc développer un peu :

Serveur A :
Quotidiennement :
- Recalcul des index si nécessaire (d'apres une proc publiée par Frédéric BROUARD).
- Recalcul des stats
- Sauvegardes
A noter que la taille des unités d'allocation des disques est de 4 ko.

Serveur B :
Restauration de la sauvegarde.
Le disque des données est formaté avec des unités de 64 ko.

Dans la mesure ou les unités d'allocation sont différentes entre les 2 serveurs, je m'interroge sur l'apparition ou non d'un phénomène de fragmentation lors de la restauration.... Du coup, je me demande s'il faut ou non recalculer les index de la base après restauration ?

J'ai fait le choix de formater le serveur B avec des unités de 64ko pour optimiser les lectures (1 page par accès disque)...

[elsuket]

Effectivement il y a une différence entre la fragmentation des indexes et le fragmentation des pages de votre base de données.

Quand on parle de la fragmentation physique des indexes, on parle aussi de fragmentation externe. Celle-ci se "produit" lorsque l'ordre logique des pages de l'index est incorrect. Les nouvelles valeurs de clé de l'index sont alors insérées dans de nouvelles pages d'index, qui désordonnent l'ordre original de la clé de l'index.

Quand on parle de fragmentation logique de l'index, on parle aussi de fragmentation interne : c'est le cas lorsque la quantité de données stockée dans les pages de l'index est plus petite que la quantité maximale de données que peut stocker une page.

Les pages de données de SQL Server font 8Ko, et chacune d'entre elle est stockée dans une extension, c'est-à-dire un groupe de 8 pages, donc un espace de 64Ko.
Votre serveur B est donc proprement configuré, mais ce n'est pas le cas de votre serveur A.

@++ ;

[achestyx]

Oui Elsuket; j'ai pu imposer le formatage du serveur B mais malheureusement je ne peux rien faire pour le Server A...
Du coup lorsque je passe une sauvegarde A vers B dois je recalculer mes index ? Y-a-t-il quelque chose à faire pour les données ?

Merci

[elsuket]

Oui, puisque vous n'avez pas la même configuration sur les deux serveurs.
Reconstruisez donc vos indexes avec l'instruction CREATE INDEX et l'option DROP_EXISTING à ON.

@++

[mikedavem]

Bonsoir,

Il faut faire attention : une sauvegarde agit au niveau physique des données alors que la fragmentation des index et statistiques se situe au niveau logique.

Par conséquent, la restauration de votre base de données sur votre serveur même sur une taille d'allocation de cluster différente ne changera rien à votre fragmentation et aux valeurs de statistiques sur vos index.

Un test simple est de restaurer votre base sur votre serveur B et de comparer la fragmentation et les valeurs de statistiques sur certaines tables. Vous verrez que vous aurez exactement la même chose.

Comme vous restaurez sur votre serveur B, une mise à jour de vos index et des statistiques peut être une bonne chose avant de recommencer toute activité sur votre nouvelle base.

++

[achestyx]

Bonjour,


Bon les avis divergent du coup pas facile de faire un choix . C'est vrai que j'ai fait les 2 tests (avec et sans recalcul d'index) et je n'ai pas trouvé de différence vraiment notable...
Évidemment ma base de données est beaucoup plus grosse sur mon serveur B que sur mon serveur A. Ca semble logique puisque les extents non pleins pèsent 64 ko d'un coté et 4ko de l'autre...

[mikedavem]

Vous m'étonnez.

Pourquoi votre base serait elle beaucoup plus grosse sur votre serveur B ?
Un extent fait 64 Ko dans tous les cas. C'est l'espace de travail de base de SQL Server.

Sur votre serveur A la taille d'allocation de vos clusters NTFS fait 4Ko.
Cela veut dire que votre extent sera morcelé en 16 clusters NTFS.

Sur votre serveur B la taille d'allocation de vos clusters NTFS étant de 64Ko votre extent tiendra dans un seul cluster NTFS.

Votre taille doit être par conséquent identique sur vos 2 serveurs.

++

[achestyx]

Sur A si je crée un fichier texte avec un caractère il occupera 4Ko sur le disque.
Si je fais la même opération sur B ce même fichier pèsera 64Ko.

Du coup j'avais imaginé que l'explication était identique pour mon fichier de données puisque les taux de remplissage ne sont pas à 100% ?

[mikedavem]

Vous avez raison pour ce qui concerne la création de fichier.
Un fichier nouvellement créé (un fichier texte par exemple) fera réellement quelques octets mais sur disque il prendra la place d'une taille de cluster. On le voit bien en faisant clic droit et propriétés du fichier.
C'est pour cela d'ailleurs qu'il est déconseillé de créer une partition avec une allocation de 64Ko pour ce type d'utilisation.

Pour SQL Server c'est différent. Un extent prendra la place d'un cluster NFTS de 64Ko mais c'est un espace de travail pour SQL Server. C'est SQL Server qui va gérer ensuite l'espace occupée dans cet espace et non le système d'exploitation

++