Галактика в вопросах и ответах

народ вот такая проблема..
Сервер:
ОС - 2003 SRV

2 CPU 3.2 GHz XEON
RAM - 4GB

Галактика 8.0 Объем БД - 35 Гиг (D_DICT -25Гиг)
Pervasive 8.70
проблема в следующем. надо почистить журнал..делаю как обычно.ставлю очистку журнала с такого то числа.. процесс заканчивается.. данные почистили . а размер журнала не уменьшается..
в чем причина.. ?? может как то вручную надо удалять.. . журнализацию останавливать нельзя..

А мы обычно, как размер журнала приближается к 2Г, так его архивируем и файл просто убиваем, а архив складываем в хорошее место. Получается очень быстро и экономно
Если нужно журнал восстановить, разворачиваем архив где-нибудь в тесте.

у меня в D-DICT лежит файл JOURNAL.ADF (размер чутьбольше 2х гигов)
, а есть есть файлы JOURNAL ^01,^02,^03 и т.д... зачем они нужны?

pervasive не умеет в автомате освобождать место из-под удаленных данных. Штатное средство это rebuild. Сюдя по наличию большого кол-ва файлов типа ^01 Вам проще выгрузить в dbf , удалить все journal.* и потом загрузить обратно. Наличие файлов ^01 вызвано тем что первасив до 9 версии не могет работать с файлами больше 2гиг, а в 9 нужно сконвертировать в формат 9 и поставить нужные галочки в контрольной панели. Вообще проще делать как s2176. Поищите на форуме - тема не раз обсуждалась.

дык. а 585 то делали.. и все было нормально...

При чистке журнала размер файла JOURNAL.ADF не должен уменьшаться!... Pervasive этим не занимается и не должен заниматься!... Он, как и любая СУБД, при удалении данных увеличивает кол-во свободных блоков в файле с данными, а если они заканчиваются увеличивает размер файла... UIN, как ты думаешь, если бы размер файла был динамическим насколько бы был фрагментирован диск?.. А если ты хочешь уменьшить размер файла см. пост edward_K...

Эта проблема уже не раз обсуждалась на форуме. Оптимально установить срок хранения журнала - 1 день и 23:55 копировать журнал в левую базу и оттуда выгружать в dbf этот dbf импортировать в месячный архив. Утром запускать до работы любой процесс , чтоб на нем сжимался журнал. Иначе первый входящий будет неприятно удивлен. Журнал все равно придется иногда сжимать после интенсивной работы и делать это быстрее первасивовским ребилдом поставив галочки не создавать системных ключей и версии - 7. После этой операции галактика получит у Вас поистине космическое ускорение Успехов

Все эти файлы journal.* - суть журнал....
Но нужен ли он такой огромный? Ведь поиск по нему становится слишком долгим...
Лучше заведите себе регламент: раз в месяц(неделю) журнал(все файлы journal.*) сносить влево, там его архивировать и "убирать на полочку". После удаления журнал начинает расти с 0.
Не надо ничего выгружать в dbf, зачем на это время тратить??? Если сильно надо в чем-то разобраться, взяли архив, развернули, подложили журнал в тестовую базу и ищите себе на здоровье.

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

А вы думаете, наши не косячат? Но если Вы всегда будете исправлять за них ошибки, они так и будут их ляпать, не задумываясь, зная, что все можно исправить чужими руками... Мы пару раз заставили исправить свои ошибки, так пользователи стали на порядок внимательнее.
И теперь журнал больше используем не для отката, а, так сказать, для расследования

s2176 писал(а):Все эти файлы journal.* - суть журнал....
Но нужен ли он такой огромный? Ведь поиск по нему становится слишком долгим...
Лучше заведите себе регламент: раз в месяц(неделю) журнал(все файлы journal.*) сносить влево, там его архивировать и "убирать на полочку". После удаления журнал начинает расти с 0.
Не надо ничего выгружать в dbf, зачем на это время тратить??? Если сильно надо в чем-то разобраться, взяли архив, развернули, подложили журнал в тестовую базу и ищите себе на здоровье.

По истечении 3 лет ничего не изменилось?
Выгоняем пользователей, выключаем журнализацию, переносим journal.*, включаем журнализацию, впускаем пользователей.

Далее все работает корректно и никаких ошибок не появляется?

сейчас еще появиласб фишка с архивом журнала. Можно настроить хоть и тяжко и на автоматический выгруз - получятся файлики по дням - одно плохо, что смотреть их лучше на другой базе, так как для просмотра приходится менять настройки, которые в свою очердь используются в выгрузке. можно и чего то свое попробовать - типа transcate табле сделать.

truncate x$journal лучше не делать, т.к. удаление записей в связанных таблицах (j$xxxx) производится через триггера, а при truncate они не отрабатывают.

а как лучше быстро и безболезненно почистить журнал на мсскл? журнал очень объемный...

ищите на форуме уже не раз обсуждалось - на mssql запускается скрипт. Журнал настраивается без ограничений, а дата резки определяется уже в скрипте.