Tanel,
I think this is a good solution, provided the application can handle two phased commit protocol across both the databases, else there could be orphan records on one or both these databases.
Murali
Tanel Poder <[EMAIL PROTECTED]> wrote:
Tanel Poder <[EMAIL PROTECTED]> wrote:
When you want true 24x7 without compromises, then you have to step closer to
the client anyway.
This means, you have two databases for example and your app server
multiplexes all transactions to both ones.
This should be faster than sync standby or sync replication, because app
server can send requests to both databases in parallel, unlike with
standby/replication where database itself resends the requests to other
databases, making the "chain" of changes longer.
Tanel.
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Wednesday, December 10, 2003 11:24 PM
>
>
>
>
> Hi,
>
> Unfortunately I'm gonig to add the negative view, like several others
> have...
>
> True 24x7x365 (good pick-up Pete on the 7 year thing) will! be limited by
> much more than database and operating system availability. We just did a
> major software upgrade last weekend and part of the upgrade involved the
> conversion of 250+ million records in the database - that takes time no
> matter what. Yes, with unlimited budget and time constraints we could get
> the outage down to nothing but at the end of the day it's easier for the
> business to manage an outage.
>
> Our system was offline for a total of about 10 hours yet traffic drives on
> our tollroad all the time so: The roadside is designed to backlog
> transactions for several days, our system has capacity to catch up
backlogs
> fairly fast (within a day we had caught up again), we have an alternative
> front-end system that can backlog feeds, and finally we designed our
> conversion process to do as much as possible before the outage.
>
> We are also on 8.1.7 enterprise and! don't use OPS/RAC - instead we have
the
> alternative processes in place to ensure the business can function.
> Perhaps your company can consider a similar alternative? As others have
> said - it can be VERY difficult to remove every possible outage and it can
> be much easier to manage a small outage every few months.
>
> Regards,
> Mark.
>
>
>
>
> "Tracy Rahmlow"
> <[EMAIL PROTECTED] Multiple
recipients of list ORACLE-L <[EMAIL PROTECTED]>
> xp.com> cc:
> Sent by: Subject: 24 x 7 x 365
> [EMAIL PROTECTED]
> .com
>
>
> 11/12/2003 03:44
> Please respond to
> ORACLE-L
>
>
>
>
>
>
>
> Hello,
> Our company would like to know whether or not Oracle supports true
24x7x365
> availability for an oltp database. We currently are using the 8.1.7
> enterprise edition. Does an architecture exist whereby we can upgrade the
> database and/or operating system and not cause an outage? Will RAC solve
> this issue? Are there any other areas of concerns that I should be
> thinking about? For example, analyzing with the validate clause and its
> impacts on the transaction system. Thanks
>
>
> American Express made the following
> annotations on 12/10/2003 09:41:15 AM
> --------------------------------------------------------------------------
----
>
>
****************************************************************************
**
>
>
> "This message and any attachments are solely for the intended recipient
and
> may contain confidential or privileged information. If you are not the
> intended recipient, any disclosure, copying, use, or distribution of the
> information included in this message and any attachments is prohibited. If
> you! have received this communication in error, please notify us by reply
> e-mail and immediately and permanently delete this message and any
> attachments. Thank you."
>
>
****************************************************************************
**
>
>
>
>
============================================================================
==
>
>
>
>
>
>
>
>
>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Privileged/Confidential information may be contained in this message.
> If you are not the address! ee indicated in this message (or responsible for
delivery of the message to such person), you may not copy or deliver this
message to anyone.
> In such a case, you should destroy this message and kindly notify the
sender by reply e-mail or by telephone on (03) 9612-6999 or (61) 3
9612-6999.
> Please advise immediately if you or your employer does not consent to
Internet e-mail for messages of this kind.
> Opinions, conclusions and other information in this message that do not
relate to the official business of Transurban Infrastructure Developments
Limited and CityLink Melbourne Limited shall be understood as neither given
nor endorsed by them.
>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Mark Richard
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> 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).
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Tanel Poder
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
Murali Vallath
Author: Oracle Real Application Clusters Publisher Digital Press
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing
