Discussion :

[cestpasmoinonplus]

C'est bon, j'ai compris.
Le changement de logic name a bien fonctionné, mais il faut évidemment que je refasse un backup de la nouvelle base avant de pouvoir la re-dupliquer.

Je dois donc faire :

1) Dupliquer BASE_A en BASE_B depuis le .bak de BASE_A
2) modifier les logic names de BASE_B avec l'excellente requête de 7gyY9w1ZY6ySRgPeaefZ
3) Backuper BASE_B
4) Dupliquer BASE_B en BASE_C depuis le .bak de BASE_B
5) modifier les logic names de BASE_C

et là, ça marche

Tu parles d'un boulot !

Et encore je me heurte à un autre pb, mais avant de dire n'importe quoi, il faut que je le creuse.

Si seulement il existait un moyen, dans SQLServer, de dupliquer simplement une base de données . (en TSQL, je précise ).

[cestpasmoinonplus]

T'es sérieux ?
Tu me montres un bout de code avec un fichier de backup et tu considères ça comme un logical name ???

Comme je l'ai dit depuis le début, c'est depuis le .bak que je veux dupliquer la base. C'est donc bien les logical name du .bak qui sont pris en compte .

[cestpasmoinonplus]

Si seulement il existait un moyen, dans SQLServer, de dupliquer simplement une base de données . (en TSQL, je précise ).

Par exemple un "WITH RENAME LOGICAL NAME"
Ca doit bien exister, c'est quand même incroyable qu'il laisse les anciens logical name dans la base dupliquée qui ne porte plus le même nom.

Mais je me rends compte que je n'ai peut-être pas été assez clair depuis le début (malgré la liste exhaustive des requêtes) :
Quand je parle de dupliquer une base, c'est depuis un backup.
Restorer un backup sur le même serveur, mais sous un autre nom (= dupliquer pour moi ).

Oui mais, je vais faire comme ça
Restore DATABASE A vers B avec MOVE des fichiers, et modification des logical name dans la foulée.
Donc B sera propre et tant qu'elle n'aura pas été backupée, il n'y a pas de risque de restauration sous un autre nom depuis un backup

Merci mes amis, Je pense que ça devrait le faire.

[SQLpro]

Par exemple un "WITH RENAME LOGICAL NAME"
Ca doit bien exister, c'est quand même incroyable qu'il laisse les anciens logical name dans la base dupliquée qui ne porte plus le même nom.

Les noms logique des fichiers sont des identifiants internes à la base…. Ce qui importe c'est qu'ils soient tous différents au sein d'une même base (identifiants SQL). Si vous voulez les renommer faites le après la restauration avec

Code :

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

