Oracle Communications Subscriber Data Management (SDM)
 

PLA-Support>Sun Systems>CommsGBU>Broadband Network Solutions>SN-SND: Tekelec SDM
 

In this Document

Goal

Solution

References

Created from <SR 3-12358313381>

Applies to:

Goal

The following document describes the steps needed to restore Geo-Redundancy and resync the databases.

Oracle Support recommends collecting the following data should investigation be required:

• General SDM data collection documented on DOC ID 2213261.1
• SRDC - Data Collection for SDM Replication Issues - DOC ID 2211955.1

Data collection should be attached to SR.

Solution

Should a planned or unplanned event cause loss of Geo-Redundancy of the SDM SPR, Oracle Support recommends taking the following manual actions to resync the Backup/Replica SPR site.

Geographic replication using replication link

In a Geo-Redundant deployment, the Data Provider Controller has the additional role of exchanging information with its peer by establishing direct connection using the public Geo-Redundancy Virtual
IP address of the remote site. The Public Geo-Redundancy Virtual IP address is activated when the database service become active. Each site has its own Geo-Redundancy Virtual IP. The Geo-Redundancy VIP is re-activated on the new active on switch over events.

Once the connection between the two Geo-Redundant sites is established, the Data Provider Controller is in charge of managing the synchronization and replication between the main active database in a ReferenceProtected state and the main active database in a Replica state of the two sites geographically distributed. This exchange of information between the two sites is done through a master-to-master replication link. Moreover, the Data Provider Controller can manage successfully the synchronization and replication of the data between two sites even if they are located in different time zones. The database replicated between the two sites includes the subscriber profile and the service-specific volatile data. Every update applied against the database on a given site is replicated on the peer site.

The connection between the two geo-redundant sites can be lost in cases where:
1. There is a problem with the physical connection between the two sites.
2. There is a problem at one of the two sites. A database switchover on one site would cause the geolink to go down temporarily. A complete power failure at one site would cause the geolink to go down permanently.

In the case where the connection between the two sites is lost, either due to the physical connection or the operational state of the other site, the state of the database changes. If the state of the database was in a replica state, it becomes in a PendingReference state and if it was in a ReferenceProtected state, it becomes in a Reference state. The operator can force the database to change from the PendingReference state to the Reference state.

If the Geo-Redundancy feature was disabled and later enabled once again or simply if the negotiating phase of the synchronization process could not determine which site has the reference database and which one has the replica database, the synchronization process would get into an unassigned state (UnassignedEnabled). To get out of this unassigned state, the operator must execute the resume operation, which will force the synchronization process to reenter the negotiating phase in order to identify which site has the reference database and which site has the replica database.

Action Plan

1. Evaluation SDM and physical connection between the two  sites.  If  no obvious failures are seen, then you can reattempt to restore Geo-Redundancy and sync databases.

2. If not issues found, then restart blueservice on the Active Back End (BE) Server at the Replica site. This will cause the Active Replica BE Server to re-sync to the Active ReferenceProtected Server and then the Replica Stdby BE Server will resync to its Active Server.

service blue stop
service blue start

3. Validate blueservice has successfully restarted on the Replica Active and Geolink is established.

4. Monitor database synchronization, Execute the following command to monitor database synchronization:

tail -f /blue/var/log/DpController.out

Example command output:

At this time, the SDM Geo-Redundancy should be restored and the databases should be in-sync.

Should this procedure fail, please collect the specified data and open a SR with Oracle Support to investigate the failure.
 

This solution has no attachment