Update 2 - April 17 2017 - IBM has fixed the issue in 9.0.1 FP8 IF1.

Update - March 31 2017 -  You may not want to enable this, see this post.

New in Fix Pack Feature Pack 8 is the ability to move the view index files out of the NSF. NIF is the technical term for these index files and end with the file suffix of NDX. Doing this has several advantages including:
  • Make the NSF smaller, so better backup times
  • Help get more out of the 64GB limit....if 6GB of your NSF is NIF index, that's a logt of space
  • Move NIF's to better performing storage, for example SSD's
  • Allows concurrent access to to databases and views, so theoretically better performance

I decided to upgrade my production cluster to FP8 and turn on this new feature that was originally slated for 9.0.2. Here's what I did:
1.        I added a new VMDK for these new files, in my case an i: drive and a folder, so my NIF path is i:\NIF\
2.        Upgraded server to FP8
3.        Made sure CREATE_R9_DATABASES=1 (or CREATE_R85_DATABASES=1) is in the notes.ini file
4.        Added NIFNSFEnable=1 to the notes.ini
5.        Added NIFBasePath=i:\nif\ to the notes.ini
6.        Added CREATE_NIFNSF_DATABASES=1 to the notes.ini (this makes any newly created NSF use the NIF repository so you don't have to constantly worry about enabling it for new databases)
7.        Restarted Domino

Like DAOS before it, this only enabled NIF, it doesn't switch it on for existing databases. So on the server I issued a compact command:

load compact -c -nifnsf on mail\blah.nsf

Off the server goes and here's the output:

Image:Moving Domino NIF indexes out of the NSF

Oooh. Off I go to look at the new NIF drive and sure enough there it is:

Image:Moving Domino NIF indexes out of the NSF

Humm. Not a lot of savings....25MB (about 8% savings, and not a lot of folders). OK, let's try my archive mail file, that's a big-ish one:

Image:Moving Domino NIF indexes out of the NSF

Better. About 11% of the archive were view indexes (archive is 6.5GB logical size...not physical).

So what are we seeing here? Well, I think you'd see much larger savings, 25% or more, if you have a custom application with lots and lots of heavily used views and lots and lots of documents. And if that app is, oh, let's say 40GB then you can shave 10GB+ off that size that is not a bad thing. Mail seems to be between 5-15% for the record. Still that *could* equate to 15% off the time to backup your data, so even that maybe worth doing in your environment.

In some environments it may also be useful doing the Domino Directory, in this case (and for admin4 and log) the server needs to be down.

Further details are in this IBM article.

Darren Duke   |   March 29 2017 11:16:32 AM   |    domino    |  
  |   Next Document   |   Previous Document

Discussion for this entry is now closed.

Comments (4)

Gravatar Image
1 - Eric Tomenga       03/29/2017 1:31:53 PM

Nice bit of info here. Thank you. Has there been any noticeable change is speed of building views?

Gravatar Image
2 - Sean Murphy       03/29/2017 3:40:54 PM

DB2 views anyone? I never thought this day would come, better late than never I guess. I created a new replica of one of our largest databases using NIFNSFEnable=1. This NSF contains 842,000 docs with pdf attachments from our web-based reporting system. It was at 62 GB file originally. Once the new DB was created it shrunk to now 48 GB logical. The NDX object created for the views was 6.5 GB. I did not initialize all of the views with the client, so I suspect it will net out the same disk usage.

My plan is to upgrade one of the nodes in our Domino cluster and re-create the troublesome NSFs with separate ndx views and see if view performance for our web pages are any better, the views are categorized and embedded in a form with a selection formula for viewing in the browser.

Gravatar Image
3 - Christian Henseler       03/30/2017 12:31:31 AM

You may be aware of a negative performance impact where I/O is not the limiting factor(reported by Michael Bourak).

You may wait for FP8IF1...

Gravatar Image
4 - Adam Osborne    http://www.preemptive.com.au    03/30/2017 5:15:02 PM

Thanks for the info, just take care because the "load compact -c nifnsf" will most likely create mass fragmentation that will negate any backup benefit you get from the reduced file size.