DAOS – JAR files in Java agents. (UPDATE)

Yesterday I wrote about a supposed problem with DAOS.

Daniel Nashed contacted me and explained that it is not a bug; DAOS works as designed.

DAOS makes no difference between data and design documents. Only the presence of an objects of type attachment is decisive whether the object is transferred to the DAOS repository if the configured threshold value is exceeded.

Imported archive files in agents are therefore not the only objects that are transferred to the DAOS repository if the requirements are met.

The same behavior applies to Java Script Libraries, Forms, Pages and About & Using documents. Only JAR design elements are not affected because the data is stored differently here.

The application continues to work without problems. Problems may arise if the NLO files are moved to a DAOS T2 storage. In any case, the behavior of DAOS in connection with design elements should be kept in mind.


DAOS – JAR files in Java agents.

Martin Vogel from sirius-net GmbH informed me in an email about a possible problem with DAOS and Java agents.

If DAOS is activated on a database, in addition to the attachments from data documents, the jar files contained in a Java agent are also transferred to the DAOS repository if they exceed the set size.

I have been able to reproduce the problem with Domino V11.
I started with a freshly installed server, activated DAOS on the server

and enabled the database for DAOS.

load compact -c -DAOS ON barcode.nsf
[0B1C:0004-2C3C] 23.01.2020 18:26:48   Informational, DAOS has been enabled for database barcode.nsf.
[0B1C:0004-2C3C] 23.01.2020 18:26:48   Compacting barcode.nsf (barcode),  -c -DAOS ON barcode.nsf
[0B1C:0004-2C3C] 23.01.2020 18:26:48   Recovery Manager: Assigning new DBIID for C:\Domino\Data\barcode.nsf (need new backup for media recovery).
[0B1C:0004-2C3C] Clearing DBIID 5B9C3856 for DB C:\Domino\Data\barcode.ORIG
[0B1C:0004-2C3C] 23.01.2020 18:26:49   Compacted  barcode.nsf, 5K bytes recovered (<1%),  -c -DAOS ON barcode.nsf
[0B1C:0002-2F14] 23.01.2020 18:26:50   Database compactor process shutdown 

Result: Both archive files contained in the agent were transferred to the DAOS repository as NLO.

The agent continues to run without any issue.


DAOS enhancement in 8.5.2

The behavior of compact options is changed in 8.5.2 when compact options for DAOS and archiving are used in combination. You can now use a combination of options to DAOS-enable a newly created archive database.

load compact -a -DAOS on mail\database.nsf

When an archive database is newly created during the archive, the new archive database will be DAOS-enabled.
Important to know is that the combination of compact options will not affect the mail\database.nsf database itself, or any existing archive databases.
Also, the behavior of compact does not change when the otions -a and -DAOS off are used together.


DAOS: Get FileCount and RepositorySize on Linux

Migrated a Windooze server to Linux today. The files on the server are DAOS enabled and I wanted to get the number of files in the DAOS repository and the overall filesize.

Here is a small shell script that does the job

#!/bin/sh
REPOSITORY=/local/daos
OUTFILE=/local/daos.txt
fCount=`find $REPOSITORY -type f | wc -l`
fSize=`du -ksb $REPOSITORY`
IFS=”/”
array=($fSize)
fDate=$(date +”%d-%m-%Y”)
echo $fDate / $fCount / ${array[0]}>> $OUTFILE

On a daily basis, triggered by cron, it appends a new line like this one to the file defined in the OUTFILE variable

12-03-2010 / 26235 / 18743907789

You can now use the file to create charts with Dojo for example. Maybe there is a better way to accomplish the aim, but this works for me and perhaps it is useful for someone else.


Enabling DAOS on a database – new recommendation

Almost one year ago, I wrote about “How To Wast Space” when enabling DAOS on an application. And I assumed that it might not be sure that the compact task will always do the recompress BEFORE the attachments are moved to the DAOS repository.

The recommended way to enable DAOS on an application and recompress attachments was:

  1. load compact  mail\example.nsf  -c -ZU -DAOS ON

