База УТ на SQL 2005. Планы настроены: проверка, реиндексация, обновление статистики и т.п. В конце бэкапы (FULL, Differential, Transaction Log), и после них обрезка. Все делается ночью. Но лог транзакций не режется, хоть ты тресни. Как сегодняшний печальный итог, лог разросся до 70 Гигов (сама база чуть больше 8-и гигов). Как резать лог через планы? Руками через Tasks - Shrink обрезка делается, но каждый раз руками делать.......

ап

Поставь SIMPLE и не парься

(0) так а что пишет то? Почему не режется?

(2) Ни разу этого не делал, хотя мысли были. Всегда делал FULL режим. Чем грозит смена?

(3) Да черт его знает. Может, он, конечно, и режется, но совсем чуть-чуть. Т.е. я ручками его порезал. А он со временем все равно растет. Планы выполняются нормально.

(4) Когда для базы данных установлена SIMPLE модель, это говорит о том, что не будет никакой возможности восстановить изменения, сделанные в базе после предыдущего резервного копирования. Выполняются только полные резервные копирования.

(0) Ну, настрой через Execute T-SQL Statement Task.
Хотя, ежели бэкапы делаются и место не сильно критично, то повода беспокоиться нет. Шансы что лог еще больше будет расти - невелики. Понту его каждый раз резать, ежели после очередного перепроведения он опять раздуется. Можешь каждый час настроить бэкап журнала транзакции (более оперативно будет чиститься журнал транзакций в течении дня).
(4) При FULL можно делать бэкапы журнала транзакций, которые можно использовать для восстановления базы от последнего полного бэкапа. Плюс если база умерла, но есть полный бэкап и нерезанный журнал транзакций - можно данные полностью восстановить. При SIMPLE - зафиксированные транзакции автоматом вычищаются из журнала (при FULL - только при полном бэкапе и бэкапе журнала транзакций).

(6) Да ты прав, только забыл сказать что можно делать дифф. баккапы хоть каждый час.

(7) В том-то все и дело, что место критично. Примерно недели три назад лог был 18 гигов. А вчера бэкап не смог сделаться, поскольку места не хватило. А лог стал 70 гигов. Бэкапы хранятся 1 неделю.

(8) диф. бекап нельзя воостановить "на дату"

(8) А что за лог Differential? В SQL 2005 впервые увидел.

(7) + при диф-бэкапе журнал тоже чистится, конечно же.
(9) Ты что, бэкапы локально складируешь? Можно ж непосредственно на бэкап-сервер делать!

(7) >Можешь каждый час настроить бэкап журнала транзакции (более оперативно будет чиститься журнал транзакций в течении дня).

Вот хочу так сделать сегодня вечером.
Просто интересно. На SQL 2000 такого никогда не было. Настроил и забыл. А здесь что-то не так. Хотя делал помощником, пошагово.

(12) Ну да. Ночью делается выгрузка в dt на одном серваке и скулевские бэкапы на другом серваке. dt-шки хранятся 30 дней, бэкапы сулевые 1 неделю (как раз из-за больших размеров пришлось время уменьшить)

Даже вот с утра всех выгонял, делал FULL бэкап. Потом обрезку, но порезалось от 68 гигов только 5. На SQL 2000 тоже так было, что несколько раз делаешь бэкапы, прежде чем урежется до нормального размера. Но там хоть не рос так сильно. А тут...

Короче поясню (выскажу свои мысли) по поводу лога транзакций, ибо как мне кажется теоретиков здесь много, а на практике с большими базами мало кто работать и дать нужный совет не смогут:
При методе восстановления FULL, конечно откатиться назад на любую минуты состояния базы нет проблем, но:
1. А вам это насколько надо? Была ли у вас потребность откатиться на заданный час, минуту?
2. А выделенный объем винта под логи позволяет вам возможность FULL вести?

Ответив для себя на эти вопросы "НЕТ", я выбрал метод SIPLE, и проблем с хаотично растущими логами нет. Бакапы делаются каждую ночь, дифбакапы каждые четыре часа.

