Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Шринкование лог файла  [new]
Slon747
Member

Откуда:
Сообщений: 422
MSSQL 2005
Recovery model: Full
Backup: Full + transaction
Ночью после полного бекапа шринкуется база.
Во время обеденного перерыва проходит оптимизация индексов, после чего сильно вырастает журнал транзакций (в полтора раза больше файла данных).
Бекапятся транзакции и проблематично их хранить несколько дней из-за их размера.
Попробовал урезать журнал после оптимизации:
use MyBase;
BACKUP LOG MyBase WITH TRUNCATE_ONLY
DBCC SHRINKFILE(MyBase_Log, 2)
Но после этого перестает рабоать transaction backup.
Значит ли это, что его никак нельзя обрезать среди дня, если после этого планируется и дальше бекапить транзакции?
23 окт 09, 17:07    [7831350]     Ответить | Цитировать Сообщить модератору
 Re: Шринкование лог файла  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36808
Я вот одного не понимаю - зачем обрезать файл лога, а потом его увеличивать постоянно? Типа сервер железный, ему пофиг?

Сообщение было отредактировано: 23 окт 09, 17:08
23 окт 09, 17:08    [7831362]     Ответить | Цитировать Сообщить модератору
 Re: Шринкование лог файла  [new]
Glory
Member

Откуда:
Сообщений: 104760
Разумеется перестал
Потому что BACKUP LOG MyBase WITH TRUNCATE_ONLY прерывает цепочку бэкапов лога
И нужно делать полный бэкап
О чем и сказано в хелпе

[ NO_LOG | TRUNCATE_ONLY ]
Under the simple recovery model, performing a checkpoint removes the inactive part of the log without making a backup copy. This truncates the log by discarding all but the active log. This option frees space, but risks possible data loss. After the log is truncated by using either NO_LOG or TRUNCATE_ONLY, the changes recorded in the truncated portion of the log are not recoverable until the next database backup. Therefore, for recovery purposes, after using either of these options, immediately execute BACKUP DATABASE to take a full or differential database backup.
23 окт 09, 17:10    [7831374]     Ответить | Цитировать Сообщить модератору
 Re: Шринкование лог файла  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
Бэкап лога транзакций выполняется только после полного бэкапа. Если Вы BACKUP LOG MyBase WITH TRUNCATE_ONLY, т.е. прерываете целостность цепочки бэкапов лога транзакций, Вам необходимо снова сделать полный бэкап и после этого уже бэкап лога транзакций
23 окт 09, 17:10    [7831375]     Ответить | Цитировать Сообщить модератору
 Re: Шринкование лог файла  [new]
Slon747
Member

Откуда:
Сообщений: 422
Ozerov
Бэкап лога транзакций выполняется только после полного бэкапа. Если Вы BACKUP LOG MyBase WITH TRUNCATE_ONLY, т.е. прерываете целостность цепочки бэкапов лога транзакций, Вам необходимо снова сделать полный бэкап и после этого уже бэкап лога транзакций


Спасибо. Я и раньше так считал.
Просто, из предыдущего поста я подумал, что можно если сначала забекапить лог, то обрезкак его уже не скажется на бекапах логов:).
Значит буду думать, как-бы правильнее настроить задания.
23 окт 09, 17:18    [7831431]     Ответить | Цитировать Сообщить модератору
 Re: Шринкование лог файла  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
Slon747
Ozerov
Бэкап лога транзакций выполняется только после полного бэкапа. Если Вы BACKUP LOG MyBase WITH TRUNCATE_ONLY, т.е. прерываете целостность цепочки бэкапов лога транзакций, Вам необходимо снова сделать полный бэкап и после этого уже бэкап лога транзакций


Спасибо. Я и раньше так считал.
Просто, из предыдущего поста я подумал, что можно если сначала забекапить лог, то обрезкак его уже не скажется на бекапах логов:).
Значит буду думать, как-бы правильнее настроить задания.

Ну во-первых реиндексацию лучше делать ночью, во-вторых надо посмотреть, действительно ли она нужна каждый день? В третьих, можно сделать ночью реиндекс, обрезать лог, сделать полный бэкап и далее бэкап лога.
23 окт 09, 17:34    [7831546]     Ответить | Цитировать Сообщить модератору
 Re: Шринкование лог файла  [new]
Slon747
Member

Откуда:
Сообщений: 422
Ozerov
Ну во-первых реиндексацию лучше делать ночью

Днем во время обеда у меня делается только реорганизация индексов ("Reorganize Index Task" из Maintenance Plans). Как я прочитал, в этом случае таблицы не блокируются. Хотя тормозит все равно сильно.

