Здравствуйте коллеги! Когда-то в нашей организации всё было хорошо, были и DBA и Unix-админы, но сейчас на почве ликвидации остался один. Разумеется, к администрированию БД меня никто никогда не подпускал, благо оставили пароли.
Со мной случилась СУБД Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
Есть две БД, Db1 с ролью PRIMARY и Db2 с ролью PHYSICAL STANDBY на двух разных физических серверах. Обе работают в режиме Archivelog.
Однажды, боевая база Db1 остановилась, забившись архивлогами. Путём активного гугления и применения RMAN удалось сбросить бэкапы архивлогов и самой базы на внешний носитель, почистить область данных FRA, после чего, база завелась и вроде бы даже работает.
Однако, по мере углубления в принципы работы СУБД и резервного копирования баз стало понятно, что с момента остановки базы по причине забитой области FRA - прекратилось и резервное копирование на ленту.
Начал копать. Сервер с базой данных работает в паре с HP Data Protector для Linux x64 версия A.06.20/370. Управляет DP ленточной хранилкой HP MSL2024 Tape Library.
Изначально считал, что резервное копирование выполняется исходя из настроенных политик RMAN, однако - нет.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name IBS_S1 are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF;
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/dbhome_2/dbs/snapcf_IBS.f'; # default
Чуть позже, нашёл sh-скрипт следующего содержания, который выполнялся по расписанию CRON'ом. Вот его часть, которая отвечает за периодический полный бэкап базы:
1.
2.
3.
4.
5.
6.
7.
run{
allocate channel c1 type 'sbt_tape' parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=IBS,OB2BARLIST=ibsdb)';
backup database filesperset 4 format 'full_%U';
sql 'alter system archive log current';
backup archivelog all filesperset 10 delete all input format 'archivelog_%U';
backup current controlfile format 'controlfile_%U';
}
Однако, данный скрипт вызывает ошибку следующего содержания:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
RMAN> 2> 3> 4> 5> 6> 7>
using target database control file instead of recovery catalog
allocated channel: c1
channel c1: SID=968 device type=SBT_TAPE
channel c1: Data Protector A.06.20/370
Starting backup at 09-AUG-17
channel c1: starting full datafile backup set
channel c1: specifying datafile(s) in backup set
input datafile file number=00005 name=+DATA01/ibs_s1/datafile/t_aud.269.779230551
input datafile file number=00017 name=+DATA01/ibs_s1/datafile/t_aud.378.884703137
input datafile file number=00012 name=+DATA01/ibs_s1/datafile/part.281.800221021
input datafile file number=00006 name=+DATA01/ibs_s1/datafile/i_aud.268.779230551
channel c1: starting piece 1 at 09-AUG-17
released channel: c1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on c1 channel at 08/09/2017 01:00:29
ORA-19506: failed to create sequential file, name="full_lrsbe5s3_1_1", parms=""
ORA-27028: skgfqcre: sbtbackup returned error
ORA-19511: Error received from media manager layer, error text:
Vendor specific error: OB2_StartObjectBackup() failed ERR(-17)
Листаю море мануалов на англицком, согласно которым можно ходить в некий GUI Data Protector'а и там уже интересоваться происходящим. Нахожу ПК бывшего админа, на которой была установлена утилита HP DP Manager, где вижу свою ошибочную сессию в журнале.
В представлении Reporting вижу событие, есть диагностическая информация:
[138:742] Backup session "2017/08/09-2" of the backup specification "Oracle8 ibsdb",backup group "Default" has errors: 3.
Description:
Errors have been detected during the backup, copy, or consolidation session.
Actions:
Check error messages of the session by using:
* Data Protector GUI (Internal Database context)
* Session Errors report
* omnidb -session <sessionID> -report
Шлёт в другой раздел GUI, но прежде - нахожу справочник по устранению проблем с Data Protector (Trouble.txt), там написано:
MESSAGE:
[138:742] p session "p" of the backup specification "p",backup group "p" has errors: p.
DESCRIPTION:
Errors have been detected during backup.
ACTION:
Check error messages of the session by using:
* Data Protector GUI (Internal Database context)
* Backup Errors report
* omnidb -session <sessionID> -report
Т.е. ничего нового не находим. Теперь - иду в GUI Data Protection Manager, в представлении Internal Database в списке сессий нахожу свою и иду во вкладку с сообщениями:
[Major] From: OB2BAR_SBT_
CHANNEL@db1.kapitalbank.ru "IBS" Time: 09.08.2017 18:16:35
Received ABORT request from BSM (ERR: Error starting backup/restore (BMA cannot be started or similar).)
Ради интереса пробую абстрагироваться от скрипта бэкапа, делаю sbttest test - результат в точности такой же.
Собственно, вижу, что ошибка общая, вывод сообщений - аналогичный скрипту.
Попытка отыскать расшифровку кода ошибки ERR(-17) особенным успехом не увенчалась, у меня ступор.
Вопрос - куда копать, при том, что раньше оно нормально работало?
Предварительно, была идея недостаточности свободного места на ленте, сделал
RMAN> Report Obsolete;
Увидел гору бэкапсетов за прошлый год, сделал
RMAN> delete obsolete;
Перезапустил сервер с Data Protector, попробовал снова сделать бэкап - опять ошибка, т.е. причина не в свободном месте.
Хочу заметить, что бэкапсеты с ленты удалились прекрасно. И не менее прекрасно я вижу оставшиеся на ленте бэкапсеты, которые не попали под obsolete из-за политик хранения в RMAN.
Люди добрые, пните пожалуйста в нужную сторону! Можно, конечно, пробовать бэкапить на сторонний диск, но при наличии ленточной хранилки - это как-то даже неприлично.
