SQL Server : Gérer la migration

Migration de bases de données massives jamais peuvent être appelés qu'une tâche facile, mais Microsoft a un outil disponible qui peut aider à soulager la voie et de s'assurer que vous êtes prêt.

Welly Lee

La dernière itération de SQL Server, nom de code « Denali, » offre de nombreuses fonctionnalités impérieuses et conduira à de nombreuses organisations pour déplacer vers SQL Server. Même avec les performances et les avantages de coût total de propriété (TCO) permettant de déplacer vers SQL Server, cependant, certaines organisations peuvent avoir préoccupations concernant les frais et les risques pour la migration de la base de données.

Heureusement, Microsoft fournit un outil, SQL Server Migration Assistant (SSMA), d'automatiser le processus de migration. La dernière SSMA v.5.1 (publié ce mois-ci en même temps avec SQL Server Denali CTP3) appuie migration de bases de données Oracle, Sybase, MySQL et l'accès à SQL Server. Vous pouvez utiliser SSMA pour faciliter votre projet de migration de la base de données. À titre d'exemple, Voici un aperçu du processus de migration à partir d'une base de données Oracle — mais les processus et les étapes sont les mêmes lors de la migration d'autres bases de données.

Évaluer votre base de données

SSMA automatise la migration de la plupart des objets de base de données, y compris les déclencheurs, les fonctions, les colis et les procédures stockées. Il y a quelques types de données spéciaux comme le type de l'objet ou spatiale qui ne sont pas pris en charge par la version actuelle de SSMA. En outre, vous devrez peut-être aussi des déclarations de PL/SQL complexes qui ne peuvent pas être converties automatiquement. Vous pouvez utiliser SSMA pour exécuter une évaluation de la migration sur votre base de données Oracle et de déterminer si votre schéma de base de données contient de telles déclarations.

Les rapports sommaires d'évaluation contiennent les informations suivantes :

• Arborescence du schéma : une liste d'objets à partir du schéma de base de données Oracle source.
• Taux de conversion : le pourcentage des déclarations que SSMA est capable de convertir automatiquement. Pour cet exemple (voir Figure 1), l'outil SSMA peut convertir 99.39 pour cent de toutes les déclarations dans le schéma de Oracle source.
• Objet comte : le nombre de base de données des objets trouvés dans le schéma Oracle et le nombre d'objets « avec des erreurs » (plus sur cela plus tard).
• **Résumé de la conversion Message :**une description des problèmes rencontré lors de la migration du schéma d'Oracle source.

Il existe trois types de messages de conversion vous rencontrerez durant une migration à l'aide de l'outil SSMA : erreur, avertissement et information :

• Un message d'erreur est déclenché lorsque SSMA n'est pas capable de convertir un objet de base de données ou un énoncé dans un objet de base de données.
• A message d'avertissement est déclenché lorsque SSMA est capable de convertir la déclaration d'Oracle, mais l'instruction convertie ne peut pas produire le même résultat pour certains cas. Par exemple, SSMA convertit SUBSTR() Oracle SQL Server SUBSTRING(). Dans la plupart des cas, SUBSTRING() renvoie les mêmes résultats. Il existe certaines situations, cependant, où les résultats sont différents. Par exemple, la fonction SUBSTR() Oracle prend en charge les valeurs négatives pour la position de caractère. SUBSTR('TechNet',-3,3) renvoie « Net » dans Oracle, alors que SUBSTRING('TechNet',-3,3) serait retourne une chaîne vide dans SQL Server.
• Un message d'information est pour SSMA fournir des informations supplémentaires sur la façon dont il convertit certains objets.

La figure 1 un regard sur le taux de Conversion lors de la conversion d'une base de données Oracle.

Chaque message d'erreur comprend un lien qui affiche l'objet contenant l'erreur. Il y a aussi une comparaison côte-à-côte avec la déclaration originale sur la gauche et à quoi pourrait ressembler la déclaration convertie dans SQL Server (voir Figure 2) sur la droite. Le message d'erreur comprend également une estimation du nombre d'heures de conversion manuelle doivent généralement pour résoudre le problème.

La figure 2 vous obtiendrez parfois un message d'erreur de la Migration.