Ozerov
во-вторых надо посмотреть, действительно ли она нужна каждый день?
В процессе выяснения причин сильных тормозов на некоторых задачах, ночная переиндексация сильно помогает. А вот нужна ли дневная реорганизация - пока что не выяснил.
[quot Ozerov]В третьих, можно сделать ночью реиндекс, обрезать лог, сделать полный бэкап и далее бэкап лога.

У меня ночью именно так.
1. BACKUP LOG MyBase WITH TRUNCATE_ONLY
2. DBCC SHRINKFILE(MyBase_Log, 10)
3. EXEC sp_MSforeachtable N'DBCC DBREINDEX(''?'')'
23 окт 09, 17:45    [7831651]     Ответить | Цитировать Сообщить модератору
 Re: Шринкование лог файла  [new]
Slon747
Member

Откуда:
Сообщений: 422
Ozerov
во-вторых надо посмотреть, действительно ли она нужна каждый день?

В процессе выяснения причин сильных тормозов на некоторых задачах, ночная переиндексация сильно помогает. А вот нужна ли дневная реорганизация - пока что не выяснил.
23 окт 09, 17:47    [7831665]     Ответить | Цитировать Сообщить модератору
 Re: Шринкование лог файла  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
Slon747
Ozerov
во-вторых надо посмотреть, действительно ли она нужна каждый день?

В процессе выяснения причин сильных тормозов на некоторых задачах, ночная переиндексация сильно помогает. А вот нужна ли дневная реорганизация - пока что не выяснил.

Уберите и выясните. Я сильно сомневаюсь, что дневная реорганизация индексов Вам сильно полезна будет. Хотя всяко бывает и каждый случай индивидуален
23 окт 09, 17:57    [7831738]     Ответить | Цитировать Сообщить модератору
 Re: Шринкование лог файла  [new]
Excel
Member

Откуда: UA, Kiev
Сообщений: 119
лет 10 назад настроил ещё для 6.5, сейчас уже 2005, а план тот же - не тронут:

Вечером:

-- 1. Проверяем и перестраиваем:
exec master..xp_sqlmaint  '-S ServerName -D BaseName -CkDB -CkCat -RebldIdx 100'
-- Тут явный deprecated, думаю на что заменить.

-- Теперь имеем огромный и ненужный лог созданный реиндексацией
-- Следующим шагом обрезаем его не сохраняя.
-- Но после этого можно будет сделать только полный бекап базы


-- 2. Чистим и сжимаем (а зачем нам при поднятии бекапа огромный пустой файл лога):
CHECKPOINT
GO

BACKUP LOG dbname WITH TRUNCATE_ONLY
GO

-- Теперь жмем файл лога, ибо он тоже попадает в полный бекап
DBCC SHRINKFILE (db_log)

-- Теперь у нас проверенная, перестроенная база с махоньким логом. Но можно только ФулБэкап. Его и делаем

...


А утречком начинаем бекапить логи, и так до самого вечера.
11 ноя 09, 14:04    [7914035]     Ответить | Цитировать Сообщить модератору
 Касательно maintenance плана.  [new]
Excel
Member

Откуда: UA, Kiev
Сообщений: 119
При составлении планов, учтите, что согласно BOL:
Выполнение инструкции DBCC SHRINKFILE или DBCC SHRINKDATABASE может вызвать фрагментацию, если индекс частично или полностью перемещается во время операции сжатия. Следовательно, если необходимо выполнить операцию сжатия, она не должна выполняться после устранения фрагментации.



оффтоп на связанную тему:
ремарка по дефрагментации индексов
Перед выполнением дефрагментации индексов желательно выполнить дефрагментацию на уровне файловой системы. (Добавлю от себя - лучше это делать при остановленном SQL Server)

Тут же в конце статьи приведен весьма полезный скрипт для выборочной дефрагментации индексов, с дефрагментацией больше 10% и разными подходами для разных степеней фрагментированности.
14 дек 09, 16:07    [8064473]     Ответить | Цитировать Сообщить модератору
 Re: Шринкование лог файла  [new]
Excel
Member

Откуда: UA, Kiev
Сообщений: 119
Почему-то в русском переводе упомянутой выше статьи примера нет.
Но он есть в английской версии и в локальном BOL:
http://msdn.microsoft.com/en-us/library/ms188917.aspx

Сообщение было отредактировано: 14 дек 09, 17:04
14 дек 09, 16:15    [8064556]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить