![]() |
Уменьшение логов
Доброе время суток. Есть Microsoft SQL Server 2000, на нем некоторые логи разраслись сильно. Как их уменьшить, не повредив целостность базы? - Еще раз уточню, нужно не ограничить размер их разрастания, а уменьшить уже существующий, обрезать что ли.
|
|
DBCC SHRINKFILE
|
Busla, попробую, скажу.
whitedog, подробнее про данную команду можно? |
Цитата:
|
Пробовал урезать логи DBCC SHRINKFILE, и просто командной 'shrink' из контекстного меню, но лог как был одного размера, так и остался.
|
Цитата:
|
Все, получилось, всем спасибо. Тему можно закрыть.
|
отсоедини базу/базы с большими логами от сервера либо запустив соотв. хранимую процедуру либо 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, склоняюсь к уже озвученному: Цитата:
|
Цитата:
|
__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, типичное решение через задний проход
|
Цитата:
|
Busla, ну подскажи тогда лучше...
|
maintenance plan тут не при чём. Просто нет смысла вести лог, если его так варварски обрезать.
|
на самом деле в случае полной модели восстановления достаточно просто регулярно бэкапить журнал транзакций вместе с полным бэкапом базы, в этом случае файл журнала не будет постоянно увеличиваться и можно будет пользоваться всеми благами полной модели восстановления =) Только важно понимать, что при полной модели восстановления в Полный бэкап базы не входит бэкап журнала транзакций... В момент бэкапа журнала транзакций, он очищается. Убедиться в этом можно посмотрев параметр "Процентное заполнение журнала транзакций" до и после бэкапа журнала
DBCC SQLPERF(logspace) отсюда кстати можно понять какой размер дискового пространства необходимо выделить для журнала транзакций. |
Время: 07:46. |
Время: 07:46.
© OSzone.net 2001-