Наша компания недавно столкнулась с проблемой с нашей базой данных SQL Server, из-за которой у нас была высокая нагрузка, и некоторые сценарии мониторинга базы данных прервали ряд соединений.
Когда это произошло, некоторые из выполняемых транзакций не смогли завершить откат.
Они неоднократно заявляли, что откат был завершен на 0% при выполнении kill на pid.
После поиска в Интернете мы обнаружили людей, предлагающих перезапустить SQL Server. Это было нежелательно, так как это была производственная база данных. Мы также были обеспокоены тем, что перезапуск может привести к повреждению нашей базы данных, вынудив нас выполнять восстановление из резервных копий.
В конце концов мы перезапустили сервер, и все заработало нормально, без отката транзакций.
У меня вопрос:
Можно ли вообще предотвратить это? Если нет, есть ли способ узнать, безопасно ли перезапускать?
Прежде всего, чтобы ответить на ваш последний вопрос, можете ли вы представить, что это не повторится снова, нет, на самом деле.
Произошло следующее: когда процессы были убиты, SQL Server сообщает клиенту, что процесс был убит. В некоторых случаях SQL Server зависает, пытаясь сообщить клиенту, что процесс был остановлен. Обычно это не проблема, но бывает несколько раз, когда она вызывает эту проблему.
Если вы оставите процессы запущенными, ничего не произойдет, кроме SPID, который находится в процессе. Откат фактически завершен. Единственный способ очистить SPID - перезапустить экземпляр SQL. При перезапуске экземпляра SQL, когда это произошло, вероятность повреждения равна нулю.
Все, что я могу сказать, это делать базовые вещи. Прежде всего знайте важность скрипта, который в данный момент работает на сервере. Сложные сценарии, которые потребляют слишком много памяти и могут вызывать потерю данных, ДОЛЖНЫ выполнить процедуру резервного копирования перед запуском сценария. Предположим, сценарий из тысячи строк запланирован для запуска без присмотра, технически разработчики, разработавшие сценарий, должны быть посоветованы включить автоматическое дифференциальное резервное копирование в свои сценарии, чтобы в случае сбоя сценария сначала была обеспечена хотя бы надежная резервная копия.
Если в сценарии нет автоматической процедуры резервного копирования, то технический специалист должен нести ответственность за выполнение резервного копирования вручную в определенное запланированное время. Единственное, что необходимо учитывать, - это знать, когда сценарий начнет выполняться на сервере, чтобы база данных также знала, когда начинать процесс резервного копирования вручную. Одна из причин, по которой существует dba.