ssas表格模型 权限控制_如何在SQL Server 中自动执行SSAS表格模型处理

ssas表格模型 权限控制

There are many ways to process your SSAS Tabular Model. This can be achieved in SSIS using theAnalysis Services Execute DDL Taskor manually, through Management studio GUIbut to have a little fun & make the task more flexible I’m going to script this with ASSL/TMSL & build a notification round it. We can then schedule this as a step in a SQL agent job, call it from SSIS or PowerShell.

有许多方法可以处理SSAS表格模型。 这可以使用Analysis Services执行DDL任务在SSIS中实现，也可以通过Management Studio GUI手动实现但是要有一点乐趣并使任务更加灵活，我将使用ASSL / TMSL编写脚本并围绕它构建一个通知。 然后，我们可以将其安排为SQL代理作业中的一个步骤，从SSIS或PowerShell进行调用。

The easiest way to get started was for me to choose theProcess Databaseoption in SSMS and once the options are set, choosing to script to a new Query Window. This gives us a quick script to work with without the hassle of typing it out myself. I can then adjust or add to it as needed.

对于我来说，最简单的入门方法是在SSMS中选择“进程数据库”选项，一旦设置了选项，就选择脚本编写新的查询窗口。 这为我们提供了一个快速的脚本来使用，而无需自己输入。 然后，我可以根据需要进行调整或添加。

兼容性级别的重要性 (The Importance of Compatibility Level)

This was the XMLA generated for processing a tabular model calledCustomer Accountswhich sits on a SQL Server SSAS installation I have been playing with. One thing to note here is that the Compatibility Level for this DB is set to SQL Server SP1 or later(1103).

这是为处理称为客户帐户的表格模型而生成的XMLA，该表格模型位于我一直在使用SQL Server SSAS安装中。 这里要注意的一件事是，此数据库的兼容性级别设置为SQL Server SP1或更高版本（1103）。

<Process xmlns="/analysisservices//engine"><Type>ProcessDefault</Type><Object><DatabaseID>Customer Accounts</DatabaseID></Object></Process>

According to Microsoft the language this is using is Analysis Services Scripting Language (ASSL for XMLA). The importance of your database’s compatibility level & keeping it consistent is that this script will not work if you execute it against a tabular model with aCompatibility Levelof1200.XMLA is no longer usedfor tabular models as Microsoftchanged the scripting language. SQL Server now uses TMSL for scripting Tabular model databases. Here’s excerpts from the MSDN page that clarifies the change:

据微软称，它使用的语言是Analysis Services脚本语言（用于XMLA的ASSL） 。 数据库兼容性级别和保持一致性的重要性在于，如果您对兼容性级别为1200的表格模型执行脚本，则该脚本将无法工作。不再使用XMLA用于Microsoft的表格模型更改了脚本语言。 SQL Server 现在使用TMSL来编写表格模型数据库的脚本。 这是MSDN页面的摘录，阐明了更改：

“Tabular Model Scripting Language (TMSL) is the command and object model definition syntax for tabular databases at compatibility level 1200, created for the SQL Server version of Analysis Services. TMSL communicates to Analysis Services through the XMLA protocol, where the XMLA.Execute method accepts both JSON-based statement scripts in TMSL as well as the traditional XML-based scripts in Analysis Services Scripting Language (ASSL for XMLA).”

“表格模型脚本语言（TMSL）是用于表格数据库的命令和对象模型定义语法，兼容性级别为1200，是为Analysis ServicesSQL Server 版本创建的。TMSL通过XMLA协议与Analysis Services通信，其中XMLA.Execute方法既可以接受TMSL中的基于JSON的语句脚本，也可以接受Analysis Services脚本语言（针对XMLA的ASSL）中的基于XML的传统脚本。

ASSL is not ideal for Tabular models, but designing and implementing a more semanticlly correct scripting language requuired deep changes across the spectrum of the Analysis Services component architecture. Changes of this magnitude can only be made in major version releases, and only when all components are impacted by this change can be updated in tandem.

ASSL对于表格模型不是理想的选择，但是设计和实现语义上更正确的脚本语言需要在Analysis Services组件体系结构的整个范围内进行深刻的更改。如此大的更改只能在主要版本中进行，并且只有当所有组件都受此更改影响时，才能一并进行更新。

The main point to note with this change is that we didn’t see a transition version (with support for both ASSL & TMSL). It’s a straight cut. “1103” databases won’t be able to use TMSL and “1200” won’t be able to use XMLA. Don’t Panic! There is a workaround however, that will help you move a script between compatibility levels. (I’ll go into that later). The headache is, if you have any tabular models you are thinking about moving up toCompatibility Level 1200, check the scripts you run against them as they will ALL need to be recreated using TMSL!

进行此更改的主要注意事项是，我们没有看到过渡版本（同时支持ASSL和TMSL）。 这是直截了当的。 “ 1103”数据库将无法使用TMSL，而“ 1200”数据库将无法使用XMLA。 不要惊慌！ 但是，有一种解决方法可以帮助您在兼容性级别之间移动脚本。 （我稍后再讨论）。 令人头疼的是，如果您有正在考虑升级到Compatibility Level 1200的任何表格模型，请检查针对它们运行的​​脚本，因为它们都需要使用TMSL重新创建！

