2 Replies Latest reply: Jul 15, 2014 8:47 PM by Adam Weisser RSS

    Store QVD timeout

    Adam Weisser



      We're experiencing a problem here where it appears that the call to the STORE <table> INTO <file.qvd> (qvd) is taking hours to perform, causing the reload job to timeout.


      Here is an extract from the document log:


      13/07/2014 7:45:04 PM: 0098    Tango_SPV:

      13/07/2014 7:45:04 PM: 0099     LOAD

      13/07/2014 7:45:04 PM: 0100     'Tango' AS [Data Source],

      13/07/2014 7:45:04 PM: 0101     monthend(makedate(2014, 6, 1)) AS [Collections Month],




      13/07/2014 7:45:04 PM: 0172    SQL EXECUTE dbo.cspQlikViewSPVExtract '30 Jun 2014'

      13/07/2014 9:09:01 PM:         70 fields found: Data Source, Collections Month, ..., 2,615 lines fetched

      14/07/2014 1:15:35 AM: 0173    STORE Tango_SPV INTO [QVDs\TangoCurrent\Tango 2014 06.qvd] (qvd)

      14/07/2014 1:15:35 AM: 0175    DROP TABLE Tango_SPV


      It's clear that the SQL stored procedure is very slow and could do with a re-write and optimisation, but what is not clear is why it takes so long to write the QVD to disk.


      The file eventually does get written:


      14/07/2014  01:15 AM           662,807 Tango 2014 06.qvd


      It is not all that big at 648kb. There is plenty of disk space available (147Gb free), and there are no permissions issues as the file does get written successfully in the end.


      Due to the prolonged disk write, the reload eventually hits the 6 hour timeout put on the reload task. This could be increased, but I'm keen to understand why this issue is happening in the first place.


      It's only been happening for the last 7 days. Prior to that, the whole reloads process, including 2 QVD creations and storing actions, only took just over 2 hours. We are not aware of any changes to backup schedules on the system or other changes within the last 7 days. We've pushed the reload task back 45 mins and rebooted the system but the issue remains. The Qlikview server is managed by a third party in a virtualised environment to which we have limited access.


      Am I reading the log correctly? Is it the disk write taking a long time, or is it just the SQL stored proc call?


      Any suggestions would be appreciated.