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.
<BLOCKQUOTE dir=ltr
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
- Original Message -----
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black">From:
<A [EMAIL PROTECTED]
href="mailto:[EMAIL PROTECTED]">Jamadagni, Rajendra
To: <A [EMAIL PROTECTED]
href="mailto:[EMAIL PROTECTED]">Multiple recipients of list ORACLE-L
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 <FONT
size=2>--------------------------------------------------------------------------------
Rajendra dot Jamadagni at nospamespn dot com <FONT
size=2>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 [<A
href="mailto:[EMAIL PROTECTED]">mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 10, 2003 3:10 PM <FONT
size=2>To: Multiple recipients of list ORACLE-L <FONT
size=2>Subject: Re: High availability and upgrades
It is our own application. That's an interesting
approach, thanks!
- Tanel Poder <[EMAIL PROTECTED]> wrote:
> Hi! > <FONT
size=2>> 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 <FONT
size=2>> <FONT
size=2>> That means, if your client inserts
something, > then app layer does
one insert on first DB > and the
same insert in second DB too. <FONT
size=2>> <FONT
size=2>> It can be more efficient than standby
> database in maximum protection
mode, > because DMLs are sent to
databases > parallelly, not
through primary to standby. > <FONT
size=2>> 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 <FONT
size=2>> instance managed to commit when next
request > is sent to it. That
could give some > performance
practically without losing any >
reliability features. > <FONT
size=2>> 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 <FONT
size=2>> 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 <FONT
size=2>> 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. > <FONT
size=2>> 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 <FONT
size=2>> 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. <FONT
size=2>> > > -----
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 <FONT
size=2>> requirements > > is to be able to
take one database offline (i.e., direct all > >
application connections to a second database server), perform <FONT
size=2>> 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 <FONT
size=2>> > 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. > > <FONT
size=2>> > RAC doesn't give us a second database copy. <FONT
size=2>> > > > Multimaster replication
requires that changes to replicated objects >
be > > made via DBMS_REPCAT.ALTER_MASTER_OBJECT,
which propagates the > changes <FONT
size=2>> > to all masters at once. > >
> > We haven't tested Streams yet.
> > > > I'd be
interested in hearing of any experiences from those who have <FONT
size=2>> the > > same or similar
requirements. > > >
> Paul Baumgartel > > <FONT
size=2>> > > >
__________________________________ > > Do you
Yahoo!? > > SBC Yahoo! DSL - Now only $29.95 per
month! > > <A href="http://sbc.yahoo.com"
target=_blank>http://sbc.yahoo.com > > --
> > Please see the official ORACLE-L FAQ: <A
href="http://www.orafaq.net" target=_blank>http://www.orafaq.net
> > -- > > Author: Paul
Baumgartel > > INET:
[EMAIL PROTECTED] > > <FONT
size=2>> > Fat City Network Services -- 858-538-5051
<A href="http://www.fatcity.com"
target=_blank>http://www.fatcity.com > > San
Diego, California -- Mailing list
and web hosting > services <FONT
size=2>> > >
> > 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 <FONT
size=2>> > (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! <A href="http://sbc.yahoo.com"
target=_blank>http://sbc.yahoo.com --
Please see the official ORACLE-L FAQ: <A
href="http://www.orafaq.net" target=_blank>http://www.orafaq.net
- Author: Paul Baumgartel
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 <A
href="http://www.fatcity.com" target=_blank>http://www.fatcity.com
San Diego,
California -- Mailing list and web
hosting services <FONT
size=2>---------------------------------------------------------------------
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).
Received on Thu Jul 10 2003 - 15:21:04 CDT
