Resourcen Datenbank => doppelte Buchungen

[kloeti]

Sali zämme...

Wir setzten einen Domino Enterpriseserver im Cluster ein. Momentan auf der Version 5.06a (english), das ganze läuft auf NT4 mit Servicepack 6a.

Auf dem Server setzten wir die Resourcendatenbank ein, die Sitzungszimmer und Fahrzeuge und den ganzen Kram zum Reservieren zur verfügung stellt. Seit einer Weile melden mir die User, dass es doppelte Buchungen gibt, was früher nicht war.
Auf der anderen Seite kann man Ressourcen, die reserviert waren und dann wieder gecancelt wurden nicht mehr sehen.

Auf der notes.net Seite habe ich erfahren, dass ich die clusterbusy.nsf auf beiden Servern löschen muss, dann soll es wieder gehen. Hab ich jetzt ein paar mal gemacht, aber nach einer Weile fängt das Theater von vorne an und ich will das Ding nicht jede Woche von Hand löschen.

Kennt jemand das Problem? Irgendeine Lösung?
Jede Hilfe ist sehr Willkommen.

Gruzz
kloeti

[eknori]

Hallo kloeti,

guckst du hier:

du musst im script nur statt der busytime.nsf die clubusy eintragen.

http://www.atnotes.de/cgi-bin/yabb/YaBB.pl?board=Downloads;action=display;num=1013789292

eknori

[kloeti]

Aha... ein Workaround   ... Wie auch immer, ich werd's mal probieren und sage vielen Dank erstmal  

Gruzz
kloeti

[eknori]

Es gibt nur diesen Workaround; eine LÖSUNG habe ich selber noch nicht gesehen.
Selbst in der Knowledge Base steht das so beschrieben.
Also habe ich ein Tool programmiert, das mir wenigstens diese lästige Arbeit abnimmt.

eknori

[kloeti]

Hi,

Hab da noch was in eigener Recherche gefunden... wer Zeit hat, kann es sich ja mal zu Gemüte führen  :-/

So ein Scheiss  
kloeti

Technote 154278
Should the Resource Reservations Database Be Replicated? Should it Be Clustered?

Problem:

If you are setting up the Resource Reservations database for Calendaring & Scheduling with Notes 4.5x/4.6x or 5.x Client and Domino 4.5x/4.6x or 5.x Server on several different servers, should the databases be replicas of each other?

Solution:

The Resource Reservations databases should not be replicas of each other; otherwise, you run the risk of free time not being reported accurately for the following reasons:

1.        Creating reservations directly in the replica copy of the Resource Reservations database is limited to the replication schedule between servers (server connection record.)

For example, Server A contains the original Resource Reservations database.  Server B contains a replica copy the Resource Reservations database from Server A.  The busytime database of Server A contains the free time information of the Resource Reservations database.  The busytime database of Server B does not have free time information of the same database.  If users book the resources directly from the replica copy of the Resource Reservations database on Server B, that appointment has to replicate to the original database on Server A for the busytime database to be updated.  Therefore, the free time is subject to a time lag based on the replication schedule.

2.        Creating reservations from the user's mail file, as opposed to creating them directly in the Resource Reservations database, only uses the original Resource Reservations database specified in the Public Address Book (refer to the Mail-in Database view to check the server and reservation database name being used.)  It does not use any existing replicas.

3.        Typical replication issues such as replication and save conflicts can occur.


A Note About Clustering:
In Domino 4.5x/4.6x the Free Time system is not clustered.  In Domino 5.x, the Free Time system is clustered.  However, Lotus strongly recommends that system administrators do not cluster the Resource Reservations database.

The Resource Reservations database should NEVER be clustered, even in a failover scenario.  The reason is because Clubusy.nsf gets updated only on the server that hosts the Resource Reservations database (that is, the server that the Resource Reservations database was created on).  If that server goes down, and users are now making reservations on the failover server, double books are highly likely to occur because the Sched task on the cluster mate is not designed to update the Clubusy.nsf on a clustered server.  This issue has been reported to Lotus Quality Engineering but was determined not to be a bug.  The Sched task updates the clubusy only on the server that hosts the Resource Reservations database.

When using a mixed environment of R4 and R5 Domino Servers, the Calendaring & Scheduling functionality will take on the characteristics of the R4 environment; therefore, you cannot cluster the Free Time system.  Clustering the Free Time system is a Domino R5-only feature.