Устранение неполадок шлюзов — Power BI

Примечание.

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

В этой статье рассматриваются некоторые распространенные проблемы, которые могут возникнуть при использовании локального шлюза данных с Power BI. Если возникла проблема, которая не указана здесь, вы можете воспользоваться сайтом сообщества Power BI. Кроме того, вы можете создать запрос в службу поддержки.

Настройка

Ошибка: служба Power BI сообщили, что локальный шлюз недоступен. Перезапустите шлюз и повторите попытку.

В конце конфигурации служба Power BI снова вызывается для проверки шлюза. Служба Power BI не объявляет шлюз активным. Перезапуск службы Windows может позволить успешному обмену данными. Чтобы получить дополнительные сведения, вы можете собирать и просматривать журналы, как описано в разделе "Сбор журналов" из локального приложения шлюза данных.

Используйте собственный ретранслятор Azure

Шлюзы, испытывающие проблемы с подключением при использовании Bring Your Own Relay, должны убедиться, что Private Link не включен в ретрансляторе, так как эта конфигурация не поддерживается.

Источники данных

Примечание.

Не все источники данных содержат выделенные статьи о параметрах подключения или конфигурации. Для многих источников данных и соединителей, отличных от Майкрософт, параметры подключения могут отличаться между Power BI Desktop и конфигурациями управления подключениями и шлюзами в служба Power BI. В таких случаях предоставленные параметры по умолчанию — это поддерживаемые в настоящее время сценарии для Power BI.

Ошибка: не удается подключиться. Сведения: "Недопустимые учетные данные подключения"

В разделе "Показать сведения" отображается сообщение об ошибке, полученное из источника данных. Для SQL Server отображается следующее сообщение:

Login failed for user 'username'.

Убедитесь, что у вас есть правильное имя пользователя и пароль. Кроме того, убедитесь, что эти учетные данные могут успешно подключиться к источнику данных. Убедитесь, что используемая учетная запись соответствует методу проверки подлинности.

Ошибка: не удается подключиться. Сведения: "Не удается подключиться к базе данных"

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

В разделе "Показать сведения" отображается сообщение об ошибке, полученное из источника данных. Для SQL Server отображается следующее сообщение:

Cannot open database "AdventureWorks" requested by the login. The login failed. Login failed for user 'username'.

Ошибка: не удается подключиться. Сведения: "Неизвестная ошибка в шлюзе данных"

Эта ошибка может возникать по разным причинам. Убедитесь, что вы можете подключиться к источнику данных с компьютера, на котором размещен шлюз. Эта ситуация может быть результатом недоступности сервера.

В разделе "Показать сведения" можно увидеть код ошибки DM_GWPipeline_UnknownError.

Вы также можете просмотреть журналы событий журналы приложений и служб>локальной службы шлюза данных для получения дополнительной информации. Смотрите журналы событий для получения подробных сведений.

Ошибка: при попытке подключения к <серверу> возникла ошибка. Сведения: "Мы достигли шлюза данных, но шлюз не может получить доступ к локальному источнику данных".

Не удалось подключиться к указанному источнику данных. Обязательно проверьте сведения, предоставленные для этого источника данных.

В разделе "Показать сведения" можно просмотреть код ошибки DM_GWPipeline_Gateway_DataSourceAccessError.

Если базовое сообщение об ошибке аналогично приведенному ниже, это означает, что учетная запись, используемая для источника данных, не является администратором сервера для этого экземпляра служб Analysis Services. Дополнительные сведения см. в разделе Предоставление прав администратора сервера для экземпляра служб Analysis Services.

The 'CONTOSO\account' value of the 'EffectiveUserName' XML for Analysis property is not valid.

Если базовое сообщение об ошибке похоже на следующее, это может означать, что учетной записи службы Analysis Services может отсутствовать атрибут каталога Token-Groups-Global-And-Universal (TGGAU).

The username or password is incorrect.

Домены с доступом к совместимости до Windows 2000 включают атрибут TGGAU. Большинство только что созданных доменов не позволяют включить этот атрибут по умолчанию. Дополнительные сведения см. в разделе "Некоторые приложения и API-интерфейсы" требуют доступа к сведениям о авторизации для объектов учетной записи.

