To runtimestate or not to runtimestate?

We all know that CUCM database replication issues are serious. We are checking database every time there is an upgrade, server cores, new machine is added, etc., just to ensure that our customer will have properly functioning environment.

We all know CLI commands like utils dbreplication status or utils dbreplication runtimestate, but what these commands really do and what is the logic of using them?

I’ve seen many people running runtimestate command as a basic database replication test. You just check if servers are connected with status of “(2) Setup Completed” and all’s good, isn’t it?

Let’s take a look at example dbreplication check. I just put show status command bellow for time reference. Please notice the date: Feb 12th, 2017.

show-status

Now, let’s just run our old good utils dbreplication runtimestate:

1struntimestate

Interesting huh? Output says “Replication status command started at: 201701-23-05-42“, but the date we’re running the command is actually 2017-02-12. 

What does it mean? Well, here is the thing – utils dbreplication runtimestate, apart from showing the replication setup in real time, shows the output of database tables check. But what actually starts the table check is utils dbreplication stauts command. What does it mean is that when you’re logging into your CUCM and you just run runtimestate command, server will show you the outcome of table check from the last time you issued utils dbreplication status command. In my example that was 23rd of January 2017. So if you really want to check what is your current table status, you should always run utils dbreplication status command first, followed by utils dbreplication runtimestate to see if check is completed.

Let’s take a look at the bellow example. I run status command:

dbstatus

Now lets run runtimestate:

2ndruntimestate

See? Now we have info that replication status command started at the day we actually want to check it. There is also information that “Replication status command COMPLETED 42 tables checked out of 681“. This is perfectly normal. CUCM is just checking every table in its database, which takes time (the bigger database you have the longer it can take). Let’s wait couple minutes and run runtimestate command again:

3rdruntimestate

CUCM checked its all 681 tables and found no errors. That’s the proper check.

In case you have an issue with database and there are errors or mismatches, there is a very good article posted on Cisco Support Forum which goes deeply into database troubleshooting procedure and I strongly recommend to read it:

https://supportforums.cisco.com/document/52421/troubleshooting-cucm-database-replication-linux-appliance-model

 

Thanks!

1 thought on “To runtimestate or not to runtimestate?

  1. Pingback: CUCM Python scripting | Voicexplained

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s