Re: Corrupt block during backup Oracle 7.3.4

Provided you have a non-corrupt backup from 15 days ago, and provided you have all redo (archived and online) for those 15 days, then restoring from 15 days ago and recovering is not a problem, and you will not lose any data.

And no, applying redo logs to non-corrupted datafiles doesn't re-introduce the corruption: ARCH takes intelligent copies of the online logs -in other words, it checks for corruption in the *redo logs*, and ensures a clean copy is taken (otherwise it doesn't take a copy at all). So clean datafiles plus clean redo means a clean end result.

On the other hand, I'd be interested in knowing what introduced the corruption in the first place (check your hardware). I'm also interested to know why you don't check your EBU logs every morning after each backup -that would save you some grief in the future. I'd also want to know why you don't run dbv as a matter of routine against anything that's backed up. And I find myself wondering whether you look at your alert log every day.

Considering this is your 'most important database', it seems a bit dodgy to realise there's corruption in your backups only after two weeks.

Regards
HJR

--
--------------------------------------------------------------------------
Opinions expressed are my own, and not those of Oracle Corporation
Oracle DBA Resources:               http://www.geocities.com/howardjr2000
--------------------------------------------------------------------------

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