La plupart des organisations souvent effectuent des évaluations contre un certain nombre de schémas de base de données Oracle. Ils utiliserez le taux de conversion totale et le temps de conversion manuelle estimative totale de comparer et de prioriser le schéma de base de données Oracle pour la migration.

Conversion de schéma de base de données

SSMA vous donne beaucoup d'options pour la conversion de schéma. Par exemple, vous pouvez modifier de mappage de type de données. SSMA fournit le mappage de type de données par défaut entre Oracle et SQL Server. Cependant, vous pouvez personnaliser le mappage de type de données pour une table spécifique, pour toutes les tables, pour un objet spécifique (tel qu'une fonction ou une procédure stockée) ou pour un usage différent (comme le type de données dans la colonne, de type de données de variable ou de type de données dans le paramètre d'entrée/sortie de votre procédure).

Le schéma de la base de données de la convertir en cliquant sur le bouton « Convertir Schema ». Puis vous pouvez accédez à l'objet de base de données différente et comparer l'objet de schéma original et l'objet converti (voir Figure 3)

La figure 3 vue de la Conversion de schéma.

Lorsqu'un objet contient une déclaration que SSMA est incapable de convertir automatiquement, l'outil ajouter une description de l'erreur migration, commenter la déclaration spécifique ou le remplacer par un type générique. Cette approche d'isolement vous permet de continuer avec la migration de la base de données et de résoudre le problème plus tard.

Vous pourrait également résoudre le problème et de modifier l'instruction directement à partir de SSMA. Par exemple, en Figure 3, il existe une fonction définie par l'utilisateur appelée "Mandat". Cette fonction retourne un type de données INTERVAL SQL Server ne supporte pas. Vous pouvez modifier le type de retour au numéro (voir Figure 4) et la fonction de reconvertir. Cela supprime l'erreur et convertit la valeur de retour à float(53).

La figure 4 vous pouvez modifier les déclarations en SSMA pour résoudre les incompatibilités.

Vous pouvez également modifier les déclarations converties. Par exemple, vous pouvez remplacer type de retour de « float(53) » par « int ». Notez que toute modification que vous effectuez avec SSMA est stockée localement. Les modifications que vous apportez aux déclarations de source ne sont pas appliquées pour le schéma de base de données Oracle que vous avez dans la production. De même, toute modification apportée à la cible instruction SQL Server ne sont pas immédiatement appliquée au serveur. Cela vous permet de continuer à raffiner et d'apporter les modifications nécessaires aux schéma converti sans influencer votre serveur cible.

Vous pouvez déployer schéma converti à la cible de SQL Server par clic droit le nom du schéma dans la fenêtre de l'Explorateur de métadonnées pour le serveur SQL. Vous pouvez également générer un script pour créer les informations de schéma complet, dont vous pouvez ensuite déployer sur votre serveur cible (voir Figure 5).

La figure 5 déploiement converti le schéma pour SQL Server.

Migration de données

Après la création du schéma de base de données dans la cible de SQL Server, vous pouvez utiliser SSMA pour migrer des données Oracle. SSMA n'est pas la seule option pour la migration de données, cependant. Vous pouvez également utiliser SQL Server Integration Services (SSIS). Cependant, migration de données avec SSMA vous permet d'utiliser le même type de cartographie pour la conversion de schéma. Il gère également les problèmes de migration de données commun lors de la migration d'Oracle vers SQL Server.

Par exemple, Oracle a un plus large éventail de types pris en charge date que SQL Server. Par défaut, SSMA déclenche l'erreur de migration de données lorsqu'il trouve un tel cas. Vous pouvez avoir SSMA convertir automatiquement les valeurs hors-de-gamme date avec NULL ou la date plus proche de que SQL Server peut prendre en charge. Vous pouvez modifier ce paramètre via les outils | Paramètre de projet | Général | Migration de données (voir Figure 6).

La figure 6 il existe des options pour gérer les erreurs de migration des données.

Après avoir terminé la migration des données, les SSMA afficher un rapport avec le nombre de lignes migré, le taux de réussite et le temps pris pour migrer chaque table (voir Figure 7).

La figure 7 SSMA vous donnera un rapport complet de migration des données.

Tests de Migration de la base de données

Après que vous avez migré avec succès votre base de données, la prochaine étape est la validation. Lors de la migration d'Oracle et Sybase, SSMA vous permet de comparer la base de données de la source et la base de données migrée. Vous pouvez définir une série de cas de tests ; SSMA exécute ensuite les cas de tests sur la source et de la base de données cible. Il comparera les résultats, ainsi que toute modification les cas de test sur les tables sous-jacentes.

Pour définir un cas de test, sélectionnez nouveaux cas de Test dans le menu de testeur. Un assistant de Test Case sera vous guiderai dans le processus de création d'un cas de test. Vous pouvez également sélectionner des objets de base de données spécifique à tester. Par exemple, il y a une procédure appelée ADD_EMPLOYEE. Cette procédure insère un nouvel enregistrement dans la table employee basée sur la valeur du paramètre d'entrée. Vous pouvez définir des paramètres d'entrée spécifiques à utiliser dans le test via l'onglet valeurs appeler (voir Figure 8). Vous pouvez définir les valeurs d'appel autant que vous le souhaitez.

La figure 8 spécification appellent les valeurs dans l'Assistant de scénario de Test.

En comparant le test objet exécution, plus de SSMA peut également tester des changements à la table sous-jacente. Par exemple, lors de la procédure stockée à l'exécution de la ADD_EMPLOYEE, SQL Server sera insérer une ligne supplémentaire dans la table EMPLOYEES. SSMA compare les lignes modifiées dans la table touchée entre la source et la cible. Si nécessaire, vous pouvez également spécifier le niveau de granularité pour la comparaison (voir Figure 9).

La figure 9 tables sous-jacentes de spécification pour comparaison.

La dernière étape dans la définition de l'affaire de test est des paramètres supplémentaires. Un paramètre important est plus de savoir faire reculer toute modification apportée à la table à la suite de tests (voir Figure 10). Dans mon exemple, lorsque le ADD_EMPLOYEE de l'exécution d'une procédure stockée un nouvel enregistrement est ajouté à la base de données Oracle de source et de la base de données SQL Server de cible. Si vous sélectionnez l'option de restauration de données, SSMA supprimera la valeur insérée après que l'essai est terminé.

La figure 10 définition test case paramètres.

Après avoir défini le cas de test, vous pouvez l'exécuter autant de fois que nécessaire. Pour chaque course, vous recevrez un rapport de résultat de test qui compare les résultats (voir Figure 11).

La figure 11 SSMA vous donnera un rapport de résultat de l'essai complet.

SSMA vous offre une fonctionnalité très riche d'automatiser la migration de la base de données. Vous pouvez utiliser l'outil pour évaluer la complexité de la base de données vous envisagez de migrer, convertir le schéma de la base de données, de résoudre des questions de migration de la base de données communes, de migrer les données de la base de données de la source et de valider la base de données migrée.

Cet outil est conçu pour la migration vers SQL Server, mais il prend également en charge directe migration vers SQL d'Azur (à partir de bases de données MySQL, Sybase et Access). Lors de la migration vers SQL d'azur, SSMA tient compte des exigences pour la plateforme SQL d'Azur. Par exemple, SQL azur exige que ses tableaux ont un index cluster. Si la table source n'inclut pas une clé primaire ou l'index cluster, l'outil peut automatiquement ajouter une colonne ROWID et définir l'index cluster sur la colonne pendant la conversion.

Vous pouvez Télécharger SSMA sur le site Web de Microsoft SQL Server. Non seulement l'outil gratuit, mais vous pouvez également obtenir l'appui d'e-mail gratuit de soutien et Service à la clientèle Microsoft. Pour plus d'informations sur SSMA, visitez le blog de l'équipe SSMA pour une démonstration vidéo et articles HOWTO, ainsi que des conseils pour résoudre les problèmes courants de migration.

Welly Leeest responsable de programme senior avec l'équipe de l'Assistant de Migration SQL Server, et le propriétaire de la fonctionnalité de l'outil de migration de la base de données Oracle et MySQL à SQL Server. Avant de rejoindre Microsoft en 2007, il a travaillé comme consultant sur le développement de solutions de base de données et de la mise en œuvre d'enterprise application depuis plus de 10 ans.

Contenu associé

• SQL Server : Planification de votre migration vers SQL Server 2008 R2
• SQL Server : Protéger les données à tout prix
• Travailler ensemble : SQL Server 2008 R2 Reporting Services Integration dans SharePoint 2010