Master Data Services Error: Resolving from a long-running stucked Staging Batch with Status “Queued to Clear” or “Not Running”

In some ocassions,  you may run into a runaway, long-running or stucked staging batch with Master Data Services in SQL Server 2008 R2. The issue happens most frequently when a fairly large batch of rows are being processed for update or deletion.

The issue has to do with Service Broker, either due to a timeout or notifications not being received or received incomplete.  You can confirm the issue when you query the queue [mdm].[microsoft/mdm/queue/stagingbatch]. You will see one or more messages in this queue. After searching through a couple of forum threads I found the solution to be fairly simple: rollback transactions an re-enable Service Broker. The steps are as follows:

1. Set the MDS database in single user mode and rollback uncommitted transactions.

   ALTER DATABASE [MDS] SET  SINGLE_USER WITH ROLLBACK IMMEDIATE;

2. Re-enable Service Broker on the MDS database.

   ALTER DATABASE [MDS] SET  ENABLE_BROKER WITH NO_WAIT;

3. Set the MDS database back in to “regular” multi-user mode.

   ALTER DATABASE [MDS] SET  MULTI_USER WITH ROLLBACK IMMEDIATE;

Once the MDS database is brought back online, all queued messages should be cleared out and MDS database will be able to communicate normally with Service Broker.

You can check Books on Line for more information on the difference between “NO WAIT” and “WITH ROLLBACK IMMEDIATE” options when issuing the ALTER DATABASE command here. Pinal Dave has a good post about the difference between these two options as well here.

Hope this post has helped you. Your feedback is greatly appreciated.

SSAS errors: DefaultMember(Measures,Measures) (1, 1) The ‘[xxx]’ member was not found in the cube when the string, [Measures].[xxx], was parsed.

When attempting to browse an Analysis Services cube you may be presented with the following error message:

DefaultMember(Measures,Measures) (1, 1) The ‘[xxx]’ member was not found in the cube when the string, [Measures].[xxx], was parsed.

The error message is self-explanatory. There is a Default Member being referenced and was not found. But, pinpointing where this “DefaultMember” is being referenced may me a bit challenging.

The Root Cause

The root cause of this issue is quite simple: a deleted or renamed measure is still being referenced by its original name. Some of the areas where this deleted or renamed default measure could still be referenced by its original name include:

1. Cube DefaultMeasure property
2. Perspective DefaultMeasure property
3. Calculations

The fix

The fix may involve adding the measure back or renaming the measure to its original name or digging through several areas of the cube where the deleted or renamed measure is still being referenced by its original name. Here are your options:

1. Add or rename the measure back to its original name.
This may not be the desired option, but it could be the easiest and quickest way to fix the issue.

2. Modify each Perspective’s DefaultMeausure property
Unfortunately, deleting or renaming a measure does not “trickle-down” where it is being referenced in a perspective. The original measure’s name will remain.

3. Change the cube DefaulMeasure property to the new measure name.
Similar to Perspectives, deleting or renaming a measure does not “trickle-down” its new name to the cube’s DefaultMeasure property. You will need to select a new measure in the DefaultMeasure property.

4. Modify the cube XML code
This option may be a little daunting to some, but in the end it is the quickest way to make sure the original measure’s name is replaced by the new measure’s name. To do this, in Solution Explorer right click on the Cube’s name and select View Code. The XMLA definition will open. At this point, press CTRL+H or click on Edit->Find and Replace->Quick Replace.The Quick Replace window will open. Type the original measure’s name in the “Find what” textbox and type the new measure’s name in the “Replace with:” textbox.

SSAS errors: Errors in the metadata manager. The dimension with ID of ‘xxx’ referenced by the ‘yyy’ cube, does not exist.

When deploying or processing a cube or dimension you may encounter an error similar to this:

Errors in the metadata manager. The dimension with ID of ‘Student Financial Aid ~MC-Student AK’, Name of ‘Student Financial Aid ~MC-Student AK’ referenced by the ‘Student Financial Aid ~MC’ cube, does not exist.
Errors in the metadata manager. An error occurred when loading the Student Financial Aid ~MC cube, from the file, ‘\\?\C:\Program Files\Microsoft SQL Server\MSAS10_50.MSSQLSERVER\OLAP\Data\SSAS Labs.0.db\Student Financial Aid ~MC.1.cub.xml’.
(Microsoft.AnalysisServices)

If you try to process, deploy or delete this cube database you will get the same error over and over. You may even get this error when trying to deploy or process a totally separate cube database or dimension in another project or solution.

Basically, there has a been a corruption of the XML file that holds your cube definition possibly because of conflicting dimension definition between your cube structure inside your project and the deployed cube database or changes in the underlying source schema. The exact reason why this happens is a little unclear as I have not been able to replicate the circumstances why this happens. I have come across this issue only twice. The purpose of this post is to show you how to get rid of the cube database, allowing you to re-deploy it from your BIDS project.

