|
Hi!
In data guard, when you do a DML, it first goes to
primary instance log buffers, then to redolog, then to standby host using log
transport services, then applied to stanby using log apply
services.
Thus, in data guard maximum protection mode you
can't initiate changes to _standby_ databases before changes are
written to _primary_ db redologs (I might be wrong because haven't read DG
concepts too thoroughly).
But in case I described previously, you can
issue both "commits" concurrently and even better, using threading and maybe an
additional layer, you could count transaction committed when at least one node
has committed, and check whether other nodes have commited with next request
sent to DBs. That gives performance for example in OLTP environments, but of
course your app has to be able to handle situations when during next request
other nodes still haven't committed (this session with not enough committed
nodes should wait or return some kind of error or handle the situation other
way).
Of course, data guard maximum protection mode
doesn't require you to program additional mechanisms, but it definitelay hits
performance. And more, the DG switchover mechanism would be slower than just
continuing with one active database in case of failure. Also, since we are
dealing with two regular databases, we won't have problems like stanby has,
nologging, LOB logging issues, etc.
OTOH, backup&recovery strategy is probably
different than with physical standbys.
Tanel.
----- Original Message -----
Sent: Thursday, July 10, 2003 10:49
PM
Subject: RE: High availability and
upgrades
Tanel,
points 1 & 2 .... isn't it like using data guard ??
Raj
--------------------------------------------------------------------------------
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art
!
-----Original Message-----
From: Paul
Baumgartel [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 10, 2003 3:10 PM
To: Multiple recipients of list ORACLE-L
Subject: Re: High availability and upgrades
It is our own application. That's an interesting
approach, thanks!
--- Tanel Poder <[EMAIL PROTECTED]> wrote:
> Hi!
>
> Is this your own-written app?
>
> If you want performance, control and no-data-loss
reliability:
>
> 1) Have
2 completely independent databases
> 2) Have your
application servers multiplex
>
all DML requests to both database servers
>
> That means, if your client inserts
something,
> then app layer does
one insert on first DB
> and the
same insert in second DB too.
>
> It can be more efficient than standby
> database in maximum protection
mode,
> because DMLs are sent to
databases
> parallelly, not
through primary to standby.
>
> Depending on application you could commit
> done either when both servers
acnowledge
> commit, or when only
one acknowledges it.
> In that
case you could check whether second
> instance managed to commit when next
request
> is sent to it. That
could give some
> performance
practically without losing any
>
reliability features.
>
> Also, since you now have two identical
> databases, you can make your
app servers
> load balance the
selects.
>
> 3) Before
you shut down one database for
>
maintenance, you first configure your
> app servers to use only one database
> AND set change logging on on active
DB.
> There are several ways for
change logging,
> starting from
customer triggers ending
> with
logminer.
>
> 4) When
you bring second db up again you
> first synchronize all changes manually,
> several times if needed, and when the
> log of changes is sufficiently
low you
> just halt both app
servers for very short
> time, do
the final synchronization and
>
activate both databases again.
>
> If you upgrade your application, will you change the schema as
well?
> Then you must move from physical to logical
level, where you have
> some kind of mapping, which
columns of old tables match columns in
> new
tables.
>
> That way you
have two separate fully functional databases, no Stanby
> or RAC restrictions or additional licence costs etc. If you have
a
> packaged 3rd party app, then my post is quite
useless, but the idea
> should be ok.
>
> Tanel.
>
>
> -----
Original Message -----
> To: "Multiple recipients
of list ORACLE-L" <[EMAIL PROTECTED]>
>
Sent: Thursday, July 10, 2003 8:59 PM
>
>
> > We're
considering high availability options. One of our
> requirements
> > is to be able to
take one database offline (i.e., direct all
> >
application connections to a second database server), perform
> database
> > and application
upgrades, and perform a few hours' worth of tests
>
> before bringing it back online. We would then take the
second
> database
> >
offline and repeat the procedure.
> >
> > We've tried Data Guard logical standby but
it's incompatible with
> Label
> > Security (which we plan to run), presents performance
problems, and
> has
>
> a number of bugs. We'd like to use the secondary database
for
> > reporting as well, so a physical standby
isn't practical.
> >
> > RAC doesn't give us a second database copy.
> >
> > Multimaster replication
requires that changes to replicated objects
>
be
> > made via DBMS_REPCAT.ALTER_MASTER_OBJECT,
which propagates the
> changes
> > to all masters at once.
> >
> > We haven't tested Streams yet.
> >
> > I'd be
interested in hearing of any experiences from those who have
> the
> > same or similar
requirements.
> >
>
> Paul Baumgartel
> >
> >
> >
__________________________________
> > Do you
Yahoo!?
> > SBC Yahoo! DSL - Now only $29.95 per
month!
> > http://sbc.yahoo.com
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Paul
Baumgartel
> > INET:
[EMAIL PROTECTED]
> >
> > Fat City Network Services -- 858-538-5051
http://www.fatcity.com
> > San
Diego, California -- Mailing list
and web hosting
> services
> >
>
---------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an
E-Mail message
> > to: [EMAIL PROTECTED]
(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).
> >
__________________________________
Do
you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per
month!
http://sbc.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Paul Baumgartel
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego,
California -- Mailing list and web
hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail
message
to: [EMAIL PROTECTED] (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).
|
