Одна из областей, где администратор баз данных не может позволить себе делать ошибки, находится в резервной копии базы данных. Когда была протестирована последняя резервная копия базы данных? Было ли это успешным? Как часто проверяется резервная копия? Автоматизируется ли тестирование?

Одного администратора данных попросили проверить резервные копии для нескольких резервных баз данных, восстановив резервную копию базы данных на том же хосте.

Дано: на одном хосте имеется несколько экземпляров базы данных резервной копии RAC.

Цель: протестировать резервное хранилище резервных копий резервных баз RAC путем восстановления последней резервной копии на том же узле в узле1.

Имя db_unique_ для восстановленной базы данных всегда будет восстановлено для согласованности.

Вот файл параметров, и в основном единственное требуемое изменение - имя db_name, при этом все остальные согласованы.

$ cat initrestore1.ora
*.cluster_database=false
*.compatible='12.1.0.2.0'
*.db_block_size=8192
*.db_create_file_dest='+DATA'
*.db_files=5000
*.db_name='DB'
*.db_recovery_file_dest_size=4398046511104
*.db_recovery_file_dest='+RECO'
*.db_unique_name='restoredr'
*.diagnostic_dest='/u01/app/oracle'
*.pga_aggregate_target=3439329280
*.processes=1000
*.sga_max_size=5150605312
*.sga_target=5150605312
restore1.instance_number=1
restore2.instance_number=2
restore1.thread=1
restore2.thread=2
restore1.undo_tablespace='UNDOTBS1'
restore2.undo_tablespace='UNDOTBS2'

Вот скрипт для базы данных восстановления rman после восстановления файла управления и т. д. ...

Это было реализовано как таковое, поскольку процесс отсюда последователен.

$ cat restore1.rman
# CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/zfs/backup02/db_backups/%d/RMAN/%F';
# CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/zfs/backup02/db_backups/%d/RMAN/%d_%I_%s_%p.%T.bak';
#
# Note: %d is db_name from parameter file and not db_unique_name
#
# Usage: nohup rman @ restore1.rman %d > /tmp/restore1.out 2>&1 &
#
spool log to /tmp/restore1.log
connect target;
sql 'alter database mount STANDBY database';
sql 'alter database disable block change tracking';
run {
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
allocate channel c5 type disk;
allocate channel c6 type disk;
allocate channel c7 type disk;
allocate channel c8 type disk;
allocate channel c9 type disk;
catalog start with '/zfs/backup02/db_backups/&1/RMAN/' noprompt;
set newname for database to new;
restore database;
switch datafile all;
recover database NOREDO;
release channel c2;
release channel c3;
release channel c4;
release channel c5;
release channel c6;
release channel c7;
release channel c8;
release channel c9;
sql 'alter database open READ ONLY';
}
exit

Файл отслеживания изменений блоков идентичен для восстановленной базы данных DR.

restore1> select * from v$block_change_tracking;

STATUS     FILENAME
---------- -------------------------------
ENABLED    +DATA/DBDR/CHANGETRACKING/ctf.3853.987122725

dbdr> select * from v$block_change_tracking;

STATUS     FILENAME
---------- -------------------------------
ENABLED    +DATA/DBDR/CHANGETRACKING/ctf.3853.987122725

Файл отслеживания изменений блоков идентичен для восстановленной базы данных DR.
Отключить отслеживание изменений блоков, чтобы предотвратить сбой экземпляра DR из-за ошибки файла.

Вот страшная часть:

Файлы DATA и TEMP находятся в новом месте на + DATA / RESTOREDR; однако файлы LOG находятся в исходном месте + DATA / DBDR.

Было много колебаний, чтобы сбросить восстановленную базу данных. При дальнейшем тестировании с помощью виртуальной машины был совершен прыжок в неизвестность.

restore1> @logfile.sql
restore1> show parameter db%name

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string
db_name string DB
db_unique_name string restoredr
pdb_file_name_convert string
restore1> col db_unique_name for a18
restore1> col filename for a30 trunc
restore1> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY

restore1> select distinct regexp_substr(name,'[[:alpha:]]+',1,2) db_unique_name from V$DATAFILE;

DB_UNIQUE_NAME
------------------
RESTOREDR

restore1> select distinct regexp_substr(name,'[[:alpha:]]+',1,2) db_unique_name from V$TEMPFILE;

DB_UNIQUE_NAME
------------------
RESTOREDR

restore1> select distinct regexp_substr(member,'[[:alpha:]]+',1,2) db_unique_name from V$LOGFILE;

DB_UNIQUE_NAME
------------------
DBDR

restore1> select distinct regexp_substr(filename,'[[:alpha:]]+',1,2) db_unique_name from V$BLOCK_CHANGE_TRACKING;

DB_UNIQUE_NAME
------------------

restore1> select filename, status from V$BLOCK_CHANGE_TRACKING;

FILENAME STATUS
------------------------------ ----------
DISABLED

restore1> @drop_restore1.sql
restore1> set lines 300 timing off pages 10000 trimsp on tab off echo on
restore1> startup force mount restrict exclusive;
ORACLE instance started.

Total System Global Area 4294967296 bytes
Fixed Size 2932632 bytes
Variable Size 3046682728 bytes
Database Buffers 1191182336 bytes
Redo Buffers 54169600 bytes
Database mounted.
restore1> show parameter db%name

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string
db_name string DB
db_unique_name string restoredr
pdb_file_name_convert string
restore1> drop database;
ERROR:
ORA-01034: ORACLE not available
Process ID: 278789
Session ID: 2792 Serial number: 319

База данных упала.

Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options
> exit

No Comments