Restauration SQL2005

Bonjour,

Étant novice dans la gestion de BDD je me permet de poser une question qui semblera peut-être évidente pour certain.

Est-il possible ou non (et si oui comment) de restaurer un tablespace unique sur plusieurs ?

Je m'explique:

Je possède une sauvegarde, VLXXX.bak, qui contient un tablespace VLXXX.mdf.
Peut-on restaurer cette sauvegarde en la répartissant sur plusieurs fichiers: VLXXX_01.mdf, VLXXX_02.mdf, VLXXX_03.mdf, etc...

Techniquement possible ou non ?
That's the question...

Merci d'avance de votre réponse.

Non Désolé. De plus tu mélange pas mal de notions distinctes.
"Tablespace" n'a pas d'existance au sens SQL Server, c'est une notion qui vient d'oracle et qui correspond en SQL Server aux "Groupe de fichier".
Par ailleur ces notion correspondent a des espaces de stockage LOGIQUE (et non physique) il n'existe pas reelement et encore moins sous la forme d'un fichier .mdf. Ces "Groupe de fichier" sont constituer de 1 à plusieurs fichiers. 1 seul (le fichier maitre du "Groupe" PRIMARY) porte l'extention .mdf, les autres portant l'extention .ndf.
Le backup prend une image fidele de la base a l'instant T de la sauvegarde et la restaurera en l'etat, y comprit les metadonnées de la base, entre autre : les utilisateur, les fichiers etc. Créer des nouvelles metadonnées pendant la restauration est assez hasardeux et d'ailleur la plus part des editeur (Microsoft comprit) ne le permettent pas sauf pour déplacer un fichier lors d'une restauration.

Merci de ta réponse.
Effectivement pour le TableSpace j'ai confondu avec Oracle (plus souvent dessus que SQL)

En fait le but de cette manip' était d'améliorer les perfs de la base, celle-ci commencant à "ramer".

La BDD en question a été crée sous un seul fichier (Primary) au lieu de 5 (standard normalement adopté dans cette entreprise).

Je vais donc explore une nouvelle voie pour soulager mon serveur. ;)

Tu peux toujours créer un ou plusieurs nouveau FILEGROUPE et deplacer les objets de ta base dessus Index Cluster et Table Heap sur un FileGroupe DATA et les index non Cluster sur un FileGroupe INDEX. Cela dis c'est loins d'etre la premiere chose a faire ramer une base SQL Server loins de la. Meme si la séparation est toujours une bonne chose pour des question de fragmentation dans les pages de la base je ne commencerais pas par regarder de ce coté la. En effet La pression disk n'est pas la premiere cause de ralentissement, et dans la majorité des cas cette pression disk s'exerce non pas sur les fichiers de données mais sur le LOG !
Je chercherais plutot une pression mémoire ou une pression processeur en premier.

FAUX ! Si tu veux éviter une fragmentation, il suffit de dimensionner les fichiers de base de données correctement, c'est la base. La fragmentation des pages d'index est imputable au taux de remplissage. Le fait d'avoir n fichiers de base de données permet avant tout de répartir les accès disque.