Skip to main content
Announcements
Global Transformation Awards! Applications are now open. Submit Entry
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Reload frequency and timing of QVD Generators

Hi all, I have a number of QlikView documents (Generators) which are used to generate several QVD files. The main data sources for these QVDs are two DB2 Databases that are continuously used by a large number of company employees. These QVD files are then used as data sources for several QVW application that we use.

These QVD generators are scheduled to run during the night, so that the data in the Qlikview dashboards will be refreshed every 24 hours. The reload to run these QVD generators takes about 30 minutes to complete.

Recently I am having complaints from some of the dashboard users that the data is not being refreshed frequently enough for their needs. Thus, I was considering scheduling the QVD generators to reload more frequently, for instance, every 4 hours (i.e. also during working hours).

However I have the following questions:

1. Does reloading during working hours present any risks from the Qlikview side or the source database (DB2 in my case) side, such as data corruption, inconsistency or conflicts?

2. How often can such QVD generators be reloaded, is there any limits?

3. What is the best practice to offer users with dashboards that are updated more often than 24 hours?


Can someone please advice on best practice regarding such requirement?

Labels (2)
1 Solution

Accepted Solutions
Gysbert_Wassenaar

1. Does reloading during working hours present any risks from the Qlikview side or the source database (DB2 in my case) side, such as data corruption, inconsistency or conflicts?

A reload means retrieving data from the source DB. That may have a negative impact on the performance of the source database and the machine executing the reload. If a qvd is locked by a process it cannot be written to and a reload that needs a locked qvd will fail. Make sure that the task that reloads a qvd finishes before another reload uses that qvd as source. Data corruption is extremely unlikely unless you have flaky hardware. A reload can't cause corruption in the source database unless you're doing very silly things that involve writing to the database.


2. How often can such QVD generators be reloaded, is there any limits?

If a reload takes 30 minutes then you can reload 48 times a day if the source database is online, the machine that executes the reload is online and there's enough cpu, ram and harddisk capacity available to successfully reload.


3. What is the best practice to offer users with dashboards that are updated more often than 24 hours?

Reload more often.


talk is cheap, supply exceeds demand

View solution in original post

2 Replies
Gysbert_Wassenaar

1. Does reloading during working hours present any risks from the Qlikview side or the source database (DB2 in my case) side, such as data corruption, inconsistency or conflicts?

A reload means retrieving data from the source DB. That may have a negative impact on the performance of the source database and the machine executing the reload. If a qvd is locked by a process it cannot be written to and a reload that needs a locked qvd will fail. Make sure that the task that reloads a qvd finishes before another reload uses that qvd as source. Data corruption is extremely unlikely unless you have flaky hardware. A reload can't cause corruption in the source database unless you're doing very silly things that involve writing to the database.


2. How often can such QVD generators be reloaded, is there any limits?

If a reload takes 30 minutes then you can reload 48 times a day if the source database is online, the machine that executes the reload is online and there's enough cpu, ram and harddisk capacity available to successfully reload.


3. What is the best practice to offer users with dashboards that are updated more often than 24 hours?

Reload more often.


talk is cheap, supply exceeds demand
Not applicable
Author

Thanks for you informative reply Gysbert! Just wanted to make sure and feel confident about the points mentioned above

Thanks again!