How to disable urc_computer_addr replication, to prevent superfluous replication of remote control connection addresses.

Document ID : KB000009102
Last Modified Date : 02/03/2018
Show Technical Document Details
Issue:

Download replication of urc_computer_addr is taking a very long time, or has fallen behind to a point where it will no longer catch up.

Example:

Download_rep_crop.png

Environment:
Client Automation (ITCM) -- any version.
Cause:

The urc_computer_addr table stores remote control connection addresses.  The rchost plugin may report multiple connection addresses on each computer, to the domain manager.  A connection address could be a host name, IPv4 address, IPv6 address, etc.  Each domain manager uploads the connection addresses as they are reported, to the Enterprise manager, via Upload Replication.

By design, the Enterprise Manager attempts to maintain a copy of the global address book, including all the reported agent remote control connection addresses, at each domain manager.  To do this, when a new connection address is uploaded, it creates a copy of the record with the UUID of the Enterprise Manager.

In turn, the Download Replication of each Domain Manager will pull down all these connection address records, so every agent in the global address book will have a number of connection addresses listed.

By design, this type of replication is "infectious", whereby each Domain Manager receives an excess number of connection addresses, for computers that are registered globally and not necessarily registered with the Domain Manager.

Also the value of storing and replicating connection addresses, in some opinions, is little.  By design, the Remote Control Viewer will attempt to resolve the any hostname or FQDN on DNS, unless the user specifically selects one of the connection addresses.  Therefore to replicate connection addresses in this manner may be viewed as wasteful.

Resolution:

This procedure will turn off urc_computer_addr replication, for the ENTIRE ENTERPRISE:

Step 1: Disable the trigger tracking urc_computer_addr deletions in the enterprise database:
(Execute on the enterprise MDB)

disable trigger t_urc_computer_addr_del on urc_computer_addr;


Step 2: Remove download replication configuration for urc_computer_addr on the enterprise database:
(Execute on the enterprise MDB)

delete from ca_replication_status where replication_conf_uuid in (select replication_conf_uuid from ca_replication_conf where table_name='urc_computer_addr' and direction > 0);
delete from ca_replication_conf where table_name='urc_computer_addr' and direction > 0;


Step 3: Clear the pending history table deletions for the DMs on the enterprise:
(Execute on the enterprise MDB)

select count(*) from ca_replication_history where table_name='urc_computer_addr';

If the count is >10 million records, I recommend deleting in batches of 1 or 10 million at a time, otherwise you may overflow the transaction log of the database and risk a lengthy rollback:

delete top (10000000) from ca_replication_history where table_name='urc_computer_addr';

Otherwise, if you have 10 million or less records, you can just run the normal delete to clear all the records from the history table:

delete from ca_replication_history where table_name='urc_computer_addr';


Step 4
: Remove unrelated computer addresses sent by the enterprise from all DMs:
(Executed on each domain manager MDB)

-- Disable trigger tracking deletions from the enterprise
  /* This is necessary so upload replication doesn't capture
      the deletes and remove the enterprise managers data. */
disable trigger r_d_urc_computer_addr on urc_computer_addr;

-- Delete data sent by enterprise
delete from urc_computer_addr where domain_uuid not in (select set_val_uuid from ca_settings where set_id=1);

-- Enable the deletion trigger
enable trigger r_d_urc_computer_addr on urc_computer_addr;

-- Cleanup orphaned computer addresses on the DM.
delete from urc_computer_addr where computer_uuid not in (select dis_hw_uuid from ca_discovered_hardware);

Note: CAF should be stopped while performing step 4 on each Domain Manager.  Step 4 is not a time sensitive step.  Steps 1 thru 3 are sufficient for eliminating the download replication records.  Step 4 is to provide cleanup on each Domain Manager, in order to remove records already pushed by the Enterprise Manager, and eliminate records for connection addresses of computers that are not registered at the Domain Manager.