Чтобы проверить, включен ли атрибут, выполните следующие действия.

1. Подключитесь к серверу служб Analysis Services в SQL Server Management Studio. В свойствах расширенного подключения включите параметр EffectiveUserName для данного пользователя и убедитесь, что это изменение воспроизводит ошибку.

2. Вы можете использовать инструмент Active Directory dsacls для проверки, указан ли атрибут. Это средство находится на контроллере домена. Необходимо знать, каково уникальное доменное имя учетной записи, и передать это имя инструменту.

   dsacls "CN=John Doe,CN=UserAccounts,DC=contoso,DC=com"
   

   В результатах вы хотите увидеть что-то похожее на следующие выходные данные:

   Allow BUILTIN\Windows Authorization Access Group
                                   SPECIAL ACCESS for tokenGroupsGlobalAndUniversal
                                   READ PROPERTY
   

Чтобы устранить эту проблему, необходимо включить TGGAU в учетной записи, используемой для службы Windows Analysis Services.

Другая возможность для параметра "Имя пользователя или пароль неверны".

Эта ошибка также может быть вызвана, если сервер Служб Analysis Services находится в другом домене, чем пользователи, и нет двустороннего доверия.

Обратитесь к администраторам домена, чтобы проверить связь доверия между доменами.

Не удаётся увидеть источники данных шлюза данных в опыте получения данных для служб Analysis Services из сервиса Power BI

Убедитесь, что учетная запись указана на вкладке "Пользователи " источника данных в конфигурации шлюза. Если у вас нет доступа к шлюзу, обратитесь к администратору шлюза и попросите его проверить. Только учетные записи в списке "Пользователи" могут видеть источник данных, указанный в списке служб Analysis Services.

Ошибка. У вас нет шлюза, установленного или настроенного для источников данных в этом наборе данных.

Убедитесь, что вы добавили один или несколько источников данных в шлюз, как описано в разделе "Добавление источника данных". Если шлюз не отображается на портале администрирования в разделе "Управление подключениями и шлюзами", очистите кэш браузера или выйдите из службы, а затем войдите обратно.

Ошибка: Невозможно обновить источник данных, так как учетные данные недействительны. Измените свои учетные данные и повторите попытку.

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

Эта ошибка может возникать, когда шлюз пытается проверить подключение, даже если предоставленные учетные данные допустимы и операция обновления выполнена успешно. Это происходит из-за того, что при выполнении проверки подключения шлюз не включает необязательные параметры во время попытки подключения, а некоторые соединители данных (например, Snowflake) требуют необязательных параметров подключения для подключения.

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

Семантические модели

Ошибка. Недостаточно места для этой строки.

Эта ошибка возникает, если у вас есть одна строка размером более 4 МБ. Определите, какая строка принадлежит источнику данных, и попытайтесь её отфильтровать или уменьшить объём данных для этой строки.

Ошибка. Предоставленное имя сервера не соответствует имени сервера в SSL-сертификате SQL Server.

Эта ошибка может возникать, если общее имя сертификата предназначено для полного доменного имени сервера (FQDN), но вы предоставили только имя NetBIOS для сервера. Эта ситуация приводит к несоответствию параметров сертификата. Чтобы устранить эту проблему, укажите имя сервера в источнике данных шлюза и PBIX-файле, используя полное доменное имя сервера.

Ошибка. При настройке запланированного обновления локальный шлюз данных не отображается.

За эту ошибку может отвечать несколько различных сценариев:

• Имя сервера и базы данных не совпадает с введенным в Power BI Desktop и источником данных, настроенным для шлюза. Эти имена должны совпадать. Они не учитывают регистр.
• Учетная запись не указана на вкладке "Пользователи" источника данных в конфигурации шлюза. Вас должен добавить в этот список администратор шлюза.
• В файле Power BI Desktop есть несколько источников данных, а не все эти источники данных настроены с помощью шлюза. Необходимо определить каждый источник данных с шлюзом, чтобы шлюз отображался в запланированном обновлении.

Ошибка. Полученные несжатые данные на клиенте шлюза превысили ограничение.

