SQL Server 2008 SP2 - Déplacer une base de données, depuis une instance par défaut, vers une instance nommée

Bonjour à tous,


J'apprends par la force des choses à utiliser MS SQL Server 2008, pour un ERP dans mon entreprise.

Actuellement, nous disposons d'un serveur avec une instance par défaut, et une bonne dizaine de bases à l'intérieur.

Ma hiérarchie voudrait que pour les différentes bases, nous séparions les instances, sur le même serveur.

J'envisage donc de créer 5 instances nommées, afin de pouvoir leur attribuer une base chacune.

Étant assez novice en la matière, j'imaginais simplement restaurer les bases dans les différentes instances désirées, et "recopier" les droits à la main.

C'est carrément barbare, et je ne sais pas si c'est une méthode qui pourrait fonctionner (je pense sincèrement que non), mais je suis justement la pour essayer de comprendre le fonctionnement.

Je vous remercie de me lire, et reste disponible pour donner plus d'information.

Cordialement,

Bonjour,

dans ton cas tu veux modifier l'instance de ta bdd, pour moi la sauvagarde et restauration est la meilleure solution. De toute façon il faudra la créer dans ta nvelle instance pour qu'elle s'inscrive dans les nvelles tables systèmes donc autant la restaurer.

Citation:

---

Ma hiérarchie voudrait que pour les différentes bases, nous séparions les instances, sur le même serveur.

---

Pourquoi ? Quelle est la motivation de votre hiérarchie à ce propos ? Installer et multiplier les instances sur un serveur n'est pas sans conséquence pour l'administration et les performances.

Citation:

---

Étant assez novice en la matière, j'imaginais simplement restaurer les bases dans les différentes instances désirées, et "recopier" les droits à la main.

C'est carrément barbare, et je ne sais pas si c'est une méthode qui pourrait fonctionner (je pense sincèrement que non), mais je suis justement la pour essayer de comprendre le fonctionnement.

---

Vous pouvez procéder par backup / restore ou détach / attach des bases de données. Ensuite si le nombre d'objets de serveurs associés à vos bases est relativement petit .. vous pouvez tout à fait recréer le tout à la main (en n'oubliant pas de remapper vos logins si ceux-ci sont de type SQL.

++

Bonjour,

Plusieurs solutions sont possibles effectivement.
Je préfère lors de migration de serveurs, faire des détache/rattache.

Tout d'abord, merci pour vos réponses.

Citation:

---

Envoyé par mikedavem

Pourquoi ? Quelle est la motivation de votre hiérarchie à ce propos ? Installer et multiplier les instances sur un serveur n'est pas sans conséquence pour l'administration et les performances.

---

La justification est la suivante :
- Séparer les bases dans plusieurs instances, permettrait d'avoir un agent SQL par instance, et de pouvoir les redémarrer indépendamment les unes des autres
- Il y aurait plusieurs fichiers tempDB, et ça serait un avantage :aie:
(justification que je répète, je me renseigne sur leur pertinence)

Citation:

---

Envoyé par mikedavem

Vous pouvez procéder par backup / restore ou détach / attach des bases de données. Ensuite si le nombre d'objets de serveurs associés à vos bases est relativement petit .. vous pouvez tout à fait recréer le tout à la main (en n'oubliant pas de remapper vos logins si ceux-ci sont de type SQL.

---

Je maitrise le backup/restore, donc je pense que je verrai pour tester cette méthode la. Je ne sais pas detach/attach, donc c'est réglé ^^.
Notre base est quand même énorme, puisque nous avons toute la suite SAGE 100 dessus, alimentée tous les jours par environ 50 personnes simultanément.

Mon projet consiste à basculer tout sur un nouveau serveur, créer 5 instances pour 5 bases (Gescom, Compta, MdPaiement, Immo). Et j'ai actuellement une base, dont la société se divise en 2, et je dois repartir sur 2 nouvelles bases "neuves" en effectuant des extractions/importations sélectionnés.

Pour les droits de connexion accordés actuellement, c'est un groupe utilisateur d'Active Directory.

Bonjour,

Citation:

---

Séparer les bases dans plusieurs instances, permettrait d'avoir un agent SQL par instance, et de pouvoir les redémarrer indépendamment les unes des autres

---

Cela n'a aucune utilité. Il suffit d'avoir le nombre adéquat de jobs, ce qui ne pose pas de problèmes.
Redémarrer une instance n'est d'aucune utilité, à part celle de perdre le cache de données et de procédures, de prendre le risque que les bases de données soient corrompues au redémarrage parce que SQL Server n'a pas pu maintenir l'intégrité d'une transaction, ..., ... , ...

Citation:

---

Il y aurait plusieurs fichiers tempDB, et ça serait un avantage

---

Là encore, c'est une ineptie. On peut tout à fait augmenter le nombre de fichiers dans TempDB, mais il faut savoir pourquoi on le fait.
En général c'est pour limiter la contention au niveau des pages d'allocation, ce qui suppose que l'ERP fait une utilisation extensive des tables temporaires et des variables de type TABLE; ce n'est pas étonnant pour un ERP ...

En outre il faut que ces fichiers aient exactement la même taille pour que SQL Server puisse les remplir de façon proportionnelle, et les mapper à un CPU ou groupe de CPU.

Citation:

---

Je ne sais pas detach/attach, donc c'est réglé ^^.

---

Détacher une base de données de son instance consiste à supprimer la base de données de l'instance sans en supprimer les fichiers comme cela se fait avec un DROP DATABASE.
De là vous pouvez déplacer les fichiers (ou les copier) vers un autre emplacement, et procéder à l'attachement en spécifiant le nouvel emplacement de vos fichiers de base de données. Le plus long dans l'histoire, c'est de copier les fichiers et de créer le script de rattachement s'il y a de nombreux fichiers (mais ça se scripte).
Cela dit, je trouve le BACKUP + RESTORE plus sécurisé; mais c'est aussi plus lent ;)

Citation:

---

Mon projet consiste à basculer tout sur un nouveau serveur, créer 5 instances pour 5 bases (Gescom, Compta, MdPaiement, Immo). Et j'ai actuellement une base, dont la société se divise en 2, et je dois repartir sur 2 nouvelles bases "neuves" en effectuant des extractions/importations sélectionnés.

---

C'est à mon avis une totale perte de temps et d'argent en termes de migration et de maintenance future.

@++ ;)

J'ajouterais que 5 instances = 5 licences, ça me fait réfléchir ce genre de trucs ^^

Pour le basculement, passer par du mirroring... :roll:

Citation:

---

5 instances = 5 licences

---

Non si toutes les instances sont sur le meme serveur.

J'avais compris que c'était sur des machines séparées ^^ Sinon le gain de mettre 4 instances de plus sur le même serveur ... 8O

D'apres les explications c'est pour segreger les services/agents par application pour redemarrer les services plus facilement.
Ca permet de redemarrer une instance et impacter un nombre minimal d'utilisateurs. Bonne solution ou pas...

Cependant avec certains "clients difficiles" qui te disent qu'il faut rebooter l'instance et qui ne sont pas contents tant que tu le fais pas (meme si c'est inutile) ca peut parfois faciliter les choses d'un point de vue politique de leur donner une instance dedie... Voir un serveur dedie... (tant qu'ils paient apres tout why not ?!) :)

Apres la segregation par instance est aussi une question de securite souvent.
Si un service account a besoin de SA sur l'instance, il voit donc toutes les donnees de l'instance... Meme de la base de l'application d'a cote...

Citation:

---

Envoyé par Haloavandaha

Ma hiérarchie voudrait que pour les différentes bases, nous séparions les instances, sur le même serveur.

J'envisage donc de créer 5 instances nommées, afin de pouvoir leur attribuer une base chacune.

---

C'est effectivement parfaitement débile et ne peut que vous entrainer dans des problématiques complexes et couteuses :
1) 5 instances => 5 licences
2) SQL Server étant programmée pour accaparer toutes les ressources du serveur vous allez vous retrouver dans un état instable et pour y pallier il faudra fixer les ressources par serveur (CPU affinity, max server memory) et au final, la puissance globale sera nettement moindre, car le réglage n'est pas dynamique.
3) vous allez multiplier la maintenance.
par exemple une procédure de maintenance particulière devra être reproduite sur toutes les instances et maintenue sur chacune, alors que si elle est centralisée sur un seul serveur cela ne pose aucun problème !
par exemple lorsque j'interviens en conseil d'admin je fais des procédures mutualisées qui impacte toutes les bases d'un seul coup, cela simplifie beaucoup les tâches de maintenance. Et qu'il y ait 5 bases ou 50, cela ne coute rien de plus...

