Some SRDF Questions

Hi Jiliu2 .. A ton of questions ..

1) DynRDF and "static" RDF are different only when it comes to changing existing relations or creating relations. With Dynamic RDF you can easily create both RDF groups and RDF pairs with "symrdf" commands. You can easily create concurrent pairs. With static RDF you need to change the binfile. You can use "symconfigure" to change relations but it's slower and less "flexible". Recent codes and newer Solution Enabler versions offers control also on concurrent static RDF pairs. However whatever "flavor" you choose, they behave the same when it comes to pushing your data from R1 to R2

2) actual SNOW usage may be monitored using "symstat -type CACHE -g DgName -RepType rdfa" command. You mentioned that the default cache available to SRDF/A is 94%. This means that IF NEEDED the microcode MAY use up to 94% of available cache to store data captured (or being transmitted) by SRDF/A. If you reach the limit, sessions will drop depending on their priority.

3) If you enabled Transmit Idle on your RDF groups, in case of a dropped link the R1 side will accumulate changes in its cache. You already know what happens if you fill the cache and you don't have DSE

4) when the links goes up again you HAVE to sync devices in ACP_DISK mode and switch to async when you are almost in sync.

:-D

Thanks for the in-depth response Stefano!
Just want to make sure I got this right in regards to the DSE question
if DSE is not enabled and the cache is filled before the link is reestablished with the R2 site, are we looking at potentially data loss in terms of is replicated once the link is reestablished, unless we do a full establish again.

thanks

Jiliu2 dropping SRDF/A session simply means that you have to incrementally re-establish the pairs when the link comes back online .. You don't loose data at any time.

When the link goes down, R2 side won't corrupt its content (won't apply an incomplete cycle) and R1 will keep on keeping changed tracks in cache, waiting for the link to come back to send them to R2 side. When R1 cache is full (forget about DSE for a second) R1 box will drop tracks waiting to be transferred over SRDF link, but won't corrupt R1 content

DSE, Transmit Idle and all other SRDF/A goodies always relies on SRDF technology. And SRDF keeps track of changed tracks on both sides of the link .. In case someone changes tracks on R1 side while the link is down, R1 box will keep track of changed tracks. And the same happens on the R2 side. When you resume replica between pairs, both boxes will "exchange" maps of changed tracks and find changed tracks that needs to fly over the SRDF link.

Everything you said is correct Stefano, but one point might be misinterpreted so I just want to provide some clarification...

When you are running in SRDF/A mode the R2 is always consistent (at least it is once it reaches initial consistency). Assuming you haven't enabled any of the Link Resiliency "goodies" (Transmit Idle & DSE) if the physical link between sites is severed you have about 10 seconds before the pairs drop out of SRDF/A mode.

Once you have dropped out of SRDF/A your R2 will remain consitent until you start to recover tthe link. If you establish again in SRDF/A mode (if the link comes back up fast enough) your R2s should stay consistent. If much time has gone by (this is decided by your rate of change on the R1s) you will need to change the mode from Async to Adaptive Copy w/Disk. This will help you catch up faster, but you will not have a consistent R2 until everything catches up and you have switched back to Asynch mode (and it finishes catching up as well).

This is where the real power of Transmit Idle and DSE comes in. In the same situation with Transmit Idle enabled you would have stayed in SRDF/A mode as much as a couple of hours (depending on the rate of change on the R1s and the amount of cache in the box). So the re-establish would not drop your R2s out of consistency. DSE just adds additional time by providing a place on disk for cache to be destaged if the link outage is even longer. We have both enabled and have successfully survived physical link outages of 6+ hours without losing the consistency of our R2s.

I know this is a bit involved (it always seems confusion when I say I'm trying to clarify on one of Stefano's comments *lol), but hopefully it makes sense to you. Basically R2 Consistency is Good! Transmit Idle and DSE help you maintain R2 Consistency through link recoveries.

You are simply right ..

And it sounds straightforward to me

Yes, but you already know this stuff. I'm wondering how it comes across to someone hearing it for the first time.

I was a bit rushed typing it up and would definitely have tried to clean it up a bit if I had more time.

That's why I said you are right .. 'coz I forgot to explain something that's bright and clear to me but may be less clear to someone else ..
And you explained the unclear part of my post

Thanks guys, Yeah Allen brought up a very good point it's something I missed when thinking about this. Also now I fully understand the advantages of using DSE and transmit idle...to extend the amount of time the RDF pairs remain in consistent state when the SRDF link goes down, if not consistent, data on the R2 site will not be usable. Not to stray too far off topic but at my last job, we had an outage the lasted several days. The RDF pairs went into a partitioned state, adaptive disk copy did not work and the only way we got it back into async was to perform a full establish. As far as I know we did not have transmit idel / DSE configured. Does this mean too many track changes had occurred on the R1 side to just "resume" replication?

From my experience, without at least Transmit Idle enabled you will not be able to stay in a consistent state for recovery if the link is down for more than 10 seconds (that's the default setting but it can be changed). Your R2s don't become inconsistent until you start the establish once the link comes up.

With Transmit Idle you don't actually drop out of async mode unless you run out of cache before the link comes back and the pairs are re-established. DSE just extends that time even more.

I'm not sure if you would be able to handle an link outage of several days even with TI and DSE, but I suppose if the rate of change were low enough and you configured enough DSE anything is possible

so basically depending on the rate of change on R1 and how long the link stays down there may still be a need to do a full establish once link comes back up?

No .. In case the session drops, you need an INCREMENTAL establish.

Correct. It will only be an incremental establish either way. The question is whether your R2s will remain consistent during the establish. If the rate of change is too high for the amount of cache and Link Resiliency settings you have configured, then your R2s will not be consistent until the incremental establish is done. If you have properly configured the LR options and have enough cache (and possibly DSE) then your R2s will be able to remain consistent after a link outage.