Уменьшение логов
 

Доброе время суток. Есть Microsoft SQL Server 2000, на нем некоторые логи разраслись сильно. Как их уменьшить, не повредив целостность базы? - Еще раз уточню, нужно не ограничить размер их разрастания, а уменьшить уже существующий, обрезать что ли.

[решено] Обрезаем файл транзакций логов... оно?

DBCC SHRINKFILE

Busla, попробую, скажу.
whitedog, подробнее про данную команду можно?

Можно - http://msdn.microsoft.com/en-us/library/ms189493.aspx или BOL почитай. Гугль тоже вроде не в дауне. :-)

Пробовал урезать логи DBCC SHRINKFILE, и просто командной 'shrink' из контекстного меню, но лог как был одного размера, так и остался.

Recovery model - full? Смени на simple.

Все, получилось, всем спасибо. Тему можно закрыть.

отсоедини базу/базы с большими логами от сервера либо запустив соотв. хранимую процедуру либо dettach из Интерпрайз манагера. удали большие *.ldf-файлы. Подцепи к серверу базы по новой, ldf-ы создадуться сами и будут маленькие. Подрубай либо хранимой процедурой либо attach из Интерпрайз манагера.

im2002, плохой совет

Поясни чем?!

im2002, потому что вместо того, чтобы найти первопричину и нормально настроить, предлагается сломать и понадеяться, что оно само восстановит недостающие файлы и так каждый месяц

Еще такой вопрос. Логи на нужных базах я урезал пару недель назад. В свойствах указанной БД я задал размер лога транзакций, и отключил опции "автоматически увеличивать файл транзаций". Вчера появилась. следующая ошибка. Человек работал с 1С, которая как раз и хранит базу в SQL'е. Он внес в базу изменения, захотел их применить - вышла ошибка, (с его слов) в которой говорилось о том, что изменения применить невозможно, т.к. transaction log данной базы полный. Проблема была решена тем, что размер лога он увеличил еще на 500 МБ. Но я думаю что это временное решение и не совсем правильное. Объясните пожалуйста, почему SQL заругался на логи базы. Ведь как я понимаю (на основании того, что прочел в книге по SQL) - если у файла логов фиксированный размер, а в этот файл нужно еще что-либо записать, sql убирает из файла самые старые данные и вносит новые (требуемые) - т.е он автоматически подчищает в файле место, необходимое для внесения новых данных, удаляя при этом старые. - Тогда почему так получилось, или я что-то не так понял? Как можно устранить проблему? SQL Server 2000.

Да логи и должны расти а как они растут это СУБД решает. Я бы не советовал ставить в настройках базы ограничения на размер ldf-файла потому как закончиться это тем что база рухнет в суспект или ещё куда, запаришься вытягивать потом. У меня mdf~10Гб, ldf~7Гб и никакие шаманские пляски мне не помогли... долго описывать просто всё что я пытался делать... Поэтому делаю так: раз в неделю отсоединяю БД, удаляю ldf, подсоединяю БД по новой. И то это только из-за того чтоб размеры бэкапов логов уменьшить. Это правильные размеры файлов у нас так 60 филиалов работает у всех ldf 70-80% от mdf. Настрой минтранс план и не парься удаляй логи смело, за несколько дней они нарастут опять и от этого никуда не денешься. СКУЛЬ сам считает какие транзакции завершены а какие нет и почему он сразу не отсекает завершённые (т.е. уже записанные в БД) тоже объяснить можно.

im2002, спасибо за совет, но может кто-нибудь ответит мне на мой вопрос?

im2002, о чём я и говорил ;)

__sa__nya, склоняюсь к уже озвученному:

- Busla, подробнее можно, как это сделать?

__sa__nya, это свойства (параметры) базы данных - как называется соответствующая вкладка в enterprise manager я не помню. Но их там немного.

А в чем вообще различие Recovery model simple/full? НА что это влияет?

На возможности отката после сбоя системы. Recovery model - модель восстановления. В случае simple транзакция сразу подтверждается и не логгируется, т.е. восстановление будет довольно проблематичным из логов. Но я все равно ставлю simple всегда и просто делаю несколько ежедневных бекапов (простой, инкрементный и т.п.). И проще и удобней.

Еще вопрос - сейсас recovery model full, когда сменю на simple - целостность базы не нарушится. - т. е. меня интересует, это не критичное изменение по отношению к БД? Потом не будет такого что БД рухнет? (естественно менять свойства буду только после того, как выгоню всех пользователей из нужных БД, отключу локалку).

__sa__nya, никаких изменений в целостности не произойдет, сделай бекап, поменяй модель на simple и можешь просто переименовать ldf файл, SQL создаст новый.

я для уменьшения логов использую вот этот скрипт в квэри анализере


USE *database*
GO
BACKUP LOG *database* WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE ( 2 )

естессно вместо *database* пишу ту базу которая мне нужна, и после этого лог весит 1 метр

zorg_pro, типичное решение через задний проход

Ну почему же? Вполне себе легитимный подход, в случае когда вместо стандартного maintenance plan пишется бэкап-скрипт. Все зависит от задачи.

Busla, ну подскажи тогда лучше...

maintenance plan тут не при чём. Просто нет смысла вести лог, если его так варварски обрезать.

на самом деле в случае полной модели восстановления достаточно просто регулярно бэкапить журнал транзакций вместе с полным бэкапом базы, в этом случае файл журнала не будет постоянно увеличиваться и можно будет пользоваться всеми благами полной модели восстановления =) Только важно понимать, что при полной модели восстановления в Полный бэкап базы не входит бэкап журнала транзакций... В момент бэкапа журнала транзакций, он очищается. Убедиться в этом можно посмотрев параметр "Процентное заполнение журнала транзакций" до и после бэкапа журнала

DBCC SQLPERF(logspace)

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