Comments on this forum and guidance in the Knowledgebase suggest that name indexing will boost performance considerably. We have around 12000 users in the object directory - should we turn on name indexing?
What kind of performance improvement could we expect, all things being equal?
Generally, it is a good practice to index databases over 10,000 users/nodes. However, you should see the big picture too. Is your database on direct-attached storage, how fast are the disks? Do you have overlapping database tasks like reports and backups running at the same time? Did you exclude your database directory from virus scanning? Did you make the recommended OS tweaks? Do you clear your user and machine audits on a schedule? If not, take a look at the attached best practices guide.
There are lots of ways you can increase performance; database indexing is just one of the options. Also, if you're trying to speed up the "search" functionality, database indexing will have no impact. The search does not make use of the index.
The only risk of indexing is that it is another thing that could become corrupted, so you have to be sure to clear/purge the index on a regular basis (preferrably daily).
We only have 1500 users and 400 some devices currently but enabling database indexing made a huge difference in performance for our LDAP connector. Connector execution went from 20-30 minutes to 2 minutes.
The storage is directly attached SCSI disks in a RAID array. I have seen the attached guide and am checking through the items in the list to ensure that they are correctly configured, but my reading of the comments on this forum was that indexing would make a substantial difference, other things being equal. In fact, the guide says that "name indexing should be enabled on all databases especially those with over 1000 endpoints or users" so my view is that this should have been done from day 1.
Apart from the risk of corruption and the need to schedule a daily purge, are there any other disadvantages of indexing? And are there any guidelines as to how long a purge will take?
Also, if we ever need to drop and rebuild the index, is there a tool to do that? I'm browsing through the documents and haven't found one yet. What do you do if the index becomes corrupt?
Interesting comment about the LDAP Connector - the original performance issues were noted with the AD Connector.
there's a script (toastcache) which will force an index rebuild, but it will rebuild periodically of its own volition - you get to set how long it lives for, but not when it rebuilds (hence the toast script).
the reason indexing speeds up the connectors is quite simple - duplicate checks don't have to trawl the db anymore, they can be performed on the (much!) smaller index.
We have been running SafeBoot DE/MEE for PC for almost 4 years and only needed to run toastcache a few times (5000+ machines). Daily seems a bit excessive.
The risk associated with having a scheduled toastcache event is that it has the ID/password of a privileged account in the script. This means that anyone with read permission to that script (or a backup copy of that script) could alter your encryption database contents/settings. This should be an acceptable risk if your server has restricted access and your automated backup copies are not recoverable by any backup system administrator.
It doesn't need to be a very privileged account. ToastCache calls SbAdmCl getcounts and that seems to work fine using a user that has an admin level of 1 and with only a single admin right, namely users\administration.