Parsing rowid in block dump

In a blockdump a rowid is represented like 01 00 03 00 00 00.
I think I have found that this is parsed as file 010 block 00300 and row 0000. That makes sense for block and row. For file I think I've pieced together some info which would indicate that file 010 would point to file 4. The way this supposedly happens is that 010 is divided by four. Since 010 hex is 16 decimal and 16/4=4.
That is all good, but can anyone explain why it is done this way, what the other values for files are used for and if there is any known documentation for this effect.
My understanding then for that rowid is that it points to file 4, block 768 and row 0. That is exactly where it should point so that part is god. I just want to understand the file calculation better.

Similar Messages

ORACLE7/ORACLE8/OS에서 DATAFILE의 BLOCK DUMP를 얻는 방법

제품 : ORACLE SERVER
작성날짜 : 1999-05-24
Oracle7 / Oracle8 / OS에서 datafile의 block dump를 얻는 방법
'block dump'는 database 내의 block의 내용을 dump받도록 해준다.
이렇게 얻어진 dump에는 block 내에 포함된 모든 내용을 포함하는데 단, 이것은
OS level의 image dump는 아니며, oracle에서 user가 이해하는 데 도움이 되도록
정해진 SYMBOL로 표현되므로 이렇게 얻어진 내용을 해석하기 위해서는
Oracle에 dependent하며, 별도의 자료를 참조하여야 한다.
여기에서는 해석 방법은 포함하지 않으며 dump를 얻는 방법에 대해서만 기술하였다.
1. Oracle7에서 block dump 사용하는 방법
oracle7에서 block dump를 얻기 위해서는 항상 database가 OPEN 상태에서만 가
능하며, datafile도 ONLINE 상태여야 한다.
(1) dump하고자 하는 block의 DBA를 십진수 값으로 얻는다.
file 번호와 block 번호를 이용해 DBA를 얻는 방법은 <Bulletin:11508>을
이용한다.
(2) 다음 문장을 실행하여 dump 내용을 포함하는 trace file을 생성한다.
sqlplus system/manager
SQL>alter session set events 'immediate trace name BLOCKDUMP level <DBA>';
(3) 다음과 같이 trace file이 생성된 위치를 확인한다.
os>svrmgrl
SVRMGR>connect internal
SVRMGR>show parameter user_dump_dest
2. Oracle8 에서 BLOCK DUMP
Oracle7에서는 block dump를 얻기 위해서는 DBA를 얻어야하고 DBA를 이용하여
dump를 생성하는 sql 문의 syntax도 친숙하지 않은 것이었다. Oracle8에서는
보다 간단하고 사용자에게 익숙한 형태로 block dump가 가능하도록 하였다.
sqlplus로 접속한 상태에서 아래에 나열된 것과 같이 file 이름이나 번호,
block 번호나 범위를 지정하여 dump를 얻을 수 있다.
- ALTER SYSTEM DUMP DATAFILE {'filename'}|{filenumber};
- ALTER SYSTEM DUMP DATAFILE {'filename'}|{filenumber} BLOCK {blockno};
- ALTER SYSTEM DUMP DATAFILE {'filename'}|{filenumber} BLOCK MIN {blockno}
BLOCK MAX {blockno};
여기에서 blockno는 dump하고자 하는 block의 십진수 값이다.
예를 들어 다음과 같이 하면 된다.
- ALTER SYSTEM DUMP DATAFILE 1 BLOCK 5586;
- ALTER SYSTEM DUMP DATAFILE 1 BLOCK MIN 5585 BLOCK MAX 5586;
- ALTER SYSTEM DUMP DATAFILE '/u01/oradata/MYDB/system01.dbf' BLOCK 98;
주의: 그런데 이 때 잘못된 block file number를 입력하는 등의 잘못된 명령에도
불구하고 'Statement processed'라는 정상 처리 형태의 메시지가 나타난다.
이러한 경우 trace file에는 dump 내용 대신 다음과 같은 오류 메시지가
적혀 있다.
Error: alter system dump datafile: input file # 100 is too big
BLOCK 절을 생략하면 datafile의 모든 block에 대해서 dump가 생성된다.
이 때 trace file의 크기는 MAX_DUMP_FILE_SIZE에 의해 제한을 받으므로 전체
block을 모두 포함하지 않는 dump가 생성될 수 있다.
{filenumber} 를 사용할 때에는 database는 항상 OPEN된 상태이고 file은 ONLINE
이어야 한다. 그리고 이 때의 {filenumber}는 tablespace 내의 상대적인 값이 아닌,
절대적인 값이어야 한다.
'filename' 을 사용하면 같은 block size를 가지고 있는 다른 데이타베이스의
데이타화일도 dump를 할 수 있다. 이러한 경우에 dump를 수행하는 instance는
최소한nomount는 되어야 한다. 즉 다음과 같이 하면 된다.
SVRMGR>startup nomount
SVRMGR>alter system dump datafile mnt3/rctest73/server/eykim/test01.dbf'
block 88;
dump의 결과가 저장되는 trace 화일은 USER_DUMP_DEST 디렉토리에 생성된다.
USER_DUMP_DEST를 확인하는 방법은 1-(3)번(Oracle7)에서 기술하였다.
3. OS block dump
UNIX: dd if=dbfile.dbf bs=2k skip={block} count=1 | od -x > dump.out
여기에서 {block}은 dump 하지 않기 위해 skip하고자 하는 block의 갯
수를 지정한다.
NT: 다음과 같은 제품들이 사용가능하다.
MKS Toolkit , FileView (Shareware), HEdit

Interpreting an index data block dump

I have seen a few postings about reading index data blocks, mine doesnt quite look like those.
Ok: 11Gr1 (linux)
Tracing down a hot block issue with an index, I performed
alter system dump datafile 11 block 4030208;
Looking at the Web page "Index Block Dump: Index Only Section Part II (Station To Station)" and others they show a dump like this:
row#0[8021] flag: ——, lock: 0, len=15
col 0; len 5; (5): 42 4f 57 49 45
col 1; len 6; (6): 02 01 48 8a 00 00
row#1[8002] flag: ——, lock: 0, len=19
col 0; len 9; (9): 4d 41 4a 4f 52 20 54 4f 4d
col 1; len 6; (6): 02 01 48 8a 00 02
row#2[7987] flag: ——, lock: 0, len=15
col 0; len 5; (5): 5a 49 47 47 59
col 1; len 6; (6): 02 01 48 8a 00 01
—– end of leaf block dump —–
End dump data blocks tsn: 8 file#: 8 minblk 84234 maxblk 84234
I dont see anything that "obvious" in my dump. Am I looking at something other then an leaf block perhaps?
I am expecting/hoping to see some sort of pairs for an index like X(y number, z number)
Block dump from cache:
Dump of buffer cache at level 4 for tsn=6, rdba=50167552
BH (0x275f2aec8) file#: 11 rdba: 0x02fd7f00 (11/4030208) class: 4 ba: 0x274992000
set: 111 bsz: 8192 bsi: 0 sflg: 0 pwc: 0, 25 lid: 0x00000000,0x00000000
dbwrid: 2 obj: 127499 objn: 77784 tsn: 6 afn: 11
hash: [0x403d34650,0x403d34650] lru: [0x333f32878,0x209f4ea88]
lru-flags: hot_buffer
ckptq: [NULL] fileq: [NULL] objq: [0x22dede3f8,0x30ff9c3f8]
st: XCURRENT md: NULL tch: 2
flags: block_written_once redo_since_read gotten_in_current_mode
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [34]
cr pin refcnt: 0 sh pin refcnt: 0
buffer tsn: 6 rdba: 0x02fd7f00 (11/4030208)
scn: 0x0001.19bccf84 seq: 0x02 flg: 0x04 tail: 0xcf841002
frmt: 0x02 chkval: 0x987f type: 0x10=DATA SEGMENT HEADER - UNLIMITED
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x0000000274992000 to 0x0000000274994000
274992000 0000A210 02FD7F00 19BCCF84 04020001 [................]
274993FF0 00000000 00000000 00000000 CF841002 [................]
Extent Control Header
Extent Header:: spare1: 0      spare2: 0      #extents: 66     #blocks: 10239
                  last map 0x00000000 #maps: 0      offset: 4128
      Highwater:: 0x047feb5b ext#: 65     blk#: 731    ext size: 1024
