Beiträge von ha20

Wir sprechen hier von 5 Mailverzeichnissen:
1.) 1312,2GB in 1925 Dateien
2.) 2,9GB in 11 Dateien
3.) 27,7 GB in 55 Dateien
4.) 10,7 GB in 11 Dateien
5.) 428,6GB in 459 Dateien (andere Partition)

Aktuell ist die Fragmentierung wieder bei "nur" 20%, da der letze Defrag erst ein drei Wochen her ist. Nach einem Quartal sind wir aber schon bei guten 80-90% - und da wird das System so zäh, dass der Compact länger 24h braucht.

Aktuell fahren wir den compact mit "-c", auf dem Cluster ist TransactionalLogging aktiviert. Wir haben mal versucht nur mit DB-internem Compact durchzuhalten, haben dann aber nach zwei Wochen wir auf "mit Reduzierung der Datenbankgröße" wechseln müssen, da wir vom Wachstum nach zwei weiteren Wochen an die Kapazitätsgrenzen gestoßen wären.

Meine Kollegen haben sich halt damit schon längst abgefunden, aber ich bin halt schon irgendwo der Meinung, dass man das mit sicherheit eleganter lösen könnte. Ich komm nur nicht drauf :-/

Hm... Befürchtete schon, dass es auf sowas hinausläuft.

Zu 1.)
Welche sinnvollen Alternativen hätte man denn da? Kenne mich in dem Bereich leider zu wenig aus.

Zu 2.)
naja, wir versuchen es ja schon, aber wenn das FS zu über 80% fragmentiert ist bleibt halt nur noch ein drittel der Platten-Performance effektiv übrig und da wird dann schon etliches recht zäh.

Ist schon klar, dass die Fragmentierung generell erst mal ein Windows-Problem ist. Nur, wenn solche Datenmengen in massig kleinen Files rumliegen, wo sich immer wieder die tatsächliche File-Größe ändert, fragmentiert sowas halt wesentlich schneller wie z.B. ein SQL Server wo ich ne DB mit einer Initial-Größe anlege und sich diese im Filesystem im Prinzip erst einmal nicht mehr ändert. Da hängen dann alle Datenblöcke brav hintereinander auf der Platte. Nur wenn die Fiels unter der Woche mal 50GB wachsen und am Wochenende der compact wieder 49GB aufräumt, verteilen sich die Datenblöcke zu einer NSF halt schon ganz schön über die Platte :-/
Und nein, ich meine nicht die Whitespace-Fragmentation in den NSFs.
Das ganze liegt übrigens in einem SAN. Wie ganz genau könnten meine Server-Hardware-Kollegen besser erklären aber im Prinzip sind die Partitionen über einen Fiberchannel-Adapter dann ins Blechle eingebunden und für Windows sind es dann ganz normale Partitionen - natürlich mit NTFS formatiert.

Was wäre hier den generell besser bzw. BestPractice? Firmenpolitisch sind wir leider an Windows gebunden? Würd ja das ganze lieber mal unter einem Linux ausprobieren, aber man kann halt nur mit dem arbeiten, was man kriegt.

Hallo Forum,

langsam stinkt mir Domino. Tja, hätte nicht gedacht, dass ich das mal sage. Die meisten Softwaretechniken sind mittlerweilen sowas von überholt. Man könnte meinen IBM lebt noch im letzten Jahrtausend. Aber gut. Was führt mich heute hierher? Fragmentierung.

Gerade unsere zentrales Mail-Cluster und unser Anwendungs-DB/Replikations-Cluster fragmentieren tierischst! Aber ist auch kein Wunder, etwa 2200 User die täglich fleißig darauf Mails bekommen und wieder löschen und am Wochenende ein compact der alles wieder aufräumt. Im Moment läuft das so, dass die Server halt immer ein gutes Quartal für sich Zeit haben um wieder richtig langsam zu werden und dann ziehen wir drei Admins hier Streichhölzchen, wer am Wochenende manuell den Windows-Defrag laufen lässt - dauert bei unserer 2TB-Partition (davon übrigens 1,4TB belegt) zur Zeit nette 14 Stunden in denen natürlich keine Domino laufen darf. Schon alleine dadurch sind wir eigentlich schon knapp über unseren SLA...

Und genau hier kommt ihr ins Spiel *g*
Wie krieg ich den Server dazu, dass er nicht mehr fragmentiert oder zumindest weniger fragmentiert? Am idealsten wäre es ja eigentlich wenn ich analog zu Exchange 2-10 echte Datenbanken darunter hängen könnte und darin alle User-DBs liegen. Oder wenn ich den User-DBs sozusagen eine Initialgröße geben könnte. Wobei wir dann wieder aktuell das Problem haben, dass wir ohne Quota fahren, da wir erst vor kurzem unser Archiv-System wieder raus geschmissen haben, welches einfach nicht funktioniert hat - vor allem im Zusammenhang mit verschlüsselten Mails. Aber letzteres lasst mal mein Problem sein. Wenn's nur mit Quota geht, geht's halt nur mit Quota - dann können wir das auch wieder durchdrücken

