SEO

Hi all.
Does Sybase have something like Oracle's RAC,
perhaps with dual-ported disks, so that if a
main DBMS goes down, a hot standby is immediately
ready to take the same traffic, and has quick
access to the same data, including in-doubt
(prepared) XA transactions?

Thanks,
Joe Weinstein at BEA Systems

Sybase does have a High Availibility solution that works in conjunction
with the OS solution. So if one of your machines goes down, you have
another one available at the same instant.

Check out this document ....

http://www.sybase.com/detail?id=1019940

Joe Weinstein wrote:
> Hi all.
> Does Sybase have something like Oracle's RAC,
> perhaps with dual-ported disks, so that if a
> main DBMS goes down, a hot standby is immediately
> ready to take the same traffic, and has quick
> access to the same data, including in-doubt
> (prepared) XA transactions?
>
> Thanks,
> Joe Weinstein at BEA Systems

No.
--
Daniel A. Morgan
http://www.psoug.org
damorgan@x.washington.edu
(replace x with u to respond)

Sybase currently has active-active failover with its HA solution for ASE,
which does pretty much what you describe/
ASE's 'Shared disk clusters' version is one (big) step further and that's in
the works -- expected next year.

HTH,

Rob
-------------------------------------------------------------
Rob Verschoor

Certified Sybase Professional DBA for ASE 12.5/12.0/11.5/11.0
and Replication Server 12.5 / TeamSybase

Author of Sybase books (order online at www.sypron.nl/shop):
"Tips, Tricks & Recipes for Sybase ASE"
"The Complete Sybase Replication Server Quick Reference Guide"
"The Complete Sybase ASE Quick Reference Guide"

mailto:rob@YOUR.SPAM.sypron.nl.NOT.FOR.ME
http://www.sypron.nl
Sypron B.V., P.O.Box 10695, 2501HR Den Haag, The Netherlands
-------------------------------------------------------------

"Joe Weinstein" <joeNOSPAM@bea.com> wrote in message
news:430226bb$1@news.beasys.com...
> Hi all.
> Does Sybase have something like Oracle's RAC,
> perhaps with dual-ported disks, so that if a
> main DBMS goes down, a hot standby is immediately
> ready to take the same traffic, and has quick
> access to the same data, including in-doubt
> (prepared) XA transactions?
>
> Thanks,
> Joe Weinstein at BEA Systems
>

Rob Verschoor wrote:
> Sybase currently has active-active failover with its HA solution for ASE,
> which does pretty much what you describe/
> ASE's 'Shared disk clusters' version is one (big) step further and that's in
> the works -- expected next year.
>
> HTH,
>
> Rob
> -------------------------------------------------------------
> Rob Verschoor

RAC is not a Sybase like HA failover and there is no relationship
between the Sybase capability and that of Oracle's RAC. Sybase HA
failover is more equivalent to Oracle's DataGuard failover.

With the Sybase solution you do not have shared-everything. With
Sybase you do not have load balancing. With Sybase there is a
primary node and the balance are secondary. With Oracle that concept
does not exist. All nodes stand on a equal footing.

With Sybase, after failover, all existing client connections are lost.
With Oracle all existing client connections are maintained. The end-user
experience is seemless with a DML statement restarted on another live
node.

HTH
--
Daniel A. Morgan
http://www.psoug.org
damorgan@x.washington.edu
(replace x with u to respond)

"DA Morgan" <damorgan@psoug.org> wrote in message
news:1125189604.369503@yasure...
> Rob Verschoor wrote:
> > Sybase currently has active-active failover with its HA solution for
ASE,
> > which does pretty much what you describe/
> > ASE's 'Shared disk clusters' version is one (big) step further and
that's in
> > the works -- expected next year.
> >
> > HTH,
> >
> > Rob
> > -------------------------------------------------------------
> > Rob Verschoor
>
> RAC is not a Sybase like HA failover and there is no relationship
> between the Sybase capability and that of Oracle's RAC. Sybase HA
> failover is more equivalent to Oracle's DataGuard failover.
>
> With the Sybase solution you do not have shared-everything. With
> Sybase you do not have load balancing. With Sybase there is a
> primary node and the balance are secondary. With Oracle that concept
> does not exist. All nodes stand on a equal footing.
>
> With Sybase, after failover, all existing client connections are lost.
> With Oracle all existing client connections are maintained. The end-user
> experience is seemless with a DML statement restarted on another live
> node.
>
> HTH
> --
> Daniel A. Morgan
> http://www.psoug.org
> damorgan@x.washington.edu
> (replace x with u to respond)


As I said, ASE's 'Shared disk clusters' are in the works. This is a 'shared
everything' architecture, much like Oracle's RAC.

Rob V.

DA Morgan wrote:

> Rob Verschoor wrote:
>
>> Sybase currently has active-active failover with its HA solution for ASE,
>> which does pretty much what you describe/
>> ASE's 'Shared disk clusters' version is one (big) step further and
>> that's in
>> the works -- expected next year.
>>
>> HTH,
>>
>> Rob
>> -------------------------------------------------------------
>> Rob Verschoor
>
>
> RAC is not a Sybase like HA failover and there is no relationship
> between the Sybase capability and that of Oracle's RAC. Sybase HA
> failover is more equivalent to Oracle's DataGuard failover.
>
> With the Sybase solution you do not have shared-everything. With
> Sybase you do not have load balancing. With Sybase there is a
> primary node and the balance are secondary. With Oracle that concept
> does not exist. All nodes stand on a equal footing.
>
> With Sybase, after failover, all existing client connections are lost.
> With Oracle all existing client connections are maintained. The end-user
> experience is seemless with a DML statement restarted on another live
> node.

