RE: asking your opinion

From: Gogala, Mladen <MGogala_at_oxhp.com>
Date: Tue, 17 Jun 2003 07:01:48 -0700
Message-ID: <F001.005B2DA1.20030617060920@fatcity.com>

With a standby database, either physical or logical (Oracle 9i) you get a failower machine, typically much smaller then the original one. The problem
is that there isn't much else you can do on that machine. In case of a logical
standby, you can use it as a report server, but then again, you are duplicating
your disks and storing the same database in two different places. It is much

easier to administer then RAC because you don't have DLM to contend with and hardwarewise, it is cheaper (no clustering software, no high speed interconnects
no RAC licenses).
With RAC, you get much more. You get several nodes accessing the same database,
thus providing you with the transparent failover and much greater survivability
of the database. Also, you can use all nodes of a RAC configuration for transactions.
With RAC, nodes ship to each other the current version of a block as well as the
read consistent images of a block (constructed from rollback segments) so partitioning
the application functionally is no longer necessary. Also, your database is not stored
in two different places, so there is no problem with the consistency.

As for one or more databases, it depends on your budget and your business needs.
The most survivable configuration would include a central RAC database and smaller
departmental RAC databases which would deliver the data to the central database by
using multimastering replication.That would also include something like BCV database
to have up as a readonly copy during maintenance times. Now we're talking eight figures.
The business has to take a good look at itself and decide which data absolutely must
survive and which data can be temporarily offline in order for the business to survive.

There is a known story about the WTC branch office of Chase Manhattan, which was switched
to a remote copy and which didn't lose a single transaction despite the fact that the
branch office itself was completely destroyed. That kind of survivability costs money and
business must decide whether it needs it or not.

Mladen Gogala
Oracle DBA
Phone:(203) 459-6855
Email:[EMAIL PROTECTED]

-----Original Message-----
Sent: Tuesday, June 17, 2003 12:15 AM
To: Multiple recipients of list ORACLE-L

Hi Dear listers,

I'd like to ask your opinion about our possible new project. overview; install fatwire for the whole community for web application. no single point of failure, sun servers, oracle. We have more than 10 divisions currently( different department, like arts, dental, enginerring..etc), but we want the flexibility to add more "unit" as

the environment changes and grows.
Question 1: database option; what is the pros and cons about physical standby
database, logical staandby or RAC? I think the answer should be RAC, right? question 2: Among the questions is whether this is a series of databases for

each unit or a central database that is shared by all?

I am new to this area, I would appreciate any input informantion.

Thanks again,

Joan

--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: Joan Hsieh
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: Gogala, Mladen
INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------