Поделиться через


Устранение неполадок подключения конечной точки 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, Power BI 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 для 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 для импорта данных. Нет
Структурированный источник данных Источник раздела запроса Подсистема AS упаковывает собственный запрос по источнику разделов в выражение M, а затем использует механизм Mashup для импорта данных. Нет
Структурированный источник данных Источник раздела M Подсистема AS использует подсистему Mashup для импорта данных. Да

Источники данных и олицетворение

Параметры олицетворения, которые можно определить для источников данных поставщика, не применимы к Power BI. Power BI использует другой механизм на основе параметров семантической модели для управления учетными данными источника данных. По этой причине при создании источника данных поставщика убедитесь, что выбрана учетная запись службы.

Олицетворение учетной записи службы

Детализированная обработка

При активации запланированного обновления или обновления по запросу в Power BI Power BI обычно обновляет всю семантику модели. Во многих случаях более эффективно выполнять обновления более выборочно. Вы можете выполнять детализированные задачи обработки в SQL Server Management Studio (SSMS), как показано ниже, или с помощью сторонних средств или сценариев.

Обработка таблиц в 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 убедитесь в следующем:

Выполнение запросов в 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
АМО 19.12.7.0
ADOMD 19.12.7.0

Изменение членств в ролях в SSMS

При использовании SQL Server Management Studio (SSMS) v18.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, следующая ошибка: "Существует существующая модель отчета или семантики с тем же именем. Удалите или переименуйте существующую семантику и повторите попытку". может отображаться.

Не удалось опубликовать в Power BI из-за ошибки.

Это связано с тем, что публикуемая семантическая модель имеет другую строку подключения, но то же имя, что и существующая семантическая модель. Чтобы устранить эту проблему, удалите или переименуйте существующую семантику. Кроме того, не забудьте повторно опубликовать все приложения, зависящие от отчета. При необходимости подчиненные пользователи должны быть проинформированы об обновлении закладок с новым адресом отчета, чтобы убедиться, что они получают доступ к последнему отчету.

Не удается загрузить связанную семантическую модель.

Пользователи, пытающиеся создать новую модель 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, для подключения к любой рабочей области премиум.

Для получения более подробной информации о тестировании общего подключения 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_ВЫРАЖЕНИЯ

Представление управления данными (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 уменьшите количество секций, обрабатываемых параллельно. Слишком много секций, обрабатываемых параллельно с одной командой, может превышать эффективное ограничение памяти.