| Multi user SSAS writebacks may result to blocks on similar functions and new connections |
| Written by Nicholas Dritsas |
| Thursday, 23 July 2009 11:00 |
|
Writeback consists of two distinct processes. The first one is an update cube process that updates the current session with the changes. Only the current user sees the changes and he can continue with updates and what/if analysis. The second process is a commit so the changes get committed in the database and all users can see the results. The challenge is when you have many users issuing writeback commits. A writeback commit requires an SSAS database write lock. If it gets it, the other commit requests (eg. from other writebacks, cube process, alter roles etc) will have to wait. Also, during this time, new connections cannot be made since a new connection requires a read lock of the database. Read more here or here... |
Latest Author Articles
- Develop Reporting Services reports using Analysis Services data; a SQL Server 2008 technical case study
- Multi user SSAS writebacks may result to blocks on similar functions and new connections
- Proper partitioning can improve dramatically the writeback process when dealing with large data sets
- Using ProcessingGroup Dimension property option ByTable vs. ByAttribute may error with string keys
- Best SQL Server 2005 MDX Tips and Tricks - Part 1
