power bi 数据刷新_如何管理Power BI数据集刷新失败

power bi 数据刷新

As I covered in a previous post How to connect to (and query) Power BI and Azure using PowerShell, Power BI can be difficult to manage and administer, unlike on-premises BI solutions. One such concern that will often require quick action is the failure of a dataset refresh.

正如我在上一篇文章“ 如何使用PowerShell连接到（和查询）Power BI和Azure中所介绍的”中所述，与本地BI解决方案不同，Power BI可能难以管理。 通常需要快速采取行动的此类关注之一是数据集刷新失败。

If your reports and dashboards all rely on live connection or DirectQuery data sources like Azure SQL Database, Azure SQL Data Warehouse or SQL Server Analysis Services (on-premises or in Azure) then you won’t have to worry about dataset refreshes and this post will just be some interesting reading.

如果您的报表和仪表板都依赖实时连接或DirectQuery数据源（例如Azure SQL数据库，Azure SQL数据仓库或SQL Server Analysis Services）（本地或在Azure中），那么您就不必担心数据集刷新和这篇文章。将会是一些有趣的阅读。

Chances are, that you probably have at least one report that relies on an on-premises database or file source and you need to schedule it to refresh regularly to get up to date data. It’s in managing this functionality that the current offering within Power BI falls short, hopefully not for long with the rate updates are coming!

可能是，您可能至少有一个依赖于本地数据库或文件源的报告，并且需要安排它定期刷新以获取最新数据。 正是在管理此功能中，Power BI中的当前产品不足，希望随着速率更新的到来不会太久！

内置故障通知 (Built-in failure notifications)

Power BI has a method to notify you of a failed dataset, which is great. You obviously want to know when data wasn’t updated & you probably want to notify users or customers too. You may have received such an alert already. They look something like this:

Power BI有一种方法可以通知您失败的数据集，这很棒。 您显然想知道什么时候数据没有更新，您也可能想通知用户或客户。 您可能已经收到了这样的警报。 他们看起来像这样：

That’s a great first step but there is a great deal further we need to go to satisfy my inner Administrator.

这是迈出的重要第一步，但我们还需要做很多工作才能使我的内部管理员满意。

谁拥有这个！ (Who owns this!?)

You may have noticed the little checkbox near the bottom of each dataset settings page that lets you turn these failure notifications on.

您可能已经注意到每个数据集设置页面底部附近的小复选框，可用于打开这些故障通知。

The issue here is that there is no CC for a wider admin user or group. This notification will only email the current dataset owner in the event of a failure. Depending on your process for deploying content to Power BI or how users interact with it, this could be an analyst, a sales manager, a developer or indeed, the person who would be able to source & fix the issue.

这里的问题是没有CC用于更广泛的管理员用户或组。 如果发生故障，此通知将仅通过电子邮件发送给当前数据集所有者。 根据您将内容部署到Power BI的过程或用户与之交互的方式，这可能是分析师，销售经理，开发人员，或者实际上是能够找到并解决问题的人员。

Even with processes in place to “hand over” dataset ownership to a single administrator account, there will always be fluidity in where these notifications get sent, thus delaying the resolution of any issues that arise

即使有了将数据集所有权“移交给”一个管理员帐户的流程，发送这些通知的位置始终存在流动性，从而延迟了出现的任何问题的解决

但是怎么了！！ (But WHAT went wrong!?)

Oops, something went wrong! You’ve received your failure notification; now let’s check the email to see what happened.

哎呀！出事了！ 您已收到失败通知； 现在，让我们检查电子邮件以了解发生了什么。

Referring to the email excerpt above, we can see the dataset name & its next refresh time. Great, but what if you have the same dataset across several workspaces, maybe in a DEV, QA, PROD scenario?

参考上面的电子邮件摘录，我们可以看到数据集名称及其下一次刷新时间。 很好，但是如果您在多个工作空间中拥有相同的数据集，那可能是在DEV，QA，PROD场景中怎么办？

There’s no link to the failing dataset or the parent workspace. At the time of writing this, the Learn More link also hits a 404.

没有链接到失败的数据集或父工作区。 在撰写本文时，“ 了解更多”链接也会显示404。

Here is a good alternative page for troubleshooting dataset refresh issues: Troubleshooting Refresh Scenarios

这是解决数据集刷新问题的一个不错的替代页面： 刷新方案疑难解答

PowerShell警报 (PowerShell alerting)

Building on the API interactions within PowerShell from my previous blog posts I wanted to create my own dataset failure monitor. It’s not perfect but it will get me a lot more information than I get from the built-in functionality, and allow me to respond quicker too.

在我以前的博客文章中基于PowerShell中的API交互基础上，我想创建自己的数据集故障监视器。 这不是完美的方法，但是它将为我提供比内置功能更多的信息，并且也使我能够更快地做出响应。

I started by splitting out two reusable components of this monitor script to functions. The authentication & the notification.

我首先将此监视脚本的两个可重用组件分解为多个函数。 身份验证和通知。

I reference these in the main script but I plan on expanding and building these into a module in the future. Keep an eye on my GitHub. For now, save them with their function names in the same folder as the monitor script and you’re ready to go.

我在主脚本中引用了它们，但我计划将来将它们扩展并构建到模块中。 密切关注我的GitHub 。 现在，将它们及其函数名称保存在与监视脚本相同的文件夹中，即可开始使用。

Get-PBIAuthTokenUnattended (Get-PBIAuthTokenUnattended)

This first one is the authentication function. It enables unattended authentication into Azure with the use of an encrypted text file for your account’s password. The main blocker you will have with this function is the requirement for a Power BI “app”. If you already have your ClientID & Client Secret to hand, you can skip Steps 1 & 2.

第一个是身份验证功能。 通过使用加密的文本文件作为帐户密码，可以启用无人参与的身份验证到Azure。 使用此功能的主要功能是Power BI“应用程序”的要求。 如果您已经拥有ClientID和Client Secret，则可以跳过步骤1和2。

1. The Power BI app can be created from the Power BI app registration page. You do not need to be an Azure or Power BI admin to do so which is great. Make sure you choose the Server-side Web App type, which will generate both a ClientID and a Client_Secret. The ClientID can be retrieved from Azure if needed but if you don’t make note of the Client_Secret when you create the app, it’s gone. Start again. You will want to at least tick all the options under the Dataset API section for permissions.

   可以从Power BI应用程序注册页面创建Power BI应用程序 。 您无需成为Azure或Power BI管理员即可，这很棒。 确保选择服务器端Web应用程序类型，它将同时生成ClientID和Client_Secret。 可以根据需要从Azure检索ClientID，但是如果在创建应用程序时未记下Client_Secret，则该ID将消失。 重新开始。 您将至少要勾选“数据集API”部分下的所有选项以获取权限。