Re: Application Design for Data Guard

If you need nologging operations you should plan these very carefully, the safest is to switch the whole database to force logging state which always forces logging.

Another thing, since you want synchronized standby, then you should keep your commit rate low, because "replicated commits" will be slower. But for physical standby, any datatype that works in primary, will also be transferred to secondary, without problems.

These synchronized physical standbys which I've set up, work well so far, they replicate redo over dedicated 1Gb Ethernet.

Btw, do you really need synchronized standby? You can have near-synchronized standby as well if you set up asynch replication mode, but assign LGWR to do the replication, instead of archiver...

Tanel.

"Bernhard Krautschneider" <bernhard.krautschneider_at_acp.at> wrote in message news:dec9f4d1.0401130219.17f974a5_at_posting.google.com...
> Hello,
>
> i'm looking for information about how an application should (or should
> not) be designed to perform good within a data guard environment.
> As a matter of fact I didn't find a useful documentation about that
> topic.
>
> What I want to find out is, how certain application-design
> characteristics affect the over-all-performance when I (data)-guard
> the database.
> For example: is an application that does frequent
> varchar2(4000)-inserts and updates on tables, that have many (about
> 40) columns, suitable for a synchronous physical standby
> database-environment, with physical standby redologs?
>
> thanks in advance,
> Bernhard
Received on Sun Jan 18 2004 - 11:33:52 CST