symrdf establish fails

First of all, welcome in our forums !!

We hope you'll have a pleasant experience

Let me guess .. you have 2 boxes (this is the easy part) .. one is a DMX1/2 while the other one is a DMX3/4 .. you are using symcli 6.4 .. Am I wrong ??

If I am right maybe we have a problem .. but I can't yet offer a fix ..

Message was edited by:
Stefano Del Corno

Removed invisible primus.

Thank you Stefano.

We have two DMX 1000 boxes and SYMCLI version is 6.4.0.0.

Why is it showing the operation failed for device group "newbilling" when it was specified DG1

Please find below symrdf query output. This might be of some help.

Device Group (DG) Name : DG1
DG's Type : RDF1

Source (R1) View Target (R2) View MODES
-------------------------------- ------------------------ ----- --------
ST LI ST
Standard A N A
Logical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF Pair
Device Dev E Tracks Tracks S Dev E Tracks Tracks MDA STATE
-------------------------------- -- ------------------------ ----- --------

DEV001 002B RW 0 394 NR 020C RW 66 0 S.. Split
DEV002 0030 RW 0 362323 NR 0199 RW 751 0 S.. Split
DEV003 0033 RW 0 965 NR 020B RW 17 0 S.. Split
DEV006 004E RW 0 33358 NR 0197 RW 55 0 S.. Split
DEV007 00F3 RW 0 21548 NR 01C9 RW 19 0 S.. Split
DEV008 00FD RW 0 22357 NR 0169 RW 5 0 S.. Split
DEV009 0103 RW 0 21036 NR 01C7 RW 51 0 S.. Split
DEV010 0105 RW 0 29886 NR 01D3 RW 116 0 S.. Split
DEV011 011B RW 0 829 NR 0209 RW 32 0 S.. Split
DEV012 011D RW 0 0 NR 020A RW 51 0 S.. Split
DEV013 0188 RW 0 8641 NR 0111 RW 5 0 S.. Split
DEV014 018E RW 0 15419 NR 0117 RW 92 0 S.. Split
DEV015 0194 RW 0 19260 NR 011D RW 76 0 S.. Split
DEV016 019A RW 0 42388 NR 0123 RW 76 0 S.. Split
DEV017 01A0 RW 0 51015 NR 0129 RW 5 0 S.. Split
DEV018 01A6 RW 0 9148 NR 012F RW 76 0 S.. Split
DEV019 01AC RW 0 19942 NR 0135 RW 76 0 S.. Split
DEV020 01B2 RW 0 32657 NR 015D RW 108 0 S.. Split
DEV021 01B8 RW 0 1039 NR 0163 RW 53 0 S.. Split
DEV022 01DE RW 0 29990 NR 02AB RW 76 0 S.. Split
DEV023 01E4 RW 0 0 NR 02B7 RW 76 0 S.. Split
DEV024 01D7 RW 0 25732 NR 013D RW 76 0 S.. Split
DEV004 0034 RW 0 46432 NR 01AD RW 94 0 S.. Split
DEV005 0042 RW 0 25804 NR 01BB RW 94 0 S.. Split

Total -------- -------- -------- --------
Track(s) 0 820163 2146 0
MB(s) 0.0 25630.1 67.1 0.0

Message was edited by:
devarsh

Can you post the output from:

symrdf -g DG1 query

between [ code] and [ /code] tags (without the space after the [)? It's recommended to remove the Symm serial number from this output.

We can then see where the invalid tracks are. I would also recommend upgrading your symcli version.

Marc

Hi Amit,

Sorry for the confusion the correct name is newbilling. I was trying not to put the real name "newbilling" in the forums and I missed to replace newbilling with DG1 in that line.

Message was edited by:
devarsh

So I was wrong .. you have two DMX (same family, same track size) so the issue I've found in our knowledgebase does not apply .. I'll try again .. hoping to guess better

That's a good point and well spotted! (but no need to quote the entire original post)...

Was newbilling renamed to DG1 or are they different disk groups? If so we'll need to see "symrdf -g newbilling query".

M

In case you need, we can hide the real DG name .. you have only to ask.

I have found that split the original pair with the -consistent switch has fix my database issues being inconsistent. Are all of your data and log files in the DG? If not you could be causing database corruption.

As I understand your issue is, you were in split state and some one make changes at R2 side now you have invalid tracks on both side....right? You tried to run estab and this was fail due to you have invalid tracks both side. I will use force option and run estab this will overwrite whatever changes you made at R2 side and data will be resynch from R1 side. I am sorry if I miss understtod your question.

Best regards,

Majid

Message was edited by:
Majid Ali

When you split your RDF pairs you have both R1 and R2 write enabled .. and you RW enable both sides since you have hosts at both sides willing to write on the devices, thus creating invalids on R1 against R2 and on R2 against R1.. I did it in the past and never had to force an establish to resume the RDF link .. Everything sound pretty strange to me.

I'm happy you fixed your issue however I think there was something broken .. You did a great workaround .. But I suspect the root cause is still there.

Yes Majid you have understood it right. I have done a full establish and it worked fine.

I wanted to avoid a full establish and was not sure if -force would do the job.

Could you please confirm if -force would work in this case.

Message was edited by:
devarsh

yeah ..strange indeed. Devarsh ..I would research it further cause it might be ok to do a full re-sync on a 40G database but what about when you get to multi-terabyte databases and then that whole mess with SLAs, RPO and RTO