[SQL-Server 2000] Renommer un .mdf [Résolu]

[apersonnat]

Bonjour,

Je souhaiterais renommer un fichier de données sur une base SQL-Server 2000.

En parcourant la doc j'ai trouvé cette commande :

Code :

1
2
 
ALTER DATABASE <DATABASE name> MODIFY FILE ( NAME = <current_logical_name>, NEWNAME = <new_logical_name>)

En vous remerciant par avance pour vos réponses

Cdt,
A.Personnat

[vtrone]

On devine la question...
Cette commande te permet de modifier le nom logique du fichier, pas son nom physique.

Pour modifier son nom physique, il faudrait détacher la base de données, renommer le fichier sur le disque, puis attacher la base de données.

[apersonnat]

Oups oui désolé ;-)

Donc pour préciser je voulais savoir s'il n'y avait pas d'autres actions à effectuer (comme sur Oracle par exemple); ce qui semble être le cas, donc si je résume la manip :

Code :

1
2
3
4
5
 
1/   ALTER DATABASE ..
2/   Détacher la base 
3/   Renommer physiquement le fichier
4/   Attacher la base

C'est bien ça ?

Cdt,
A.Personnat

[rudib]

C'est bien ça.

[apersonnat]

Merci bien, une dernière question cependant, quel est l'impact pour les utilisateurs ?

Je suppose que leur session est déconnectée ou au mieux gelée?

[rudib]

Bien sûr, toutes les sessions qui s'exécutent dans cette base doivent être fermées, et ils ne pourront recommencer à travailler qu'après l'attachement. Pas de miracle.

[apersonnat]

SQL-Server gère les fermetures de session ? je n'ai qu'a faire un 'détach' de la base ?

Désolé si mes questions sont un peu basiques mais je débute sur SQL-Server ;-)

[rudib]

me souviens plus, mais au pire, version méchante :

Code :

ALTER DATABASE ma_base SET SINGLE_USER WITH ROLLBACK IMMEDIATE

[apersonnat]

OK merci beaucoup pour tous ces éléments, je pense faire cette manip dans le courant de la semaine (fonction de la MOA) je reviendrai vers vous le cas échéant ;-)

Cdt,
A.Personnat

[SQLpro]

Le detach fait un ROLLBACK d'office.

A +

[apersonnat]

Juste pour info, comment SQL-Server gère le renommage d'un fichier de données à chaud (utilisateur connecté et transactionnel en cours).

Sur Oracle pour renommer un fichier de données il faut positioner le fichier en mode offline, procéder au renommage logique et physique puis repositionner le fichier (tablespace) en mode online.

Qu'en est-il côté SQL-Server ?

[rudib]

Il ne le gère pas, ce n'est pas possible.

[apersonnat]

Hum dans ce cas ne devrait-on pas tout d'abord procéder au détachement de la base puis renommer via alter database .. ensuite renommer le fichier .mdf et pour finir attacher la base ?

[vtrone]

Voir les réponses plus haut, il faut détacher la base pour renommer le fichier physiquement, donc la base n'est plus disponible pendant l'opération.

[apersonnat]

Bah non justement dans mon post je demandais si le mode op était bien le suivant :

Code :

1
2
3
4
5
 
1/   ALTER DATABASE ..
2/   Détacher la base 
3/   Renommer physiquement le fichier
4/   Attacher la base

Donc si je résume on procède comme suit :

Code :

1
2
3
4
5
 
1/   Détacher la base
2/   ALTER DATABASE ..
3/   Renommer physiquement le fichier
4/   Attacher la base

C'est que je ne voudrais pas faire de bêtises ;-)

[rudib]

1/ Détacher la base
2/ Renommer physiquement le fichier
3/ Attacher la base


Il n'y a pas d'ALTER

[vtrone]

Les noms logiques et physiques sont indépendants. Et si tu détache la base, tu ne pourras pas faire ton ALTER DATABASE !

Créé une base bidon, et fais des tests, tu constateras par toi-même, c'est le meilleur moyen pour apprendre.

[apersonnat]

Je suis tout à fait d'accord, le hic c'est que je n'ai pas de serveur de test ..

Ok je note donc la version définitive :

Code :

1
2
3
4
 
1/ Détacher la base 
2/ Renommer physiquement le fichier
3/ Attacher la base

Merci à tous pour votre réactivité ;-)

[Mothership]

Étrange comme certains problèmes arrivent par deux et cela dans deux endroits totalement différents.

J'ai procédé au détachement d'une base d'épuration, peu utilisé mais un peu tout de même en consultation. L'objectif était de déplacer les fichiers pour optimiser les performances de la sauvegarde.
J'ai testé cette méthode sur ma base de DEV et de Qualité, sans problème évidemment.

Forcément en Production rien ne se passe comme prévu, entre autre chose, le fait d'être en Cluster apporte son lot de différence. La ressource disque n'étant pas dans les dépendances de la ressource SQL Server, impossible d'attacher une nouvelle base sur ce disque.
Voici l'erreur obtenu :

Msg 5184, Level 16, State 2, Line 1
Impossible d'utiliser le fichier 'M:\EPU\FICHIER_Data.MDF' pour un serveur cluster. Seuls les fichiers formatés pour lesquels la ressource cluster du serveur possède une dépendance peuvent être utilisés. La ressource de disque contenant le fichier n'est pas présente dans le groupe de clusters ou la ressource de cluster de Sql Server n'a pas de dépendance sur celui-ci.

Qui correspond à la KB : http://support.microsoft.com/kb/295732

Bref je suis bon pour un arrêt total de la production dimanche, sauf si quelqu'un a une brillante idée. J'ai pensé à feinter la bête sans succès pour le moment et plus sérieusement en remettant tout tel quel au niveau du système de fichier puis une restauration de la base système. Je pense que cette opération un peu risquée et je redoute que le remède soit pire que la maladie.

Qu'en pensez vous ?


Note : je suis en SQL2005 SP2 sur un serveur 2003 64Bit en cluster

[rudib]

Hum... il faut faire très attention quand on est en cluster. Regarde dans la base de registres si tu trouve une référence de ton ancien nom de fichiers. Pour plusieurs choses, MSCS synchronise ses infos par la base de registres.

CORRECTION : je n'ai rien dit, l'article de la KB donne la réponse.