!!! What are Obituaries
Since eDirectory is a [Distributed Data Store], each server receives updated information through synchronization. Since all the servers in the replica ring are [Eventual consistency], the server may not hold the same information at a given time. As a result, each server holds on to the old information until all the other servers receive the updates. [eDirectory] uses [{$pagename}] to keep track of this type of information and more.

! [{$pagename}] are created when an eDirectory object is:
* [DELETED|Delete Request]
* [MOVED|ModifyDNRequest]
* [RENAMED|ModifyDNRequest]
* RESTORED
The [obituary] itself is an [attribute] of the object on which the change took place. The reason for an [obituary] [attribute] is created is to maintain [database] consistency between real copies of the object and [NDS External References] of the changed object. 

!! [PurgeVector]
[{$pagename}] will only be purged per [partition], if the [ModifyTimestamp] of the [OBIT_PURGEABLE] obituary is OLDER then the [timestamp] value recorded for the [Purge Vector] [attribute], for each server [Replica number] in the [Replica List] as used in the [Transitive Vector]. The [PurgeVector] will only be updated if the [partition] has a successful sync cycle. The purpose of [PurgeVector] attribute is to prevent [{$pagename}] from being purged before all [Edirectory Replicas] have been [OBIT_NOTIFIED]. The values in the attribute are recorded per [Replica number], therefore per server in the [Replica List]. [Ndsrepair] checks and fixes the[{$pagename}] values.

%%warning
While the [{$pagename}] is actually stored as an attribute on the [Partition Root Entry] the __Obituary Vector__ is stored only in memory and is recalculated each time that the [Janitor] Process runs.  To see what the Obituary Vector actually is you can turn on the [Janitor] filter in [Ndstrace].
%%

! [NDS Obituaries Types]
[eDirectory] utilizes 14 different [NDS Obituaries Types]

Three of these types are monitored.
Data is displayed for three different types of obituaries:
* [OBIT_DEAD]: created when an object is deleted.
* [OBIT_NEWRDN]: created when an object is renamed.
* [OBIT_MOVED]: created when an object is moved from one location to another. 

! [NDS Obituaries Classification]s
[NDS Obituaries Classifications] of an obituary determines how it is processed. Currently, there are four classes of obituaries. 

! [NDS Obituary States]
In order for an [NDS Obituaries] to be processed or deleted from eDirectory the must go through several [NDS Obituary States].
Most NDS Obituaries must go through the following NDS Obituary State in order:
* [OBIT_ISSUED]
* [OBIT_NOTIFIED]
* [OBIT_OK_TO_PURGE]
* [OBIT_PURGEABLE]
You can check on the [NDS Obituary States] using [Ndsrepair]

! There are 12 different distinct combinations for a given [{$pagename}]
[NDS Obituary States] and monitored [NDS Obituaries Types] generate the distinct combinations:
* [OBIT_DEAD_ISSUED]
* [OBIT_DEAD_NOTIFIED]
* [OBIT_DEAD_OK_TO_PURGE]
* [OBIT_DEAD_PURGEABLE]
* [OBIT_NEWRDN_ISSUED]
* [OBIT_NEWRDN_NOTIFIED]
* [OBIT_NEWRDN_OK_TO_PURGE]
* [OBIT_NEWRDN_PURGEABLE]
* [OBIT_MOVED_ISSUED]
* [OBIT_MOVED_NOTIFIED]
* [OBIT_MOVED_OK_TO_PURGE]
* [OBIT_MOVED_PURGEABLE]
In [imonitor] a number is displayed against each of these combinations, which denotes the total number of objects that are in a particular state at the end of the last obituary processing cycle. 
The change cache count displays the number of objects present in the change cache of the partition in the current server. 

!! [{$pagename}] Process Optimization
Prior [EDirectory 8.8.8.0 (20801.46)] had two redundant methods of processing obituaries: 
* [BackLinks]
* [DRLs] ([Distributed Reference Links]).  The DRL method has been removed eliminating these unnecessary cycles.
Additionally, if all servers in a ring are on [EDirectory 8.8.8.0 (20801.46)], [OBIT_OK_TO_PURGE] is no longer used in processing [OBIT_DEAD], [OBIT_NEWRDN] and [OBIT_MOVED] [{$pagename}].  This results in the cycles required to process an obituary being reduced by 50-75%.  Some tests have shown a reduction of up to 230% in the total time to process [{$pagename}]. 
Another side benefit is there are far fewer "UsedBy" and "Obit_UsedBy" obituary attributes that need to be processed.

Prior to [EDirectory 8.8.8.0 (20801.46)], the [{$pagename}] process __would not run__ on a [partition] if the server was currently outbounding changes for that [partition] to other servers.  This would cause [{$pagename}] for that partition to be delayed. In a busy environment with hundreds of changes per second this could lead to [Change Cache] buildup.  Now the obituary process can run in parallel with outbound synchronization thereby reducing [{$pagename}] processing delays.


!! Category
%%category [eDirectory]%%

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Obituary Troubleshooting in eDirectory|https://support.microfocus.com/kb/doc.php?id=7011536|target='_blank'] - based on information obtained 2018-11-27-