Migration d'oracle vers MySQL

Transcription

2 Introduction L'objectif de ce livre blanc est de décrire les facteurs qui influent la migration de base de données et d'applications d' vers. Les facteurs de coûts et les risques seront détaillées, ainsi que des outils et des méthodologies pour aider à atteindre une conversion de qualité supérieure. Il est très vrai que la base de données Sun peut réduire considérablement le Coût total de possession (TCO) de la base de données pour une entreprise en réduisant les coûts de licence, matériel et administration. Le plus grand risque dans le déplacement de la plate-forme est le risque et la complexité de la migration de la logique métier d', en particulier lorsque les applications existantes font un usage important de procédures PL / SQL, les triggers, les forfaits et les instructions SQL spécifiques à. La migration d' vers peut être gênant, fastidieux et coûteux. Cependant, les méthodes et outils éprouvés peuvent réduire le coût et le temps requis et peuvent atténuer considérablement le risque. Avec l'aide des de produits de migration SQLWays, la migration peut être évaluée, planifiée et correctement automatisée. Avec l'utilisation appropriée des outils automatisés et un processus de gestion de projet solide en place, les entreprises peuvent engager des économies de plus de 70% par rapport aux techniques traditionnelles de migration manuelle. Couplé avec les économies réalisées grâce à la mise en œuvre, la migration automatisée devient une alternative très attrayante. Défis La base de données offre des fonctionnalités très avancées pour développer la logique de l'application qui se trouve entièrement à l'intérieur de la base de données en utilisant PL / SQL procédures stockées, des fonctions, des packages et les triggers. PL / SQL est une extension facile à utiliser et puissante pour SQL qui est fortement recommandée par pour des raisons de performances. Dans la plupart des applications, l'utilisation de PL / SQL conduit naturellement à une significative grande nombre de procédures, packages et des déclencheurs., bien qu'ayant certaines fonctionnalités similaires, ne pas faire usage de PL / SQL. Outre la syntaxe spécifique, PL / SQL offre de nombreuses fonctionnalités non compatibles ANSI, y compris les caractéristiques qui ne se retrouvent dans. Ces caractéristiques d' comprennent: Packages - shared package variables, built-in packages %TYPE, %ROWTYPE, exceptions Fonctionnalités orientées objet: les types d'objets, fonctions et collections Business Intelligence et XML caractéristiques etc Copyright Ispirer Systems Ltd. Tous Droits Réservés. 2

3 Une migration d' à peut être un processus très difficile, en particulier si les fonctionnalités spécifiques à sont utilisés, tels que décrites ci-dessus. Cependant, une telle migration pourrait être relativement facile et sans risque. Tel serait le cas si la base de données cible contient une quantité relativement faible de tables et de la logique métier simple. Depuis que les coûts et les risques peuvent se varier d'un projet à l'autre, il est important de réaliser une évaluation préliminaire. Évaluation Le but de cette évaluation est de définir la portée, la faisabilité, le coût et le risque associés à la migration d'une base de données d' à une application de base de données basé sur. Évaluation de base de données Tout d'abord, vous devez définir les types d'objets de base de données et combien d'entre eux vous aurez besoin de migrer. Les objets sont des éléments tels que les suivants: Tables Vues Procédures Fonctions Packages Triggers Séquences, synonymes etc. Si vous avez besoin de convertir code PL / SQL (procédures, packages, fonctions et les triggers) ou vues / requêtes contenant la syntaxe SQL spécifique d', vous devez étudier quelles fonctionnalités sont utilisées et définir le nombre de leurs occurrences. Des exemples d'éléments qui doivent être pris en compte sont: Non-ANSI compatible SQL fonctions, operators et déclarations Results sets Cursor loops Exceptions Temp tables Types d'objet et fonctions Collections Copyright Ispirer Systems Ltd. Tous Droits Réservés. 3

