Быстрый Рост размера базы

[SNG]

Кто сталкивался с быстрым ростом размера БД Аксапты? За месяц на 5 GB. Что можно предпринять?

[Vadik]

Цитата:

Изначально опубликовано SNG
Что можно предпринять?

Для начала - дать больше информации, тут ведь не телепаты и не ясновидящие..

Сервер БД? Версия аксапты? Включены ли множественные складские проводки? Какие таблицы растут быстрее всего? Работы по реиндексации/дефрагментации БД проводите?

А может быть, для Вашей БД 5 Гб в месяц - это нормально?

[Hobo]

скорее всего у вас sql
и нет ограничения на рост транзакшен лога?
разберитесь с администрированием скл -сервера - поможет
скрипт типа

backup log axdb with truncate_Only;
dbcc shrinkfile(AX30SP1Std_Log,64);

[SNG]

Да действительно sql и растет транзакшен лог. А если поставить ограничение роста лога или переодически выполнять скрипт backup log axdb with truncate_Only;
dbcc shrinkfile(AX30SP1Std_Log,64); проблем не будет?

[Hobo]

не будет - если вы один раз урежете этот транзакшен лог - и в Entrprise Meneger в свойсвах базы поставите ограничение на рост транзакшен лога - скажем 500 метров - или гиг.. этого достаточно (тратья закладка - крыжа - Restruct file grows (Mb)
и все бедет пучком.
почитаейте в лмитературе про транзакшен лог. незачем ему давать волю...

[Hobo]

да, в скрипте
backup log axdb with truncate_Only;
dbcc shrinkfile(AX30SP1Std_Log,64);

axdb - имя базы
AX30SP1Std_Log - имя File Name - посмотрите как у вас это называется.

[SNG]

Ок, спасибо за совет , поробовал на демо базе все получилось.

[Vadik]

Если Вы не делаете резервные копии лога, не парьтесь - выставьте recovery model simple, будьте проще

[Andrew Besedin]

Привет!
2Hobo: Совет ограничивать размер файла, на мой взгляд, ОЧЕНЬ вредный.

2SNG: Если ты используешь базу только как демо, то совет Vadik'а вполне нормальный. Но если есть требования к актуальности даных и скорости их восстановления, то тебе все же придется разбираться в стратегиях резервного копирования.

[Vadik]

Цитата:

Изначально опубликовано SNG
Да действительно sql и растет транзакшен лог. А если поставить ограничение роста лога или переодически выполнять скрипт backup log axdb with truncate_Only;
dbcc shrinkfile(AX30SP1Std_Log,64); проблем не будет?

будут, если конечно "The log file for database '%.*ls' is full" считать проблемой
причем не ЕСЛИ, а КОГДА - рано или поздно

Если используете recovery model, отличную от simple, и при этом не бэкапите transaction log, естестенно, он будет разрастаться до неприличных размеров. Бороться с этим бессмысленно.

2Hobo: опасные советы даете, между прочим

[Hobo]

А что в них опасного? При ограничении транзакшен лога - он начинает писаться "по кругу". вы считаете, что им необходимо будет откатываться назад более чем на неделю?
зачем жрать серверное пространство? легче бекапиться регулярно и катать на внешние носители бэкапы..
п если ктому же надо поднимать регулярно учебную базу на другой машине - еще и такие объемы гонять по сети? или я чего-то не понимаю?

[Андре]

Цитата:

Совет ограничивать размер файла, на мой взгляд, ОЧЕНЬ вредный.

Согласен. А то ограничат - а после такие вопросы возникают -

http://www.sql.ru/forum/actualtopics...E9%F2%E8&bid=1

Цитата:

Если Вы не делаете резервные копии лога, не парьтесь - выставьте recovery model simple, будьте проще

Не рекомендовал бы использовать на промышленной БД simple recovery mode. Также как и для Оракла режим NOARCHIVELOG. Если база данных работает в этих режимах - данные рано или поздно будут потеряны.
Использование RAID-5 не является оправданием использования данных режимов - сталкивался с тем, что по вине изготовителей все 5 дисков массива останавливались. Видел также и поврежденные аппаратным контроллером файлы данных.
Просто поймите, что база это самое ценное, что у Вас есть. Потеря данных -может поставить весь проект (и даже весь бизнес) под угрозу.

[Андре]

Цитата:

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

А Вы уверены, что не перетрете еще не забекапленную часть ? Точно ? А если кто-то пару раз запустит импорт данных ? Или еще какую либо операцию приводящую к множественному изменению данных.

Цитата:

зачем жрать серверное пространство?

Сколько стоит гигабайт серверного пространства ? Неужели Вы оцениваете Ваши данные дешевле ?

Цитата:

п если ктому же надо поднимать регулярно учебную базу на другой машине - еще и такие объемы гонять по сети?

А вот бэкапить можно с усечением журнала транзакций.

[Hobo]

Спасибо за информацию. Наверно задумаюсь...

[Lazy_Tiger]

Цитата:

Изначально опубликовано Hobo
Спасибо за информацию. Наверно задумаюсь...

эт точно... и начать думать нада с вдумчивого чтения BOL и стандартных курсов по администрированию SQL2000

P.S. если нету - могу дать