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 -----
From: "Paul Baumgartel" <[EMAIL PROTECTED]>
To: "Multiple recipients of list ORACLE-L"
<[EMAIL PROTECTED]>
Sent: Thursday, July 10, 2003 8:59 PM
Subject: High availability and
upgrades
> 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).
>
