Erweiterte Eigenschaften aus Schablone übernehmen

[ofshore]

Hallo,

gibt es die Möglichkeit, aus einer Schablone, wenn ich daraus eine neue DB erstellen möchte,
die erweiterteten Eigenschaften mit zugeben?
Konkret möchte ich, das für alle Datenbanken die auf eine best. Schablone bestehen, die Transactionprotokollierung deaktivert ist

Gruß
           Ofshore

[Tode]

Transaktionsprotokollierung darf rein logisch nicht auf der Schablone basieren, weil es Dich sonst zu sehr einschränkt.

Ein sehr weit hergeholtes Beispiel (aber egal):

Stellen wir uns vor, Du hast z.B. zwei Infothek- Datenbanken:
In einer werden pro Tag ca. 20 Dokumente geändert, dafür sind die Daten immens wichtig.
Deshalb willst Du die Transaktionsprotokollierung einschalten.

In der zweiten werden pro Tag 100.000 Dokumente geändert,
z.B. durch einen Agenten, der Daten ständig auf dem korrekten Stand halten muss
(ja, ich weiss: das wäre übelstes Design, aber ich will ja nur das Prinzip verdeutlichen).
Wenn Du bei dieser DB die TP aktivierst, laufen möglicherweise Deine logs voll, Du möchtest sie hier ausschalten.

Wenn diese Eigenschaft auf der Schablone basieren würde, hättest Du ein echtes Problem...

Andererseits könnte man über den Datenbank- Katalog leicht alle Datenbanken finden, die auf einer Schablone basieren, und die entsprechende Eigenschaft per Script setzen:

Set dc = catalogDB.Search( "DbInheritTemplateName = DeinSchablonenname" )

dc durchlaufen, datenbank zum entsprechenden Doc öffnen, und über
db.SetOptions(...) die Transaktions-Protokollierung setzen / entfernen

HTH
Tode

[ofshore]

Hallo Tode,

vom Prinzip her weiß ich das ;-), aber z.B. haben wir das Problem,
das Datenbanken wie die Clubusy.nsf bei uns regelmäßig gelöscht werden müssen,
da wir sonst massive Probleme mit der freien Zeit suche haben, daher habe ich halt nach einer Lösung gesucht, für solche nur temporär bestehende DB die Protokollierung standardmäßig zu deaktivieren.
                       
Gruß
            Ofshore

[Tode]

hm... entschuldige wenn ich böse werde: das ist ja mal wieder ne tolle rangehensweise an ein Problem:

Die clubusy ist regelmässig defekt, und um mir nach dem Neuanlegen einen Klick zu sparen, suche ich in einem Forum nach Workarounds.

Aber warum die Datei ständig defekt ist, das untersuche ich nicht, sondern nehme es einfach als gegeben hin...

ja, so kann man Probleme auch umschiffen, indem man die Auswirkungen immer wieder beseitigt, anstatt die Ursache zu bekämpfen...

[ofshore]

Hallo Tode,

das ist schon o.k. und ich nehme das nicht persönlich ;-),
aber der Call bei IBM war aufgemacht unter Domino R5, dort wurde uns
das obige Vorgehen vorgeschlagen, und wir wurden auf Version 6.5 vertröstet.
Nach 4 Wochen unter R6 hatten wir dort das gleiche Problem, das die Frei Zeit suche
nur unzureichend funktioniert, da in der clubusy.nsf z.T. falsche oder keine Einträge
 für bestimmte Resourcen hinterlegt waren. Die Einträge sind aber jeweils beim
Neuaufbau in Ordung.
Daher kam meine obige Anfrage.

Gruß
         Ofshore
             

[ofshore]

Hallo,

ich kommentiere mich dann nochmal selber,
mein Problem hat sich erstmal erledigt. Es gibt einen  Notes.ini Parameter,
der das erfüllt.

schedule_disabletxnlogging=1

Gruß
         Ofshore

[Glombi]

Hier der entsprechende Artikel aus der KBASE:

Scheduler Task using a lot of CPU
Product:
Lotus Domino  >  Lotus Domino Server  >  Versions 6.5, 6.0
Platform(s):
Platform Independent
Doc Number:
1213708

Published   02.09.2005
Technote

Problem

You notice that the Scheduler task is using a lot of CPU.



Solution
The Scheduler task is responsible for maintaining the Freetime data. When new calendar entries are created, they need to be added to the freetime database (Busytime.NSF or Clubusy.NSF). This merging of new entries into existing entries for a user has been seen to cause a spike in the amount of CPU used by the Scheduler task. 

The following steps are recommended to reduce the amount of CPU used by the Scheduler task:                                             

The Notes.INI parameter "SCHEDULE_NO_CALCSTATS=1" disables the hourly statistics collection by the Scheduler task. This also applies to Busytime.NSF if clustering is not configured.                                                             

If using Transaction Logging, turn it off on the Busytime.NSF or Clubusy.NSF.  In 6.0.3/6.5.2, a Notes.INI parameter was introduced to accomplish this:


"schedule_disabletxnlogging=1"


For releases prior to 6.0.3/6.5.2, the customer can manually update the database properties to disable Transaction Logging on Busytime.NSF.

We have seen instances where users have repeating calendar entries very far into the future.  When these users add additional repeating entries to their calendar, Scheduler shows a CPU spike while merging these new entries. To see if this is part of the problem, have the customer issue the following command:


"tell sched stats"
                               

This command provides the number of calendar entries per user on the server.

For users having high number of calendar entries, use the following command:


"tell sched show username" (full Notes canonical name)
   

This will provide detailed output of this user´s calendar entries. Having the user reduce the number of long-term repeating calendar entries should provide some relief.


Andreas