Re: Corrupt block during backup Oracle 7.3.4

Others have supplied sufficient answers to address the symptom ... now lets talk about the problem.
If this database is critical to your business, work hard at being proactive in both system and database management. I hope you're sysadmin does wait two weeks (or more) to check for errors in the messages file.
Work with you sysadmin to build some simple shell scripts to check your alert log, export log, UDUMP directory, etc. for points of interest.

Also, since you know the block numbers that are corrupt, you can figure out the object that uses those block numbers. If you're really lucky, it may be and index ... which can be dropped and recreated without loosing *any* data. I'll leave the research up to you.

jc

In article <8ro3m4$ovq$1_at_nnrp1.deja.com>,   tkman23_at_my-deja.com wrote:
> Hi folks!
>
> We have a problem or a big problem!!!
>
> We are running our most importen databases on Oracle 7.3.4 on Solaris
> 2.6 we are useing EBU as the backup software. We are useing
>
> Today when I read the EBU logfiles I saw that EBU has detect corrupt
> block in our Oracle databases in the backups which has been taken the
> last 1-2 weeks, not good. The logfiles include at lot of rows (100-
 200)
> as:
> We are useing EBU to run a online backup every night. We have just
> switch to run offline backup every weekend (the first one run today).
>
> We are running the databases in archive log mode and store the archive
> log files for more then 3 months.
>
> We also do som export of the databases to remote filsystem.
>
> --> Start <---
> Database file number 1 ("/var/order/system01") block 13152 contains
 file
> number 0
> Database file number 1 ("/var/order/system01") block 13152 contains
> block number 0
> RBA fixed for database file number 1 ("/var/order/system01") block
> 13152, read (0, 0)
> ...
> ...
> Warning: found 89 physically corrupted blocks in database file
> "/var/order/system01"
> Warning: 89 database block headers in database file
> "/var/order/system01" were marked as logically corrupt to allow backup
> to proceed
> ---> End <---
>
> EBU founds corruptions in three files, the system file (as in the
> example above), our main tabelspace-file" order_data" which only
 include
> table, our tablespace "order_index" for indexs.
>
> I have trace the corrupt blocks back to the object which use the
 corrupt
> blocks.
> I have done a "select * from TABLE_NAME" on all table object I have
> found on corrupt blocks. The select command run without any problem.
> Shouldn't I got some kind of error if I do select on a table which
> reside on a corrupt block?
>
> How do I fix the problem? We can't lose any data from the databases.
> As far as I know when you got corrupt block on the Oracle databases
 you
> should immediate restore from a corrupt-free backup.
>
> The system table shouldn't contain any information which can't be
> recreated easy from scratch. The index table can be recreated, so the
> most crtical is the order_data tablespace/file. Which only have 15
> corrupted block (system as 89 corrupted, order_index has 149 corrupted
> block).
>
> Our problem is that the latest corrupt-free backup is more then 14
 days
> old. This is to old for ous and we can't lose any data, so we are in
> deep shit just now I think. But we still have the archive log files
 for
> more then 14 days back.
>
> My plan is too
>
> 1) Restore the latest corrupt-free backup
> 2) Apply the archive log files to the databases to "patch" the
 databases
> to the status of then the latest archive log was create.
>
> Or will the archive log also apply the corruptions to the databases?
>
> Or should I use the exprots?
>
> The thing I don't understand is why I can run a select on a table
 which
> should reside on corrupt block? The select return all rows correct.
>
> Any sugesstions?
>
> Kind regards
>
> //Tommy Svensson
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Mon Oct 09 2000 - 01:57:56 CDT