4 SQL Dynamique Built-in packages OLAP fonctions XML fonctions etc. Une fois que vous avez terminé l'examen, il est préférable de choisir des équivalents ou des solutions pour remplacer des fonctionnalités spécifiques. Vous pouvez trouver des solutions typiques dans les chapitres suivants. Évaluation de l'application Outre schéma et la conversion de la logique métier côté serveur, vous pouvez aussi avoir besoin de modifier les instructions SQL dans l'application. Il est essentiel d'évaluer combien de ce travail devra être fait pour compléter la migration. Pour commencer, vous devez vérifier ce que l'api base de données est utilisée dans vos applications pour accéder à la base de données. Il est important de noter combien de fichiers source de l'application contiennet le code spécifique d' et donc il doit être modifié pour fonctionner avec. La plupart des applications utilisent une API standard comme ODBC, JDBC, et ADO.NET pour accéder à, mais certaines applications peuvent utiliser une API native comme OCI ou Pro * C / C + +. La collecte de toutes ces informations est impératif. Même si vous utilisez une API standard, comme l'utilisation de pilotes ODBC / JDBC, des changements importants peuvent être apportées aux instructions SQL existantes. Par exemple les fonctions de décoder ou héritage laissé de syntaxe de jointure externe (*) devra être modifié. Il est recommandé d'estimer le nombre de requêtes SQL natives. Si la demande arrive à utiliser une API native comme OCI, vous aurez besoin d'une refonte complète du code d'accès de base de données à utiliser l'api et ODBC. Évaluation d'outils Il est important de comprendre combien il est fait usage des fonctionnalités de base de données spécifiques. Quelle est la meilleure évaluation de «l'utilisation de fonction» est effectuée? Commencez d'abord par le calcul du nombre de tables, procédures, des vues, etc, comme dans le tableau ci-dessous. Pour une analyse plus détaillée, vous pouvez utiliser le produit SQLWays de Ispirer de recueillir des statistiques complètes. Voici l'échantillon d'une évaluation: Base de Données Nombre Tables 350 Vues 280 Procédures 420 Fonctions 135 Triggers 50 Packages 10 Détails de BD BLOBs 37 Outer joins 155 Ref cursors 89 Excéptions 450 Temp tables 34 Copyright Ispirer Systems Ltd. Tous Droits Réservés. 4

5 Application Java/JDBC 590 de fichiers Outer joins 190 SQL functions 356 Result sets 47 Approche de la migration Conversion Automatisée Sur la base des résultats de l'évaluation, vous pouvez élaborer un plan de migration. Si vous avez des dizaines de procédures, vous pourriez envisager une conversion manuelle, mais si des centaines ou des milliers de procédures doivent être migré, il est préférable d'examiner les outils de migration automatisés sur le marché. SQLWays fournit une telle fonctionnalité. Coût et Risque Le coût et le risque associés au projet de conversion dépendent de l'ampleur de la migration. Il est important de noter que le coût et les risques sont également touchés par la diversité et la fréquence des fonctionnalités d' en usage dans la base de données et d'application. D'autres fonctionnalités d' en cours d'utilisation, le plus complexe et plus coûteuse est la conversion. En outre, plus les fonctionnalités d' sont en cours d'utilisation, les outils plus automatisés pourraient aider à atteindre le succès. Coût de la Migration de Données et DDL La migration des objets de données et DDL (Schéma) est effectuée d'habitude de manière facile, car il y a pleins d'outils dans le marché qui peuvent vous aider à réaliser ce type de la migration. La migration typique de Données et DDL implique la conversion de Types de Données Contraintes (clés primaires et étrangères, contraintes unique, NULL, défaut etc) Transfert de Données Indexes Bien qu'il existe des différences dans la syntaxe d' et des instructions DDL SQL, les deux ont des types de données similaires (caractère, nombre, date, heure, LOB) ce qui vous permet de préciser les contraintes d'intégrité similaires. L'échantillon de l'éstimation de la Migration de DDL/Données: Base de Données Tables <100 tables LOBs 10 colonnes Max rangées en table <10M Max taille de tables <300 Mb Processus de Migration Evaluation configuration Transfert Automatisé Test, changement de configuration, itération suivante Durée Totale 2-8 h 4-16 h 2-4 h 4-12 h h Copyright Ispirer Systems Ltd. Tous Droits Réservés. 5

