Вы когда-нибудь сталкивались с ошибками в вашей базе данных SQL Server и задавались вопросом, что их вызвало? В этой статье мы рассмотрим реальный сценарий, в котором база данных столкнулась с ошибками и как они были устранены.

История начинается с серии ошибок в базе данных DB123 на SQL01. Одной из ошибок была ошибка “ужасного шоу”, которая предлагала восстановить базу данных или исправить ее. Однако, когда сервер был проверен, база данных была онлайн. Это вызвало вопрос: как база данных восстановилась самостоятельно?

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

Чтобы понять, что вызвало автоматическое увеличение размера, был использован запрос из трассировки по умолчанию для проверки событий автоматического увеличения размера. Было обнаружено, что автоматическое увеличение размера началось в определенное время и происходило от .NET-провайдера, исключая внутренние причины, такие как обслуживание индексов или статистики.

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

Оператором, вызывающим проблему, была операция DELETE на таблице с названием SecurityAction. В этой таблице было миллионы строк, и операция DELETE не удалась из-за нехватки места в журнале. Для решения этой проблемы был предложен пакетный подход к удалению, удаляя строки пакетами по 10 000, пока не останется строк, удовлетворяющих критериям.

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

Основные уроки, извлеченные из этого сценария:

1. Не выполняйте гигантские удаления без учета их влияния.
2. Ошибки “ужасного шоу” не всегда являются ужасным шоу – всегда полностью исследуйте!

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

Спасибо за чтение!