Окружающая среда:
Каждую ночь мы делаем резервные копии нашей производственной системы, а затем восстанавливаем их на проблемном сервере. Резервные копии сжимаются. Все шло нормально, пока несколько недель назад мы не начали получать ошибки блокировки буфера (тип 2) в процессе восстановления. Они также сопровождаются сообщениями «запросы ввода-вывода, для выполнения которых требуется более 15 секунд». Эти сообщения находятся в разных базах данных.
Истекло время ожидания фиксации буфера - тип 2, ...
SQL Server обнаружил 4 вхождения запросов ввода-вывода, выполнение которых длилось более 15 секунд в файле [{myPath} \ ReportServer.mdf] ...
Подавляющее большинство проблем с защелкой буфера сообщается в [ReportServer] или [ReportServerTempDB], но некоторые из них связаны с [tempdb].
Я создал билет с нашими сотрудниками службы поддержки Azure, которые сообщили, что и наш диск журнала, и виртуальная машина регулируются из-за ограничений пропускной способности, и именно поэтому мы видим эти сообщения.
Что меня смущает, так это то, почему это внезапно начало происходить, почему SQL внезапно попытался протолкнуть больше данных во время восстановления, чем он ранее заставлял Azure снижать скорость. Наши базы данных не так сильно увеличиваются в размерах, поскольку у нас есть архивирование для наших более активных таблиц, и мы восстанавливаем базы данных по одной. К сожалению, у нас нет механизма отслеживания для отслеживания использования пространства файлов журналов и данных.
За 3 недели до начала изменений в виртуальную машину или SQL Server не было внесено никаких изменений, включая установку обновлений.
ВОПРОС:
Я знаю, что иногда производительность SQL-запроса может «упасть» даже при малейшем изменении набора данных, который он потребляет, но возможны ли такие же вещи для ввода-вывода? Может быть, небольшой рост подтолкнул сервер к тому моменту, когда он пытается протолкнуть больше данных, чем при предыдущих операциях восстановления?
Вещи, которые я пробовал:
!! РЕДАКТИРОВАТЬ:
В качестве дополнительной информации, все наши файлы журналов имеют не менее 90% свободного места, а наши файлы данных имеют не менее 25% свободного места, поскольку мы увеличиваем их заранее, чтобы минимизировать события автоматического роста. Поэтому, когда я подумал, что, возможно, виновником может быть рост объемов данных, я не был так уверен сейчас. Размер файлов, которые восстанавливал этот процесс, был бы неизменным в течение нескольких лет.
Учитывая тот факт, что у нас нет истории использования файла SQL с течением времени, я могу только предположить, что мы пересекли некоторую черту в отношении потребления файлового пространства, которая заставляет SQL пытаться протолкнуть больше данных, чем было раньше. Это не твердый ответ, но все, что я чувствую, каждый может предложить с учетом нашей ситуации.