Discussion :

[StringBuilder]

Bonjour,

Après l'installation d'un programme, toutes les table de la base sont dans le même fichier, celui par défaut, primary.

Afin d'optimiser la charge du serveur, je souhaite :
- déplacer les tables "actives" sur un disque SSD
- déplacer les tables "archivées" sur un disque de stockage, volumineux mais lent

J'ai trouvé ce lien :
http://sqlandme.com/2011/10/13/how-t...e-in-database/

Je suis un peu surpris par la façon dont les données sont déplacées d'une table à une autre : on re-crée l'index clustered ailleurs et ça déplace la table

Y'a pas une méthode plus... sémantique ?

Quel est l'impact si on lance la chose pendant que le serveur est en pleine charge (lenteur, ou plantage ?)
Pour tout ce qui est PK et autres procédures stockées, quel est le risque potentiel ?

Existe-t-il un risque à faire ces déplacements ?

[hmira]

Je suis un peu surpris par la façon dont les données sont déplacées d'une table à une autre : on re-crée l'index clustered ailleurs et ça déplace la table

L'index cluster est la table elle-même. L'index cluster se confond avec la table et ne fait plus qu'un avec la table. Donc c'est tout à fait normal que le déplacement de l'index cluster revient à déplacer la table elle-même.

Y'a pas une méthode plus... sémantique ?

Une méthode plus "sémantique" si l'on peut dire est d'utiliser la clause WITH (MOVE TO ...) lors de la suppression de l'index Cluster.
Exemple :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ALTER TABLE dbo.MaTable
 DROP CONSTRAINT  PK_MaTable WITH (MOVE TO SecondaryFG)

Dans l'exemple ci-dessus, l'index cluster sera supprimé, et les lignes de données qui se trouvaient au niveau des feuilles de l'index cluster seront déplacées vers le nouveau File groupe SecondaryFG

Puis création de la clé primaire Cluster dans le nouveau File groupe SecondaryFG

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 ALTER TABLE dbo.Matable
  ADD CONSTRAINT PK_MaTable PRIMARY KEY  CLUSTERED   ( Id  ASC ) 
ON SecondaryFG

Quel est l'impact si on lance la chose pendant que le serveur est en pleine charge (lenteur, ou plantage ?)

Lenteur Oui surement, plantage Non assurément ! En effet, depuis SQL Server 2005, vous pouvez créer l'index, soit en ligne (ONLINE) ou hors ligne (OFFLINE). En mode hors ligne (OFFLINE) la table est en lecture seule pendant la création de l'index.
En mode en ligne (ONLINE), la table peut être utilisée en lecture et en écriture pendant la phase de création de l'index. SQL fusionne dans tous les changements qui se sont produits pendant la création ou la reconstruction de l'index.
Il ne faut pas oublier par ailleurs, que les opérations de création ou de reconstruction de l'index sont journalisées, en ce sens que la cohérence de la base est préservée.

Pour tout ce qui est PK et autres procédures stockées, quel est le risque potentiel ?

Tu veux parler plutôt des FK. Concernant les FK, je dirais que le problème est le même que d'habitude, et ce, indépendamment du nouveau File group ; il faudra au préalable supprimer les FK avant de supprimer la PK puis recréer les FK après le création et le transfert de la PK dans le nouveau file Group.
Concernant les procédures etc . et plus généralement les plans d'exécution des requêtes, la reconstruction des indexes a pour effet, le recalcul des statistiques, et le recalcul des statistiques a pour effet l'invalidation des plans d'exécution ce qui provoque donc la recompilation des plans impactés. il s'agit là d'un processus classique normale indépendant de l'ajout du nouveau du file group.

Existe-t-il un risque à faire ces déplacements ?

D'après moi, il n' y a aucun risque !

A+

[StringBuilder]

Merci pour ta réponse détaillée.

En effet, après lecture (y compris d'un article de la MSDN) il s'avère que l'index cluster est les données de la table elles-mêmes (même si je trouve que ce lien de cause à effet nuit à la sémantique : il y a la notion de table d'un côté et d'index cluster de l'autre, l'un pouvant vivre sans l'autre (une table peut ne pas avoir d'index cluster, et dans ce cas, visiblement on est obligé de dupliquer la table la supprimer, puis renommer le duplicata, ou alors créer un index cluster temporairement le temps de faire le déplacement).

Pour ce qui est des FK, c'est vrai que j'avais pas percuté qu'il fallait tout droper avant de re-créer la PK...

Bon, ceci dit, je ne crois pas qu'il existe de FK dans la base en question, base éditeur... donc pas de problème...

Merci en tout cas !

[darkelend]

Tu peux faire cette manipulation avec l'outil Filegroup Migrator de Kankuru (http://www.kankuru.fr/post/2013/01/2...-Migrator.aspx). Mais effectivement, pour déplacer une table, il faut déplacer le clustered index.