Re: 24 x 7 x 365

Tracy, both OPS (8i) and RAC (9i)support independent node shutdown. Both support listener based load balancing so that incoming connections will be evenly spread on all nodes. That still doesn't give you the true 24 x 7 x 365 availability. For that, you need two replicated copies of the database, both in OPS/RAC mode. The problem with a single OPS/RAC database is that it has to be shut down for the database upgrade. You cannot have both 8i and 9i instances accessing the same database at the same time, which means that in the case of the database upgrade, all databases in the cluster must be brought down. The only way for production database to remain available after all clustered instances have been brought down is the existence of another copy of your production database, on separate cluster. It is foreseeable that there will be some data discrepancies after the primary configuration is upgraded and brought back online, which means that you must have symmetric replication set up in such a way that your instances can be quickly synchronized. Please, be aware that both configurations, the primary and secondary one must be clustered, because if the secondary database is not clustered, then the instance accessing it becomes the single point of failure, which is what needs to be avoided at all costs. Also, you may decide to limit the meaning of "24 x 7 x 365 availability" and decide that the spare configuration will be available in read-only mode while you are upgrading the primary configuration. That would be the case for a physical standby and playing with EMC BCV-s. In that case, you do not need to set up symmetric replication, because there are no data changes (database is in the read-only mode) but the guys doing upgrade are limited by the time that business may tolerate the database being in the read-only mode. Given the organization you work for, I surmise that a) your database is larger then 10MB and b) that you need it to be fully accessible to the fullest extent of the "24 x 7 x 365" phrase. That probably means that having read-only database for the full two hours is not acceptable. You will need replication. Those two databases should be physically separated in case of catastrophic failure (things that never happen, like big power-grid blackouts, passenger jets crashing into skyscrapers or forest wildfires scorching suburb or two of a major urban area). Of course, network connections must be redundant as well. That would be the true "24 x 7 x 365 availability", but the price tag is really a major number, much more then most companies are willing to spend. Given all the infrastructure and real estate, the price tag probably comes close to 8 zeros range, which is probably what those guys that were hand-picked to test 10g make annually.

On 12/10/2003 11:44:25 AM, Tracy Rahmlow wrote:
> 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."
>
> ******************************************************************************
>
>
> ==============================================================================
>

Mladen Gogala
Oracle DBA

Note:
This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Mladen Gogala
  INET: mladen_at_wangtrading.com

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: ListGuru_at_fatcity.com (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).