According to IBM technote #1411563, the new recommendation is to perform 2 compacts.

First, enable compression and then enable DAOS.  This is critical for customers which have upgraded from 6.5x to 8.5

  1. load compact  mail\example.nsf -c -ZU
  2. load compact  mail\example.nsf -c -DAOS ON

If you want to get the most out of DAOS, this is the way to do it.

btw. the IBM technote obviously has a typo. See the mistake?


Customize DAOSEST file attachment size

The daoest by default has a large gap in attachment size evaluation between 64k and 1 MB. You may wish to understand the value of setting the object size between these parameters

Set the Notes.ini parameter DAOSEST_BUCKETS to customize the size shown in the report.

For example:
DAOSEST_BUCKETS=16,64,128,256,512,768,1024,2048,3072,4096
The above line sets to 16K, 64K, 128K, 256K, 512K, 768K, 1MB, 2MB, 3MB and 4MB.

It can be set to any set of 10 values in kilobytes.

Source: Lotus Software KnowledgeBase #1418102


DAOS: Problem with SoftDeletion

One of our servers had the following error message in log.nsf

“The database F:\data\mail\xxxxxxxxx.nsf has the incorrect DAOS object count, you should run fixup on this database. Using this database in this condition will cause the DAOS catalog to go into the ‘Needs Resync’ state.”

The database already had DAOS enabled but the logical and physical filesize were almost the same. So I ran a load compact -c on the server console and the message immediately appeard on the console and in the log.

A fixup did not change anything. After some investigation I found that soft deletion was the cause for this issue.

I unchecked the option in the database properties and ran fixup again.

