Dump des fichiers Redo

Date de publication : le 26 Septembre 2006

Cet article vous montre les multiples possibilités qu'offrait Oracle d'exporter les informations des fichiers REDO

I. Introduction
II. Notions Internes
A. Le vecteur de changement
B. L'enregistrement redo
C. RBA
D. DBA
E. Opcode
1. Opérations sur les Lignes (Row Operations)
2. Opérations sur les transactions
3. Opérations sur les Indexes
4. Block Cleanout
5. Opérations du Hot Backup
6. Opérations sur les écritures de blocs
7. Opérations sur le Direct Loads
III. Décharge du fichier de journalisation
A. Dump basé sur le DBA (Data Block Address)
B. Dump basé sur le RBA (Redo Block Address)
C. Dump basé sur le temps
D. Dump basé sur le SCN
E. Dump basé sur la couche et l'opcode
F. Dump du fichier de journalisation en entier
G. Décharge de l'entête des fichiers de journalisations
IV. Contenu d'un fichier de journalisation
A. L'entête d'un fichier de journalisation
V. Exemples
A. Exemples sur un cas de corruption
B. Exemples sur cas de perte de données

Attention, Certains commandes peuvent endommager vos bases de données si vous ne maitrisez pas le concept interne d'Oracle.

I. Introduction

Les fichiers de journalisation gardent des informations sur les undo et les redo à chaque modification atomique de la base. Ces informations sont enregistrées comme des opcodes, qui sont normalement de la forme code.operation . Par exemple, l'opcode 4.1 désigne l'opération de nettoyage du bloc dans la couche transaction du bloc.

La décharge d'un fichier de journalisation est normalement demandé par le support oracle pour analyser les corruptions de données (corruption logique). Il peut être utiliser comme un utilitaire d'audit. Par exemple, si on veut connaître l'heure et la date des extents alloués pour un segment, on peut décharger l'opcode approprié de l'allocation d'extent à partir d'un ensemble de redo ou de fichiers d'archives et obtenir des détails qu'on ne le trouve nulle part dans le dictionnaire de données.

II. Notions Internes

A. Le vecteur de changement

Le vecteur de changement décrit un changement d'un simple bloc de données. Il peut être appliqué sur

Les entêtes UNDO
Les blocs Undo
L'entête du segmenet de données
Les blocs de données

Il est crée dans le PGA avant que le tampon du bloc de données soit modifié.

Il est constitué de :

L'entête
Un tableau contenant les longueurs des enregistrement modifiés (change record)
Un tableau d'enregistrements modifiés

Chaque vecteur de changement à un entête et voici un exemple :

CHANGE #2 TYP:0 CLS:25 AFN:2 DBA:0x00800049 OBJ:4294967295 SCN:0x0000.001b79d1 SEQ:  2 OP:5.2
ktudh redo: slt: 0x0015 sqn: 0x00000235 flg: 0x0012 siz: 180 fbi: 0
            uba: 0x008002f0.01f7.3a    pxid:  0x0000.000.00000000

Dans l'entête on a :

CHANGE	le numéro de changement
TYP	Type de changement
CLS	Classe
AFN	Numéro Absolue du fichier
DBA	L'addresse Relative du Bloc
SCN	System Change Number
SEQ	Numéro de Sequence (relative au SCN)
OP	Le Code de l'Opération

La classe dans l'entête d'enregistrement est equivalente à CLASS dans la table système X$BH.

Class	Déscription
1	Data Block
2	Sort Block
3	Save Undo Block
4	Segment Header
5	Save Undo Header
6	Free List
7	Extent Map
8	1 st level bmb
9	2 nd level bmb
10	3 rd level bmb
11	Bit Map Block
12	Bitmap Index Block
13	File Header Block
14	unused
15	System Undo Header
16	System Undo Block
17	Undo Header
18	Undo Block

B. L'enregistrement redo

Un enregistrement redo est constitué :

d'un entête
d'un ou plusieurs vecteurs de changements

Chaque enregistrement redo contient un undo et un redo pour une modification atomique, et certains changements n'ont pas besoin d'un undo.