Точное ограничение составляет 10 ГБ несжатых данных на таблицу. Если вы попадаете на эту проблему, есть хорошие варианты для оптимизации и предотвращения ее. В частности, уменьшите использование высококонстантных, длинных строковых значений и вместо этого используйте нормализованный ключ. Удаление столбца, если он не используется, помогает.

Ошибка: DM_GWPipeline_Gateway_SpooledOperationMissing

За эту ошибку может отвечать несколько различных сценариев:

• Процесс шлюза, возможно, перезагрузился во время обновления набора данных.
• Компьютер сервера шлюза клонируется на том устройстве, где выполняется шлюз. Клонировать компьютер шлюза не следует.

Отчеты

Ошибка: отчету не удалось получить доступ к источнику данных, поскольку у вас нет доступа через локальный шлюз данных.

Эта ошибка обычно вызвана одной из следующих причин:

• Сведения об источнике данных не соответствуют тому, что находится в базовом наборе данных. Имя сервера и базы данных должно совпадать между источником данных, определенным для локального шлюза данных, и тем, что вы предоставляете в Power BI Desktop. Если вы используете IP-адрес в Power BI Desktop, источник данных для локального шлюза данных также должен использовать IP-адрес.
• В вашей организации нет источника данных ни на одном шлюзе. Вы можете настроить источник данных в новом или существующем локальном шлюзе данных.

Ошибка: ошибка доступа к источнику данных. Обратитесь к администратору шлюза.

Если этот отчет использует динамическое подключение к службам Analysis Services, вы можете столкнуться с проблемой, связанной со значением, передаваемым в EffectiveUserName, которое либо является недопустимым, либо не имеет разрешений на сервере служб Analysis Services. Как правило, проблема с проверкой подлинности связана с тем, что значение, передаваемое для «EffectiveUserName», не соответствует локальному имени пользователя (UPN).

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

1. Найдите действительное имя пользователя в журналах шлюза.

2. После получения переданного значения убедитесь, что оно правильно. Если это ваш пользователь, вы можете использовать следующую команду в командной оболочке, чтобы просмотреть UPN. UPN выглядит как адрес электронной почты.

   whoami /upn
   

При желании, вы можете увидеть, что Power BI получает из Microsoft Entra ID.

1. Перейдите в https://developer.microsoft.com/graph/graph-explorer.

2. Выберите "Войти" в правом верхнем углу.

3. Выполните следующий запрос. Вы видите довольно большой ответ в формате JSON.

   https://graph.windows.net/me?api-version=1.5
   

4. Найдите userPrincipalName.

Если ваш Microsoft Entra UPN не соответствует локальному UPN Active Directory, можно использовать функцию "Отображение имен пользователей", чтобы заменить его допустимым значением. Вы можете обратиться либо к администратору Power BI, либо к локальному администратору Active Directory, чтобы изменить ваш UPN.

Kerberos

Если базовый сервер базы данных и локальный шлюз данных не настроены для ограниченного делегирования Kerberos, включите дополнительное ведение журнала на шлюзе. Затем исследуйте ошибки или следы в файлах журнала шлюза, используя их как отправную точку для устранения неполадок. Сведения о сборе журналов шлюза для просмотра см. в разделе "Сбор журналов" из локального приложения шлюза данных.

Уровень_имперсонификации

Уровень олицетворения связан с настройкой имени главного имени службы (SPN) или параметром локальной политики.

[DataMovement.PipeLine.GatewayDataAccess] About to impersonate user DOMAIN\User (IsAuthenticated: True, ImpersonationLevel: Identification)

Решение

Выполните следующие действия, чтобы устранить проблему.

1. Настройте SPN для локального шлюза.
2. Настройте ограниченное делегирование в Active Directory.

FailedToImpersonateUserException: не удалось создать удостоверение Windows для пользовательского ID пользователя

FailedToImpersonateUserException происходит, если вы не можете олицетворение от имени другого пользователя. Эта ошибка также может произойти, если учетная запись, которую вы пытаетесь олицетворить, принадлежит другому домену, чем домен службы шлюза. Это ограничение.

Решение

• Убедитесь, что конфигурация правильна в соответствии с шагами в предыдущем разделе "Уровень олицетворения".
• Убедитесь, что идентификатор пользователя, под видом которого осуществляется попытка, является действительным аккаунтом Active Directory.

