Verify that you actually have corrupt files. Use dbv on the files
themselves. Use analyze...validate statistics on the objects. It sounds
like your backup software is nuts.
--
Dave A
<tkman23_at_my-deja.com> wrote in message news:8ro3m4$ovq$1_at_nnrp1.deja.com...
> 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.
Received on Sat Oct 07 2000 - 22:35:02 CDT