I undertand now that RAC != Sybase HA (yet). However RAC is not nirvana,
and the above seems to confuse/co-mingle Oracle RAC with Oracle TAF.
With RAC alone, connections to a failing RAC node are simply dead.
There is a connect-time option for the Oracle client code to try
a named series of RAC nodes to find on that is currently running,
(failover and/or load-balancing). When a RAC conneciton dies, any
ongoing local transaction or global transaction that has not yet reached
the prepared state is gone. Transactions in the prepared state will
be known to other nodes, so these can be completed according to XA
during recovery (needed because of the failure of the original connection).
However, there are bugs and problems: These in-doubt transactions will
not be known *and in a recoverable state* for upwards of a minute, during
which time, Oracle will return these TX IDs to the coordinator, but
if the coordinator then says to commit/roll back these IDs, the DBMS
will send failures. This is worked around by retrying the resolution
calls for a while. Also, in a wierd turn-about, Oracle uses PAGE_LEVEL
LOCKING like old Sybase! All data that is (must be) locked regarding these
in-doubt transactions is locked in pages, which also locks logically
unrelated data, so until these in-doubt transactions are resolved,
Oracle will fail other new unrelated transactions!
TAF is different. It is "Transparent Application Failover", and
purports to make connections failover in-flight, so applications
can just continue to do their work. This is a noble goal, but TAF is
a cynical misnomer for most real clients. Below is a link to
Oracle documents which partially admits to the computational and
session state that is lost over the 'transparent failover', which
boils down to a connection which can be worse than useless for anything
but read-only applications. In the case of JDBC clients, all
existing prepared statements are dead, all packages are wiped clean,
current queries may be corrupted, and all user-set session state is
gone. In the case of some ongoing query-data reading, Oracle will try
to re-establish the cursor state so the results can keep coming, but it
does so by re-querying and stepping through the data *by row count* to
get the cursor back to the same place. In cases where the data
is different in the new node (such as the query including data that
the user had not yet committed in the previous state of the pre-prepared
transaction), the new cursor will be at the wrong place...

(http://metalink.oracle.com/metalink/...p_id= 97926.1)



5.1.3 TAF - SESSION state after failing over


If a session fails over to the BACKUP then there are some important restrictions on statements either in progress at the time of
fail-over, or statements issued after the failover. These restrictions are documented in the Oracle8i documentation and include:
PL/SQL package state is lost after failover
ALTER SESSION statements are lost
In-progress transactions must be rolled back
Continuing work on existing cursors may raise an error (eg: ORA-25401 "cannot continue fetches")
Failed over selects may take time to re-position (when FAILOVER_TYPE=SELECT)
Failed over selects may raise an error
In the case of instance or node failure there may be a delay before the BACKUP instance can do any user work (due to time taken
for lock remastering and any instance recovery)


>
> HTH

Comments in-line.

Joe Weinstein wrote:

>> RAC is not a Sybase like HA failover and there is no relationship
>> between the Sybase capability and that of Oracle's RAC. Sybase HA
>> failover is more equivalent to Oracle's DataGuard failover.
>>
>> With the Sybase solution you do not have shared-everything. With
>> Sybase you do not have load balancing. With Sybase there is a
>> primary node and the balance are secondary. With Oracle that concept
>> does not exist. All nodes stand on a equal footing.
>>
>> With Sybase, after failover, all existing client connections are lost.
>> With Oracle all existing client connections are maintained. The end-user
>> experience is seemless with a DML statement restarted on another live
>> node.
>
>
> I undertand now that RAC != Sybase HA (yet).

It would be nice if Sybase offered an equivalent capability.

> However RAC is not nirvana,
> and the above seems to confuse/co-mingle Oracle RAC with Oracle TAF.

Actually not but we'll get there. RAC != TAF. TAF also works with
DataGuard and in other situations as TAF is Net Services.

> With RAC alone, connections to a failing RAC node are simply dead.

Well yeah. If you yank the power cord the node is dead. But the end
user never knows it.

> There is a connect-time option for the Oracle client code to try
> a named series of RAC nodes to find on that is currently running,
> (failover and/or load-balancing). When a RAC conneciton dies, any
> ongoing local transaction or global transaction that has not yet reached
> the prepared state is gone.

Where did you get this misinformation? It is absolutely untrue.

My standard lecture demo of RAC node failure is to live-demo transparent
failover ... transparent means transparent.

> However, there are bugs and problems: These in-doubt transactions will
> not be known *and in a recoverable state* for upwards of a minute,

Sorry but this is pure nonsense. I've never seen a TAF failover take
more than 2 seconds ... generally they are subsecond. I teach RAC
classes and my students generally build 4-8 two node clusters each and
every month. Not once has any one of them ever experienced what you
describe.

> Also, in a wierd turn-about, Oracle uses PAGE_LEVEL
> LOCKING like old Sybase!

You've really got to stop smoking whatever it is you are smoking. To
start with Oracle has no concept of pages ... they are blocks. And
you couldn't lock a block in Oracle by any method short of writing a
program that interrogated the block, determined what rows it contained
and then locked each individual row. Seriously Joe ... where are you
getting this stuff?

> TAF is different. It is "Transparent Application Failover", and
> purports to make connections failover in-flight, so applications
> can just continue to do their work.

Exactly.

> This is a noble goal, but TAF is
> a cynical misnomer for most real clients. Below is a link to
> Oracle documents which partially admits to the computational and
> session state that is lost over the 'transparent failover'
>
http://metalink.oracle.com/metalink/...p_id= 97926.1)


"Admits"? You have misunderstood what you read.

What happens behind the scenes is irrelevant to the end-user experience.
Which is subsecond and truly transparent.
--
Daniel A. Morgan
http://www.psoug.org
damorgan@x.washington.edu
(replace x with u to respond)