est il realiste d'essayer de transferer une Database SQL Server sur une autre machine ?

[olibara]

Bonjour

Veuillez excuser monincompétence et mon énervement face au parcours d'obstacle infranchissable rencontré dans ma tentative de Transferer une DataBase SQL SErver 2008 vers une autre machine SqlServer 2008

Dommage que MySql soit passé chez Oracle, ils avaient un syteme de gestion un peu plus souple et convivial

J'essaye donc de transferer une base d'une machine vers une autre (s'il vous plait n'essayer pas de me trouver des argument pour me dire que je ne peux pas faire ca)

J'ai essayé BackUp Restore : impossible pas la meme version de serveur
J'ai essayé detach et copie des fichier : impossible pour les memes raisons

Je pensais donc pouvoir m'en sortir en generant un script de creation de DB avec donnée avec SSMS : mais la aussi ca coince.

Voici le script généré : déja je trouve débile que le chemin d'acces physique au fichier DB soit hard codé dans le script (c'est au serveur de gerer ca) et c'est probablement la premiere cause de plantage rencontré (voir erreur apres)

Existe_t_il un truc spécial ou bien le transfert de database c'est vraiment un truc impossible ou réservé a ceux qui son nés avec MSSql dans le biberon (j'ai prévenu SSMS me rends nerveux et idiot)

Merci en tout cas a ceux qui voudraient m'aider

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
USE [master]
GO
/****** Object:  Database [SmartBill]    Script Date: 01/08/2012 15:38:17 ******/
CREATE DATABASE [SmartBill] ON  PRIMARY 
( NAME = N'SmartBill', FILENAME = N'c:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA\SmartBill.mdf' , SIZE = 3072KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
 LOG ON 
( NAME = N'SmartBill_log', FILENAME = N'c:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA\SmartBill_log.ldf' , SIZE = 1024KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
GO
ALTER DATABASE [SmartBill] SET COMPATIBILITY_LEVEL = 100
GO
IF (1 = FULLTEXTSERVICEPROPERTY('IsFullTextInstalled'))
begin
EXEC [SmartBill].[dbo].[sp_fulltext_database] @action = 'enable'
end
GO
ALTER DATABASE [SmartBill] SET ANSI_NULL_DEFAULT OFF
GO

Code :

1
2
3
4
5
6
7
8
9
10
11
12
Msg 5133, Level 16, State 1, Line 2
Directory lookup FOR the file "c:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA\SmartBill.mdf" failed WITH the operating system error 3(Le chemin d’accès spécifié est introuvable.).
Msg 1802, Level 16, State 1, Line 2
CREATE DATABASE failed. Some file names listed could NOT be created. CHECK related errors.
Msg 5011, Level 14, State 5, Line 1
User does NOT have permission TO ALTER DATABASE 'SmartBill', the DATABASE does NOT exist, OR the DATABASE IS NOT IN a state that allows access checks.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.
Msg 5011, Level 14, State 5, Line 1
User does NOT have permission TO ALTER DATABASE 'SmartBill', the DATABASE does NOT exist, OR the DATABASE IS NOT IN a state that allows access checks.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.

[mikedavem]

J'ai essayé BackUp Restore : impossible pas la meme version de serveur
J'ai essayé detach et copie des fichier : impossible pour les memes raisons

Si vous avez une erreur de ce type c'est que vous ne transférez pas vos bases entre serveurs de même version. Vous devez commencer par vérifier cela en lançant la requête suivante sur vos 2 serveurs :

Code :

SELECT @@VERSION

Voici le script généré : déja je trouve débile que le chemin d'acces physique au fichier DB soit hard codé dans le script (c'est au serveur de gerer ca) et c'est probablement la premiere cause de plantage rencontré (voir erreur apres)

Vous demandez un script de bases de données c'est donc normal que celui-ci vous scripte le chemin physique de vos fichiers de bases de données. Votre serveur SQL ne peut pas deviner où vous placez vos fichiers. C'est à vous de lui préciser.

Vous manquez un peu de formation sur SQL Server .. c'est normal que cela vous prenne un peu de temps .. c'est exactement la même chose sur les autres SGBD).

