> # Merging the Database

> The merge behavior depends on the fabric-wide merge control setting:

> - Restrict—If the two databases are not identical, the ISLs between the switches are isolated.
> - Allow—The two databases are merged using the merge rules specified in Table 17-4.

> Table 17-4 Database Zone Merge Status
> Local Database | Adjacent Database | Merge Status | Results of the Merge
> --- | --- | --- | ---
> The databases contain zone sets with the same name1 but different zones, aliases, and attributes groups. | Successful. | The union of the local and adjacent databases.
> The databases contains a zone, zone alias, or zone attribute group object with same name1 but different members. | Failed. | ISLs are isolated.
> Empty. | Contains data. | Successful. | The adjacent database information populates the local database.
> Contains data. | Empty. | Successful. | The local database information populates the adjacent database.

> 1In the enhanced zoning mode, the active zone set does not have a name in interop mode 1. The zone set names are only present for full zone sets.

> Caution | Remove all non-pWWN-type zone entries on all MDS switches running Cisco SAN-OS prior to merging fabrics if there is a Cisco MDS 9020 switch running FabricWare in the adjacent fabric.

> The merge process operates as follows:

> 1. The software compares the protocol versions. If the protocol versions differ, then the ISL is isolated.
> 2. If the protocol versions are the same, then the zone policies are compared. If the zone policies differ, then the ISL is isolated.
> 3. If the zone merge options are the same, then the comparison is implemented based on the merge control setting.
> 1. If the setting is restrict, the active zone set and the full zone set should be identical. Otherwise the link is isolated.
> 2. If the setting is allow, then the merge rules are used to perform the merge.

> Copyright 2010-2013, Cisco Systems, Inc. All rights reserved.