You may have also noticed, that even though we are using a “1200” database & we’ve generated a TMSL script, that SSAS is still using an XMLA window in Management Studio. This is because SSAS still uses the XMLA protocol which will accept both JSON and ASSL. The XMLA protocol accepts both but SSAS does not, which makes transition to the higher, 1200 compatibility level, far from smooth.

您可能还已经注意到，即使我们使用的是“ 1200”数据库并生成了TMSL脚本，SSAS仍在Management Studio中使用XMLA窗口。 这是因为SSAS仍使用XMLA协议，该协议将同时接受JSON和ASSL。 XMLA协议接受两种协议，但SSAS不能接受，这使得过渡到更高的1200兼容级别远远不够顺利。

TMSL万岁！ (Long live TMSL!)

Using the same settings in theProcess Databasewizard against a “1200 Tabular DB” generates the following script:

在“Process Database”向导中针对“ 1200 Tabular DB”使用相同的设置将生成以下脚本：

{"refresh": {"type": "automatic","objects": [{"database": "Customer Accounts"}]}}

So, using this as our starting point, we can flesh the script out a bit.

因此，以此为出发点，我们可以使脚本更加充实。

descriptiondefinition.描述定义将更多的元数据添加到脚本中。 If you wanted to only process a table that can be defined using thetableparameter. 如果只想处理可以使用table参数定义的表。Refreshcommand:刷新”命令定义了所有选项：

{"refresh": {"description": "This is where I explain what this script does","type": "automatic","objects": [{"database": "Customer Accounts""table": "Date"}]}}

使用SQL Agent执行TMSL (Executing TMSL with SQL Agent)

Now that we have a script to work with, let’s create the job to surround it.

现在我们有了一个可以使用的脚本，让我们创建一个包围它的作业。

Create a new step with the following settings:

使用以下设置创建一个新步骤：

Type:SQL Server Analysis Services Command类型：SQL Server Analysis Services命令Run As:SQL Server Agent Service Account运行方式：SQL Server代理服务帐户Server:SSAS01服务器：SSAS01

Jumping aside for a minute, I mentioned at the start that there is a workaround to get TMSL to execute in an 1103 or 1100 compatibility level database. This is how we can get round that.

稍等片刻，我在开始时提到，有一种解决方法可让TMSL在1103或1100兼容性级别的数据库中执行。 这就是我们可以解决的方法。

As TMSL is only supported in SQL Server you will not be able to set this SQL Agent job up as shown above. To do this we can wrap the JSON in XMLA which can be handled by a SQL - Agent job. Here’s an example:

由于TMSL仅在SQL Server 中受支持，因此您将无法如上所述设置此SQL Agent作业。 为此，我们可以将JSON包装在XMLA中，这可以由SQL -代理作业处理。 这是一个例子：

<Statement xmlns="urn:schemas-microsoft-com:xml-analysis">{"refresh": {"type": "automatic","objects": [{"database": "Customer Accounts"}]}}</Statement>

With ourProcess DBstep setup, we now want to look at logging & notification of success.

通过我们的Process DB步骤设置，我们现在要查看日志记录和成功通知。

We want to provide information in an email format that will help admins or users know the database has been processed. We can query the SSAS engine for the last processed date of the database. This will have to be an MDX query so I’ll need to get the SQL Agent step to store the output. The final “email” step can then pick that up & send the email.

我们希望以电子邮件格式提供信息，以帮助管理员或用户知道数据库已被处理。 我们可以查询SSAS引擎以获取数据库的最后处理日期。 这必须是MDX查询，因此我需要执行SQL Agent步骤来存储输出。 然后，最后的“电子邮件”步骤可以接听并发送电子邮件。

Here’s how…

这是如何做…

Create a new step with the following settings:

使用以下设置创建一个新步骤：

Type:SQL Server Analysis Services Query类型：SQL Server Analysis Services查询Run As:SQL Server Agent Service Account运行方式：SQL Server代理服务帐户Server:SSAS01服务器：SSAS01Database:数据库：Customer Accounts(drop down)客户帐户（下拉列表）

SELECT [CATALOG_NAME],[DATE_MODIFIED]FROM$SYSTEM.DBSCHEMA_CATALOGSWHERECATALOG_NAME = 'Customer Accounts'

Log to Tablecheckbox.记录到表”复选框。

This logs the job step output (Our DB & last processed date) to the [msdb].[dbo].[sysjobstepslogs] table. We’ll then add logic to the email step to find & return these values.

这会将作业步骤输出（我们的数据库和最后处理日期）记录到[msdb]。[dbo]。[sysjobstepslogs]表中。 然后，我们将在电子邮件步骤中添加逻辑以查找并返回这些值。

For the final step I’ve put together some SQL to query the above table and send it as an HTML email.

对于最后一步，我整理了一些SQL来查询上表并将其作为HTML电子邮件发送。

Feel free to pad this out with more options. I.e.

随意使用更多选项进行填充。即

