Hi,

we are using ASMCD to sync our cubes from a Cubebuild Server to a Reporting Server. We migrated some days ago from 2012 to 2014. We are also using rel. Engine with StoredProcs for calling and executing xp_cmdshell for the Ascmd.

Actually all works fine for our smaller cubes. For the bigger one we got the following issue. The cube is being synced but the proc delivers error.

In the log we found this entry:

(7/7/2015 11:26:22 AM) Message: The directory '\\?\D:\SSAS_DATA\GPMR Local CNTR.510.db\Local Controlling Cube.0.cub' could not be deleted. Please check the directory for permissions. (Source: \\?\D:\SSAS_LOG\msmdsrv.log, Type: 3, Category: 289, Event ID: 0xC1210020)
(7/7/2015 11:26:34 AM) Message: The directory '\\?\D:\SSAS_DATA\GPMR Local CNTR.510.db' could not be deleted. Please check the directory for permissions. (Source: \\?\D:\SSAS_LOG\msmdsrv.log, Type: 3, Category: 289, Event ID: 0xC1210020)
(7/7/2015 11:34:04 AM) Message: Lock conflict status report: Aborting transaction on SPID 264495 blocking transaction on SPID 264858. (Source: \\?\D:\SSAS_LOG\msmdsrv.log, Type: 1, Category: 289, Event ID: 0x41210042)

As said the other cubes are working fine. They using the same SQl user, impersonating by the same Domain user to execute the xp_cmdshell, got the same Proc structure. ForceCommitTimeout: 30000, CommitTimeout:0

Any Ideas?

Kr Jrgen

Hi yger,

Thank you for your question.  

I am trying to involve someone more familiar with this topic for a further look at this issue. Sometime delay might be expected from the job transferring. Your patience is greatly appreciated.  

Thank you for your understanding and support. 

Thanks,

Hi Jrgen,

According to the following error message, we can see this is a blocking issue.

 (7/7/2015 11:34:04 AM) Message: Lock conflict status report: Aborting transaction on SPID 264495 blocking transaction on SPID 264858. (Source: \\?\D:\SSAS_LOG\msmdsrv.log, Type: 1, Category: 289, Event ID: 0x41210042)

Either SPID 264495 or SPID 264858 might be the one that sync the cubes, and another of them might hold a lock that prevent the sync process from being finished.

It is easy to explain why the smaller cubes are synced fine, which is because they hold fewer data, therefore, the conflict locks rarely occur. Things are different when sync large cubes, while it takes a very long time to sync the cube, it increases the chances for the other connections to acquire locks that might cause blocking.

Things to check:

• Make sure there are enough resources (memory, for example) for those tasks to finish timely.
• Find out what query statement is executed in the another connection, (either SPID 264495 or SPID 264858), see if we can optimize it.

Possible solutions/workarounds:

• Schedule the sync to be processed during night to avoid blocking.
• Change the isolation level to a lower level, for example, from READ COMMITTED to READ_COMMITTED_SNAPSHOT.
  

• Edited by SQL Team - MSFTMicrosoft employee 1 hour 19 minutes ago