K Gopalakrishnan wrote:
>
> If you want to Zero data loss in standby you can copy the online redo logs
> thru an external C program. You can copy the online redo log files when
> the LGWR is writing to it.
>
> The program should read the log files without locking. You can use the fixed
> table X$KCCLE and X$KCCCP to find how much is written in the log files.
> The partially filled log file can be shipped to the standby location and
> you can
> open the standby database with the new control file created with NORESETLOGs
> ..
>
> In this way you have a graceful fail over in the standby database and no
> committed
> Transaction is lost in the standby database
>
> Does this sound good?
>
> Best Regards,
> K Gopalakrishnan
> Bangalore, INDIA
>
> -----Original Message-----
> Sent: Wednesday, November 28, 2001 4:16 PM
> To: Multiple recipients of list ORACLE-L
>
> I am also facing the same problem. All these disadvantages in 8i standby DB
> have been taken care of in oracle 9i version. The other solution could be to
> buy an expensive Veritas Cluster server/Database edition.
>
> Thanks,
> -- Janardhana babu
>
> -----Original Message-----
> Sent: Wednesday, November 28, 2001 3:35 PM
> To: Multiple recipients of list ORACLE-L
>
> Quick question. Is it a fair statement to say that using Oracle's hot
> standby database allows you recoverability up to the last archive log, but
> would NOT recover to the latest redo log (prior to a log switch). In other
> words, the potential to lose transactions is very high if you depend on this
> for failover (not good for e-commerce type databases). Would it be possible
> to somehow mirror redo logs across to the failover server and apply them
> when activating the standby database, or is the only real solution
> clustering or something like DoubleTake?
>
> Am I making sense?
>
> Thanks,
>
> Ed
>
Very interesting thread. If I understand Ed's idea, it would be to have
at least one redo log file in each group written at the remote location,
through a NFS mount or similar (indeed, I'd rather have 'similar' than
'NFS mount', for having tried once a NFS-mounted tablespace). I fear
that it wouldn't work, because Oracle waits for the log to be physically
written to disk before saying 'committed' to you, and I don't think that
it says 'committed' once it has been written successfully to ONE log
file but to ALL log files (has anybody tested the impact of the number
of log files on performance?). In the best of case, it would seriously
impair performance. In the worst one (network glitch) you may have
failing transactions; its a bit like two-phase commit, succeed
everywhere or fail everywhere is nice only as long as everything
succeeds. I presume (it's a functionality I have not had the opportunity
to test yet) that 9i handles this by writing synchronously (in respect
to COMMITs) local redo logs and asynchronously remote copies. Being
sceptical by nature, I have serious doubts about 'zero loss' ('total
quality' and 'zero default', anyone? Do you realise how dull your life
would be without patches?); it is certainly OK with small or not much
updated databases, but having seen 'Checkpoint not complete' a number of
times in alert log files I wonder how it can catch up with intense OLTP.
Most standby databases I know are used for disaster recovery plans, in
physically remote locations, which means that the link is not exactly an
ultra-fast LAN.
I really love the C program solution, even if it probably shares the
limitations I mention above. That said, with your code you can improve
it, open several connections, etc. Would certainly be fun to write. But
I also find it difficult to sell the idea of financing this kind of
development to management, with the Oracle salesman whispering 'no loss
with 9i' to their ears (I guess that all of them only have a very faint
idea of what a standby database is and what it can be used for).
Ultimately, the expensive hardware solution would probably be the
easiest sell. But perhaps accepting that minimizing loss, not making it
disappear, would be the wisest solution.
--
Regards,
Stephane Faroult
Oriole Corporation
Voice: +44 (0) 7050-696-269
Fax: +44 (0) 7050-696-449
Performance Tools & Free Scripts
--------------------------------------------------------------
http://www.oriole.com, designed by Oracle DBAs for Oracle DBAs
--------------------------------------------------------------
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Stephane Faroult
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
