Устранение неполадок подключения конечной точки XMLA
Конечные точки XMLA в Power BI используют собственный протокол связи Служб Analysis Services для доступа к семантической модели Power BI. Из-за этого устранение неполадок конечной точки XMLA совпадает с устранением неполадок с типичным подключением служб Analysis Services. Однако некоторые различия между зависимостями, зависящими от Power BI, применяются.
Подготовка к работе
Прежде чем устранять неполадки с сценарием конечной точки XMLA, ознакомьтесь с основами подключения к семантической модели с конечной точкой XMLA. Наиболее распространенные варианты использования конечной точки XMLA рассматриваются здесь. Другие руководства по устранению неполадок Power BI, такие как устранение неполадок шлюзов — Power BI и анализ неполадок в Excel, также могут быть полезными.
Включение конечной точки XMLA
Конечная точка XMLA может быть включена в емкостях Power BI Premium, Premium на пользователя и Power BI Embedded. В небольших емкостях, таких как емкость A1 с размером всего 2,5 ГБ памяти, при попытке задать конечную точку XMLA для чтения и записи , а затем нажмите кнопку "Применить". Сообщение об ошибке "Возникла проблема с параметрами рабочей нагрузки. Повторите попытку в некоторое время.
Вот несколько вещей, которые нужно попробовать:
- Ограничьте потребление памяти других служб на емкости, например потоки данных, до 40 % или меньше, или отключите ненужную службу полностью.
- Обновите емкость до более крупного номера SKU. Например, обновление с A1 до емкости A3 решает эту проблему конфигурации, не отключая потоки данных.
Помните, что необходимо также включить параметр экспорта данных на уровне клиента на портале администрирования Power BI. Этот параметр также необходим для функции "Анализ в Excel".
Установка подключения клиента
После включения конечной точки XMLA рекомендуется проверить подключение к рабочей области в емкости. Дополнительные сведения см. в статье "Подключение к рабочей области Premium". Кроме того, обязательно ознакомьтесь с разделом "Требования к подключению" для полезных советов и сведений о текущих ограничениях подключения XMLA.
Подключение к субъекту-службе
Если вы включили параметры клиента, чтобы разрешить субъектам-службам использовать API Power BI, как описано в разделе "Включение субъектов-служб", вы можете подключиться к конечной точке XMLA с помощью субъекта-службы. Помните, что субъект-служба требует того же уровня разрешений доступа на уровне рабочей области или семантической модели, что и обычные пользователи.
Чтобы использовать субъект-службу, обязательно укажите сведения об удостоверениях приложения в строка подключения следующим образом:
Приложение идентификатора - пользователя:appid@tenantid
Пароль
cert:thumbprint (рекомендуется для безопасности)
Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=cert:<thumbprint>;Секрет приложения
Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=<secret>;
Если вы получите следующую ошибку:
"Невозможно подключиться к семантической модели из-за неполных сведений об учетной записи. Для субъектов-служб обязательно укажите идентификатор клиента вместе с идентификатором приложения с помощью формата app:<appId>@<tenantId>, а затем повторите попытку".
Убедитесь, что идентификатор клиента указан вместе с идентификатором приложения, используя правильный формат.
Также допустимо указать идентификатор приложения без идентификатора клиента. Однако в этом случае необходимо заменить myorg псевдоним в URL-адресе источника данных фактическим идентификатором клиента. Затем Power BI может найти субъект-службу в правильном клиенте. Но, как рекомендуется, используйте myorg псевдоним и укажите идентификатор клиента вместе с идентификатором приложения в параметре идентификатора пользователя.
Подключение с помощью Microsoft Entra B2B
С поддержкой Microsoft Entra business-to-business (B2B) в Power BI можно предоставить внешним гостевым пользователям доступ к семантической модели через конечную точку XMLA. Убедитесь, что на портале администрирования Power BI включен параметр общего доступа к содержимому с внешними пользователями . Дополнительные сведения см. в статье Распространение содержимого Power BI внешним гостевым пользователям с помощью Microsoft Entra B2B.
Развертывание семантической модели
Проект табличной модели можно развернуть в Visual Studio (SSDT) в рабочей области, назначенной емкости Premium, так же, как и ресурс сервера в Службах Azure Analysis Services. Однако при развертывании существуют некоторые дополнительные рекомендации. Обязательно просмотрите раздел "Развертывание проектов модели из Visual Studio (SSDT) в семантической модели подключения к конечной точке XMLA.
Развертывание новой модели
В конфигурации по умолчанию Visual Studio пытается обработать модель в рамках операции развертывания, чтобы загрузить данные в семантику модели из источников данных. Как описано в разделе "Развертывание проектов модели из Visual Studio (SSDT)", эта операция может завершиться ошибкой, так как учетные данные источника данных не могут быть указаны в рамках операции развертывания. Вместо этого, если учетные данные для источника данных еще не определены для существующих семантических моделей, необходимо указать учетные данные источника данных в параметрах семантической модели с помощью пользовательского интерфейса Power BI (учетные данные семантических моделей>параметров>источника данных редактируют учетные данные).> Определив учетные данные источника данных, Power BI может автоматически применить учетные данные к этому источнику данных для любой новой семантической модели после успешного развертывания метаданных и создания семантической модели.
Если Power BI не может привязать новую семантику к учетным данным источника данных, появится сообщение об ошибке "Не удается обработать базу данных. Причина: не удалось сохранить изменения на сервере с кодом ошибки "DMTS_DatasourceHasNoCredentialError", как показано ниже:
Чтобы избежать сбоя обработки, задайте параметры обработки параметров развертывания>не обрабатывать, как показано на следующем рисунке. Затем Visual Studio развертывает только метаданные. Затем можно настроить учетные данные источника данных и нажать кнопку "Обновить сейчас " для семантической модели в пользовательском интерфейсе Power BI.
Новый проект из существующей семантической модели
Создание нового табличного проекта в Visual Studio путем импорта метаданных из существующей семантической модели не поддерживается. Однако вы можете подключиться к семантической модели с помощью СРЕДЫ SQL Server Management Studio, создать скрипт метаданных и повторно использовать ее в других табличных проектах.
Перенос семантической модели в Power BI
Рекомендуется указать уровень совместимости 1500 (или более поздней) для табличных моделей. Этот уровень совместимости поддерживает большинство возможностей и типов источников данных. Более поздние уровни совместимости обратно совместимы с более ранними уровнями.
Поддерживаемые поставщики данных
На уровне совместимости 1500 Power BI поддерживает следующие типы источников данных:
- Источники данных поставщика (устаревшие версии с строка подключения в метаданных модели).
- Структурированные источники данных (представленные на уровне совместимости 1400).
- Встроенные объявления источников данных M (как power BI Desktop объявляет их).
Рекомендуется использовать структурированные источники данных, которые Visual Studio по умолчанию создает при переходе по потоку данных импорта. Однако если вы планируете перенести существующую модель в Power BI, использующую источник данных поставщика, убедитесь, что источник данных поставщика зависит от поддерживаемого поставщика данных. В частности, драйвер Microsoft OLE DB для SQL Server и любые сторонние драйверы ODBC. Для OLE DB Driver for SQL Server необходимо переключить определение источника данных на поставщик данных платформа .NET Framework для SQL Server. Для сторонних драйверов ODBC, которые могут быть недоступны в служба Power BI, необходимо переключиться на определение структурированного источника данных.
Также рекомендуется заменить устаревший драйвер Microsoft OLE DB для SQL Server (SQLNCLI11) в определениях источников данных SQL Server с помощью поставщика данных платформа .NET Framework для SQL Server.
В следующей таблице представлен пример поставщика данных платформа .NET Framework для SQL Server строка подключения замены соответствующего строка подключения драйвера OLE DB для SQL Server.
| Драйвер OLE DB для SQL Server | Поставщик данных .NET Framework для SQL Server |
|---|---|
Provider=SQLNCLI11;Data Source=sqldb.database.windows.net;Initial Catalog=AdventureWorksDW;Trusted_Connection=yes; |
Data Source=sqldb.database.windows.net;Initial Catalog=AdventureWorksDW2016;Integrated Security=SSPI;Encrypt=true;TrustServerCertificate=false |
Перекрестные ссылки на источники секций
Так же, как и несколько типов источников данных, существует также несколько типов источников секций, табличная модель может включать импорт данных в таблицу. В частности, секция может использовать источник секции запроса или источник секции M. Эти типы источников секций, в свою очередь, могут ссылаться на источники данных поставщика или структурированные источники данных. Хотя табличные модели в Службах Azure Analysis Services поддерживают перекрестную ссылку на эти различные типы источников данных и секционирования, Power BI применяет более строгие отношения. Источники секций запросов должны ссылаться на источники данных поставщика, а источники секций M должны ссылаться на структурированные источники данных. Другие сочетания не поддерживаются в Power BI. Если вы хотите перенести семантику перекрестной ссылки, в следующей таблице описаны поддерживаемые конфигурации:
| Источник данных | Источник секции | Комментарии | Поддерживается конечной точкой XMLA |
|---|---|---|---|
| Источник данных поставщика | Источник секции запроса | Подсистема AS использует стек подключения на основе патронов для доступа к источнику данных. | Да |
| Источник данных поставщика | Источник секции M | Подсистема AS преобразует источник данных поставщика в универсальный структурированный источник данных, а затем использует подсистему Mashup для импорта данных. | No |
| Структурированный источник данных | Источник секции запроса | Подсистема AS упаковывает собственный запрос в источник секции в выражение M, а затем использует подсистему Mashup для импорта данных. | No |
| Структурированный источник данных | Источник секции M | Подсистема AS использует подсистему Mashup для импорта данных. | Да |
Источники данных и олицетворение
Параметры олицетворения, которые можно определить для источников данных поставщика, не относятся к Power BI. Power BI использует другой механизм на основе параметров семантической модели для управления учетными данными источника данных. По этой причине при создании источника данных поставщика убедитесь, что выбрана учетная запись службы.
Детализированная обработка
При активации запланированного обновления или обновления по запросу в Power BI Power BI обычно обновляет всю семантику модели. Во многих случаях более эффективно выполнять обновления более выборочно. Вы можете выполнять детализированные задачи обработки в SQL Server Management Studio (SSMS), как показано ниже, или с помощью сторонних средств или сценариев.
Переопределяется в команде Refresh TMSL
Переопределения в команде обновления (TMSL) позволяют пользователям выбирать другое определение запроса секции или определение источника данных для операции обновления.
Подписки электронной почты
Семантические модели, обновляемые с помощью конечной точки XMLA, не активируют подписку электронной почты.
Ошибки в емкости Premium
Подключение к ошибке сервера в SSMS
При подключении к рабочей области Power BI с SQL Server Management Studio (SSMS) может появиться следующая ошибка:
TITLE: Connect to Server
------------------------------
Cannot connect to powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].
------------------------------
ADDITIONAL INFORMATION:
The remote server returned an error: (400) Bad Request.
Technical Details:
RootActivityId:
Date (UTC): 10/6/2021 1:03:25 AM (Microsoft.AnalysisServices.AdomdClient)
------------------------------
The remote server returned an error: (400) Bad Request. (System)
При подключении к рабочей области Power BI с помощью SSMS убедитесь в следующем:
- Параметр конечной точки XMLA включен для емкости клиента. Дополнительные сведения см. в разделе "Включить чтение и запись XMLA".
- Разрешить конечные точки XMLA и анализ в Excel с параметром локальных семантических моделей включен в параметрах клиента.
- Вы используете последнюю версию SSMS. Скачайте последнюю версию.
Выполнение запросов в SSMS
При подключении к рабочей области в Power BI Premium или емкости Power BI Embedded среда SQL Server Management Studio может отобразить следующую ошибку:
Executing the query ...
Error -1052311437: We had to move the session with ID '<Session ID>' to another Power BI Premium node. Moving the session temporarily interrupted this trace - tracing will resume automatically as soon as the session has been fully moved to the new node.
Это информационное сообщение, которое можно игнорировать в SSMS 18.8 и выше, так как клиентские библиотеки будут автоматически подключаться. Обратите внимание, что клиентские библиотеки, установленные с SSMS версии 18.7.1 или ниже, не поддерживают трассировку сеансов. Скачайте последнюю версию SSMS.
Выполнение большой команды с помощью конечной точки XMLA
При выполнении большой команды с помощью конечной точки XMLA может возникнуть следующая ошибка:
Executing the query ...
Error -1052311437:
The remote server returned an error: (400) Bad Request.
Technical Details:
RootActivityId: 3716c0f7-3d01-4595-8061-e6b2bd9f3428
Date (UTC): 11/13/2020 7:57:16 PM
Run complete
При использовании SSMS версии 18.7.1 или более поздней для выполнения длительной операции обновления (>1 мин) для семантической модели в емкости Power BI Premium или Power BI Embedded SSMS может отобразить эту ошибку, даже если операция обновления выполнена успешно. Это связано с известной проблемой в клиентских библиотеках, где состояние запроса обновления неправильно отслеживается. Это разрешено в SSMS 18.8 и более поздних версиях. Скачайте последнюю версию SSMS.
Эта ошибка также может возникать, когда очень большой запрос необходимо перенаправить на другой узел в кластере Premium. Часто это происходит при попытке создать или изменить семантику модели с помощью большого скрипта TMSL. В таких случаях ошибку обычно можно избежать, указав начальный каталог в имя базы данных перед выполнением команды.
При создании новой базы данных можно создать пустую семантику модели, например:
{
"create": {
"database": {
"name": "DatabaseName"
}
}
}
После создания новой семантической модели укажите начальный каталог и внесите изменения в семантику.
Другие клиентские приложения и инструменты
Клиентские приложения и средства, такие как Excel, Power BI Desktop, SSMS или внешние средства, подключающиеся к семантической модели в емкостях Power BI Premium, могут вызвать следующую ошибку: удаленный сервер вернул ошибку: (400) Bad Request.. Ошибка может быть вызвана особенно в том случае, если выполняется базовый запрос DAX или команда XMLA. Чтобы устранить потенциальные ошибки, обязательно используйте самые последние приложения и средства, устанавливающие последние версии клиентских библиотек служб Analysis Services с регулярными обновлениями. Независимо от приложения или средства, минимальные необходимые версии клиентской библиотеки для подключения и работы с семантических моделей в емкости Premium через конечную точку XMLA:
| Клиентская библиотека | Версия |
|---|---|
| MSOLAP | 15.1.65.22 |
| AMO | 19.12.7.0 |
| ADOMD | 19.12.7.0 |
Изменение членства в роли в SSMS
При использовании СРЕДЫ SQL Server Management Studio (SSMS) версии 18.8 для изменения членства в роли в семантической модели SSMS может отобразить следующую ошибку:
Failed to save modifications to the server.
Error returned: ‘Metadata change of current operation cannot be resolved, please check the command or try again later.’
Это связано с известной проблемой в REST API служб приложений. Это будет разрешено в предстоящем выпуске. В то же время, чтобы обойти эту ошибку, в свойствах роли нажмите кнопку "Скрипт", а затем введите и выполните следующую команду TMSL:
{
"createOrReplace": {
"object": {
"database": "AdventureWorks",
"role": "Role"
},
"role": {
"name": "Role",
"modelPermission": "read",
"members": [
{
"memberName": "xxxx",
"identityProvider": "AzureAD"
},
{
"memberName": “xxxx”
"identityProvider": "AzureAD"
}
]
}
}
}
Ошибка публикации — семантическая модель динамического подключения
При повторной публикации динамической семантической модели, используюющей соединитель Служб Analysis Services, следующая ошибка: "Существует существующая модель отчета или семантики с тем же именем. Удалите или переименуйте существующую семантику и повторите попытку". может отображаться.
Это связано с семантической моделью, имеющей другую строка подключения, но имя которой совпадает с существующей семантической моделью. Чтобы устранить эту проблему, удалите или переименуйте существующую семантику. Кроме того, не забудьте повторно опубликовать все приложения, зависящие от отчета. При необходимости подчиненные пользователи должны быть проинформированы об обновлении закладок с новым адресом отчета, чтобы убедиться, что они получают доступ к последнему отчету.
Не удается загрузить динамическую семантику динамической семантической модели
Пользователи, пытающиеся создать новую модель Live Connected или открыть существующую модель Live Connected с помощью версий Power BI Desktop за март 2024 г. или более поздней версии, могут столкнуться с ошибкой, аналогичной следующему: "Не удалось подключиться к модели в служба Power BI. Возможно, набор данных удален, переименован, перемещен или не имеет разрешения на доступ к нему".
Ошибка может возникать при настройке прокси-сервера в среде пользователя, а прокси-сервер запрещает доступ к служба Power BI. Начиная с версии Power BI Desktop за март 2024 г. среда пользователя должна разрешать подключения к служба Power BI в конечной точке *.pbidedicated.windows.net или соответствующие конечные точки служба Power BI для национальных облаков.
Чтобы проверить, является ли проблема результатом параметров прокси-сервера, попробуйте использовать соединитель СЛУЖБ SQL Server Analysis Services в Power BI Desktop или любое стороннее или стороннее внешнее средство, например SQL Server Management Studio, для подключения к любой рабочей области premium.
Дополнительные сведения о тестировании общего подключения XML/A см. в разделе об установке подключения клиента в этой статье.
Не удается открыть книгу Excel
Книга Excel может не открыться с ошибкой "Сбой инициализации источника данных. Проверьте сервер базы данных или обратитесь к администратору базы данных. Если книга содержит подключение к семантической модели Power BI, проверьте, содержит ли строка подключения свойство "Catalog Rebound=True". Если свойство найдено, удалите его, сохраните книгу и повторите попытку открыть ее.
Свойство "Catalog Rebound=True" автоматически добавляется поставщиком OLE DB служб Analysis Services (MSOLAP) в более новых версиях Excel, когда подключение к семантической модели Power BI оптимизировано поставщиком. Так как свойство сохраняется в книге, при открытии той же книги в Excel, которая использует старую версию поставщика, которая не поддерживает оптимизацию, Excel не сможет открыть книгу.
"Rebound" каталога предназначен только для внутреннего использования.
Псевдоним рабочей области и сервера
В отличие от Служб Azure Analysis Services псевдонимы имен сервера не поддерживаются для рабочих областей Premium.
DISCOVER_M_EXPRESSIONS
Представление управления данными (DMV) DISCOVER_M_EXPRESSIONS в настоящее время не поддерживается в Power BI с помощью конечной точки XMLA. Приложения могут использовать табличную объектную модель (TOM) для получения выражений M, используемых моделью данных.
Ограничение памяти команд управления ресурсами в категории "Премиум"
Емкости класса Premium используют управление ресурсами, чтобы гарантировать, что одна семантическая модель не может превышать объем доступных ресурсов памяти для емкости, определяемой номером SKU. Например, подписка P1 имеет эффективное ограничение памяти для каждого элемента в 25 ГБ, для подписки P2 ограничение составляет 50 ГБ, а для подписки P3 ограничение составляет 100 ГБ. Помимо размера семантической модели (базы данных), эффективное ограничение памяти также применяется к операциям базовой семантической модели, таким как Create, Alter и Refresh.
Эффективное ограничение памяти для команды основано на меньшем пределе памяти емкости (определяется номером SKU) или значением свойства DBpropMsmdRequestMemoryLimit XMLA.
Например, для емкости P1, если:
DbpropMsmdRequestMemoryLimit = 0 (или не указано), эффективное ограничение памяти для команды составляет 25 ГБ.
DbpropMsmdRequestMemoryLimit = 5 ГБ, эффективное ограничение памяти для команды составляет 5 ГБ.
DbpropMsmdRequestMemoryLimit = 50 ГБ, эффективное ограничение памяти для команды составляет 25 ГБ.
Как правило, эффективное ограничение памяти для команды вычисляется на памяти, разрешенной для семантической модели емкостью (25 ГБ, 50 ГБ, 100 ГБ) и объемом памяти, которую уже использует семантическая модель при запуске команды. Например, семантическая модель с использованием 12 ГБ емкости P1 позволяет использовать эффективное ограничение памяти для новой команды размером 13 ГБ. Однако эффективное ограничение памяти может быть дополнительно ограничено свойством DbPropMsmdRequestMemoryLimit XMLA, если при необходимости указано приложением. Используя предыдущий пример, если в свойстве DbPropMsmdRequestMemoryLimit указано 10 ГБ, то эффективное ограничение команды уменьшается до 10 ГБ.
Если операция команды пытается использовать больше памяти, чем разрешено ограничением, операция может завершиться ошибкой и возвращается ошибка. Например, следующая ошибка описывает эффективное ограничение памяти в 25 ГБ (емкость P1), так как семантическая модель уже потребила 12 ГБ (12288 МБ) при запуске команды, а для выполнения команды было применено эффективное ограничение в 13 ГБ (13312 МБ):
"Управление ресурсами: эта операция была отменена, так как не было достаточно памяти для завершения работы. Увеличьте память емкости Premium, в которой размещена эта семантическая модель, или уменьшите объем памяти для семантической модели, выполнив такие действия, как ограничение объема импортированных данных. Дополнительные сведения: потребляемая память 13312 МБ, ограничение памяти 13312 МБ, размер базы данных перед выполнением команды 12288 МБ. Дополнительные сведения: https://go.microsoft.com/fwlink/?linkid=2159753."
В некоторых случаях, как показано в следующей ошибке, "потребляемая память" составляет 0, но сумма, показанная для параметра "Размер базы данных перед выполнением команды", уже больше, чем эффективное ограничение памяти. Это означает, что операция не удалось начать выполнение, так как объем памяти, уже используемый семантической моделью, превышает предел памяти для SKU.
"Управление ресурсами: эта операция была отменена, так как не было достаточно памяти для завершения работы. Увеличьте память емкости Premium, в которой размещена эта семантическая модель, или уменьшите объем памяти для семантической модели, выполнив такие действия, как ограничение объема импортированных данных. Дополнительные сведения: потребляемая память 0 МБ, ограничение памяти 25600 МБ, размер базы данных до выполнения команды 26000 МБ. Дополнительные сведения: https://go.microsoft.com/fwlink/?linkid=2159753."
Чтобы избежать превышения эффективного ограничения памяти, выполните следующие действия.
- Обновление до более крупного размера емкости Premium (SKU) для семантической модели.
- Уменьшите объем памяти в семантической модели, ограничив объем данных, загруженных с каждым обновлением.
- Для операций обновления через конечную точку XMLA уменьшите количество секций, обрабатываемых параллельно. Слишком много секций, обрабатываемых параллельно с одной командой, может превышать эффективное ограничение памяти.