How long does global sync take?

Document ID : KB000014598
Last Modified Date : 14/02/2018
Show Technical Document Details
Question:

Is there a way to determine how long each stage of global sync takes?

Environment:
Any CAPM environment
Answer:

The following steps can be taken to get this information from the netqosportal database

  1. Open a linux shell to CAPC
  2. Run the following command to connect to the database: mysql netqosportal
  3. Run the following query: select from_unixtime(synctime), stagename, (endtime-starttime)/60, Status, ErrorMessage from global_sync_log order by synctime desc, stagename limit 18;

Here is an example of the output:

+-------------------------+---------------------------------+------------------------+---------+--------------+

| from_unixtime(synctime) | stagename                       | (endtime-starttime)/60 | Status  | ErrorMessage |

+-------------------------+---------------------------------+------------------------+---------+--------------+

| 2017-05-30 00:28:07     | GlobalSync                      |                 0.0167 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Access_Rights            |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Alias                    |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Cached_Items             |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Device_Life_Cycle_States |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Domain_Groups            |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Dynamic_Groups           |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_group_Items              |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Items                    |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Item_Combination         |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Item_Members             |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Item_Relations           |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Item_Types               |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Property_Types           |                 0.0167 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Relation_Types           |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Subnets                  |                 0.0000 | Success | NULL         |

| 2017-05-30 00:28:07     | Global_Tenant_Groups            |                 0.0000 | Success | NULL         |

| 2017-05-26 23:06:37     | GlobalSync                      |                 0.0167 | Success | NULL         |

+-------------------------+---------------------------------+------------------------+---------+--------------+

As you can see, we show how long each stage took, along with the status, and any error messages that may have occurred.  We are limiting the output to 18 records but can certainly tweak that if needed

 

Additional Information:

If a stage took a long period of time you can look at the DMService.log to try and determine how many items were being synced during the time in question.  You might see lines like the following:

| Processing 63975 device items 

| Processing 4577475 interface items 

| Processing 86601 address items 

 

Based on this, some significant change must have occurred on a data source.  This would be something you could pursue with the owner of the application in question