The SDU may be able to help you utilise the full bandwidth to your standby that is available, but if you generate redo at a higher rate than the bandwidth available to you, it can't solve this problem only mitigate it. One way of seeing this is checking if any changes affect your speed of shipping redo could be the LNS wait on SENDREQ wait event, this wait event bundles in multiple things including the time taken to ship the redo. Another big win is setting the TCP send and recieve buffer size. There is a lot of good detail in the Redo Transport Network Best Practices available at the Oracle MAA site: http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm Another thought is some way of compressing the redo before/during sending could also maximise your network bandwidth jason. -- http://jarneil.wordpress.com -- http://jarneil.wordpress.com 2009/3/11 Jason Heinrich <jheinrichdba@xxxxxxxxx> > Speaking of the SDU parameters, has anyone here seen tangible benefits from > increasing the SDU for shipping redo from the primary database to a > standby? Our specific environment: > > Windows 2003 > Oracle 10.2.0.4 w/DataGuard > Logical standby geographically separate from the primary > Primary in maximum performance mode > > The other day we had a situation where redo was being generated so quickly > on the primary that not all of it got shipped to the standby. I was > wondering if a large SDU could alleviate this type of problem in the future. > > -- > Jason Heinrich >