Erfahrung mit dem Feature NIFNSF (Views aus der NSF-Datenbank ausgliedern)

[Patrick Schneider]

Hallo,

ich bin heute bei 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):

Code

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:

Code

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.

Code

> 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

Im NIFBasePath ist jetzt eine entsprechende Struktur, in der dann .ndx Dateien liegen.

Hat jemand ähnliche Erfahrungen gemacht?

Viele Grüße,
Patrick

[Tode]

Da ich noch in keiner Release- Note von dem Feature gelesen habe, denke ich, dass da "versehentlich" schon was in die Doku gerutscht ist, was eigentlich erst mit einem der nächsten "FeaturePacks" kommen soll... Ich meine mich zu erinnern, dass das Feature für FP8 vorgesehen ist, finde aber die Folie nicht mehr wo -zumindest grob- drinstand, welches Feature in welchen Featurepack kommt...

[eknori]

NIFNSF kommt mit FP8. Der code ist schon in Domino 901 enthalten, aber noch nicht ganz ausgereift, wie du ja bereits durch den crash gemerk hast.
Im FP8 ( momentan als private Beta ) funktioniert das compact im laufenden Betrieb.
Unter 901 kann man den compact bei heruntergefahrenem Domino machen. Dann werden die View Index Daten ausgelagert. Danach kann der Server wieder gestartet werden.
 Bitte noch nicht produktiv einsetzen!!!

[Ralf_M_Petter]

Sieht ja echt ziemlich cool aus, aber es wirft wirklich kein gutes Licht auf die IBM, dass einfach mal so unfertige Features integriert werden. Soweit ich weiß sollte dieses Feature erst in einem späteren FP kommen wie Thorsten und Ulrich sagen und hat damit absolut nichts in einem Produktionsrelease verloren, vor allem wenn es gleich mal den Server crashed.

P.S. Danke Ulrich für die Erklärung. Wird das am Client auch funktionieren und kann das helfen, dass man eventuell noch etwas mehr Platz bis zum 64 GB Datenbanklimit hat?

[eknori]

@Ralf: habe ich noch nicht ausprobiert. Das Feature braucht aber Transaktionsprotokollierung. Gut, die funktioniert auch auf den Client. Muss ich mal ausprobieren.



Übrigens ist der Wert für NIFNSFEnable in 901 anders, damit man das nicht versehntlich aktiviert. 😬

Da war jetzt die IBM mit der Doku ausnahmsweise zu schnell. Und auserdem, seit wann liest jemand die Doku?

[Patrick Schneider]

Hallo zusammen,

nach dem Update auf Feature Pack 8 lässt sich die Funktion nun auch ohne Abstürze offiziell nutzen.
Hier noch ein Link zur Doku:
https://www.ibm.com/support/knowledgecenter/de/SSKTMJ_9.0.1/admin/admn_moving_views_out_of_databases.html

Viele Grüße,
Patrick

[eknori]

Es gibt win bestätigtes Performanceproblem, wenn bei ausgelagertem Index Funktionen aufgerufen werden, die auf dem Index zugreifen. Konnte es nachstellen.
Daher ist in produktiven Umgebungen zunächst einmal Vorsicht angesagt.

[Buzzy]

Moing zusammen,

was genau hinter dem ominösen Satz

"Bessere Leistung, indem der gleichzeitige Zugriff auf Datenbank und Ansichten ermöglicht wird."

genau steckt weiss auch keiner, oder? In meinen Ohren macht der Satz an sich auch nicht viel Sinn, aber ich will nicht ausschließen, dass
mein Entwicklerhirn dafür zu klein ist 


Greets,
Buzzy

[Tode]

Das bedeutet: Man kann die Ansichts- Indizes auf eigene Platten / Spindeln auslagern, was einen höheren parallelen Zugriff und damit erhöhte Performance ermöglicht.

[eknori]

was einen höheren parallelen Zugriff und damit erhöhte Performance ermöglicht.

soweit die Theorie

Vor FP9 würde ich das Feature nicht produktiv einsetzen

[Buzzy]

soweit die Theorie
Vor FP9 würde ich das Feature nicht produktiv einsetzen

Genau darauf wollte ich hinaus ;-)