6 Outils Gratuit, soit moins de $500 Grâce à l'automatisation, le coût de la migration DDL et des données n'est pas directement proportionnel au nombre de tables et de la taille des données. Par exemple, le coût de la migration pour les 100 et 300 tables peut être similaire dans le coût, si les tableaux ont une structure et la taille des données similaires. Lorsque le nombre de tables et leur taille s'augmentent, vous devrez peut-être passer plus de temps à configurer correctement la base de données, au transfert de données d'un morceau, et de se concentrer sur des choses comme la performance de création d'index. Atténuation des risques pour la migration typique de DDL et des données La migration typique DDL / données impose un risque relativement faible. En utilisant SQLWays, il est possible d'exécuter le transfert de base de données complète en mode d'évaluation, d'examiner les données et exécuter des applications liées à la nouvelle base de données : C'est workflow général: 1. Exécuter le transfert de base de données complète en mode d'évaluation 2. Vérifiez les erreurs de transfert, comparer les structures des tables, le nombre de lignes dans d' et 3. Examiner et tester des données aux tableaux représentant et en utilisant l'outil SQL d' SQL * Plus, Query Browser, ou l'utilitaire de ligne de commande mysql 4. Exécuter et tester l'application cible connecté à Défis de la Migration de Données Même si, en général, la migration de données / DDL est relativement facile par rapport à la conversion de la logique métier, il y a certaines conditions qui augmentent généralement la complexité de la migration de données / DDL: De grands volumes de données Si vous avez besoin de migrer de grands volumes de données, vous devrez peut-être pocéder plus d'efforts pour configurer les serveurs. Une grande quantité de données peut influer sur le processus de migration, en particulier en termes de temps qu'il faut pour terminer la migration. Afin d'atténuer le temps nécessaire pour terminer la migration, vous pouvez exécuter la migration d'une manière simultanée. Cela augmente la complexité de la migration. En outre, le transfert d'un grand volume de données peut compliquer la gestion des erreurs, comme vous pouvez maintenant se permettre de ré-exécuter une migration complète si quelques tables échouent. Le projet pourrait bénéficier d'outils qui permettent de vrac options d'insertion, comme des outils qui émettent un commit après chaque rangée qui n'est plus une option viable. Temps d'arrêt minimal Dans certains environnements critiques, vous devez vous assurer que les temps d'arrêt est maintenu à un minimum. Pour répondre à ces exigences, vous devez bien concevoir le processus de migration de faire des choses telles que le transfert des données de s'exécuter simultanément, ou transférer des tables statiques de la fenêtre de temps d'arrêt. Parfois, les outils de réplication doivent être utilisés pour réduire les temps d'arrêt. Exigences de performance rigoureuses Copyright Ispirer Systems Ltd. Tous Droits Réservés. 6

7 Certains environnements ont des exigences très strictes en matière de performance pour les applications. Lors de la migration de, il est impératif que la performance existante est maintenue ou améliorée. Cela vous oblige à passer plus de temps sur la conception de base de données et l'optimisation, ainsi que l'exécution des migrations tests afin de tester les performances de suivi de migration. Atténuation des risques pour contester DDL et de migration de données Le défis de la migrations de données ne peut être complété par un simple double-clic. Une migration Proof-of-Concept doit être exécuté afin de s'assurer que les exigences peuvent être satisfaites. Le plus souvent, le processus de migration suivante est recommandée pour les projets complexes de migration de données: Proof-of-Concept migration pour vérifier la faisabilité des exigences Migration de test pour émuler complètement migration de production et exécuter des tests complets La migration de la production Coût de conversion de la logique métier Si votre base de données contient une douzaine de procédures et les triggers, il est facile de réécrire manuellement à la syntaxe SP. Mais si vous avez des milliers de procédures et les triggers, conversion manuelle est assez cher. Vous devez considérer comment un outil automatisé peut vous aider. Le coût de la conversion manuelle est directement proportionnelle au nombre de lignes de code que vous devez convertir. D'autre part, les outils automatisés peuvent limiter les coûts, et de faire la migration de même un million de lignes de code très raisonnable en coût et l'effort. Selon les lignes de code être convertis, la conversion automatique de la logique métier en utilisant un outil comme SQLWays peut coûter 7-10 fois moins que la conversion manuelle. La diversité et la fréquence des fonctionnalités spécifiques à définit la complexité des affaires migration logique et le niveau d'automatisation fourni par outils. Pour une automatisation efficace, nos experts estiment qu'un outil de migration comme SQLWays doit être capable de convertir plus de 95% de la logique métier. Copyright Ispirer Systems Ltd. Tous Droits Réservés. 7

