RE: Dataguard Benchmark

[Niall Litchfield]

Title: Message

I see your point, but I'm not sure if I'd say it was a bandwidth issue or a rate of redo generation issue - if you see what I mean. It sounds like the batch job places execess stress on the redo/archive log system as a whole.   That said if the remore destination is optional and can be caught up - and the batch job is relatively short lived is it actually a problem? I have to confess I am also assuming a certain given level of bandwidth (not dataguard over a 64k ISDN link for example) and that the point of data guard is DR not HA.   Niall -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve McClure Sent: 17 September 2003 00:15 To: Multiple recipients of list ORACLE-L Subject: RE: Dataguard Benchmark Am I missing something here because I think bandwidth is an important consideration.  We are using standby database in 8.1.7, also on Solaris, and the biggest problem I have is when a coworker sets off a huge batch job that effectively shuts down our remote archiving.  In short the first redo log is not archived before a second needs to be archived, so another archiver process kicks off and starts to archive a second log.  This steals some of the bandwidth the first archiver process is using.  Then neither of those logs are archived before a third needs to be archived.  When this is repeated as needed, you can reach a point where you have rolled through your redo logs, but don't have any that free to be over written.  IMO Bandwidth should be a concern when implementing Dataguard. Otherwise you have to deal with manually cleaning up after a scenario like the one I described above.   Steve McClure -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Niall Litchfield Sent: Tuesday, September 16, 2003 1:40 PM To: Multiple recipients of list ORACLE-L Subject: RE: Dataguard Benchmark Just to add to Mladen's comments. I would wish to know   1. How long is fail over time in reality. 2. What is the impact on online operations. Of the db and of anything else that happens to use the same 'backup' link.   You'll note I don't give a damn about bandwidth, I do care what impact DR has on the online system. I think this is intelligent :(   Niall -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of VIVEK_SHARMA Sent: 15 September 2003 18:49 To: Multiple recipients of list ORACLE-L Subject: Dataguard Benchmark We are doing a Data guard Benchmark.   INFO.:- ----- WAN Simulator :- We have a WAN Simulator with 2 routers at either ends of it. Thruputs from 0 to 2 MBPS can be manually set as is required by the run.   Application = Banking :- Transactions mainly OLTP in nature (Both DML & SELECTS) . We can do CPU intensive batch Transactions too if advised by you folks   Machines = 2 machines of 4 CPUs each Memory = 8 GB on each machine O.S. = Solaris 9 Oracle = 9.2 Sniffer network tool ( to get volume of bytes transferred over the WAN ) Dataguard Setup will transfer Data thru the listener services :- i.e. init.ora - LOG_ARCHIVE_DEST_2 = ‘SERVICE=<SERVICE_NAME_FROM_TNSNAMES.ORA>,. . .’   Execution methodology:-   Run Same Transaction’s Volume in BOTH Logical & Physical (Maximum Protection , Maximum Availability , Maximum performance ) standby modes     Qs What readings to be particularly monitored & measured? Qs What thruput bandwidths should be benchmarked? Qs Does total Size of Existent Database-in-use matter to the Benchmark? Current Database Size = 3 GB Qs Does RMAN setup add any value to the Dataguard benchmark in some way? Else we will do Without RMAN, manually altering the various modes Qs Any Sample Docs, Links on existing Dataguard Benchmarks? Qs Any else that will enable us to bring out a paper of reasonable standard?