Общая ошибка: ошибка 1033 при анализе протокола

Вы получаете ошибку 1033, если внешний идентификатор, настроенный в SAP HANA, не соответствует параметрам входа, когда пользователь олицетворяется с использованием UPN (alias@domain.com). В верхней части журналов ошибок отображается сообщение "Исходный UPN 'alias@domain.com' заменен новым UPN 'alias@domain.com'", как показано здесь:

[DM.GatewayCore] SingleSignOn Required. Original UPN 'alias@domain.com' replaced with new UPN 'alias@domain.com.'

Решение

• SAP HANA требует, чтобы олицетворенный пользователь использовал атрибут sAMAccountName (псевдоним пользователя) в Active Directory. Если этот атрибут не является правильным, отображается ошибка 1033.

  

• В журналах вы видите sAMAccountName (псевдоним), а не UPN, который представляет собой псевдоним, за которым следует домен (alias@domain.com).

  

      <setting name="ADUserNameReplacementProperty" serializeAs="String">
        <value>sAMAccount</value>
      </setting>
      <setting name="ADServerPath" serializeAs="String">
        <value />
      </setting>
      <setting name="CustomASDataSource" serializeAs="String">
        <value />
      </setting>
      <setting name="ADUserNameLookupProperty" serializeAs="String">
        <value>AADEmail</value>

[SAP AG][DLL LIBODBCHDB][HDBODBC] Сбой связи:-10709 Сбой подключения (RTE:[-1] Ошибка Kerberos. Серьезная ошибка: "Неопределенная ошибка [851968]". Мелкая ошибка: "В пакете безопасности недоступны учетные данные".

Вы получите сообщение об ошибке "-10709 Соединение не удалось", если ваше делегирование неправильно настроено в Active Directory.

Решение

• Убедитесь, что у вас есть сервер SAP HANA на вкладке "Делегирование" в Active Directory для учетной записи службы шлюза.

  

Экспорт журналов для запроса в службу поддержки

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

1. Определите кластер шлюза.

   Если вы являетесь владельцем набора данных, сначала проверьте имя кластера шлюза, связанное с набором данных. На следующем рисунке IgniteGateway — это кластер шлюза.

   

2. Проверьте свойства шлюза.

   Администратор шлюза должен проверить количество членов шлюза в кластере и включить балансировку нагрузки.

   Если балансировка нагрузки включена, шаг 3 должен повторяться для всех членов шлюза. Если он не включен, экспорт журналов в основном шлюзе достаточно.

3. Получение и экспорт журналов шлюза.

   Затем администратор шлюза, который также является администратором системы шлюза, должен выполнить следующие действия.

   a. Войдите на компьютер шлюза и запустите локальное приложение шлюза данных для входа в шлюз.

   b. Включите дополнительное ведение журнала.

   c. При необходимости можно включить функции мониторинга производительности и включить журналы производительности, чтобы предоставить дополнительные сведения об устранении неполадок.

   d. Запустите сценарий, для которого вы хотите записать журналы шлюза.

   д) Экспорт журналов шлюза.

История обновлений

При использовании шлюза для запланированного обновления журнал обновлений поможет узнать, какие ошибки произошли. Он также может предоставить полезные данные, если вам нужно создать запрос на поддержку. Вы можете просматривать запланированные и по запросу обновления. На следующих изображениях показано, как получить доступ к истории обновлений.

На странице сведений для семантической модели выберите «Обновить» на ленте, а затем выберите историю обновлений.

Вы также можете получить доступ к журналу обновлений из параметров семантической модели. Выберите "Файл " на ленте, а затем выберите "Параметры".

Дополнительные сведения об устранении неполадок в сценариях обновления см. в статье "Устранение неполадок в сценариях обновления".

Связанный контент

• Устранение неполадок с локальным шлюзом данных
• Настройка параметров прокси-сервера для локального шлюза данных
• Управление источниками данных SQL Server Analysis Services
• Управление источником данных — SAP HANA
• Управление источником данных SQL Server
• Управление источником данных — импорт и запланированное обновление

Есть еще вопросы? Попробуйте Сообщество Power BI.