Salut Comme promis dans un article
précédent sur la redéfinition basée sur l'édition - c'est la deuxième partie.
Alors avec quoi travaillons-nous? Notre serveur de production principal est Oracle 12C, Enterprise Edition. Et, ce qui est important à noter, plusieurs dizaines d'applications s'exécutent simultanément dessus. Pourquoi nous concentrons-nous là-dessus? La technologie est relativement nouvelle, elle n'est pas très bien rodée. Et il serait illogique d'y transférer immédiatement certains systèmes critiques. Par conséquent, nous avons décidé par nous-mêmes que nous passerons lentement des systèmes moins critiques à des systèmes plus critiques. En conséquence, le prochain problème que nous devions comprendre: comment travailler avec la technologie EBR et comment organiser l'intégration dans la situation où nous avons une version versionnée et l'autre non. Dans la 12e version d'Oracle, il s'est avéré que vous pouvez créer des objets non versionnés, des packages non versionnés, des représentations non versionnées dans un schéma versionné pour organiser l'intégration même.
Bien sûr, nous pouvons créer une API non versionnée et la donner au schéma non version pour utilisation. Mais que se passe-t-il si cette API non-version (ou une partie de celle-ci) est utilisée à l'intérieur de notre application et que nous devons la version à l'intérieur de nous-mêmes, et donner des objets non-version à côté? Ce n'est que le prochain problème avec lequel nous avons lutté. Nous avons utilisé l'API à plusieurs reprises, mais, comme vous vous en souvenez, il existe une limitation selon laquelle les objets versionnés ne peuvent pas être utilisés sans version. Naturellement, à condition que plusieurs applications s'exécutent sur le serveur, il était nécessaire de comprendre comment nous pourrions basculer une application vers la nouvelle édition et conserver la possibilité d'utiliser l'API de ce schéma avec d'autres schémas de base de données.
Il existe plusieurs options pour installer Edition:
- définissez la valeur d'édition par défaut sur toute la base de données
- installer l'environnement, à nouveau sur toute la base de données.
Ces options sont immédiatement rejetées car au moins certaines applications ne passeront pas à l'utilisation d'EBR.
Il est également possible de créer un service pour déterminer la version, ou pour déterminer la version lors de la connexion de l'application au circuit. C'est pratique si nous nous connectons à la base de données via une application tierce.
Et si nous avons besoin de travaux pour fonctionner dans les délais et travailler dans une édition spécifique? En conséquence, il existe une autre option pour passer à une nouvelle version - c'est d'
orienter la session en cours vers une version spécifique .
En fait, nous avons choisi cela pour nous-mêmes comme solution. Vous pouvez attacher un déclencheur après la connexion au schéma versionné, qui indiquera que la session en cours dans ce schéma fonctionnera dans cette édition.
Revenons à l'intégration et à la duplication de la logique. Il y a des tâches: je veux versionner une sorte de logique d'application à l'intérieur de mon schéma, et je dois également l'exposer à un utilisateur non-version. Au début, il semblait que cela ne pouvait pas être implémenté, mais après avoir approfondi la question, nous avons considéré que le package dbms_sql habituel, qui en principe vise à effectuer une sorte de requêtes dynamiques, peut aider à résoudre ce problème. Comment? Très simple - lorsque vous traitez une requête ou appelez un bloc anonyme, nous pouvons jeter le nom de la condition en paramètre, indiquant ainsi la version dans laquelle ce code sera analysé et exécuté. Si nous devons utiliser une procédure à l'intérieur de nous-mêmes et donner la même procédure à un schéma tiers, nous l'enveloppons simplement avec un appel dans la procédure dbms_sql.parse, créant ainsi un wrapper qui peut être placé dans un objet non-version, et - s'il vous plaît, notre objet versionné peut utiliser utilisateur non versionné.
À quoi faites-vous face ici? Pour une raison quelconque, lors de la spécification d'une condition, les paramètres de sortie ne sont pas émis dans les procédures. Pourquoi - ce n'est pas clair, mais dans les régimes dans lesquels nous avons travaillé, cela n'est pas souvent utilisé. Peut-être que nous allons refaire la logique en quelque sorte, ou nous chercherons d'autres solutions.
Les problèmes suivants sont des bogues ou des fonctionnalités de l'EBR que nous avons rencontrés. Le premier est un problème avec les types construits et les fonctions en pipeline. Qu'est-ce que Pipeline a à voir avec ça? Outre le fait que nous avons vraiment certains algorithmes qui fonctionnent sur la base de fonctions pipelinées, Pipeline est une certaine solution pour mettre la vue versionnée de côté. Nous avons hérité des vues, qui contiennent une logique assez compliquée pour le prétraitement des données, et des schémas tiers utilisent également ces vues. En conséquence, il était nécessaire de comprendre comment définir nos vues de gestion des versions sur un circuit consommateur de données non version, à condition que l'ensemble de colonnes de sortie ne change pas. En tant que solution de ce type, il était clair que vous pouviez envelopper toutes ces vues avec dbms_sql dans la fonction Pipeline et les mettre dans la vue finale pour le consommateur, oui, cela demande beaucoup de ressources pour le serveur, mais cela ne nécessiterait aucune modification de la part du système récepteur.
Ainsi, en revenant à l'utilisation des fonctions de pipeline, il s'est avéré que si le type en cours de construction n'est pas créé dans le package de version qui est créé et qu'il est construit pour la première fois, le package ne compile tout simplement pas et se désagrège. Immédiatement une solution n'est pas venue, est allé chercher ce qui a été suggéré par les autres programmeurs? Quelqu'un a dit qu'il était nécessaire de créer ce type dans la version zéro du package ou de créer un package avec le type correspondant dans la version zéro de la base de données. Il n'était pas clair pourquoi faire cela. Ils ont trouvé une solution pour que ces types, qui sont implicitement créés lors de la compilation du package, puissent simplement être placés dans un type distinct en tant qu'objet de base de données. Ainsi, le problème avec les fonctions de convoyeur est résolu.
La prochaine fonctionnalité sur laquelle nous sommes tombés est le comportement non standard des vues versionnées.
Rappelez-vous, j'ai parlé du fait que les objets sont hérités et mis à jour? Donc, il s'est avéré que si vous et moi avons créé une vue versionnée sur une édition conditionnellement nulle, à la cinquième édition, nous avons remarqué que nous avions des inexactitudes dans les commentaires. Par exemple, je remarque par moi-même que dans un commentaire sur une colonne, je peux échanger deux lettres par endroits. Ne laissez pas une telle imperfection!
Ainsi, la commande de commentaires habituelle conduit au fait que notre vue versionnée est mise à jour dans la version actuelle. Pour cette raison, tous les packages dépendants s'effondrent, et comment y faire face? Pour ce faire, ils ont écrit un certain script qui, lors de la création d'une nouvelle édition, mettra à jour la vue des versions à chaque sortie de la prochaine version. Cela n'entraîne pas une charge importante sur le dictionnaire de base de données, mais si nécessaire, apportez des corrections mineures ou, par exemple, émettez de nouvelles subventions, nous n'avons pas besoin de créer une nouvelle édition
Eh bien, le dernier bug ou une telle fonctionnalité ... On ne sait pas pourquoi, lors de la modification de la valeur non nulle, les restrictions sur la colonne des vues versionnées se sont effondrées. Autrement dit, dès que nous disons que notre colonne de la table de base ne doit plus avoir de restrictions nulles, la vue s'effondre même lors de l'utilisation de la redifinition dbms. Nous ne pouvions pas vaincre cette chose en aucune façon, peut-être que les lecteurs l'ont rencontré, il sera intéressant de savoir si une solution a été trouvée.
Que voudrais-je dire en conclusion? La redéfinition basée sur l'édition est une technologie efficace pour une réelle opportunité de lancer une version ou un correctif en ligne, en mode utilisateur. Nous avons touché, senti, réalisé que l'organisation de l'intégration sur un serveur, lorsque tous les schémas ne se déplaceront pas pour utiliser cette technologie, est réelle, sans oublier que le schéma versionné peut fonctionner sur un serveur dédié ou sur une base de données de conteneurs distincte.
Et en tant qu'application, et réponse à la question clé, "est-ce possible en production?" ... Nous espérons que la redéfinition basée sur l'édition se déplacera tôt ou tard dans tous nos projets, et ce sera peut-être le dernier arrêt de nos applications et garantissons un calme sommeil du développeur responsable de l'installation de la nouvelle version.
En fait, c'est tout. Merci de votre attention.