Corrupt blocks in the LOB segment 11.2.0.2

Hello,
at a dbexport we found corrupted blocks in a LOB-Segment. Then we start rman and do a backup validate check logical database, nothing, rman didn't found any corruption. meanwhile we have repaired the LOB-Segment with restore, now all is ok. But we are confused about this situation, why did rman not found the corruption ? we are making backups with rman (with parameter check logical) and we think rman found logical data corruption. should we now make daily an export to dev_null that we found any corruption.It would be very nice if someone had an answer for us.
thanks very much

As far as I know rman validate backup only check for corrupted blocks among database blocks which are used at least once(i.e. used, or free-but at least once used before). For not used blocks RMAN will not report any block corruption.
The alternate approach could be using dbv utility(Database verification utility)

Similar Messages

LOB segment size is 2 times bigger than the real data

here's an interesting test:
1. I created a tablespace called "smallblock" with 2K blocksize
2. I created a table with a CLOB type field and specified the smallblock tablespace as a storage for the LOB segment:
SCOTT@andrkydb> create table t1 (i int, b clob) lob (b) store as
t1_lob (chunk 2K disable storage in row tablespace smallblock);
3. I insert data into the table, using a bit less than 2K of data for the clob type column:
SCOTT@andrkydb> begin
2 for i in 1..1000 loop
3 insert into t1 values (mod(i,5), rpad('*',2000,'*'));
4 end loop;
5 end;
6 /
4. Now I can see that I have an average of 2000 bytes for each lob item:
SCOTT@andrkydb> select avg(dbms_lob.getlength(b)) from t1;
AVG(DBMS_LOB.GETLENGTH(B))
2000
and that all together they take up:
SCOTT@andrkydb> select sum(dbms_lob.getlength(b)) from t1;
SUM(DBMS_LOB.GETLENGTH(B))
2000000
But when I take a look at how much is the LOB segment actually taking, I get a result, which is being a total mystery to me:
SCOTT@andrkydb> select bytes from dba_segments where segment_name = 'T1_LOB';
BYTES
5242880
What am I missing? Why is LOB segment is being ~2 times bigger than it is required by the data?
I am on 10.2.0.3 EE, Solaris 5.10 sparc 64bit.
Message was edited by:
Andrei Kübar

thanks for the link, it is good to know such thing is possible. Although I don't really see how can it help me..
But you know, you were right regarding the smaller data amounts. I have tested with 1800 bytes of data and in this case it does fit just right.
But this means that there is 248 bytes wasted (from my, as developer, point of view) per block! But if there is such an overhead, then I must be able to estimate it when designing the data structures. And I don't see anywhere in the docs a single word about such thing.
Moreover, if you use NCLOB type, then only 990 bytes fits into a single 2K chunk. So the overhead might become really huge when you go over to gigabyte amounts...
I have a LOB segment for a nclob type field in a production database, which is 5GB large and it contains only 2,2GB of real data. There is no "deleted" rows in it, I know because I have rebuilt it. So this looks like a total waste of disk space... I must say, I'm quite disappointed with this.
- Andrei

Truncate table will delete the corresponding LOB segment of table or not ?

Hi All,
I have few table with LOB segments, if i fire the truncate table on those table will it purge the LOB segment as well ?
Approximately how much time will take to truncate 100gb LOB segments.
Thanks

903787 wrote:
Hi ,
1.Truncate will delete the LOB segment or not ?It won't delete the LOB segments but it should release most of the allocated space.
>
2.To reclaim space we need to run the below command, is it correct ?
ALTER TABLE <table_name> MODIFY LOB (LOB_COLUMN) (SHRINK SPACE);
Should not be needed in 11.2:
SQL> select * from v$version;
BANNER
Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production
PL/SQL Release 11.2.0.2.0 - Production
CORE    11.2.0.2.0      Production
TNS for 32-bit Windows: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
SQL> select count(*) from user_segments;
COUNT(*)
         0