ALTER DATABASE MaBase MODIFY FILE (NAME + 'ancien_nom', NEWNAME + 'nouveau_nom)

Mais je me rends compte que je n'ai peut-être pas été assez clair depuis le début (malgré la liste exhaustive des requêtes) :
Quand je parle de dupliquer une base, c'est depuis un backup.
Restorer un backup sur le même serveur, mais sous un autre nom (= dupliquer pour moi ).

Oui mais, je vais faire comme ça
Restore DATABASE A vers B avec MOVE des fichiers, et modification des logical name dans la foulée.
Donc B sera propre et tant qu'elle n'aura pas été backupée, il n'y a pas de risque de restauration sous un autre nom depuis un backup

Merci mes amis, Je pense que ça devrait le faire.

A +

[cestpasmoinonplus]

Ah oui mais non, j'ai encore un soucis .
Je viens de me rendre compte que (avec la version standard évidemment),
le memory_optimized_filegroup n'est pas renommé !
Si je fais un restore de Base_Test vers Base_Test2 avec les trois move qui vont bien, dont le

Code :

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

MOVE Base_Test_memory_optimized_filegroup TO Base_Test2_memory_optimized_filegroup

Le nouveau dossier "Base_Test2_memory_optimized_filegroup" est bien créé.
Mais quand je vais dans les propriétés de la base, -> filegroups, dans MEMORY OPTIMIZED DATA il a gardé le nom de la base d'origine : Base_Test_memory_optimized_filegroup .
Si tente un remove (dans le but d'ajouter ensuite la nouvelle), il gueule "cannot drop the last memory-optimized_file".
Je ne voudrais pas vous embêter un vendredi, mais si quelqu'un avait une idée pour renommer le "Base_Test_memory_optimized_filegroup" en "Base_Test2_memory_optimized_filegroup", je lui en serais bien reconnaissant.

[SQLpro]

Ah oui mais non, j'ai encore un soucis .
Je viens de me rendre compte que [...] le memory_optimized_filegroup n'est pas renommé !
[...] si quelqu'un avait une idée pour renommer le "Base_Test_memory_optimized_filegroup" en "Base_Test2_memory_optimized_filegroup", je lui en serais bien reconnaissant.

pas possible, car c'est juste un pointeur en mémoire.... Si vous faisiez ceci, vos données seraient supprimées !

A +

[cestpasmoinonplus]

Ok.
Peut-être une astuce syntaxique concernant le

Code :

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

MOVE Base_Test_memory_optimized_filegroup TO Base_Test2_memory_optimized_filegroup

Qui créé bien le nouveau dossier "Base_Test2_memory_optimized_filegroup", mais la nouvelle base reste pointée sur l'ancien "Base_Test_memory_optimized_filegroup" ?

[elsuket]

Bonjour,

il semble que vous mélangiez ce qu'est un nom de fichier logique, un nom de fichier physique et un groupe de fichiers.

Un nom de fichier logique est, comme le disait SQLPro, seulement un pointeur mémoire. Il "appartient" à SQL Server.
D'une certaine manière, SQL Server se fiche complètement du nom de fichier physique. Ce dernier "appartient" à l'OS.
Ceci permet, en outre et justement, de restaurer une base de données sur un autre serveur, sur un ou des volumes disque qui peuvent être totalement différents, et sur une instance SQL Server sous Windows ou Linux. Si ce n'était pas le cas, comment pourrait-on restaurer une base sauvegardée sous Windows et la restaurer sous Linux, par exemple ?

Les noms de fichiers logiques sont enregistrés tels qu'ils sont au moment de la sauvegarde, et il n'y a pas de raison que ceux-ci soient changés.
On peut, comme vous l'avez fait, renommer le fichier logique, mais dans l'absolu, c'est de la pure cosmétique.
Si j'ai envie de donner comme nom logique à un fichier de base de données paniniet à l'autre choucroute, ou ma_base_data et ma_base_log, cela ne change rien au fonctionnement de la base ou du moteur de SQL Server. Et comme lorsqu'on manipule les données d'une base, on est en abstraction de ce que fait le moteur de stockage, on peut se ficher du nom logique des fichiers.

Enfin, un groupe de fichiers est ce que son nom indique, mais là encore une fois, il est préférable de l'entendre au niveau logique.
Cela permet, entre autres :

• de conserver le groupe de fichiers PRIMARY de toute base SQL Server de petite taille, ce qui permet de récupérer la base de données plus rapidement après un redémarrage de SQL Server, du serveur, ou d'un crash de ce dernier.
• de découper physiquement la base de données, c'est à dire de placer les données dans un groupe de fichiers, et les index de ces données dans un autre, ou encore de répartir physiquement le partitionnement (logique) de tables et/ou d'index. Les fichiers peuvent bien sûr être placés sur des volumes physiquement distincts, ce qui est bénéfique aux performances.
• de restaurer et sauvegarder au niveau dudit groupe de fichier, ce qui permet de contrôler la granularité des sauvegardes, chose intéressante sur VLDB notamment
• d'exécuter des contrôle d'intégrité de base de données au niveau du groupe de fichiers, ce qui est là aussi intéressant sur les VLDB puisqu'alors on peut découper un telle opération courante de maintenance de base de données.

Le livre en référence dans ma signature expose plus en détails (et bien d'autres) tout cela. Bonne lecture
@++

[cestpasmoinonplus]

Moui... Et donc ?
Il n'en reste pas moins que dans les filegroups, le memory optimized data porte toujours le même "Name" que celui de la base d'origine.
Alors que SQLServer a bien créé le nouveau dossier 'NouvelleBase_memory_optimized_filegroup' dans le dossier DATA, et semble s'en servir.