8 Un échantillon d'estimation de la migration de logique métier côté serveur se présente comme suit: Base de Données Procédures Stockées 1000 Triggers 300 Fonctions 250 Packages 10 (50 procédure par package) Conversion manuelle Coût du travail conversion automatique Évaluation, discussion des solutions conversion itérative, l'analyse Test 5,000 h (~30 mois-homme) $50,000-$250,000 (selon le pays) h h h Durée totale h Coût d'outils moins que $5,000-$10,000 Si vous comparez la migration de DDL / données et de logique métier, vous pouvez voir que celui-ci peut faire jusqu'à 95% du coût total du projet. Cela est particulièrement vrai pour les grands projets de migration d' vers. Atténuer les risques pour la Conversion de la Logique Métier S'il ya beaucoup de lignes de code pour convertir, et une grande diversité de fonctionnalités de base de données d' sont utilisés, la conversion peut imposer des risques importants, de sorte que vous devez prendre plusieurs mesures importantes pour atténuer. Expérience Le personnel responsable du projet de migration doit avoir et les compétences administratives et de l'expérience développeur à la fois pour les bases de données et. Ils doivent comprendre clairement la portée, les défis, les tâches et les étapes à mettre en œuvre avec succès la migration. Evaluation globale Au stade initial, vous devez effectuer une évaluation complète des bases de données que vous souhaitez migrer. En conséquence, vous saurez ce que la fonctionnalité spécifique dont vous avez besoin pour convertir, quelles sont les solutions que vous allez utiliser pour remplacer les fonctionnalités d' conformes à non-ansi. Vous devez déterminer si il ya une solution pour chaque fonction en cours d'utilisation. Certaines fonctionnalités d' ne sont pas faciles à correspondre à un équivalent similaire dans, vous devrez donc de repenser certaines fonctionnalités. Proof-of-Concept pour le code complet de base Les outils automatisés comme SQLWays permettent d'exécuter facilement des conversions sur la base de code complète au début de l'évaluation de la migration. Nous vous suggérons de faire cela dans le cadre d'une migration complexe, car cela aidera à exposer les goulets d'étranglement potentiels et de mieux clarifier "le pour cent de l'automatisation" ou facteur de réussite de l'outil de migration fourni. Copyright Ispirer Systems Ltd. Tous Droits Réservés. 8

9 Plus important encore, il vous rendra confiant que la conversion du lourd code PL / SQL est réalisable à faible coût. Utilisez migration automatisée autant que possible En plus de son coût élevé, la migration manuelle réduit la visibilité des goulots d'étranglement dans les premiers stades, ce qui peut entraîner la nécessité de repenser la migration. Cela augmente encore l'effort et le coût de la migration. Par comparaison, les outils automatisés permettent la conversion devant être exécuté à plusieurs reprises pour un faible coût, mais avec des niveaux élevés de rétroaction. Cela permet de migrations hautement raffinées et à l'écoute sans pénalités significatives de coûts. En général, la conversion manuelle est une tâche fastidieuse qui conduit à une forte probabilité d'erreur humaine. Très souvent, les développeurs peuvent souvent produire des résultats différents de conversion pour un code similaire. En conséquence, ce qui conduit à de grands problèmes de coût et de temps pour les tests. Test précoce Les tests à des stades précoces doivent également servir à réduire le risque du projet. Vous pouvez exécuter des tests unitaires, ou d'effectuer des revues de code, même si les tests fonctionnels au niveau de l'application ne sont pas encore possible. Vous pouvez utiliser les fonctionnalités d'outils automatisés qui peuvent générer des cas de test pour invoquer les procédures et fonctions avec des valeurs spécifiques et comparer les résultats. Veuillez noter que cela ne peut pas remplacer les tests fonctionnels au niveau de l'application, mais il peut aider à découvrir de nombreux problèmes potentiels. Conversion d'application Outre la conversion de la logique métier côté serveur, dans la plupart des cas, vous devez modifier vos applications pour travailler avec. Il peut y avoir des instructions SQL non-ansi dans Java ou des applications PowerBuilder, c'est la syntaxe qui diffère de la syntaxe SQL et doit être modifiée. Plus précisément, les fonctions syntaxiques les plus typiques qui ont besoin d'attention pour les conversions d' à sont jointure externe gauche (+) des scripts de syntaxe. Des fonctions comme DECODE, NVL et SYSDATE tous auront besoin d'attention. Vous ne pouvez pas remplacer des noms de fonctions à l'aide de Rechercher / Remplacer dans ces situations. Dans de nombreux cas, les fonctions peuvent avoir la syntaxe de paramètre différent, ou exiger des modifications d'instructions SQL telles que la jointure externe gauche. En outre, les remplacements de chaînes simples peuvent changer le texte dans des endroits inattendus, comme des chaînes de caractères, ou des instructions en langage Java. La meilleure approche consiste à utiliser un outil comme SQLWays qui est capable de modifier automatiquement le code d'application et la conversion des instructions SQL pour syntaxe correcte. Ces outils peuvent identifier correctement les instructions SQL dans le code, effectuer la conversion, et générer des rapports sur tous les changements, ce qui simplifie grandement la tâche de conversion de l'application. Copyright Ispirer Systems Ltd. Tous Droits Réservés. 9

