Hello

I create a replication group for an application that has about 300 libraries in all, each name of which begins  with AAS.  Then I create INCLUDE spec for Object=*ALL, Type=*ALL, Library=AAS* and iCluster adds all 300 entries of each specific library name for me.  Then I remove the AAS* entry.  When I start the group for the first time, I see the following message in iCluster event log and iCluster shows the count of 3 for 'S/O'  :

COREPRO1 OMI0234 20 iCluster cannot mirror content changes to user space AAS1/XVCLB.0001 because the user space is in the system domain.

COREPRO1 OMI0234 20 iCluster cannot mirror content changes to user space AAS1/XVCLB.0002 because the user space is in the system domain.             

COREPRO1 OMI0234 20 iCluster cannot mirror content changes to user space AAS2/X02LB.0001 because the user pace is in the system domain.                                                             

A discussion with the app implementation team reveals that the app uses some number of user space, data queue, and data area in several of its libraries but somehow the exhaust list of these objects and their libraries is not available.    The local iCluster SE tells me that I should add DMSELOBJ INCLUDE spec. to the group for data queue and data area to these 300 libraries and specify MIRRCNTS(*NO) as a good practice.  He also tells me I may need to also add EXCLUDE spec. for *USRSPC to all the 300 libraries as well.   This will make a total of 1,200 entries of DMSELOBJ in the group definition.

My question is whether there is any principle or practical concern on adding too many DMSELOBJ entries in a replication group?  

Thanks.

Hi Satid,

This application you describe is quite large.  We must keep in mind when configuring iCluster that, not only volume of data in the selection, but also the transaction volume this selection represents and potentially the total number of objects contained. Although the single selection statement will allow you to easily add all these libraries to a single replication group, there are additional considerations.  

• Are a portion of the libraries part of an archive of data that is potentially dormit? 
• Are all these libraries really representative of the active application and data?
• Are all the journalable objects in these libraries now all journaled to the default journal defined for this replication group or were they previously assigned to journals for other services such as resiliency or commitment-control?

So yes, the selection captured the name specification of the desired libraries, but will the resulting replication group perform well?  iCluster is designed to have one apply process per group per data journal.  So if the data was spread across multiple data journals and well balanced well, the group, despite its size for a single group could perform well even though a sync check could take some time to complete.  What I'm suggesting is that you may want to analyze if there are additional logical separations that exists beside the library prefix of AAS*.  That would allow you to easily split this into multiple replication groups rather than only having one.

The essential part of your other question is do the data ques need to exist on the backup or will the application create them as needed (in the event of a switchover)?  If the application will create any missing Data queues, then the best method would be to add the necessary exclusions.  Again, looking for an easy way to reduce the effort using wild card specifiers.  At minimum you would need one generic selection per library to exclude all Data Queues. 

Rocket also offers professional services to walk through the implementation to help get you up to speed and fully deployed quickly if that would be helpful.