+(16) Т.е. не трудно догадаться, что откатиться я могу на любой день и час кратный четырем часам.. Удачи

(14) Т.е. сиквельные бэкапы на сиквельном серваке лежат? Ну и толку от них, ежели сервак ёкнется? А ежели ёкнется сервак где dt лежат - база целая останется (т.к. цел сиквельный сервак).
(15) А, так это другое. Журнал транзакций как и база - фрагментируются. Обрезка выполняет срез свободного места в конце. Т.е. если не повезло - может нифига и не срезаться, хотя внутри полно свободного места. Есть режим резки с дефрагментацией (намного дольше). Можешь попробовать его заюзать через скрипты. Если место нужно срочно, можно отсоединить базу, прибить лог и подключить базу с созданием нового лога.

(16) Нет, за все время работы не приходилось откатываться. Тьфу, тьфу, тьфу.... Базы были всякие. Самая большая 120 гигов (на 7.7 и SQL 2000). Проблем не было.
На винтах места достаточно, если бы логи не такие большие были бы. Для 1 месяца хранения хватит (баз несколько)

(18) Ну, я так критично вопрос не рассматриваю о накрывшемся железе.  :)  Но на всякий случай, и делаю бэкапы на двух серваках разными способами.

На сегодня мы пока решили много пользователей не пускать в базу, чтобы хоть дать остальным работать. А вечером буду че-то придумывать, чтобы максимально уменьшить размер лога.

(17) Всё хорошо, если это неторопливый бэк-офис с тремя пользователями. Сплошь и рядом за потерянные 4 часа плотной работы ...надцати пользователей - расстрел на месте. Не говоря уже о том, что ежели база распределенная - восстановить данные и их целостность еще сложнее.

(20) А каким образом выполняется дефрагментация? Может, из-за этого и не режется (или режется очень мало). Как-то ведь надо уменьшать. Постоянный рост лога - не хорошо. Может, в плане где-то это указать надо?

(21) Точно не подскажу. Books online читать надо.
Но в MSSQL 2000 при интерактивном шринке можно было выбрать между
- truncate free space from the end of the file
- compress pages and then truncate free space from the file
Если не ошибаюсь, за это отвечает параметр TRUNCATEONLY команды DBCC SHRINKFILE.
А планы без вариантов генерят скрипт с этим параметром.
Как я уже говорил, можно попробовать через Execute T-SQL Statement Task, где ручками прописать нужный скрипт.

(21) Дело в том, что рост лога не постоянный, а скачкообразный. Т.е. пока нагрузка на базу равномерная - лог не растет (если бэкапы делаются). Потом бац - серьезная реструктуризация или перепроведение, лог в 10 раз больше :) Обрезка поможет только до следующего аналогичного события.

(23) Да это понятно, что лог растет из-за каких-то действий. Но в течение рабочего дня это объяснимо, все ж работают. Но после бэкапа (да еще и ночью, когда никто не работает) лог не уменьшается хотя бы наполовину - это непонятно. Я бы даже был согласен, если бы он уменьшался хотя бы до размеров базы. Но больше самой базы почти в 10 раз - это перебор.

Буду думать, как от этого избавится.
Всем спасибо за участие.

(24) может регламентные задания и обмены?

(25) Обменов нет. Регламентные задания есть (типовые и парочка своих, которые делаются в нерабочее время).

По расписанию никакое не попадает на время шринка и т.п.?

(27)  Нет. Все бэкапы заканчиваются примерно к 4 утра. Задание запускается в 5.

хм - а если руками сделать шринк, а потом симтировать запуск задания и, соответвенно, посмотреть, а не задание ли случаем так над базой измывается?

(29) Вот вечером как раз и займусь. Это тоже буду пробовать. Надо сначала порезать по максимуму. Но вряд ли это из-за этого. Фактически только одно задание выполняется каждую ночь. Второе только в выходные. И все равно это не оно. Там не настолько действий, чтобы раздуть лог-файл до 70 Гигов. Да и раньше логи не настолько увеличивались, хотя задания давно делаются. Это вот буквально последние пару-тройку дней так.