The Great updall argument...

Wednesday 16th August, 2006
On this thread, on edbrill.com, NeilT writes:

"However take that same server, issue a "load updall -r -c" and you will see the space utilisation grow in a spectacular way. That is because the new files will have no indexes. As soon as the indexes are built, you can kiss goodbye to a large chunk of space which will never come back again until you do a compact -d. But the first thing that will happen is that the indexes will come back again as you can't use the databases without them."

I point out in a response that this is fundamentally wrong:

NeilT,

I have never, ever seen anyone issue a "load updall -r -c" on a production server...it's non-sensical.

Either you have indexes and they need rebuilding and you use -r or you don't and you need to create with a -c. These switches just don't have much purpose being issued together.

"Updall -c" alone should be issued sparingly. Yes, on a huge database with thousands of documents you may want to pre-create indexes for that specific database but as a general command...never.

View indexes can be set to be discarded over time for a reason...they aren't in use. There's no point in indexing, and re-indexing, views that a user doesn't use regularly if at all. On my user mailfiles, I estimate that only 25% of the views are in use in the production environment. All the others have either never been built or have long since been discarded. Issuing an "updall -c" will just waste space building an index that isn't required.

"updall -r" only rebuilds indexes that already exist so won't actually use up any more space at all. In fact, as the views get rebuilt, they may even get smaller as they are optimised to take into account deleted documents etc.

So yes, 'issue a "load updall -r -c" and you will see the space utilisation grow in a spectacular way', but who the hell would ever do that?

Neil replies:

Well Ben,

Updall -r updates all indexes used once or more. Updall -c updates all indexes never used and all FT indexes. So, if you want to force a full update of ALL indexes after a rebuid/Updgrade, you will ALWAYS use updall -r -c. Well if you don't want to be doing it real time during user log-in at peak periods and jamming your server up.

As you have said, indexes which are unused are discarded after 45 days. So you create a new database/do a full compact, front load it with all indexes then let lack of use remove those which are not used.

Which part of proactive maintenance and server load levelling did I miss?

Remember that I'm on record as saying the disk usage of indexes are not an issue, so long as you manage it.

What I left you to infer was that claiming this index usage doesn't exist by comparing unindexed databases leads customers to believe they don't need to expand their disk capacity. Disk is cheap, accept and plan for it is what I was saying. Doing the other leads to dissatisfaction and defectors for completely avoidable reasons.

I'm not sure if he hasn't read my reply, or it's hard to teach an old dog new tricks but I followed up:

On the technical side you're wrong, but I don't see any value in a public argument; by all means contact me off-line to discuss further if you wish.

Neil:

Ahh technically wrong. I shall remember that :-)

Bill says he wants to slap me when he's on my side. The last guy I publicly humiliated because he was wrong (and tyring to make me accept it), made my life a misery for 2 years. I shall instead refer you to "Updall options" in the Domino Administrators Guide and leave it at that.

However if you are challenging the processes I use to design/support Domino servers, you have every right to do that and I won't have a public fight over it.

Which naturally called me out in public which I didn't want to do but, seeing as Neil won't take it offline, then here we are.

Yes, I am challenging you - but this isn't the place. I've created a new thread...just for you...I hope Bill is watching :O)

So, we're here Neil...do you want this? Do you want me to tell me you why you are wrong?

Comments/Trackbacks [11]