Серьезная ошибка в Azure SQL DB с использованием вставки

Question

Я получаю серьезную ошибку во время оператора вставки в Azure sql db. Поэтому я не могу проверить журнал SQL Server. До прошлой недели я не получал эту ошибку, поэтому я восстановил БД с тех пор, но не повезло. У кого-нибудь есть идея или информация о том, как увидеть точную ошибку?

Полная ошибка: A severe error occurred on the current command. The results, if any, should be discarded.

INSERT INTO [Staging].[table] ([att1],[att2]) SELECT [att1], [att2] FROM [Staging].[vw_table]".

Возможные причины сбоя: проблемы с запросом, неправильно задано свойство \ "ResultSet \", неправильно заданы параметры или неправильно установлено соединение.

Answer 1

Ответ от Microsoft для всех, кому интересно:

Ниже приведены результаты нашего исследования.

• Мы заметили, что LOG% часто достигает 100%, что может вызвать ошибки, которые вы видите.
• Стандартные базы данных уровня производительности имеют меньше операций ввода-вывода, чем Premium Edition. базы данных уровня производительности.
• Поскольку эта рабочая нагрузка достигает максимума журнала Оцените для Standard S3 / S4, рекомендуется использовать Premium. я мог бы Предлагаем попробовать уровень обслуживания P1 / P2 и поделиться с нами результатами.

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

Answer 2

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

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

SELECT *
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;

Если вы видите, что avg_log_write_percent близок или равен 100%, вам нужно увеличить уровень базы данных. Вы можете рассмотреть возможность масштабирования до премиальных уровней перед запуском процессов ETL, которые используют премиальное хранилище. Уменьшите, когда процесс ETL завершится.

А как насчет графика DTU на портале? Пожалуйста, убедитесь, что потребление ресурсов достигает предела при появлении ошибок.

Один из способов управления дросселированием и высоким использованием DTU - выполнять вставки с использованием пакетов, как объяснено здесь .