Managing Resynchronization from the LSMS

3 Managing Resynchronization from the LSMS

This chapter describes the features required for resynchronization, the resynchronization types, and how to initiate and manage resynchronization from the Oracle Communications LSMS (LSMS) (Local Service Management System).

3.1 Introduction

This chapter describes how to determine if an LNP database needs to be restored and assists in choosing one of the methods that can be used to complete the restoration. LNP Database Synchronization Overview provides an overview of the variety of methods available; this chapter helps you determine when you need to perform one of the methods and helps you choose which method is most appropriate.

Once you have decided which restoration method to use, see “Understanding Sequence of Procedures to Be Performed” for a summary of the various procedures you must perform in the order indicated. The remainder of this manual provides the detailed instructions for the procedures to be performed.

An LNP database in a given network element that needs to be restored when a condition occurs that has caused the LNP database to be corrupted or back-level. The following are examples of conditions that cause a need to restore an LNP database:

A network outage occurs
A hardware failure occurs at the system where the network element’s LNP database resides
Software that controls LNP databases has been stopped

When the condition has been repaired, the LSMS and network element attempt to perform automatic resynchronization, which requires no user action. For information about the actions performed by the LSMS and network element during automatic resynchronization, see “Automatic Resynchronization Process”.

When the LSMS and network element reconnect, the network element sends the LSMS the Database Time Stamp (DBTS) of the last update it received before the outage. If the LSMS finds that DBTS in the LSMS resynchronization database, it begins automatic resynchronization using the same protocol as is used for normal updates.

If the LSMS determines that automatic resynchronization cannot be performed because the DBTS cannot be found in the LSMS resynchronization database, notifications are posted at both the LSMS and the network element (see “Notifications that Database Maintenance Is Required”). If those notifications are posted, you can choose among various options for proceeding with synchronization (see “Choosing a Synchronization Procedure”).

3.2 Notifications that Database Maintenance Is Required

During an attempt to automatically resynchronize, if the LSMS cannot access necessary log files or cannot find the network element’s DBTS in the LSMS resynchronization database, the following actions occur:

The LSMS sends this notification (with event number 0002) to the LSMS graphical user interface (in addition, Surveillance notifications with the same event numbers are posted):
```
[Critical]:  <Timestamp> 0002 <CLLI> NE DB maintenance required
```
The LSMS informs the network element that database maintenance is required.
The network element displays the following notification on the network element terminal (the number xxxx indicates how many other notifications have already been displayed at the terminal):
```
rlghncxa03w 01-09-07 11:50:04 GMT EAGLE 39.0.0.0
*C  xxxx.0041 *C LSMS Connection  A1   LNP DB Maintenance Required.
```
After any of these notifications, the LSMS administrator and the network element operator should confer and choose one of the synchronization options described in Choosing a Synchronization Procedure.

3.3 Choosing a Synchronization Procedure

When the LSMS and the network element require database maintenance (see Notifications that Database Maintenance Is Required), the LSMS and network element operators should confer to decide on the method they will use to perform the database restoration. After they have agreed which method to use, they work together to complete one or more procedures (see Understanding Sequence of Procedures to Be Performed).

Use one of the following procedures to restore an LNP database, listed by priority of least elapsed time and operator intervention (for more information about performance estimates for the various methods, see Understanding Sequence of Procedures to Be Performed):

Copy the RTDB from the standby ELAP on the mated network element—If the mated network element (NE) has both RTDBs synchronized with the LSMS (as indicated by the EMS status indicator for the mated network element displaying green on the LSMS graphical user interface), copy the standby RTDB from the mated NE to the RTDB that requires restoration.
This method requires:
1. Determination that the mated NE’s standby ELAP RTDB is current with the LSMS (indicated by the EMS status indicator displaying green for the mated network element on the LSMS graphical user interface).
  If the EMS status indicator displays yellow or red, choose between method 2 and method 4.