First, stop the SQL Server Analysis Services service from the Windows Services console,  from SQL server Configuration Manager or from the command prompt using net stop <service> (or even from PowerShell) . Once the service  has stopped rename or delete the folder where the cub.xml file resides as specified on the error window.

In my case, I need to rename or delete the folder “SSAS Labs.0.db” as specified on the third sentence: “C:\Program Files\Microsoft SQL Server\MSAS10_50.MSSQLSERVER\OLAP\Data\SSAS Labs.0.db\”. You can rename this folder whatever you want, such as “XXX SSAS Labs.0.db” or simply delete it.

Once you rename or delete the folder, restart the SQL Server Analysis Services service. Connect to your SQL Server Analysis Services instance via SQL Server Management Studio (SSMS) and delete the cube database. Now you should be able to re-deploy your cube database from your BIDS project.

Once I replicate the circumstances that cause this issue, I will do a follow-up post. Make sure to check back or subscribe to my blog.

*** Update 5/10/2011: Apparently this is a SQL Server 2008 R2 issue when re-deploying several times in a short period of time. I was advised this issue should be corrected in Service Pack 1. If you are having this issue in SQL Server 2008 R1 or still experiencing it after installing SQL Server 2008 R2 Service Pack 1 please comment.

SSAS errors: Logon failure / Cube process failure

Often I encounter this error myself when trying to process an SSAS cube at a client’s site or get asked by customers and friends how to solve this error. Although it may seem really obvious,  not everyone may understand “what” is rejecting their credentials or “what” are they authenticating against.

Simple. The data source.

So, what credentials are being passed through to your data source?

At this point you may answer: “my Windows credentials” or “credentials of the current user.” This is not always the case.

Impersonation
Your Windows credentials are used to create the connection strings to your data source at design-time. During processing and run-time, Analysis Services needs an account to be able to reach the data source. Keep in mind that you will not always process Analysis Services cubes manually within BIDS or SSMS. Once the Analysis Services cube is initially deployed, in most environments you will have scheduled SSIS packages that will re-process the cubes every night. In order for Analysis Services to be able to read the data from your data source, it needs some form of credentials to pass through. This is also known as impersonation.

In Analysis Services 2008-R2, there are several impersonation options:

• Use a specific Windows username and password
• Use the service account
• Use the credentials of the current user
• Inherit (or default)

To learn more about each of these options you can read MSDN Books Online at: http://msdn.microsoft.com/en-us/library/ms187597.aspx

In a nutshell, the impersonation account specified needs to have read access to your data source. For example, if your data source resides in SQL Server, the account specified as your impersonation account needs to  be mapped to your database with db_datareader role membership. It is best practice to specify a dedicated account that has limited read-only access to the database. Avoid using an account with elevated privileges such as sysadmin or db_owner.

The recommended impersonation setting is to specify a Windows username and password. If your server is joined to a domain, you will have to specify DOMAIN\Username in the User name textbox and the associated password in the Password textbox as seen below:

If you specify “Use the service account”,  it will use the account used to start the Analysis Services instance to authenticate against your data source. In this case, the service account will need read access to the data source. Keep in mind that the system service accounts Network Service, Local System and Local Service will not have access to your data source if the data source is on a different server. Typically, you will use a Windows domain account that has Log on as Service privilege in Active Directory Group Policy as your service account to start Analysis Services.

Inherit (SQL Server 2008/2008-R2, Default in SQL Server 2005) uses the impersonation mode  and credentials set in the Data Source Impersonation Info database property. To view or modify this database property, open SSMS and connect to the Analysis Services instance, expand the databases folder and right click on the database you are interested and select properties. You will now see the database properties window and the impersonation mode selected. To change the impersonation mode, click on the elipsis inside of the Data Source Impersonation Info textbox highlighted below:

Per MSDN Books Online, by default the Data Source Impersonation Info database property is set to Use the service account. This means that if the Inherit impersonation option is selected in your BIDS solution, it will use whatever is specified in the Data Source Impersonation Info database property. If this database property was set to Default as shown on the image above, then it will use the Default impersonation mode in which it will use the impersonation method that is most appropriate for the context in which impersonation is used. For more details read http://technet.microsoft.com/en-us/library/ms126693.aspx.

In summary, if you are getting a logon failure when processing an SSAS cube, check the impersonation settings of your data source. As a best practice, choose “Use specific username and password” as Impersonation option and use a dedicated Windows domain account.

The dedicated domain account should be configured at a minimmum as follows:
– Regular domain user or part of a restricted domain user group
– No password expiration policy should be applied. If not, password may expire and processing will fail at some point.
– Account should be mapped to a SQL Server database login with db_datareader role membership.

If the dedicated domain account will be used as the service account, make sure it is part of the “Logon as a service” AD Group Policy.