10 Planification - Etapes de migration Une bonne planification est très importante pour une migration réussie, et les étapes de migration habituelles sont les suivantes: Evaluation L'évaluation (qui est décrit précédemment dans ce document) est destinée à analyser les bases de données et applications dont vous avez besoin de migrer, définir la portée de la migration, et de documenter toute fonctionnalité spécifique d' qui devra être mis en correspondance avec. Sur la base des informations recueillies par l'évaluation, vous pouvez définir quelles approches doivent être utilisées (conversion manuelle ou automatique) et le coût et les risques qui sont associés à la migration. Conversion complète à un stade précoce Proof-of-Concept Supposons que vous avez une base de données avec procédures. Vous pouvez exécuter SQLWays de convertir la totalité de la base de code lors des étapes preuve de concept. Ceci est suggéré, même si vous décidez de tester et de déployer module par module. Très tôt dans le processus (lorsque les outils d'automatisation sont utilisés), la rétroaction et la visibilité sont disponibles en ce qui concerne la migration. Ceci est en contraste direct à une migration manuelle où de nombreuses heures de travail peuvent souvent être dédié aux tâches avant de réaliser le processus de migration a rencontré un écueil et doit revenir en arrière. Vous pouvez appliquer une approche de migration plus intégrée et uniforme à l'aide de solutions automatisées comme SQLWays. Très souvent, les tâches de migration manuelle sont répartis entre différentes personnes au sein d'une organisation, des procédures différentes, les approches sont souvent utilisées pour la même syntaxe. En conséquence, plus les résultats d'une migration sont uniformes et intégrés, plus il sera facile de tester et de modifier. Idéalement, vous avez besoin pour atteindre près de 100% sans erreur la création d'objets dans à un stade précoce. Cela signifie que toutes les tables, les fonctions, les procédures, les trigger sont créés avec succès dans. Puisque 100% de conversion est très difficile à atteindre pour toutes les bases de données dans la version actuelle de n'importe quel outil de conversion, l'équipe de Ispirer offre la personnalisation gratuite (1-2 jours par fix) pour atteindre près de 100% d'automatisation lors de l'évaluation initiale. Run-Time, Test logique et de performance La migration est souvent déployée module par module. Après avoir converti la logique métier côté serveur, avant même que les applications sont converties et les tests de niveau de l'application est possible, vous devriez tester la conversion de base de données. Vous pouvez sélectionner plusieurs représentant ou procédures les plus critiques et d'effectuer une revue de code. Bien sûr, vous ne pouvez pas trouver tous les problèmes examen du code, mais au début, il est très utile. Avec le code, vous pouvez examiner comment les solutions sont appliquées, et estimer la qualité de la conversion en général. Il est préférable de créer une liste de conversion de fonction dont vous voulez étudier en profondeur. Même si vous pouvez créer une procédure ou une fonction dans la base de données, cela ne signifie pas qu'il ne contient pas d'erreurs critiques. De nombreuses erreurs peuvent être rapidement découvertes par l'exécution des procédures. Un moyen simple et efficace pour tester les procédures est de générer des cas de test. Copyright Ispirer Systems Ltd. Tous Droits Réservés. 1 0

