Automatic Rebuild of CLUBUSY.NSF (Clustered BusyTime) Domino 6.0.2CF1

pts.
Tags:
Lotus Domino
I am experiencing periodic corruption/integrity problems with the Clubusy.nsf database on a Domino 6.0.2.CF1 server environment. CLUBUSY.NSF is the clustered version of BusyTime.nsf used for scheduling meetings with people and booking rooms and resources via the Room Reservation database. I have 4 clustered Mail servers and 2 Clustered Application Servers (2 different clusters) The Mail server CLUBUSY.NSF hold people busytime and thr Applciations server CLUBUSY.NSF room and resource busytime. I have asked IBm Software SUpport on this and they want to charge me for the pleasure of a fix - I cannot believe that no-one else has similar problems. When these databases get corrupted or fail to operate orrectly the usual method of correction is rebuild. To rebuild the databases it is necessary to stop the CalComm and Scheduler tasks on each server in the cluster, delete the Clubusy.nsf database on each server and then restart the Scheduler and CalConn tasks on each server. It is easy to stop and start the tasks via nserver commands and RCMD but it isn't easy to delete the clubusy.nsf - this has to be done within the Notes Environment because there is always some process accessing the database (to book a room, schedule a meeting, etc). It is possible to delete the clusbusy.nsf from a Notes client using an id with sufficient access (or the Server Notes Client). I want to be able to setup a scheduled automatic rebuild of the clubusy.nsf (to occur out of working hours) so I need to be able to do this programmatically, triggered from one coordinating point. Has anyone done this?, If so, how? If not any ideas would be welcome. I have ideas along the lines of setting up an Agent which will action the rebuild process on all the servers but my Script knowledge is not sufficent to be able to build such a beast. Any help would be greatly appreciated and I'm sure many others could benefit too. Dave

Answer Wiki

Thanks. We'll let you know when a new response is added.

Before you build any agents to rebuild the cluster system file, please look in log and check to see if you have any errors messages like replication errors or index build errors. Another thing that can be causing your problem is the resouse.nsf, this file should not be replicate to another server. It should be available in one server. If you still have the busytime.nsf on your cluster server, that mean that the cluster manager has not build the cluster busytime db.

Run this command on the server console, to force adminp, to process any pending process that might have been stuck in qoueue, Tell Adminp Process All. The what the cluster db fo any error.

if you want to rebuild the db at off hour create a program doc, that run the Fixup and updall task onthe db. You can schedule this for any time.

Good Luck!

