Guest

Cisco BTS 10200 Softswitch

Switchover Data Mismatch Deferror Prevention (Release 5.0 MR 1.1)

  • Viewing Options

  • PDF (135.8 KB)
  • Feedback
Switchover Data Mismatch Deferror Prevention Feature Module for Release 5.0 MR 1.1

Table Of Contents

Switchover Data Mismatch Deferror Prevention Feature Module for Release 5.0 MR 1.1

Query Oracle Replication Queue on the Active EMS

Job Status Query

Query Number of Unpushed Calls

Control Element Manager to Switchover

Control Element Manager without Forced=Y

Control Element Manager with Forced=Y


Switchover Data Mismatch Deferror Prevention Feature Module for Release 5.0 MR 1.1


Revised Date: April 15, 2008

This feature module describes enhancements for Release 5.0 MR1.1 to prevent Oracle data mismatch errors upon switchover. Previously, at EMS switchover, the standby EMS platform was transitioned to active without waiting for the Oracle replication queue to completely drain from the active EMS. To alleviate this, the Session Manager (SMG) now waits 120 seconds when a switchover is initiated to allow the replication queue to drain. Two new commands, Query Oracle Replication Queue on the Active Element Management System (EMS) and Control Element Manager to Switchover have also been added.


Caution If any command response states that the Oracle Replication Queue is broken, contact Cisco TAC.

Query Oracle Replication Queue on the Active EMS

Two new commands permit querying either the status of a job or the number of unpushed calls left in the replication queue.

Job Status Query

This command queries the job status of the Oracle Replication Queue. A user must be logged in to Oracle to execute this command. This example shows that the replication PUSH job is broken. The Oracle Replication Queue is not draining. If the Oracle Replication Queue is broken, it will never drain.

Examples

priems# su - oracle

Sample response:

$ dbadm -r push_job_status

JOB=2 BROKEN=Y FAILURES=0

Query Number of Unpushed Calls

This command queries Oracle for the number of unpushed calls left in the Replication Queue and the estimated time for the Queue to drain. The following example shows that there are 18262 calls in the Replication Queue that may take up to 514 seconds to drain.

Examples

$ dbadm -r unpushed_defcall_cnt

Sample response:

UNPUSHED_CALLS=18262 ESTIMATED_PUSH_TIME_SECOND=514

Control Element Manager to Switchover

When the CLI Control Element Manager to Switchover command is executed, the system now checks the replication queue for unpushed calls. If the number of unpushed calls is greater than a preset threshold, the control command fails. If switchover is still desired, regardless of the unpushed calls in the queue, the option FORCED=Y is permitted. However, the system now waits 120 seconds before switching over, which allows as many unpushed calls as possible to drain.

Control Element Manager without Forced=Y

This command checks the status of the Oracle Replication Queue before executing a switchover. The following example shows that the control command fails because the Oracle PUSH job is broken. A Database Alarm is given. Contact Cisco TAC for support.

Examples

CLI>control element-manager id=EM01; target-state=standby-active;

Sample response:

Reply: Failure: at 2007-07-19 15:50:42 by optiuser
   The replication queue contains 128262 transactions, and it is expected
   to take 513 seconds for the queue to drain.

Control Element Manager with Forced=Y

The following example forces the system to switchover. It does not check the status of the Oracle Replication Queue.

Examples

CLI>control element-manager id=EM01; target-state=standby-active; force=y