Oracle Internal Core : Trouver les objets cachés via le dictionnaire de données et autres - Find hidden Oracle objects
Introduction
La base de données Oracle s'appuie sur des objets cachés qui ne sont pas documentés et ne devraient jamais être utilisés directement. Pour pallier cela, Oracle propose des objets alternatifs (en général des vues) qui s'appuient eux-même sur ces objets cachés et qui sont parfaitement documentés.
Néanmoins, dans certains cas, il est bon de savoir que ces objets existent, ne serait-ce que pour mieux comprendre comment fonctionne Oracle et pour accéder à des informations qui n'existent pas dans les vues ou dans les objets officiels.
Nous verrons aussi qu'il existe d'autres objets plus ou moins cachés, dont nous avons entendu parler, que nous utilisons parfois, des outils comme les traces, le rapport AWR... mais qui ne sont pas officiellement reconnus par Oracle puisqu'ils n'apparaissent pas dans la doc officielle.
Points d'attention
Je le rappelle : les objets que nous allons voir ne sont pas documentés et ne devraient être utilisés qu'avec l'accord du support Oracle! N'étant pas documentés, il est impossible de connaître leurs effets de bord et dommages collatéraux!
Base de tests
Une 11gr2.
Exemples
============================================================================================
Liste des tables systèmes d'Oracle.
============================================================================================
Dans le dictionnaire de données, la plupart des objets, comme DBA_TABLES, ne sont pas de vraies tables mais des vues s'appuyant sur les tables système d'Oracle, le vrai MPD. Ces tables systèmes sont répertoriées dans DBA_TABLES et se terminent par le signe $.
Exemple : si on utilise la fonction dbms_metadata.get_ddl sur DBA_ROLES, on se rend compte que DBA_ROLES s'appuie sur la table système USER$.
SQL> select dbms_metadata.get_ddl('VIEW', 'DBA_ROLES') from dual;
DBMS_METADATA.GET_DDL('VIEW','DBA_ROLES')
--------------------------------------------------------------------------------
CREATE OR REPLACE FORCE VIEW "SYS"."DBA_ROLES" ("ROLE", "PASSWORD_REQUIRED", "
AUTHENTICATION_TYPE") AS
select
name, decode(password, null, 'NO', 'EXTERNAL', 'EXTERNAL', 'GLOBAL', 'GLOBAL', 'YES'),
decode(password, null, 'NONE','EXTERNAL', 'EXTERNAL','GLOBAL', 'GLOBAL', 'APPLICATION', 'APPLICATION','PASSWORD')
from
user$
where
type# = 0 and
name not in ('PUBLIC', '_NEXT_USER')
L'ordre SQL pour avoir la liste de ces tables système est le suivant (exception faite des tables AWR qui ont le $ au milieu de leur nom) :
SQL> SELECT TABLE_NAME FROM DBA_TABLES WHERE TABLE_NAME LIKE '%$' ORDER BY 1;
TABLE_NAME
------------------------------
ACCESS$
APPROLE$
ARGUMENT$
ASSEMBLY$
ASSOCIATION$
ATEMPTAB$
ATTRCOL$
ATTRIBUTE$
ATTRIBUTE_TRANSFORMATIONS$
AUD$
AUDIT$
...
Dans la 11g r2, Oracle gère 463 tables système.
SQL> SELECT count(*) FROM DBA_TABLES WHERE TABLE_NAME LIKE '%$';
COUNT(*)
----------
463
Comparaison avec les vues sur ces tables système
Structure d'une de ces tables systèmes, OBJ$, contenant les objets de la base : vous remarquerez que les noms des colonnes ne sont pas très parlants si on compare avec DBA_OBJECTS, vue basée sur OBJ$. C'est normal car Oracle ne veut pas que vous mettiez le nez dans ses tables système mais que vous utilisiez à la place les vues basées dessus, d'où des colonnes au nom et au contenu hermétiques.
SQL> desc OBJ$
Name Null? Type
-----------------------------------------
OBJ# NOT NULL NUMBER
DATAOBJ# NUMBER
OWNER# NOT NULL NUMBER
NAME NOT NULL VARCHAR2(30)
NAMESPACE NOT NULL NUMBER
SUBNAME VARCHAR2(30)
TYPE# NOT NULL NUMBER
CTIME NOT NULL DATE
MTIME NOT NULL DATE
STIME NOT NULL DATE
STATUS NOT NULL NUMBER
REMOTEOWNER VARCHAR2(30)
LINKNAME VARCHAR2(128)
FLAGS NUMBER
OID$ RAW(16)
SPARE1 NUMBER
SPARE2 NUMBER
SPARE3 NUMBER
SPARE4 VARCHAR2(1000)
SPARE5 VARCHAR2(1000)
SPARE6 DATE
SQL> desc dba_objects
Name Null? Type
-------------------------------------------------------
OWNER VARCHAR2(30)
OBJECT_NAME VARCHAR2(128)
SUBOBJECT_NAME VARCHAR2(30)
OBJECT_ID NUMBER
DATA_OBJECT_ID NUMBER
OBJECT_TYPE VARCHAR2(19)
CREATED DATE
LAST_DDL_TIME DATE
TIMESTAMP VARCHAR2(19)
STATUS VARCHAR2(7)
TEMPORARY VARCHAR2(1)
GENERATED VARCHAR2(1)
SECONDARY VARCHAR2(1)
NAMESPACE NUMBER
EDITION_NAME VARCHAR2(30)
============================================================================================
Liste des paramètres cachés en 11g.
============================================================================================
Les paramètres cachés d'Oracle, hidden parameters en anglais, commencent par un underscore _. Leur liste se trouve dans la structure mémoire X$KSPPI avec un court commentaire. L'ordre SQL pour les afficher est :
SQL> SELECT UPPER(KSPPINM) AS "PARAMETER", KSPPDESC AS "DESCRIPTION" FROM X$KSPPI WHERE SUBSTR(KSPPINM,1,1) = '_' ORDER BY 1,2;
PARAMETER DESCRIPTION
----------------------------------------------------------------------------------
_OPTIMIZER_ADAPTIVE_CURSOR_SHARING optimizer adaptive cursor sharing
_OPTIMIZER_ADJUST_FOR_NULLS adjust selectivity for null values
_OPTIMIZER_AUTOSTATS_JOB enable/disable auto stats collection job
_OPTIMIZER_AW_JOIN_PUSH_ENABLED Enables AW Join Push optimization
_OPTIMIZER_BLOCK_SIZE standard block size used by optimizer
_OPTIMIZER_CACHE_STATS cost with cache statistics
_OPTIMIZER_CARTESIAN_ENABLED optimizer cartesian join enabled
...
Dans la 11g r2, Oracle gère 2306 paramètres cachés.
SQL> SELECT count(*) FROM X$KSPPI WHERE SUBSTR(KSPPINM,1,1) = '_';
COUNT(*)
----------
2306
============================================================================================
Liste des structures mémoires X$ appelées Fixed tables.
============================================================================================
Les vues dynamiques de performances V$xxx s'appuient sur des vues GV$xxx qui elles même s'appuient sur des structures mémoires appelées X$xxx.
Utilisons la vue v$fixed_view_definition pour vérifier cela et afficher le code source de ces vues.
Exemple avec la vue V$CONTROLFILE : celle-ci s'appuie bien sur GV$CONTROLFILE.
SQL> select view_name, view_definition from v$fixed_view_definition where view_name like 'V$CONTROLFILE';
VIEW_NAME VIEW_DEFINITION
---------------------------------------------------------------------------
V$CONTROLFILE select STATUS , NAME, IS_RECOVERY_DEST_FILE, BLOCK_SIZE,
FILE_SIZE_BLKS
from GV$CONTROLFILE
where inst_id = USERENV('Instance')
Regardons maintenant la définition de GV$CONTROLFILE : bingo, nous tombons sur x$kcccf!
SQL> select view_name, view_definition from v$fixed_view_definition where view_name like 'GV$CONTROLFILE';
VIEW_NAME VIEW_DEFINITION
------------------------------------------------------------------------
GV$CONTROLFILE select inst_id,decode(bitand(cfflg,1),0,'',1,'INVALID'),cfnam, decode(bitand(cff
l2,1),0,'NO','YES'), cfbsz, cffsz from x$kcccf
La liste de ces structures mémoires X$xxx se trouve dans la vue V$FIXED_TABLE.
SQL> SELECT NAME FROM V$FIXED_TABLE ORDER BY NAME;
NAME
------------------------------
X$KQFCO
X$KQFDT
X$KQFOPT
X$KQFTA
X$KQFVI
X$KQFVT
X$KSDAF
X$KSDAFT
X$KSLECLASS
X$KSLED
X$KSLEMAP
...
Dans la 11g r2, Oracle gère 2002 structures mémoire.
SQL> SELECT count(*) FROM V$FIXED_TABLE;
COUNT(*)
----------
2002
Exemple d'une de ces structures mémoire : X$BH gérant les buffers headers de la base.
Vous remarquerez que les noms des colonnes ne sont pas très parlants si on compare avec V$BH, la vue basée sur X$BH. A nouveau c'est normal puisque Oracle souhaite cacher ces objets et les rendre inutilisables pour le commun des mortels.
SQL> desc X$bh
Name Null? Type
----------------------------------------------------- -----
ADDR RAW(8)
INDX NUMBER
INST_ID NUMBER
HLADDR RAW(8)
BLSIZ NUMBER
NXT_HASH RAW(8)
PRV_HASH RAW(8)
NXT_REPL RAW(8)
PRV_REPL RAW(8)
FLAG NUMBER
FLAG2 NUMBER
LOBID NUMBER
RFLAG NUMBER
SFLAG NUMBER
LRU_FLAG NUMBER
TS# NUMBER
FILE# NUMBER
DBARFIL NUMBER
DBABLK NUMBER
CLASS NUMBER
STATE NUMBER
MODE_HELD NUMBER
CHANGES NUMBER
CSTATE NUMBER
LE_ADDR RAW(8)
DIRTY_QUEUE NUMBER
SET_DS RAW(8)
OBJ NUMBER
BA RAW(8)
CR_SCN_BAS NUMBER
CR_SCN_WRP NUMBER
CR_XID_USN NUMBER
CR_XID_SLT NUMBER
CR_XID_SQN NUMBER
CR_UBA_FIL NUMBER
CR_UBA_BLK NUMBER
CR_UBA_SEQ NUMBER
CR_UBA_REC NUMBER
CR_SFL NUMBER
CR_CLS_BAS NUMBER
CR_CLS_WRP NUMBER
LRBA_SEQ NUMBER
LRBA_BNO NUMBER
HSCN_BAS NUMBER
HSCN_WRP NUMBER
HSUB_SCN NUMBER
US_NXT RAW(8)
US_PRV RAW(8)
WA_NXT RAW(8)
WA_PRV RAW(8)
OQ_NXT RAW(8)
OQ_PRV RAW(8)
AQ_NXT RAW(8)
AQ_PRV RAW(8)
OBJ_FLAG NUMBER
TCH NUMBER
TIM NUMBER
CR_RFCNT NUMBER
SHR_RFCNT NUMBER
SQL> desc v$bh
Name Null? Type
----------------------------------------------------- --------
FILE# NUMBER
BLOCK# NUMBER
CLASS# NUMBER
STATUS VARCHAR2(10)
XNC NUMBER
FORCED_READS NUMBER
FORCED_WRITES NUMBER
LOCK_ELEMENT_ADDR RAW(8)
LOCK_ELEMENT_NAME NUMBER
LOCK_ELEMENT_CLASS NUMBER
DIRTY VARCHAR2(1)
TEMP VARCHAR2(1)
PING VARCHAR2(1)
STALE VARCHAR2(1)
DIRECT VARCHAR2(1)
NEW CHAR(1)
OBJD NUMBER
TS# NUMBER
LOBID NUMBER
CACHEHINT NUMBER
Pour savoir comment leur nom est construit, lisez cet autre article : "Comment le nom des structures mémoires Oracle X$ est construit".
============================================================================================
Liste des packages PL/SQL cachés.
============================================================================================
Oracle propose près de 260 packages PL/SQL documentés dans sa base version 11g r2. La liste est ici : https://docs.oracle.com/cd/E11882_01/appdev.112/e40758/toc.htm
Néanmoins, si on regarde dans la vue DBA_PLSQL_OBJECT_SETTINGS, on a 4671 objets dont 961 packages, soit 700 de plus que dans la liste officielle ci-dessus.
SQL> SELECT count(*) FROM DBA_PLSQL_OBJECT_SETTINGS ;
COUNT(*)
----------
4671
Si on regarde le type de ces objets, on voit qu'il existe le type PACKAGE.
SQL> SELECT distinct type FROM DBA_PLSQL_OBJECT_SETTINGS order by type;
TYPE
------------
FUNCTION
LIBRARY
PACKAGE
PACKAGE BODY
PROCEDURE
TRIGGER
TYPE
TYPE BODY
8 rows selected.
Combien de package dans Oracle? 260 ou plus? On tombe sur le nombre de 961 soit 700 de plus!
SQL> SELECT count(*) FROM DBA_PLSQL_OBJECT_SETTINGS where TYPE = 'PACKAGE';
COUNT(*)
----------
961
Comment savoir lesquels sont des packages cachés? La vue DBA_PLSQL_OBJECT_SETTINGS n'a malheureusement pas d'attribut permettant de répondre à cette question. En revanche, on peut valider le fait que parmi ces packages il y en a bien qui sont cachés car on y trouve DBMS_SYS_SQL qui n'est pas répertorié dans la liste https://docs.oracle.com/cd/E11882_01/appdev.112/e40758/toc.htm.
SQL> SELECT name FROM DBA_PLSQL_OBJECT_SETTINGS where TYPE = 'PACKAGE' AND NAME LIKE 'DBMS_%SQL' order by name;
NAME
------------------------------
DBMS_SQL
DBMS_SYS_SQL
============================================================================================
Liste des hints cachés.
============================================================================================
Oracle propose sur son site une liste de hints utilisables et documentés. Ici se trouve une liste de plus de 120 hints https://docs.oracle.com/database/121/SQLRF/sql_elements006.htm#SQLRF00219.
Néanmoins, dans la vue V$SQL_HINTS introduite en 11gR2, nous en avons 140 autres qui ne sont pas documentés.
SQL> desc v$sql_hint
Nom NULL ? Type
----------------------------------------------------- --------
NAME VARCHAR2(64)
SQL_FEATURE VARCHAR2(64)
CLASS VARCHAR2(64)
INVERSE VARCHAR2(64)
TARGET_LEVEL NUMBER
PROPERTY NUMBER
VERSION VARCHAR2(25)
VERSION_OUTLINE VARCHAR2(25)
SQL> select count(*) from v$sql_hint;
COUNT(*)
----------
263
Voici le nombre de hints par version d'Oracle depuis la 8.
SQL> select version, count(*) from v$sql_hint group by version order by to_number(replace(version,'.', '0'));
VERSION COUNT(*)
------------------------- ----------
8.0.0 14
8.1.0 50
8.1.5 18
8.1.6 4
8.1.7 2
9.0.0 26
9.2.0 13
10.1.0.3 42
10.2.0.1 25
10.2.0.2 4
10.2.0.3 3
10.2.0.4 2
10.2.0.5 2
11.1.0.6 34
11.1.0.7 5
11.2.0.1 19
16 ligne(s) sélectionnée(s).
Les hints VECTOR_READ et SHARED par exemple ne sont pas documentés par Oracle.
SQL> select name, version from v$sql_hint where name = 'VECTOR_READ' OR NAME = 'SHARED' order by name;
NAME VERSION
---------------------------------------------------------------
SHARED 8.1.0
VECTOR_READ 10.1.0.3
Malheureusement, comme pour les packages PL/SQL, aucun indicateur dans la vue ne dit si ces hints sont documentés ou non par Oracle. Il faut donc les vérifier un par un avec la liste officielle du lien ci-dessus.
============================================================================================
Liste des types de données cachés [EDIT 28/02/2017]
============================================================================================
J'ai découvert dernièrement un endroit qui est la caverne d'ali baba pour les DBA : le répertoire des scripts gérant la base Oracle et son dictionnaire de données. Celui-ci se trouve sous $ORACLE_HOME/rdbms/admin et contient, pour une 12.2, 1862 fichiers!
Parmi ceux-ci, le fichier stdspec.sql renferme la définition du package STANDARD qui contient la liste des types internes d'Oracle.
Voici une partie de son contenu : on y découvre que tous les types manipulés pointent en réalité vers des types de données interne à Oracle, DATE_BASE par exemple, NUMBER_BASE, CHAR_BASE etc etc. On y voit aussi les définitions des sous-types, par exemple DECIMAL est un number(38,0) mais aussi, plus amusant, que VARCHAR est un sous-type de VARCHAR2 alors que je pensais que c'était un type en propre. On note que tous les types caractères dérivent de VARCHAR2.
type BOOLEAN is (FALSE, TRUE);
type DATE is DATE_BASE;
type NUMBER is NUMBER_BASE;
subtype FLOAT is NUMBER; -- NUMBER(126)
subtype REAL is FLOAT; -- FLOAT(63)
subtype "DOUBLE PRECISION" is FLOAT;
subtype INTEGER is NUMBER(38,0);
subtype INT is INTEGER;
subtype SMALLINT is NUMBER(38,0);
subtype DECIMAL is NUMBER(38,0);
subtype NUMERIC is DECIMAL;
subtype DEC is DECIMAL;
subtype BINARY_INTEGER is INTEGER range '-2147483647'..2147483647;
subtype NATURAL is BINARY_INTEGER range 0..2147483647;
subtype NATURALN is NATURAL not null;
subtype POSITIVE is BINARY_INTEGER range 1..2147483647;
subtype POSITIVEN is POSITIVE not null;
subtype SIGNTYPE is BINARY_INTEGER range '-1'..1; -- for SIGN functions
type VARCHAR2 is NEW CHAR_BASE;
subtype VARCHAR is VARCHAR2;
subtype STRING is VARCHAR2;
subtype LONG is VARCHAR2(32760);
subtype RAW is VARCHAR2;
subtype "LONG RAW" is RAW(32760);
subtype ROWID is VARCHAR2(256);
-- Ansi fixed-length char
-- Define synonyms for CHAR and CHARN.
subtype CHAR is VARCHAR2;
subtype CHARACTER is CHAR;
type BLOB is BLOB_BASE;
type CLOB is CLOB_BASE;
type BFILE is BFILE_BASE;
-- Verbose and NCHAR type names
subtype "CHARACTER VARYING" is VARCHAR;
subtype "CHAR VARYING" is VARCHAR;
subtype "NATIONAL CHARACTER" is CHAR CHARACTER SET NCHAR_CS;
subtype "NATIONAL CHAR" is CHAR CHARACTER SET NCHAR_CS;
subtype "NCHAR" is CHAR CHARACTER SET NCHAR_CS;
subtype "NATIONAL CHARACTER VARYING" is VARCHAR CHARACTER SET NCHAR_CS;
subtype "NATIONAL CHAR VARYING" is VARCHAR CHARACTER SET NCHAR_CS;
subtype "NCHAR VARYING" is VARCHAR CHARACTER SET NCHAR_CS;
subtype "NVARCHAR2" is VARCHAR2 CHARACTER SET NCHAR_CS;
subtype "CHARACTER LARGE OBJECT" is CLOB;
subtype "CHAR LARGE OBJECT" is CLOB;
subtype "NATIONAL CHARACTER LARGE OBJEC" is CLOB CHARACTER SET NCHAR_CS;
subtype "NCHAR LARGE OBJECT" is CLOB CHARACTER SET NCHAR_CS;
subtype "NCLOB" is CLOB CHARACTER SET NCHAR_CS;
subtype "BINARY LARGE OBJECT" is BLOB;
subtype pls_integer is binary_integer;
type TIME is new DATE_BASE;
type TIMESTAMP is new DATE_BASE;
type "TIME WITH TIME ZONE" is new DATE_BASE;
type "TIMESTAMP WITH TIME ZONE" is new DATE_BASE;
type "INTERVAL YEAR TO MONTH" is new DATE_BASE;
type "INTERVAL DAY TO SECOND" is new DATE_BASE;
SUBTYPE TIME_UNCONSTRAINED IS TIME(9);
SUBTYPE TIME_TZ_UNCONSTRAINED IS TIME(9) WITH TIME ZONE;
SUBTYPE TIMESTAMP_UNCONSTRAINED IS TIMESTAMP(9);
SUBTYPE TIMESTAMP_TZ_UNCONSTRAINED IS TIMESTAMP(9) WITH TIME ZONE;
SUBTYPE YMINTERVAL_UNCONSTRAINED IS INTERVAL YEAR(9) TO MONTH;
SUBTYPE DSINTERVAL_UNCONSTRAINED IS INTERVAL DAY(9) TO SECOND (9);
TYPE UROWID IS NEW CHAR_BASE;
type "TIMESTAMP WITH LOCAL TIME ZONE" is new DATE_BASE;
subtype timestamp_ltz_unconstrained is timestamp(9) with local time zone;
subtype BINARY_FLOAT is NUMBER;
subtype BINARY_DOUBLE is NUMBER;
type "<ADT_1>" as object (dummy char(1));
type "<RECORD_1>" is record (dummy char(1));
type "<TUPLE_1>" as object (dummy char(1));
type "<VARRAY_1>" is varray (1) of char(1);
type "<V2_TABLE_1>" is table of char(1) index by binary_integer;
type "<TABLE_1>" is table of char(1);
type "<COLLECTION_1>" is table of char(1);
type "<REF_CURSOR_1>" is ref cursor;
============================================================================================
Objets construits sur des SELECT avec filtres.
============================================================================================
Oracle peut délibérement choisir de filtrer le résultat des requêtes et de masquer certains enregistrements. Et ce même si on est connecté comme SYS! Exemple avec DBA_ROLES qui est une vue et où, dans l'ordre SELECT constituant cette vue, les deux rôles PUBLIC et _NEXT_USER sont filtrés.
SQL> SET LONG 1000000
SQL> select dbms_metadata.get_ddl('VIEW', 'DBA_ROLES') from dual;
DBMS_METADATA.GET_DDL('VIEW','DBA_ROLES')
--------------------------------------------------------------------------------
CREATE OR REPLACE FORCE NONEDITIONABLE VIEW "SYS"."DBA_ROLES" ("ROLE", "ROLE_I
D", "PASSWORD_REQUIRED", "AUTHENTICATION_TYPE", "COMMON", "ORACLE_MAINTAINED", "
INHERITED", "IMPLICIT") AS
select name, user#,
decode(password, null,
decode(spare4, null, 'NO',
decode(REGEXP_INSTR(spare4, '[ST]:'), 0, 'NO',
'YES')),
'EXTERNAL', 'EXTERNAL',
'GLOBAL', 'GLOBAL',
'YES'),
decode(password, null,
decode(spare4, null, 'NONE',
decode(REGEXP_INSTR(spare4, '[ST]:'), 0, 'NONE',
'PASSWORD')),
'EXTERNAL', 'EXTERNAL',
'GLOBAL', 'GLOBAL',
'APPLICATION', 'APPLICATION',
'PASSWORD'),
decode(bitand(spare1, 4224), 0, 'NO', 'YES'),
decode(bitand(spare1, 256), 256, 'Y', 'N'),
decode(bitand(spare1, 4224),
128, decode(SYS_CONTEXT('USERENV', 'CON_ID'),
1, 'NO', 'YES'),
4224, decode(SYS_CONTEXT('USERENV', 'IS_APPLICATION_PDB'),
'YES', 'YES', 'NO'),
'NO'),
decode(bitand(spare1, 32768), 32768, 'YES', 'NO')
from user$
where type# = 0
and name not in ('PUBLIC', '_NEXT_USER')
============================================================================================
Data Block Header [EDIT 06/05/2020]
============================================================================================
Cette fois l'info ne se trouve pas dans le dictionnaire de données d'Oracle, ni même sur le site d'Oracle. J'avais trouvé cette image sur Google il y a longtemps, je la partage avec vous, avec quand même les réserves suivantes : ce n'est pas un document officiel oracle.
============================================================================================
Les types d'ojets gérés par Oracle [EDIT 06/05/2020]
============================================================================================
Comment savoir quels sont TOUS les types d'objets gérés par Oracle? Aucune vue ne contient cette info, il faut carrément récupérer l'ordre DDL de DBA_OBJECTS pour avoir cette liste.
Je vous renvoie vers ce post : Les types d’objets d'une base de données Oracle - The object types of an Oracle database
============================================================================================
Les outils cachés d'Oracle [EDIT 06/05/2020]
============================================================================================
Et oui, Oracle utilise plein d'outils qui ne sont pas documentés et que nous, DBA, pouvons utiliser; A NOS RISQUES ET PERILS!
Les traces des évènements systèmes
Les traces sont un outil génial pour comprendre le fonctionnement interne d'Oracle, mais aucune doc n'existe pour les comprendre.
Parmi celles-ci, les traces 10046, 10053 sont les plus utilisées.
Une liste complète ici : http://www.juliandyke.com/Diagnostics/Events/EventReference.php
Et une mise en garde : https://asktom.oracle.com/pls/apex/asktom.search?tag=list-of-event-codes-for-traces
"- not supported, not documented, etc etc etc
- events can very destructive, you could destroy a database if used incorrectly."
Voici un exemple de trace 10053 trouvé sur le net pour une table ayant des statistiques étendues sur deux colonnes liées. Chercher la chaîne CorStregth pour voir la relation entre deux colonnes pour lesquelles des stats étendues ont été créées.
The corresponding 10053 trace file excerpt shows:
SINGLE TABLE ACCESS PATH
Single Table Cardinality Estimation for Y1[Y1]
Column (#1):
NewDensity:0.050000, OldDensity:0.000050 BktCnt:10000, PopBktCnt:10000, PopValCnt:10, NDV:10
Column (#2):
NewDensity:0.100000, OldDensity:0.000050 BktCnt:10000, PopBktCnt:10000, PopValCnt:5, NDV:5
ColGroup (#1, Index) Y1_I1
Col#: 1 2 CorStregth: 5.00
ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
Le rapport AWR
Eh oui, le fameux rapport AWR n'est pas documenté par Oracle... Oracle nous explique ce qu'est AWR (et encore heureux puisqu'il fait partie du Diagnostic Pack) MAIS aucune info sur le rapport. D'après ce que j'avais entendu, il était utilisé par le support Oracle (d'où la quantité faramineuse d'infos dedans) mais il n'était pas prévu d'y donner accès aux utilisateurs. Et puis finalement ceux-ci s'en sont emparés, l'objet est très utile pour analyser ce qui se passe sur une base MAIS Oracle ne vous explique pas comment l'utiliser... c'est bien dommage :-(
Oradebug
ATTENTION, outil dangereux! A nouveau il n'est pas documenté apr Oracle et vous risquez de corrompre votre base. Certaines personnes le présentent, comme son nom l'indique, comme un outil de déboggage. Il est souvent utilisé pour faire un dump d'un bloc de données ou d'index et voir ce qu'il y a à l'intérieur.
Une bonne présentation ici : http://www.juliandyke.com/Diagnostics/Tools/ORADEBUG/ORADEBUG.php
Contenu d'un dump de bloc
Sous Oracle il est possible de faire un dump d'un bloc de données : soit un data block soit un bloc d'index (feuille ou branche ou racine). Le problème sera d'interpréter le résultat car Oracle ne documente pas les données extraites.
Exemple de dump
SQL> insert into test(a) values (1000000000);
SQL> insert into test(a) values(1999999999);
SQL> commit;
SQL> Select file_id, relative_fno, extent_id, block_id, blocks
from dba_extents
where segment_name = 'TEST'
And owner = 'MNI';
FILE_ID RELATIVE_FNO EXTENT_ID BLOCK_ID BLOCKS
---------- ------------ ---------- ---------- ----------
4 4 0 1029224 8
La génération du dump proprement dit :
SQL> alter system dump datafile 4 block min 1029231 block max 1029231;
Puis on affiche le contenu du fichier dump généré : amusez-vous bien avec Google pour comprendre de quoi il s'agit...
block_row_dump:
tab 0, row 0, @0x1f92
tl: 6 fb: --H-FL-- lb: 0x1 cc: 1
col 0: [ 2] c5 0b
tab 0, row 1, @0x1f88
tl: 10 fb: --H-FL-- lb: 0x1 cc: 1
col 0: [ 6] c5 14 64 64 64 64
end_of_block_dump
/https%3A%2F%2Fassets.over-blog.com%2Ft%2Fcedistic%2Fcamera.png)
/https%3A%2F%2Fprofilepics.canalblog.com%2Fprofilepics%2F1%2F5%2F1555182.jpg)