Discuss This Question: 8  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • ThomasBalatka
    Hi, i have a batchfile with following Commands on windows System: c:notesNserver -c "dbcache flush" c:notesNserver -c "Drop all" c:notesNserver -c "dbcache flush" del d:notesrundataclubusy.nsf in 95 Percent this works fine for me, also scheduled! Explanations: "DBCACHE FLUSH" -- Writes all Cached data to disk, and empty Cache! c:notes => Notes SRV Executable Dir! c:notesnserver -c => set a command on the Server Console! hope this helps! Thomas If one clubusy.nsf is corrupt, the other could be fine and replication would fix this issue!
    0 pointsBadges:
    report
  • Jvpaton
    Hi Dave, BTW - how often is it happening? Maybe replace the template as well. The following link is an IBM technote that gives the details for debugging busytime problems. The debug info may help identify what is causing the problems. Remember that debugging will put extra load on the server. http://www-1.ibm.com/support/docview.wss?rs=0&uid=swg21141060 I have seen a few comments around about weekly deletions of clubusy.nsf to avoid problems, so it seems that it's not just you. Unfortunately they mostly don't specify Domino versions, so not sure if an upgrade might help (even though it's not identified as a fix). GL :) Vanessa
    0 pointsBadges:
    report
  • DAPSynch
    Thank you for the replies which gave food for thought and I have followed up on some of the suggestions such as replacing the templates by one on a clustered server which is used by the stable clubusy. I also on the advice of IBM Tech Support switched off Transaction logging (you can do this for individual databases by a checkbox in the 'Propeller head' tab in the Database properties) This was supposed to speed up the rebuild process. I have over 6000 mail users on the 4 servers in the cluster - it took 3 days to fully populate the clubusy database and since removing Transaction Logging it takes half the time but it went unstable after 2 days of user. Today the 4 clubusy databases had varying numbers of entries ranging from 1500 to 5100 (both less that the 6000+ mail users hosted by these servers. In a fit of desperation I manually replicated the databases with eachother - this made no obvious difference to the variation o number of records. I used te console command "Tell Sched Validate" - this forces the Scheduler to rescan the whole database - it added a few records but didn't 'equalise' the database replicas. My friendly IBM support person was very frustrated and had me running "Show Directory" commands which proved to be even more confusing as none of the servers showed Clubusy.nsf and some other crucial database such as Names.NSF", Admin4, Log.nsf and others - any one have any ideas on this one? The problem has been escalated to the Server team now plus I've been asked to action a Cluster analysis using the Admin Client but I don't feel any closer to solving this problem. Any further thoughts would be very welcome. One other thought - because the Clubusy database takes so long to rebuild IBM actually advise people to avoid rebuilding the database on a regular basis. Any opinions? Looking forward to some more feedback - my managers are getting a little impatient now.... Regards
    0 pointsBadges:
    report
  • Jvpaton
    Well, that sounds even worse! Did you build these servers? If not, do you know if they were correctly installed? I had a situation once with Domino on a windows server with a load of strange problems, and it seemed that the server just wasn't installed correctly, after installing straight over the top (after a good backup of course) I later found out that the server had previously been rebuilt, and the Domino directories had simply been restored from tape - no install of Domino Server. Anyway, just a thought. Also, have you considered an upgrade? I'd go to 6.5.2 or 6.5.1 (6.5.3 apparently has some issues) GL 8!8
    0 pointsBadges:
    report
  • DAPSynch
    My CLUBUSY saga continues. My IBM Lotus Support techie is convinced that my servers are not correctly set up and have taken the Notes.ini files to check (haven't heard anything for 2 days now...) New symptomns that have come to light: 1. I didn't have enough Cluster Replicator Tasks running to cope with the demand which probably accounts for the lack of synchronisation between the different clubusy.nsf files on the servers in the cluster. I've increased the number of tasks to 10 using the Notes.ini entry "CLUSTER_REPLICATORS=10" via the server configuration document. 2. The problem consistently occurs over the weekend ie all fine on Friday then Monday morning the Clubusy lacks considerable numbers of entries. The tasks that run over the weekend include: Compact with space recovery (22:00 Friday night), fixup -j (06:00 Sun before backup) updall on the $ServerAccess and $Users views on names.nsf (02:00 & 04:00 Sunday before backup) Full backup (we are using Tivoli Storage Manager TDP for Domino) A Compact -s 10 is run Tue-Fri (02:00) Catalogue is run daily Mon-Fri (04:00) Statlog is run daily Mon-Fri (01:00) Updall is run daily Mon-Fri (05:00) Design is run daily Mon-Fri (04:30)(Design refresh) Anyone see any obvious connection here? I plan to monitor the clubusy database this weekend just to see when it does get compromised... Thanks again for your input Dave
    0 pointsBadges:
    report
  • Rkeefer
    You didn't by any chance do an incremental update instead of a full install? I have seen incremental updates cause all sorts of strange problems... Additionally Domino uses the data directory as a temp space for domino so if your data drives do not have enough disk space things can get weird and unexplainable... Are you having any other wierd issues that seem unrelated, corrupt ACL's replication issues etc?
    0 pointsBadges:
    report
  • Dool
    I have been using a product called GSX ServerGuard for several years to rebuild the clubusy database on a weekly basis. I have this setup to stop CalConn, stop Sched, delete clubusy.nsf, start Sched, start CalConn. This process causes the clubusy to be rebuilt and it is re-populated with all of the current entries in the individual calendars. We also use this product to perform weekly re-boots of the Domino servers in order to clear up any memory leaks. Any time we need to re-start a Domino server after hours we simply set up a one-time maintainence schedule to restart the server. It has worked flawlessly for us. It is a relatively inexpensive product. I believe there may even be an evaluation copy available from their website (www.gsx.net).
    0 pointsBadges:
    report
  • DAPSynch
    Thank you al for your advice and comments. The latest I have on this problem with CLubusy.nsf integrity is that in Domino R6.0.2CF1 there is a bug. This is fixed in R6.5.3 and R6.0.5 (still in beta so not really available). IBM have me told that I can expect a hotfix but given that my company is about to embark on rolling out R6.5.3 on a pilot basis my installation is a dead ringer! I expect I'll be upgrading to 6.5.3 before the hotfix comes available. In the meantime my user population will just have remain frustrated when they get the 'Busytime unavailable' message. Thanks again Dave
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following