Проблема с gzip под Solaris при работе по cron

[RXL]

$ uname -a
SunOS orion 5.9 Generic_118558-09 sun4u sparc SUNW,Ultra-250

$ gzip --version
gzip 1.3
(1999-12-21)

По cron запускается shell-скрипт, выполняющий экспорт из базы Oracle и затем архивирующий дамп. По непонятной причине, время от времени, получившийся архив не распознается gzip-ом. Тот же исходный файл, сжатый с теми же (только -9) параметрами руками (под тем же пользователем), получается полноценным gzip-архивом.

Кто-нибудь сталкивался с таким поведением?

[RXL]

Вот кусок шеловского скрипта:

#!/sbin/sh

echo '(start) ' `date`

cd $HOME
. ./.profile
cd /u03/backup/exp/
MD=`date '+%m_%y'`
DD=`date '+%d_%m'`
mkdir -p $MD/$DD
cd $MD/$DD

exp user/pass@server owner=users_list log=export.log file=export.dmp  direct=y

echo '(export completed) ' `date`

gzip -9 export.dmp

echo '(dump archived) ' `date`

gzip -t export.dmp.gz

echo '(finish) ' `date`


Дальнейшие тесты показали, что gzip не виноват - bzip2 то же создает некоректный архив. Руками то же самое исполняется на ура и с gzip и с bzip2.

Значит дело в экспортере оракла.
Версия экспортера - Release 9.2.0.6.0

Размер дампа около 2.5ГБ, gz - 400МБ, bz2 - 300МБ.

[Sla]

с импортом-экспортом у оракла всегда была проблема, эт лучше тебе не сюда. на sql.ru там монстры захаживают

[RXL]

Sla, спасибо - роюсь, но что-то пока не вижу...

Логика подсказывает, что после завершения процесса exp в файл дампа продолжается запись.

[Sla]

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

[RXL]

Sla, логично. Я об том же подумал. С другой стороны, чтение из файла ничем не отличается чтением из stdin. Разве что размер заранее не известен.
Жаль только места на диске для экспериментов нет и сервер нагружен. Ночью он 2.5 часа упаковывает, а днем 3-4.

[Sla]

а зачем ты делаешь экспорт?
делай бекап инкрементный
а экспорт и импорт нужно делать только в крайних случаях (так меня учили; знаю что неправильно учили)
при переходе с одной версии на другую, для дефрагментации базы и т.д. А для хранения бекап

[RXL]

Sla, это заведено было не мной. Я то пока в оракле чайник...

[Sla]

Это дело надо ломать
я в оракле то же не очень того... но 4 года его поддержки, при условии полного сопротивления "опытного начальника", опыт хоть какой-то

[RXL]

bzip2: export.dmp.bz2: bad magic number (file not created by bzip2)

Забавное дело. Я тут помозговал немного... Если бы дамп был плохой (изменялся по ходу компресии), то выходной файл независим от него и должен иметь нормальный формат. Загадка...
Когда разберусь, непременно напишу из-за чего все было.

[Sla]

интересненько
а ты заголовок файла смотрел?
а если подождать после експорта минут 5?
и как я тебя понимаю, вся эта фигня делается ночью, раз в сутки остается только посочувствовать
смотри в сторону бекапа

[RXL]

Бекап то же выполняется, но раз в неделю.
Пробовал только добавлять sleep 60.

[RXL]

Проблема полностью решена - пауза на пол часа. За месяц ни одного сбоя.
Дурит значит exp.