Je vais me permettre de tenter d'apporter quelques éléments techniques sur Oracle (version 10g) - c'est un moteur avec lequel je travaille depuis plusieurs années, je ne suis pas "gourou" Oracle, je n'ai pas d'actions chez eux, et je n'ai pas choisi de travailler avec ce produit.
J'insiste : je parle de technique, pas de prix - c'est un autre débat qui dépend du contexte de chacun et de la valeur que chacun donne à ce qui est dans son moteur de base de données versus le coût de développement (+ maintenance + degré de qualité) des fonctionnalités qui manquent dans ce moteur pour répondre aux exigences du client + la réactivité et la qualité du support de l'éditeur + le savoir-faire des équipes en place + plein d'autre choses. Donc, ça varie et chacun a sa vision de la vérité, elle n'est ni meilleure ni moins bonne qu'une autre vérité. Ce post n'a pas pour volonté d'ouvrir ce genre de débat sans issue, je souhaite juste apporter ma pierre à l'édifice.
Voici pour le préambule afin de "fixer le décor".
Maintenant, le plus important est de comprendre que le moteur de base de données SQL d'Oracle ne représente finalement qu'une petite partie du produit. Ce moteur SQL est apprécié, il a des qualités et des défauts (comme les autres), etc mais choisir Oracle uniquement pour son moteur SQL c'est comme acheter une voiture de course en pensant que l'on a acheté une charrette à bras : c'est globalement sous-optimal, on passe à côté de beaucoup de fonctionnalités offertes par le produit que l'on risque de s'évertuer à vouloir re-implémenter ou re-développer à côté (et, partant du principe qu'une ligne de code fiable et bien débugée est une ligne de code que l'on n'a pas à écrire car d'autres l'ont déjà fait, je laisse à chacun le soin de conclure).
Donc, on trouve par exemple dans Oracle :
* un broker de messages applicatifs offrant notamment une API JMS (et de la cohérence transactionnelle avec la base, évidemment) ;
* (déjà cité dans un autre post) un langage nommé PL/SQL qui peut ne pas plaire à tout le monde mais qui offre plein de possibilités dont un compilateur ;
* une foultitude de packages PL/SQL prêts à l'emploi ;
* du Java avec compilateur natif ;
* des API et des pré-compilateurs variés ;
* un scheduler, c.à.d un moteur d'exécution de jobs ;
* un socle de Change Data Capture (CDC) en temps réel permettant de faire de la réplication de données multi-sites, multi-bases, et bien plus encore ;
* un outil de backup / restore évolué (gestion de la péremption des backups, de leur redondance, …) ;
* un stockage raw (comprendre "pas des fichiers") redondant et stripé ;
* un outil d'administration / supervision Web ;
* des métriques de performance très vastes, avec une vision instantanée et une vision historique ;
* une documentation très complète ;
* …
… et plein d'autres choses encore.
On constatera donc que dire qu'Oracle est une base de données est une définition finalement assez réductrice. Son moteur SQL est riche, mais quand on considère l'ensemble des fonctionnalités apportées par ce que l'on appelle "Oracle" et qui est disponible sur plusieurs OS et plusieurs plate-formes matérielles (du PC x86 "basique" Linux / Windows jusqu'aux mainframes en passant par Solaris, AIX, …), on obtient un socle d'exécution dans lequel le moteur SQL n'est qu'une brique parmi d'autres.
Ce qui fait l'intérêt d'Oracle, bien au-delà des qualités (ou pas) du moteur SQL que l'on peut aimer ou pas, c'est tout ce qui est disponible en plus du moteur SQL, qui fait partie intégrante du produit et qui forme un socle cohérent, homogène, documenté, supporté, et d'une certaine manière, portable (on ne développe plus sous Linux ou Windows ou mainframe, on développe sur Oracle).
Chacun appréciera en fonction de son contexte, des exigences techniques et fonctionnelles du projet, du budget, des compétences en place, …
Disclaimer :
* J'espère que tout ceci ne ressemble pas à une publicité pour Oracle car ce n'est pas mon intention, ils ont bien assez de budget pour faire de la pub' sans moi, je ne suis pas attaché à Oracle plus qu'à un autre produit (j'utilise par ailleurs SQL Server et postgres - sur des projets de moindre envergure - et cela donne entière satisfaction).
* Et Oracle n'est pas un produit parfait ni miraculeux, tout le monde s'en doutait !
Plus de détails ci-dessous (je ne suis pas assez "calé" en Oracle mais à priori, tout ce qui est décrit ci-dessous est disponible à l'identique sur tous les OS et toutes les plate-formes matérielles supportés par Oracle).
Un broker de messages applicatifs :
* pas besoin d'installer un serveur JMS : il y en a déjà un dans le moteur ;
* pas besoin de chercher comment on fait une transaction XA afin d'embarquer dans un seul commit ou rollback un put dans une file de messages et des actions quelconques en base de données : c'est nativement supporté sans faire du XA ;
* comme c'est natif et intégré au moteur, l'état du broker (messages en cours, …) est backupé avec la base et cela forme donc un ensemble transactionnellement cohérent si on doit faire un restore ;
* ce broker s'utilise aussi en PL/SQL et autres langages (Java/JMS n'est qu'une API au-dessus du composant Oracle qui se nomme Advanced Queuing) ;
* il permet d'échanger des messages entre différents serveurs Oracle ;
* il supporte le publish and subscribe ou le point à point ;
* … bla bla, voir par ici pour en savoir plus AQ 10g ;
* … le fonctionnement est supervisable via des tables, tant sur son bon fonctionnement que sur les performances et la volumétrie, voir par exemple DBA_HIST_BUFFERED_SUBSCRIBERS qui historise certaines des statistiques d'utilisation dans un scénario publish and subscribe (la même chose existe temps réel).
(déjà cité dans un autre post) Un langage nommé PL/SQL qui peut ne pas plaire à tout le monde mais qui offre tout ce que l'on peut raisonnablement attendre d'un langage procédural dont par exemple :
* la possibilité de créer des packages avec une partie publique et une partie privée ;
* un compilateur optimisant ;
* un profiler de code afin de collecter des métriques de performance ;
* un debuger live ;
* des concepts tels que des tableaux associatifs, des structures, de l'héritage aussi si ma mémoire est bonne, … ;
* la possibilité de créer des types personnels autant que de besoin ;
* la possibilité de créer des fonctions dont les résultats peuvent être consommés par une requête SQL comme si c'était une table ;
* un mécanisme try / catch ;
* un traitement efficace des opérations de masse afin de limiter les fetch en base ;
* la possibilité de créer des fonctions dont le résultat sera mis en cache par le moteur afin d'accéler les appels suivants avec les mêmes arguments ;
* la présence de ce langage, à l'identique et avec les mêmes possibilités, sur toutes les plateformes matérielles et tous les OS supportés par Oracle : Linux, Windows, HP/UX, z/OS, Solaris, AIX, … celui qui cherche la portabilité devrait pouvoir trouver son bonheur ;
* … bla bla - ceux qui veulent en savoir plus peuvent aller faire un tour ici PL/SQL 10g.
Une foultitude de packages PL/SQL prêts à l'emploi :
* je ne vais pas tous les citer, il doit y en avoir plus d'une centaine ;
* la liste se trouve ici packages 10g.
Pour ceux qui préfèrent Java :
* on peut aussi écrire des procédures stockées en Java ;
* avec un compilateur natif ;
* et on peut appeller du code Java depuis PL/SQL (et vice-versa je crois me souvenir) ;
* plus de détails ici Java 10g.
Des API et des pré-compilateurs variés :
* on peut travailler en C#, C/C++, Java, Cobol, Fortran ;
* sur différents systèmes d'exploitation : Linux, Windows, Solaris, AIX, OpenVMS, z/OS, … ;
* et d'autres (PHP par exemple), mais je ne connais pas assez pour détailler.
Un scheduler, c.à.d un moteur d'exécution de jobs
* permettant de définir des enchaînements de tâches ;
* permettant de définir des fenêtres temporelles durant lesquelles un job peut ou ne peut pas se déclencher (par exempe : job XYZ déclenché tous les avant-derniers jeudi du mois à 2h du matin en heure locale) ;
* permettant de définir des quotas à un job en fonction de la fenêtre temporelle courante (jobs de maintenance = 100% quota tous les dimanche mais seulement 10% en semaine afin de ne pas "plomber" les IO des requêtes applicatives) ;
* tout ceci est transactionnel, intégré à la base et correctement audité ;
* ceci est décrit ici Scheduler 10g.
Un socle de Change Data Capture en temps réel permettant de faire de la réplication multi-sites, multi-bases, et avec des boucles si on le souhaite :
* je manque un peu de courage pour détailler la chose, j'espère que cela restera compréhensible et assez proche de la réalite ;
* CDC permet de collecter en temps réel les modifications apportées à une table (ou mille tables), soit en mémoire soit par analyse des journaux si ça va trop vite, puis alimente une table qui décrit ces modifications ("la 678ème opération de la transaction 5772829 était un update ; les données avant l'update sont : bla bla ; les données après l'update sont bla bla") ;
* ces tables de changements sont accessibles directement si on veut ;
* mais on préfère y accéder via des vues (mise en place par une API PL/SQL) afin que plusieurs consommateurs puissent traiter lesdites données, chacun à son rythme (dans le principe, c'est un peu comme du publish and subscribe dans le monde JMS sauf que l'on ne consomme pas des messages mais des infos stockées dans des tables) ;
* CDC se charge de supprimer les anciennes données de ces tables lorsque tout le monde les a consommées ;
* le composant CDC n'est qu'une surcouche simplificatrice à un autre composant nommé Oracle Streams (qui s'appuie lui-même sur le broker de messages applicatifs cité auparavant) ;
* Streams permet de faire à peu près tout ce dont on peut rêver de faire dans n'importe quel scénario de réplication de données ;
* on peut inspecter les données, les transformer, les router, … ;
* cela réplique non seulement les opérations type DML (insert / …) mais aussi le DDL (create table, …) ;
* pour CDC, la porte d'entrée est ici CDC - il y a plusieurs options techniques (triggers = beurk ou via journaux comme expliqué au dessus = mieux = ici par exemple) ;
* pour Streams, la porte d'entrée est ici Streams ;
* ceci est supervisable via des tables afin d'en contrôler le bon fonctionnement et la performance ;
* ceci étant intégré au moteur, c'est également intégré au backup / restore, ce qui garantit de toujours revenir à un état transactionnellement cohérent si on doit faire une restauration.
Un outil de backup / restore évolué :
* il se nomme RMAN ;
* il sait compresser ;
* il sait faire des backups redondants ;
* il sait gérer la péremption des backups ("je veux deux backups de ma base dans ce répertoire-ci et ce répertoire-là et je veux être capable de revenir en arrière de trois semaines à tout instant : débrouille-toi !") ;
* ceci est supervisable via des tables ;
* … pour en savoir plus sur RMAN, voir par exemple ici RMAN.
Un stockage raw nommé ASM (warning : je n'ai jamais mis en oeuvre) :
* les fichiers c'est bien mais cela suppose de traverser pas mal de couches de l'OS ;
* cela n'est pas obligatoirement optimal en termes de performance ;
* cela peut imposer à l'OS de gérer beaucoup de blocs en cache, ce qui réduit d'autant la mémoire que peut utiliser Oracle pour son propre cache (et ce qui pénalise aussi les autres applications) ;
* c'est pourquoi ASM permet de dédier plusieurs partitions à Oracle ;
* ASM se charge ensuite de la redondance des données (0, 1 ou 2 copies) et du striping ;
* pour en savoir plus, c'est ici ASM.
Un outil d'administration / supervision Web :
* il se nomme OEM ;
* la licence Oracle permet de l'utiliser dans sa version mono-instance (de ce que j'ai compris : 1 licence Oracle = 1 droit d'utilisation de OEM) ;
* il y a une version dite "grid", c.à.d multi-bases et qui fait le café mais il faut sortir le chéquier ;
* OEM permet de faire par clic-clic beaucoup d'opérations d'administration : backup ponctuel, gestion des utilisateurs, de l'espace de stockage, … ;
* OEM permet aussi de faire de la supervision de performance du moteur dans sa globalité, des requêtes, et du système d'exploitation ;
* on peut obtenir des rapports de performance détaillés afin de savoir à quoi la base passe son temps ;
* on peut comparer deux périodes d'activité de la base (par exemple : comparer l'activité du mercredi 10H-12H avec l'activité du mercredi précédent sur le même créneau horaire afin d'aider à comprendre pourquoi il y a eu des problèmes de performance) ;
* OEM peut vérifier si la configuration de la base est conforme à un certain nombre de règles de sécurité (pré-définies ; je suppose qu'on peut en ajouter) ;
* si cela lui est permis, OEM peut identifier les patchs qui n'ont pas été déployés sur la base ;
* … pour en savoir plus, voir ici OEM ;
* … pour quelques copies d'écran du monitoring de perfs en temps réel, voir ici OEM perf ;
* … pour un petit aperçu de quelques métriques disponibles, voir la fin de cette page MET.
Des métriques de performance très vastes, avec une vision instantanée et une vision historique :
* en instantané, une fois par seconde pour être précis, il y a ASH qui collecte une multitude d'indicateurs de performance et qui permet, en cas de souci, d'aider à comprendre où se situe le problème (IO ? quel type d'IO : journaux ? données ? lectures de blocs en séquentiel ou en aléatoire ? mémoire ? quelle(s) requête(s) sont responsables de cette activité ? …) ;
* en historique, il y a ADDM et AWR qui stockent tout ceci (pas 100%, il y a du sampling) en base de données ;
* il est alors possible de d'obtenir des tendances sur plusieurs jours, semaines, mois, … (la durée de rétention de ces données de performance est paramétrable) ;
* il est également possible de comparer l'activité de la base entre deux périodes (par exemple : évolution entre cette semaine et la semaine précédente) ;
* tout ceci est exploitable par des tables et / ou une API PL/SQL et / ou via l'IHM Web de OEM ;
* … et pour en savoir plus, c'est ici, au chapitre 5 par exemple PERFS ;
* … pour une liste plus exhaustive, voir "Part III" ici V$, quand on est un peu (beaucoup !) maniaque sur les perfs, on peut apprécier des choses telles que V$FILE_HISTOGRAM par exemple.
Une documentation très complète :
* le point d'entrée est ici DOC ;
* un index index donnera une idée de la quantité de documentation disponible ;
* cette documentation peut être installée localement sur n'importe quel PC (on perd la recherche dans la doc au format HTML mais elle est également fournie en fichiers PDF avec possibilité de faire des recherches globales) ;
* ceci est un réel atout pour le développeur, l'administrateur DBA ou le concepteur que de pouvoir s'appuyer sur une documentation aussi riche (de mémoire : quelques centaines de Mo) ;
* cette documentation prend soin de définir les concepts importants : c'est bête mais c'est vital ;
* pour se faire une idée, voir ici CONCEPTS : c'est 400 ou 500 pages qui donnent un aperçu de tout, du sol au plafond.
Toutes mes félicitations à celles et ceux qui ont tout lu jusqu'ici, bonne continuation.
# 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é à 3.
Bonsoir à tous,
Je vais me permettre de tenter d'apporter quelques éléments techniques sur Oracle (version 10g) - c'est un moteur avec lequel je travaille depuis plusieurs années, je ne suis pas "gourou" Oracle, je n'ai pas d'actions chez eux, et je n'ai pas choisi de travailler avec ce produit.
J'insiste : je parle de technique, pas de prix - c'est un autre débat qui dépend du contexte de chacun et de la valeur que chacun donne à ce qui est dans son moteur de base de données versus le coût de développement (+ maintenance + degré de qualité) des fonctionnalités qui manquent dans ce moteur pour répondre aux exigences du client + la réactivité et la qualité du support de l'éditeur + le savoir-faire des équipes en place + plein d'autre choses. Donc, ça varie et chacun a sa vision de la vérité, elle n'est ni meilleure ni moins bonne qu'une autre vérité. Ce post n'a pas pour volonté d'ouvrir ce genre de débat sans issue, je souhaite juste apporter ma pierre à l'édifice.
Voici pour le préambule afin de "fixer le décor".
Maintenant, le plus important est de comprendre que le moteur de base de données SQL d'Oracle ne représente finalement qu'une petite partie du produit. Ce moteur SQL est apprécié, il a des qualités et des défauts (comme les autres), etc mais choisir Oracle uniquement pour son moteur SQL c'est comme acheter une voiture de course en pensant que l'on a acheté une charrette à bras : c'est globalement sous-optimal, on passe à côté de beaucoup de fonctionnalités offertes par le produit que l'on risque de s'évertuer à vouloir re-implémenter ou re-développer à côté (et, partant du principe qu'une ligne de code fiable et bien débugée est une ligne de code que l'on n'a pas à écrire car d'autres l'ont déjà fait, je laisse à chacun le soin de conclure).
Donc, on trouve par exemple dans Oracle :
* un broker de messages applicatifs offrant notamment une API JMS (et de la cohérence transactionnelle avec la base, évidemment) ;
* (déjà cité dans un autre post) un langage nommé PL/SQL qui peut ne pas plaire à tout le monde mais qui offre plein de possibilités dont un compilateur ;
* une foultitude de packages PL/SQL prêts à l'emploi ;
* du Java avec compilateur natif ;
* des API et des pré-compilateurs variés ;
* un scheduler, c.à.d un moteur d'exécution de jobs ;
* un socle de Change Data Capture (CDC) en temps réel permettant de faire de la réplication de données multi-sites, multi-bases, et bien plus encore ;
* un outil de backup / restore évolué (gestion de la péremption des backups, de leur redondance, …) ;
* un stockage raw (comprendre "pas des fichiers") redondant et stripé ;
* un outil d'administration / supervision Web ;
* des métriques de performance très vastes, avec une vision instantanée et une vision historique ;
* une documentation très complète ;
* …
… et plein d'autres choses encore.
On constatera donc que dire qu'Oracle est une base de données est une définition finalement assez réductrice. Son moteur SQL est riche, mais quand on considère l'ensemble des fonctionnalités apportées par ce que l'on appelle "Oracle" et qui est disponible sur plusieurs OS et plusieurs plate-formes matérielles (du PC x86 "basique" Linux / Windows jusqu'aux mainframes en passant par Solaris, AIX, …), on obtient un socle d'exécution dans lequel le moteur SQL n'est qu'une brique parmi d'autres.
Ce qui fait l'intérêt d'Oracle, bien au-delà des qualités (ou pas) du moteur SQL que l'on peut aimer ou pas, c'est tout ce qui est disponible en plus du moteur SQL, qui fait partie intégrante du produit et qui forme un socle cohérent, homogène, documenté, supporté, et d'une certaine manière, portable (on ne développe plus sous Linux ou Windows ou mainframe, on développe sur Oracle).
Chacun appréciera en fonction de son contexte, des exigences techniques et fonctionnelles du projet, du budget, des compétences en place, …
Disclaimer :
* J'espère que tout ceci ne ressemble pas à une publicité pour Oracle car ce n'est pas mon intention, ils ont bien assez de budget pour faire de la pub' sans moi, je ne suis pas attaché à Oracle plus qu'à un autre produit (j'utilise par ailleurs SQL Server et postgres - sur des projets de moindre envergure - et cela donne entière satisfaction).
* Et Oracle n'est pas un produit parfait ni miraculeux, tout le monde s'en doutait !
Plus de détails ci-dessous (je ne suis pas assez "calé" en Oracle mais à priori, tout ce qui est décrit ci-dessous est disponible à l'identique sur tous les OS et toutes les plate-formes matérielles supportés par Oracle).
Un broker de messages applicatifs :
* pas besoin d'installer un serveur JMS : il y en a déjà un dans le moteur ;
* pas besoin de chercher comment on fait une transaction XA afin d'embarquer dans un seul commit ou rollback un put dans une file de messages et des actions quelconques en base de données : c'est nativement supporté sans faire du XA ;
* comme c'est natif et intégré au moteur, l'état du broker (messages en cours, …) est backupé avec la base et cela forme donc un ensemble transactionnellement cohérent si on doit faire un restore ;
* ce broker s'utilise aussi en PL/SQL et autres langages (Java/JMS n'est qu'une API au-dessus du composant Oracle qui se nomme Advanced Queuing) ;
* il permet d'échanger des messages entre différents serveurs Oracle ;
* il supporte le publish and subscribe ou le point à point ;
* … bla bla, voir par ici pour en savoir plus AQ 10g ;
* … le fonctionnement est supervisable via des tables, tant sur son bon fonctionnement que sur les performances et la volumétrie, voir par exemple DBA_HIST_BUFFERED_SUBSCRIBERS qui historise certaines des statistiques d'utilisation dans un scénario publish and subscribe (la même chose existe temps réel).
(déjà cité dans un autre post) Un langage nommé PL/SQL qui peut ne pas plaire à tout le monde mais qui offre tout ce que l'on peut raisonnablement attendre d'un langage procédural dont par exemple :
* la possibilité de créer des packages avec une partie publique et une partie privée ;
* un compilateur optimisant ;
* un profiler de code afin de collecter des métriques de performance ;
* un debuger live ;
* des concepts tels que des tableaux associatifs, des structures, de l'héritage aussi si ma mémoire est bonne, … ;
* la possibilité de créer des types personnels autant que de besoin ;
* la possibilité de créer des fonctions dont les résultats peuvent être consommés par une requête SQL comme si c'était une table ;
* un mécanisme
try / catch;* un traitement efficace des opérations de masse afin de limiter les fetch en base ;
* la possibilité de créer des fonctions dont le résultat sera mis en cache par le moteur afin d'accéler les appels suivants avec les mêmes arguments ;
* la présence de ce langage, à l'identique et avec les mêmes possibilités, sur toutes les plateformes matérielles et tous les OS supportés par Oracle : Linux, Windows, HP/UX, z/OS, Solaris, AIX, … celui qui cherche la portabilité devrait pouvoir trouver son bonheur ;
* … bla bla - ceux qui veulent en savoir plus peuvent aller faire un tour ici PL/SQL 10g.
Une foultitude de packages PL/SQL prêts à l'emploi :
* je ne vais pas tous les citer, il doit y en avoir plus d'une centaine ;
* la liste se trouve ici packages 10g.
Pour ceux qui préfèrent Java :
* on peut aussi écrire des procédures stockées en Java ;
* avec un compilateur natif ;
* et on peut appeller du code Java depuis PL/SQL (et vice-versa je crois me souvenir) ;
* plus de détails ici Java 10g.
Des API et des pré-compilateurs variés :
* on peut travailler en C#, C/C++, Java, Cobol, Fortran ;
* sur différents systèmes d'exploitation : Linux, Windows, Solaris, AIX, OpenVMS, z/OS, … ;
* et d'autres (PHP par exemple), mais je ne connais pas assez pour détailler.
Un scheduler, c.à.d un moteur d'exécution de jobs
* permettant de définir des enchaînements de tâches ;
* permettant de définir des fenêtres temporelles durant lesquelles un job peut ou ne peut pas se déclencher (par exempe : job XYZ déclenché tous les avant-derniers jeudi du mois à 2h du matin en heure locale) ;
* permettant de définir des quotas à un job en fonction de la fenêtre temporelle courante (jobs de maintenance = 100% quota tous les dimanche mais seulement 10% en semaine afin de ne pas "plomber" les IO des requêtes applicatives) ;
* tout ceci est transactionnel, intégré à la base et correctement audité ;
* ceci est décrit ici Scheduler 10g.
Un socle de Change Data Capture en temps réel permettant de faire de la réplication multi-sites, multi-bases, et avec des boucles si on le souhaite :
* je manque un peu de courage pour détailler la chose, j'espère que cela restera compréhensible et assez proche de la réalite ;
* CDC permet de collecter en temps réel les modifications apportées à une table (ou mille tables), soit en mémoire soit par analyse des journaux si ça va trop vite, puis alimente une table qui décrit ces modifications ("la 678ème opération de la transaction 5772829 était un update ; les données avant l'update sont : bla bla ; les données après l'update sont bla bla") ;
* ces tables de changements sont accessibles directement si on veut ;
* mais on préfère y accéder via des vues (mise en place par une API PL/SQL) afin que plusieurs consommateurs puissent traiter lesdites données, chacun à son rythme (dans le principe, c'est un peu comme du publish and subscribe dans le monde JMS sauf que l'on ne consomme pas des messages mais des infos stockées dans des tables) ;
* CDC se charge de supprimer les anciennes données de ces tables lorsque tout le monde les a consommées ;
* le composant CDC n'est qu'une surcouche simplificatrice à un autre composant nommé Oracle Streams (qui s'appuie lui-même sur le broker de messages applicatifs cité auparavant) ;
* Streams permet de faire à peu près tout ce dont on peut rêver de faire dans n'importe quel scénario de réplication de données ;
* on peut inspecter les données, les transformer, les router, … ;
* cela réplique non seulement les opérations type DML (insert / …) mais aussi le DDL (create table, …) ;
* pour CDC, la porte d'entrée est ici CDC - il y a plusieurs options techniques (triggers = beurk ou via journaux comme expliqué au dessus = mieux = ici par exemple) ;
* pour Streams, la porte d'entrée est ici Streams ;
* ceci est supervisable via des tables afin d'en contrôler le bon fonctionnement et la performance ;
* ceci étant intégré au moteur, c'est également intégré au backup / restore, ce qui garantit de toujours revenir à un état transactionnellement cohérent si on doit faire une restauration.
Un outil de backup / restore évolué :
* il se nomme RMAN ;
* il sait compresser ;
* il sait faire des backups redondants ;
* il sait gérer la péremption des backups ("je veux deux backups de ma base dans ce répertoire-ci et ce répertoire-là et je veux être capable de revenir en arrière de trois semaines à tout instant : débrouille-toi !") ;
* ceci est supervisable via des tables ;
* … pour en savoir plus sur RMAN, voir par exemple ici RMAN.
Un stockage raw nommé ASM (warning : je n'ai jamais mis en oeuvre) :
* les fichiers c'est bien mais cela suppose de traverser pas mal de couches de l'OS ;
* cela n'est pas obligatoirement optimal en termes de performance ;
* cela peut imposer à l'OS de gérer beaucoup de blocs en cache, ce qui réduit d'autant la mémoire que peut utiliser Oracle pour son propre cache (et ce qui pénalise aussi les autres applications) ;
* c'est pourquoi ASM permet de dédier plusieurs partitions à Oracle ;
* ASM se charge ensuite de la redondance des données (0, 1 ou 2 copies) et du striping ;
* pour en savoir plus, c'est ici ASM.
Un outil d'administration / supervision Web :
* il se nomme OEM ;
* la licence Oracle permet de l'utiliser dans sa version mono-instance (de ce que j'ai compris : 1 licence Oracle = 1 droit d'utilisation de OEM) ;
* il y a une version dite "grid", c.à.d multi-bases et qui fait le café mais il faut sortir le chéquier ;
* OEM permet de faire par clic-clic beaucoup d'opérations d'administration : backup ponctuel, gestion des utilisateurs, de l'espace de stockage, … ;
* OEM permet aussi de faire de la supervision de performance du moteur dans sa globalité, des requêtes, et du système d'exploitation ;
* on peut obtenir des rapports de performance détaillés afin de savoir à quoi la base passe son temps ;
* on peut comparer deux périodes d'activité de la base (par exemple : comparer l'activité du mercredi 10H-12H avec l'activité du mercredi précédent sur le même créneau horaire afin d'aider à comprendre pourquoi il y a eu des problèmes de performance) ;
* OEM peut vérifier si la configuration de la base est conforme à un certain nombre de règles de sécurité (pré-définies ; je suppose qu'on peut en ajouter) ;
* si cela lui est permis, OEM peut identifier les patchs qui n'ont pas été déployés sur la base ;
* … pour en savoir plus, voir ici OEM ;
* … pour quelques copies d'écran du monitoring de perfs en temps réel, voir ici OEM perf ;
* … pour un petit aperçu de quelques métriques disponibles, voir la fin de cette page MET.
Des métriques de performance très vastes, avec une vision instantanée et une vision historique :
* en instantané, une fois par seconde pour être précis, il y a ASH qui collecte une multitude d'indicateurs de performance et qui permet, en cas de souci, d'aider à comprendre où se situe le problème (IO ? quel type d'IO : journaux ? données ? lectures de blocs en séquentiel ou en aléatoire ? mémoire ? quelle(s) requête(s) sont responsables de cette activité ? …) ;
* en historique, il y a ADDM et AWR qui stockent tout ceci (pas 100%, il y a du sampling) en base de données ;
* il est alors possible de d'obtenir des tendances sur plusieurs jours, semaines, mois, … (la durée de rétention de ces données de performance est paramétrable) ;
* il est également possible de comparer l'activité de la base entre deux périodes (par exemple : évolution entre cette semaine et la semaine précédente) ;
* tout ceci est exploitable par des tables et / ou une API PL/SQL et / ou via l'IHM Web de OEM ;
* … et pour en savoir plus, c'est ici, au chapitre 5 par exemple PERFS ;
* … pour une liste plus exhaustive, voir "Part III" ici V$, quand on est un peu (beaucoup !) maniaque sur les perfs, on peut apprécier des choses telles que V$FILE_HISTOGRAM par exemple.
Une documentation très complète :
* le point d'entrée est ici DOC ;
* un index index donnera une idée de la quantité de documentation disponible ;
* cette documentation peut être installée localement sur n'importe quel PC (on perd la recherche dans la doc au format HTML mais elle est également fournie en fichiers PDF avec possibilité de faire des recherches globales) ;
* ceci est un réel atout pour le développeur, l'administrateur DBA ou le concepteur que de pouvoir s'appuyer sur une documentation aussi riche (de mémoire : quelques centaines de Mo) ;
* cette documentation prend soin de définir les concepts importants : c'est bête mais c'est vital ;
* pour se faire une idée, voir ici CONCEPTS : c'est 400 ou 500 pages qui donnent un aperçu de tout, du sol au plafond.
Toutes mes félicitations à celles et ceux qui ont tout lu jusqu'ici, bonne continuation.