QlikView Master Summit - Drop Fields Diskussion

Rob Wunderlich hat sich in seinem aktuellen Blogpost einer unserer Diskussionen vom MasterSummit for QlikView in Barcelona angenommen.

Falls Sie Rob's Document Analyzer benutzen, um Felder am Ende des Skripts zu droppen, hier nochmals meine Beobachtung.

Attached a small example that shows the issue:

- 01_testDatabase.qvw produces a .qvw with about 350MB on disk
- 02_testDatabaseBinaryDrop400fields.qvw does a BINARY Load and then drops 400 fields --> it's about 18 MB on disk (136 MB in Memory including QV.exe)

So one would expect that 18 MB is the final size of the .qvw!
However when I do an additional RESIDENT-Load after dropping fields, the .qvw gets much smaller:

- 03_testDatabaseBinaryDrop400fields_Resident does a BINARY Load, then drops 400 fields and THEN makes a RESIDENT LOAD on the table, dropping the original table

--> suddenly the .qvvw is only 1.2 MB on disk (26 MB in Memory including qv.exe)!
Download Example

Rob hat dies nun weiter analysiert und bemerkt, dass die  Record pointers nicht freigegeben werden.  Erst mit einem weiteren RESIDENT-Load wird tatsächlich der komplette DISK/MEMORY-Space freigegeben.

  • Im Moment ist es besser die nicht benutzen Felder im Skript auszukommentieren, anstatt Sie erst am Ende des Skripts zu droppen!
  • Falls dies nicht möglich ist, sollte man nach den Drop Fields Statement die (Fakten)-Tabelle nochmals resident laden.


3 Response to "QlikView Master Summit - Drop Fields Diskussion"

  1. Andrey says:

    Danke für die Example-Files, Roland!
    Ein sehr obskurer Bug in QlikView, in der Tat.

    Ich hatte nun ein wenig weiter recherchiert und fand dabei heraus:

    - wenn man einen QlikView-Publisher verwendet, werden die Speicherreste von Record Pointers durch das "Distribute" Schritt ohne "Reduce" auch nicht freigegeben! D.h. die Applikationen die auf dem QlikViewServer publiziert werden, verschwenden unter Umständen RAM-Resourcen, die faktisch nicht benutzt werden!

    - falls man eine Publisher-Task mit einem Reduce-Step verwendet, bzw. verwenden kann (z.B. ein Reduce auf das Zähler-Feld=1), werden offenbar die Resourcen dabei freigegeben! In meinem Versuch wurde die publizierte Datei von der Grösse identisch mit der "RESIDENT LOAD" QVW-Datei. Da RESIDENT LOAD auf grossen Tabellen sehr lange Zeit dauert, ist diese Methode mit Reduce durch den Publisher aus meiner Sicht zu präferieren.

    - einen gleichen Effekt wie mit dem Reduce kann man auch durch File > Reduce Date > Keep Possible Values (mit einer leeren Selektion) in dem Desktop-Client erreichen. Dabei werden keine Daten entfernt, aber der unbenutzte Speicherbereich wird freigegeben. Das erfordert jedoch immer einen manuellen Schritt vor dem Speichern (kann man es mit einem Macro und dem Trigger OnPostReload irgendwie machen?)

    Hi Andrey!

    Danke für die weitere Analyse!
    Momentan sind die Optionen also:

    1) Felder auskommentieren statt zu Droppen
    2) drop fields & dummy-reduce in Publisher
    3) drop fields & resident load, falls kein Publisher vorhanden

    Ich habe eine CaseID 168135 beim QT Support, aber leider noch keine Bestätigung. Sobald ich etwas habe, werde ich es posten!

    Sieht aus als wäre dieses Verhalten in QlikView 12.X gelöst; manchmal sind QV12 .qvws aber deutlich größer als sie in QV11 waren. Laut Qlik Support ist das "Working as Designed" durch eine interne Umstellung!

Kommentar veröffentlichen

heldendaten GmbH,2017