Contents

1   Introduction

This instruction concerns alarm handling for the Storage Engine, Deleted Data Due to Reconciliation alarm.

1.1   Alarm Description

The alarm is issued if data has been deleted from the Data Store (DS) data partition due to a data reconciliation process.

The possible alarm causes and the corresponding fault reasons, fault locations, and impacts are described in Table 1.

Table 1    Alarm Causes

Alarm Cause	Description	Fault Reason	Fault Location	Impact
The automated reconciliation process has deleted data to achieve consistency.	Data was deleted from the Data Store (DS) data partition due to a data reconciliation process to achieve consistency.	No fault, a data reconciliation task is ongoing or pending.	DS Unit Group (DSG)	No impact, the reconciliation task must be finished.

The alarm attributes are listed and explained in Table 2.

Table 2    Alarm Attributes

Attribute Name	Attribute Value
Auto Cease	No
Module	STORAGE-ENGINE
Error Code	12
Timestamp First	Date and time when the alarm was raised for the first time.
Repeated Counter	Number which indicates how many times the alarm was raised.
Timestamp Last	Date and time of the most recent alarm raised.
Resource ID	.1.3.6.1.4.1.193.169.1.2.12.<DG>
Alarm Model Description	Deleted data due to reconciliation, Storage Engine
Alarm Active Description	Storage Engine (DS-group #<DG>): Deleted data due to reconciliation.
ITU Alarm Event Type	communicationsAlarm (2)
ITU Alarm Probable Cause	databaseInconsistency (160)
ITU Alarm Perceived Severity	(5) – Minor
Originating Source IP	Node IP where the alarm was raised.
Sequence Number	Number which indicates the order in which alarms were raised.

In Table 2, the indicated variables are as follows:

• <DG>: The DS Unit Group (DSG) where the deleted data was stored.

For further information about attribute descriptions, refer to CUDB Node Fault Management Configuration Guide, Reference [1].

1.2   Prerequisites

This section provides information on the documents, tools and conditions that apply to the procedure.

1.2.1   Documents

Before starting this procedure, ensure that you have read the following documents:

• CUDB System Administrator Guide, Reference [2] for further information.
• CUDB Node Fault Management Configuration Guide, Reference [1], regarding alarm configuration.
• System Safety Information, Reference [6]
• Personal Health and Safety Information, Reference [7]

1.2.2   Tools

Not applicable.

1.2.3   Conditions

Not applicable.

2   Procedure

If the alarm is raised, do the following:

1. Establish an admin "CUDB CLI" session towards the target CUDB node:

   ssh <admin_user>@<CUDB_Node_OAM_IP_Address>

2. Run the following command to check if there are any pending or ongoing reconciliation tasks:

   sudo cudbReconciliationMgr -l

   This command returns the DSG in affirmative case. Otherwise, it returns nothing. In affirmative case, wait for the task to be completed.

   Refer to CUDB Node Commands and Parameters, Reference [3] for further information about this command.

3. Check the log information about reconciliation to see the distributed data involved in the process. For more information, refer to CUDB Node Logging Events, Reference [4].
4. Clear the alarm manually as described in CUDB Node Fault Management Configuration Guide, Reference [1].

Glossary

For the terms, definitions, acronyms and abbreviations used in this document, refer to CUDB Glossary of Terms and Acronyms, Reference [5].

Reference List

CUDB Documents
[1] CUDB Node Fault Management Configuration Guide.
[2] CUDB System Administrator Guide.
[3] CUDB Node Commands and Parameters.
[4] CUDB Node Logging Events.
[5] CUDB Glossary of Terms and Acronyms.

Other Ericsson Documents
[6] System Safety Information.
[7] Personal Health and Safety Information.