RE: What to Choose ?

I've got to respectfully disagree
with a couple of statements made below.

First TAF.
TAF works just fine, reconnecting to the surviving node with NO changes in the application program. All I had to do was re-write the tnsnames.ora file. Oracle did state in some of the documentation that this would only work for apps using a specific OCI call, but both applications (PRO*C and JAVA) reconnected with no problems and even finished executing the statements that had been running when one node failed. (NOTE - there is additional overhead for this functionality)

While it is true that PCM locking does add some overhead, it is not huge. Pinging is a much more serious concern, and cache fusion (8.1.6) helps to eleviate some of those problems. In addition, it is NOT necessary to assign PCM locks at the datafile level. Using DBA locking allows you to just define how many locks to use and Oracle assigns them as needed. This has slightly higher overhead than static locking, but for OLTP environments, it really help get rid of the false pinging problem.

Getting back to the orignal poster's issues, disk failure would be seen across all nodes of an OPS cluster. That's why anyone I know who uses OPS runs raid 0+1 for the fault tolerance of the mirroring. (Although that being said, at least twice in my life I have seen a disk and it's mirror crash simultaneously, even though they were on difference controllers).

OPS is NOT a silver bullet to solve all problems and does have significant issues, not the least of which is the learning curve. But it should not automatically be dismissed for OLTP systems. I've used for a few oltp systems,
and IF CAREFULLY DESIGNED AND IMPLEMENTED, it works just fine. I do firmly believe that the application needs to be designed from the ground up to be OPS aware to achieve maximum benefit.

> -----Original Message-----
> From: Jeffrey Kilgour [mailto:Jeffrey.Kilgour_at_exodus.net]
> Sent: Thursday, August 31, 2000 11:39 AM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: What to Choose ?
>
>
> Jain,
> If you do not have experience with OPS and raw devices
> you should
> stick with a cluster and mirrored disks. If you need
> performance use the
> Parallel Query Option and Partitions. You are correct that OPS is for
> scaling and DSS not really HA or OLTP. Of course many folks
> are thinking of
> using OPS and Transparent Application Fail-over (TAF) for HA
> - but they fail
> to consider unless the application (third party in most cases) and the
> database are designed for TAF they will fail-over as
> advertised - users
> would have to re-connect to a surviving node so why pay the
> cost of OPS when
> a cluster solution does the same thing. Another important
> point is that you
> DO NOT just migrate to OPS. OPS uses PCM locks to control block level
> access between the nodes. These are assigned at the datafile
> level - so if
> the application/database design does not create tablespaces
> based on access
> or lumps all the objects into large/general tablespaces and
> you plan to
> provide access to these objects by all nodes you will have
> contention -
> pinging in OPS terms. Also these PCM locks add overhead so
> unless you plan
> to really scale the number of nodes you will not be able to
> overcome this
> performance hit.
>
> Hope this helps,
>
> Jeffrey S. Kilgour
> Professional Services (Oracle)
> Washington IDC
>
>
>
> -----Original Message-----
> Sent: Wednesday, August 30, 2000 4:27 PM
> To: Multiple recipients of list ORACLE-L
>
>
> I thought that Oracle parallel server meant multiple processing
> nodes mounted onto the same disk farm. Thus disk failures would show
> up in all instances. Also, if different instances are accessing
> the same data block, one has to wait for the other to finish with it,
> making OPS not a proven technology for OLTP (??).
>
> A backup from the hardware end sounds more purposeful towards high
> availability.
>
> P.S. Someone said IBM's HACMP config isn't reliable in having the
> second node mount disks when one node goes down, leaving no access
> to data at all.
>
> Akshay Jain
> _______________________
> Newcourt-CIT
> Tel. (416) 507-5385
> mailto:Akshay.Jain_at_cit.com
> _______________________
>
>
> -----Original Message-----
> Sent: Friday, August 25, 2000 6:02 AM
> To: Multiple recipients of list ORACLE-L
>
>
>
> WE are looking at "high availability".I need some help to decide
> whether to go for
> a High Availability Sun cluster with backup server or for
> Oracle parallel
> server.
> Keeping the key word in mind what would u people advice ?
> I would be happy if you can provide any links to the
> mentioned Subject.
> Thanks,
> Kamal
> --
> Author: Kamalakannan, D (CAP, GCF)
> INET: D.Kamalakannan_at_gecapital.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> 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).
> --
> Author: Jain, Akshay
> INET: Akshay.Jain_at_cit.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> 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).
> --
> Author: Jeffrey Kilgour
> INET: Jeffrey.Kilgour_at_exodus.net
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> 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
Received on Thu Aug 31 2000 - 10:10:49 CDT