In the previous blog post I explained that we have a 1 hour timeout in Powerpivot for Excel due to the inherited default SSAS instance properties. Now you might argue that this timeout should not pose a problem in the Powerpivot for Sharepoint environment. After all we are using a standalone SSAS instance in Sharepoint mode. We can thus modify the Instance properties to our liking via the Management Studio properties GUI or SSAS instance configuration file “msmdsrv.ini“.
Unfortunately this won’t help you. Even if you set your timeout properties to values much higher than the expected data refresh execution time.
The data refresh job will still fail after 1 hour execution time and will see the following error message appearing:
“The data refresh job failed because it has been inactive for more than 3600 seconds”
Whats the reason?
This time the limitation does not come from the SSAS instance timeout properties. Instead we need to look at the PowerPivot Data Refresh timer job architecture. Scheduled data refreshes are triggered by a PowerPivot Data Refresh timer job that scans schedule information in the PowerPivot service application database at one minute intervals. When data refresh is scheduled to begin, the timer job tries to add the request to a processing queue on an available PowerPivot server. If there is a previous data refresh run still active , the new triggered data refresh job won’t be able to run and it’ll simply return and wait for its next chance. In order to avoid complete blocking of data refresh activity by a single “hanging” data refresh run a data refresh timeout of 3600 sec was introduced. Now when a new data refresh request comes along and is blocked by a data refresh activity that has been running for > 3600 sec, then the old data refresh run will be aborted and the new data refresh request can proceed. For the aborted long runner data refresh job you will see the above mentioned error message: “The data refresh job failed because it has been inactive for more than 3600 seconds” . Which is not necessarily a very accurate statement because the data refresh job could have been quite busy during its life time. But in the application logic everything that has been running > 3600 sec is considered “hanging” and will be aborted.
The described data refresh timeout of 3600 sec cannot be modified. But it will only be applied whenever a new data refresh request enters the processing queue. Thus we do have a workaround in that we can increase the scan interval of the Powerpivot Data Refresh Timer Job from its default value of 1 min to a value that is larger than the execution time of your long running data refresh.
Be advised that this workaround has strong side effects because your data refreshes can now only run with lower frequency and you may have many scheduled data refreshes trying to run at the same time (when scan is done). For a discussion of this problem see the “Reschedule the PowerPivot Data Refresh Timer Job” section of the online documentation article Enable and Configure PowerPivot Data Refresh (Analysis Services).
June 2013 update:
we now have official documentation at technet:
It affects all Powerpivot versions we released so far:
- SQL Server 2012 SP1 PowerPivot for SharePoint and SharePoint 2010
- SQL Server 2012 SP1 PowerPivot for SharePoint and SharePoint 2013
- SQL Server 2012 PowerPivot for SharePoint and SharePoint 2010
- SQL Server 2008 R2 PowerPivot for SharePoint and SharePoint 2010