RE: Dataguard Benchmark

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-----

Steve McClure
Sent: 17 September 2003 00:15
To: Multiple recipients of list ORACLE-L

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-----

Niall Litchfield
Sent: Tuesday, September 16, 2003 1:40 PM To: Multiple recipients of list ORACLE-L

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-----

VIVEK_SHARMA
Sent: 15 September 2003 18:49
To: Multiple recipients of list ORACLE-L

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?  

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Niall Litchfield
  INET: niall.litchfield_at_dial.pipex.com

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: ListGuru_at_fatcity.com (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).