Устранение неполадок с хранилищем

  • Статья

Область применения:✅ хранилище в Microsoft Fabric

В этой статье приводятся рекомендации по устранению распространенных проблем в хранилище в Microsoft Fabric.

Временные ошибки подключения

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

  1. Проверьте состояние хранилища и убедитесь, что он не приостановлен.
  2. Не сразу повторяйте неудачную команду. Вместо этого дождитесь 5–10 минут, установите новое подключение, а затем повторите команду. Иногда система Azure быстро перемещает аппаратные ресурсы для улучшения балансировки нагрузки различных рабочих нагрузок. Большинство этих событий перенастройки завершаются менее чем за 60 секунд. В течение этого периода времени перенастройки могут возникнуть проблемы с подключением к базам данных. Подключение также может завершиться ошибкой при автоматическом перезапуске службы для устранения определенных проблем.
  3. Подключитесь с помощью другого приложения и (или) другого компьютера.

Сбой запроса из-за проблемы с пространством tempdb

Это tempdb системная база данных, используемая подсистемой для различных временных потребностей хранилища во время выполнения запроса. Доступ к нему или настройке пользователями не удается. Запросы могут завершиться ошибкой tempdb из-за нехватки места. Выполните следующие действия, чтобы сократить tempdb использование пространства:

  1. Ознакомьтесь со статьей о статистике, чтобы проверить правильность статистики столбцов, созданную во всех таблицах.
  2. Убедитесь, что все статистические данные таблицы обновляются после больших транзакций DML.
  3. Запросы с сложными joIN, GROUP BY и ORDER BY и ожидают возврата большого результирующий набор, используя больше tempdb места в выполнении. При возможности обновите запросы, чтобы уменьшить количество столбцов GROUP BY и ORDER BY.
  4. Повторно запустите запрос, если не выполняются другие активные запросы, чтобы избежать ограничения ресурсов во время выполнения запроса.

Производительность запросов, кажется, снижается с течением времени

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

  1. Определите различия во всех факторах, влияющих на производительность, среди хороших и плохих запусков производительности.
  2. Ознакомьтесь со статьей о статистике, чтобы проверить правильность статистики столбцов, созданную во всех таблицах.
  3. Убедитесь, что все статистические данные таблицы обновляются после больших транзакций DML.
  4. Проверьте отклонение данных в базовых таблицах.
  5. Приостановка и возобновление службы. Затем повторно запустите запрос при отсутствии других активных запросов. Вы можете отслеживать рабочую нагрузку хранилища с помощью dmV.

Запрос завершается сбоем после выполнения в течение длительного времени. Никакие данные не возвращаются клиенту.

Инструкция SELECT может успешно завершиться в серверной части и завершается ошибкой при попытке вернуть результирующий набор запроса клиенту. Выполните следующие действия, чтобы изолировать проблему:

  1. Используйте разные клиентские средства для повторного выполнения одного запроса.
    • SQL Server Management Studio (SSMS)
    • Azure Data Studio
    • Редактор sql-запросов на портале Microsoft Fabric
    • Редактор визуальных запросов на портале Microsoft Fabric
    • Служебная программа SQLCMD (для проверки подлинности с помощью идентификатора Microsoft Entra (ранее — Azure Active Directory) с MFA, используйте параметры -G -U)
  2. Если шаг 1 завершается ошибкой, выполните команду CTAS с неудачной инструкцией SELECT, чтобы отправить результат запроса SELECT в другую таблицу в том же хранилище. Использование CTAS позволяет избежать отправки результирующих наборов запросов обратно на клиентский компьютер. Если команда CTAS завершится успешно, а целевая таблица заполнена, то исходный сбой запроса, скорее всего, вызван проблемами внешнего интерфейса или клиента хранилища.

Что собирать перед обращением в службу поддержки Майкрософт

  • Укажите идентификатор рабочей области хранилища.
  • Укажите идентификатор оператора и идентификатор распределенного запроса. Они возвращаются в виде сообщений после завершения запроса или сбоя.
  • Укажите текст точного сообщения об ошибке.
  • Укажите время завершения или сбоя запроса.

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