Уважаемые подписчики! Этот выпуск посвящен весьма интересному вопросу - какие журналы повторного выполнения можно упаковывать, удалять или копировать. На него сегодня ответил Том Кайт на сайте asktom.oracle.com. Давно обещанные комментарии к сценарию, с помощью которого Том получает такие красивые приглашения в SQL*Plus - в одном из следующих выпусков.
Прошу прощения за большой перерыв между выпусками. Две недели непрерывного чтения курсов по Solaris и Informix закончились, и ближайшие две недели я буду заниматься исключительно СУБД Oracle. Соответственно, выпуски рассылки будут выходить с обещанной регулярностью.
Привет, Том!
Периодически мне надо упаковывать архивные файлы журнала, чтобы освободить место.
Мой сценарий сжимает все файлы, кроме последнего (с максимальным последовательным
номером). Я предполагаю, что процесс ARCH может еще работать с последним
журналом, но уже наверняка завершил работу со всеми предыдущими.
Теперь я услышал, что это предположение может оказаться неверным.
Так когда же будет безопасно упаковывать архивные файлы журнала?
Заранее благодарен,
Алан
Необходимо проверять в словаре данных, завершена ли работа с файлом (Те, кто сказал, что ваш подход может оказаться "небезопасным" - правы. Может работать несколько процессов ARCH, каждый из которых записывает в свой файл).
Необходимо выполнить запрос к представлению v$archived_log, чтобы убедиться, что работа с этим файлом действительно завершена (см. значение в столбце archived).
Я обычно генерирую сценарий, запрашивающий представления v$ после чтения каталога архивных файлов и определяющий, какие из них безопасно упаковывать:
#!/bin/ksh
export DUPLEX_LOC=/arch2/oradata/ora8i/arch
echo set heading off > /tmp/$$.sql
echo set feedback off >> /tmp/$$.sql
echo set linesize 200 >> /tmp/$$.sql
echo set trimspool on >> /tmp/$$.sql
echo column cmd format a70 >> /tmp/$$.sql
echo spool /tmp/$$.sh >> /tmp/$$.sql
echo select "'/opt/gnu/bin/gzip -v ' || name ||' ; cp -p '||name||'.gz
$DUPLEX_LOC ' " >> /tmp/$$.sql
echo 'from sys.v_$archived_log' >> /tmp/$$.sql
echo 'where name in(' >> /tmp/$$.sql
ls /arch1/oradata/ora8i/arch/*.log | sed "s/^/'/;s/"'$'"/',/" >> /tmp/$$.sql
echo 'NULL ) and sequence# not in ' >> /tmp/$$.sql
echo '( select sequence# from v$log where archived = '"'NO'"')' >> /tmp/$$.sql
echo '/' >> /tmp/$$.sql
echo spool off >> /tmp/$$.sql
echo exit >> /tmp/$$.sql
Не забудьте изменить команду ls, конечно. Этот сценарий просто генерирует сценарий SQL*Plus -- выполните его и разберитесь, что он делает (поймите как он работает, прежде чем выполнять).
Если вы работаете не в ОС UNIX (мне вас жаль), придется изменить этот сценарий, сделав из него "bat-файл". Прнинцип понятен -- я динамически генерирую запрос следующего вида:
set heading off set feedback off set linesize 200 set trimspool on column cmd format a70 spool /tmp/21513.sh select '/opt/gnu/bin/gzip -v ' || name ||' ; cp -p '||name||'.gz ' from sys.v_$archived_log where name in( '/arch1/oradata/ora8i/arch/redo_1_18504.log', ... тут идут другие файлы ... '/arch1/oradata/ora8i/arch/redo_1_18707.log.gz', NULL ) and sequence# not in ( select sequence# from v$log where archived = 'NO') / spool off exit
Этот запрос, при выполнении, сгенерирует сценарий с соответствующими командами упаковки.
Удивительно, как подход может использоваться годами и быть при этом ошибочным.
Спасибо за помощь!!!
Могу только присоединиться к предыдущему комментарию. Я и сам в конце прошлого года советовал авторам "хитрых" сценариев обработки архивных журналов: чтобы не затронуть активный журнал, "брать все журналы, кроме последнего по времени", или "кроме последних нескольких, на всякий случай"... Какая наивность - только сервер точно знает, какие журналы действительно архивные и уже не изменяются!
Оригинал обсуждения этого вопроса можно найти здесь.
Пока точно не знаю. Возможно, как и было обещано, - Том Кайт о мутирующих таблицах. Следите за новостями на сайте проекта Open Oracle.
С наилучшими пожеланиями,
В.К.
|
|