Функционирование резервной базы данных (standby). Заметки по собственному опыту

dbstalker, 16 июня

Сегодня у меня возникли проблемы с базой данных, которая имеет две standby базы данных. То есть, на два отдельных сервера посылаются архивные файлы журнализации и там они накатываются (более детально об standby можно увидеть в моих статьях на эту тему). И в один непрекрасный день случилось две проблемы:

  1. На основном сервере ночью был сделан холодный бэкап( без rman), который в том числе архивирует с удалением все архивные файлы журнализации. Так случилось, что этот бэкап удалил archivelogs, которые не были переданы на сервера standby.
  2. На основном сервере одна redo group не могла заархивироваться.

Сейчас опишу, как нашелся выход из этой ситуации. Может быть, Вы предложите что-нибудь более рациональное?

Первая проблема решалась сначала не правильно (опишу, чтобы Вы так не делали):

  • Из бэкапа достали все archivelogs необходимые для standby
  • Вручную перенесли их в нужные папки (параметр инициализации standby_archive_dest) на все базы stanby

Но накат этих файлов на резервных базах данных не производился. Эти базы в упор не видили этих archivelogs, recover managed standby database висел в ожидании необходимой порции архивных файлов журнализации.

А нужно было всего-то: положить удалённые archivelogs туда, откуда они были удалены, т.е. на основном сервере в папку определенную параметром log_archive_dest_1. ORACLE сам их переместил на нужные резервные сервера, где они были любовно приняты и накатаны. Оказалось, что ORACLE не любит, когда вместо него работают.

Вторая проблема доставила немного неприятных хлопот. Как стало ясно, что одна redo group не могла заархивироваться? На резервном сервере в алерте появилось сообщение:

Media Recovery Waiting for thread 1 seq# 239
Tue May 15 10:07:37 2007
Completed: alter database recover managed standby database di
Tue May 15 10:20:17 2007
kccrsz: expanded controlfile section 11 from 237 to 279 records
  requested to grow by 41 record(s); added 3 block(s) of records
Tue May 15 10:20:21 2007
Fetching gap sequence for thread 1, gap sequence 239-239
Trying FAL server: my_server.world
Tue May 15 10:21:51 2007
Failed to request gap sequence. Thread #: 1, gap sequence: 239-239
All FAL server has been attempted.

Вот эту seq# 239 резервные сервера не могли получить от основного сервера, хотя все последующие файлы были получены. Но накат не производился, так как seq# 239 не было.

На основном сервере выполнили

SELECT * FROM v$LOG

чтобы посмотреть, что там происходит с redo logs. Действительно, одна группа была неактивная, но незаархивированная. В алерте на основном сервере были сообщения типа:

ARCH: Completed archiving  log 4 thread 1 sequence 243
ARCH: Evaluating archive   log 7 thread 1 sequence 239
ARCH: Unable to archive log 7 thread 1 sequence 239
      Log actively being archived by another process
ARCH: Evaluating archive   log 6 thread 1 sequence 244
ARCH: Beginning to archive log 6 thread 1 sequence 244
Creating archive destination LOG_ARCHIVE_DEST_3: 'my_st2.world'
Creating archive destination LOG_ARCHIVE_DEST_2: 'my_st1.world'
Creating archive destination LOG_ARCHIVE_DEST_1: 'K:\ORACLE\ORADATA\ MY_SERVER\ARCHIVE\ARC00244.001'
ARCH: Completed archiving  log 6 thread 1 sequence 244

Чтобы иметь время на размышление, добавили парочку новых redo group и начали колдовать. Попробовали вручную заархивировать:

Alter system archive log all;
Alter system archive log group номер;
Alter system archive log change номер;

Ничего не дало, только в алерте появляются сообщения подобные:

ARCH: Evaluating archive   log 7 thread 1 sequence 239
ARCH: Unable to archive log 7 thread 1 sequence 239
      Log actively being archived by another process

То есть эта несчастная группа архивируется другим процессом и никак не заархивируется.

Решение:

Дождались (добавляли новые redo group) пока появилась возможность перегрузить сервер. При останове ORACLE архивирует все незаархивированые файлы. Но shutdown immediate не получился, пришлось выполнить shutdown abort. После чего, на наше удивление, сервер стартовал, смонтировался, открылся. Наша группа была архивирована, передана на резервные сервера, где благополучно продолжился накат.

На этом наши проблемы разрешились. На долго ли?

2 комментария

Прокоментировать

Igor
25 апреля 2008 г. в 09:32

У меня недавно тоже такое было. Это когда в момент архивации журнала упал стэндбай. Как оказалось, этот журнал "завис" со статусом "архивируется", и Alter system archive log all заархивировал все остальные журналы, кроме этого, и завис, пока не сняли ^C. Shutdown immediate долго ждал, наконец выдал фразу вроде "не могу дождаться окончания архивации журнала, прерываю процесс" и нормально положил базу. После старта все нормально заархивировалось.

Teo
17 января 2011 г. в 23:45

Это не Оракл не любит когда за него работают, а обычный РТФМ:

This clause allows the registration of manually archived redo logs. The SQL statement syntax is:

ALTER DATABASE REGISTER [OR REPLACE] [PHYSICAL | LOGICAL] LOGFILE filespec;

 

Новый комментарий

Я не спамер: введите суму 2+8



 

От авторов блога

О Блоге - прочитай перед началом.

Задать вопрос и получить ответ - уже решено 94 вопросов

Глоссарий - список терминов и сокращений


 
 

Бизнес форум

Последние темы:

Нужна гадалка
20 июля, 1 ответа
Бутель для воды
20 июля, 1 ответа