Ich fand die Formulierung nur etwas komisch - ich hab nämlich einen Kunden, der hat echt große Ansichten (>300k Doks).
Da hab ich mal auf einem Test-DB die Views ausgelagert (NDX-Größe ~9GB)...bin grad noch am überlegen, wie ich das jetzt am besten teste...

Obwohl es da eher weniger um parallel Zugriffe geht, sondern um sehr viele GetDocByKey etc. die der Client absetzt.

Grüße,
Buzzy

[eknori]

bin grad noch am überlegen, wie ich das jetzt am besten teste...

Da wirst du dir ein paar TestSzenarien in Java oder LS selber zusammen löten müssen.

Einmal mit NIFNSF OFF und einmal mit NIFNSF ON

Dann greifst du per Code mit den unterschiedlichen Möglichkeiten, wie z.B

- ViewNavigator
- NoteCollection
- ViewEntryCollection
- FTSearch

auf die DB zu und misst die Zeiten. Dir sollte dann auffallen, daß  NIFNSF ON langsamer ist.

IBM arbeitet an einem Fix. Möglicherweise gibt es einen HF, das ist aber noch nicht klar.

[Buzzy]

Okidoki, dann wart ich erstmal ab - aber danke schomal für die Info!

Grüße,
Buzzy

[eknori]

Moing zusammen,

was genau hinter dem ominösen Satz

"Bessere Leistung, indem der gleichzeitige Zugriff auf Datenbank und Ansichten ermöglicht wird."

genau steckt weiss auch keiner, oder? In meinen Ohren macht der Satz an sich auch nicht viel Sinn, aber ich will nicht ausschließen, dass
mein Entwicklerhirn dafür zu klein ist 


Greets,
Buzzy

ich denke, das bezieht sich auf

View concurrency enhancements
Dedicated View Refresh: Dedicated background thread alleviates issue of view indexes being update at same time when reading/writing to a view
Inline view updates: views are updated as part of the note updates

Das ist aber erst für FP9 vorgesehen

[Buzzy]

Moing!

Schade - bis dahin läuft die Anwendung vielleicht schon unter XPages/mySQL ;-)

Danke & Gruß,
Buzzy

[Buzzy]

So, kaum ist ein 3/4 Jahr rum ist das FP9 schon ne Weile draußen (und die Anwendung läuft immer noch im Client) - hat jemand zwischenzeitlich wieder mit NIFNSF rumprobiert?

Grüße,
Buzzy

[eknori]

Ich habe es bei mir laufen. Primär auf den Maildatenbanken.
Da habe ich auch keine Probleme beobachten können. Performance? Ich sehe keinen Unterschied. Gemessen habe ich aber noch nicht.

Bei Datenbanken, die viele Änderungen in kurzer zeit haben, habe ich immer noch das problem, das neben dem eigentlichen index immer wieder und mehr "temporäre" Files ( 123456789.ndx ) angelegt werden. Die sollen lt. IBM zwar vom System selbst wieder gelöscht werden; bei einer Db hatte ich aber ca 400 solcher files, ohne das irgendeine Bereinigung stattfand. Daher habe ich nifnsf auf dieser Db wieder deaktiviert.
Hatte noch keine zeit und Muße, mich näher damit zu beschäftigen. PMR ist mir echt zu doof, da ich mich nicht auf endlose Diskussionen mit dem Support einlassen möchte. Die zeit kann ich besser nutzen.

[JayDee]

Ich kann diese Ausführungen voll bestätigen. Funktioniert, spart Platz, Performancegewinn aber bislang nicht spürbar. Die erwähnten Zombie-Dateien kenn ich auch, ist aber bei uns relativ selten vorgekommen bisher.

[michael-r]

Moin,

Diese Funktion ist für große Datenbanken hilfreich und bietet die folgenden Vorteile:
•Kleinere Datenbankdatei, um das Erreichen der Begrenzung von 64 GB zu vermeiden.

Das heisst aber nur bei vielen Dokumenten in den Views bringt mir dieses Feature was.
Bei Dokumenten mit vielen kleinen und großen Dateien, dabei würde das Feature nichts bringen.

War korrekt oder?

MFG Michael

[eknori]

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.

Code

[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.