Le seule problème est celui de la tempdb. mais il est facilement contournable par un placement et un dimensionnement correcte des fichiers de ladite base.

A +

Citation:

---

Envoyé par SQLPro

Le seule problème est celui de la tempdb. mais il est facilement contournable par un placement et un dimensionnement correcte des fichiers de ladite base.

---

Difficile de la faire comprendre aux Bernard L'Hermite-Admin SAN de tous les employeurs chez qui je suis passé et suis ...

@++ ;)

Voir impossible de leur faire comprendre, quand pour eux un SAN c'est x LUNs de 1 Tera et puis basta.... :)

Have a nice week end !

Je reste d'un avis partagé...

Citation:

---

Envoyé par SQLpro

C'est effectivement parfaitement débile et ne peut que vous entrainer dans des problématiques complexes et couteuses :
1) 5 instances => 5 licences

---

C'est vrai si c'est sur 5 serveurs différents.
Et dans ce cas la le point 2 ci-dessous n'est plus vraiment valable.
Les licences sont par serveur et non par instance.

Citation:

---

Envoyé par SQLpro

2) SQL Server étant programmée pour accaparer toutes les ressources du serveur vous allez vous retrouver dans un état instable et pour y pallier il faudra fixer les ressources par serveur (CPU affinity, max server memory) et au final, la puissance globale sera nettement moindre, car le réglage n'est pas dynamique.

---

C'est vrai que l'administration se fait, dans le cas d'un serveur avec plusieures instances, avec un regard serveur et instances.
Pour ce qui est de la mémoire, c'est une bonne pratique, même avec une seule instance, de fixer le max memory.
Apres reste les CPUs, c'est vrai que dans ce cas la il y a les affinity mask ou WSRM.
A prendre en compte aussi, les ports ! Je pense en particuliers aux endpoints pour le mirroring qui utilise des ports niveau serveur - ca marche pas 2 instances avec le même port pour 1 endpoint... Ça le crée mais niveau connections apres ca joue pas.
Au final tout se résume assez facilement en 1 feuille excel et ce ne sont pas des choses qu'on change tous les jours. Un bon design et c'est partit.
Je trouve même qu'il peut être bien d'utiliser plusieurs instances sur un même serveur lorsque celui-ci est gros car ca permet de le faire travailler comme il faut :) Un peu comme on ferait travailler un gros host avec plein de VMs.

Citation:

---

Envoyé par SQLpro

3) vous allez multiplier la maintenance.
par exemple une procédure de maintenance particulière devra être reproduite sur toutes les instances et maintenue sur chacune, alors que si elle est centralisée sur un seul serveur cela ne pose aucun problème !
par exemple lorsque j'interviens en conseil d'admin je fais des procédures mutualisées qui impacte toutes les bases d'un seul coup, cela simplifie beaucoup les tâches de maintenance. Et qu'il y ait 5 bases ou 50, cela ne coute rien de plus...

---

Effectivement, dans ce cas il faut maintenir un même code à plusieurs endroits.
Avec le Central Management Server et/ou les jobs centralisés aussi, je ne vois pas cette tache insurmontable.
Et rien n'empêche d'utiliser des taches de maintenances gérants plusieures bases en une seule fois comme mentionné :)

Donc voila, je reste partagé comme je disais... Il faut voir au cas pas cas :)

Merci pour toutes vos réponses, je vais prendre le temps de bien vous lire et d'analyser tous vos propos.
Je ne passe pas encore en résolu volontairement :D