SQL>
SQL> create table t(x clob);
Table created.
SQL> select segment_name, segment_type, bytes
2 from user_segments;
SEGMENT_NAME                             SEGMENT_TYPE            BYTES
T                                        TABLE                   65536
SYS_IL0000030908C00001$$                 LOBINDEX                65536
SYS_LOB0000030908C00001$$                LOBSEGMENT              65536
SQL>
SQL> insert into t select lpad(segment_name,8192) from dba_segments;
6312 rows created.
SQL> commit;
Commit complete.
SQL>
SQL> select segment_name, segment_type, bytes
2 from user_segments;
SEGMENT_NAME                             SEGMENT_TYPE            BYTES
T                                        TABLE                  393216
SYS_IL0000030908C00001$$                 LOBINDEX                65536
SYS_LOB0000030908C00001$$                LOBSEGMENT           53477376
SQL>
SQL> truncate table t;
Table truncated.
SQL>
SQL> select segment_name, segment_type, bytes
2 from user_segments;
SEGMENT_NAME                             SEGMENT_TYPE            BYTES
T                                        TABLE                   65536
SYS_IL0000030908C00001$$                 LOBINDEX                65536
SYS_LOB0000030908C00001$$                LOBSEGMENT              65536
SQL>
SQL> alter table t modify lob(x) (shrink space);
Table altered.
SQL>
SQL> select segment_name, segment_type, bytes
2 from user_segments;
SEGMENT_NAME                             SEGMENT_TYPE            BYTES
T                                        TABLE                   65536
SYS_IL0000030908C00001$$                 LOBINDEX                65536
SYS_LOB0000030908C00001$$                LOBSEGMENT              65536
SQL>

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)

Problem creating LOB segment

