J'ai récemment mis à niveau la base de données SQL Server 2000 vers 2008 R2.
Ce que j'ai fait était:
Question: Que dois-je faire d'autre pour terminer la migration?
Je veux:
En d'autres termes: Je veux juste savoir comment convertir correctement et complètement l'ancienne base de données SQL 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.
Je pose cette question, parce que j'ai trouvé beaucoup de sites sur Internet qui disent tellement de choses différentes qui me rendent confus: certains disent qu'il est nécessaire de reconstruire les index, un autre dit de faire d'autres choses ... et maintenant je ne sais rien donc je veux entendre l'opinion d'une personne expérimentée et des instructions claires, étape par étape. Je travaille pour une très petite entreprise, je suis seul et je ne veux pas foirer les choses.
Monsieur, je suis vraiment impressionné par votre réponse, je ne m'attendais pas à tant de choses.
Donc quelques commentaires:
La base de données est maintenant en production. Comme je l'ai dit, il a été mis à niveau en utilisant la méthode deattach-attach comme je l'ai décrit dans le premier post et comme décrit sur MSDN: http://msdn.Microsoft.com/en-us/library/ms189625.aspx Cela devait être fait rapidement, alors j'ai été obligé de le faire de cette façon. Oublions à quel point cela pouvait être inapproprié et concentrons-nous sur la situation actuelle.
Les utilisateurs/persmission ne sont pas un problème ici - il n'y en a que peu et les autorisations sont simples.
L'application qui utilise la base de données est compatible avec SQL 2000 jusqu'en 2012, ce n'est donc pas un problème non plus.
Le fichier de base de données (MDF) n'est pas gros - seulement environ 1 Go.
Quelques questions supplémentaires:
Vous recommandez d'utiliser la méthode de sauvegarde/restauration, mais j'ai fait comme écrit ci-dessus, puis-je rencontrer des problèmes maintenant? Tout a fonctionné sans problème.
À propos du modèle de somme de contrôle et de récupération complète: il n'était pas disponible/activé sur SQL 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 cela ne suffisait pas et je devrais également reconstruire des index ou quelque chose. Je ne sais vraiment pas, je demande juste.
Je prépare en amont pour migrer cette base de données vers SQL 2012 - donc d'abord c'était de SQL 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 des bases de données SQL 2000 dans SQL 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?
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?
Comme nous utilisions SQL 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 2008, n'est-ce pas toujours mieux que d'utiliser la fonction de sauvegarde dans Management Studio?
Mode de récupération complète avec des sauvegardes fréquentes du journal des transactions - Où est stocké le journal des transactions - est-ce le fichier LDF? Comment puis-je le sauvegarder correctement?
Je sais que mes questions peuvent sembler idiotes, je ne suis pas un administrateur professionnel de la base de données, mais je suis la seule personne ici à pouvoir effectuer une telle tâche "hard core" comme la mise à niveau du moteur de base de données. Je suis également sûr que vos connaissances aideront beaucoup d'autres personnes comme moi.
Merci beaucoup pour votre temps et vos connaissances, j'apprécie vraiment cela.
L'étape la plus importante consiste à exécuter le Conseiller de mise à niveau sur la base de données SQL Server 2000 et résolvez tous les problèmes signalés par celle-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:
DBCC CHECKDB ('<db_name_goes_here>' ) WITH ALL_ERRORMSGS,NO_INFOMSGS, DATA_PURITY
DBCC UPDATEUSAGE('database_name') WITH COUNT_ROWS
Update Statistics table_name with FULLSCAN
sp_recompile 'procedureName'
SP_REFRESHVIEW view_name
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 amorti en 2012), vous devez également le réinitialiser.
Anciens 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 en utilisant Assistant de migration de package .
En outre, vous pouvez utiliser mon script trouvé à https://dba.stackexchange.com/a/36701/878 . Cependant, 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 note:
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.
CHECKSUM
est 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 model
n'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 données perdues.
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 100
avec 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 se trouvent des étapes dont je me souviens et je suis pratiquement 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.
Quelques questions supplémentaires:
Vous recommandez d'utiliser la méthode de sauvegarde/restauration, mais j'ai fait comme écrit ci-dessus, puis-je rencontrer des problèmes maintenant? Tout a fonctionné sans problème.
Si tout fonctionnait bien et que vous pouviez attacher 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 allait mal (dans le pire des cas), puis au moins vous avez une sauvegarde à 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 cela ne suffisait pas et je devrais également 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. C'est juste SQL Server qui l'appelle .. sauvegarde/restauration.
A lire: Comprendre les sauvegardes SQL Server par Paul Randall.
Syntaxe simple (pour la syntaxe complète, reportez-vous à 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ù est stocké le journal des transactions - est-ce le 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 à Gestion du journal des transactions et ma réponse ici a également d'excellents liens.
Si vous migrez l'intégralité de votre instance d'une version à une autre, je recommande fortement d'utiliser la solution basée sur PowerShell Start-SqlMigration