为语义模型禁用 OneDrive 刷新后，仍可以通过在语义模型菜单中选择“立即刷新”来按需同步语义模型
。 在按需刷新过程中，Power BI 会检查 OneDrive 或 SharePoint Online 上的源文件是否比 Power BI 中的语义模型更新，如果是，则同步语义模型。 “刷新历史记录”会在“OneDrive”选项卡上将这些活动列为按需刷新 。
请记住，OneDrive 刷新不会从原始数据源中请求数据， 而只是使用 .pbix、.xlsx 或 .csv 文件中的元数据和数据更新 Power BI 中的资源，如下图所示。 为确保语义模型具有数据源中的最新数据，Power BI 还会在按需刷新过程中触发数据刷新。 你可以在“刷新历史记录”中切换到“计划”选项卡来对此进行验证 。
如果为连接 OneDrive 或 SharePoint Online 的语义模型一直启用 OneDrive 刷新，并且希望按计划执行数据刷新，请确保配置计划，以便 Power BI 在 OneDrive 刷新后执行数据刷新。 例如，如果你创建自己的服务或进程，以在每天凌晨 1 点更新 OneDrive 或 SharePoint Online 中的源文件，则可以将计划刷新配置为凌晨 2:30，以便为 Power BI 提供足够的时间来完成 OneDrive 刷新，然后再启动数据刷新。
查询缓存刷新
如果语义模型驻留在高级容量上，则可以通过启用查询缓存来提高所有关联报表和仪表板的性能，如以下屏幕截图所示。 查询缓存会指示高级容量使用其本地缓存服务来维护查询结果，避免基本数据源计算这些结果。 有关详细信息，请参阅
Power BI Premium 中的查询缓存
。
但是，在进行数据刷新之后，先前缓存的查询结果便不再有效。 Power BI 会丢弃这些缓存结果，并且必须重新生成它们。 因此，对于与经常刷新（例如每天 48 次）的语义模型关联的报表和仪表板，使用查询缓存的意义不大。
报表视觉对象刷新
此刷新过程不太重要，因为它仅与 Analysis Services 的实时连接有关。 对于这些连接，Power BI 会缓存报表视觉对象的最后一个状态，这样一来，当你再次查看报表时，Power BI 就不必查询 Analysis Services 表格模型。 当你与报表交互时（例如通过更改报表筛选器），Power BI 会查询表格模型并自动更新报表视觉对象。 如果你怀疑报表显示过时数据，还可以选择报表的“刷新”按钮来触发所有报表视觉对象的刷新操作，如以下屏幕截图所示。
仅刷新固定的视觉对象，而不是固定的实时页面。 若要刷新固定的实时页面，可使用浏览器的“刷新”按钮。
查看数据基础结构依赖项
无论采用哪种存储模式，都必须能够访问基础数据源，否则将无法成功刷新数据。 有三种主要的数据访问方案：
语义模型使用驻留在本地的数据源
语义模型使用云中的数据源
语义模型使用来自本地源和云源的数据
连接到本地数据源
如果语义模型使用 Power BI 无法通过直接网络连接访问的数据源，则必须先为此语义模型配置网关连接，然后才能启用刷新计划或执行按需数据刷新。 有关数据网关及其工作原理的详细信息，请参阅
什么是本地数据网关？
你有以下选择：
选择具有所需数据源定义的企业数据网关
部署个人数据网关
可以在
管理数据源 - 导入/计划刷新
一文中找到需要数据网关的数据源类型列表。
使用企业数据网关
Microsoft 建议使用企业数据网关（而不是个人网关）将语义模型连接到本地数据源。 请确保正确配置网关，这意味着网关必须具有最新的更新和所有必需的数据源定义。 数据源定义可为 Power BI 提供给定源的连接信息，包括连接终结点、身份验证模式和凭据。 有关在网关上管理数据源的详细信息，请参阅
管理数据源 - 导入/计划刷新
。
如果你是网关管理员，则将语义模型连接到企业网关相对来说比较简单。 必要时，可以使用管理员权限立即更新网关并添加缺少的数据源。 实际上，你可以直接从语义模型设置页面向网关添加缺少的数据源。 展开切换按钮以查看数据源，然后选择“添加到网关”链接，如以下屏幕截图所示。 但如果你不是网关管理员，则必须联系网关管理员添加所需的数据源定义。
仅网关管理员可将数据源添加到网关。 此外，确保网关管理员将你的用户帐户添加到有权使用数据源的用户的列表。 语义模型设置页面仅允许选择你有权使用其匹配数据源的企业网关。
请确保将正确的数据源定义映射到数据源。 如上面的屏幕截图所示，网关管理员可在连接到同一数据源的单个网关上创建多个定义，其中每个定义使用不同的凭据。 如示例中所示，销售部门中的语义模型所有者会选择 AdventureWorksProducts-Sales 数据源定义，而支持部门中的语义模型所有者会将语义模型映射到 AdventureWorksProducts-Support 数据源定义。 如果数据源定义的名称不直观，请联系网关管理员来明确要选择哪个定义。
语义模型只能使用单个网关连接。 换句话说，不能跨多个网关连接访问本地数据源。 因此，必须将所有必需的数据源定义添加到同一网关。
部署个人数据网关
如果你无权访问企业数据网关，并且你是唯一管理语义模型的人员，无需与其他人共享数据源，那么可以在个人模式下部署数据网关。 在“网关连接”部分的“未安装个人网关”下，选择“立即安装” 。 如
本地数据网关（个人模式）
中所述，个人数据网关存在若干限制。
与企业数据网关不同，你无需向个人网关添加数据源定义， 可以使用语义模型设置中的“数据源凭据”部分来管理数据源配置，如以下屏幕截图所示
。
访问云数据源
如果 Power BI 可以与云数据源（如 Azure SQL DB）建立直接网络连接，则使用该源的语义模型不需要数据网关。 相应地，可以使用语义模型设置中的“数据源凭据”部分来管理这些数据源的配置
。 如以下屏幕截图所示，你无需配置网关连接。
每个用户在其拥有的所有语义模型上，每个数据源只能有一组凭据，无论语义模型驻留的工作区是什么。 每个语义模型只能有一个所有者。 如果想要更新语义模型的凭据，但不是语义模型所有者，必须先单击语义模型设置页面上的“接管”按钮来接管语义模型。
在同一源查询中访问本地源和云源
语义模型可以从多个源获取数据，这些源可能驻留在本地或云中。 但是，如前所述，一个语义模型只能使用单个网关连接。 虽然云数据源不一定需要网关，但如果语义模型在单个糅合查询中同时连接到本地源和云源，则需要网关。 在此方案中，Power BI 也必须使用网关来访问云数据源。 下图阐释了此类语义模型如何访问其数据源。
如果语义模型使用不同的糅合查询连接到本地源和云源，则 Power BI 使用网关连接访问本地源，使用直接网络连接访问云源。 如果糅合查询合并或追加来自本地源和云源的数据，则即使是云源，Power BI 也会切换为使用网关连接。
Power BI 语义模型依靠 Power Query 来访问和检索源数据。 以下糅合列表显示了合并来自本地源和云源的数据的基本查询示例。
OnPremSource = Sql.Database("on-premises-db", "AdventureWorks"),
CloudSource = Sql.Databases("cloudsql.database.windows.net", "AdventureWorks"),
TableData1 = OnPremSource{[Schema="Sales",Item="Customer"]}[Data],
TableData2 = CloudSource {[Schema="Sales",Item="Customer"]}[Data],
MergedData = Table.NestedJoin(TableData1, {"BusinessEntityID"}, TableData2, {"BusinessEntityID"}, "MergedData", JoinKind.Inner)
MergedData
可通过以下两种方式来配置数据网关，以支持合并或追加来自本地源和云源的数据：
除本地数据源外，将云源的数据源定义也添加到数据网关。
启用复选框“允许用户的云数据源通过此网关群集刷新”。
如果启用“允许用户的云数据源通过网关配置中的此网关群集刷新”复选框（如上面的屏幕截图所示），则 Power BI 可使用该用户在语义模型设置中的“数据源凭据”下为云源定义的配置
。 这有助于降低网关配置开销。 但是，如果希望更好地控制网关建立的连接，则不应启用此复选框。 在这种情况下，必须向网关添加要支持的每个云源的显式数据源定义。 也可以启用该复选框，并向网关添加云源的显式数据源定义。 在这种情况下，网关会使用所有匹配源的数据源定义。
配置查询参数
使用 Power Query 创建的糅合或 M 查询的复杂程度可能不同，既有可能是简单的步骤，也有可能是复杂的参数化构造。 以下列表显示了一个小型糅合查询示例，它使用两个名为
SchemaName
和
TableName
的参数来访问 AdventureWorks 数据库中的给定表。
Source = Sql.Database("SqlServer01", "AdventureWorks"),
TableData = Source{[Schema=SchemaName,Item=TableName]}[Data]
TableData
查询参数仅适用于导入模式语义模型。 DirectQuery/LiveConnect 模式不支持查询参数定义。
若要确保参数化语义模型访问正确的数据，必须在语义模型设置中配置糅合查询参数。 也可以使用
Power BI REST API
以编程方式更新参数。 以下屏幕截图显示了一个用户界面，可在其中配置使用上述糅合查询的语义模型的查询参数。
刷新和动态数据源
动态数据源是这样一种数据源，其中的部分或所有信息在 Power Query 运行查询之后才能确定是否需要连接，因为数据是在代码中生成的或从其他数据源返回的。 示例包括：SQL Server 数据库的实例名称和数据库；CSV 文件的路径；或 Web 服务的 URL。
在大多数情况下，无法在 Power BI 服务中刷新使用动态数据源的 Power BI 语义模型。 有几种例外情况，可以在 Power BI 服务中刷新动态数据源，例如，将 RelativePath 和查询选项与 Web.Contents M 函数结合使用时。 也可以刷新引用 Power Query 参数的查询。
若要确定是否可以刷新动态数据源，请在 Power Query 编辑器中打开“数据源设置”对话框，然后选择“当前文件中的数据源” 。 在出现的窗口中，查找以下警告消息，如下图所示：
某些数据源可能未列出，因为它们包含手动编写的查询。
如果该警告显示在出现的“数据源设置”对话框中，则会显示无法在 Power BI 服务中刷新的动态数据源。
配置数据刷新时，在 Power BI 和数据源之间建立连接是目前为止最具挑战性的任务。 其余步骤（包括设置刷新计划和启用刷新失败通知）相对来说比较简单。 有关分步说明，请参阅操作指南
配置计划刷新
。
设置刷新计划
可在“计划刷新”
部分定义刷新语义模型的频率和时间段。 如前所述，如果语义模型位于共享容量上，则可以配置每天最多 8 个时间段；如果位于 Power BI Premium 上，则可以配置每天最多 48 个时间段。 以下屏幕截图显示了时间间隔为 12 小时的刷新计划。
配置完刷新计划后，语义模型设置页面会通知你下一个刷新时间，如上面的屏幕截图所示。 如果要加快数据刷新速度以执行网关和数据源配置测试等操作，请使用导航窗格的语义模型菜单中的“立即刷新”选项进行按需刷新
。 按需刷新不会影响下一计划的刷新时间。
Power BI 没有每月刷新间隔选项。 但是，可以使用 Power Automate 创建每月发生的自定义刷新间隔，如以下
Power BI 博客文章
中所述。
另请注意，配置的刷新时间可能不是 Power BI 启动下一个计划进程的确切时间。 Power BI 会尽最大努力启动计划刷新。 目标是在计划时间段的 15 分钟内启动刷新，但如果服务无法更快地分配所需资源，则可能会延迟最多一小时。
Power BI 会在连续四次失败后或当服务检测到需要配置更新的不可恢复错误（例如无效或过期的凭据）时停用刷新计划。 无法更改连续失败阈值。
获取刷新失败通知
默认情况下，Power BI 通过电子邮件将刷新失败通知发送给语义模型所有者，以便在发生刷新问题时，他们可以及时采取行动。 如果所有者在其移动设备上具有 Power BI 应用，则他们也会在那里收到失败通知。 当服务由于连续失败而禁用计划刷新时，Power BI 也会向你发送电子邮件通知。 Microsoft 建议将复选框“向语义模型所有者发送刷新失败通知电子邮件”保留为启用状态
。
另外，最好是使用“
刷新失败时，向这些联系人发送电子邮件
”文本框来指定计划刷新失败通知的其他收件人。 指定的收件人可通过电子邮件接收刷新失败通知，并将通知推送到移动应用，就像语义模型所有者所做的那样。 指定的收件人可以是在休假时负责处理语义模型的同事，也可以是负责处理部门或组织的刷新问题的支持团队的电子邮件别名。 向除语义模型所有者以外的其他人发送刷新失败通知有助于确保及时察觉和处理相关问题。
向移动应用推送通知不支持组别名。
请注意，Power BI 不仅会在刷新失败时发送通知，还会在服务因数据集不活动而暂停计划刷新时发送通知。 两个月后，当没有用户访问基于语义模型构建的任何仪表板或报表时，Power BI 会认为该语义模型处于非活动状态。 在这种情况下，Power BI 会向语义模型所有者发送一封电子邮件，指出该服务已暂停语义模型的刷新计划。 有关此类通知的示例，请参阅以下屏幕截图。
若要恢复计划刷新，请访问使用此语义模型生成的报表或仪表板，或使用“立即刷新”选项手动刷新语义模型
。
不支持向外部用户发送刷新通知。 在“刷新失败时，向这些用户发送电子邮件”文本框中指定的收件人必须在 Microsoft Entra 租户中拥有帐户。
此限制适用于语义模型刷新和数据流刷新。
检查刷新状态和历史记录
除了失败通知之外，最好定期检查语义模型是否存在刷新错误。 一种快捷方法是查看工作区中的语义模型列表。 出现错误的语义模型会显示一个小警告图标。 选中警告图标可获取附加信息，如以下屏幕截图所示。 有关解决特定刷新错误的详细信息，请参阅
刷新方案故障排除
。
警告图标有助于指示当前的语义模型问题，但偶尔检查刷新历史记录也不失为一个好办法。 顾名思义，通过刷新历史记录可以查看过去同步周期的成功或失败状态。 例如，网关管理员可能已更新一组过期的数据库凭据。 如以下屏幕截图所示，刷新历史记录显示受影响的刷新何时再次开始工作。
可以在语义模型设置中找到显示刷新历史记录的链接。 也可以使用
Power BI REST API
以编程方式检索刷新历史记录。 通过使用自定义解决方案，可以集中监视多个语义模型的刷新历史记录。
自动页面刷新
自动页面刷新针对报表页面执行，使用此功能，报表作者可以为页面中仅在使用页面时处于活动状态的视觉对象设置刷新间隔。 自动页面刷新仅适用于 DirectQuery 数据源。 最小刷新间隔取决于要在其中发布报表的工作区的类型，以及 Premium 工作区和
嵌入工作区
的容量管理设置。
有关自动页面刷新的详细信息，请参阅
自动页面刷新
一文。
语义模型刷新历史记录
Power BI 语义模型的刷新尝试可能并非总是顺畅进行，或者可能需要比预期更长的时间。 可以使用“
刷新历史记录
”页来帮助诊断刷新可能未按预期发生的原因。
如果语义模型刷新失败，Power BI 会自动多次尝试刷新语义模型。 不深入了解刷新的历史活动时，可能看起来只是刷新花费的时间比预期要长。 使用“
刷新历史记录
”页时，可以查看这些失败的尝试，并深入了解失败的原因。
以下屏幕截图显示了失败的刷新，其中包含 Power BI 每次自动尝试成功完成刷新的详细信息。
还可以查看 Power BI 在先前几次尝试失败后成功，如下图所示，该图显示 Power BI 仅在先前失败三次后就成功了。 请注意，成功的数据刷新和查询缓存具有相同的索引号，表示它们均在第四次尝试时成功。
可以选择失败旁边的“
显示
”链接，以获取失败的刷新尝试相关的详细信息，它有助于排查问题。
此外，每个 Power BI 刷新尝试分为两个操作：
数据
- 将数据加载到语义模型中
查询缓存
–高级查询缓存和/或仪表板磁贴刷新
下图显示了
刷新历史记录
如何分隔这些操作，并提供有关每个操作的信息。
大量使用仪表板磁贴或高级缓存可能会延长刷新持续时间，因为这两个操作都会在每次刷新后将许多查询排队。 可以减少仪表板数或
禁用自动缓存刷新
设置，以帮助减少查询数。
数据和查询缓存阶段彼此独立，但按顺序运行。 首先运行数据刷新，成功后，运行查询缓存刷新。 如果数据刷新失败，则不会启动查询刷新。 有可能数据刷新成功运行了，但查询缓存刷新失败。
使用
XMLA 终结点
进行的刷新不会在“刷新历史记录”
窗口中显示尝试详细信息。
如果要在高峰时间段停止刷新大型语义模型，则停止语义模型刷新非常有用。 使用刷新取消功能停止刷新驻留在
Premium
、
Premium Per User (PPU)
或
Power BI Embedded
容量上的语义模型。
若要取消语义模型刷新，你必须是语义模型工作区的参与者、成员或管理员。 语义模型刷新取消仅适用于使用
导入模式
或
复合模式
的语义模型。
不支持作为数据市场的一部分创建的语义模型。
若要开始刷新，请转到要刷新的语义模型，然后选择“立即刷新”
。
若要停止刷新，请执行以下步骤：
转到正在刷新的语义模型，然后选择“取消刷新”
。
在“取消刷新”弹出窗口中，选择“是”。
若要确保报表和仪表板使用当前数据，定期检查语义模型的刷新历史记录是可采用的最重要的最佳做法之一。 一旦发现问题，请及时解决，并在必要时跟进数据源所有者和网关管理员。
此外，请考虑以下建议，以便为语义模型建立和维护可靠的数据刷新过程：
将刷新安排在较空闲的时间进行，特别是当语义模型位于 Power BI Premium 上时。 如果在更宽的时间范围内分配语义模型的刷新周期，则可以帮助避开可能过度占用可用资源的高峰时间段。 延迟启动刷新周期意味着资源过载。 如果高级容量耗尽，Power BI 甚至有可能跳过刷新周期。
记住刷新限制。 如果源数据频繁更改或数据量很大，并且源中增加的负载以及对查询性能的影响是可接受的，则考虑使用 DirectQuery/LiveConnect 模式而不是导入模式。 避免持续刷新导入模式语义模型。 但是，如
在 Power BI Desktop 中使用 DirectQuery
所述，DirectQuery/LiveConnect 模式存在一些限制，例如返回数据的行数限制为一百万行，运行查询的响应时间限制为 225 秒。 这些限制可能会导致你仍然使用导入模式。 对于大数据量，请考虑使用
Power BI 中的聚合
。
确保语义模型刷新时间不超过最大刷新持续时间。 使用 Power BI Desktop 检查刷新持续时间。 如果需要刷新 2 小时以上，请考虑将语义模型移至 Power BI Premium。 语义模型可能无法在共享容量上刷新。 另请考虑对大于 1 GB 或刷新时间长达几小时的语义模型使用
增量刷新
。
优化语义模型以仅包括报表和仪表板使用的表和列。 优化糅合查询，如有可能，避免使用动态数据源定义和高成本的 DAX 计算。 特别是避免使用测试表中每一行的 DAX 函数，因为这种函数的内存消耗和处理开销非常高。
应用与 Power BI Desktop 中相同的隐私设置，确保 Power BI 可以生成有效的源查询。 记住，Power BI Desktop 不会发布隐私设置。 发布语义模型后，必须手动重新应用数据源定义中的设置。
限制仪表板上视觉对象的数量，尤其是在使用
行级别安全性 (RLS)
时。 如本文前面所述，过多的仪表板磁贴会显著增加刷新持续时间。
使用可靠的企业数据网关部署将语义模型连接到本地数据源。 如果发现与网关相关的刷新故障（例如网关不可用或过载），请让网关管理员向现有群集添加其他网关或部署新群集（纵向扩展与横向扩展），直至问题得到解决。
为导入语义模型和 DirectQuery/LiveConnect 语义模型使用不同的数据网关，这样计划刷新期间的数据导入就不会影响基于 DirectQuery/LiveConnect 语义模型（通过每次用户交互查询数据源）的报表和仪表板的性能。
确保 Power BI 可以向你的邮箱发送刷新失败通知。 垃圾邮件筛选器可能会阻止电子邮件或将其移至你可能不会立即注意到的单独文件夹中。
配置计划刷新
用于解决刷新问题的工具
刷新方案故障排除
更多问题？
尝试咨询 Power BI 社区
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：
https://aka.ms/ContentUserFeedback
。
提交和查看相关反馈
