Et quand bien même ils arrêtent sur la 12 ou 13 d'améliorer le composant, il restera en place un bon bout de temps (comme l'ancien scheduler de jobs par exemple). Ces deux point sont clairement annoncés dans Oracle GoldenGate Statement of Direction , page 4 :
Given the strategic nature of Oracle GoldenGate, Oracle Streams will continue to be supported, but will not be actively enhanced. Rather, the best elements of Oracle Streams will be evaluated for inclusion with Oracle GoldenGate.
Current customers depending on Oracle Streams will continue to be fully supported, and Oracle Streams customers should continue using the feature wherever it is deployed today.
Evidemment, les promesses n'engagent que ceux qui y croient comme on dit…
Scheduler
Merci du retour sur le produit que tu cites, il fut un candidat potentiel pour un projet passé et je suis heureux de ne pas l'avoir retenu (je crois qu'on a remplacé le scheduler par un humain dans cette histoire).
Concernant le scheduler d'Oracle, c'est sans doute différent de l'idée que tu en as. En résumé :
Il y a au moins deux IHM disponibles via des produits Oracle (gratuits).
C'est un scheduler dédié aux problématiques de base de données et qui permet - par exemple - de mettre en oeuvre une sorte de QoS, comme pour les réseaux, mais dans un contexte de base de données.
Pour l'IHM :
Elle est fournie nativement avec le produit OEM que je cite dans mon premier post.
Il y a aussi SQL Developper (à télécharger gratuitement chez Oracle). Pour les jobs, tu peux jeter un oeil à cette séquence, ça commence à la planche 13, et à partir de la planche 28 tu constateras que c'est assez éloigné d'un truc qui n'a pas d'interface graphique : on peut afficher les graphes de dépendance des tâches et ce genre de trucs.
Il y a aussi d'autres outils tiers, Toad par exemple - je n'en suis pas fana à titre perso mais c'est manifestement un produit qui a des utilisateurs fidèles.
Pour les fonctionnalités :
Le calendrier sur lequel s'appuie le cadencement "basique" offre des possibilités que l'on peut qualifier de "crontab aux stéroïdes". Si tu veux te faire une idée rapide, tu peux jeter un oeil au chapitre "Calendaring Syntax" de DBMS_SCHEDULER.
Un petit exemple, pour un job à déclencher le dernier lundi du mois sauf si ça tombe un jour férié : FREQ=MONTHLY; BYDAY=MON; EXCLUDE=JoursFeries; BYSETPOS=-1 (JoursFeries étant le nom d'un calendrier que l'on a défini par ailleurs avec la liste … des jours fériés).
Au passage : si quelqu'un connaît un scheduler (pas cher) qui sait faire facilement ce genre de choses et qui fonctionne à l'identique sur Windows, Linux et mainframe, je suis preneur d'informations et de liens vers la documentation technique du produit.
Le scheduler s'appuie sur trois concepts qui me semblent aussi correspondre à du "crontab on steroids" : les fenêtres de temps, les classes de job, et les plans de ressource (traduction personnelle "à la hache"). En synthèse, car c'est assez riche en protéines :
Une fenêtre de temps permet de définir des plages temporelles telles que "du vendredi 20H au samedi minuit" (voir chapitre "Windows" ici, et le doc de manière globale qui présente les concepts du scheduler).
Un plan de ressource permet de définir des quotas d'utilisation du moteur (x % de CPU, consommation de journaux, …), des règles de bascule vers un autre plan de ressource si une application dépasse les bornes (durée d'exécution max par exemple), et des règles d'association par défaut de toutes les sessions ouvertes sur la base (si connection depuis la machine nommée ABC, alors utiliser tel plan de ressource pour les requêtes de cette session). Pour en savoir plus, c'est ici.
Enfin, les classes de jobs font le lien entre les deux concepts mais mieux que je ne l'explique ici avec cette phrase lapidaire.
Il est ainsi possible de définir des choses telles que "mon job qui fait des trucs super lourds a le droit d'utiliser 80% du temps de calcul d'Oracle tous les vendredi de minuit à 2H du matin, s'il fonctionne encore après 2H alors il devra se limiter à 30% (sauf s'il est tout seul, auquel cas il pourra utiliser 100%)".
Cela permet donc de mettre en oeuvre une sorte de QoS, comme pour les réseaux, mais dans un autre contexte.
Je ne doute pas qu'il existe des schedulers (? $U ?) qui savent faire bien plus que celui qui est nativement intégré à Oracle. Ce dernier possède cependant, à mon sens, quelques caractéristiques qui peuvent avoir de la valeur selon l'environnement dans lequel on travaille, les contraintes, les besoins, …
Cela fait un composant en moins dans l'architecture logicielle et c'est toujours bon à prendre car c'est une adhérence en moins, des montées de version en moins, des test d'interopérabilité en moins, une hotline en moins, … = moins de complexité.
Un backup de la base = un ensemble cohérent avec les données, et le reste, dont les jobs, leur état, leurs journaux d'exécution (et aussi les files de messages par exemple).
On peut déployer en prod' sur Solaris, migrer un jour sur du Red Hat, tout en ayant installé Oracle sur les postes Windows XP des développeurs pour leurs tests (ça fonctionne très bien pour du dev), … Dans tous ces types de scénarios :
le scheduler reste le même, il exécute donc les mêmes jobs aux mêmes heures en se comportant de la même manière que ce soit en production, en homologation / recette, en développement, …,
les DBAs sont à l'aise pour travailler avec un développeur sur une problématique particulière car le socle technique est Oracle et non pas l'OS (les OS),
et réciproquement un développeur est à l'aise pour aider les DBAs quand il y a un souci en prod'.
Pas besoin d'avoir un login sur le système d'exploitation pour intervenir / superviser / analyser, donc réduction de la surface d'attaque (pas que Oracle soit 100% secure par défaut : c'est seulement que "pas de login sur l'OS" = bon à prendre).
Pour info : Oracle mange sa propre nourriture puisque le scheduler est mis en oeuvre pour des tâches d'administration système.
En résumé : "ça juste fonctionne" ("it just works"), c'est toujours installé, toujours disponible, et c'est la même chose partout où une base Oracle est déployée.
Perspectives
En complément, par rapport à mon premier post :
Il est possible d'envisager des cas d'usage un peu plus riches, avec par exemple plusieurs serveurs, des files de messages, et des jobs qui se déclenchent sur réception de tel ou tel message, puis mettent à jour des tables dont les données sont répliquées sur le serveur A, B ou C selon la nature de l'opération (A reçoit tout mais B ne reçoit que les insert / update) ou selon le contenu de la donnée elle-même (les factures payées sur un serveur, les autres sur un autre serveur), … On peut aussi mettre du XML dans le scénario, c'est pris en charge.
Ceci s'exécute dans un contexte 100% transactionnel, ce qui réduit considérablement les question à se poser pour les reprises après crash, coupure réseau, …
Ceci se sauvegarde et se restaure de la même manière de partout.
Ceci ne nécessite qu'un seul produit, un seul langage et ça fonctionne à l'identique sur de multiples systèmes d'exploitation.
Ceci nécessite aussi d'investir du temps pour connaître le produit et d'avoir des personnels compétents, on s'en doutait un peu.
Au final, cela peut représenter une "force de frappe" conséquente quand on commence à faire l'inventaire de tous les composants qu'il faut assembler, faire fonctionner de manière harmonieuse et maintenir si on souhaite (ou si on doit !) partir sur une approche "brique par brique" plutôt que "all in one".
Oracle n'est certainement pas une solution miracle mais le produit a de réelles qualités, sur un vaste périmètre, souvent méconnues, et qui prennent tout leur sens quand on considère l'architecture d'un système d'information, sa réalisation, sa qualité, sa maintenance, et son exécution. Libre à chacun de déterminer si les fonctionnalités du produit fournissent de la valeur (qualitatif : moins de code à écrire = moins de bug, moins de technos à assembler et maîtriser, portabilité, …) et si le coût (quantitatif) est compétitif avec d'autres solutions.
Cela influe évidemment sur l'intérêt et le coût d'une migration :
Si on utilise Oracle (ou autre) juste pour faire insert / select, alors, pour résumer "à la hache" car il se fait tard, on a acheté une voiture de luxe avec un moteur surpuissant mais on ne sert que du cendrier : cela facilite sans doute un portage, mais on peut aussi aussi se demander "que puis-je faire de plus, mieux, ou plus vite" avec ma super voiture pour en rentabiliser le prix, pour en "avoir pour mon argent" ? Au lieu de faire des transactions XA, puis-je simplifier mon code, voire le supprimer ? Comment faire pour ne pas avoir à gérer les cas de reprise après crash entre un transfert via sftp et une piste d'audit en base de données ? Comment faciliter le travail des DBA et des sysadmin pour qu'ils aient des environnements moins hétérogène à gérer ? …
Si on cherche à exploiter à fond ce que propose Oracle (Sql Server, DB2, MySql, postgres, openingres)… peu importe) pour en tirer la dernière goutte de "force de frappe", on rentabilise alors le coût de l'engin (licence, support, formation, …) mais un portage sera évidemment plus dur.
En tout état de cause, merci de ton article initial sur Ora2Pg - il a intégré mon catalogue d'outils "au cas où" et il me permettra peut-être un jour de proposer une solution pertinente à un client.
[^] # Re: Oui mais Oracle n'est pas un moteur SQL...
Posté par ekp . En réponse à la dépêche Migrer de Oracle à PostgreSQL : Ora2Pg. Évalué à 4.
Sommaire
@hamelg et @Niniryoku : j'aurais aimé compléter vos sujets mais il se fait trop tard pour mon petit cerveau.
@baud123
10g
Chantier "migration" en cours :-) (mais, à ma connaissance, on est toujours supporté).
Ceci explique aussi pourquoi je parle beaucoup de la 10g : c'est ce que nous avons en prod' depuis longtemps, c'est donc ce que je connais le mieux.
Streams
En effet, déprécié comme tu dis.
Mais cela ne signifie pas que ce composant va disparaître demain. Voir par exemple "Oracle Streams: What's New in Oracle Database 11g Release 2" : ça bouge encore pas mal.
Et quand bien même ils arrêtent sur la 12 ou 13 d'améliorer le composant, il restera en place un bon bout de temps (comme l'ancien scheduler de jobs par exemple). Ces deux point sont clairement annoncés dans Oracle GoldenGate Statement of Direction , page 4 :
Evidemment, les promesses n'engagent que ceux qui y croient comme on dit…
Scheduler
Merci du retour sur le produit que tu cites, il fut un candidat potentiel pour un projet passé et je suis heureux de ne pas l'avoir retenu (je crois qu'on a remplacé le scheduler par un humain dans cette histoire).
Concernant le scheduler d'Oracle, c'est sans doute différent de l'idée que tu en as. En résumé :
Pour l'IHM :
Pour les fonctionnalités :
FREQ=MONTHLY; BYDAY=MON; EXCLUDE=JoursFeries; BYSETPOS=-1(JoursFeriesétant le nom d'un calendrier que l'on a défini par ailleurs avec la liste … des jours fériés).Je ne doute pas qu'il existe des schedulers (? $U ?) qui savent faire bien plus que celui qui est nativement intégré à Oracle. Ce dernier possède cependant, à mon sens, quelques caractéristiques qui peuvent avoir de la valeur selon l'environnement dans lequel on travaille, les contraintes, les besoins, …
En résumé : "ça juste fonctionne" ("it just works"), c'est toujours installé, toujours disponible, et c'est la même chose partout où une base Oracle est déployée.
Perspectives
En complément, par rapport à mon premier post :
Au final, cela peut représenter une "force de frappe" conséquente quand on commence à faire l'inventaire de tous les composants qu'il faut assembler, faire fonctionner de manière harmonieuse et maintenir si on souhaite (ou si on doit !) partir sur une approche "brique par brique" plutôt que "all in one".
Oracle n'est certainement pas une solution miracle mais le produit a de réelles qualités, sur un vaste périmètre, souvent méconnues, et qui prennent tout leur sens quand on considère l'architecture d'un système d'information, sa réalisation, sa qualité, sa maintenance, et son exécution. Libre à chacun de déterminer si les fonctionnalités du produit fournissent de la valeur (qualitatif : moins de code à écrire = moins de bug, moins de technos à assembler et maîtriser, portabilité, …) et si le coût (quantitatif) est compétitif avec d'autres solutions.
Cela influe évidemment sur l'intérêt et le coût d'une migration :
En tout état de cause, merci de ton article initial sur Ora2Pg - il a intégré mon catalogue d'outils "au cas où" et il me permettra peut-être un jour de proposer une solution pertinente à un client.
Au plaisir de te lire à nouveau.