Как убить / разрешить действительно продолжительное обновление в SQL Server

Question

Мой коллега (я обещаю , что это был коллега!) Оставил обновление, запущенное на нашем главном SQL Server, с прошлого четверга (да, это верно, ребята, сейчас у нас 100 часов!),Рассматриваемый SQL (в одну транзакцию, я мог бы добавить):

update daily_prices  set min_date = (select min(a.date)
   from daily_prices a       
   where a.key = daily_prices.key and       
   a.iid = daily_prices.iid)

(Да, я знаю, отвратительный ...)

Общая стоимость в плане запроса выходиткак 22186.7, предполагаемое количество строк для обновления составляет около 151 млн.

Нам, очевидно, нужно разрешить этот запрос тем или иным образом, мы понимаем, что если мы собираемся убить запрос, мы собираемся сгенерировать несколькожестокий откат, но мы не можем знать, как далеко он продвинулся.Единственное, что мы знаем, это запись из sys.dm_exec_requests:

session_id  status      query_text              cpu_time    total_elapsed_time  reads       writes      logical_reads
52          suspended   update daily_prices...  2328469     408947075           13831137    42458588    151809497

Итак, мой вопрос: какой наш лучший курс действий?

1. подождите
2. убить его и откатиться, и надеяться, что он откатится до следующего ледникового периода
3. что-нибудь еще?

Answer 1

Итак, нам надоело ждать завершения нашей транзакции (после полной недели один кусок SQL, который не будет?), и, как это мешало нашей резервной копии процесс, мы думали, что убийство было неизбежным злом.

База данных начала откат транзакции.

прошло 5 дней.

Мы заметили в некоторых постах в Интернете, что иногда какая-то магия произошло, когда база данных была перезапущена, и транзакция «ушла», хотя они обычно опровергаются *, и это не имеет смысла, мы думали, что нечего было терять, поэтому мы попробовали. Мы знали, что база данных войдет в режим восстановления, но база все равно становилась все более больной и не способной в любом случае, чтобы запустить что-либо, кроме текущей работы по откату, и мы увидели, что SQL Server неправильно работает с перегрузкой системных ресурсов и не отвлекает их туда, где он должен выполнять работу.

(* мы также знаем достаточно теории баз данных, чтобы знать, что БД не просто «забудет» о транзакции в процессе, но мы также видели дампы стека в Журналы ошибок SQL Server, которые говорят нам, что SQL Server получал все более раздражительный на сумму отката, который он должен был предпринять)

Итак, мы перезапустили базу данных.

Конечно, база данных перешла в режим восстановления. Тем не менее, журнал событий SQL Server теперь каждые 20 секунд давали нам обновления о том, как долго принять (в целом, около 25 часов от сообщений журнала, но в конечном итоге всего полтора часа (!)).

Буду ли этот метод восстановления / отката быстрее, я бы сильно сомневался (как я ожидаю SQL Server должен был выполнить тот же уровень работы, что и раньше, чтобы завершить транзакцию), однако он завершился в течение полутора часов, в любом случае, я не хочу заводить свою рабочую базу данных, когда она находится на полпути через откат). Сообщения об обновлениях в журнале событий были абсолютной находкой, как и любой, кто написал пакетную программу скажу тебе; какими бы неточными они ни оказались - по крайней мере, это был наихудший случай.

Поскольку у нас была роскошь быть единственными двумя людьми, использующими эту производственную коробку, выбирая отправить базу данных в режим восстановления работал для нас, и дал нам информационные сообщения, которые мы не было доступа только с нашим предыдущим состоянием отката (или, по крайней мере, ничего, что мы могли бы интерпретировать, учитывая наши недостающие навыки DBA). Я бы порекомендовал сделать это в будущем? .... Абсолютно нет, однако, надеюсь, что заинтересованные стороны извлекли урок, и мы можем попросить у платы немного денег для правильного сервера разработки! (эпический Джоэл-Тест провалился!)

Answer 2

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

С точки зрения восстановления некоторой управляющей / рабочей системы, если у вас есть подходящие резервные копии, выведите в оперативный режим другую базу данных для восстановлениярезервное копирование / резервное копирование, но вы не захотите восстанавливать после того, как транзакция была запущена (или ей все равно придется откатывать). Это, по крайней мере, дает вам систему, с которой вы могли бы продолжить работу с dev, но вряд ли это будетидеальная ситуация для системы prod.

Если это производственный сервер, попросите кого-нибудь любезно сказать о пригодности тестирования запросов и планов запросов до его выполнения.Я уверен, что многие администраторы могут предложить менее вежливые методы обучения:)