Hallo,
ich bin heute bei https://www.ibm.com/support/knowledgecenter/en/SSKTMJ_9.0.1/admin/tune_compactoptions_r.html (https://www.ibm.com/support/knowledgecenter/en/SSKTMJ_9.0.1/admin/tune_compactoptions_r.html) über die compact Commandline Option "-c -nifnsf on" gestolpert.
Die scheint ja noch sehr frisch zu sein und implementiert wohl das Feature, die Views getrennt von der eigentlichen NSF Datenbank speichern zu können.
Dazu muss man in der Notes.ini noch folgende Parameter setzen (und ggf. den Server neu starten):
NIFNSFEnable=1
NIFBasePath=E:\NIF
Wichtig auch: ODS sollte möglichst aktuell sein (Create_R9_Databases=1, compact -c -ODS)
Anschließend dann die gewünschten Datenbanken mit compact -c -nifnsf on pfad\zur\db.nsf compacten.
Bei mir (Windows 2012R2, Domino 9.0.1 FP7 IF2, 64 Bit, aktuelle JVM) hat das auf einem System zum Crash von Domino mit NSD geführt (Fatal Thread ncompact.exe) - ich schiebe es mal darauf, dass das System 4 Domino Partitionen hat und Traveler auch noch drauf installiert ist.
Auf dem 2. System (Windows und Domino auf dem gleichen Stand wie auf dem ersten System, aber nur eine Domino Partition, dafür mit IMSMO 2.0.1.0) kann ich zwar compacten, aber außer ein paar Warnungen kommt nichts dabei rum:
load compact -c -nifnsf on mail\xyz
[02F8:0004-09E0] 19.01.2017 15:47:12 Informational, NIFNSF has been enabled for database mail\xyz.
[02F8:0004-09E0] 19.01.2017 15:47:12 Informational, database design compression is enabled in database mail\xyz.
[02F8:0004-09E0] 19.01.2017 15:47:12 Informational, LZ1 is enabled in database mail\xyz.
[02F8:0004-09E0] 19.01.2017 15:47:12 Compacting mail\xyz(X Y), -c -nifnsf on mail\xyz
[02F8:0004-09E0] dest should be linked, but not accessed C:\IBM\Domino\Data\mail\xyz.tmp
[02F8:0004-09E0] dest should be linked, but not accessed C:\IBM\Domino\Data\mail\xyz.tmp
[02F8:0004-09E0] dest should be linked, but not accessed C:\IBM\Domino\Data\mail\xyz.tmp
[02F8:0004-09E0] dest should be linked, but not accessed C:\IBM\Domino\Data\mail\xyz.tmp
[02F8:0004-09E0] dest should be linked, but not accessed C:\IBM\Domino\Data\mail\xyz.tmp
[02F8:0004-09E0] dest should be linked, but not accessed C:\IBM\Domino\Data\mail\xyz.tmp
[02F8:0004-09E0] dest should be linked, but not accessed C:\IBM\Domino\Data\mail\xyz.tmp
[02F8:0004-09E0] dest should be linked, but not accessed C:\IBM\Domino\Data\mail\xyz.tmp
[02F8:0004-09E0] dest should be linked, but not accessed C:\IBM\Domino\Data\mail\xyz.tmp
[02F8:0004-09E0] dest should be linked, but not accessed C:\IBM\Domino\Data\mail\xyz.tmp
[02F8:0004-09E0] 19.01.2017 15:47:18 Compacted mail\xyz, 0K bytes recovered (0%), -c -nifnsf on mail\xyz
Auf einem dritten System (Win2003R2, 9.0.1 FP7 32 Bit, Traveler 9.0.1.15) ist der Server ebenfalls beim compact gecrasht.
Folgende Regelmäßigkeit ist mir aber aufgefallen:
Compact erzeugt immer erst eine dbname.tmp Datei im gleichen Verzeichnis wie die dbname.nsf liegt und crasht dann den Domino-Server.
Wenn der Server dann wieder da ist und man das compact auf die gleiche Datenbank ausführt, findet er anscheinend schon die .tmp Datei und kann damit weiterarbeiten und gliedert damit die Views aus.
Führt man das compact dann auf die nächste Datenbank aus, fängt das Spiel wieder von vorne an.
Hier z.B. nach dem Crash - die "activity.tmp" existierte dann schon -> activity.nsf wurde jetzt korrekt verarbeitet, aber bei der admin4.nsf ist er wieder gecrasht.
> load compact -c -nifnsf on
19.01.2017 16:16:45 Informational, NIFNSF is already enabled in database activity.nsf.
19.01.2017 16:16:45 Informational, database design compression is enabled in database activity.nsf.
19.01.2017 16:16:45 Informational, document data compression is enabled in database activity.nsf.
19.01.2017 16:16:45 Informational, LZ1 is enabled in database activity.nsf.
19.01.2017 16:16:45 Compacting activity.nsf (Activity Trends (Sonne)), -c -nifnsf on
19.01.2017 16:16:48 Recovery Manager: Assigning new DBIID for D:\Lotus\Domino\data\activity.nsf (need new backup for m
edia recovery).
Clearing DBIID EE8B5DED for DB D:\Lotus\Domino\data\activity.ORIG
19.01.2017 16:16:49 Compacted activity.nsf, 1024K bytes recovered (8%), -c -nifnsf on
19.01.2017 16:16:49 Informational, NIFNSF has been enabled for database admin4.nsf.
19.01.2017 16:16:50 Informational, database design compression is enabled in database admin4.nsf.
19.01.2017 16:16:50 Informational, document data compression is enabled in database admin4.nsf.
19.01.2017 16:16:50 Informational, LZ1 is enabled in database admin4.nsf.
19.01.2017 16:16:50 Compacting admin4.nsf (Admin-Anforderungen (V5.0)), -c -nifnsf on
dest should be linked, but not accessed D:\Lotus\Domino\data\admin4.tmp
dest should be linked, but not accessed D:\Lotus\Domino\data\admin4.tmp
dest should be linked, but not accessed D:\Lotus\Domino\data\admin4.tmp
dest should be linked, but not accessed D:\Lotus\Domino\data\admin4.tmp
dest should be linked, but not accessed D:\Lotus\Domino\data\admin4.tmp
dest should be linked, but not accessed D:\Lotus\Domino\data\admin4.tmp
dest should be linked, but not accessed D:\Lotus\Domino\data\admin4.tmp
dest should be linked, but not accessed D:\Lotus\Domino\data\admin4.tmp
Thread=[1178:0004-0AC0]
Stack base=0x0CB4009C, Stack size = 19876 bytes
PANIC: LookupHandle: null handle
Hat jemand ähnliche Erfahrungen gemacht?
Viele Grüße,
Patrick
Ich hatte ja bereits von den vielen ghost-ndx files berichtet, die ich auf meiner Entwicklungsumgebung beobachten konnte. Das Phänomen kann ich hier auch beliebig reproduzieren. PMR habe ich noch nicht erstellt.
Mein Domino it 901FP9
Gestern habe ich versucht, eine Ansicht in dieser Datenbank zu öffnen. Die Datenbank enthält nicht viele Dokumente und in dieser Ansicht ist lt. Ansichtenformel auch kein Dokument zu finden.
Der Client hat über 5 Minuten versicht, die Ansicht zu öffnen; danach hat er den Hinweis gegeben, ich solle die Datenbank schließen und wieder neu öffnen. Danach habe ich micht im Kreis bewegt. Die Ansicht ging einfach nicht auf. Gleiches verhalten auch mit einer anderen Ansicht. Lediglich ein "03:CC" Fehler, der darauf hindeutete, daß hier etwas im Argen liegt.
Da ich den Fehler im NIFNSF vermute, habe ich heute zunächst versucht, mittels updall und fixup die Datenbank zu bereinigen.
An der Console konnte ich folgende Meldungen sehen.
[088C:0002-1FBC] 12/12/2017 07:21:00 AM Error updating view '#1362' in C:\Program Files\IBM\Domino\data\products\traveler\traveler-rules.nsf: 03:CC
[088C:0002-1FBC] 12/12/2017 07:21:00 AM Error updating view '#1322' in C:\Program Files\IBM\Domino\data\products\traveler\traveler-rules.nsf: 03:CC
Mittels -nifnsf OFF wollte ich dann das Flag wieder zurückzusetzen und den Viewindex wieder in die Datenbank zu befördern.. Der compact -c -nifnsf off veranscheidete sich mit einem Server crash.
Zur Sicherheit habe ich die komplette Maschine neu gestartet und den Befehl erneut abgesetzt. Jetzt lief der compact durch.
Danach konnte ich die Datenbank öffnen und auch die fehlerhaften Ansichten ließen sich ohne Probleme und Meldungen öffnen.
Aus meiner Sicht sollte man mit diesem feature noch vorsichtig sein. So ganz rund scheint es nicht zu laufen. Möglicherweise ist es aber auch nur wieder auf meiner Maschine, und der rest der Welt hat diese Probleme nicht ( icl. IBM ) Daher auch kein PMR von meiner Seite.