Hi all,
I'm working with 11gR2 version in RAC environment with 2 nodes. I'm creating the schemes on my new database with empty tablespaces and 100Mb of initial free space. I'm having an error on the creation of this table:
CREATE TABLE "IODBODB1"."DOCUMENTOS"
(     "ID_DOC" NUMBER NOT NULL ENABLE,
     "ID_APP" NUMBER(5,0) NOT NULL ENABLE,
     "ID_CLS" NUMBER(6,0) NOT NULL ENABLE,
     "CREATE_FEC" DATE NOT NULL ENABLE,
     "LAST_MODIFIED_FEC" DATE NOT NULL ENABLE,
     "DOC_NAME" VARCHAR2(100 BYTE) NOT NULL ENABLE,
     "DOC_SIZE" NUMBER NOT NULL ENABLE,
     "DOC_DATA" BLOB NOT NULL ENABLE,
     "CLASE_FORMATO_FORMATO" VARCHAR2(150 BYTE),
     "REGULAR_NAME" VARCHAR2(100 BYTE) NOT NULL ENABLE,
     "USUARIO" VARCHAR2(25 BYTE),
     "USUARIO_LEVEL" VARCHAR2(5 BYTE)
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 STORAGE(BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "ODBODB_TBD_DADES"
LOB ("DOC_DATA") STORE AS BASICFILE (ENABLE STORAGE IN ROW CHUNK 8K PCTVERSION 10 NOCACHE LOGGING STORAGE( BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT))
PARTITION BY LIST ("ID_APP")
SUBPARTITION BY RANGE ("ID_DOC")
PARTITION "PTL_DOCUMENTOS_FICTICIO" VALUES (0) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE(BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "ODBODB_TBD_DADES"
LOB ("DOC_DATA") STORE AS BASICFILE (ENABLE STORAGE IN ROW CHUNK 8K PCTVERSION 10 NOCACHE LOGGING STORAGE(BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT))
(SUBPARTITION "PTR_DOCUMENTOS_FICTICIO" VALUES LESS THAN (MAXVALUE) LOB ("DOC_DATA") STORE AS (TABLESPACE "ODBODB_TBL_LOBS" ) TABLESPACE "ODBODB_TBD_DADES" NOCOMPRESS ) );
PARTITION "PTL_DOCUMENTOS_ALFIMG" VALUES (2) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE(BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "ODBODB_TBD_DADES"
LOB ("DOC_DATA") STORE AS BASICFILE (ENABLE STORAGE IN ROW CHUNK 32K PCTVERSION 10 NOCACHE LOGGING STORAGE(BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT))
(SUBPARTITION "STR_DOCUMENTOS_ALFIMG" VALUES LESS THAN (MAXVALUE) LOB ("DOC_DATA") STORE AS (TABLESPACE "BEALFIMG_TBL_ODB" ) TABLESPACE "BEALFIMG_TBD_ODB" NOCOMPRESS )
The error is:
ORA-03252: initial extent size not enough for LOB segment
I can't understand how Oracle can't allocate enough extents to create the LOB segment, and I don't know to which LOB segment it refers because the sqlplus don't mark it with the error.
Any ideas about this issue?
Thanks in advance!
dbajug

Please, forget this post, I feel dumb... The LOB segment need to have same size of the rest of partition...

DB Recovery due to corrupt block in redologfile

Hello.
A block was corrupted in the redo log file # 2 and I don't have backup.
So I tried recovering the database using the RECOVER DATABASE until a specified change #. The database required me to use the RECOVER DATABASE USING BACKUP CONTROLFILE instead. This command asked for a filename of a redo logfile. I entered the filename of redo log#1 since log#2 contained the corrupted block.
The recovery wasn't successful. The error messages stated that the recovery required the sequence #333 but redo log#1 contained the sequence #332. I later found out that redo log#2 contained the sequence #333.
Basically, the scenario is this: according ora-00279, the recovery requires the sequence #333 found in redolog#2 which contains the corrupted block. When i try recovery i get the ora-01194 error plus the ora-01112: media recovery not started
is there still hope in recovering the database?
Thanks in advance

Well i think you can only recover up to scn #332 using log#1.
If your redo members are not multiplexed you have lost some data.
Acr

Corrupt Block and Standby Database

Guys,
I created a standby database recently. I then discovered a corrupt block on my primary, I assume the corruption is also on the standby since the files were coppied. If I repair the corrupt block on the primary how do I move the correction to the standby, do I have to recreate it?
DB version is 9iR2
Delton

Hi Delton,
How do you plan to repair the corrupt block ?
* Drop and re-create the object
* Restore from backup
In both cases, changes are replicated to the standby database, so nothing to worry about. As Sybrand has mentioned, make sure the changes are done with LOGGING option.
Regards
Asif Momen
http://momendba.blogspot.com

Move LOB segment

Oracle 11.0.1.7:
How can I move the lob segment: I am trying this
CREATE TABLE PART_TMP(
PAYLOAD_ID Number(19,0) NOT NULL,
created_date timestamp(6),
pay blob
LOB ("PAY") STORE AS (DISABLE STORAGE IN ROW TABLESPACE EFE_LOB)
PARTITION BY RANGE (payload_id)
interval (2)
SUBPARTITION BY HASH (payload_id)
SUBPARTITIONS 64(PARTITION PART_TMP_p00 VALUES LESS THAN (1));
alter table part_tmp move subpartition SYS_SUBP28243 update indexes; --This works
--But this doesn't work. Is this the right way of moving LOB segment? Looks like Lobs segment doesn't move with above command.
alter table part_tmp move LOB(pay) subpartition SYS_SUBP28243 update indexesI need to move SUBPARTTION and associated LOB SUBPARTITION. Could someone please help?

There is a table which has a LOB and there are lot of deletes and updates happening daily .
I need to shrink the space. When I use:
alter table lob_test modify lob (data) (shrink space);
It throws an error cannot use shrink clause on this table. Table as no function based indexes and segment space management for this tablespace is auto.
Can any one tell what is the best approach to reclaim the space.
Can any one tell can I use the alter table move online or needs downtime.
Thanks

Corrupted block rman

Hi
As far as I know, if rman finds block corruption, it will terminate the backup session.
However, in my scenerio, rman skipped the corrupted block and continue taking backup of remaining datafiles.
What is the reason for this?
Note that, I didnt use maxcorrupt in rman script.
The below is the end of the logfile:
channel t4: backup set complete, elapsed time: 01:02:50
released channel: t1
released channel: t2
released channel: t3
released channel: t4
released channel: t5
released channel: t6
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on t2 channel at 03/20/2010 17:29:52
ORA-19566: exceeded limit of 0 corrupt blocks for file /dbs02/prd/mis_refrence.dbf01
Recovery Manager complete.

Hi,
RMAN is terminated only when it does not find the data file etc. But it does not terminate due to block corruption.
See the following excerpts from the following oracle document link.
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10734/rcmconc1.htm#1016108
RMAN detects and responds to two primary types of backup errors: I/O errors and corrupt blocks. Any I/O errors that RMAN encounters when reading files or writing to the backup pieces or image copies cause RMAN to terminate the backup jobs. For example, if RMAN tries to back up a datafile but the datafile is not on disk, then RMAN terminates the backup. If multiple channels are being used, or redundant copies of backups are being created, RMAN may be able to continue the backup without user intervention.
If BACKUP AS BACKUPSET creates more than one complete backup set and an error occurs, then RMAN needs to rewrite the backup sets that it was writing at the time of the error. However, it retains any backup sets that it successfully wrote before terminating. The NOT BACKED UP SINCE option of the BACKUP command restarts a backup that partially completed, backing up only files that did not get backed up.
RMAN copies datafile blocks that are already identified as corrupt into the backup. If RMAN encounters datafile blocks that have not already been identified as corrupt, then RMAN stops the backup unless SET MAXCORRUPT has been used. Setting MAXCORRUPT allows a specified number of previously undetected block corruptions in datafiles during the execution of an RMAN BACKUP command. If RMAN detects more than this number of corruptions while taking the backup, then the command terminates. The default limit is zero, meaning that RMAN does not tolerate corrupt blocks by default.
When RMAN finds corrupt blocks, until it finds enough to exceed the MAXCORRUPT limit, it writes the corrupt blocks to the backup with a reformatted header indicating that the block has media corruption. If the backup completes without exceeding MAXCORRUPT,then the database records the address of the corrupt blocks and the type of corruption in the control file. Access these records through the V$DATABASE_BLOCK_CORRUPTION view. Note that if more than MAXCORRUPT corrupt blocks are found, the V$DATABASE_BLOCK_CORRUPTION view is not populated. In such a case, you should set MAXCORRUPT higher and re-run the command to identify the corrupt blocks.
Regards
Edited by: skvaish1 on Mar 24, 2010 4:39 PM

Performance of LOB Segments for Blob Columns

Hi,
I am migrating 11,000 rows of tiff images from Informix to Oracle.In Informix the datatype for the image storage is Byte and Oracle we chose it to Blob.
The Blob column is creating lob segment and lob index.
When I do the migration I observe that the size of the lob segment object is increasing rather than the table object.
So due to creation of this lob segment for the Blob column,will there be any performance issues while retrieval of images from the database and Inserting images into into the database.
Can I get all the issues that can be encountered by storing data in blob column in terms of lob segment.
This is very important information for us as the application has lot of SQL queries for retrieving and injecting images in the database.
It will be really apprecialbe if you can provide Information about this.
Thanks & Regards
Ramanathan KrishnaMurthy

I agree with D.Morgan that object type with 250 attributes is doubtful.
I don't like object tables (tables with "row objects") too.
But, your table is a relational table with object column ("column object").
C.J.Date in An introduction to Database Systems (2004, page 885) says:
"... object/relational systems ... are, or should be, basically just relational systems
that support the relational domain concept (i.e., types) properly - in other words, true relational systems,
meaning in particular systems that allow users to define their own types."
1. How will Oracle store the data in the ADT column?...
For some answers see:
“OR(DBMS) or R(DBMS), That is the Question”
http://www.quest-pipelines.com/pipelines/plsql/tips.htm#OCTOBER
and (of course):
"Oracle® Database Application Developer's Guide - Object-Relational Features" 10g Release 2 (10.2)
http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14260/adobjadv.htm#i1006903
Regards,
Zlatko

Alter index ... rebuild was failing - getting corrupt blocks

Database: 9.2.0.5
OS: HPUX-ia64
Hello,
i rebuilded a index, announced from UpdatStats in DB13, and get a ORA-01114: IO error writing block to file 2045 (block # 319154) and
ORA-27072: skgfdisp: I/O error in my sqlplus session.
-> i do a alter index SAPR3."xxx~0" rebuild online parallel 4 nologging;
-> System was up and running
After that, the DBVerify marked some blocks corrupt, here one example:
BR0398E DBVERIFY detected corrupted blocks in /oracle/XXX/sapdata22/btabi_95/btabi.data95
We checked all corrupted blocks - all in free space.
So we fixed that with creating a table with next extend size from the corrupted blocksize.
I think we had not enough space in the tablespace where the index is, okay ... and what we also found, the PSAPTEMP datafiles was created as SPARSE files ...!!
-> PSAPTEMP-Datafile: 10GB in the System - 2,5GB maximum on OS-Level, no more space.
But my question is why i am getting corrupt blocks when a "alter index ... rebuild ..." is failing ?!?!
Thank you for your support.
Regards,
Markus
Edited by: Markus Dinkel on Oct 9, 2008 12:56 PM
Edited by: Markus Dinkel on Oct 9, 2008 12:56 PM
Edited by: Markus Dinkel on Oct 9, 2008 12:59 PM

Thany you for the answer.
I cant find any "cor" entries in the last DBVeriy log.
I think (hope) we dont' have anymore corrupted blocks in the system.
We get a response from SAP to update to 9.2.0.8.
My customer wanna do a update to oracle 10 in march/april 2009, so he send me the question if we need a update to 9.2.0.8 ASAP or can we wait for the update to oralce10.
But the important question from my customer and me is, why we get corrupt blocks after failing the alter index rebuild?
Regards,
Markus

Dropping a Spatial LOB segment

Hi guys,
I´m trying to reduce the size of my datafile. but oracle spatial creates a LOB segment in this tablespace and I´m having trouble to move or drop it. Anybody here have any suggestion regarding this ?
the LOB segment is called SYS_IL0000078552C00003$$
Thanks in advance,
Felipe

Hi Felipe,
What do you exactly want to do? Reorganizing your tablespace or ...?
regards, Andreas
btw: The SYS_IL0000078552C00003$$ you can't rename! The name is different in any database.

Need to find the corrupted blocks.

Hi,
I am having blocks corruption(nologging) for the 11g database. Want to find the whether corrupted blocks are from indexes or from specific tables...

Thanx..
I am firing below query.
SELECT e.owner, e.segment_type, e.segment_name, e.partition_name, c.file#
, greatest(e.block_id, c.block#) corr_start_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1) corr_end_block#
, least(e.block_id+e.blocks-1, c.block#+c.blocks-1)
- greatest(e.block_id, c.block#) + 1 blocks_corrupted
, null description
FROM dba_extents e, v$database_block_corruption c
WHERE e.file_id = c.file#
AND e.block_id <= c.block# + c.blocks - 1
AND e.block_id + e.blocks - 1 >= c.block#
UNION
SELECT s.owner, s.segment_type, s.segment_name, s.partition_name, c.file#
, header_block corr_start_block#
, header_block corr_end_block#
, 1 blocks_corrupted
, 'Segment Header' description
FROM dba_segments s, v$database_block_corruption c
WHERE s.header_file = c.file#
AND s.header_block between c.block# and c.block# + c.blocks - 1
UNION
SELECT null owner, null segment_type, null segment_name, null partition_name, c.file#
, greatest(f.block_id, c.block#) corr_start_block#
, least(f.block_id+f.blocks-1, c.block#+c.blocks-1) corr_end_block#
, least(f.block_id+f.blocks-1, c.block#+c.blocks-1)
- greatest(f.block_id, c.block#) + 1 blocks_corrupted
, 'Free Block' description
FROM dba_free_space f, v$database_block_corruption c
WHERE f.file_id = c.file#
AND f.block_id <= c.block# + c.blocks - 1
AND f.block_id + f.blocks - 1 >= c.block#
order by file#, corr_start_block#;

Blocks corrupted always with the same checksum 0x400

Hello Oracle gurus,
Need your help with finding source of block corruption errors that we observe repeatedly on one system. See the error below.
Location of the corrupted block is always different, but the computed checksum is always 0x400. Only one block gets corrupted after a couple of days of stress testing. We completely re-install OS (RHEL4) and re-create DB. Still the same error with the same checksome appears, but in a different location. This happened 3 times already.
Does anybody know what 0x400 corresponds to? Is it all zeroes?
In my understanding, if the corruption was caused by a drive error, such as a single bit flip or several sectors corruption, then the computed checksum would be always different.
Is this correct? Any other ideas what can be the reason for such corruption?
Thanks a lot.
Hex dump of (file 9, block 357024) in trace file /u01/app/oracle/admin/pndb/udump/pndb_ora_13828.trc
Corrupt block relative dba: 0x024572a0 (file 9, block 357024)
Bad check value found during buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x024572a0
last change scn: 0x0000.00b31c70 seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x1c700601
check value in block header: 0xfcd0
computed block checksum: 0x400
Reread of rdba: 0x024572a0 (file 9, block 357024) found same corrupted data
Fri Apr 27 04:09:32 2007
Corrupt Block Found
TSN = 9, TSNAME = PN_TABL
RFN = 9, BLK = 357024, RDBA = 38105760
OBJN = 40738, OBJD = 40738, OBJECT = PN_EVENT_SESSION_1, SUBOBJECT =
SEGMENT OWNER = PNADMIN, SEGMENT TYPE = Table Segment

Well I understand that, however Oracle is running on higher level (application level).
It's hard to trace a potential lower level ( hardware level) problem in high level application.
The least thing you can try is find out which object this corrupted block belong if it's always same object or some pattarn you can tell then there might have something to do with Oracle.
If it's totally random then it's hard to say.
select segment_name,segment_type,owner
from sys.dba_extents
where file_id=(9)
and (357024) between block_id and block_id + blocks -1;

RMAN Skips the corrupted Block

Hi,
We are using Oracle 10.2.0.4 rman utility for backup, In SYSAUX tablespace, datafile 3, one block has been corrupted.
I have try to export the tablespace , i found warning message of "corrupted block and table name". But RMAN, while try to backup datafile 3, or validate the backup, it doesn't popu any error message and went through with out any problem.
==>I have set maxcorrupt 0 in run block
==> Check logical i have used
==> V$database_block_corruption pops the result but MAXCORRUPT 0.
==> But Analyis the table show the corrupted block error.
===> Try to select * from corrupted table. it throws the error message.
Please advice
Regards
Krish

Steve,
Thank you for the doc, But i have already mentioned,
--> i have tried from check logical
--> Also MaxCorrupt parameter
Am able to view the corrutped block information in database_block_corruption
but while backing with rman using
RMAN> run
2> {
3> set MAXCORRUPT for datafile 3 to 0;
4> backup datafile 3;
5> }
executing command: SET MAX CORRUPT
using target database control file instead of recovery catalog
Starting backup at 27-APR-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=12 instance=TEST devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00003 name=+DBFILE_GRP1/TEST/datafile/sysaux.499.667900479
channel ORA_DISK_1: starting piece 1 at 27-APR-09
channel ORA_DISK_1: finished piece 1 at 27-APR-09
piece handle=/usr/oradata/BKUP/TEST/backup/database/BIRTEF1_4229_1_1_45kdh7uj tag=TAG
comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15
Finished backup at 27-APR-09
Starting Control File and SPFILE Autobackup at 27-APR-09
Finished Control File and SPFILE Autobackup at 27-APR-09
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 23260 1 0 CORRUPT
3 123228 1 0 CORRUPT
ITs backing up with no issues. Thats the confusion here.
REgards
KRishnan

Corrupt blocks in the LOB segment 11.2.0.2

Similar Messages

Maybe you are looking for