Oracle Communications EAGLE (Software)
 

PLA-Support>Sun Systems>CommsGBU>Global Signaling Solutions>SN-SND: Tekelec Eagle 5
 

In this Document

Goal

Solution

Created from <SR 3-12993566882>

Applies to:

Goal

RTDB defragmentation/memory claim procedure in EPAP

Solution

This KM Doc focuses on DN/IMSI only. Other data occupy very small space and are very less in numbers and will not create too many problems.
Basic:

-------
SM4G has 4 GB memory, SM8G has 8 GB memory. SM8G will use memory beyond 4GB, ONLY when Eagle is in 64 bit. A 32 bit Eagle with SM8G card will still use maximum 4GB memory.
When there is less memory space available then the amount of data present in the data base, there could be two reasons:
1. RTDB fragmentation leaving unused memory
2. Few entries were made of one type and later all entries were deleted resulting in a table's worth of memory unused.

In both the cases, making a fresh RTDB from PDB, will free the memory which are otherwise unused.

Both the cases are referred as fragmented RTDB in the document here onwards, as in both the cases there are unused memory which can be reused by claiming those memory again.

When to think of defragmentation?

-----------------------------------------
When there is RTDB 80% full alarm in EPAP 15.0/16.0 or RTDB 90% full alarm in EPAP 16.1 (and later releases till we implement 480M DN) , it’s time to look for possible RTDB defragmentation or memory leakage due to previous entries getting removed from DB resulting in a table's worth of data unaccounted for.

How to determine, EPAP system have reached the limit?

---------------------------------------------------------------
The following condition will imply, RTDB defragmentation is a MUST i.e. without RTDB defragmentation, further provisioning will not be possible after reaching a certain boundary.
Open EPAP GUI.
Click on the link “RTDB -> View RTDB Status”.
You will see two fields.
“DB Size” under “Local RTDB Status”.
“Min DSM Size” under “RTDB Configuration”.
Find out the difference between the two and let’s call it “Available Memory”.
e.g.
Available Memory = Min DSM Size - DB Size.

Note: fractional number has been made next whole number in the below memory requirement
e.g. 200.17 M will be treated as 201M.

In EPAP 15.0/16.0:
If Available Memory < 201 M; The defragmentation is a MUST. No further DN can be provisioned from the next available boundary. We will see a little later, what the boundary is.

In EPAP 16.1:
If Available Memory < 401 M ; The defragmentation is a MUST. No further DN can be provisioned from the boundary. We will see a little later, what the boundary is.
For IMSI, the required memory in EPAP 15.0/16.0 and in EPAP 16.1 will be 194 M and 387 M respectively.
For DNs they are 201 M and 401 M respectively.

Boundaries in EPAP 15.0/16.0: (Same boundaries applies to both DN and IMSI):

-----------------------------------------------------------------------------------------
The boundaries in EPAP 15.0/16.0 are:
……, 90M, 97.5M, 105M, 112.5M, 120M
Which means,
If the current DN count is 101M and the available memory is less than 201 M, the maximum that the system can go is, upto next boundary i.e. 105M. There after provisioning will stop.
If the current DN count is 107M and the available memory is less than 201 M, the maximum that the system can go is, upto next boundary i.e. 112.5M. There after provisioning will stop.
Boundaries in EPAP 16.1:
The boundaries in EPAP 16.1 are:
……, 180M, 195M, 210M, 225M, 240M
Which means,
If the current DN count is 206M and the available memory is less than 401 M, the maximum that the system can go is, upto next boundary i.e. 210M. There after provisioning will stop.
If the current DN count is 220M and the available memory is less than 401 M, the maximum that the system can go is, upto next boundary i.e. 225M. There after provisioning will stop.

In Summary:

---------------
EPAP 15.0/16.0:
If you see 80% alarm in EPAP 15.0/16.0. Read this MOP and find out the available memory. See where we stand? How many Millions are remaining till we hit the next boundary? Based on that figure, talk to customer about their average daily burn rate and find out how many days the system can survive without going over allocated. Then decide whether you want to defragment immediately or after few days.

EPAP 16.1:
If you see 90% alarm in EPAP 16.1. Read this MOP and find out the available memory. See where we stand. How many Millions are remaining till we hit the next boundary? Based on that figure, talk to customer about their average daily burn rate and find out how many days the system can survive without going over allocated. Then decide whether you want to defragment immediately or after few days.

How to defragment/claim memory of RTDB in EPAP?

---------------------------------------
Note:
It is advisable that the RTDB defragmentation is done on a PROV server. This will ensure there is no network overhead when RTDB is made from PDB.
Open EPAP GUI.
1. Put EPAP in “Forced Standby” mode.
Open the link “Maintenance -> Force Standby -> Change Status”.
Click on “Activate STANDBY Restriction”.
2. Make fresh RTDB from PDB
Open the link “RTDB -> Maintenance -> Reload from PDBA”.
Click on “Reload”.
After many hours (based on DB size), the RTDB will be made a fresh. The new RTDB will have got rid of unused memory.

NOTES:

--------

In EPAP 15/16:

1. If the DN + IMSI count has already reached more than 112.5M , there is NO chance of gaining any memory back by the activity

2. If the DN + IMSI count has already reached more than 105M AND Available memory is less than 201M,  there is very small chance of gaining memory depending upon presence of other small tables. Consult DS for exact calculation before moving ahead with the procedure.

3. If the DN + IMSI count is less than 105M AND Available memory is less than 201M, there is bright chance of reclaiming lost memory. Go ahead with the procedure. You may consult DS if any doubt for exact calculation.

This solution has no attachment