11 SQLWays peut générer une série d'appels de procédure avec les différents paramètres d'entrée. En examinant le code, SQLWays peut savoir quelles valeurs, de la ficelle et des constantes jour, les conditions de contrôle de flux sont utilisés, et de générer les cas de test raisonnables dans de nombreuses situations. Pour effectuer une logique plus globale et les tests de performance, vous pouvez développer des scripts de test avec des données réelles, la mise en œuvre de divers scénarios. Si vous utilisez un logiciel d'assurance qualité automatisée pour votre base de données et applications, vous pouvez envisager de les mettre à jour pour fonctionner avec et d'assurer les essais de migration globale. Solutions de Conversion typique - Échantillons Bien que les tâches et les solutions de conversion varient d'un projet à l'autre, beaucoup d'entre eux sont typiques pour une migration. Remarque. Toutes les conversions décrites ci-dessous sont effectuées par SQLWays automatiquement. DDL et soutiennent la commande CREATE TABLE, mais il ya beaucoup de différences de syntaxe. Types de Données CREATE TABLE employees ( id NUMBER(5), name VARCHAR2(120), hire_date DATE, salary NUMBER(7), dept_id NUMBER(2) ); CREATE TABLE employees ( id INT, name VARCHAR(120), hire_date DATETIME, salary INT, dept_id TINYINT ); Mots Réservés et utilisent de différentes séries de mots réservés, de sorte que certains noms de colonnes doivent maintenant être cités dans les requêtes. SELECT product_id, limit FROM product_data; SELECT product_id, `limit` FROM product_data; Requêtes et Code PL / SQL Vous devez modifier les instructions SQL principalement à modifier la syntaxe de fonctions et expressions. PL / SQL doit être complètement transformée pour SQL syntaxe procédurale. Jointure OUTER prend en charge la syntaxe spécifique pour les jointures externes qui est largement utilisé dans les anciennes applications. Copyright Ispirer Systems Ltd. Tous Droits Réservés. 1 1

12 SELECT e.name, d.name FROM employees e, departments d WHERE e.dept_id = d.id(+); SELECT e.name, d.name FROM employees e LEFT OUTER JOIN departments d ON e.dept_id = d.id; Affecter une valeur de ID de colonne ne supporte pas les colonnes à incrémentation automatique (identité), et un objet de séquence est utilisée pour assigner de nouvelles valeurs d'identité à partir d'une application ou d'un déclencheur. Même si un objet de séquence unique peut être utilisé pour attribuer des valeurs pour plusieurs tables dans, dans de nombreux cas, il est utilisé pour une seule table et cette fonctionnalité peut être convertie en colonne à incrémentation automatique dans. Pour la conversion automatisée, SQLWays inspecte les requêtes SQL et des instructions INSERT dans les applications, les procédures et les triggers pour identifier l'affectation d'identification et les convertir en colonnes à incrémentation automatique dans. CREATE TABLE employees ( id NUMBER(5) PRIMARY KEY, name VARCHAR2(120), hire_date DATE, dept_id NUMBER(2) ); CREATE TRIGGER emp_id BEFORE INSERT ON employees FOR EACH ROW BEGIN SELECT emp_id_seq.nextval INTO :new.id FROM dual; CREATE TABLE employees ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(120), hire_date DATETIME, dept_id TINYINT ); -- Trigger is no required anymore Triggers multiples sur un seul événement Dans, pour la même table, vous pouvez définir plusieurs triggers pour le même événement (par exemple, plusieurs déclencheurs sur événement INSERT pour la table des employés). Ce n'est pas admissible dans, que vous devez mettre tout le code pour un événement dans le même déclencheur. Packages et des Variables partagées Dans, un package est un ensemble de procédures et de fonctions permettant le partage des variables connexes. La procédure et la fonction du Package doivent être converties en objets autonomes dans. Copyright Ispirer Systems Ltd. Tous Droits Réservés. 1 2

13 Les variables de package peuvent être modifiées dans une procédure de package. En outre, une autre procédure de package peut voir ou relayer la valeur actualisée. Pour remplacer cette fonctionnalité dans, vous pouvez utiliser des variables de session qui commencent par CREATE PACKAGE BODY emp_pack AS processed NUMBER DEFAULT 0; PROCEDURE new_employee AS BEGIN processed := processed + 1; PROCEDURE raise_salary AS BEGIN processed := processed + 1; CREATE PROCEDURE new_employee BEGIN IS NULL = + 1; CREATE PROCEDURE raise_salary BEGIN IS NULL = + 1; Résultats du scrutin établit Vous devez utiliser des variables de curseur (REF CURSOR) comme paramètre OUT pour retourner un ensemble de résultats à partir d'. Dans de nombreux cas, cela peut être converti à un simple SELECT dans. CREATE PROCEDURE get_salaries (d_id IN NUMBER, cur OUT SYS_REFCURSOR) AS BEGIN OPEN cur FOR SELECT id, name, salary FROM employees WHERE dept_id = d_id ORDER BY name; CREATE PROCEDURE get_salaries (IN d_id INT) BEGIN SELECT id, name, salary FROM employees WHERE dept_id = d_id ORDER BY name; %TYPE et% ROWTYPE définitions de type de données L'attribut % TYPE vous permet de définir les types de données pour les variables PL / SQL basées sur les types de colonnes du tableau. Dans, vous devez spécifier le type de données explicitement. Copyright Ispirer Systems Ltd. Tous Droits Réservés. 1 3

