Comments 8
Стоп. У вас программная ошибка, какой-то скрипт что-то запустил и подвис и/или вылетел уже, а вы вместо того, чтобы отправить алерт в мониторинг, тупо пришибаете все следы бага?
Энтерпрайзненько, ничего не скажешь…
Энтерпрайзненько, ничего не скажешь…
Для этого и существует архивная таблица-кто-то ночью что-то запулил и забыл. Система сама удалит эту транзакцию, а Вы утром посмотрите и дадите по рукам тому, кто это сделал. А так (без автоматизации решения данной проблемы)-уже до утра пользователи пострадают от того, что транзакция вызовет общую блокировку и запросы все встанут и Вас поднимут ночью и плюс в деньгах компания потеряет
Насчет забытых транзакций в SSMS при ошибках, давно привык всегда после открытия транзакции писать set xact_abort on. Не шумит визуально, как try/catch, а делает в общем-то то что и надо в большинстве случаев — как только ошибка, сразу откат транзакции.
Эмм. А что — в больших базах данных нет возможности сделать default timeout на транзакцию?
Типа, кому надо длинную транзакцию делать — пусть в явном виде указывает большой тайм-аут, а для обычных «зависших» транзакций система сама их пришибёт через какое-то время (конечно, с записью в лог этого славного деяния).
Да, есть такая настройка
Но по опыту скажу-это плохая настройка как и автосжатие, т к важный для бизнеса запрос может в редких случаях выполняться в разы дольше по разным причинам и тому виной не только возникшие проблемы в железе, а запрос должен в любом случае выполняться+ эта настройка не в буквальном смысле говорит сколько в сек должен выполняться запрос, а сколько оценит оптимизатор ещё до начала выполнения этого запроса, и часто оптимизатор ошибается из-за многих влияющих внешних факторов
Так что по осторожнее с этой настройкой
Но по опыту скажу-это плохая настройка как и автосжатие, т к важный для бизнеса запрос может в редких случаях выполняться в разы дольше по разным причинам и тому виной не только возникшие проблемы в железе, а запрос должен в любом случае выполняться+ эта настройка не в буквальном смысле говорит сколько в сек должен выполняться запрос, а сколько оценит оптимизатор ещё до начала выполнения этого запроса, и часто оптимизатор ошибается из-за многих влияющих внешних факторов
Так что по осторожнее с этой настройкой
Насчет настройки — да, я с вами согласен: любая настройка вносящая существенное изменение поведения системы довольна чувствительна.
По мне — так зависшие транзакции — это существенное неправильное поведение системы, оно не должно происходить в штатном режиме. Как раз настройка СУБД для «прибивания» такой ситуации позволит таки высвободить задействованные ресурсы, и продолжить работу системы. Однако нужно понимать, что произошел сбой — который желательно отработать на прикладном уровне.
Подход в статье предполагает отработку ситуации на прикладном уровне — да, это предпочтительнее. Просто это нужно реализовывать, а настроука СУБД может защитить от ситуации «из коробки», а «разгребание» последствий — дело DBA.
Конечно, дело вкуса что использовать. Я бы совместил — настроку в СУБД, и, по возможности, отработку зависания транзакций в прикладном решении (в админке?)
По мне — так зависшие транзакции — это существенное неправильное поведение системы, оно не должно происходить в штатном режиме. Как раз настройка СУБД для «прибивания» такой ситуации позволит таки высвободить задействованные ресурсы, и продолжить работу системы. Однако нужно понимать, что произошел сбой — который желательно отработать на прикладном уровне.
Подход в статье предполагает отработку ситуации на прикладном уровне — да, это предпочтительнее. Просто это нужно реализовывать, а настроука СУБД может защитить от ситуации «из коробки», а «разгребание» последствий — дело DBA.
Конечно, дело вкуса что использовать. Я бы совместил — настроку в СУБД, и, по возможности, отработку зависания транзакций в прикладном решении (в админке?)
Со временем, когда вся СУБД будет исследована, я обычно выставляю эту настройку, выставив значение в несколько раз больше, чем максимально выполняемая по времени транзакция
Но пока не полностью покрыта СУБД или условия часто меняются (взаимодействие с другими системами), порой даже не согласовав вносимые изменения с DBA, с этой настройкой нужно быть крайне осторожным
Но пока не полностью покрыта СУБД или условия часто меняются (взаимодействие с другими системами), порой даже не согласовав вносимые изменения с DBA, с этой настройкой нужно быть крайне осторожным
Sign up to leave a comment.
Автоматизация удаления забытых транзакций