Re: Very Large OLTP Database

I can certainly sympathize with your situation. If high availability is critical to you, Oracle RAC may be the way to go. If implemented correctly with a lot of cash :), there should not be a single point of failure at the database level. You will have multiple instances plus mulitple copies of the data. Of course, ease of programming is an extra bonus. You may want to make sure Oracle has got all the major bugs worked out of 9i before putting it in production.

moab88_at_emirates.net.ae (Nabil Courdy) wrote in message news:<ae1f8554.0203262314.68f12a40_at_posting.google.com>...
> Currently, my group is supporting a mixture of Oracle and Ingres
> databases. The plan is to migrate the Ingres databases/applications
> to Oracle 9i. The size to be migrated is over 1 TB of Online Data.
> This data is NOT in a single database. However, the team who is
> leading the migration effort has gotten some literature from the local
> Oracle Sales force advocating the idea of putting everything in a
> single database and relying on RAC9i and Data Guard for high
> availability and scalability. I have some concerns with this.
>
> Currently, the Ingres application/databases are partitioned per
> region. We have six regions. Some are large and some are small.
> Cross regional transactions are supported. The applications that are
> supported are for Telecomm Customer Service/Service Provisioning/Real
> Time Bill Payments/Cycle End Billing/Fault Reporting. All serives are
> real time. That is, bill payments are accepted through the Net, ATM
> Machines, & Cash Counters (not by post office mail. To get a new
> GSM/Internet line, your line is activated by the time you walk out of
> service center. Your line is tossed due to non-payment? You pay
> through the Net, cash counter, or ATM, boom you are instantly
> reactivated. You want to subscibe for call-waiting or add any other
> service to an existing line, use IVR or the Net, boom, it is activated
> instantly. Availability is crucial and our customers have come to
> expect this real time services.
>
> The model works perfectly for us since if one region is out due to
> some reason, all other regions continue to work fine. We have
> implemented high availability solution in all regions, this includes
> node fail-over, dual everything (network cards, power supplies, etc.),
> disk mirroring, etc.
>
> We feel that although Oracle offers nice features such as RAC9i,
> Standby databases, partitioning, etc. The concept of single database
> is still a single point of failure at the database level. Surely
> there may be situations when the primary and standby databases are
> out. Currently, we generate giga bytes of redo logs (journal files in
> Ingres), these files would have to be constantly shipped to keep the
> standby database sychronized.
>
> I am approaching this from and operational point of view. Where as the
> driving team (the development team) is approaching it from
> easier-to-code in non-distributed environment. But I know that
> management is down my throat once an outage occurs on a single region
> database. I cannot imagine what would happen when the whole country
> is out. The Oracle sales force has not made my job easier where they
> are providing cases as genetic engineering companies and what have you
> as examples of large single database sites. We all know that the way
> business is run for a Telecomm company is different than a genetic
> engineering company.
>
> I'd like to know what other DBAs out there think about this. Keep in
> mind that outages are minutely tolerated in our environment.
>
> Nabil
> =====
Received on Wed Mar 27 2002 - 23:56:41 CET