Встала задача смигрировать незнакомую базу с одних дисков на совершенно другие диски.
База небольшая, терабайт на 20, но видел я ее практически впервые и за каким-то ее сделали на ASM. Как выяснилось позже, еще ее сделали контейнерной, обо что я сильно споткнулся.
Версия 19.20
Итак, сначала посмотрел, что файл профиля лежит на файловой системе.
Код:
show parameter spfile
Далее контрольники, темпы и redo, которые нельзя перенести онлайн, выписываем в блокнотик, выполняя запросы из всех контейнеров и ROOT
Код:
show parameter control_files
select member from v$logfile;
select name from v$tempfile;
далее с помощью lsblk и blkid находим новые диски
Код:
vda 253:0 0 2.9T 0 disk
vdb 253:16 0 2.9T 0 disk
vdc 253:32 0 2.9T 0 disk
vdd 253:48 0 2.9T 0 disk
vde 253:64 0 2.9T 0 disk
vdf 253:80 0 2.9T 0 disk
соответственно, оформляем их в ASM (из под рута)
Код:
/usr/sbin/asmtool -C -l /dev/oracleasm -n '101_1' -s /dev/vda -a force=yes
/usr/sbin/asmtool -C -l /dev/oracleasm -n '101_2' -s /dev/vdb -a force=yes
/usr/sbin/asmtool -C -l /dev/oracleasm -n '101_3' -s /dev/vdc -a force=yes
/usr/sbin/asmtool -C -l /dev/oracleasm -n '101_4' -s /dev/vdd -a force=yes
/usr/sbin/asmtool -C -l /dev/oracleasm -n '101_5' -s /dev/vde -a force=yes
/usr/sbin/asmtool -C -l /dev/oracleasm -n '101_6' -s /dev/vdf -a force=yes
Вот запрос по статусу дисков
SQL код:
select path,header_status from v$asm_disk;
Создаем дисковую группу с этими дисками
Код:
CREATE DISKGROUP 101 EXTERNAL REDUNDANCY
DISK '/dev/oracleasm/disks/101_1' name 101_1,
'/dev/oracleasm/disks/101_2' name 101_2,
'/dev/oracleasm/disks/101_3' name 101_3,
'/dev/oracleasm/disks/101_4' name 101_4,
'/dev/oracleasm/disks/101_5' name 101_5,
'/dev/oracleasm/disks/101_6' name 101_6
ATTRIBUTE 'AU_SIZE'='16M',
'compatible.asm' = '19.0.0.0.0',
'compatible.rdbms'='19.0.0.0.0';
обратите внимание, что если напрямую не указать уровень совместимости, то будет ошибка невозможности создавать диски размером более 2Тб, а если указать только совместимость ASM, то будет ошибка
ORA-15234: target RDBMS compatibility (19.0.0.0.0) exceeds ASM compatibility
(11.2.0.2.0)
вот запрос проверки совместимости
SQL код:
select name, value,GROUP_NUMBER from v$asm_attribute where name like 'comp%';
Чтобы в процессе никто не создал случайно файлик на старом месте, сделал
SQL код:
alter system set db_create_file_dest='+101';
зашел в asmcmd (никакого rlwrap на хосте не было и работа была просто страданием и болью с копированием в блокнотик и обратно), имейте ввиду, что mv там нет, есть только cp... Будете плакать, колоться и сверять, что скопировали, что нет... И это еще не все. Сначала хотел скопировать по маске * и получил
ORA-15046: ASM file name '+101/REDO/group_3.261.1169726747' is not in single-file creation form
то есть имена могут быть только без того цифрового хвоста, который им OMF приделывает, в итоге собрал скрипт копирования вручную для тех файлов, которые были с этим хвостом, что REDO, что потом TEMP (база, понятное дело, была опущена)
Код:
ls -l +REDO3/101_YC/ONLINELOG/*
Type Redund Striped Time Sys Name
ONLINELOG MIRROR COARSE FEB 07 14:00:00 Y group_1.263.1169725765
ONLINELOG MIRROR COARSE FEB 07 14:00:00 Y group_2.262.1169726279
ONLINELOG MIRROR COARSE FEB 07 14:00:00 Y group_3.261.1169726747
ONLINELOG MIRROR COARSE FEB 07 14:00:00 Y group_4.260.1169727543
ONLINELOG MIRROR COARSE FEB 07 14:00:00 Y group_5.259.1169722087
ONLINELOG MIRROR COARSE FEB 07 14:00:00 Y group_6.258.1169722851
ONLINELOG MIRROR COARSE FEB 07 14:00:00 Y group_7.257.1169723023
ONLINELOG MIRROR COARSE FEB 07 14:00:00 Y group_8.256.1169723563
Код:
cp +REDO3/101_YC/ONLINELOG/group_1.263.1169725765 +101/REDO/group_1
cp +REDO3/101_YC/ONLINELOG/group_2.262.1169726279 +101/REDO/group_2
cp +REDO3/101_YC/ONLINELOG/group_3.261.1169726747 +101/REDO/group_3
cp +REDO3/101_YC/ONLINELOG/group_4.260.1169727543 +101/REDO/group_4
cp +REDO3/101_YC/ONLINELOG/group_5.259.1169722087 +101/REDO/group_5
cp +REDO3/101_YC/ONLINELOG/group_6.258.1169722851 +101/REDO/group_6
cp +REDO3/101_YC/ONLINELOG/group_7.257.1169723023 +101/REDO/group_7
cp +REDO3/101_YC/ONLINELOG/group_8.256.1169723563 +101/REDO/group_8
убедитесь, что файлы появились, где надо, и в будущем можете проверять время их изменения
Код:
ls -ls +101/TEMP/
ls -ls +101/REDO/
далее надо будет для всех скопированных файлов переименовать их
SQL код:
alter database rename file '+DATA3/101_YC/TEMPFILE/tmpdatanew.tmp' to '+101/TEMP/tmpdatanew.tmp';
для спокойствия я оторвал сразу дисковую группу с REDO
Код:
alter diskgroup redo3 dismount;
темпы сверял более тщательно...
После всех проверок можно запускать базу... И дальше уже сделать скриптик такого вида
SQL код:
select 'alter database move datafile '''||name||''' to '''||replace(substr(name,1,instr(name,'.',-1)-1),'+DATA3/DATAFILE/','+101/DATA/')||''';' from v$datafile where name not like '%+101%';
после чего запустить его где-то, где не порвется связь, поскольку у меня этот move всех 573 файликов занял около двух суток.
SQL код:
select file#,name from v$datafile where name not like '%+101%';
select file#,''''||name||'''' from v$datafile where name not like '%+101%';
после всех перемещений я в asmcmd ввел команду lsof и посмотрел открытые файлы... увы, не все они были на новом месте. Соответственно, я сначала пересоздал файлик block change tracking просто выключив и включив его, а потом воззрился на файлик по пути
+DATA3/101_YC/DADF2965AC2142A1E0533FCA300AAD63/DATAFILE/
По пути было понятно, что это файлик какого-то контейнера, тут я и споткнулся, что это контейнерная база
SQL код:
select pdb_name from DBA_PDBS;
покажет, какие есть контейнеры, в моем случае я забыл PDB$SEED
для расшифровки пути (части, вроде DADF2965AC2142A1E0533FCA300AAD63) можно использовать нижеследующий скрипт и конкретно GUID вывода
SQL код:
COLUMN NAME FORMAT A8
SELECT NAME, CON_ID, DBID, CON_UID, GUID FROM V$CONTAINERS ORDER BY CON_ID;
ну и после того, как убедитесь, что база нормально работает, сначала сделайте dismount группам дисков, а потом можете их удалить
SQL код:
drop diskgroup fra3 force including contents;