about News
Unified Audit 12.2 vs 12.1
- Détails
- Catégorie : News
- Publié le mercredi 13 juin 2018 20:13
- Écrit par Administrator
- Affichages : 68228
Cet article fait suite à 12c : (Pure) Unified Auditing qui avait été écrit pour la 12.1, la 12.2 n’étant alors pas encore sortie. L’audit unifié était une nouveauté de cette release. Mais avec la version 12.2, Oracle a changé l’architecture de l’audit unifié. Sur le principe il reste unifié, c’est-à-dire qu’il regroupe tous les audits en une seule table comme écrit dans le précédent article; ce qui change c’est l’architecture de cette table et aussi son mode de collecte.
En 12.1 la table de l’audit trail se nomme AUDSYS.CLI_* (nom dépendent de la base), en 12.2 elle se nomme AUDSYS.AUD$UNIFIED. Mais la véritable différence est qu’en 12.1 les données de l’audit se trouvent dans un champs de type blob (colonne LOG_PIECE) alors que sur la 12.2 les données de d’audit se trouvent éclatées au niveau des colonnes de façon classique comme pour l’audit standard dans la table SYS.AUD$ en 11g et avant.
En 12.1, dans la table AUDSYS.CLI_*, une ligne semble correspondre aux audit trails pour une session (SID#,SERAIL#) entre 2 flush d’audit (FLUSH_SCN, MAX_SCN, MIN_SCN), voir extract ci-dessous. En effet, une nouveauté en 12.1, qui sur le papier semble une très bonne idée, et qu’il est possible de ne pas écrire en direct dans la table d’audit mais dans un buffer queue (paramètre d’init : unified_audit_sga_queue_size et activation/désactivation avec la procédure DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY). D’où on peut en déduire que chaque fois que le cache de l’audit unifié est plein, il descend alors à ce moment-là en base et qu’il est mis dans le champs de type blob : LOG_PIECE.
Historique du Load et de l'AAS
- Détails
- Catégorie : Tuning et Performance
- Publié le vendredi 2 février 2018 20:18
- Écrit par Administrator
- Affichages : 11922
Quand on veut voir l’évolution dans le temps du load d’une base de données ou du AAS (Active Average Session), il faut requêter dba_hist_active_sess_history, à condition d’avoir une licence Diagnostic Pack. La vue contient autant d’historique que la période de rétention des snaphots AWR, (14 jours par défaut). Le résultat des requêtes n’est pas évident à formater pour avoir une vision synthétique et rapidement analysable.
En cherchant avec mon ami google, une requête permettant d’avoir une bonne vision du LOAD dans le temps, je suis tombé sur le billet Database Load heatmap with AWR and Python de Laurent Leturgez, qui, soit dit en passant, avoue lui-même avoir chercher une requête sur internet qui faisait déjà cela et il était tombé sur le blog de Marcin Przepiorowski.
Laurent Leturgez explique, dans son article, comment sortir le résultat de la requête en mode heatmap avec python. Le résultat est beau et effectivement les périodes les plus chargées ressortent bien.
Trouver l'édition et la version Oracle
- Détails
- Catégorie : Edition, version, option, usage, licence
- Publié le jeudi 1 février 2018 20:54
- Écrit par Administrator
- Affichages : 42018
Il peut arriver parfois d’avoir besoin de connaitre la version et l’édition d’un moteur Oracle sur un serveur alors qu’aucune base de données ne tourne, voir n’a été créée. Cela peut paraître trivial, mais il y a des cas, en particulier en 11g, où ce n’est pas toujours évident même avec une de base démarrée.
Cet article explique comment trouver la version : 11.2.0 .4, 12.2.0.1… et l’édition : Entreprise Standard Two, Express... d’un moteur Oracle même base de données éteinte. Il peut s’appliquer aux versions 10gR2 à 12cR2. Il devrait être applicable au version 9 et 8 (non testé) et peut être au versions 18 et plus (version non sortie à ce jour).
La Version
La version est l’information la plus facile à obtenir par rapport à l’édition, même base arrêtée.
Pour déterminer la version des binaires Oracle installés sur un serveur, quand il n’y a aucune base qui tourne et que l’on a accès au binaire du moteur, accès local donc, le plus rapide est de tester la version du sqlplus :
[oracle@ora12cR2 ~]$ sqlplus -version
SQL*Plus: Release 12.2.0.1.0 Production
Une méthode, plus rigoureuse, est d’interroger OPatch.
[oracle@ora12cR2 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory|grep "Oracle Database"
Oracle Database 12c 12.2.0.1.0
[oracle@asmdbm01 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory|grep "Oracle Database"
Oracle Database 11g 11.2.0.4.0
[oracle@saddbm ~]$ $ORACLE_HOME/OPatch/opatch lsinventory|grep "Oracle Database"
Oracle Database 10g 10.2.0.1.0
Oracle Database 10g Release 2 Patch Set 4 10.2.0.5.0
News: Après la 12, la 18.
- Détails
- Catégorie : News
- Publié le mercredi 13 décembre 2017 22:05
- Écrit par Administrator
- Affichages : 58163
En janvier 2018 va sortir la version d’Oracle 18.1.0. Non ce n’est pas une erreur, ni un poisson de décembre. Cette version sera la suite de la version 12.2.0.1, et elle correspondra à la version 12.2.0.2. Il n’y aura donc jamais de version 13 ce qui aurait certainement porté malheur à Oracle. Plus sérieusement, Oracle change sa nomenclature des versions de base de données ainsi que le mode/rythme des mises à jour.
Oracle prévoit de sortir une release tous les ans, et cette release portera le nom de l’année de sortie d’où le 18 à la place de la 12.2.0.2 qui est prévu pour janvier 2018. Ensuite pour cette release, tous les trimestres sortira un RU (Release Update), qui est un peu l’équivalent du Proactive Bundle Patch, qui s’appliquera à une Release. Et chaque trimestre sortira un RUR (Release Update Revisions), l’équivalent d’un PSU (Patch Set Update), qui s’appliquera à un couple Release.RU. La frise chronologique ci-dessous permet mieux appréhender l’enchainement des sorties des Release, RU et RUR:
Extrait de la note Oracle: Release Update Introduction and FAQ (Doc ID 2285040.1)
News: H: suite et fin
- Détails
- Catégorie : News
- Publié le lundi 20 novembre 2017 21:30
- Écrit par Administrator
- Affichages : 61022
J’avais publié le 22 novembre 2015, l'article News: Problème de sécurité sur les passwords 12c sur la facilité à casser les mots de passe de type H: dans sys.user$. Les mots de passes y étaient stockés en MD5 avec un secret. Et le 22 janvier 2016 dans l'article News: Le secret du H:, j’expliquais que ce secret été simple à trouver. Je proposais aussi de faire un update dans sys.user$ pour sortir (effacer) le stockage du mot de passe en MD5 de la base, mais alors cela provoquerait une perte de support d’Oracle, et qu’il valait mieux ouvrir un support à Oracle avant. Quelque temps plus tard, j’ai donc ouvert un support à Oracle faisant suite à ces deux articles, et cela c’était conclu de la part du support : il n’y avait de contournement possible et qu’effectivement le hash MD5 du mot de passe était faible.
Cette faiblesse de stockage de mot de passe a été corrigé dans le patch sécurité d’octobre 2016. Mais attention le passage de ce patch ne corrige pas le problème sur les anciens comptes générés avant le patch, il y a une action manuelle à faire qui correspond, qui grossièrement correspond à faire un update dans sys.user$ mais en passant par une nouvelle procédure fournit par oracle. Tout ceci est expliqué dans le document 2194116.1 sous Oracle support. On y apprend que le mot de passe était stocké en MD5 pour permettre l’authentification avec XDB HTTP(S), et un peu sous forme de mea culpa, Oracle reconnait que ce n’est plus très bien de faire cela.