So, war jetzt viel Text. Hoffe jemand weiß Rat. Vielen Dank schon mal so weit für's lesen.

ich würde mir irgendwie an der AS/400 ein "Script" anlegen, welches mir die Mails verschickt. Oder direkt dort ein Programm schreiben welches über den AS/400-MTA die Mails verschickt. In dem AS/400-MTA dann einfach den Domino als Smart-Relay-Host eintragen, am Domino selbstverständlich SMTP inbound aktivieren, den SMTP listener aktivieren und mit "load smtp" denn listener auch starten (bei Bedarf in der .ini mit nachtragen) und gut ist. Ist imho die sauberste Lösung. Ansonsten halt wie schon vorgeschlagen über einen Agenten oder whatever das Zeug einlesen und verarbeiten.

VM einrichten und dann einfach Domino in das selbe Verzeichnis wie auf der phys. Kiste installieren. Auf den selben Stand der Fixpacks achten. Danach einfach das komplette DATA-Verzeichnis auf die VM und aus dem prog-Verzeichnis die notes.ini mit übernehmen.
Dran denken, dass die Bezeichnung des Service unter Windows von den Installationspfaden abhängt. Installierst du beim Setup z.B. Notes-Data unter "D:\NotesData\" so heißt der Service "Lotus Domino Server (NotesData)" - wenn du ihn aber unter "D:\notesdata\" installiert ist beim Service der Teil in der Klammer auch klein. Das hinterher zu ändern ist ein ziemlich fießer Akt. Wichtig ist das ganze, wenn du den Service über Skript ansprechen willst - genau an dieser Stelle achtet Windows plötzlicherweise nämlich wieder auf Groß-Klein-Schreibung...

:wuet:

wie peinlich... es geht. Was ich geändert habe? Nichts!
Vermutlich wurden gestern durch meine ständige testerei irgendwie diverse Dokumente nicht oder welche zu viel gezogenund ich war nie auf nem vernünftigen Stand... Wie dem auch sei - jetzt funktionierts.

Vielen Dank für die Hilfeversuche!

eigentlich nicht, da wir noch drei andere Foreign SMTP Domains verwenden. Gut - die werden nicht von extern angenommen und sind daher bis jetzt auch noch nie über GATEWAY rein gekommen... Außerdem sind's keine Subdomains von "firma.com". Könnte es vielleicht daran liegen? Also, dass mein schönes Domino der Meinung wäre, wenn's schon für firma.com zuständig ist, ist's auch für alle Subdomains zuständig...

Moment, die Domain "test.firma.com" ist selbstverständlich nicht im Global Domain Dokument! Dort ist nur die "firma.com" - und die muss da eigentlich ja auch sein, da die Domino-Domäne in der GATEWAY ist ja auch tatsächlich für die Internet-Domäne "firma.com" zuständig ist.

Global Domain Dokument

Ich habe ein Foreign SMTP Domain Dokument mit folgenden Informationen:

Domain Type: Foreign SMTP DomainInternet Domain: test.firma.comDomain name: TESTDOMAIN

Und dann habe ich ein verbindungsdokument von HAUPTSERVER:

Connection type: SMTP
Source server: HAUPTSERVER
Connect via: Direct connection
Destination server: TESTDOMAIN
Destination domain: TESTDOMAIN
SMTP MTA relay host: "Anderer Server"
Routing task: Mail Routing

mehr habe ich nicht. Kann es sein, dass GATEWAY sich für die Domain zuständig fühlt, da "test.firma.com" eine Subdomain von "firma.com" ist?

Wenn ich von intern (d.h. ich auf dem HAUPTSERVER arbeite) eine Mail schicke geht das ganze einwandfrei - die Mail kommt auf "Anderer Server" an. Nicht gerouted werden Mails die aus dem Internet kommen - die landen auf dem GATEWAY und selbiger kann mit der Mail dann nichts anfangen.

Wenn ich dem GATEWAY nun auch noch ein SMTP-Verbindungsdokument gebe versucht das die Mail nun direkt an "Anderer Server" zuzustellen - logischerweise. Geht aber nicht - ich hätte noch erwähnen müssen, dass diese gestrichelte Linie hier eine Firewall darstellt.

Sorry, wenn ich mich zu missverständlich ausgedrückt habe :-/

Bedingung ist halt, dass die Mails die von extern über GATEWAY kommen per Notes-Routing (kein SMTP) auf den HAUPTSERVER kommen - dieser leitet dann die Mails ja jetzt schon richtig weiter.

Hallihallo liebe Domino-Freunde... Ich habe leider mal wieer ein Problem mit Mail-Routing

Folgendes ist gegeben (vgl. Bildchen):

HAUPTSERVER und GATEWAY sind in einer Domino-Domäne
GATEWAY nimmt Mails aus dem Internet an
Domino-Internet-Domäne sei "firma.com"
"Anderer Server" wartet auf SMTP-Mails unter der Domäne "test.firma.com"