#blocks in seg. hdr's freelists: 0
#blocks below: 9946
mapblk 0x00000000 offset: 65
                   Unlocked
     Map Header:: next 0x00000000 #extents: 66   obj#: 127499 flag: 0x40000000
Extent Map
   0x02fd7f01 length: 127
   0x0339ea80 length: 128
...

Some time ago, I wrote a python script to print decimal form integer values from an index block dump. I don't know if it will help you, but it may be a start. It only prints the integer equivalent of the first column in the index, as that is what I needed at the time.
It is called as...
18:55:31 oracle@oh1xcwcdb01 /u02/admin/wcperf/udump >./blockdump.py wcperf1_ora_21618.trc
col 0: [ 4] c4 48 2a 53 converts to 71418200 on line #526 in the block dump.
col 0: [ 5] c4 48 2a 53 1d converts to 71418228 on line #640 in the block dump.
col 0: [ 6] c5 08 02 20 61 3f converts to 701319662 on line #648 in the block dump.
col 0: [ 6] c5 08 03 2f 33 17 converts to 702465022 on line #785 in the block dump.
col 0: [ 6] c5 08 03 2f 33 5f converts to 702465094 on line #793 in the block dump.
col 0: [ 6] c5 08 03 2f 40 38 converts to 702466355 on line #801 in the block dump.
col 0: [ 6] c5 08 03 30 09 5c converts to 702470891 on line #809 in the block dump.
col 0: [ 6] c5 08 03 32 61 05 converts to 702499604 on line #817 in the block dump.
col 0: [ 6] c5 08 03 33 0b 06 converts to 702501005 on line #827 in the block dump.
col 0: [ 6] c5 08 03 33 19 4b converts to 702502474 on line #835 in the block dump.
col 0: [ 6] c5 08 03 33 44 3d converts to 702506760 on line #843 in the block dump.
col 0: [ 6] c5 08 03 33 45 08 converts to 702506807 on line #851 in the block dump.
col 0: [ 6] c5 08 03 33 4e 5a converts to 702507789 on line #859 in the block dump.
col 0: [ 6] c5 08 03 33 5f 3b converts to 702509458 on line #867 in the block dump.
col 0: [ 6] c5 09 01 01 21 64 converts to 800003299 on line #875 in the block dump.
col 0: [ 6] c5 09 01 01 22 3b converts to 800003358 on line #883 in the block dump.
18:55:41 oracle@oh1xcwcdb01 /u02/admin/wcperf/udump >...and the script itself is below...
#!/usr/bin/python
#Author:        Steve Howard
#Date:          March 23, 2009
#Organization: AppCrawler
#Purpose:       Simple script to print integer equivalents of block dump values in index.
import fileinput
import string
import sys
import re
#boo=1
boo=0
j=0
for line in fileinput.input([sys.argv[1:][0]]):
j=j+1
if re.match('^col 0:', line):
    #print line
    dep=int(string.replace(string.split(string.split(line,"]")[1])[0],"c","")) - 1
    #print dep
    i=0
    tot=0
    exp=dep
    for col in string.split(string.split(line,"]")[1]):
      if i > 0:
        tot = tot + ((int(col, 16) - 1) * (100**exp))
        exp = exp - 1
      i = i + 1
    print line.rstrip("\n") + " converts to " + str(tot) + " on line #" + str(j) + " in the block dump."

Index block dump: "header address" doesn't match rdba

I did a dump on index leaf block, and I found "header address" doesn't match rdba, what's the "header address"? I also found several leaf blocks have the same "header address".
buffer tsn: 11 rdba: 0x1684d120 (90/315680)
========> 0x1684d120 (1)
header address 4403265988=0x1067481c4
========> 0x1067481c4 (2)
*** SERVICE NAME:(SYS$USERS) 2009-08-04 04:37:36.335
*** SESSION ID:(14234.24426) 2009-08-04 04:37:36.335
Start dump data blocks tsn: 11 file#: 90 minblk 315680 maxblk 315680
buffer tsn: 11 rdba: 0x1684d120 (90/315680)
========> 0x1684d120 (1)
scn: 0x0324.dda9ec3d seq: 0x01 flg: 0x04 tail: 0xec3d0601
frmt: 0x02 chkval: 0xeb2a type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Block header dump: 0x1684d120
Object id on Block? Y
seg/obj: 0x7ca10 csc: 0x324.dda9ec3d itc: 17 flg: O typ: 2 - INDEX
     fsl: 0 fnx: 0x1684cf72 ver: 0x01
Itl           Xid                  Uba         Flag Lck        Scn/Fsc
Leaf block dump
===============
header address 4403265988=0x1067481c4
========> 0x1067481c4 (2)
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x90: opcode=0: iot flags=I-- is converted=Y
kdxconco 2
kdxcosdc 5
kdxconro 0
kdxcofbo 36=0x24
kdxcofeo 7672=0x1df8
kdxcoavs 7636
kdxlespl 0
kdxlende 0
kdxlenxt 373579108=0x16445d64
kdxleprv 377801347=0x1684ca83
kdxledsz 0
kdxlebksz 7672
----- end of leaf block dump -----Thanks,
Daniel

Hi user646745
You didn't say why you need to do index block dump ?
Also take are that block structures and dumps some time are different from a ver to ver it 9i and 10g. Unless you now what exectaly you are looking for
Thanks

Leaf Block Dump / Output varies

Hello guys,
i have faced the following issues on a leaf block dump:
First)
row#0[8024] flag: ------, lock: 0, len=12, data:(6): 00 40 76 fa 00 00
col 0; len 2; (2): c1 02
col 1; NULL
row#1[7998] flag: ------, lock: 0, len=14, data:(6): 00 40 76 fa 00 02
col 0; len 2; (2): c1 03
col 1; len 2; (2): c1 02
.......Second)
1103F5A90 3D91D858 000C0100 03303130 0944454C [=..X.....010.DEL]
1103F5AA0 494E535F 494E0832 30303730 36303106 [0505.20070601.]
1103F5AB0 30303535 3331063D 91D85800 0D010003 [005531.=..X.....]
1103F5AC0 30313009 44454C49 4E535F49 4E083230 [010.DAT050_IN.20]
1103F5AD0 30373036 30310630 30353533 34063D91 [070601.005534.=.]
1103F5AE0 D858000E 01000330 31300944 454C494E [.X.....010.DAT03]
1103F5AF0 535F494E 08323030 37303630 31063030 [S_IN.20070601.00]
1103F5B00 35353334 063D91D8 58000F01 00033031 [5534.=..X.....01]
1103F5B10 30094445 4C494E53 5F494E08 32303037 [0.DAT050_IN.2007]Sometimes i am facing the row#n output like in the first example and sometimes i am facing only the "real data" like in the second example when i am doing a leaf block dump. Both examples are from different indeces...
When does one occur? Has anyone any idea?
Regards
Stefan

