Скуль 2000, лог базы разрастается по несколько гигов в день, открыл свойства базы, на вкладке Transaction log в поле maximum file size проставил пункт restrict file growth и написал ему 30 гигов. После этого на вкладке "options" проставил галочку Auto shrink. Когда размер лога подошел к 30 гигам скуль перестал пускать пользователей с сообщением по аглицки нехватает места, большой лог файл и т.п...

(0) А нафига вам вообще логи нужны? Разностые бэкапы делаете?

(0) сорри за тупизм, имеете в виду дифференцированные? Нет, не делаем, делаю раз в день полный бэкап и перекидываю его в надежное место...

(2) Ну и перевести тогда модель в Simple.

а модель то какая? full?

+2 я со скулем только начал работать, все сделал по статьям, описывающим переход с дбф на скл. Там было написано, делаем мдф, делаем лог. Не задумывался над тем, нужен он нам вообще или нет. Знающие люди рассказывали что в случае чего лог позволит восстановить базу по состоянию на любую временную точку, которую он "захватывает". Решили дать ему 30 гигов, в Книга знаний: Почему разрастается журнал транзакций - файл .LDF для MS-SQL я прочитал как делать авто шринк... В принципе если он не будет разрастаться, то пусть лучше будет...
(4) да, модель фулл
(3) simple это для одного юзера чтоли? Монопольный доступ? Кому он нужен?

(5) Может, стоит еще доку подчитать? Про монопольный доступ и модели, например? Да и про бэкапы - тоже.

если фулл - делайте job на шринк или в симпл переводите...

>>simple это для одного юзера чтоли?

симпл - модели востановления и single user - разные вещи

(7) о, спасибо, врубился... Если сделать симпл, то будет автоматически обрезаться, я правильно понимаю???

(8) он будет в меньшей степени использоваться + автоматически резаться на чекпоинтах

(8) Зафиксированные транзакции будут автоматически удаляться из лога. Обрезание файлов сиквел никогда добровольно не делает. Т.е. если мегатранзакцию запустите, лог всё равно раздует и размер не изменится, когда она зафиксируется. Просто место внутри лога освободится. Вообще странно. При полном бэкапе зафиксированные транзакции также должны вычищаться из лога. Т.е. при штатной нагрузке на базу (без мегареструктуризаций и перепроведений) лог не должен был постоянно расти.

Или вы бэкап не сиквельный делали, а выгрузку из конфигуратора?

(6) Вот я и прочитал:
Параметр Auto shrink
Если значение этого параметра установить TRUE, база данных и журнал транзакций будут автоматически уплотняться, что позволит сохранить место на жестком диске.
Марк Шпеник, Руководство администратора баз данных MICROSOFT SQL Server 2000

И нихрена не работает... Что я сделал не так?

(8)
Марк Шпеник, Руководство администратора баз данных MICROSOFT SQL Server 2000:
Simple. База данных может быть восстановлена до последнего резервного копирования, однако без журнала транзакций. Применять это значение параметра в коммерческих базах данных не рекомендуется, потому что он обеспечивает только самый низкий уровено защиты данных
Full. База данных может быть восстановлена на заданный момент времени, вплоть  до момента аварии. Это значение обеспечивает самый высокий уровень защиты данных

Сами - то каким пользуетесь?

(12) автошринк высвобождает место в журнале, не сокращая его размер

(12) Нафига тебе Full, если ты делаешь только "полный" бэкап? Ты почитай, в какой ситуации можно восстановить базу "на заданный момент времени".

(13) прикольно... а что ж делать для того, чтобы он уменьшал его размер?
(11) сиквельный, сиквельный...

(14) ладно, уговорили :) ставлю симпл)

(15) job нужен нормальный.

(17) вот что мне другой мозг дал: это оно?
backup log test_log with truncate_only
go
dbcc shrinkfile('test_log', truncateonly)
go

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

(18) Первая команда удаляет из журнала транзакций зафиксированные транзакции
Вторая - срезает свободное место в конце файла журнала транзакций.

(19) я окончательно запутался...
"(13) автошринк высвобождает место в журнале, не сокращая его размер"
"(19) Автошринк как раз обрезает файл, уменьшая размер"

(20) мне просто не хоцца писать код, задача ведь простецкая, я еще даже не знаю куда его в скуле писать, чтобы он выполнился... Думал можно галочками - переключателями настроить...

Короче ставлю симпл и врубаю авто шринк...

(21) "Короче ставлю симпл и врубаю авто шринк..." Вот и ладушки.
Если оставить Full плюс запуск джоба (18) перед полным бэкапом, то теоретически сможете восстановить базу на момент после сбоя, если умрёт mdf, а ldf выживет. И то шаманить придется. Штатно модель Full предполагает создание бэкапов журнала транзакций.

(22) а можете про джоб поподробней рассказать, так, что называется для общего развития? Или сцылочку кинуть на внятный ресурсик... Буду очень благодарен

http://www.sql.ru/forum/actualtopics.aspx?bid=1

(23) Не запаривайся с T-SQL.
Иди Management->Maintenance Plans
Там практически любой джоб первой необходимости можно мастером склепать методом научного тыка.

Блин, народ, после простановки simple и установки флага Auto Shrink лог стал весить 39 Мб... Не маловато - ли? То он 30 гигов весит, то 30 метров...

(26) нормально. Он скоро вырастет, и растишки не нужно

(26)то много , то мало  вас не поймешь. сколько надо метров? :-D

(28) :-D да жесть вообще, я сам в шоке)) сколько вешать в граммах )))))