Standby Database

kmesser

OPS is not used for STANDBY DB.

To overcome the online redo log problem, you might need to use DISK VOLUMN MANAGER (Veritas, DoubleTake..) s.t. the online redo log will be mirrored to remote site at DISK level while the archive log is transffered maually or automatic.

However in 9i oracle introduced Physical Standby and Logical standby to address the issues.

Do visit oracle web sit and there is a lot of techincal paper on standby.

hptse:

Thanks for the info about 9i and Veritas! I didn't think OPS was used with Standby DB, my point was that OPS is a high availability alternative to Standby DB.

How would I decide which to use (Standby vs. OPS)?

Thanks again!

Here you go with some info on top of my head. Your justification goes with time in terms of "High Availability". I mean, ? if at all there is problem with the system, how much downtime your business can afford to have ??

STAND BY:

There is noticeable downtime as of today( which might change with the release of 9i) and you need to switch standby as primary when primary is down and primary becomes secondary after yopu fix the problem. this continues in cycle.

Cost effective solution from maintenance and management perspective, if you could afford to have the down time that takes up to switch STANDBY as PRIMARY.

OPS:

Apparently, there will not be any downtime thats noticed except that that the performance of the dbsystem will be down by 25% when other node takes up the workload from failed node. Users don't see any change from business perspective, other than resubmitting their transactions, if their application is not desgined for OPS OR their client connection can't be rerouted.

Lots of maintenance and management costs from resources perspective.

HACMP(IBM):

We started using HACMP(IBM hardware technology) after changing mind from OPS, as we felt its best and cost effective solution for our business scenario.

[Edited by sreddy on 03-08-2001 at 01:03 PM]

sreddy,

What is HACMP?

With OPS, my understanding is that the instances don't share uncommitted data, so any uncommitted transactions would be lost and any users connected to the failed instance would be disconnected. Is there any way to automatically reroute user transactions through the remaining instances? Also load balancing can be implemented across the instances either intelligently or sequential distribution. I think that's what you were alluding to when you mentioned the 25% reduction in performance . . .

Thanks!

Kmeeser, you are right.

But OPS does not solve the disk crash problem. I think many DBAs confused with HIGH AVAILABILTY and SCALABILITY. Both are entirely different concept. When you define availability, it should be measured like 99.999 % or 99.99% or 99.9%.

http://www.sire.co.uk/ibmhacmp.html

In order your transactions to be rerouted, either you have to design your application that way or your client should be capable of noticing the instance failure and reroute the transactions.

As tamilselvan mentioned "high availability" fom OPS perspetive is at database level but not physical disk failure. HACMP is thats what "high availability" from hardware failure.

AFAIK, So the best "high availability" solution is OPS, with RAID 0+1 disk array, WHICH IS EXPENSIVE from all the perspectives like hardware,software licensing and resources...

sreddy,

If an authenticated user is logged in through an instance which fails, wouldn't that user lose their connection? So if they could be dynamically rerouted through the application, they'd have to re-authenticate?!

I guess there's really no way around that problem. If you could, for example put the authentication into the load balancing system, then if that system fails, all the users are disconnected anyway. Would OS authentication be part of high availability, from a client connection perspective?

tamilselvan,

High availability vs. scalability has alot of interwoven components, doesn't it? It seems the idea of OPS increases availability and scalability since adding instances allows more connections and allows for instance failures without loss of access to the DB. By comparison, Standby DB increases availability by reducing downtime due to hardware failures, but does not improve scalability and it seems to me could even reduce performance, since we're using the subsystems of our online system to copy archives to an additional location at the standby DB. As for the disk crash problem you mentioned, we are currently using a RAID system, so one disk lost wouldn't hurt us, other than replacing that one hot-swappable drive that failed with another. Losing a controller would be another matter . . .

[Edited by kmesser on 03-08-2001 at 11:30 AM]

Good thoughts and alternatives..
What will be the recovery scenario of a standby database, since the standby instance is only started. I mean, mounted and not opened always and not used at all. When something happens and you recover the database, you got to recover (apply redologs automatically) and then open it and make that a primary.. But how can we prevent any problems there?
Suppose storage media can have problems and redologs fails when applied... Anything..
Did any of you implement a standby system?

Quote:

---

Originally posted by kmesser
sreddy,

If an authenticated user is logged in through an instance which fails, wouldn't that user lose their connection? So if they could be dynamically rerouted through the application, they'd have to re-authenticate?!

I guess there's really no way around that problem. If you could, for example put the authentication into the load balancing system, then if that system fails, all the users are disconnected anyway. Would OS authentication be part of high availability, from a client connection perspective?

---

You have to design your application keeping in mind the implementation of OPS. If it can't connect to database for some reason(say OPS instance failure), control your application logic to connect/ retry the database after looping thru the exception for first time. By the time it retries there will be connection established with the other node taken the work load of failed node. Here Iam trying to say the possibility, the actual implementation might varies.

Else, you have the same connection string(service_name) pointing to two diffrent instances. when one instance fails, still there is other instance to serve database requests...

The best you can get from anything is from Grounds up, thats from design and anlysis that best suits the business scenarios...

[Edited by sreddy on 03-08-2001 at 04:20 PM]

There is a lot of techincal documents mentioning HA.

http://technet.oracle.com/deploy/availability

It is worth reading.