An instance of Microsoft SQL Server contains a group of databases. Some are called system databases created during the SQL Server installation. Others are called user databases that are added later to store the data of business applications. Each SQL Server database is self-contained, which means that when using PowerFlex replication, the RCG can contain a single database, multiple databases, or all the databases.

In general, it is recommended to only replicate user databases, and have the SQL Server instance with the system databases preinstalled at the target site. In that way, in a case of a disaster at the source site, the replicated user databases can be quickly added to the pre-existing SQL Server instance at the target site.

An alternative solution is to replicate both user and the system databases in either single, or multiple RCGs. By replicating the system databases any updating or modifications that took place at the source site are reflected in the replicated databases at the target. A disadvantage of this strategy is that since the SQL Server instance is not already running at the target, it takes a while to resume operations after a disaster at the source.

A key design consideration when deciding on databases to include in each RCG, is that when using remote snapshots while the PowerFlex replication is active, the snapshot granularity has to contain all the volumes of an RCG.

If remote snapshots are used to create database copies for purposes such as test, development, and reporting. The design decision of which databases to include in the RCG, determines the databases that are available while using remote snapshots of these RCGs.

For example, While replicating two user databases remotely, and using the remote snapshots to provide database copies for testing groups:

• If the remote snapshots are always created together for both databases, they can share the RCG.
• If the remote snapshots need to be refreshed at different times, then they should use different RCGs.