Hi,
File is truncated by trace file limit. Yeah but the file is not big enough.. i only dumped one block.. and the limit is up to 10MB
But as far as I'm aware, a memory dump is normally not included in block dump. Did you check what's at the top? Really interesting... i have done the same on our test system on the same index.. and there the section leaf block dump includes the information. The same command on the same index (i have cloned the database 3 days ago to our test system).
Leaf block dump
===============
row#0[3514] flag: ---D--, lock: 2, len=39
col 0; len 3; (3): 30 31 30
col 1; len 9; (9): 44 45 4c 49 4e 53 5f 49 4e
col 2; len 8; (8): 32 30 30 37 30 36 30 31
col 3; len 6; (6): 30 30 35 35 31 39
col 4; len 6; (6): 3d 91 d7 d8 00 13
----- end of leaf block dump -----Can this leaf block cleaned out (by deletes) and not include any pointers anymore?
I have compared the leaf block attributes:
-> kdxcoavs 3298 (with row#n entries)
-> kdxcoavs 6988 (without row#n entries)
So the dump were are no row#n entries has much more available space - this would be confirm my guess.
Regards
Stefan

About Block Dump

Hi,
Recently I try to learn BBED to analyze data block.
I create a test table, and run query as below:
BBED@linora>select file_id, block_id from dba_extents
2 where segment_name = 'BLOCK_LAB';
FILE_ID BLOCK_ID
9 1825
I knew that the block 1825 is the table BLOCK_LAB's header block. The data block is in the immediate next block ,so in this example, will be 1826.
But when I run below query, it's result not as expect!
BBED@linora>SELECT
2 dbms_rowid.rowid_relative_fno(rowid) REL_FNO,
3 dbms_rowid.rowid_block_number(rowid) BLOCKNO,
4 dbms_rowid.rowid_row_number(rowid) ROWNO
5 from block_lab
6 where id=1
7 /
REL_FNO BLOCKNO ROWNO
9 1832 0
how could this happened?
Edited by: user12957738 on 2013-6-6 上午12:31

Fung.Kong wrote:
Hi,
Recently I try to learn BBED to analyze data block.
I create a test table, and run query as below:
BBED@linora>select file_id, block_id from dba_extents
2 where segment_name = 'BLOCK_LAB';
FILE_ID BLOCK_ID
9 1825
I knew that the block 1825 is the table BLOCK_LAB's header block. The data block is in the immediate next block ,so in this example, will be 1826.The first block of the first extent isn't necessarily the segment header block; and the first block used for an insert isn't necessarily the first block after the segment header block. You have to check whether you're using freelists or bitmaps for segment space management, and if it's freelist management you have to allow for the freelist blocks if you've declared multiple freelist groups for a segment, and if it's bitmap management the first used block might be almost anywhere in the first extent.
Quick demo to show the potential mismatch between dba_extents and dba_segments:
SQL> select segment_name, file_id, block_id from dba_extents where owner = 'TEST_USER' and extent_id = 0;
SEGMENT_NAME                FILE_ID   BLOCK_ID
T1                                5        128
T2                                6        128
2 rows selected.
SQL> select segment_name, header_file, header_block from dba_segments where owner = 'TEST_USER';
SEGMENT_NAME             HEADER_FILE HEADER_BLOCK
T1                                 5          128
T2                                 6          131File 5 is using freelist management - the segment header block is the first block of the first extent
FIle 6 is using ASSM - with a relatively small first extent size - the segment header block follows 2 level 1 bitmap blocks and a level 2 bitmap block.
Regards
Jonathan Lewis

Tag to make coldfusion skip parsing a certain block of code.

Is there a tag to make coldfusion skipping parsing a certain code.
Example, I want coldfusion to output the following code without executing it.
<cfquery name="qryTest" datasource="myds">
SELECT * FROM dual
</cfquery>
should result as
<cfquery name="qryTest" datasource="myds">
SELECT * FROM dual
</cfquery>
not coldfusion executing the qryTest.

how?
you mean the following:
<cfquery name="qryTest" datasource="myds">
SELECT * FROM dual
</cfquery>
not exactly what I am looking for.

Get the table's rowid of the session that is locking in RAC database

I am a developer and not a DBA and I need to find th correct query to find the exact rowid of the record locked on a table. This is for a RAC database and locked record can be from the web form in oracle application server. When I try to get the correct row id, I get the following error:
ORA-01410 - Invalid row id
For the criteria, the output is Dbms_Rowid.rowid_create(1, -1, 36, 7845, 0), why I get a -1 for the ROW_WAIT_OBJ#?
Additional Information: The lock type is DML and the lock mode is: Row Exclusive, the table is locked and the program is web oracle forms executiong.
I am executing the query in Oracle Database 11g Enterprise Edition Release 11.1.0.7.0
How to accomplish gettting the correct rowid? Below is the selection criteria I have:
select vs.inst_id,
vs.audsid audsid,
locks.sid sid,
locks.type,
locks.id1 id1,
locks.id2 id2,
locks.lmode lmode,
locks.request request,
locks.ctime ctime,
locks.block block,
vs.serial# serial#,
vs.username oracle_user,
vs.osuser os_user,
vs.program program,
vs.module module,
vs.action action,
vs.process process,
decode(locks.lmode,
0, '0 None',
1, '1 NULL',
2, '2 Row Share',
3, '3 Row Exclusive',
4, '4 Share',
5, '5 Share Row Exclusive',
6, '6 Exclusive', '?') lock_mode_held,
decode(locks.request,
0, '0 None',
1, '1 NULL',
2, '2 Row Share',
3, '3 Row Exclusive',
4, '4 Share',
5, '5 Share Row Exclusive',
6, '6 Exclusive', '?') lock_mode_requested,
decode(locks.type,
'MR', 'Media Recovery',
'RT', 'Redo Thread',
'UN', 'User Name',
'TX', 'Transaction',
'TM', 'DML',
'UL', 'PL/SQL User Lock',
'DX', 'Distributed Xaction',
'CF', 'Control File',
'IS', 'Instance State',
'FS', 'File Set',
'IR', 'Instance Recovery',
'ST', 'Disk Space Transaction',
'TS', 'Temp Segment',
'IV', 'Library Cache Invalidation',
'LS', 'Log Start or Log Switch',
'RW', 'Row Wait',
'SQ', 'Sequence Number',
'TE', 'Extend Table',
'TT', 'Temp Table',
locks.type) lock_type,
vs.row_wait_obj# row_wait_obj#,
vs.row_wait_file# row_wait_file,
vs.row_wait_block# row_wait_block#,
vs.row_wait_row# row_wait_row#,
dbms_rowid.rowid_create ( 1, vs.ROW_WAIT_OBJ#, vs.ROW_WAIT_FILE#, vs.ROW_WAIT_BLOCK#, vs.ROW_WAIT_ROW# ) rowid_created,
objs.owner object_owner,
objs.object_name object_name,
objs.object_type object_type,
round( locks.ctime/60, 2 ) lock_time_in_minutes,
from gv$session vs,
gv$lock locks,
dba_objects objs,
dba_tables tbls
where locks.id1 = objs.object_id
and vs.sid = locks.sid
and objs.owner = tbls.owner
and objs.object_name = tbls.table_name
and objs.owner != 'SYS'
-- and locks.type in ('TM', 'TX')
order by lock_time_in_minutes;
Edited by: user3564713 on Jun 10, 2012 10:56 PM

Firstly, read this thread
Identifying locked rows
And the last bit from Randolf
>
It is a common misconception that you can locate a locked row in Oracle via a query. The point is that the information that you're querying only gets populated in case of a blocking lock, and even then not in every case, since you might have blocking locks that do not refer to a particular row.
Oracle stores the lock information within the block, so if you identified in which block the row is located that you've attempted to lock, you could get detailed information about the row locks of that block by performing a block dump.
Other than that Oracle doesn't maintain this information anywhere else and it is only externalized for blocking situations - it is a matter of design that there is no central lock manager in Oracle that would inherently limit scalability, hence the downside of that approach is that there is no central information pool where you could obtain detailed information about row level locks.
>
However, if you see support note "Sample Code to Select from a Table EXCLUDING Locked Rows [ID 186531.1]"
You can take the same code from the script in that note to identify rowid of the locked rows.

Get blocker from the (self) deadlock trace file

Hi,
Recently I had an issue on a 10.2.0.4 single instance database where deadlocks were occurring. The following test case reproduces the problem (I create three parent tables, one child table with indexed foreign keys to all three parent tables and a procedure which performs an insert into the child table in an autonomous transaction):
create table parent_1(id number primary key);
create table parent_2(id number primary key);
create table parent_3(id number primary key);
create table child( id_c number primary key,
                   id_p1 number,
                   id_p2 number,
                   id_p3 number,
                   constraint fk_id_p1 foreign key (id_p1) references parent_1(id),
                   constraint fk_id_p2 foreign key (id_p2) references parent_2(id),
                   constraint fk_id_p3 foreign key (id_p3) references parent_3(id)
create index i_id_p1 on child(id_p1);
create index i_id_p2 on child(id_p2);
create index i_id_p3 on child(id_p3);
create or replace procedure insert_into_child as
pragma autonomous_transaction;
begin
insert into child(id_c, id_p1, id_p2, id_p3) values(1,1,1,1);
commit;
end;
insert into parent_1 values(1);
insert into parent_2 values(1);
commit;And now the action that causes the deadlock:
SQL> insert into parent_3 values(1);
1 row created.
SQL> exec insert_into_child;
BEGIN insert_into_child; END;
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource
ORA-06512: at "SCOTT.INSERT_INTO_CHILD", line 4
ORA-06512: at line 1My question is: how can I determine which table the insert into CHILD was waiting on? It could be waiting on PARENT_1, PARENT_2, PARENT_3, a combination of them or even on CHILD if I tried to insert a duplicate primary key in CHILD. Since we have the full testcase we know that it was waiting on PARENT_3 (or better said, it was waiting for the "parent" transaction to perform a commit/rollback), but is it possible to determine that solely from the deadlock trace file? I'm asking that because to pinpoint the problem I had to perform redo log mining, pl/sql tracing with DBMS_TRACE and manual debugging on a clone of the production database which was restored to a SCN just before the deadlock occurred. So, I had to do quite a lot of work to get to the blocker table and if this information is already in the deadlock trace file, it would have saved me a lot of time.
Below is the deadlock trace file. From the "DML LOCK" part I guess that the child table (tab=227042) holds a mode 3 lock (SX), all the other three parent tables have mode 2 locks (SS), but from this extract I can't see that parent_3 (tab=227040) is blocking the insert into child:
Deadlock graph:
                       ---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name          process session holds waits process session holds waits
TX-00070029-00749150        23     476     X             23     476           S
session 476: DID 0001-0017-00000003     session 476: DID 0001-0017-00000003
Rows waited on:
Session 476: obj - rowid = 000376E2 - AAA3biAAEAAA4BwAAA
(dictionary objn - 227042, file - 4, block - 229488, slot - 0)
Information on the OTHER waiting sessions:
End of information on OTHER waiting sessions.
Current SQL statement for this session:
INSERT INTO CHILD(ID_C, ID_P1, ID_P2, ID_P3) VALUES(1,1,1,1)
----- PL/SQL Call Stack -----
object      line object
handle    number name
3989eef50         4 procedure SCOTT.INSERT_INTO_CHILD
391f3d870         1 anonymous block
        SO: 397691978, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
        DML LOCK: tab=227042 flg=11 chi=0
                  his[0]: mod=3 spn=35288
        (enqueue) TM-000376E2-00000000 DID: 0001-0017-00000003
        lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x6
        res: 0x398341fe8, mode: SX, lock_flag: 0x0
        own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x398341ff8
        SO: 397691878, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
        DML LOCK: tab=227040 flg=11 chi=0
                  his[0]: mod=2 spn=35288
        (enqueue) TM-000376E0-00000000 DID: 0001-0017-00000003
        lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x6
        res: 0x3983386e8, mode: SS, lock_flag: 0x0
        own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x3983386f8
        SO: 397691778, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
        DML LOCK: tab=227038 flg=11 chi=0
                  his[0]: mod=2 spn=35288
        (enqueue) TM-000376DE-00000000 DID: 0001-0017-00000003
        lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x6
        res: 0x398340f58, mode: SS, lock_flag: 0x0
        own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x398340f68
        SO: 397691678, type: 36, owner: 39686af98, flag: INIT/-/-/0x00
        DML LOCK: tab=227036 flg=11 chi=0
                  his[0]: mod=2 spn=35288
        (enqueue) TM-000376DC-00000000 DID: 0001-0017-00000003
        lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x6
        res: 0x39833f358, mode: SS, lock_flag: 0x0
        own: 0x3980df420, sess: 0x3980df420, proc: 0x39859c660, prv: 0x39833f368
      ----------------------------------------Thank you in advance for any comments,
Jure

Hi Jonathan,
thank you very much for your reply which more than answers my question. I think it actually clears a lot of doubts I had about TX locks, since your mentioning of "undo segment header transaction table" pointed me in the right direction for further research on this topic (honestly, I didn't know what's "behind" TX locks). So if I understood correctly, to determine which table is the blocker (in the testcase presented above), you have to have some kind of history of executed SQL statements (e.g. by mining redo logs)?
The statement you wrote:
At this point, and with your example, the waiting session is waiting on a TX (transaction) lock - this means it has not idea (and no interest) in the actual data involved, it is merely waiting for an undo segment header transaction table slot to clear. and the example with the savepoint you gave, made me think of some of the consequences of that behaviour. That is probably the reason why it is not possible to get the "blocker" table from v$lock (although sometimes it's possible to get it from v$session.row_wait_obj#) when a session tries to change a row another session holds in exclusive mode, e.g.:
create table t1 (id number);
insert into t1 values (1);
commit;
Session 126:
SID = 126> update t1 set id=2 where id=1;
1 row updated.
Session 146:
SID = 146> update t1 set id=2 where id=1;
{session hangs}
In a separate session:
SQL> SELECT   CASE
2                  WHEN TYPE = 'TM'
3                     THEN (SELECT object_name
4                             FROM user_objects
5                            WHERE object_id = l.id1)
6               END object_name,
7                  SID, TYPE, id1, id2, lmode, request, BLOCK
8          FROM v$lock l
9         WHERE SID IN (126, 146)
10     ORDER BY SID, TYPE, 1
11 /
OBJECT_NAME    SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
T1             126 TM      68447          0          3          0          0
               126 TX     262153       4669          6          0          1
T1             146 TM      68447          0          3          0          0
               146 TX     262153       4669          0          6          0The only thing I can tell from this output is that session 146 is trying to get a TX lock in exclusive mode, and session 126 is blocking it, the reason of the blocking being unknown from this view alone.
Since I'd like to get a better understanding on the mechanics behind this (e.g. why the blocked session can't know the segment that is waiting for, since it has to go to the same segment's data block to find the address of the undo segment header transaction table slot? ; can we get the content/structure of the transaction table in the data block - probably by making a block dump?), do you have any source where a more in depth explanation what happens "behind the scenes" is available (perhaps in Oracle Core?)? Some time ago I found a link on your blog http://jonathanlewis.wordpress.com/2010/06/21/locks/ which points to Franck Pachot's article where he nicely explains the various locking modes: http://knol.google.com/k/oracle-table-lock-modes#. There I also found Kyle Hailey's presentation about locks http://www.perfvision.com/papers/09_enqueues.ppt where slide 23 nicely depicts what's going on when acquiring TX locks. Of course I'll try to search on my own, but any other source (especially from an authority like you) is more than welcome.
Thank you again and regards,
Jure

BLOCK CORRUPTION (ORACLE8 에서 ORA-1578 조치방법)

제품 : ORACLE SERVER
작성날짜 : 2002-04-26
BLOCK CORRUPTION (ORACLE8 에서 ORA-1578 조치방법)
================================================
PURPOSE
본 bulletin 에서는 Oracle8 에서의 data block corruption error
(ORA-1578) 에 대해서 조치방법을 알아본다.
BACKGROUND
ORA-1578 은 data block 에 corruption 이 생긴 경우에 발생한다.
이 error 는 corruption 이 발생한 곳의 file number 와 block
number 를 알려준다.
본 bulletin 에서는 file number 를 'f', block number 를 'b' 로
지칭하기로 한다. ORA-1578 과 함께 return 되는 file number는
relative file number 가 아닌 absolute file number 를 의미한다.
(Oracle8 에서 새롭게 소개된 relative file number 에 대해서는 본
bulletin 의 6번 항목에서 다루도록 한다.)
RESOLUTION
1. 최선의 해결책은 backup 받아둔 file 을 restore 한 후
recover 작업을 하는 것이다. 이 작업을 위해서는 archive
log mode 로 운영 중이어야 한다.
dba_data_files 또는 v$datafile 과 ORA-1578 error 에서
return 된 absolute file number 를 이용하여 corruption이
발생한 datafile 의 이름을 알아낼 수 있다.
Oracle8 에서는, dba_data_files 에 absolute file number
(file_id) 와 함께 relative file number (relative_fno) 를
가지고 있다.
v$datafile 에는 아직 absolute file number (file#) 만을 가진다.
backup 을 restore 하기 전에 hardware 의 문제를 fix 해야 할
필요가 있을 수 있다. 만약 corruption 이 disk 불량에 의해
발생하였다면, backup 받아둔 datafile 을 문제가 없는 disk 에
restore 하고, startup mount 한 후, 새로운 위치로 datafile
rename 을 하고 recover 한다.
만약 해당 datafile 이 system tablespace 에 속하지 않는다면
offline tablespace recovery 도 가능하다.
2. backup datafile 을 restore 하고 recover 하지 않을 것이라면
우선, 어떤 object 에서 corruption 이 발생하였는지 확인해야
한다.
다음의 SQL 문을 이용한다.
SELECT owner, segment_name, segment_type, relative_fno
FROM dba_extents
WHERE file_id = f
AND b BETWEEN block_id AND block_id + blocks - 1 ;
3. 해당 segment 가 non-data dictionary index라면, 해당 index를
drop 한 후 재생성한다.
4. 해당 segment 가 table 이라면, corruption 이 발생한 block 의
data 는 소실된 것이다.
5. 만약 해당 table 에 대한 최근의 export dump file이 존재한다면,
해당 table 을 drop 한 후 import 함으로써 복구할 수 있다.
최근의 export dump file 이 없거나 이를 export 받을 수 있는
최근의 backup 이 없다면 다음과 같은 방법을 이용할 수 있다.
6. corruption 이 발생한 non-clustered table 에서 corrupted
block 을 access 하지 않고 나머지 data 들을 select 할 수
있도록 ROWID 를 이용할 수 있다. non-clustered table의 모든
row 들은 해당 row 의 물리적인 주소를 가리키는 고유한 ROWID를
갖는다(해당 row가 여러 block에 조각이 나 있다면 첫번째 조각에
대한 주소). clustered table 인 경우에는 서로 다른 table 의
data 들이 같은 block 에 존재할 수 있으며, 같은 ROWID 를 가질
수 있다.
Oracle 은 index 를 구성하기 위하여 내부적으로 ROWID 를 사용한다.
따라서 where 절에 ROWID 를 사용하여 select 하면 강제로 range
scan 를 할 수 있다.
Oracle8 에서는 이를 위하여 ROWID hint 를 사용할 필요가
없어졌다.
ROWID 를 이용하여 table 로부터 data 를 추출하기
예제로써 ACCT_NO, PERSON, WEEKNO 등의 column 으로 구성된
SCOTT user의 EXAMPLE 이라는 table 이 있다고 가정한다.
이때, ORA-1578 "ORACLE data block corrupted (file # 5,
block # 2) 가
발생하였다고 가정하자.
ROWID in Oracle8 :
Oracle8 에서의 ROWID 는 'OOOOOOFFFBBBBBBSSS' format 을 가진다.
OOOOOO = data object number
Oracle7 의 object_id 와는 별도로 segment 의 id 를 갖는다.
dba_objects 의 data_object_id 에서 확인가능
FFF = relative file number
BBBBBB = block number
SSS = row number
Oracle8에서의 ROWID 는 absolute file number 가 아닌 relative
file number 를 갖는다는 점에 주목해야 한다.
relative file number 는 tablespace 에 대해 상대적이며
(tablespace마다 첫번째, 두번째, 세번째 datafile 을 가질 수
있음을 의미) absolute file number 는 전체 database 내에서
고유하다. 두개의 서로다른 file 들이 동일한 relative file
number를 가질 수 있다.
만약 EXAMPLE table 에서 ACCT_NO, ROWID 를 select하면 다음과
같은 결과가 나올 수 있다.
ACCT_NO ROWID
12345 AAAAh3AAGAAACJAAAA
19283 AAAAh3AAGAAACJAAAB
22345 AAAAh4AAFAAAAADAAA
60372 AAAAh4AAFAAAAADAAB
33456 AAAAh5AAEAAAAIuAAA
29473 AAAAh5AAEAAAAIuAAB
이러한 format 을 extended ROWID character format 이라고
지칭한다.
extended ROWID 는 number 이므로 substr 함수를 이용하여
extended ROWID 로부터 일부를 떼어낼 수 없다.
ROWID 를 생성하기 위해서는 모든 component 를 알아야 한다.
그런다음, DBMS_ROWID package 의 function 을 이용하여 ROWID 를
생성할 수 있다.
function rowid_create(rowid_type IN number,
object_number IN number,
relative_fno IN number,
block_number IN number,
row_number IN number)
return rowid;
pragma RESTRICT_REFERENCES(rowid_create,WNDS,RNDS,WNPS,RNPS);
-- rowid_type - type (restricted=0/extended=1)
-- object_number - data object number
(rowid_object_undefined for )
-- restricted
-- relative_fno - relative file number
-- block_number - block number in this file
-- file_number - file number in this block
corruption 이 발생한 block 의 data object number 를 알기
위해서는 dba_objects 를 조회한다.
SELECT data_object_id FROM dba_objects
WHERE owner = 'SCOTT'
AND object_name = 'EXAMPLE' ;
DATA_OBJECT_ID
2168
우리는 이미, 위에서 사용한 다음의 SQL 에 의해서 relative file
number 를 알고 있다.
SELECT owner, segment_name, segment_type, relative_fno
FROM dba_extents
WHERE file_id = 5
AND 2 BETWEEN block_id AND block_id + blocks - 1 ;
OWNER SEGMENT_NAME SEGMENT_TYPE RELATIVE_F
SCOTT EXAMPLE TABLE 5
corruption 이 발생한 block 이 2이므로, block# 2 이전의 access
가능한 마지막 ROWID 는 block# 1 에 존재한다. 그리고 block# 2
이후의 access 가능한 첫 ROWID 는 block# 3에 존재한다. block
안에 몇개의 row number 가 존재할 지 모르므로 row number 0 을
이용한다.
이제 corrupted block 이전의 ROWID 와 이후의 ROWID 를 생성할
준비가 끝났다.
corrupted block 이전의 ROWID :
SELECT DBMS_ROWID.ROWID_CREATE(1,2168,5,1,0) FROM example ;
DBMS_ROWID.ROWID_C
AAAAh4AAFAAAAABAAA
corrupted block 이후의 ROWID :
SELECT DBMS_ROWID.ROWID_CREATE(1,2168,5,3,0) FROM example ;
DBMS_ROWID.ROWID_C
AAAAh4AAFAAAAADAAA
다음으로, EXAMPLE table 과 같은 spec 으로 table 을 하나 만든다.
CREATE TABLE temp AS SELECT * FROM example WHERE 1=2;
그리고 corrupted block 이외의 block 에서 data 를 추출하여
insert 한다.
INSERT INTO temp SELECT * FROM example
WHERE ROWID <= 'AAAAh4AAFAAAAABAAA';
INSERT INTO temp SELECT * FROM example
WHERE ROWID >= 'AAAAh4AAFAAAAADAAA';
이후 원본 table 을 drop 하고, TEMP 를 rename 한다.
7. 만약 data dictionary 에 속하는 table, index 또는 rollback
segment에 corrupted block 이 발생하였다면 Oracle Support 의
지원을 받는다.
8. 일반적으로, ORA-1578 은 hardware 의 문제때문에 유발된다.
하지만 만약에 ORA-600[3374] 가 발생한다면 memory 상에서
corruption 이 발생한 경우이다.
이 경우 database 를 restartup 하면 문제가 해결될 수 있다.
Reference Documents
--------------------

Hello,
Please check the link i posted.
Example: Detecting Corruption
The CHECK_OBJECT procedure checks the specified object, and populates the repair table with information about corruptions and repair directives. You can optionally specify a range, partition name, or subpartition name when you want to check a portion of an object.
Validation consists of checking all blocks in the object that have not previously been marked corrupt. For each block, the transaction and data layer portions are checked for self consistency. During CHECK_OBJECT, if a block is encountered that has a corrupt buffer cache header, then that block is skipped.
The following is an example of executing the CHECK_OBJECT procedure for the scott.dept table.
SET SERVEROUTPUT ON
DECLARE num_corrupt INT;
BEGIN
num_corrupt := 0;
DBMS_REPAIR.CHECK_OBJECT (
SCHEMA_NAME => 'SCOTT',
OBJECT_NAME => 'DEPT',
REPAIR_TABLE_NAME => 'REPAIR_TABLE',
CORRUPT_COUNT => num_corrupt);
DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt));
END;
SQL*Plus outputs the following line, indicating one corruption:
number corrupt: 1

Data Block, Extents, and Segments in Datafiles

I'm trying to understand the relationship of Data Blocks, Extents, and Segments in Datafiles. What is the simpliest explanation for their relationships.

Hi,
Look at this (might be more readable if you paste it somewhere and use a font with fixed width):
SQL>CONNECT SYSTEM/MANAGER
ConnectÚ.
SQL> CREATE TABLE MyTable
2 (
3 CH1 VARCHAR2(10),
4 CH2 VARCHAR2(10)
5 ) TABLESPACE TOOLS;
Table crÚÚe.
SQL>SELECT * FROM DBA_SEGMENTS WHERE SEGMENT_NAME='MYTABLE';
OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME HEADER_FILE HEADER_BLOCK BYTES BLOCKS EXTENTS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS RELATIVE_FNO BUFFER_
SYSTEM MYTABLE TABLE TOOLS 7 1555 65536 16 1 65536 1 2147483645 7 DEFAULT
SQL> SELECT * FROM DBA_EXTENTS WHERE SEGMENT_NAME='MYTABLE';
OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO
SYSTEM MYTABLE TABLE TOOLS 0 7 1553 65536 16 7
SQL> -- Give it another extent
SQL> ALTER TABLE MyTable ALLOCATE EXTENT;
Table modifiÚe.
SQL> SELECT * FROM DBA_EXTENTS WHERE SEGMENT_NAME='MYTABLE';
OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_FNO
SYSTEM MYTABLE TABLE TOOLS 0 7 1553 65536 16 7
SYSTEM MYTABLE TABLE TOOLS 1 7 1569 65536 16 7
SQL> -- Note that in this particular case, Both extents are on the same datafile (7), and if you add the block_id (first block in the extent) of the extent 0 (first one) to the number
SQL> -- of blocks in the extent (16) = 1553 + 16 = 1569 = BLOCK_ID of the second extent (they are physically side by side)
SQL> -- THIS IS NOT ALWAYS TRUE, AND GENERALLY FALSE!
SQL>
SQL> -- Let's dump the first block and see what's in:
SQL> ALTER SYSTEM DUMP DATAFILE 7 BLOCK 1553;
SystÞme modifiÚ.
SQL> -- Now edit the trace file
/* Content:
Start dump data blocks tsn: 7 file#: 7 minblk 1553 maxblk 1553
buffer tsn: 7 rdba: 0x01c00611 (7/1553)
scn: 0x0000.0007b1fa seq: 0x02 flg: 0x00 tail: 0xb1fa2002
frmt: 0x02 chkval: 0x0000 type: 0x20=FIRST LEVEL BITMAP BLOCK
Dump of First Level Bitmap Block
nbits : 4 nranges: 1 parent dba: 0x01c00612 poffset: 0
unformatted: 13 total: 16 first useful block: 3
owning instance : 1
instance ownership changed at
Last successful Search
Freeness Status: nf1 0 nf2 0 nf3 0 nf4 0
Extent Map Block Offset: 4294967295
First free datablock : 3
Bitmap block lock opcode 0
Locker xid: : 0x0000.000.00000000
Highwater:: 0x01c00614 ext#: 0 blk#: 3 ext size: 16
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 0
HWM Flag: HWM Set
DBA Ranges :
0x01c00611 Length: 16 Offset: 0
0:Metadata 1:Metadata 2:Metadata 3:unformatted
4:unformatted 5:unformatted 6:unformatted 7:unformatted
8:unformatted 9:unformatted 10:unformatted 11:unformatted
12:unformatted 13:unformatted 14:unformatted 15:unformatted
End dump data blocks tsn: 7 file#: 7 minblk 1553 maxblk 1553
SQL> -- Now add 2 lines
SQL> INSERT INTO MYTABLE VALUES ('ABC','123');
1 ligne crÚÚe.
SQL> COMMIT;
Validation effectuÚe.
SQL> INSERT INTO MYTABLE VALUES ('DEF','456');
1 ligne crÚÚe.
SQL> COMMIT;
Validation effectuÚe.
SQL> -- And get the ROWID (absolute line physical position) of these lines
SQL> SELECT ROWID FROM MYTABLE;
ROWID
AAAHotAAHAAAAYfAAA
AAAHotAAHAAAAYfAAB
SQL> -- Absolute file number of these 2 lines:
SQL> SELECT DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO('AAAHotAAHAAAAYfAAA','SYSTEM','MYTABLE') FROM DUAL;
DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO('AAAHOTAAHAAAAYFAAA','SYSTEM','MYTABLE')
7
SQL> SELECT DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO('AAAHotAAHAAAAYfAAB','SYSTEM','MYTABLE') FROM DUAL;
DBMS_ROWID.ROWID_TO_ABSOLUTE_FNO('AAAHOTAAHAAAAYFAAB','SYSTEM','MYTABLE')
7
SQL> -- Both in file 7: no surprise, in the extent.
SQL> -- Let's be curious and look up the block id:
SQL> SELECT DBMS_ROWID.ROWID_BLOCK_NUMBER('AAAHotAAHAAAAYfAAA') FROM DUAL;
DBMS_ROWID.ROWID_BLOCK_NUMBER('AAAHOTAAHAAAAYFAAA')
1567
SQL> SELECT DBMS_ROWID.ROWID_BLOCK_NUMBER('AAAHotAAHAAAAYfAAB') FROM DUAL;
DBMS_ROWID.ROWID_BLOCK_NUMBER('AAAHOTAAHAAAAYFAAB')
1567
SQL> -- Both lines are in block number 1567.. look again into the dump from block 1553 (First free datablock : 3)
SQL> -- Dump the block:
SQL> ALTER SYSTEM DUMP DATAFILE 7 BLOCK 1567;
SystÞme modifiÚ.
SQL>
/* Content:
Start dump data blocks tsn: 7 file#: 7 minblk 1567 maxblk 1567
buffer tsn: 7 rdba: 0x01c0061f (7/1567)
scn: 0x0000.0007b2fd seq: 0x01 flg: 0x02 tail: 0xb2fd0601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Block header dump: 0x01c0061f
Object id on Block? Y
seg/obj: 0x7a2d csc: 0x00.7b2f5 itc: 2 flg: E typ: 1 - DATA                                             <--------- Here is the objet ID. 0x7a2d = 31227 (check just below block dump)
brn: 0 bdba: 0x1c00611 ver: 0x01
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0006.003.000002f8 0x008000b7.0081.06 --U-    1 fsc 0x0000.0007b2f9
0x02 0x0005.000.000002fd 0x00800099.008f.16 --U-    1 fsc 0x0000.0007b2fd
data_block_dump,data header at 0x2ff1064
===============
tsiz: 0xf98
hsiz: 0x16
pbl: 0x02ff1064
bdba: 0x01c0061f
76543210
flag=--------
ntab=1
nrow=2                                                                                                                                                                                              <--------- 2 Lines in the block
frre=-1
fsbo=0x16
fseo=0xf82
avsp=0xf6c
tosp=0xf6c
0xe:pti[0]     nrow=2     offs=0
0x12:pri[0]     offs=0xf8d
0x14:pri[1]     offs=0xf82
block_row_dump:
tab 0, row 0, @0xf8d
tl: 11 fb: H-FL lb: 0x1 cc: 2                                                                                                                        <--------- First line header
col 0: [ 3] 41 42 43                                                                                                                                                      <--------- Here is 'ABC'
col 1: [ 3] 31 32 33                                                                                                                                                      <--------- Here is '123'
tab 0, row 1, @0xf82
tl: 11 fb: H-FL lb: 0x2 cc: 2                                                                                                                        <--------- Second line header
col 0: [ 3] 44 45 46                                                                                                                                                      <--------- Here is 'DEF'
col 1: [ 3] 34 35 36                                                                                                                                                      <--------- Here is '456'
end_of_block_dump
End dump data blocks tsn: 7 file#: 7 minblk 1567 maxblk 1567
SQL> SELECT OBJECT_ID FROM DBA_OBJECTS WHERE OBJECT_NAME='MYTABLE';
OBJECT_ID
31277
Sincerely hope this'll help you understand.
Regards,
Yoann.

Javacc assistance: adding a block of arbitrary text

Hi all
I'm developing a statechart compiler, which takes in a textual format and generates C. This C is destined for embedded systems. Part of the frontend of the compiler is my parser.
Most of my parser grammer is done, apart from this: allowing parsing of arbitrary text, as per this example:
MyStateA
entry
    --arbitrary C code here--
}So, parse the state block, which contains an entry block (all good so far). But how do I approach the arbitrary C code section? I dont want to incorporate the entire C grammer into my langauge. I've seen techniques whereby { and } braces are counted somehow, and the skip and token specs change. In this arbitrary code section, I can make the requirement that there must be prefectly paired braces within, thus the last closing one for entry can be determined.
Can someone give me a hand with this?
Thanks
Rich

Thanks
Okay, my compiler / code generator is written in Java. Thus the output of javacc plays very well with the rest of the compiler. It is the output of my compiler that is C.
I currently have something like:
void State()
(Entry())?
void Entry()
<ENTRY>
<LEFTBRACE>
    (nothing here yet)
<RIGHTBRACE>
}What does one do next? Do I define a token for (.*)? Then do something like x=<THAT_TOKEN> in the middle there? At some point I need to capture the actual code to place into my intermediate representation. None of the capturing parts of the input to the IR is done yet.
void Entry()
<ENTRY>
<RANGLEBRACE>
    (something)
<LANGLEBRACE>
}Cheers
Rich

Oracle giving Block corruption errors when using CDC for sending the data to SQL Server 2012

Hello Friends,
We are facing an error while using CDC with Oracle. It is a "Block corruption" error, which indicates at some level of data corruption. We ran RMAN validate command to scan the database for corruption but it returned with no errors, however he
Alert Log in Oracle is still coming up with the following error. Has anyone experienced this error when using Oracle Standard Edition and SQL 2012 ?
Trace file e:\app\pulse-ad\diag\rdbms\orcl\orcl\trace\orcl_ora_5992.trc
Oracle Database 11g Release 11.1.0.7.0 - 64bit Production
Windows Server 2003 Version V5.2 Service Pack 2
CPU                 : 4 - type 8664, 4 Physical Cores
Process Affinity    : 0x0000000000000000
Memory (Avail/Total): Ph:6782M/24575M, Ph+PgF:12203M/30844M
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 151
Windows thread id: 5992, image: ORACLE.EXE (SHAD)
*** 2013-12-12 03:04:33.655
*** SESSION ID:(1281.3832) 2013-12-12 03:04:33.655
*** CLIENT ID:() 2013-12-12 03:04:33.655
*** SERVICE NAME:(orcl) 2013-12-12 03:04:33.655
*** MODULE NAME:(xdbcdcsvc.exe) 2013-12-12 03:04:33.655
*** ACTION NAME:() 2013-12-12 03:04:33.655
Lost-write detected for sequence 70856. The lost-write starts occurring in block 11193. The current block being validating is 12930.
Block dump of the first lost-write block:
Flag: 0x1 Format: 0x22 Block: 0x00002bb9 Seq: 0x000114bf Beg: 0x94 Cks:0x68ee
Dump of memory from 0x0000000598D06C00 to 0x0000000598D06E00
598D06C00 00002201 00002BB9 000114BF 68EE8094 [."...+.........h]
598D06C10 00085BF1 0023BDA1 000DE19C 000DE19C [.[....#.........]
598D06C20 0000000C 00000000 2209160A 5BF10000 [..........."...[]
598D06C30 3EB10502 00C0F5CA 0031BDA1 00010205 [...>......1.....]
598D06C40 02B22C6A 038A6D69 00000001 00000000 [j,..im..........]
598D06C50 4D554407 30373230 35BB0206 001100AE [.DUM0270...5....]
598D06C60 0001040A 000D000E 038A6D69 56B25735 [........im..5W.V]
598D06C70 729C0003 E19C0001 000C0006 000D0006 [...r............]
598D06C80 02BB0502 00C0F5CD 0023BDA1 000A0002 [..........#.....]
598D06C90 00C00013 000000D0 00030201 56B25736 [............6W.V]
598D06CA0 03890001 00000000 00000000 002E0105 [................]
598D06CB0 FFFF0003 00C0F5CD 56B25736 3EB10003 [........6W.V...>]
598D06CC0 FFFF0024 0014000C 000C0018 00120014 [$...............]
598D06CD0 09CC0058 E75B0022 0009000F 00085BF1 [X...".[......[..]
598D06CE0 0024BDA1 000DE19D 000DE19D 0000000C [..$.............]
598D06CF0 00000000 2309160A 5BF10000 3EB10502 [.......#...[...>]
598D06D00 00C0F5CD 0020BDA1 00010205 02B22C72 [...... .....r,..]
598D06D10 03900974 00000019 00000000 3030300A [t............000]
598D06D20 33303030 06323132 AE35BB02 0B441100 [0003212...5...D.]
598D06D30 0001040A 000D000E 03900974 56B25736 [........t...6W.V]
598D06D40 729C0003 E19D0011 000C0006 000D0006 [...r............]
598D06D50 02BB0502 00C0F5CD 0024BDA1 00EA0002 [..........$.....]
598D06D60 00270016 000001FC 00032C01 56B25736 [..'......,..6W.V]
598D06D70 00000001 00000000 30393007 002E0105 [.........090....]
598D06D80 FFFF0003 00C0F5CD 56B25736 00000003 [........6W.V....]
598D06D90 FFFF0025 00140052 000C0018 00070035 [%...R.......5...]
598D06DA0 0003000A 00070003 0001001D 00030001 [................]
598D06DB0 00010001 00010001 00010001 00010001 [................]
598D06DC0 00010001 00010001 00010001 00010001 [................]
598D06DD0 00010001 00000001 00010001 00010001 [................]
598D06DE0 00010001 00000014 09720174 00000022 [........t.r."...]
598D06DF0 0009000F 00085BF1 0025BDA1 000DE19A [.....[....%.....]
Block dump of the current block being validating:
Flag: 0x1 Format: 0x22 Block: 0x00003282 Seq: 0x000114c8 Beg: 0x0 Cks:0x312a
Dump of memory from 0x0000000598DDFE00 to 0x0000000598DE0000
598DDFE00 00002201 00003282 000114C8 312A8000 [."...2........*1]
598DDFE10 50424703 31303607 34353335 69745319 [.GBP.6015354.Sti]
598DDFE20 6E696C72 72502067 6375646F 4C207374 [rling Products L]
598DDFE30 4E206474 C3025650 0380013D 0457454E [td NPV..=...NEW.]
598DDFE40 4E1E09C2 1E09C204 10C2024E 1E09C204 [...N....N.......]
598DDFE50 09C2044E C2024E1E 03C30510 021B0929 [N....N......)...]
598DDFE60 C3053DC3 0F192602 2602C305 C3050F19 [.=...&.....&....]
598DDFE70 0C1A6203 5102C105 C2041F4E 044E1E09 [.b.....QN.....N.]
598DDFE80 4E1E09C2 0410C202 4E1E09C2 1E09C204 [...N.......N....]
598DDFE90 10C2024E 2903C305 78071B09 011D0B71 [N......)...xq...]
598DDFEA0 BF020101 1FBF0215 4E018001 53014E01 [...........N.N.S]
598DDFEB0 0723002C 0B0C7178 0A3C3C18 30303030 [,.#.xq...<<.0000]
598DDFEC0 33373030 4D033337 47034255 36075042 [007373.MUB.GBP.6]
598DDFED0 38333936 4E113331 2065776B 74616C50 [693813.Nkwe Plat]
598DDFEE0 6D756E69 56504E20 0B0AC303 4E038001 [inum NPV.......N]
598DDFEF0 C2045745 0459512E 59512EC2 5253C203 [EW...QY...QY..SR]
598DDFF00 512EC204 2EC20459 C2035951 C3055253 [...QY...QY..SR..]
598DDFF10 1B092903 0B0AC303 3C04C305 C3053239 [.).........<92..]
598DDFF20 32393C04 4F08C305 C105114F 1F4E5102 [.<92...OO....QN.]
598DDFF30 512EC204 2EC20459 C2035951 C2045253 [...QY...QY..SR..]
598DDFF40 0459512E 59512EC2 5253C203 2903C305 [.QY...QY..SR...)]
598DDFF50 78071B09 01190A71 C0030101 C0034709 [...xq........G..]
598DDFF60 8001330A 4E014E01 002C5301 71780723 [.3...N.N.S,.#.xq]
598DDFF70 3C180B0C 30300A3C 30303030 33373337 [...<<.0000007373]
598DDFF80 42554D03 50424703 31304207 344C5131 [.MUB.GBP.B011QL4]
598DDFF90 6F725020 63657073 614A2074 206E6170 [ Prospect Japan ]
598DDFFA0 646E7546 64724F20 44535520 30302E30 [Fund Ord USD0.00]
598DDFFB0 04C30331 03800133 0557454E 5B1603C3 [1...3...NEW....[]
598DDFFC0 03C30521 04215B16 1F4004C3 1603C305 [!....[!...@.....]
598DDFFD0 C305215B 215B1603 4004C304 03C3051F [[!....[!...@....]
598DDFFE0 031B0929 043304C3 4D245AC2 245AC204 [).....3..Z$M..Z$]
598DDFFF0 02C3054D 040A1A18 494002C1 1603C305 [M.........@I....]
*** 2013-12-12 03:05:07.984
** LOGMINER WARNING - Invalidated 6 LCRs **
Complete dump of first invalid START LCR follows:
++ LCR Dump Begin: 0x0000000532C004E0 - CANNOT_SUPPORT
     op: 255, Original op: 3, baseobjn: 0, objn: 233316, objv: 1
     DF: 0x00000002, DF2: 0x00000000, MF: 0x00000000, MF2: 0x00000000
     PF: 0x40000001, PF2: 0x00002000
     MergeFlag: 0x00, FilterFlag: 0x00
     Id: 0, iotPrimaryKeyCount: 3, numChgRec: 4
     NumCrSpilled: 0
     RedoThread#: 1, rba: 0x0114c8.0001c6ce.00d4
     scn: 0x0003.56b593be, xid: 0x0008.00c.00100d85, pxid: 0x0008.00c.00100d85
     ncol: 0newcount: 0, oldcount: 0
     LUBA: 0x3.c109c0.c.15.38f64
Thanks
Dee

Hi Dee,
Thank you for your question.
I am trying to involve someone more familiar with this topic for a further look at this issue. Sometime delay might be expected from the job transferring. Your patience is greatly appreciated.
Thank you for your understanding and support.
Regards,
Mike Yin
TechNet Community Support

Ora-01113 and ora-01110 -- Data Block Corruption

Running 10g no backup and noarchivelog.
I put the datafile offline so I can bring up the database. Can anyone help me figure out how to fix the Bad datafile?
Thank You,

TRACE FILE INFORMATION
SQL> select pa.value || '/' || i.instance_name || '_ora_'
2         || pr.spid || '.trc' as trace_file
3 from v$session s, v$process pr, v$parameter pa, v$instance i
4 where s.username = user and s.paddr = pr.addr
5* and pa.name='user_dump_dest';
TRACE_FILE
/oracle/admin/ora9i/udump/ora9i_ora_25199.trcDUMPING A TABLE BLOCK
SQL> select file_id,block_id,bytes,blocks
2 from dba_extents
3 where owner='P' and segment_name='EMP';
FILE_ID   BLOCK_ID            BYTES   BLOCKS
      3          9           65,536        8next is to find out the tablespace name and the datafile...
SQL> select tablespace_name,file_name from dba_data_files
2 where relative_fno = 3;
TABLESPACE_NAME                FILE_NAME
USER_DATA           /oradata3/ora9i/user_data01.dbfNow that we know which file and blocks hold our table, let’s dump a sample block of the table. This is done as follows:
SQL> alter system dump datafile 3 block 10;System altered.
Let’s now look at the contents of dumping one block.
Start dump data blocks tsn: 3 file#: 3 minblk 10 maxblk 10
buffer tsn: 3 rdba: 0x00c0000a (3/10)
scn: 0x0000.00046911 seq: 0x02 flg: 0x04 tail: 0x69110602
frmt: 0x02 chkval: 0x579d type: 0x06=trans data
Block header dump: 0x00c0000a
Object id on Block? Y
seg/obj: 0x6d9c csc: 0x00.46911 itc: 2 flg: O typ: 1 - DATA
     fsl: 0 fnx: 0x0 ver: 0x01
Itl           Xid                  Uba         Flag Lck        Scn/Fsc
0x01   xid: 0x0005.02f.0000010c    uba: 0x00806f10.00ca.28 C---    0 scn 0x0000.00046900
0x02   xid: 0x0003.01c.00000101    uba: 0x00800033.0099.04 C---    0 scn 0x0000.00046906
This is the beginning of the data block dump. The first line tells us that we are dumping file#3, starting at block# 10 (minblk), and finishing with block# 10 (maxblk). Had we dumped more than one data block, these values would represent a range. The relative data block address (rdba) is 0x00c0000a. For more information on the rdba, refer to a later section in this paper. At the end of this line, we can see in parentheses that the rdba corresponds to file# 3, block# 10 (3/10).
The third line describes the SCN of the data block. In our case, the SCN is 0x0000.00046911. The tail of the data block is composed of the last two bytes of the SCN (6911) appended with the type (06) and the sequence (02). If the decomposition of the tail does not match these three values, then the system knows that the block is inconsistent and needs to be recovered. While this tail value shows up at the beginning of the block dump, it is physically stored at the end of the data block.
The block type shows up on the fourth line. Some of the valid types correspond to the following table:
     Type     Meaning
     0x02     undo block
0x06     table or index data block
0x0e     undo segment header
     0x10     data segment header block
     0x17     bitmapped data segment headeri hope it will help...

SQLplus command in a begin/end block

Hi all,
is it possible to use a SQLplus command (i.e. "@") inside a begin/end block , so in a plsql script ?
thanks in advance and regards
John

user10899797 wrote:
is it possible to use a SQLplus command (i.e. "@") inside a begin/end block , so in a plsql script ?Just a quick explanation why not.
That begin..end block is called an anonymous (nameless, unlike a procedure or function) PL/SQL block. The client (in this case, SQL*Plus) transmits the block to Oracle.
The server process servicing that client receives the block, parses it and executes it.
This server process only understands SQL and PL/SQL. Not any language.
So just as you cannot use .Net/Cobol/Visual Basic/Java/etc commands inside that PL/SQL anonymous block, you cannot use SQL*Plus commands in it.
Part of the confusion regarding SQL*Plus is using substitution variables. This enables you to create an anonymous PL/SQL block in SQL*Plus that contains substitution variables.
However, SQL*Plus itself does a very primitive parse of that block before it fires it off at the server - it detects these substitution variables and replace them with the assigned values for these variables. It then transmits this resulting block to the Oracle server for parsing and execution.
Just remember that PL/SQL is a server-side language that runs inside an Oracle server process and that should clear most confusion in this regard (including whether PL/SQL can read keyboard data or write to a client PC's harddrive, or interactively display progress status on a client monitor).

Parsing rowid in block dump

Similar Messages

Maybe you are looking for