Re: Doubts on Data Guard and Replication

> Could we perhaps kill this myth before it gets out of hand? There
*is*
> downtime with RAC...

Sure. Having no downtime is a goal - an expensive and elusive one. There is always some form of downtime (possible.) To implement that goal one starts talking about high availability, not 100% availability, and how many 9s of availability are feasible. What it means for the system to be available has to be carefully defined. What happens if just one datafile is lost. Is the database available? What if a network switch fails, is the database available? etc. If being highly available is a real requirement then one will want to consider RAC part of the solution along with the most redundant storage system you can imagine.

> It is important to qualify that statement. If you want it truly
> transparent..

Good point. By transparent, I think of not requiring the end user to do anything special (e.g. restarting) in order to continue work - most end users are used to waiting. Implementing TAF in an application will definitely require some effort. Callback functions need to be built. These functions have to handle issues like setting the session appropriately and handling any failed transactions.

>> Alternatively, you can failover
>> to another peer in your replicated environment. However, there may
be
>> some data loss that has to be handled.

>There needn't be in Data Guard, but I think you covered that with the
>'synchronous replication' stuff you mentioned earlier and which I
snipped.

Yes, it's essentially the same. Data Guard's maximum data protection mode is synchronous and costs availability. Maximum availability is a compromise, but there is a possibility for some loss. With asynch replication, you can kiss data bye-bye for sure. However, it might be possible for a TAF callback function to handle lost transactions. If peer-to-peer asynch replication is already a requirement then you have to deal with it anyway.

>> BTW: TAF works with DataGuard too ... not just with RAC.

>I realise that. Where in my post did I state or imply otherwise?

>Since TAF was invented in 8i, and RAC didn't make an appearance qua
RAC
>until 9i, it's rather obvious that the two are not joined at the hip.

It may work, but how do you switch the database roles quickly enough for TAF? Once the OCI/JDBC driver catches an appropriate error message, like ORA-03113 , TAF kicks-in. You can set a delay and the number of retires. Do you keep a logical standby open read/write? What happens if the application is running on the logical standby before the role change? Do you really want to automate failover to a standby?

BTW, the "OracleŽ Database High Availability Architecture and Best Practices" documentation for 10g says to use TAF if you can not use automatic RAC availability notifications and events. Received on Tue Nov 23 2004 - 16:18:15 CST