Отправляет email-рассылки с помощью сервиса Sendsay

Открыто о СУБД Oracle на русском

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "СУБД Oracle "с нуля"" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Июль 2002   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Сергей

Статистика

10.773 подписчиков
-8 за неделю
←   Все выпуски   →

Открыто о СУБД Oracle на русском : Когда можно упаковывать архивные журналы


Информационный Канал Subscribe.Ru

Выпуск 8

Упаковка журналов

Уважаемые подписчики! Этот выпуск посвящен весьма интересному вопросу - какие журналы повторного выполнения можно упаковывать, удалять или копировать. На него сегодня ответил Том Кайт на сайте 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

Этот запрос, при выполнении, сгенерирует сценарий с соответствующими командами упаковки.

Обсуждение

Спасибо. Комментарий читателя 14 июля 2002 года

Удивительно, как подход может использоваться годами и быть при этом ошибочным.

Спасибо за помощь!!!

Комментарий В.К.

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

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

В следующем выпуске

Пока точно не знаю. Возможно, как и было обещано, - Том Кайт о мутирующих таблицах. Следите за новостями на сайте проекта Open Oracle.

С наилучшими пожеланиями,

  В.К.

http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное