![Cisco BTS 10200 Softswitch Troubleshooting Manual Download Page 758](http://html.mh-extra.com/html/cisco/bts-10200-softswitch/bts-10200-softswitch_troubleshooting-manual_67550758.webp)
16-10
Cisco BTS 10200 Softswitch Troubleshooting Guide, Release 5.0.x
OL-8723-19
Chapter 16 Disaster Recovery Procedures
Element Management System Database Recovery from Hot Backup
Total System Power Outage
Step 1
If the platforms start, take them down first.
Step 2
Audit the Oracle database.
Step 3
Check the mysql database.
Step 4
Clear the data directories on both CallAgent sides and do a fresh download from the EMS.
Step 5
On all platforms repeat the following steps:
a.
Enter the following command:
cd <platform>/bin/data; rm *
b.
Restart both sides using the following command:
platform start all
c.
Do a fresh download (extract Oracle data from the EMS and send it to the Call Agent). See the
BTS
10200 Command Line Interface Guide
.
d.
Check the transaction queue to make sure that data is going from the EMS to the CA.
e.
Enter the command
audit db ems
to either make sure everything is in sync.
Step 6
Discrepancies will have to be fixed via CLI commands.
Caution
This may take hours to complete and during this time, call processing is lost, that is why it is critical that
there is no common single point of failure in the power feeds.
Element Management System Database Recovery from Hot
Backup
This section provides procedures to restore your Oracle EMS database data files from the most current
hot backup and then recover your database from the backup. If additional archive log backup (by
ora_arch_backup.ksh) was done after the hot backup, the additional archive log backup file sets need to
be restored also. All of these backup file sets are assumed to be located on the remote FTP site.
Directory to restore backup files:
/opt/oraback
.
The following assumptions were made for this procedure:
Daily backup schedule:
2:00 AM–daily hot backup (by ora_hot_backup.ksh process)
18:00 PM–daily archive log backup (by ora_arch_backup.ksh process)
Oracle databases on both primary and secondary EMS systems crashed completely at January 10, 2002,
20:00pm.