Компьютерный форум OSzone.net  

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)
-   Программирование и базы данных (http://forum.oszone.net/forumdisplay.php?f=21)
-   -   Уменьшение логов (http://forum.oszone.net/showthread.php?t=110317)

__sa__nya 30-06-2008 17:43 838611

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

Busla 30-06-2008 23:17 838862

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

whitedog 01-07-2008 23:48 839832

DBCC SHRINKFILE

__sa__nya 02-07-2008 16:45 840475

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

whitedog 02-07-2008 23:23 840928

Цитата:

Цитата __sa__nya
Busla, попробую, скажу.
whitedog, подробнее про данную команду можно? »

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

__sa__nya 04-07-2008 13:40 842163

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

whitedog 04-07-2008 20:58 842561

Цитата:

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

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

__sa__nya 12-07-2008 11:22 849495

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

im2002 21-07-2008 14:34 857558

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

Busla 21-07-2008 14:53 857574

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

im2002 21-07-2008 15:44 857622

Цитата:

Цитата Busla
im2002, плохой совет »

Поясни чем?!

Busla 21-07-2008 17:46 857719

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

__sa__nya 25-07-2008 08:45 860606

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

im2002 25-07-2008 10:06 860651

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

__sa__nya 25-07-2008 11:00 860691

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

Busla 26-07-2008 01:25 861280

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

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

Цитата whitedog
Recovery model - full? Смени на simple. »


__sa__nya 26-07-2008 09:32 861337

Цитата:

Цитата Busla
Цитата whitedog:
Recovery model - full? Смени на simple. »

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

Busla 26-07-2008 12:15 861400

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

__sa__nya 28-07-2008 08:52 862492

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

Delirium 28-07-2008 09:56 862525

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

__sa__nya 28-07-2008 10:15 862536

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

Delirium 29-07-2008 01:41 863232

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

zorg_pro 07-08-2008 02:58 869933

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


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

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

Busla 07-08-2008 12:10 870156

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

whitedog 08-08-2008 01:14 870787

Цитата:

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

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

zorg_pro 08-08-2008 01:39 870794

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

Busla 08-08-2008 16:36 871240

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

TywkaH4uk 22-10-2008 15:15 930560

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

DBCC SQLPERF(logspace)

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


Время: 07:46.

Время: 07:46.
© OSzone.net 2001-