Discussion :

[Vyns1520]

Bonjour,

Après plusieurs recherches, je vous soumets ma question car je n'ai pas réussi à trouver de solution ; donc je me lance :
Une base de données contient deux groupes de fichiers : PRIMARY (2 Go) et SECONDARY (30 Go) ; le groupe de fichier SECONDARY ne contient qu'une seule table sans aucune contrainte d'intégrité.
Je souhaite dupliquer cette base de données de l'environnement de production vers l'environnement de tests, mais sans le groupe de fichier SECONDARY (manque d'espace disque).
La base de données de l'environnement de tests existe déjà avec des tailles plus raisonnables (PRIMARY = 800 Mo et SECONDARY = 1 Go).

J'ai essayé les ordres SQL suivants sans succès :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
BACKUP DATABASE [maBaseProd] FILEGROUP = N'PRIMARY' 
TO  DISK = N'c:\PRIMARY.bak' 
WITH NOFORMAT, NOINIT,  NAME = N'maBaseProd-Complète Groupe de fichiers Sauvegarde', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO
RESTORE DATABASE [maBaseTest] 
FILEGROUP = N'PRIMARY' 
FROM  DISK = N'c:\PRIMARY.bak' 
WITH  REPLACE, RECOVERY
GO

Le résultat ne renvoie pas d'erreur mais la base de tests est inutilisable car en état "Restauration". La réponse de SSMS est la suivante :

Code :

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

1
2
 
The roll forward start point is now at log sequence number (LSN) 7167000000040400001. Additional roll forward past LSN 7188000000054500009 is required to complete the restore sequence.

Quelqu'un saurait comment faire ?

[SQLpro]

Une base de données ne peut être restaurée qu'en intégralité. En effet, il n'y a pas de sens d'un point de vu logique, de restaurer certaines tables d'une base et pas d'autre, qu'il y ait ou non de l'intégrité référentielle ou pas entre les diverses tables.

Si vous voulez ne "restaurer" que certains partie d'une base, il faut simplement extraire le code DDL de chaque objet concerné et le code SQL de réinjection, soit par fichier (bcp) soit par instruction SQL (INSERT INTO).

A +

[Vyns1520]

Merci pour votre réponse ; au moins c'est clair désormais.

Nous allons donc faire la duplication de l'environnement de production vers l'environnement de tests "à la main" :
- Pour les procédures stockées/fonctions SQL, pas de problème.
- Pour le contenu des tables, nous ne pouvons pas utiliser la clause SELECT INTO car les deux bases de données ne sont pas situées sur le même serveur SQL et les deux serveurs ne sont pas liés. Je pensais utiliser les fonctionnalités d'import/export de données offertes par SQL Server. Est-ce la même chose que bcp ?

[rudib]

Hello,

pour gérer la mise à jour vers l'environnement de dev, vous avez une possibilité intégrée dans SQL Server depuis 2008, qui est le DAC (application de la couche données). Vous pouvez synchroniser les structures avec des fichiers DACPAC, et les données avec des fichiers BACPAC. Faites une petite recherche avec ces mots-clés et regardez si ça peut vous convenir. si vous êtes en SQL Server 2012 c'est vraiment une option à considérer.

[Vyns1520]

Bonjour et merci pour cette solution alternative mais malheureusement, je viens de tenter de l'utiliser sans succès.

En effet, je suis bloqué avec le message suivant lors de la vérification / validation des dépendances d'objet de la fonctionnalité "Application de couche de données" (pour info, je suis en version 2008R2 "10.50.1600") :

Objets non pris en charge dans une DAC :
Les groupes de fichiers non principaux ne sont pas pris en charge dans une application de la couche Données

Pour cela, j'ai effectué un clic-droit sur la base de données, puis "Tâches --> Inscrire en tant qu'application de la couche Données" et ce message m'empêche de poursuivre. J'ai également des problèmes de compatibilité similaires avec des procédures stockées qui accèdent à des tables d'une autre base de données mais cela n'aurait sans doute pas été bloquant...
Je pense donc que nous allons nous rabattre vers les outils SQL d'import/export de données.

Merci quand même !