2. User action at the LSMS to verify that the mated NE is configured properly as a mate.
3. Sufficient bandwidth in the customer network, which connects the mated NEs.
4. Stopping software both on the ELAP from which the RTDB is being copied and also on the ELAP to which the RTDB is being copied.
  This method is recommended when both RTDBs at a given NE require recovery (after one RTDB has been restored, its mate can be restored by copying the newly restored RTDB). The time required to complete this method depends on the bandwidth of the customer network, as shown in Table D-2 (then add approximately 9 minutes to copy to the local network element’s mate RTDB). For a detailed description of this method, see Copy RTDB from Remote.
Support ELAP reload via database image—This function replaces the Copy the RTDB from the ELAP Mate process. This method has faster reload times and provides synchronous data replication between the active and standby nodes.
This method requires:
1. LSMS 12.0 (or greater) and ELAP 9.0 (or greater).
2. User action at the NE to allow a user-initiated bulk load from the LSMS to occur (this action prevents an inadvertent initiation of a bulk load or resynchronization).
3. User action at the LSMS GUI to initiate and manage the bulk download.
  For detailed instructions on this method, see SERVDI Bulk Download.
Attempt a user-initiated resynchronization from the LSMS—User-initiated resynchronization is possible as long as the database time stamp (DBTS) in the RTDB that requires restoration is no more than seven days older than the current time at the LSMS.
This method requires:
1. User action at NE to allow a user-initiated resynchronization or electronic bulk load from the LSMS to occur (this action prevents an inadvertent initiation of a user-initiated resynchronization).
2. User action at the LSMS GUI to initiate and manage the resynchronization.
  For instructions on performing a user-initiated resynchronization, see .
Perform an electronic bulk load from the LSMS—If none of the other methods described in this section is possible, perform an electronic bulk load from the LSMS.
This method requires:
1. User action at NE to allow an electronic bulk load from the LSMS to occur (this action prevents an inadvertent initiation of an electronic bulk load).
2. User action at the LSMS GUI to initiate and manage the electronic bulk load.
  For instructions on performing an electronic bulk load, see Bulk Load Procedure.
Copy the RTDB from the ELAP mate—If the RTDB on the mate ELAP is current or can be automatically resynchronized with the LSMS, copy the mate ELAP’s RTDB to the RTDB that requires restoration.
This method can be completed in about 9 minutes; it requires:
1. Determination that the mate ELAP’s RTDB is current with the LSMS (indicated by the EMS status indicator displaying yellow for this network element on the LSMS graphical user interface).
  If the EMS status indicator displays red, choose among methods 1 through 4.
2. Disconnection of both mated ELAPs from the LSMS for about nine minutes during the copy of the current RTDB to the RTDB that requires restoration.

3.4 Understanding Sequence of Procedures to Be Performed

For most synchronization methods, the following phases must be completed:

Preparing for synchronization.
Preparing and transporting data to be used for synchronization.

Distributing LNP database synchronization at the network element.

Some phases are accomplished automatically by the LSMS and network element, and some phases require operator intervention. Table 3-1 summarizes, for the various synchronization methods described in this manual, which phases are required for each method and where those phases are described in this manual.

Table 3-1 Procedures Required for Synchronization Phases

	Method	Phase 1 Preparing NE	Phase 2 Initiating or Completing Data Transport	Phase 3 Distributing Data
Resynchronization Methods	Automatic resynchronization	Not required	Automatic, as described in “Automatic Resynchronization Process”
Reconcile Methods	Audit and reconcile	Not required	Managing Audit and Reconcile from the LSMS GUI	Automatic
Bulk Load Methods	Support ELAP reload via database image	Verify that EMS Status Indicator on the LSMS is yellow	SERVDI Bulk Download and Restore RTDB on ELAP	Distributing an RTDB to Service Module Cards
	Reload from standby ELAP’s RTDB on mated network element	Verify that EMS Status Indicator on the LSMS for mated network element is green or yellow	Copy RTDB from Remote	Distributing an RTDB to Service Module Cards
	Electronic bulk load from the LSMS to ELAP	4	Managing Bulk Load from the LSMS	Distributing an RTDB to Service Module Cards
	Reload from mated ELAP RTDB	Verify that EMS Status Indicator on the LSMS is yellow	Restore RTDB on ELAP	Distributing an RTDB to Service Module Cards