Troubleshooting&Best Practices For ReadUnread Marks
Troubleshooting&Best Practices For ReadUnread Marks
Troubleshooting&Best Practices For ReadUnread Marks
2012
Manisha Parida - Lotus Technical support engineer Presenter Sandeep R Deshpande - Lotus Technical support engineer Presenter Hansraj Mali - Lotus Technical Advisor Focussing on Notes/Domino, LotusLive Ranjit Rai - Lotus Technical Advisor Focussing on entire Notes/Domino Jayavel Rajendran - Lotus Technical Advisor Focussing on entire Notes/Domino Vinayak Tavargeri Lotus Support Facilitator for Open Mics
Agenda
Unread Marks Architecture How are Unread Marks Updated? How are Unread Marks Maintained? Tips for troubleshooting unread mark issues Best Practices
Q/A
Unread marks are a list of unread documents within a Notes database. Use note ID tables to track all unread documents. If a note ID is in this table,it will appear as a UNREAD document. If it is not in the table it appears as READ. Each user that accesses a database has an individual Unread ID table in a database How the Unread ID table in a database looks like ?
Notes Client has unread mark journal which tracks individual operations for each database replica ID by UNID and it is present in cache.ndk Journal operations are applied to unread table on database open Journal is circular and has a limit on the total operations it can retain Mark All operations are treated as Mark All Before This Time
Unread Mark journal can be disabled with notes.ini parameters: For databases that replicate unread marks
DEBUG_LIMIT_UNREAD_JOURNAL=1
Unread mark table is created when a user first opens the database All note Ids are initially added to the user's Unread ID table Read a document, remove a note id On next db open, newly modified docs are added to the table Works well for single replica-multiple client machines scenario
User reads documents in replica on Server A Unread Mark Journal tracks operations User opens database on Server B Journal operations are then applied to table in replica B
Most of the unread mark issues are seen in this scenario. Notes.INI parameter introduced to synchronize unread mark tables during client-side replication REPLICATOR_SYNC_UNREAD=2 will sync Unread ID table every one hour (half of the 2) Or
Lotus iNotes iNotes directly uses the Unread ID table to mark the document as read (It does not use Unread mark journal like Notes Client.)
Blackberry, Traveler: Essentially use their own systems that wrap/integrate with the Unread ID table and thereby directly modifying the Unread ID table in database.
Unread Activity logs are stored per user in the NSF database Log entries include timestamp of operation These logs will replicate! Data organized into chunks to help minimize I/O. Only necessary chunks are loaded/replicated to avoid performance issue. Old data is purged (Replication Cutoff) This is how Unread Activity log looks like -
Replicates individual chunk entries between databases Uses adjusted activity time for sequence Minimizes server bounceback Client-initiated replication only processes user's activity logs Do not mark modified documents unread should be selected
Playback starts from the oldest modified log entry since playback.
Do not mark modified documents unread ignores modified docs since read operation
Repalce the design of mail file. Shut down the Client and rename cache.ndk.
After starting the Notes Client, go to workspace and unstack replica icons for mail file and then select both icons and then exchange unread marks by going to Edit > Unread marks > Exchange unread marks. So unread marks from first selected replica will be pushed to second selected replica.
e.g.- DEBUG_UNREAD=50 (32 + 16 + 2) then extreme logging related to management and those for view refresh are captured. DEBUG_UNREAD=512 for document mark read/unread logging
Best Practices:
If you are upgrading your Domino servers in cluster, then always upgrade both servers to same version, if you just upgrade one server, then you might face unread mark issues. If you are creating a new server in cluster then always make sure to have the parameter ADMINP_EXCHANGE_ALL_UNREAD_MARKS =1 in source server before you create new replicas on secondary server. Use the parameter REPL_SYNC_ALL_UNREAD=1 carefully, if you add it to server where unread marks are incorrect, then all replicas may end up with incorrect unread marks.
Make sure to select Database Properties > Advanced > Replicate unread marks to All Servers for all your mail files on server and on local. If using a custom mail template, use the template based on at least 8.5.1 or above as using older template like 8.5 may cause some unread mark problems. If unread marks are getting affected during weekend then probably some third party software if running on weekend might be responsible for corrupting NSF databases, so try to exclude some databases from it or try to disable it for some time and check again.
Best Practices:
There are some unread mark issues fixed in Domino 8.5.2 FP2 version, so if you are using an earlier version of Domino, then upgrade to Domino 8.5.2 FP2 (preferably 8.5.3) to fix these issues. If the cache.ndk of the users is frequently getting corrupted and recreating the cache.ndk is resolving the problem, then something might be wrong in your mail template. This generally happens with custom mail templates, so try using a standard mail template for few users and monitor. Use the Debug parameters like Debug_Unread=xx at last if nothing is helping at your side. You need to give the logs to IBM for analysis or if you are interested you can have a look at logs yourself and you may get a clue what is going wrong. While exchanging unread marks between 2 replicas from workspace, always select the replica with correct unread marks first and then select the replica with incorrect unread marks.
Additional resources
Unread count for a folder is greater than actual number of unread documents Technote #1110573) http://www.ibm.com/support/docview.wss?uid=swg21110573
Questions?