When the distributed database topology has been fully configured with GDSCTL commands, run the GDSCTL DEPLOY command to deploy the Oracle Globally Distributed Database configuration.

When you run the GDSCTL DEPLOY command the output looks like the following.

GDSCTL> deploy
deploy: examining configuration...
deploy: requesting Data Guard configuration on shards via GSM
deploy: shards configured successfully
The operation completed successfully

What Happens During Deployment

As you can see, when you run DEPLOY several things happen.

• GDSCTL calls a PL/SQL procedure on the shard catalog that examines the distributed database topology configuration to determine if there are any undeployed shards present that are able to be deployed.
• For shards that need to be deployed, the shard catalog sends requests to the shard director to update database parameters on the shards, populate topology metadata on the shard, and direct the shard to register with the shard director.
• If Oracle Data Guard replication is in use, and standby databases are present to deploy, then the shard director calls PL/SQL APIs on the primary shards to create a Data Guard configuration, or to validate an existing configuration on the primary and standby sets. Fast Start Failover functionality is enabled on all of the shards and, in addition, the shard director starts a Data Guard observer process on its host to monitor the Data Guard configuration.
• If new shards are being added to an existing distributed database that already contains deployed shards (called an incremental deployment), then any DDL statements that have been run previously are run on the new shards to ensure that the application schemas are identical across all of the shards.
• Finally, in the case of an incremental deployment on a distributed database using system-managed or composite data distribution methods, automatic chunk movement is scheduled in the background, which is intended to balance the number of chunks distributed among the shards now in the configuration. This process can be monitored using the GDSCTL CONFIG CHUNKS command after the DEPLOY command returns control to GDSCTL.

What Does a Successful Deployment Look Like?

Following a successful deployment, the output from CONFIG SHARD should look similar to the following, if Data Guard active standby shards are in use.

GDSCTL> config shard
Name      Shard Group          Status   State     Region   Availability
--------- -------------------  -------  --------  -------  ------------
cdb1_pdb1 shardgroup_primary   Ok       Deployed  region1  ONLINE
cdb2_pdb1 shardgroup_standby   Ok       Deployed  region2  READ ONLY
cdb3_pdb2 shardgroup_primary   Ok       Deployed  region1  ONLINE
cdb4_pdb2 shardgroup_standby   Ok       Deployed  region2  READ ONLY

If mounted, non-open standbys are in use, the output will be similar to the following, because the shard director is unable to log in to check the status of a mounted database.

GDSCTL> config shard
Name      Shard Group         Status        State     Region   Availability
--------- ------------------  ------------- --------  -------  ------------
cdb1_pdb1 shardgroup_primary  Ok            Deployed  region1  ONLINE
cdb2_pdb1 shardgroup_standby  Uninitialized Deployed  region2  -
cdb3_pdb2 shardgroup_primary  Ok            Deployed  region1  ONLINE
cdb4_pdb2 shardgroup_standby  Uninitialized Deployed  region2  -

What To Do If Something Is Not Right

If any shards are showing an availability of PENDING, confirm that all steps related to ADD INVITEDNODE and CONFIG VNCR from the topology configuration were completed. If not, complete them now and run GDSCTL SYNC DATABASE -database shard_name to complete shard deployment.

If the "State" column of the GDSCTL config shard command output shows a shard that is "Replicated" instead of "Deployed," then the shard did not register with the GSM listener during deployment. Any of the following steps can resolve the issue assuming that the ADD INVITEDNODE and CONFIG VNCR steps in Add Host Metadata were completed:

1. Connect to the shard as SYS and run

   alter system register reconnect;

2. Stop and restart the shard PDB.

3. Stop and restart all GSMs.

After performing one of the three actions above, run CONFIG SHARD to verify the state of the shard.