La première étape consiste à exécuter le Conseiller de mise à niveau sur la base de données SQL Server 2000 et à résoudre tous les problèmes signalés par celui-ci.
À titre de meilleure pratique, utilisez l'outil Upgrade Advisor sur votre base de données héritée SQL Server 2000 et importez un fichier de trace dans l'outil Upgrade Advisor pour analyse. Le fichier de trace permet au Conseiller de mise à niveau de détecter les problèmes qui pourraient ne pas apparaître dans une simple analyse de la base de données, tels que TSQL intégré aux applications. Vous pouvez capturer des traces de TSQL à l'aide de SQL Profiler sur votre serveur SQL Server 2000 pendant les heures habituelles et analyser ces traces à l'aide du Conseiller de mise à niveau.
Donc, le reste des étapes serait:
Le jour de la migration:
- script nos connexions sur le serveur 2000 en utilisant sp_help_revlogin .
- Scriptez les travaux et les serveurs liés à partir du serveur SQL 2000.
- arrêter les serveurs Web de se connecter au serveur 2000. Assurez-vous qu'aucune application ne se connecte au serveur 2000.
- sauvegardez vos bases de données et restaurez-les sur le serveur sql 2008 R2 de destination.
- Une fois vos sauvegardes restaurées sur le serveur 2008 R2, exécutez la sortie de sp_help_revlogin sur le serveur 2008 R2 pour recréer les connexions.
- Synchronisez les utilisateurs orphelins (le cas échéant) et recréez les travaux de l'agent SQL et les serveurs liés sur le nouveau serveur.
- changer le niveau de compatibilité sur les bases de données restaurées à 100.
- Dbcc checkdb avec les options all_errormsgs et data_purity activées:
DBCC CHECKDB ('<db_name_goes_here>' ) WITH ALL_ERRORMSGS,NO_INFOMSGS, DATA_PURITY
- exécuter DBCC UPDATEUSAGE sur les bases de données restaurées
DBCC UPDATEUSAGE('database_name') WITH COUNT_ROWS
- Mettre à jour les statistiques sur toutes les tables avec analyse complète:
Update Statistics table_name with FULLSCAN
- Facultatif: vérifiez les niveaux de fragmentation et, en fonction du niveau de fragmentation, exécutez une réorganisation / reconstruction de tous les index. Vous pouvez utiliser les scripts d'Ola .
- Recompiler tous les SP en utilisant
sp_recompile 'procedureName'
- Rafraîchissez vos vues
SP_REFRESHVIEW view_name
- assurez-vous de changer l'option de base de données: page vérifier en CHECKSUM.
- Remplacez le modèle de récupération (s'il diffère de SQL 2000) par PLEIN. Si vous passez au modèle de récupération COMPLET, assurez-vous que vous effectuez fréquemment des sauvegardes du journal des transactions. Cela vous aidera à récupérer un point dans le temps et à ne pas gonfler votre T-Log.
Dans SQL Server 2005 et versions ultérieures, Database Mail a été introduit. Vous devez donc migrer de SQLMail vers Database Mail.
USE [master]
GO
sp_configure 'show advanced options',1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'Database Mail XPs',1
GO
RECONFIGURE
GO
De plus, si vous avez une réplication, vous devez la réinitialiser. Si un DR comme l'expédition de journaux ou la mise en miroir (nouveau en 2005 et supérieur, mais déprécié en 2012), vous devez également le réinitialiser.
Les anciens packages DTS doivent être migrés vers SSIS à l'aide de C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTSMigrationWizard.exe(ligne de commande) ou à l'aide de l' assistant de migration de package .
En outre, vous pouvez utiliser mon script disponible sur /dba//a/36701/8783 . Bien qu'il utilise la méthode detach / attach, je vous recommande fortement d'utiliser la méthode BACKUP / RESTORE . Modifiez le script en conséquence.
En remarque:
- activez l' initialisation instantanée des fichiers sur le nouveau serveur.
- Avoir plusieurs fichiers de données tempdb de taille égale.
- Activer l'indicateur de trace 1118
- Configurez correctement la mémoire max et min. Surtout la mémoire Max loin de la valeur par défaut.
- Ajustez correctement les paramètres MAXDOP. Reportez-vous à /dba//a/36578/8783 pour plus de détails.
- Le mieux est d'installer sp_Blitz de Brent Ozar. Exécutez-le et résolvez les problèmes critiques et hautement prioritaires signalés par celui-ci.
- Vous pouvez même utiliser SQL Power Doc de kendalvandyke - SQL Power Doc fonctionne avec toutes les versions de SQL Server de SQL Server 2000 à 2012, et toutes les versions de Windows Server et des systèmes d'exploitation Windows grand public de Windows 2000 et Windows XP à Windows Server 2012 et Windows 8. Également utile pour la planification des mises à niveau - voyez quelles fonctionnalités masquées sont utilisées sur une instance.
- Activez Optimiser pour les charges de travail ad hoc et les options de compression de sauvegarde par défaut.
Permet de répondre à vos questions ...
Que dois-je faire d'autre pour terminer la migration?
Référez-vous à ma réponse. Il vous aidera à élaborer correctement un plan de migration. Testez toujours votre plan de migration dans un UAT (hors production) avec des tests d'application appropriés par les utilisateurs professionnels.
utiliser de nouvelles fonctionnalités comme le checksum et le modèle de récupération complète.
CHECKSUMest nouveau dans SQL Server 2005 et versions ultérieures. Je l'ai couvert dans le cadre des étapes de migration décrites ci-dessus.
full recovery modeln'est pas nouveau. Cela dépend de votre type d'entreprise et dicte la quantité de données que vous pouvez perdre en cas de catastrophe.
Le mode de récupération complète avec des sauvegardes fréquentes du journal des transactions vous permettra de restaurer instantanément et là-bas en réduisant la quantité de perte de données.
faire en sorte que cette base de données soit exactement telle qu'elle a été créée dans SQL Server 2008 R2.
rendre cette base de données entièrement compatible, correcte et parfaitement adaptée au nouveau moteur de base de données SQL 2008 R2.
Je ne comprends pas bien ça! Mais les étapes de migration ci-dessus vous aideront. Il vous suffit de restaurer la base de données et de modifier le niveau de compatibilité 10 100avec les étapes ci-dessus.
Je veux juste savoir comment convertir correctement et complètement l'ancienne base de données SQL Server 2000 en nouvelle base de données 2008 R2, être calme que tout est bien fait et être satisfait de toutes les nouvelles fonctionnalités.
Vous devez être prudent avec cela, car cela nécessitera également des modifications de votre code d'application. Si votre code d'application est modifié pour utiliser les nouvelles fonctionnalités de SQL Server 2008 R2, vous ne rencontrerez aucun problème - À condition que vous ayez effectué un test de régression complet de votre application dans un environnement UAT ou DEV. Cela vous donnera une meilleure confiance lorsque vous effectuez la migration réelle dans PROD.
Remarque: ci- dessus sont des étapes dont je me souviens et je suis presque sûr que rien n'est oublié. Si je vois que j'ai raté des trucs, alors je les ajouterai ou d'autres experts sur ce site - n'hésitez pas à ajouter!
Tout ce qui est décrit ci-dessus doit d'abord être rejoué sur un environnement NON PRODUCTION pour éviter toute surprise lors de la migration réelle.
----------
Encore quelques questions:
Vous recommandez d'utiliser la méthode de sauvegarde / restauration, mais j'ai fait comme écrit ci-dessus, donc puis-je rencontrer des problèmes maintenant? Tout a fonctionné sans problème.
Si tout fonctionnait bien et que vous pouviez joindre la base de données, alors NON, vous n'aurez aucun problème. Détacher / Attacher vs Sauvegarder / Restaurer n'est qu'une méthode sur la façon dont vous déplacez vos bases de données vers un autre endroit. Juste FYI .. La sauvegarde / restauration est plus sécurisée et fiable comme si quelque chose ne va pas (dans le pire des cas), puis au moins vous avez une sauvegarde pour restaurer et récupérer votre base de données / s.
À propos du modèle de somme de contrôle et de récupération complète: il n'était pas disponible / activé sur SQL Server 2000, donc je veux les utiliser maintenant. Vous avez dit que la seule chose que je dois faire est d'activer ces options dans les propriétés de la base de données? J'ai lu quelque part, que ce n'est pas suffisant et je devrais aussi reconstruire des index ou quelque chose. Je ne sais vraiment pas, je demande juste.
Comme je l'ai dit, la somme de contrôle est nouvelle dans la version 2005 et plus. Il s'agit d'un mécanisme par lequel SQL Server détectera la corruption de pages, notamment en raison des E / S. Reportez-vous à ma réponse ici pour plus de détails.
Pour activer CHECKSUM et changer le modèle de récupération en FULL, vous pouvez le faire en utilisant le code T-SQL ci-dessous:
USE master;
GO
ALTER DATABASE [your_database_name] -- change this !!
SET RECOVERY FULL, PAGE_VERIFY CHECKSUM;
GO
Remarque: Une fois que vous avez défini les options de base de données, elles seront conservées lors de la migration de 2008R2 vers 2012.
Je me prépare à migrer cette base de données vers SQL Server 2012 - donc d'abord c'était de 2000 à 2008 R2, maintenant ce sera de 2008 R2 à 2012 (il était impossible de le faire directement en raison du manque de prise en charge de 2000 bases de données dans SQL Server 2012). Je comprends donc que je devrais suivre votre guide: le sauvegarder en 2008 R2 et restaurer en 2012, puis faire le reste de vos conseils, non?
Oui s'il vous plaît. Comme je l'ai dit, la restauration de sauvegarde est la méthode préférée , sauf si vous avez une bonne raison de ne pas le faire.
Veuillez m'expliquer la méthode de sauvegarde / restauration: est-ce comme un vidage de la base de données vers des requêtes SQL, puis la restaurer en exécutant un tas de requêtes? Cette méthode va-t-elle d'ailleurs "défragmenter" ma base de données? Sinon, comment défragmenter / optimiser manuellement?
La sauvegarde / restauration est ... similaire au vidage et à la charge utilisés dans Sybase, Oracle ou probablement MySQL également. C'est juste SQL Server qui l'appelle .. sauvegarde / restauration.
A lire absolument: Comprendre les sauvegardes SQL Server par Paul Randall.
Syntaxe simple (pour la syntaxe complète, voir BOL ):
backup database database_name
to disk = 'D:\backup\database_name_full.bak'
with init, stats =10
La restauration peut alors être effectuée sur le serveur de destination comme:
- en supposant que la disposition du disque de destination ne correspond pas à celle du serveur source
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
move 'logical_data_fileName' to 'physical_path\database_name.mdf'
move 'logical_log_fileName' to 'physical_path\database_name_log.ldf'
with recovery, stats = 10
- en supposant que la disposition du disque de destination correspond à celle du serveur source
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
with recovery, stats = 10
Cette méthode va-t-elle d'ailleurs "défragmenter" ma base de données? Sinon, comment défragmenter / optimiser manuellement?
la sauvegarde / restauration ne défragmentera pas votre base de données. Vous devez utiliser Alter Index Reorganize ou Rebuild en fonction de votre niveau de fragmentation.
Puisque vous êtes nouveau sur SQL Server, je vous recommande fortement d'utiliser Ola Hallengren:
Comme nous utilisions SQL Server 2000 Express depuis des années (pas d'interface de gestion), nous faisions des sauvegardes simplement en arrêtant le moteur et en RAR le répertoire DATA. Pour l'instant, comme nous sommes sur SQL Server 2008, n'est-ce pas toujours mieux que d'utiliser la fonction de sauvegarde dans Management Studio?
Arrêter le moteur est la pire chose que vous puissiez faire pour faire une sauvegarde !!
Lisez le lien de Paul sur les sauvegardes que j'ai mentionnées et utilisez le script d'Ola. Microsoft a un article de la base de connaissances avec le script pour effectuer des sauvegardes automatisées - Comment planifier et automatiser les sauvegardes des bases de données SQL Server dans SQL Server Express
Mode de récupération complète avec des sauvegardes fréquentes du journal des transactions - Où le journal des transactions est-il stocké - s'agit-il du fichier LDF? Comment puis-je le sauvegarder correctement?
Chaque base de données SQL Server possède un journal qui enregistre toutes les transactions et modifications de base de données effectuées par chaque transaction. Le journal des transactions est un composant essentiel de toute base de données.
L'extension de convention de dénomination habituelle pour le journal des transactions est «.LDF», mais elle peut être n'importe laquelle.
Je ne vais pas écrire plus à ce sujet car cela rendra la réponse très maigre. Reportez-vous à
Transaction Log Management et ma réponse ici contient également d'excellents liens.
EDIT: 24/08/2016 .. Cela aidera les futurs lecteurs:
Si vous migrez l'intégralité de votre instance d'une version à une autre, je vous recommande vivement d'utiliser la solution basée sur PowerShellStart-SqlMigration
