Re: Corrupt block message in alert log

Hello,

You have to check the objects inside the tablespace corrupted.

• Persistents objects like table and indexes ******** In the DBA_TABLES and DBA_INDEXES, you have the TABLESPACE_NAME column, and you have to check this objects with analyze :

ANALYZE TABLE xxxx COMPUTE STATISTICS;

ANALYZE INDEX xxxx COMPUTE STATISTICS;

If some indexs are corrupted : you drop and recreate them.

If tables are corrupted : problems, problems !! if you have a recent export file : you drop the table and import it.

If you have an database in archive log mode : * shutdown the database
* restore the files of THE tablespace corrupted (not all the tablespaces) and the archived log files
* startup mount
* recover tablespace

• rollbacks ******** If the objects are rollback segments : * you have to drop the rollback * drop the tablespaces * shutdown the database * delete the files of the tablespace * startup the database * create the tablespace * create the rollbacks segment

Good luck

Regards

"Lynux" <lynux_at_netvigator.com> a écrit dans le message news: 93q7ia$l4135_at_imsp212.netvigator.com...
> Recently, we found the following message appearred in our alert_<SID>.log
> file.
>
>
> ***
> Corrupt block relative dba: 0x1e403ac6 file=121. blocknum=15046.
> Fractured block found during direct read
> Data in bad block - type:8. format:2. rdba:0x1e403ac8
> last change scn:0x0000.382b9618 seq:0x1 flg:0x08
> consistancy value in tail 0x96840801
> check value in block header: 0x0, check value not calculated
> spare1:0x0, spare2:0x0, spare2:0x0
> ***
> Corrupt block relative dba: 0x1e403ac8 file=121. blocknum=15048.
> Fractured block found during direct read
> Data in bad block - type:8. format:2. rdba:0x1e403ac8
> last change scn:0x0000.382b9618 seq:0x1 flg:0x08
> consistancy value in tail 0x96840801
> check value in block header: 0x0, check value not calculated
> spare1:0x0, spare2:0x0, spare2:0x0
>
>
> However, when we try to see any problem on the corresponding tablespace,
> the result is everything normal. The size reported in system view is the
> same as before. The 'v$recover_file' return no datafile need to be
> repaired. The 'alter system check datafiles;' return everything are
> normal.
>
> Do anyone know what's the problem on these messages. Please help and
> advice. Thank You Very Much!
> Thanks in Advance!
>
Received on Sat Jan 13 2001 - 13:32:19 CST