Bonjour,
 
notre serveur SQL Server 2000 se fait vieux. Nous avons donc acheté un tout nouveau serveur. J'ai installé SQL Server 2000 sur le nouveau serveur, et à présent il me reste la tâche délicate de migrer toutes les databases (une centaine) de l'ancien, vers le nouveau serveur. Je dois également recuperer les Logins, users, etc etc ...
 
Helas, je suis assez nouveau dans la boite, et je n'ai encore jamais fait ça. Quelqu'un peut me dire quelle est la procédure la plus simple et la plus sûre pour effectuer cette migration ??
 
Merci d'avance !!

Salut,
 
pour migrer les bases de données je pense qu'un simple detach de chaque base sur l'ancien, copie des fichiers sur le nouveaux server, puis attach de chaque base sur le nouveau sql server devrait suffire.
 
Pour les logins je sais pas trop, vaut mieux que quelqu'un d'autre reponde
 
a+

Ok merci
 
Sinon, si je veux garder l'ancien serveur au cas où, un Import / Export Data avec l'option "Copier tous les objets" activée, ça marche aussi, mais c'est plus long non ?

Oula! Les DTS je deteste ca, je veux pas en entendre parler. Je saurai donc pas trop t'aider avec cette technique

Plusieurs solutions :
1/ Tu restores les backups de l'ancien serveur sur le nouveau
2/ Tu fais un lot DTS de récupération des objets. Sauf qu'au lieu de l'exécuter, tu l'enregistre. Après, tu le modifies pour qu'il boucle sur toutes tes bases.
 
Slash- > Qu'est-ce qui t'ennuie avec DTS ?

Dois-je inclure les bases system (Master, etc etc) dans ma migration ?
 

Non, les bases systèmes sont toujours présentes sur une instance de SQL Server. Les données qu'elles contiennent dépendent des autres bases, il ne faut en aucun cas les "forcer". Contente-toi de prendre les tables que tu as créé toi-même.

Voilà ! La migration s'est bien déroulée, et m'a occupé une bonne partie de la nuit ...
 
J'ai coupé l'ancien serveur, copié l'intégralité des fichiers MDF/LDF sur le nouveau serveur (toutes les bases utilisateurs, pas les bases systèmes), puis j'ai fait un Attach Database sur chacune des bases. Cependant, il subsiste un problème et non des moindres :
 
- Tous nos sites attaquaient la base de données avec Iusr / Iusr comme User / Pwd. Ce login etait présent dans la partie Logins / Security de SQL Server, mais dans les permissions, aucune base ne lui était attaché. Lorsque je tentais de lui attacher une DB via la petite Checkbox, il me disait que ce login existait déjà. J'étais donc obligé de supprimer le login user, présent cette fois dans la partie Users de chaque DB, pour pouvoir lui assigner la DB en question, ce qui a eu pour effet de recréer le iusr précédemment effacé, mais sans aucune permission d'accès !!! Donc, dans chaque DB, j'ai du réactiver toutes les permissions (stored procedures, Select des tables, etc etc ...), ce qui équivaut à environ 150 check par DB, et il y a 150 DB. Pa rmanque de temps, donc, j'ai preferé dans un premier temps changer l'identifiant de connexion sur tous nos sites, en utilisant le sa qui lui par défaut, donne accès à tout.
 
Donc voici ma question : Y a t il une possibilité de réassigner toutes les bases au login iusr sans avoir à les effacer un par un dans chaque DB et recréer toutes les permissions d'acces ? Sinon, y a t il un réel risque de configurer ses sites avec le login sa ?
 
Voilà, désolé si ce message est un peu confus, et merci d'avance de m'éclairer

Ah oui, la migration des droits, c'est toujours le bordel...
 
Bon, vu ce que tu racontes, ça tombe bien, y'avais un sacré boulot de mise en place d'une réelle politique de sécurité dans vos bases !
 
Dans un premier tems :

 
sa, comme son nom l'indique ("super administrateur" ), ben... c'est l'équivalent d'un point de vue logique du compte "administrateur" de NT.
En admin système avisé, vas-tu permettre à tes utilisateurs d'utiliser le compte admin du domaine pour lire leurs mails ? Voilà, t'as ta réponse
 
C'est d'autant plus vrai que le compte sa est un synonyme du compte Administrateur local de la machine. Ainsi, avec ce compte, on peut faire un sacré paquet de conneries, style éxécuter des instructions CMD depuis la base, ou autres joyeusetés qui peuvent rapidement guider à un point de non retour.
 
Ensuite, donner le même login/pass à toutes les bases, c'est archi-moyen... J'en déduis vu le nom, que vous faites de l'hébergement de site internet (ou intranet). Je ne sais pas si ce sont des clients interne ou non, mais même en interne, je doute que vos clients trouvent ça sympa qu'un concurrent (même entre services ça arrive, plus que sur le marché d'ailleurs) vienne trifouiller dans le base. Utiliser des comptes un peu plus sécurisés est donc un peu plus safe...
 
Ensuite, IIS permet d'authentification à SQL Server via le compte NT. SQL Server support les connections avec des login NT, donc autant en profiter.
 
Vous avez deux choix distincts :
- la non-restriction de lecture/écriture d'une base à l'autre ne vous dérange pas du tout (autres systèmes de sécurité, données absolument pas importantes, client unique, etc.)
=> Créez un groupe de droits dans SQL Server. Donnez des droits à ce groupe (ou rôle) dans les bases. Dans IIS, vérifiez que vous utilisez le compte "IUSR_nommachine" pour faire tourner chaque site. Si c'est sur la même machine que SQL Server, alors laisse comme ça. Sinon, mettez un nouveau compte :
login: tôt¤_l@~prà|iñ€
passe : QbAâ-p2_}¨=Ât|5,ˆ0ˆ§äÛH$FE8Îd>¨RJ¡¨A’dÛmoÛq3
=> c'est c'est du mdp ou je ne m'y connais pas (prendre un divx ou un mp3 dans notpad, copier une ligne, et virer tous les caractères pas faisables au clavier / le code barre du de la carte mère, c'est pas mal aussi, mais les suites numériques à 13 chiffres ça se carck en moins d'une heure sur un PC récent). Sur le serveur SQL Server, créer le même compte (sauf si c'est IUSR_xxx).
Dans SQL Server, attribuer à ce compte le rôle que vous avez créé juste avant.
- Vous ne voulez pas qu'un site puisse se connecter à une autre base que la sienne
=> Créez pour chaque site un compte NT et faite tourner chaque site avec son propre compte
Sur le serveur SQL, recréez ces mêmes comptes, et donnez leur l'accès à la base correspondante.
 
Avantage pour une migration : il suffit de répliquer les droits NT sur le nouveau serveur. Si vous bossez en domaine, c'est aisé, mais malheureusement non recommandé par Microsoft.
 
Ensuite, la chaîne de connection SQL Server depuis les sites :
"Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=NOM_DE_LA_BASE;Data Source=NOM_OU_IP_DE_SQL_SERVER (local si en local)"
 
Sinon, pour en revenir à la question de départ, malheureusement, je ne vois pas de solution miracle à moins d'écrire un script T-SQL qui fasse le boulot.

Merci beaucoup pour ton aide
 
Je vois que le boulot est encore loin d'être terminé donc Surtout que notre IIS n'est pas sur la même machine !!
 

Là ça risque d'être chiant. En effet, je ne suis pas certain que créer les mêmes comptes sur les deux machines soit suffisant... Si possible, essayez de mettre en domaine les deux machines afin d'éviter tout problème...