Re: Help required on Data Guard

Mark Bole wrote:
> Howard J. Rogers wrote:
>

>> Joel Garry wrote:
>> [snip]
>>
>>>
>>> RAC is, as you say, for a single database.  Data Guard uses log files
>>> to replicate the transactions to another database.
>>
>>
>>
>> Minor quibble: it actually uses processes, either LGWR or ARCn, to 
>> trasport redo. No files actually get shipped between machines, as such.
>>
>> HJR

Data Guard: the one where what it uses is actually mentioned.

> More specifically, in the case of Data Guard, are you saying that no
> matter how far beind, the primary database, once it notices it can talk
> to the standby again after an interruption, actually re-reads the
> previously locally archived redo logs, and then sends the data, as
> re-read, to the standby via log transport, where the redo log file is
> then re-instantiated on the fly?

Well, ordinarily, if archiving to a destination is deferred, and then re-enabled, no catchup of any kind is performed, and it's up to you to plug the gaps, and that would involve manually copying log files.

But with Data Guard, you can configure a 'FAL Server' and a 'FAL Client', and additional processes are then responsible for doing exactly what you've described: mining files on the FAL Server, and shipping the extracted redo to the FAL client. I can't recall, however, whether that capability first made an appearance in 9i Release 2 (I believe so), or in 10g.

That, at least, is my understanding -though I note the 10g doco talks about "by automatically retrieving missing archived redo log files from the primary database". So even it talks about copying *files* across... but then quite a lot of the doco uses language loosely.

When you have diagrams showing Oracle background processes talking to each other, it's a fair bet that they aren't having a chat about doing a simple 'cp'!

> Hmm, I'd never thought of that. But of course, that *would* be much
> more portable across OS platforms.

Precisely.

Regards
HJR
> I did notice that the timestamps of
> 'catch up' log files were contemporaneous with the catch-up, but I
> thought that was just a sloppy way of copying files (for example, not
> using the equivalent of "-p" = preserve option).
>
> -Mark Bole
>
>
Received on Mon Nov 29 2004 - 22:28:02 CST