Как расследовать плавающие ошибки Databricks SQL warehouse без бесконечных ретраев: statement ID, query history, scheduling time, warehouse events и безопасный пакет для поддержки.
Сведите клиентский лог к одной временной шкале
Для двух неудачных и двух успешных запусков одного и того же задания сохраните UTC-время, client или dbt invocation, warehouse, statement ID, SQLSTATE, текст ошибки и номер попытки. SQL и параметры могут содержать данные, поэтому вместо них используйте хэш нормализованного запроса. Не делайте вывод по одному сообщению: Invalid OperationHandle может проявляться на этапе получения статуса или результата, а Query could not be scheduled относится к другой границе. Нужна последовательность событий вокруг одного ID.
Проверьте Query History
Azure Databricks Query History показывает статус, пользователя, compute, источник, длительность, I/O и подробности выполнения для доступных запросов. Найдите statement ID или узкое окно времени и сравните Failed, Cancelled, Queued и Finished. Если клиент сообщил ошибку, а запрос завершился, исследуйте сессию и получение результата; если записи нет, проверяйте соединение и права просмотра; если есть Failed, сохраняйте внутренний код. Не перезапускайте warehouse до экспорта этой картины.
Отделите очередь от выполнения и fetch
На вкладке Monitoring видны running и queued queries, cluster count и query history. Разложите общую длительность на scheduling, running и result fetching. Серия ошибок при росте очереди указывает на управление ёмкостью или доступностью, но не доказывает нехватку размера; ошибка после Finished указывает на клиентскую сессию или fetch. Сравните один интервал с нормальным интервалом того же workload. Не смешивайте разные warehouses, регионы и клиентские версии в одну выборку.
Ограничьте ретраи и сохраните состояние
Повтор допустим для транзиентной ошибки, только если операция идемпотентна и клиент использует ограниченный exponential backoff. Задайте максимум попыток и общий timeout, после которых job завершается с сохранением IDs. Бесконечный retry маскирует длительность инцидента, увеличивает очередь и может повторить запись. Не меняйте одновременно concurrency, размер warehouse и версию клиента. Один обратимый эксперимент — тот же запрос через UI либо SQL client при неизменном warehouse — помогает локализовать client path.
Эскалируйте по коррелируемым идентификаторам
В пакет входят workspace region без полного ID, тип warehouse, UTC-интервал, statement IDs, статусы Query History, scheduling/running/fetch durations, cluster count, клиент и его версия, число ретраев и обезличенный хэш запроса. Секреты подключения, SQL-текст и email пользователей не нужны. Критерий остановки — повторяемая ошибка для нескольких IDs при нормальном client path либо внутренний код платформы. Тогда новые настройки workload не дадут доказательства и могут скрыть исходную последовательность.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 29 июля 2026 года по обезличенному сигналу Microsoft Q&A и официальной документации Azure Databricks; SQL-текст, пользователи и workspace ID не использовались.
Источники и проверка
- Microsoft Learn — Query History Azure Databricks проверено 2026-07-29
- Microsoft Learn — мониторинг SQL warehouse проверено 2026-07-29
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.