Exemple de l'entête d'un enregistrement redo :

REDO RECORD - Thread:1 RBA: 0x003667.000000cf.0011 LEN: 0x019c VLD: 0x01
SCN: 0x0000.00eb1279 SUBSCN:  1 05/08/2006 16:44:12

L'entête contient :

le numéro de thread
le RBA
Longueur de l'enregistrement en octect et 0x019c = 412 octect
la date et l'heure de changement

C. RBA

L'emplacement de chaque entrée redo est identifié par un RBA qui est constitués de trois parties :

Le numéro de séquence du fichier redo (4 octets)
Le numéro de bloc dans le fichier redo (4 octets)
L'offset dans ce bloc (2 octets)

pour le RBA: 0x000047.000018b8.003c

Les RBA ne sont pas nécessairement uniques dans leurs thread, car le numéro de séquence peut être initialisé à 1 si la base est ouverte avec l'option RESETLOGS.

La notion du RBA est utilisée dans différentes façons, par exemple : low RBA, High RBA, checkpoint RBA, on-disk RBA, sync RBA.

D. DBA

Chaque bloc de la base est identifié uniquement par un DBA (Adresse du Bloc de Données, il ne faut pas confondre avec l'administrateur de bases de données) qui est constitué du numéro du fichier de données et du numéro du bloc dans le fichier de données.

Pour calculer le DBA d'un bloc qui se trouve dans un fichier de donnée, on utilise la fonction make_data_block_address du paquetage dbms_utility.

Par exemple pour calculer le dba du bloc 7 dans le fichier de donnée 5

SQL> select dbms_utility.make_data_block_address( 5, 7) from dual;

DBMS_UTILITY.MAKE_DATA_BLOCK_ADDRESS(5,7)
-----------------------------------------
                                 20971527

Après, Il faut convertir la valeur trouvée en Hexadécimal

SQL> select to_char(dbms_utility.make_data_block_address( 5, 7),'xxxxxxxx') from dual;

TO_CHAR(D
---------
  1400007

Donc le DBA du bloc 7 dans le fichier de donnée 5 est 1400007

Supposons qu'on connaît le DBA et on veut trouver le numéro du bloc et le numéro du fichier de données.

Prenons comme DBA la valeur 1400007

Sa valeur en décimal

SQL> select to_number('1400007','xxxxxxxx') from dual;

TO_NUMBER('1400007','XXXXXXXX')
-------------------------------
                       20971527

Le numéro du bloc

SQL> select DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK (20971527) from dual;

DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(20971527)
-----------------------------------------------
                                              7

Le numéro du fichier de données

SQL> select DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE (20971527) from dual;

DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(20971527)
----------------------------------------------
                                             5

Donc, pour décharger tous les enregistrements redo dans un rangée de blocs de données specifié par file# et bloc#..

A partir de SQL, en lance la commande suivante :

ALTER SYSTEM DUMP LOGFILE 'filename'  
 DBA MIN fileno . blockno  
   DBA MAX fileno . blockno;

Exemple:

        ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V10.2/dbs/arch1_76.dbf'  
        DBA MIN 5 . 31125  
        DBA MAX 5 . 31150;

E. Opcode

Chaque changement est representé par une opération dans le fichier de journalisation, et chaque opération est representée par une couche et un code de l'opération.

On cite ici certains couches :

Couche	Description
4	Block cleanout
5	Transaction Management
10	Index Operations
11	Row Operations
13	Segment Management
14	Extent Management
17	Tablespace Management
18	Block Image (Hot Backups)
19	Direct Loader
20	Compatibility Segment
22	Locally Managed Tablespace
23	Block Writes
24	DDL Statements

1. Opérations sur les Lignes (Row Operations)

Les opération sur les lignes sont generés par la couche 11, on a :

Opcode	Mnemonic	Signification	Description
11.2	IRP	single Insert Row Piece	Insert Single Row
11.3	DRP	Delete Row Piece	Delete Single Row
11.4	LKR	LocK Piece	Lock Row
11.5	URP	Update Row Piece	Update Row
11.6	ORP	Overwrite Row Piece	Chained Row
11.9	CKI	Cluster Key Index	Cluster key index
11.10	SKL	Set cluster Key	Set cluster key pointers
11.11	QMI	Quick Multi-row Insert	Insert Multiple Rows
11.12	QMD	Quick Multi-row Delete	Delete Multiple Rows

A. Insertion d'une simple ligne

B. Insertion multi-lignes

D. Mise à jours d'une seule ligne

Quand un utilisateur fait une mise à jours d'une ligne sur une table, Oracle insère une entrée dans l'entête du bloc de données en indiquent quelle partie du bloc à été modifié et quel segment rollback tient l'information undo. Si un autre utilisateur exécute une requête qui lit ce même bloc avant que le premier utilisateur à valider sa modification, la requête du deuxième utilisateur regarde dans le segment rollback qui lui fournit les données avant la validation.

E. Mise à jours multi-lignes

F. Suppression d'une seule ligne

G. Suppression multi-lignes

H. Select for update pour une seule ligne

L'expression SELECT FOR UPDATE dans une requêtte génère des entrées redo car Oracle doit créer des verrous pour réserver les lignes demandés pour une mise à jours.

I. Select for update pour plusieurs lignes

J. ROLLBACK

2. Opérations sur les transactions

3. Opérations sur les Indexes

Les opérations sur les indexes sont génèrés par la caouche 10.

Opcode	Description
10.2	Insert Leaf Row
10.3	Purge Leaf Row
10.4	Delete Leaf Row
10.5	Restore Leaf Log
10.6	Lock block
10.7	Clear block opcode on commit
10.8	Initialise header
10.9	Apply XAT do to ITL 1
10.10	Set leaf block next pointer
10.11	Set leaf block previous pointer
10.12	Initialize root block after split
10.13	Make leaf block empty
10.15	Insert branch row
10.16	Purge branch row
10.18	Update key data in ow
10.19	Clear split flag
10.21	Undo branch operation
10.22	Undo leaf operation
10.24	Shrink ITL
10.30	Update nonkey value
10.31	Create/Load Index
10.34	Make leaf block embty

A. Insertion dans une table indexé

B. Mise à jours dans une table indexé

A. Suppression dans une table indexé

4. Block Cleanout

Quand l'utilisateur valide une transaction, Oracle mis à jours l'entête du segment rollback. Oracle essaye aussi de trouver les blocs de données c.a.d modifié par la transaction et mis à jours l'entête dans les blocs pour indiquer que la modification à été bien validé. Ce qu'on appelle une validation cleanout. Oracle garde une courte liste de blocs de données affectées par chaque transaction pour connaître quels blocs ont besoins d'un cleanout au moment de la validation.

Si une transaction met à jours trop de blocs pour qu'oracle les gardent dans sa liste courte ou si le bloc modifé n'est plus dans le buffer cache au moment de la validation ou si le bloc est dans le buffer cache mais verrouillé par une autre session, alors oracle ne doit pas nettoyer tous les blocs affectés au moment de la validation. On appelle cela commit cleanout failures.

Si oracle échoue de nettoyer l'entête du bloc au moment de la validation, alors ce bloc de donnée doit incorrectement indiquer que cette portion de bloc à été mis à jours par une transaction non validé. La prochaine fois qu'oracle lit ce bloc de donnée, il devrait détecter une incohérence dans l'entête du bloc et le corrige. C'est le delayed block cleanout. Si Oracle découvre une telle condition en traitant une requête, par exemple, alors il interrompe le traitement de la requête pour effectuer le delayed block cleanout. Cela génère des entrées redo et ralenti l'exécution de la requête.

Cela explique qu'une simple opération de lecture , par exemple SELECT, peut générer des entrées redo.

Supposons que le chargement d'une table T1 de 100Mo par un import prend 10mn. La première SELECT COUNT(*) FROM T1 dure 15mn et la même requête après, dure 2mn. Beaucoup de personne se trompe en pensant que toutes cette attente vient seulement que la table n'a pas été mise en cache.

On crée la table DVP3.

create table dvp3 ( c char(2000), y char(2000), z char(2000));

On active la trace des statistqiues.

set autotrace traceonly statistics ;

On insère 500 lignes dans la table DVP3.

insert into dvp3 select 'x', 'y', 'z' from all_objects where rownum  500;
Statistiques
----------------------------------------------------------
       2199  recursive calls
       3984  db block gets
       2408  consistent gets
         14  physical reads
    3291012  redo size
        671  bytes sent via SQL*Net to client
        606  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
         40  sorts (memory)
          0  sorts (disk)
        500  rows processed
commit;

Dans la première requête la taille des redo génèrés est de 536.

select * from dvp3;
Statistiques
----------------------------------------------------------
         29  recursive calls
          1  db block gets
        613  consistent gets
          0  physical reads
        536  redo size
    3024334  bytes sent via SQL*Net to client
        744  bytes received via SQL*Net from client
         35  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        500  rows processed

Dans la deuxième requête la taille des redo génèrés est 0.

select * from dvp3;
Statistiques
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        537  consistent gets
          0  physical reads
          0  redo size
    3024334  bytes sent via SQL*Net to client
        744  bytes received via SQL*Net from client
         35  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        500  rows processed
set autotrace off

5. Opérations du Hot Backup

Pendant la sauvegarde à chaud, des informations supplementaires sont enregistrés dans le fichier de journalisation en ligne.

ALTER TABLESPACE dvp  BEGIN BECKUP;

La première fois qu'un bloc à été modifié dans un fichier de données en mode hot backup, le bloc en entier est écrits dans le fichier de journalisation, et non seulement les octets modifiés c.a.d les redo vector. Car, on peut se trouver dans la situation où le processus de sauvegarde est entrain de copier le fichier de données et en même temps DBWR écrit simultanement dans le même bloc. L'opcode est 18.1

A chaque fichier de données d'un tablespace, correspond un enregistrement redo contenant son numéro de fichier de données et son SCN de BEGIN BACKUP. Dans mon exemple, j'ai deux enregistrements redo pour le BEGIN BACKUP.

REDO RECORD - Thread:1 RBA: 0x000047.000018b8.003c LEN: 0x2024 VLD: 0x01
SCN: 0x0000.001f1add SUBSCN:  1 10/13/2006 17:04:13
CHANGE #1 TYP:3 CLS: 1 AFN:6 DBA:0x01800815 OBJ:53556 SCN:0x0000.001d477d SEQ:  2 OP:18.1

REDO RECORD - Thread:1 RBA: 0x000047.000018dd.0010 LEN: 0x2050 VLD: 0x05
SCN: 0x0000.001f1ae0 SUBSCN:  1 10/13/2006 17:04:16
CHANGE #1 TYP:3 CLS: 1 AFN:6 DBA:0x0180081c OBJ:53557 SCN:0x0000.001d477d SEQ:  2 OP:18.1

Le premier, concerne ma table DVP ayant pour numéro d'objet : 53556 et le deuxième, concerne l'index de DVP ayant pour numéro d'objet : 533557. On peut utiliser la vue ALL_OBJECTS :

SQL> select owner, object_name, object_type from all_objects where object_id=53556;

OWNER  OBJECT_NAME       OBJECT_TYPE
------ ------------      -----------
DVP    T1                TABLE

SQL> select owner, object_name, object_type from all_objects where object_id=53556;

OWNER  OBJECT_NAME       OBJECT_TYPE
------ ------------      -----------
DVP    XNUM1             INDEX

Quand le mode de sauvegade est désactivé, un marqueur fin de sauvegarde est écrit dans le fichier de journalisation (17.1).

ALTER TABLESPACE dvp END BACKUP;

REDO RECORD - Thread:1 RBA: 0x000047.00001e44.00b4 LEN: 0x0044 VLD: 0x01
SCN: 0x0000.001f2100 SUBSCN:  1 10/13/2006 17:53:50
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:  0 OP:17.1
End backup marker - file:6 scn:  0x0000.001f19ed

6. Opérations sur les écritures de blocs

Depuis Oracle 9.0.1 les blocs écrits depuis le buffer cache vers le disque par le processus DBWR sont écrites dans les fichiers de journalisations.

REDO RECORD - Thread:1 RBA: 0x000047.0000018f.0010 LEN: 0x0080 VLD: 0x06
SCN: 0x0000.001f0ddb SUBSCN:  1 10/13/2006 15:59:57
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:  0 OP:23.1
 Block Written - afn: 2 rdba: 0x008000fd BFT:(1024,8388861) non-BFT:(2,253)
                   scn: 0x0000.001f0dbf seq: 0x11 flg:0x04
 Block Written - afn: 2 rdba: 0x008000fe BFT:(1024,8388862) non-BFT:(2,254)
                   scn: 0x0000.001f0dd3 seq: 0x04 flg:0x04

7. Opérations sur le Direct Loads

Si le mode d'archivage est activé, les blocs du direct load sont écrites dans les fichiers de journalisation. Dans Oracle 9.2, chaque bloc exige les changements 19.1 et 24.2

Les Chargements Direct (Direct Loads) ne peuvent pas être reconstruits, suite au minimum information contenus dans les fichiers de journalisations.

REDO RECORD - Thread:1 RBA: 0x000047.000016d5.0040 LEN: 0x2024 VLD: 0x01
SCN: 0x0000.001f1a73 SUBSCN:  1 10/13/2006 17:01:05
CHANGE #1 TYP:1 CLS: 1 AFN:3 DBA:0x00c06f80 OBJ:8939 SCN:0x0000.001f1a73 SEQ:  1 OP:19.1
Direct Loader block redo entry
Long field block dump:
Object Id     8939 
LobId: 00010001DB9C PageNo        0 
Version: 0x0000.00000001  pdba: 12611449

Ici, on voit bien que le LOB passe bien par un chargement direct.

III. Décharge du fichier de journalisation

A. Dump basé sur le DBA (Data Block Address)

Donc, pour décharger tous les enregistrements redo dans un rangée de blocs de données specifié par file# et bloc#..

A partir de SQL, en lance la commande suivante :

ALTER SYSTEM DUMP LOGFILE 'filename'  
 DBA MIN fileno . blockno  
   DBA MAX fileno . blockno;

Exemple:

        ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V10.2/dbs/arch1_76.dbf'  
        DBA MIN 5 . 31125  
        DBA MAX 5 . 31150;

B. Dump basé sur le RBA (Redo Block Address)

Ici, on décharge tous les enregistrements redo entre deux adresses redo spécifiés par un numéro de séquence et un numéro de bloc.

ALTER SYSTEM DUMP LOGFILE 'filename'  
   RBA MIN seqno . blockno  
   RBA MAX seqno . blockno;

Example:

ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V10.2/dbs/arch1_76.dbf'  
   RBA MIN 2050 . 13255  
   RBA MAX 2255 . 15555;

C. Dump basé sur le temps

Cette option devrait provoquer la décharge des enregistrements redo crées entre deux dates.

Pour décharger le fichier redo suivant les dates, on utilise la commande suivante :

ALTER SYSTEM DUMP LOGFILE 'filename'  
   TIME MIN value  
   TIME MAX value;

Par exemple:

        ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V10.2/dbs/arch1_76.dbf'  
        TIME MIN 299425687  
        TIME MAX 299458800;

La date est donnée dans la REDO DUMP TIME.

time = (((((yyyy - 1988)) * 12 + mm - 1) * 31 + dd - 1) * 24 + hh) * 60 + mi) * 60 + ss;

YYYY	année
mm	mois	01-12
dd	jours	01-31
hh	heure	00-23
mi	minute	00-59
ss	seconde	00-59

D. Dump basé sur le SCN

Cette option, consiste à décharger les enregistrements redo possédant un SCN rangée entre minscn et maxscn.

ALTER SYSTEM DUMP LOGFILE 'nom du fichier de journalisation'
SCN MIN minscn
SCN MAX maxscn;

E. Dump basé sur la couche et l'opcode

LAYER et OPCODE sont utilisés pour décharger tous les enregistrements d'un type particulier.

Depuis la commande SQL :

ALTER SYSTEM DUMP LOGFILE 'filename'  
   LAYER value  
   OPCODE value;

Par exemple:

        ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V10.2/dbs/arch1_76.dbf'  
        LAYER 11  
        OPCODE 3;

F. Dump du fichier de journalisation en entier

A partir de SQL on peut lancer la commande suivante :

ALTER SYSTEM DUMP LOGFILE 'filename';

Il faut entrer le nom complet du fichier redo entre les simples quotes.

Par exemple:

 ALTER SYSTEM DUMP LOGFILE 'u01/oracle/V10.2/dbs/arch1_76.dbf';

G. Décharge de l'entête des fichiers de journalisations

Cette commande décharge les informations des entêtes de tous les fichiers redo en ligne.

A partir de SQL :

alter session set events 'immediate trace name redohdr level 10';

La commande décharge les entêtes de tous les fichiers journaux

IV. Contenu d'un fichier de journalisation

A. L'entête d'un fichier de journalisation

DUMP OF LOG FILES: 3 logs in database
LOG FILE #1: 
  (name #3) D:\ORACLE\PRODUCT\10.2.0\ORADATA\B10G2\REDO01.LOG
 Thread 1 redo log links: forward: 2 backward: 0
 siz: 0x19000 seq: 0x00000053 hws: 0x4 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00315ef2
 Low scn: 0x0000.0031b9a8 10/23/2005 00:40:37
 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
 FILE HEADER:
	Compatibility Vsn = 169869568=0xa200100
	Db ID=1483236283=0x586863bb, Db Name='B10G2'
	Activation ID=1483223739=0x586832bb
	Control Seq=2084=0x824, File size=102400=0x19000
	File Number=1, Blksiz=512, File Type=2 LOG
 descrip:"Thread 0001, Seq# 0000000083, SCN 0x00000031b9a8-0xffffffffffff"
 thread: 1 nab: 0xffffffff seq: 0x00000053 hws: 0x4 eot: 1 dis: 0
 reset logs count: 0x21d964be scn: 0x0000.00085bc4
 Low scn: 0x0000.0031b9a8 10/23/2005 00:40:37
 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
 Enabled scn: 0x0000.00085bc4 09/01/2005 20:40:30
 Thread closed scn: 0x0000.0031fb40 10/23/2005 08:58:17
 Disk cksum: 0x5c30 Calc cksum: 0x5c30
 Terminal Recovery Stop scn: 0x0000.00000000
 Terminal Recovery Stamp  01/01/1988 00:00:00
 Most recent redo scn: 0x0000.00000000
 Largest LWN: 0 blocks
 Miscellaneous flags: 0x0
 Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000

V. Exemples

A. Exemples sur un cas de corruption

B. Exemples sur cas de perte de données

Supposons qu'un utilisateur à supprimer une table qui n'a pas été sauvegardé la nuit précédente. Pris de panique pendant un certain temps avant d'appeler le DBA.

La solution, est d'arrêter la base proprement, de restaurer la base juste avant la suppression de la table, de faire l'export de la table, de continuer la restauration jusqu'à que tous les redologs sont appliqués et enfin importer la table.

Ainsi, on a besoin de connaître exactement le SCN qui a provoqué la suppression de la table.

On décharge le fichier redolog, en limitant le fichier dump dans la période qui nous intéresses. Avec un éditeur, on visualise le fichier dump et on cherche l'opération DDL qui a supprimé la table.

Quand on exécute une opération DDL, Oracle effectue des opérations DML sur les tables de dictionnaires de données : FET$, UET$ et OBJ$. La table OBJ$ nous intéresse, car il contient le nom de l'objet, et dans notre cas c'est la table SALES_DATA.

On peut trouver OBJ# de la table OBJ$ en utilisant la requête suivante :

Select obj# from obj$ where name='OBJ$' ;
OBJ#
3202

1 row selected.

Si on effectue un describe de la table OBJ#, le nom de l'objet se trouvera dans la quatrième colonne avec un type VARCHAR2. Donc, on est entrains de chercher les opérations sur l'objet 3202 ou la colonne 4 contient le string 'SALES_DATA', en hexadécimal est : 53 41 4c 45 53 5f 44 41 54 41.

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.