Nun habe ich ein "Foreign SMTP Domain"-Dokument erstellt und ein Verbindungsdokument von "HAUPTSERVER" nach "Anderer Server" und was soll ich sagen - es geht

Das, was mir seit paar Tagen nun Kopfzerbrechen bereitet ist das Mailrouting von extern über GATEWAY, über HAUPTSERVER nach "Anderer Server". Hab schon alle möglichen Verbindungs-Einstellungen durchprobiert aber entweder sagt mir GATEWAY "No route found to test.firma.com" oder "User (adresse@domino-domäne) not listed in Directory". Ich raff's einfach nicht. Ich will doch eignetlich nur ein Dokument, dass dem GATEWAY sagt, alles was rein kommt an "test.firma.com" schickst du per Notes-Mailrouting zum HAUPTSERVER, auf dass dieser es per SMTP an "Anderer Server" schickt.

Kann mir bitte jemand auf die Sprünge helfen oder zumindest nen Stupps in die richtige Richtung geben?

Genau das ist ja unser Problem.
Ich hab auch schon die Kachel gelöscht und anschließend sowohl die Desktop, die Bookmark und die Cache weg genommen und Notes gestartet, aber es war immernoch unterschiedlich...
Seeehr komisch das ganze. Sonst merkt er sich das ja nirgends, oder?
Naja, mal sehen ob unser Workaround funktioniert.
Soweit schon mal vielen Dank für die Hilfe.

Achso... Dann wäre es ja ein Server-Problem.
Was dann allerdings komisch ist, dass das sowohl vom Client als auch von der User-ID abhängt.
Schau ich mir die DB-Properties über die Kachel am Client A mit User X an, dann heißt "app\db.nsf", wenn ich am selben Client aber mit User Y komme, heißts "app\db.nsf"

Wir haben gerade mal die Funktion, die den Aufruf generiert mit dem LCase modifiziert und warten gerade aus Antwort aus Amerika.

-.-
Oh man, da hätte man mal drauf kommen müssen. Ich werd gleich mal unserem Entwickler bescheid sagen, ob er da den Aufruf mit einem LowerCase modifizieren kann...

Ich verstehe jetzt aber nicht ganz, was du mit Client-/Server-Problem meinst. Steh da gerade auf dem Schlauch.

es spielt insofern eine Rolle, da aus der DB diverse Web-Aufrufe generiert werden, wo der DB-Pfad mit eingerechnet wird. Wenn dann der Ordner groß geschrieben aufgerufen wird, denkt der Tomcat dahinter, dass damit die Java-Anwendung gemeint ist, wenn der Ordner klein geschrieben wird, ist damit die Web-Ansicht der DB direkt unter Domino gemeint. Ich weiß, nicht gerade das Optimum bezüglich Application-Design, aber es gibt noch ein paar Abhängigkeiten wieso das so sein muss. Geht leider nicht anders. :cry:

Sorry, aber ich muss das nochmal pushen. Sind wir mal wieder die einzigste Firma weltweit die mit einer blöden Notes-Eigenheit Probleme hat? :lol:

Sorry, bringt leider nichts. Hatte auch schon mal die ganze Bookmarks.nsf weg genommen.

Hallo,

habe gerade ein Rießen-Problem (im wahrsten Sinne des Wortes).
Mir ist durchaus klar, dass das in der Regel kein Problem darstellt. Wir haben da aber einen Workflow mit integriert, bei dem das essenziell wichtig ist. Hier aber mal die Beschreibung (etwas umfangreicher, aber dafür klarer):

Wir haben da einen Server A, auf dem eine DB liegt. Der Pfad schaut beispielsweise so aus:

Server_A!!pfad\ordner\db.nsf

Nun haben ein paar Helden beim Anlegen einer Replik auf dem Server B folgendes erzeugt:

Server_B!!pfad\ORDNER\db.nsf

Nun habe ich das am Server geändert. Habe sogar die DB gelöscht, sämtliche Caching-Dateien, die ich am Server gefunden habe gelöscht und komplett neu hin repliziert. Wenn ich bei manchen Usern, die auf dem Server_B arbeiten, mir die Eigenschaften der DB anschau (über deren Kacheloberfläche), so ist bei manchen Usern das manchmal in Großbuchstaben bei manchen in Kleinbuchstaben.

Dazu hatte ich folgenden Workaround:
1.) Kachel löschen
2.) Notes beenden
3.) Cache.ndk löschen
4.) mit der ID eines Users anmelden, bei dem der DB-Pfad klein geschrieben ist
5.) Kachel neu anlegen
6.) mit dem ursprünglichen User anmelden

Und plötzlich ist auch bei dem ursprunglichen User der DB-Pfad komplett klein geschrieben.
Das ging jetzt etwa ein viertel Jahr gut, doch gestern ist das Problem wieder aufgetreten (und aktuell noch anhaltend). Der Workaround funktioniert nicht mehr. :cry:

Ich habe echt keine Ahnung mehr, was ichd a noch machen könnte.
Hoffe jemand von euch hätte da eine Idee dazu!

Gruß,
ha