Может ли большой журнал транзакций привести к увеличению скорости процессора

Question

У меня есть клиент с очень большой базой данных на Sql Server 2005. Общее пространство, выделенное для БД, составляет 15 ГБ с примерно 5 ГБ для БД и 10 ГБ для журнала транзакций. Совсем недавно истекло время ожидания для веб-приложения, которое подключается к этой базе данных.

Я проследил действия на веб-странице и изучил запросы, которые выполняются во время выполнения этих веб-операций. В плане выполнения нет ничего плохого.

Сам запрос использовал несколько объединений, но завершается очень быстро. Тем не менее, процессор БД сервера поднимается до 100% в течение нескольких секунд. Эта проблема возникает, когда в системе работают несколько пользователей одновременно (когда я говорю «несколько». Прочтите о 5). При этом тайм-ауты начинают происходить.

Полагаю, мой вопрос: может ли большой журнал транзакций вызвать проблемы с производительностью процессора? Сейчас на диске около 12 ГБ свободного места. Конфигурация немного не в моих руках, но база данных и журнал находятся на одном физическом диске.

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

Большое спасибо,

Answer 1

Трудно сказать точно, учитывая отсутствие данных, но всплески обычно наблюдаются на контрольной точке журнала транзакций.

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

Это включает в себя множество I/O, включая CPU операций, и может быть причиной CPU всплесков активности.

Обычно, контрольная точка возникает, когда журнал транзакций70% заполнен или когда SQL Server решает, что процедура восстановления (повторного применения журнала) займет больше времени, чем 1 минута.

Answer 2

Ваш первый приоритет должен быть адрес журнала транзакций размером .Правильно ли выполняется резервное копирование БД и как часто.Решите эти проблемы, а затем посмотрите, исчезнут ли пики ЦП.CHECKPOINT - это процесс чтения журнала транзакций и применения изменений к файлу БД. Если журнал транзакций ОГРОМНЫЙ, то имеет смысл, что это может повлиять на него?

Answer 3

Хотя я не удивлюсь, если бревно такого размера не вызовет проблемы, есть и другие вещи, которые могут быть такими же. Статистика была обновлена ​​в последнее время? Происходят ли всплески, когда выполняется какое-то автоматизированное задание, есть ли четкая временная диаграмма, когда у вас есть всплески, а затем посмотрите, что еще выполняется? Загружали ли вы новую версию чего-либо на сервер в то время, когда всплески начали происходить?

В любом случае журнал транзакций должен быть исправлен. Причина, по которой он настолько велик, заключается в том, что оно не резервируется (или резервируется недостаточно часто). Недостаточно сделать резервную копию базы данных, вы также должны сделать резервную копию журнала. Мы копируем наши каждые 15 минут, но наша система требует высокой транзакции, и мы не можем позволить себе потерять данные.

Answer 4

Вы можете попытаться расширить авторасширение: Кимберли Трипп предлагает более 500 МБ для автозаписей транзакций, измеряемых в ГБ:

http://www.sqlskills.com/blogs/kimberly/post/8-Steps-to-better-Transaction-Log-throughput.aspx

(см. Пункт 7)