SQL 2005 история изменения рамера файла транзакционого лога

MaxiBek
Дата: 29.01.2009 12:33:53
Привет.

Коллеги нужно оценить динамику приращения размера файла транзакционного лога для принятия решения об оптимальном размере filegrowth для файла транзакционого лога. В логах SQL не удалось найти события очередного приращения размера файла. Подскажите плиз как можно получить такую историю?
tpg
Дата: 29.01.2009 12:42:33
Профилером.
MaxiBek
Дата: 29.01.2009 12:50:17
tpg,

Не очень интересный вариант, т.к. могу написать джоб который с нужной периодичностью будет присылать мне сообщение о текущем состоянии файлов транзакционных логов всех моих баз (а это 50 боевых баз). Я надеялся, что не знаю/просмотрел возможность найти эту информацию в логах SQL или может самой ОС, или может есть какая-нибудь недокументированная процедура по извлечению этой информации.
ars22
Дата: 29.01.2009 12:58:57
Можно посмотреть в стандартных отчетах. В SSMS на базе правый клик, Reports -> Standart Reports ->Disk USage

Там есть история изменения файлов БД. Возможно этой информации будет достаточно
DeColo®es
Дата: 29.01.2009 13:02:08
Создайте алерты, будут приходить сообщения о нехватке места.
alexeyvg
Дата: 29.01.2009 13:33:09
ars22
Можно посмотреть в стандартных отчетах. В SSMS на базе правый клик, Reports -> Standart Reports ->Disk USage

Там есть история изменения файлов БД. Возможно этой информации будет достаточно
+1
Кромо того, можно посмотреть стандартный отчёт бакапов.
MaxiBek
Дата: 29.01.2009 14:02:07
Стандартные отчеты не содержат требуемую инфу :-(

Что касается алертов, то это у меня и так реализовано. Смысл совершенно не в переполнении дисков.

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

Ок. Ладно похоже придется джобик набросать для контроля.
DeColo®es
Дата: 29.01.2009 16:33:21
Приращение файла должно иметь по-хорошему минимальные значения.
Ибо по-хорошему файлы вообще не должны расти в ходе обычного workflow.
Поддержание некоторого количества свободного места в файлах лога и данных - это задача обслуживания базы. То есть раз в день/неделю должен запускаться job, который проверяет, что в файлах достаточно места, чтобы вообще не возникло необходимости в авто-приращении вполь до следующего цикла обслуживания. И если места мало - сам job и должен увеличавать размер файлов.

С файлами логов проще - если в нерабочее время идет перестроение индексов а потом бэкап лога, то в логе проблемы с местом будет скорее всего не будет. :)
Idol_111
Дата: 30.01.2009 06:52:55
Используй это: DBCC LOGINFO. Динамику в принципе понять можно.
MaxiBek
Дата: 30.01.2009 15:24:46
Idol_111,

Да вы абсолютно правы, спасибо. Мне в Microsoft сразу ее порекомендовали.
Жаль, что относится к недокументированным - тогда бы сам нашел.