Check if the cube has processed “today” first & send a different email.检查多维数据集是否已先处理了“今天”并发送其他电子邮件。Highlight the datetime if the refresh took longer than XX mins (assuming you know the start time)如果刷新时间超过XX分钟，请突出显示日期时间（假设您知道开始时间）

Create a new step with the following settings:

使用以下设置创建一个新步骤：

Type:Transact-SQL script (T-SQL)类型：Transact-SQL脚本（T-SQL）Run As:SQL Server Agent Service Account运行方式：SQL Server代理服务帐户Database: msdb数据库：msdb

USE msdbGOBEGINDECLARE @EmailRecipient NVARCHAR(1000)DECLARE @SubjectText NVARCHAR(1000)DECLARE @ProfileName NVARCHAR(1000)DECLARE @tableHTML1 NVARCHAR(MAX)DECLARE @tableHTMLAll NVARCHAR(MAX)DECLARE @startDate SMALLDATETIMEDECLARE @stopDate SMALLDATETIMEDECLARE @timeSpanText VARCHAR(100)SET QUOTED_IDENTIFIER ONSET NOCOUNT ONSELECT @EmailRecipient = 'craig@'SET @SubjectText = 'SSAS201 Process Database has Completed'SELECT TOP 1 @ProfileName = [Name] FROM msdb.dbo.sysmail_profile WHERE [Name] = 'Alert-BI-Admins'SET @tableHTML1 =N'<H3 style="color:#642891; font-family:verdana">SSAS Tabular Processing</H3>' +N'<p align="left" style="font-family:verdana; font-size:8pt"></p>' +N'<table border="3" style="font-size:8pt; font-family:verdana; text-align:left">' +N'<tr style="color:#42426F; font-weight:bold"><th>Tabluar Database Name</th><th>Date Last Processed</th>' +CAST(( SELECTtd = CAST([log] as xml).value('(//*[local-name()="CATALOG_NAME"])[1]', 'nvarchar(max)'), '',td = CAST(CONVERT(datetimeoffset, CAST([log] as xml).value('(//*[local-name()="DATE_MODIFIED"])[1]', 'nvarchar(max)'),127) AS DATETIME)FROM [msdb].[dbo].[sysjobstepslogs]WHERE step_uid IN (SELECT js.step_uidFROM [msdb].[dbo].[sysjobsteps] jsLEFT JOIN [msdb].[dbo].[sysjobs] jON j.job_id = js.job_idWHERE j.name = 'Process Customer Accounts Tabular Model' --This is the name of the SQL Agent Job & is used to uniquely identify the step log we wantAND js.step_id = 2) --This is the MDX step number in our SQL Agent Job. Change this if you add other steps. FOR XML PATH('tr'), TYPE) AS NVARCHAR(MAX)) +N'</table>'--Set Table variable to a zero length string if it’s nullSET @tableHTMLAll = ISNULL (@tableHTML1,'')-- Check Table variable is greater than a zero length stringIF @tableHTMLAll <> ''BEGINSELECT @tableHTMLAllEXEC msdb.dbo.sp_send_dbmail@profile_name = @ProfileName,@recipients = @EmailRecipient,@body = @tableHTMLAll,@body_format = 'HTML',@subject = @SubjectTextENDSET NOCOUNT OFFEND

You can setup a schedule for this but I’ve just finished here to test the script.

您可以为此设置时间表，但是我刚刚在这里完成了测试脚本的步骤。

The output of this script should look something like the HTML output below, which was generated by the SELECT @tableHTMLAll line above, just before the send mail command, in case you wanted to check the output yourself.

该脚本的输出应类似于下面HTML输出，该输出是由上面的SELECT @tableHTMLAll行生成的，就在send mail命令之前，以防您自己检查输出。

This is quite a robust way to automate the processing of your tabular model but bear in mind that errors generated during processing aren’t captured & will just spit out as a failed Agent job. You may also need to split up your processing into multiple tasks in the job, depending on the size of your model & the version of SQL Server you use. (Tabular models are limited to using 16GB in Standard edition!). Please let me know if anyone finds a way of capturing processing errors or a better way to do what I’ve described. This was a learning process for me and I hope it will help others out.

这是一种自动化处理表格模型的强大方法，但请记住，处理过程中生成的错误不会被捕获，只会作为失败的Agent作业吐出。 您可能还需要根据作业的大小和所用SQL Server的版本将处理分为多个任务。 （表式机型仅限于标准版使用16GB！）。 请让我知道是否有人找到捕获处理错误的方法或做我所描述的更好的方法。 这对我来说是一个学习过程，希望对其他人有帮助。

参考资料 (References)

Tabular Model Scripting Language (TMSL) Reference 表格模型脚本语言（TMSL）参考 Analysis Services Scripting Language (ASSL for XMLA) Analysis Services脚本语言（用于XMLA的ASSL） Refresh command (TMSL) 刷新命令（TMSL）

翻译自: /how-to-automate-ssas-tabular-model-processing-in-sql-server-/

ssas表格模型 权限控制

如果觉得《ssas表格模型 权限控制_如何在SQL Server 中自动执行SSAS表格模型处理》对你有帮助，请点赞、收藏，并留下你的观点哦！