“Informational, rebuild view needed – collection object was deleted (reading F:\data\mail\xxxxxxxx.nsf view note Title:'($SoftDeletions)|($SoftDeletion’)”

After the fixup had finished, I enabled the option again. Another compact -c now transferred all attachments to the DAOS repository without errors.


DAOS and Resync

When your DAOS catalog gets out of sync, it has to be resynced again. This has not do be done immediately, because an out of sync catalog only affects the prune process. DAOS will work even with an out of sync catalog.

An earlier entry in the Lotus Notes and Domino Wiki described, how to automatically resync the catalog with DDM. This document has now been removed and replaced by a description of how to do the process using a program document. (DAOS: How To Set Up A Regularly Scheduled Resynchronization).

The most important information in this document is

Note that if a resync operation is performed when the DAOS catalog is already in ‘Synchronized’ state, the operation detect that there is no work to do, and will exit immediately.

This seems to be obvious as there is also a “tell daosmgr resync force” command, which will resync the catalog even if in syncronized state.

But the administration help is not clear enough as far as I’m concerned.

But what is the best time to schedule the program document? You can find out the best time for your environment by using the Log Analysis from the Administration Client.

If you want to be sure that the catalog is synchronized before 02:00 am, you have to find out how long the resync process lasts.

Open the Log Analysis in the Administration Client and search for “DAOSMGR: Resync”  ( Match all words ).

You will get a result like

DAOSResyncTime

If you want to schedule a daily resync after the prune process, you need to know, how long the prune process runs on the server.

Using Log Analysis and “DAOSMGR: Prune” for the search, you will get this result.

DAOSPrune

Now you can configure the program document and set the schedule time either 7 hours before or 15 minutes after the daily prune operation.


DAOSMinObjSize – DEFAULT value changed in 8.5.1

Today I came across an issue with DAOS and DCT. I thought it was an error in DCT. When I setup my test environment, I did not touch the default value for DAOSMinObjSize in the DAOS section of the server document.

After I ran DCT on this server, I found the following entry in the scan results.

DaosDct

I contacted Scott O’Keefe and asked him to review this rule. Scott replied immediately ( as always )

The default value has been changed in pubnames.ntf so that when DAOS is enabled the default minimum object size is 64000, to match the suggestion of the wiki.

DAOSMinObjSize


More Nagios, More DAOS

I have configured 2 more services on my Nagios server to check the size and filecount of the DAOS repository.

The filecount is determined by the check_file plugin by Tevfik Karagulle and I use a simple script on my Windows 2003 host to get the folder size in KB.

Const intOK = 0
Const intWarning = 1
Const intCritical = 2
Const intUnknown = 3

strDrivePathFolder = Wscript.Arguments.Unnamed.Item(0)
strWarningValue = Wscript.Arguments.Unnamed.Item(1)
strCriticalValue = Wscript.Arguments.Unnamed.Item(2)

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFolder = objFSO.GetFolder(strDrivePathFolder)

FolderSize = CDbl(objFolder.Size)
strWarningValue = CDbl(strWarningValue)
strCriticalValue = CDbl(strCriticalValue)

If ( FolderSize > strWarningValue ) or ( FolderSize > strCriticalValue ) Then 
  'Wscript.Echo "Inside outer If statement."

  If (FolderSize > strCriticalValue) Then
    'Wscript.Echo "Inside CriticalValue If statement."
    Wscript.Echo "CRITICAL: Folder Size is " & FolderSize &"|Folder.Size=" & FolderSize & ";" &  strWarningValue & ";" & strCriticalValue
    Wscript.Quit(intCritical) 
  End If

  If (FolderSize > strWarningValue) Then
    'Wscript.Echo "Inside WarningValue If statement."
    Wscript.Echo "WARNING: Folder Size is " & FolderSize &"|Folder.Size=" & FolderSize & ";" &  strWarningValue & ";" & strCriticalValue
    Wscript.Quit(intWarning)
  End If

End If

Wscript.Echo "OK: Folder Size is " & FolderSize &"|Folder.Size=" & FolderSize & ";" &  strWarningValue & ";" & strCriticalValue
Wscript.Quit(intOK)

Both programs are invoked from the nagios server by starting the check_nrpe plugin .

The result looks like this:

nagiosDaos

Once there is enough data collected, you can create nice looking graphs.


DAOS – Catalog needs re-sync on Domino startup

Whenever I start my Domino after a clean shutdown, the DAOS catalog needs to be re-synced.

I see the following message on the server console :

postponed

The behaviour is reproducable. I have done a fresh installation of Domino 8.5 on Windows 2003 server and configured the server for the first start. After the server has started successfully, I opened the server document in names.nsf and configured DAOS and transactional logging. I saved my settings and restarted the server by typing “restart server” on the console. The server came up and created the transaction logs. Then I restarted the server once again and from now on the message appears at every server start.

This seems to be the same as described here. Just wonder, if there is already a fix available.


DAOS: Transaction Protocol Trap

I’m recently working with DAOS on our production servers and had an issue with transactional protocol. Well not really a problem but a thing to check before you enable DAOS on a database.

As you might know, you must enable trasaction protocol on your server to be able to use DAOS.

But, there is a second place where transaction protocol is controlled; on the advanced tab of the database.

For some reason, transaction protocol was disabled on a handful of databases.

When you trigger a “load compact -c -daos on path\database.nsf” on the server console, the database is compacted and DAOS is enabled on the database. But none of the attachments from the database are moved to the DAOS repository.

When you type “load daosmgr status dbsummary” on the console after the compact task has finished, you will see the following output

daostrans

At this point, you should look at the advanced tab of the database, uncheck “Disable Transaction Protocol” and run compact again.


Impressive DAOS results

I recently ran daosest 1.1 on one of our production server.  The test took almost 48 hours. Here are the results.

Total DB’s analyzed: 957
Total DB’s skipped due to errors: 0
Total Size of NSF’s Examined: 1023.8 GB
Total Attachments found: 3070488
Total Duplicate Attachments found: 2084628
Total DAOS Eligible Attachments: 3070488
Estimated Size of DAOSified NSF’s: 89.6 GB
Estimate Size of DAOS dir: 335.0 GB
Total Disk Savings: 636.8 GB

I am really impressed. Never expected the calculated total disk savings.

If you want to use DAOS in a clustered environmen, here is some information by Paul Mooney.