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

Similar Messages

  • 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."

  • Oracle Datafile block corruption

    HI all
    i am facing datafile block corruption in following datafile .
    i don't have any backup.
    how i can recover these blocks
    Regards
    Vivek Rawat

    Hi Vivek,
    Please refer below SAP notes to analyze the affected objects which needs to be recovered
    365481 - Block corruptions
    1559652 - How to deal with block corruptions on Oracle
    923919 - Advanced Oracle block checking features
    http://www.dba-oracle.com/t_repair_corrupt_blocks.htm
    Hope this helps.
    Regards,
    Deepak Kori

  • 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

  • System datafile block corrupted

    hi there,
    i have got a serious problem, my database is in mount state, but when i try to start it up, it gives error datafile block corrupted file 'd:\path\system01.dbf'. these are backup file from last database, afer which os has been formated and reinstalled.
    these are files from oracle 9i R1 and i want to install it intom oracle 9i R2.is it ok or i have to install oracle 9i R1 for making database up?
    plz help what should i do???
    thanks and regards
    VD

    ya its true,
    its not consistent backup.its not RMAN backup.i just have files >DBF,controlfiles and redo log files.
    now i am asked to retrieve data from these files.i have rebuild the database, and mounted it.but it is not getting opened.
    if i use 'ALTER DATABASE OPEN RESETLOGS' it takes too much time but dosent open.
    thats the issue.
    SQL> ALTER DATABASE OPEN RESETLOGS;
    ALTER DATABASE OPEN RESETLOGS
    ERROR at line 1:
    ORA-01190: controlfile or data file 2 is from before the last RESETLOGS
    ORA-01110: data file 2: 'D:\ORACLE\ORADATA\ORACLE\UNDOTBS01.DBF'
    alert log file entry:-
    Mon Nov 17 15:59:49 2008
    ORA-1589 signalled during: ALTER DATABASE OPEN..
    Mon Nov 17 16:00:06 2008
    RESETLOGS after incomplete recovery UNTIL CHANGE 81553193
    Resetting resetlogs activation ID 0 (0x0)
    Mon Nov 17 16:00:21 2008
    Errors in file D:\ORACLE\admin\ORACLE\udump\ORA02204.TRC:
    ORA-01110: data file 2: 'D:\ORACLE\ORADATA\ORACLE\UNDOTBS01.DBF'
    ORA-01114: IO error writing block to file 2 (block # 1)
    ORA-27041: unable to open file
    OSD-04002: unable to open file
    O/S-Error: (OS 5) Access is denied.
    Mon Nov 17 16:00:22 2008
    now tell me what should i do??
    thanks and regards
    VD

  • System datafile block corruption - no backups and database in NOARCHIVELOG mode

    Dear All,
    Database version - oracle 11.1 Enterprise
    OS - RHELinux 5.8
    What are the options of recovering from physical block corruption when there are no backup available to perform block media recovery?
    V$DATABASE_BLOCK_CORRUPTION reports two segments corrupted (please see attached image for details).
    1 table in system datafile - sys_fba_barrierscn
    1 index - (applicaiton index)
    What are my options?
    I know there is a possibility that the database will not restart after a shutdown due to corruption in system tablespace.
    Database is in noarchivelog mode. So online backups are not possible and there aren't any full backups either.
    I am thinking of below,
    1. Run dbms_repair with fix_block_corruption. - Still database startup might fail?
    2. Shutdown the database and take offline full backup with RMAN MAXCorrupt option.
    Appreciate your suggestions and advises.
    Thanks
    Stefan

    Thanks Sybrand,
    Agree with your first two suggestions .
    Also scheduled a expdp job tonight. (Only backup like thing they had was a expdp cron, but until today all the large tables were failing due to small undo_retention).
    Yes. Flashback is not used. So hopefully it will not affect the a database restart i guess?
    Related to dbms_repair, I was referring to - http://askdba.org/weblog/2010/08/physical-corruption-ora-1578-part-3/.
    Where DBMS_REPAIR.FIX_CORRUPT_BLOCKS and DBMS_REPAIR.SKIP_CORRUPT_BLOCKS used.
    Which i think will not use any redo.
    Thanks
    Stefan

  • Backup incremental level 1 for recover of copy datafile (BLOCKING?)

    Hi,
    I recently added a datafile copy backup to the backup strategy. This is an extra backup to supplement compressed backupsets.
    The datafile copy incremental was set to run at 5 am. I noticed that a process that was set to run at the same time as the backup stalled. It normally takes a few minutes to run but it took over an hour. Enterprise Manager did not report any blocked sessions over this hour (EM is configured to do so). No notable CPU spike either during this time. this morning I have moved the datafile copy backup to
    a different time so as to avoid the 5 am job and sure enough that job completed in 6 minutes.
    Does backup incremental for recover block in some way?
    Thanks!

    The other job loads data via sql loader and PL/SQL
    Actually, no blocking was detected. I could not check the waits since the job was done by the time I was aware that there was a problem. Rescheduling the backup seems to have avoided the problem. It happened twice though. I am unaware that a backup might cause this behavior. I suspect that the "for recover" might be the source of the updates being suspended. I would not expect that though since the backup copy is being recovered (not the actual datafile)

  • 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.

    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.

  • 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

  • Export/Import from Oracle8 to Oracle7

    When I export tables from an Oracle8 database it says after exporting sucessfully: "Export done in WE8ISO8859P1 character set and WE8ISO8859P1 NCHAR character set".
    (NLS_LANG = GERMAN_GERMANY.we8iso8859p1
    at both systems.)
    When I try to import the dumpfile in an Oracle7 database I get an error message:
    IMP-00038: Could not find environment character set handle
    IMP-00021: operating system error - error code (dec 2, hex 0x2)
    I don't get these errors when I export from the Oracle7 database and import to Oracle7.
    What can I do to solve the problem?
    Frank

    For Oracle8 export dump file, there may contain new feature
    for Oracle8 that cannot be recognized by Oracle 7. In order to export from
    Oracle8 and import into Oracle7, Oracle8 needs to be set to Oracle7 mode so
    that no new feature for Oracle8 will be export into the dump file.

  • 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.

  • SCN in blocks and datafile headers

    When CKPT updates datafiles headers with the new SCN is it also updates the datafiles blocks with the new SCN ?
    Thank you,
    Micheal.

    imran khan wrote:
    The SCN are not stored the datafile blocks in fact it stores the SCNs in terms of bitmaps..Cheers!An absolutely wrong statement! How you think that the transaction within a block would come to know that its committed or not if there is no SCN stored in the block?
    See below the dump of a block and also the SCN info recorded in it,
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    SQL> select header_file, header_block from dba_segments where segment_name='EMP'
      2  ;
    HEADER_FILE HEADER_BLOCK
              4          234
    SQL> select blocks from dba_segments where segment_name='EMP' and owner='SCOTT';
        BLOCKS
             8
    SQL> alter session set tracefile_identifier=myblockd;
    Session altered.
    SQL> alter system dump datafile 4 block 235;
    System altered.
    SQL> exit
    Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Windows XP Version V5.1 Service Pack 2
    CPU                 : 2 - type 586
    Process Affinity    : 0x0x00000000
    Memory (Avail/Total): Ph:437M/2045M, Ph+PgF:1335M/3428M, VA:1663M/2047M
    Instance name: orcl
    Redo thread mounted by this instance: 1
    Oracle process number: 30
    Windows thread id: 4596, image: ORACLE.EXE (SHAD)
    *** 2011-08-21 17:40:49.781
    *** SESSION ID:(16.6) 2011-08-21 17:40:49.781
    *** CLIENT ID:() 2011-08-21 17:40:49.781
    *** SERVICE NAME:(SYS$USERS) 2011-08-21 17:40:49.781
    *** MODULE NAME:(sqlplus.exe) 2011-08-21 17:40:49.781
    *** ACTION NAME:() 2011-08-21 17:40:49.781
    Start dump data blocks tsn: 4 file#:4 minblk 235 maxblk 235
    Block dump from cache:
    Dump of buffer cache at level 4 for tsn=4, rdba=16777451
    Block dump from disk:
    buffer tsn: 4 rdba: 0x010000eb (4/235)
    scn: 0x0000.002c106e seq: 0x05 flg: 0x04 tail: 0x106e0605
    frmt: 0x02 chkval: 0xed5f type: 0x06=trans data
    Hex dump of block: st=0, typ_found=1There is for sure, a block level SCN that oracle maintains .
    Aman....

  • Data corrupt block

    os Sun 5.10 oracle version 10.2.0.2 RAC 2 node
    alert.log 내용
    Hex dump of (file 206, block 393208) in trace file /oracle/app/oracle/admin/DBPGIC/udump/dbpgic1_ora_1424.trc
    Corrupt block relative dba: 0x3385fff8 (file 206, block 393208)
    Bad header found during backing up datafile
    Data in bad block:
    type: 32 format: 0 rdba: 0x00000001
    last change scn: 0x0000.98b00394 seq: 0x0 flg: 0x00
    spare1: 0x1 spare2: 0x27 spare3: 0x2
    consistency value in tail: 0x00000001
    check value in block header: 0x0
    block checksum disabled
    Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
    Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
    Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
    Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
    Reread of blocknum=393208, file=/dev/md/vg_rac06/rdsk/d119. found same corrupt data
    corrupt 발생한 Block id 를 검색해 보면 Block id 가 검색이 안됩니다.
    dba_extents 로 검색
    corrupt 때문에 Block id 가 검색이 안되는 것인지 궁금합니다.
    export 받으면 데이타는 정상적으로 export 가능.

    다행이네요. block corruption 이 발생한 곳이 데이터가 저장된 블록이
    아닌 것 같습니다. 그것도 rman백업을 통해서 발견한 것 같는데
    맞는지요?
    scn이 scn: 0x0000.00000000 가 아닌
    0x0000.98b00394 인 것으로 봐서는 physical corrupt 가 아닌
    soft corrupt인 것 같습니다.
    그렇다면 버그일 가능성이 높아서 찾아보니
    Bug 4411228 - Block corruption with mixture of file system and RAW files
    의 버그가 발견되었습니다. 이것이 아닐 수도 있지만..
    이러한 block corruption에 대한 처리방법 및 원인분석은
    오라클(주)를 통해서 정식으로 요청하셔야 합니다.
    metalink를 통해서 SR 요청을 하십시오.
    export는 high water mark 이후의 block corruption을 찾아내지 못하고 이외에도
    아래 몇가지 경우에서도 찾아내지 못합니다.
    db verify( dbv)의 경우에는 physical corruption은 찾아내지 못하고
    soft block corruption만 찾아낼 수 있습니다.
    경험상 physical corruption 이 발생하였으나 /dev/null로
    datafile copy가 안되는데도 dbv로는 이 문제를 찾아내지
    못하였습니다.
    그렇다면 가장 좋은 방법은 rman 입니다. rman은 high water mark까지의
    데이터를 백업해주면서 전체 데이터파일에 대한 체크를 하기도 합니다.
    physical corruption뿐만 아니라 logical corruption도 체크를
    하니 점검하기로는 rman이 가장 좋은 방법이라 생각합니다.
    The Export Utility
    # Use a full export to check database consistency
    # Export performs a full scan for all tables
    # Export only reads:
    - User data below the high-water mark
    - Parts of the data dictionary, while looking up information concerning the objects being exported
    # Export does not detect the following:
    - Disk corruptions above the high-water mark
    - Index corruptions
    - Free or temporary extent corruptions
    - Column data corruption (like invalid date values)
    block corruption을 정상적으로 복구하는 방법은 restore 후에
    복구하는 방법이 있겠으나 이미 restore할 백업이 block corruption이
    발생했을 수도 있습니다. 그러므로 다른 서버에 restore해보고
    정상적인 datafile인 것을 확인 후에 실환경에 restore하는 것이 좋습니다.
    만약 백업본까지 block corruption이 발생하였거나 또는 시간적 여유가
    없을 경우에는 table을 move tablespace 또는 index rebuild를 통해서
    다른 테이블스페이스로 데이터를 옮겨두고 문제가 발생한 테이블스페이스를
    drop해버리고 재생성 하는 것이 좋을 것 같습니다.(지금 현재 데이터의
    손실은 없으니 move tablespace, rebuild index 방법이 좋겠습니다.
    Handling Corruptions
    Check the alert file and system log file
    Use diagnostic tools to determine the type of corruption
    Dump blocks to find out what is wrong
    Determine whether the error persists by running checks multiple times
    Recover data from the corrupted object if necessary
    Preferred resolution method: media recovery
    Handling Corruptions
    Always try to find out if the error is permanent. Run the analyze command multiple times or, if possible, perform a shutdown and a startup and try again to perform the operation that failed earlier.
    Find out whether there are more corruptions. If you encounter one, there may be other corrupted blocks, as well. Use tools like DBVERIFY for this.
    Before you try to salvage the data, perform a block dump as evidence to identify the actual cause of the corruption.
    Make a hex dump of the bad block, using UNIX dd and od -x.
    Consider performing a redo log dump to check all the changes that were made to the block so that you can discover when the corruption occurred.
    Note: Remember that when you have a block corruption, performing media recovery is the recommended process after the hardware is verified.
    Resolve any hardware issues:
    - Memory boards
    - Disk controllers
    - Disks
    Recover or restore data from the corrupt object if necessary
    Handling Corruptions (continued)
    There is no point in continuing to work if there are hardware failures. When you encounter hardware problems, the vendor should be contacted and the machine should be checked and fixed before continuing. A full hardware diagnostics should be run.
    Many types of hardware failures are possible:
    Bad I/O hardware or firmware
    Operating system I/O or caching problem
    Memory or paging problems
    Disk repair utilities
    아래 관련 자료를 드립니다.
    All About Data Blocks Corruption in Oracle
    Vijaya R. Dumpa
    Data Block Overview:
    Oracle allocates logical database space for all data in a database. The units of database space allocation are data blocks (also called logical blocks, Oracle blocks, or pages), extents, and segments. The next level of logical database space is an extent. An extent is a specific number of contiguous data blocks allocated for storing a specific type of information. The level of logical database storage above an extent is called a segment. The high water mark is the boundary between used and unused space in a segment.
    The header contains general block information, such as the block address and the type of segment (for example, data, index, or rollback).
    Table Directory, this portion of the data block contains information about the table having rows in this block.
    Row Directory, this portion of the data block contains information about the actual rows in the block (including addresses for each row piece in the row data area).
    Free space is allocated for insertion of new rows and for updates to rows that require additional space.
    Row data, this portion of the data block contains rows in this block.
    Analyze the Table structure to identify block corruption:
    By analyzing the table structure and its associated objects, you can perform a detailed check of data blocks to identify block corruption:
    SQL> analyze table_name/index_name/cluster_name ... validate structure cascade;
    Detecting data block corruption using the DBVERIFY Utility:
    DBVERIFY is an external command-line utility that performs a physical data structure integrity check on an offline database. It can be used against backup files and online files. Integrity checks are significantly faster if you run against an offline database.
    Restrictions:
    DBVERIFY checks are limited to cache-managed blocks. It’s only for use with datafiles, it will not work against control files or redo logs.
    The following example is sample output of verification for the data file system_ts_01.dbf. And its Start block is 9 and end block is 25. Blocksize parameter is required only if the file to be verified has a non-2kb block size. Logfile parameter specifies the file to which logging information should be written. The feedback parameter has been given the value 2 to display one dot on the screen for every 2 blocks processed.
    $ dbv file=system_ts_01.dbf start=9 end=25 blocksize=16384 logfile=dbvsys_ts.log feedback=2
    DBVERIFY: Release 8.1.7.3.0 - Production on Fri Sep 13 14:11:52 2002
    (c) Copyright 2000 Oracle Corporation. All rights reserved.
    Output:
    $ pg dbvsys_ts.log
    DBVERIFY: Release 8.1.7.3.0 - Production on Fri Sep 13 14:11:52 2002
    (c) Copyright 2000 Oracle Corporation. All rights reserved.
    DBVERIFY - Verification starting : FILE = system_ts_01.dbf
    DBVERIFY - Verification complete
    Total Pages Examined : 17
    Total Pages Processed (Data) : 10
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index) : 2
    Total Pages Failing (Index) : 0
    Total Pages Processed (Other) : 5
    Total Pages Empty : 0
    Total Pages Marked Corrupt : 0
    Total Pages Influx : 0
    Detecting and reporting data block corruption using the DBMS_REPAIR package:
    Note: Note that this event can only be used if the block "wrapper" is marked corrupt.
    Eg: If the block reports ORA-1578.
    1. Create DBMS_REPAIR administration tables:
    To Create Repair tables, run the below package.
    SQL> EXEC DBMS_REPAIR.ADMIN_TABLES(‘REPAIR_ADMIN’, 1,1, ‘REPAIR_TS’);
    Note that table names prefix with ‘REPAIR_’ or ‘ORPAN_’. If the second variable is 1, it will create ‘REAIR_key tables, if it is 2, then it will create ‘ORPAN_key tables.
    If the thread variable is
    1 then package performs ‘create’ operations.
    2 then package performs ‘delete’ operations.
    3 then package performs ‘drop’ operations.
    2. Scanning a specific table or Index using the DBMS_REPAIR.CHECK_OBJECT procedure:
    In the following example we check the table employee for possible corruption’s that belongs to the schema TEST. Let’s assume that we have created our administration tables called REPAIR_ADMIN in schema SYS.
    To check the table block corruption use the following procedure:
    SQL> VARIABLE A NUMBER;
    SQL> EXEC DBMS_REPAIR.CHECK_OBJECT (‘TEST’,’EMP’, NULL,
    1,’REPAIR_ADMIN’, NULL, NULL, NULL, NULL,:A);
    SQL> PRINT A;
    To check which block is corrupted, check in the REPAIR_ADMIN table.
    SQL> SELECT * FROM REPAIR_ADMIN;
    3. Fixing corrupt block using the DBMS_REPAIR.FIX_CORRUPT_BLOCK procedure:
    SQL> VARIABLE A NUMBER;
    SQL> EXEC DBMS_REPAIR.FIX.CORRUPT_BLOCKS (‘TEST’,’EMP’, NULL,
    1,’REPARI_ADMIN’, NULL,:A);
    SQL> SELECT MARKED FROM REPAIR_ADMIN;
    If u select the EMP table now you still get the error ORA-1578.
    4. Skipping corrupt blocks using the DBMS_REPAIR. SKIP_CORRUPT_BLOCK procedure:
    SQL> EXEC DBMS_REPAIR. SKIP_CORRUPT.BLOCKS (‘TEST’, ‘EMP’, 1,1);
    Notice the verification of running the DBMS_REPAIR tool. You have lost some of data. One main advantage of this tool is that you can retrieve the data past the corrupted block. However we have lost some data in the table.
    5. This procedure is useful in identifying orphan keys in indexes that are pointing to corrupt rows of the table:
    SQL> EXEC DBMS_REPAIR. DUMP ORPHAN_KEYS (‘TEST’,’IDX_EMP’, NULL,
    2, ‘REPAIR_ADMIN’, ‘ORPHAN_ADMIN’, NULL,:A);
    If u see any records in ORPHAN_ADMIN table you have to drop and re-create the index to avoid any inconsistencies in your queries.
    6. The last thing you need to do while using the DBMS_REPAIR package is to run the DBMS_REPAIR.REBUILD_FREELISTS procedure to reinitialize the free list details in the data dictionary views.
    SQL> EXEC DBMS_REPAIR.REBUILD_FREELISTS (‘TEST’,’EMP’, NULL, 1);
    NOTE
    Setting events 10210, 10211, 10212, and 10225 can be done by adding the following line for each event in the init.ora file:
    Event = "event_number trace name errorstack forever, level 10"
    When event 10210 is set, the data blocks are checked for corruption by checking their integrity. Data blocks that don't match the format are marked as soft corrupt.
    When event 10211 is set, the index blocks are checked for corruption by checking their integrity. Index blocks that don't match the format are marked as soft corrupt.
    When event 10212 is set, the cluster blocks are checked for corruption by checking their integrity. Cluster blocks that don't match the format are marked as soft corrupt.
    When event 10225 is set, the fet$ and uset$ dictionary tables are checked for corruption by checking their integrity. Blocks that don't match the format are marked as soft corrupt.
    Set event 10231 in the init.ora file to cause Oracle to skip software- and media-corrupted blocks when performing full table scans:
    Event="10231 trace name context forever, level 10"
    Set event 10233 in the init.ora file to cause Oracle to skip software- and media-corrupted blocks when performing index range scans:
    Event="10233 trace name context forever, level 10"
    To dump the Oracle block you can use below command from 8.x on words:
    SQL> ALTER SYSTEM DUMP DATAFILE 11 block 9;
    This command dumps datablock 9 in datafile11, into USER_DUMP_DEST directory.
    Dumping Redo Logs file blocks:
    SQL> ALTER SYSTEM DUMP LOGFILE ‘/usr/oracle8/product/admin/udump/rl. log’;
    Rollback segments block corruption, it will cause problems (ORA-1578) while starting up the database.
    With support of oracle, can use below under source parameter to startup the database.
    CORRUPTEDROLLBACK_SEGMENTS=(RBS_1, RBS_2)
    DB_BLOCK_COMPUTE_CHECKSUM
    This parameter is normally used to debug corruption’s that happen on disk.
    The following V$ views contain information about blocks marked logically corrupt:
    V$ BACKUP_CORRUPTION, V$COPY_CORRUPTION
    When this parameter is set, while reading a block from disk to catch, oracle will compute the checksum again and compares it with the value that is in the block.
    If they differ, it indicates that the block is corrupted on disk. Oracle makes the block as corrupt and signals an error. There is an overhead involved in setting this parameter.
    DB_BLOCK_CACHE_PROTECT=‘TRUE’
    Oracle will catch stray writes made by processes in the buffer catch.
    Oracle 9i new RMAN futures:
    Obtain the datafile numbers and block numbers for the corrupted blocks. Typically, you obtain this output from the standard output, the alert.log, trace files, or a media management interface. For example, you may see the following in a trace file:
    ORA-01578: ORACLE data block corrupted (file # 9, block # 13)
    ORA-01110: data file 9: '/oracle/dbs/tbs_91.f'
    ORA-01578: ORACLE data block corrupted (file # 2, block # 19)
    ORA-01110: data file 2: '/oracle/dbs/tbs_21.f'
    $rman target =rman/rman@rmanprod
    RMAN> run {
    2> allocate channel ch1 type disk;
    3> blockrecover datafile 9 block 13 datafile 2 block 19;
    4> }
    Recovering Data blocks Using Selected Backups:
    # restore from backupset
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 FROM BACKUPSET;
    # restore from datafile image copy
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 FROM DATAFILECOPY;
    # restore from backupset with tag "mondayAM"
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 199 FROM TAG = mondayAM;
    # restore using backups made before one week ago
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE
    UNTIL 'SYSDATE-7';
    # restore using backups made before SCN 100
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE UNTIL SCN 100;
    # restore using backups made before log sequence 7024
    BLOCKRECOVER DATAFILE 9 BLOCK 13 DATAFILE 2 BLOCK 19 RESTORE
    UNTIL SEQUENCE 7024;
    글 수정:
    Min Angel (Yeon Hong Min, Korean)

  • 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...

Maybe you are looking for