Vous pouvez par exemple :

- utiliser la génération de script pour votre base de données qui vous scriptera l'ensemble de votre base, objets et même données si votre base n'est pas trop volumineuse.
- Générer les scripts de vos différents objets et utiliser bcp / ssis pour importer vos données
- Générer les scripts de vos différents objets, utiliser un serveur lié + procédures SQL d'imports de vos données inter serveurs etc ...
...

++

[olibara]

Merci MikeDavem

J'apprécie ta patience et ton aide mais je reste énervé avec SqlServer

Si vous avez une erreur de ce type c'est que vous ne transférez pas vos bases entre serveurs de même version. Vous devez commencer par vérifier cela en lançant la requête suivante sur vos 2 serveurs :

Oui j'avais compris cela ....
mais la Machine source utilise la version 2008 10.27 etc..
La machine destination utilise la version 2008 10.50 etc..

J'avais espéré que SqlServer etait au moins capable de gerer une compatibilité Ascendente entre les build d'une meme version

Mais j'ai fini par admettre que j'avais a peu pres autant de chance de reussir cette operation en ayant deux serveurs scrupuleusement identique que de gagner au Lotto (et encore : le lotto je ne desespère pas )

J'ai donc opté pour le script

Vous demandez un script de bases de données c'est donc normal que celui-ci vous scripte le chemin physique de vos fichiers de bases de données. Votre serveur SQL ne peut pas deviner où vous placez vos fichiers. C'est à vous de lui préciser.

Là je ne suis pas d'accord !!
Il ne faut pas confondre le Nom logique de la base de donnée et le chemin Physique des fichier qui vont la contenir !!

Que le nom logique doive etre spécifié dans le script me semble evident
Mais PAS le chemin physique : c'est le serveur qui doit gerer et connaitre cela : ce chemin peut etre différent selon les machines !!
D'ailleurs pour utiliser mon sript j'ai créé la database a la main, j'ai supprimé du script le code spécifique a la création de la base et je l'ai executé

Tout s'est alors a peu pres bien passé sauf qu'il m'a encore un peu embèté en me signalant de maniere obscure et peu sympatique qu'il y avait un problème de user login. Comme tout etait généré et accessible je ne me suis pas attardé sur le sujet qui est une des autre misères de SqlServer

Vous manquez un peu de formation sur SQL Server .. c'est normal que cela vous prenne un peu de temps .. c'est exactement la même chose sur les autres SGBD).

Tout a fait d'accord sur mon manque d'expérience et je comprends que c'est un handicap important
Par contre je pense que MSSql Server est asser spécifique dans sa complexité et son manque de convivialité
Je n'ai jamais rencontré ca dans mes autres fréquentation de SGBD ni MySql ni MDBS (mais ca c'est une vielle histoire)

Je comprends qu'un spécialiste ne se rends plus compte qu'il y a un tas de truc vraiment pas simple peu intuitif ou sans doute parfois vraiment mal conçu.
Mais le néophyte est completement perdu dans la jungle

C'est un peu comme si l'engine etait geré et développé par une equipe dynamique moderne et efficace
Et que les outils admin etaient développés par une équipe de pachyderme rouillés ayant développpé leurs savoir sur Access (c'est l'homme frustré qui parle )

Dans le debat "Qu'est ce qui manque selon vous a SqlServer" je vote haut la main pour "Un ou des outils admin mieux concu plus intuitifs"

[mikedavem]

Là je ne suis pas d'accord !!
Il ne faut pas confondre le Nom logique de la base de donnée et le chemin Physique des fichier qui vont la contenir !!

