check RMAN-processes

Сегодня с утра одна из баз (10.2.0.3, HP-UX 11.11) оказалась остановленной. При попытке стартовать базу вылетели ошибки о нехватке места. df -k показал, что место в разделе /oracle, где лежит ORACLE_HOME было забито. Очень странно, при размере разделе в 10Гб и размере ORACLE_HOME до 4Гб. Я начал судорожно искать куда делось место через "du -k" по поддиректориям. Не найдя никаких новых файлов, заметил вчерашние нулевые логи бакапов архивлогов и один лог на текущее время. Просмотрел его через tail -f - лог постоянно пополнялся ошибками.
Посмотрел процессы rman - висело 2 процесса rman со вчерашнего вечера.
Убил их ... и место освободилось, почти 4Гб.
Т.е. какой-то процесс rman занимал все доступное место в разделе - очень странно.
Но надо иметь ввиду - либо отстреливать зависшие RMAN-процессы, либо надо переписать скрипты так чтобы логи падали в другой раздел. Возможно это поможет в таких случаях.

dbid в шаблоне %F

При восстановлении базы RMAN-ом необходимо установить DBID командой set dbid .
Дабы не искать его в логах лучше пользоваться шаблоном %F - при создании backup_set это первая последовательность цифр в имени файла при использовании шаблона %F - например,

configure controlfile autobackup format for device type disk to '/orabackup/rman2disk/back1_ctl_%F';

Перенос базы в новую ASM_DISKGROUP

После того, как был добавлен новый LUN, был настроен автостарт базы осталось решить последнюю проблему - необходимо перенести базу из текущих asm_diskgroups, поднятых на RAID0 в новую asm_diskgroup, созданную на базе нового добавленного LUN'а RAID1.
При подготовке к данному переносу почитал доку, ноты металинка и провел ряд тестов на своей тестовой базе в VMVare-машине. В результате составил след.инструкцию, которую и использовал при работе с продакшн базой.
====
Задача: Перенести базу в новую asm_diskgroup
Данные: Имя новой asm_diskgroup - EVA01R1


1) Сделать бэкап control- файла

SQL> select name from v$controlfile;
SQL> alter database backup controlfile to '+EVA01R1';

2) Задать новое месторасположение control-файла в spfile

SQL> alter system set control_files='+EVA01R1\ITC\CONTROLFILE\CONTROL01.CTL' SCOPE=SPFILE;

Прим. если spfile не используется экземпляром, то прописать в его init.ora

3) Восстановить новый из старого control-файла


$ rman target /
RMAN > shutdown immediate;
RMAN > startup nomount;
RMAN> restore controlfile from '+EVA02/itc/controlfile/current.266.610247845';

4) Запустить копирование базы

RMAN> alter database mount;
RMAN> backup as copy database format ' +EVA01R1 ';

5) Переключить базу на копию

RMAN> switch database to copy;
RMAN> RUN
{
SWITCH TEMPFILE 1 TO '+EVA01R1';
}


6) Добавить в init.ora
параметр Db_create_file_dest=+eva01r1

7) Открыть базу
RMAN> alter database open;

8) Добавить в новую asm_diskgroup зеркальные копии онлайн-логов во всего журнальные группы экземпляра

alter database add logfile member ' +EVA01R1 ' to group 1 ;
alter database add logfile member ' +EVA01R1 ' to group 2;
alter database add logfile member ' +EVA01R1 ' to group 3 ;
alter database add logfile member ' +EVA01R1 ' to group 4 ;
alter database add logfile member ' +EVA01R1 ' to group 5 ;

9) Переключить журнал
alter system archive log current

10) Удалить старые копии журналов из старой asm_diskgroup

Можно использовать скрипт (здесь старая группа +EVA02)

declare
strSQL varchar2( 200 );
begin
for pList in (select member from v$logfile where member like '+EVA02/%' ) loop
strSQL:= 'alter database drop logfile member "' || pList.member || '"' ;
begin
EXECUTE IMMEDIATE strSQL;
end;
end loop;
end;

или вручную через

alter database drop logfile member '+EVA02/itc/onlinelog/group_1.256.609887989’
(имя файла изменять на свое)

Проверить остались ли старые файлы
select member from v$logfile where member like '+EVA02/%'

11) Переместить файл block_change_tracking

SQL> select status,filename
from v$block_change_tracking;

SQL> alter database disable block change tracking

SQL> alter database enable block change tracking
using file '+EVA01R1' reuse;


12) Проверить месторасположение всех фалов

select name from v$controlfile
union
select name from v$datafile
union
select name from v$tempfile
union
select member from v$logfile
union
select filename from v$block_change_tracking


13) Удалить все старые дисковые группы как ненужные

SQL> drop diskgroup eva01 including contents;
SQL> drop diskgroup eva02 including contents;

Block change tracking (Сказочно, но проверить!)

Отслеживание измененных блоков для оптимизации инкрементального резервирования за счет устранения необходимости полного просмотра файлов данных в ходе резервирования.
Информация о физическом расположении всех изменений, заносится в файл отслеживания изменений change tracking file фоновым процессом CTWR (change tracking writer).
При включенном режиме отслеживания файл измененных блоков автоматически используется RMAN-ом.

Для просмотра включен ли режим отслеживания измененных блоков
sys@ORCL> select status from v$block_change_tracking;

STATUS
----------
DISABLED

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

sys@ORCL> show parameter db_create_file_dest;

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string +ASM_DATA

Если параметр включен как в примере выше, то включение без указания имени файла.
sys@ORCL> alter database enable block change tracking;

sys@ORCL> select status,filename from v$block_change_tracking;

STATUS FILENAME
---------- --------------------------------------------------
ENABLED +ASM_DATA/orcl/changetracking/ctf.303.623334603

При выключенном параметре parameter db_create_file_dest
sys@ORCL> alter database enable block change tracking
2> using file '/mydir/rman_change_track.f'
3> REUSE;

alter database open resetliogs;

Эксперимент с потерей onlinelogs ...
Для симуляции потери online-logs, удалил их вручуную через 'asmcmd -p' при закрытой базе. При попытке открыть базу после этого ошибка
sys@ORCL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01139: RESETLOGS option only valid after an incomplete database recovery

Делаем recover until cancel (либо until time) и открываем базу.

sys@ORCL> alter database recover until cancel;
sys@ORCL> alter database open resetlogs;
Database altered.
ИЛИ
sys@ORCL> alter database recover automatic until time "to_date('2007-07-05:15:00:00','YYYY-MM-DD:HH24:MI:SS')";
sys@ORCL> alter database open resetliogs;
Database altered.

И ВАЖНО ПОМНИТЬ, что после OPEN RESETLOGS необходимо сразу сделать полный бэкап базы, т.к. все предыдущие потеряют актуальность.