Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: exp and archive available.... recover table

Re: exp and archive available.... recover table

From: joel garry <joel-garry_at_home.com>
Date: Fri, 13 Jul 2007 11:19:43 -0700
Message-ID: <1184350783.259250.163290@d30g2000prg.googlegroups.com>


On Jul 13, 3:00 am, Alexander Skwar <alexan..._at_skwar.name> wrote:

>
> What I'm now considering to do is, that I'd copy all the .dbf files and
> also the redo log files. When I have the archived redo log files available,
> I am able to do a media recovery, aren't I? And I (might) need to do a
> media recovery, when I try to startup the database and give it .dbf files,
> which are "hot". Or am I overlooking something again?

NONONONO! Please google about until you find an explanation as to why you do not backup redo log files (as opposed to archived log files). Note that RMAN doesn't even let you do this.

The essential problem is that it is unexpectedly easy to get into a situation where you overwrite current redo with older, and lose transactions you otherwise wouldn't have.

> > To do a hot backup, you need to put the tablespace in backup mode.

> What would happen, if I would NOT do this?

This is called the split block or fractured block problem. When the operating system utilty is copying the blocks, the OS only knows about it's own blocksize, say 512, while Oracle may consider blocksize 8K. So Oracle tells the OS to write 8K, the OS writes out the first 512, copies all the blocks with your mirror splitting, then writes out the next 7 blocks for Oracle. Oracle doesn't know about operating system utilities, so putting tables in hot backup mode tells Oracle to freeze the SCN in the headers of the data files and write out additional redo, so later when it tries to recover it can decide if a block was written before or after the placement in hot backup mode and deal with it accordingly.

So if you don't put the ts in backup mode, you have the risk of making a copy of what will eventually come out as a corrupted Oracle block, one part updated and another part not yet updated. A bit difficult to predictably replicate, but quite likely to occur in actuality, more likely if any updates are happening.

RMAN, on the other hand, is smart enough to be able to know about Oracle writing blocks, and can wait until it is done writing the entire Oracle block before copying it. Even so, there are some obscure situations where you have to do funny things like convince Oracle an empty block is not corrupt. But at least you can work with that, you can't work with OS v. Oracle generated corruption.

http://download.oracle.com/docs/cd/B10501_01/server.920/a96519/glossary.htm#432645

jg

--
@home.com is bogus.
Live Free or Die Hard already obsolete:
http://www.zdnetasia.com/news/security/0,39044215,62028389,00.htm
Received on Fri Jul 13 2007 - 13:19:43 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US