Que le nom logique doive etre spécifié dans le script me semble evident
Mais PAS le chemin physique : c'est le serveur qui doit gerer et connaitre cela : ce chemin peut etre différent selon les machines !!
D'ailleurs pour utiliser mon sript j'ai créé la database a la main, j'ai supprimé du script le code spécifique a la création de la base et je l'ai executé

Vous pouvez tout à fait créer une base de données sans préciser quoi que ce soit.

Code :

CREATE DATABASE <mabase>;

Simplement vous demandez un script de la base de données c'est donc normal qu'il vous précise l'ensemble des paramètres de la base. A vous d'enlever les paramètres de fichiers dans ce cas. Cependant comme je vous le disais avant, si vous ne précisez rien SQL Server sera incapable de connaître la taille de vos fichiers, les paramètres d'autogrowth, le nombre de fichiers etc .... Si vous ne précisez rien ce sont les paramètres par défaut du serveur en question qui seront appliqués.

++

[olibara]

Merci Mikedavem

Oui je comprends mais c'est précisément sur ces points là que je trouve que les outils de management sont franchement peu conviviaux et d'une technologie d'un autre age

L'outil de génération de script pourrait offrir une interface plus claire et explicite sur les différentes options

[serge0934]

le plus simple, si ta base n'est énorme est de passer par l'exportateur de datas;

tu te mets dans SSMS (explorateur SQL)
tu sélectionne la base de départ et tu te mets sur le nom de la base
click droit
all tasks
export datas
et tu suis ce qu'on te demande

[olibara]

Merci Serge0934

Oui je connais et effectivement je suis déja parvenu à "bricolé" une solution

Mais si ma base avait fait quelques centaines de MB je pense que j'etais cuit car le probleme fondamental c'est que SQL server n'assure meme pas de compatibilité ascendante entre les version de server si l'on veut faire un restore de Back-Up sur un autre serveur que l'original

[zinzineti]

Envoyé par olibara

Merci Serge0934

Oui je connais et effectivement je suis déja parvenu à "bricolé" une solution

Mais si ma base avait fait quelques centaines de MB je pense que j'etais cuit car le probleme fondamental c'est que SQL server n'assure meme pas de compatibilité ascendante entre les version de server si l'on veut faire un restore de Back-Up sur un autre serveur que l'original

Compatibilité ascendante ?! non ! ça n'a pas de sens !

Vous pouvez utiliser la réplication pour obtenir le même résultat.

Par ailleurs même si vos données sont de l'ordre du Go ou To le Wizard Import/Export de SQL SERVER fait bien le boulot d'import des datas vers le nouveau serveur

Avec ce même Wizard vous pouvez générer le script de création des :

--> tables/index/contraintes/vues
--> procédures stockées / fonctions / ...
--> ...

[Ptit_Dje]

Envoyé par zinzineti

Compatibilité ascendante ?! non ! ça n'a pas de sens !

Compatibilite ascendante ? Vous voullez dire de 2005 a 2008 ou de 2008 a 2008R2 ?
Evidemment que ca a du sens et est completement supporte...

Comment effectuer vous votre backup et comment effectuez vous votre restore ?
Quel est le message d'erreur exact ?
Quelles sont les editions des 2 serveurs ?

[elsuket]

Bonjour,

Si je suis certain qu'il est impossible de restaurer une base de données de version b sur une version a, où a < b, il est clair que restaurer une base de données d'une version a sur une b est possible.

D'ailleurs on peut migrer de SQL Server 2000 à 2008 d'un trait ...
Quelle est l'erreur que vous obtenez quand vous restaurez la base de données SQL Server 2008 (10.0.x.y) sur une instance SQL Server 2008 R2 (10.50.w.z) ?

@++

[mikedavem]

mais la Machine source utilise la version 2008 10.27 etc..
La machine destination utilise la version 2008 10.50 etc..

Au vu des informations suivantes (si elles sont excates) je pense que le message d'erreur n'a rien à voir avec un problème de compatibilité descendante. La compatibilité ascendante fonctionne très bien (comme le précise Ptit_Dje).

