Standby Database Experience [message #60079] |
Tue, 13 January 2004 23:35 |
Bernhard
Messages: 1 Registered: January 2004
|
Junior Member |
|
|
Hello,
How do certain application-design characteristics affect the over-all-performance when I (data)-guard a 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?
Are there any experiences?
thanks in advance,
Bernhard
|
|
|
Re: Standby Database Experience [message #60090 is a reply to message #60079] |
Thu, 15 January 2004 03:49 |
Thiru
Messages: 1089 Registered: May 2002
|
Senior Member |
|
|
Are you concerned about too much redo generation ?
Amongst the DML, inserts generate the least UNDO ,as only the ROWID is required to undo the chnages.
Deletes generate the most amount of UNDO, as the entire row is recorded to be able to rollback the change.
Updates, generate UNDO depending on how many(&big) columns you are updating.
Having too many Indexes, do generate a lot of REDO,unless they are created in NOLOGGING mode. But beware of NOLOGGING operations/objects on the Primary when you are using Physical Standby.
Unnecesary ROLLBACK generates unnecessary REDO.
But if you are concerned about High Availability,you should be able to allocate sufficient space for the archived redologs and a 'fast internal network' between the primary and standby and not be too concerned with the application design ?
-Thiru
|
|
|