14 De la même manière, l'attribut %ROWTYPE vous permet de créer des variables d'enregistrement en fonction des lignes de la table. Dans, vous devez créer des variables autonomes et spécifier leurs types de données explicitement. v_emp_name employees.name%type; v_emp_rec employees%rowtype; v_emp_name VARCHAR(120) v_ emp_id INT v_ emp_name VARCHAR(120) v_ emp_hire_date DATETIME v_ emp_salary INT v_ emp_dept_id TINYINT Conversion SQL dans les applications Java Dans les applications Java, vous pouvez avoir besoin de modifier la syntaxe des instructions SQL. PreparedStatement ps = null; ResultSet rs = null; String sql = SELECT e.name, d.name + FROM employees e, departments d + WHERE e.dept_id = d.id(+) ; ps = conn.preparestatement(sql); rs = ps.executequery(); PreparedStatement ps = null; ResultSet rs = null; String sql = SELECT e.name, d.name + FROM employees e LEFT OUTER JOIN + departments d ON e.dept_id = d.id ; ps = conn.preparestatement(sql); rs = ps.executequery(); Conversion SQL dans les applications PowerBuilder Dans les applications PowerBuilder, vous pouvez aussi avoir besoin de changer la syntaxe des instructions SQL. datawindow(units=0 processing=0 print.orientation = 0 print.preview.buttons=no) table(column=(type=char(120) updatewhereclause=yes name=e_name dbname="employees.name" ) column=(type=char(120) updatewhereclause=yes name=d_name dbname="departments.name" ) retrieve="select e.name, d.name FROM employees e, departments d WHERE e.dept_id = d.id(+) ) datawindow(units=0 processing=0 print.orientation = 0 print.preview.buttons=no) table(column=(type=char(120) updatewhereclause=yes name=e_name dbname="employees.name" ) column=(type=char(120) updatewhereclause=yes name=d_name dbname="departments.name" ) retrieve=" SELECT e.name, d.name FROM employees e LEFT OUTER JOIN departments d ON e.dept_id = d.id ) Copyright Ispirer Systems Ltd. Tous Droits Réservés. 1 4

15 Solutions de contournement pour les fonctionnalités non prises en charge Il ya de nombreuses fonctionnalités d' PL / SQL qui ne sont pas actuellement prises en charge par SQL langage procédural. Si cette fonctionnalité est utilisée dans la base de données source, vous devez appliquer diverses solutions pour obtenir le même comportement dans. Voici quelques exemples précis: PL/SQL Collections Vous pouvez utiliser des tables temporaires et les opérations DML SQL (SELECT, INSERT, UPDATE, DELETE) pour remplacer cette fonctionnalité dans. RAISE_APPLICATION_ERROR Vous pouvez utiliser une UDF pour générer une erreur de procédures stockées SQL. UTL_FILE Built-in Package Vous pouvez utiliser une UDF pour travailler avec des fichiers à partir de procédures stockées SQL. Complex Business Logic Comme une solution générale, complexe PL / SQL logique métier peut être convertie en langage Java. Conclusion Automatiser la migration vers le modèle de licence fournit une valeur incroyable. En utilisant SQLWays de Ispirer sur le complexe de projets de migration d' vers augmente la qualité, vous permettant d'économiser temps et argent. Il ya beaucoup de choses à garder à l'esprit lors de la planification sur la logique métier de la migration et du contenu de la base de données pour une application existante. Une bonne planification, l'analyse et l'attention aux détails sont nécessaires pour chaque étape d'un projet de migration. Bien que la migration de base de données complexe d' vers qui implique la conversion de la logique métier est une tâche difficile, une approche appropriée et l'utilisation d'outils de migration vous permettra d'exécuter des migrations à un faible coût et avec minimum de risque. Le produit SQLWays de Ispirer et services de Ispirer peuvent fournir une grande quantité de valeur lorsqu'il s'agit de conversion complexe de logique métier. Copyright Ispirer Systems Ltd. Tous Droits Réservés. 1 5