Il faudrait avoir le message d'erreur exact rencontré lors de la restauration ?

++

[zinzineti]

Envoyé par elsuket

Bonjour,

Si je suis certain qu'il est impossible de restaurer une base de données de version b sur une version a, où a < b, il est clair que restaurer une base de données d'une version a sur une b est possible.

@++

Petite précision : a <= b ( a inférieur ou égal à b )

[olibara]

Merci à tous

Bon et bien peut etre que je me suis laissé embrouiller !

Je vais retenter l'experience du Back-Up restore et voir si j'ai toujours le meme problème

Le cas échéant je tranmetrai a votre sagacité ce que SQL Server veut bien me donner comme information

N.B. : J'essaye des que possible peut-etre pas ce soir

[SQLpro]

Comme déjà dit, la compatibilité ascendante fonctionne parfaitement et ce depuis les version 2000 jusqu'à 2005, 2008, 2008 R2
ou de 2005 à n'importe quelle version 2008 ou de 2008 à 2008 R2.

CEPENDANT... vous ne pouvez pas migrer d'une version Standard, Entreprise ou autre vers SQL Server EXPRESS, si la base fait plus de 10 Go... Et il existe d'autres limitations de ce genre !

C'est pourquoi au lieu de perdre du temps stupidement et de crier contre vous même, commencez par respecter les demandes que l'on vous formule pour vous aider.

En particulier :
1° nous renvoyer les données obtenue par la requête SELECT @@VERSION pour chacun des serveur (demande formulé dans la première réponse à votre post)
2° nous renvoyer les messages d'erreur, car même s'ils vous semblent abscons, parce que vous ne connaissez pas le système, ils sont en général très parlant pour nous (demande formulée par ptit_dje hier à 17h25).

A +

[olibara]

Merci SQL Pro

Je vais prendre le temps ce soir de réessayer un Back-Up / Restore et fournir pour l'occasion toutes l'information et messages que j'obtiendrais

- Version des deux server
- Messages d'erreur eventuels

[elsuket]

Bonjour,

Vous pouvez aussi utiliser ce petit billet pour la version

Envoyé par zinzinetti

Petite précision : a <= b ( a inférieur ou égal à b )

Bien vu

@++

[olibara]

Merci tout le monde

Effectivement a force de me heurter aux difficultés j'ai du m'embrouiller quelque part

Je viens de réessayer le Back-Up / Restore sur deux serveur distinct : ca a fonctionné
N.B. : Je n'ai pas eu le cas mais je le sens venir : existe-il une methode accessible a un profane comme moi qui permettrait de transporter les user login spécifique a la base Back-Uppée du serveur 1 vers le server 2 ?

SELECT @@Version sur Machine source

Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (Intel X86) Mar 29 2009 10:27:29 Copyright (c) 1988-2008 Microsoft Corporation Express Edition on Windows NT 5.1 <X86> (Build 2600: Service Pack 3)

SELECT @@Version sur Machine destination

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1617.0 (X64) Apr 22 2011 19:23:43 Copyright (c) Microsoft Corporation Express Edition with Advanced Services (64-bit) on Windows NT 6.1 <X64> (Build 7600: )

[elsuket]

Avec les versions, il est normal que cela ait fonctionné

Pour les utilisateurs, il suffit de passer dans la base de données pour tous les utilisateurs, et d'exécuter :

Code :

1
2
ALTER USER monUtilisateur
WITH LOGIN = loginDeUtilisateur

Et le tour est joué.
Cela suppose que le login est déjà présent.

Si vous voulez faire une procédure stockée, et que par chance vos logins sont identiques à vos noms d'utilisateur, il vous faut comparer la colonne sid de la vue système sys.database_principals (les utilisateurs de base de données) avec celui que vous trouvez dans la vue système sys.server_principals (les logins).

@++

[mikedavem]

Il est fort ce Elsuket

++