Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 GAP на STANDBY. Непонятное поведение  [new]
stil
Member

Откуда: Кемерово
Сообщений: 1295
Пару недель назад поломался STORAGE на резервоном сервере (причины в принципе не важны). Главное, что логи на резерв не передавались и не применялись там

Сейчас все починено - standby запущен. Друг друга видят. fal_server и fal_client настроены. Вроде бы все ок, но.. Отставание резерва на текущий момент - 2 недели. Всех архивлогов с того времени уже нет. Хотелось посмотреть, как Oracle будет реагировать на эту проблему..

На текущий момент вижу:
на primary
Wed Mar 31 15:05:51 2010
LGWR: Standby redo logfile selected to archive thread 1 sequence 3647
LGWR: Standby redo logfile selected for thread 1 sequence 3647 for destination LOG_ARCHIVE_DEST_2
Wed Mar 31 15:05:51 2010
Thread 1 advanced to log sequence 3647 (LGWR switch)
  Current log# 4 seq# 3647 mem# 0: /путь/o1_mf_4_5q6toq94_.log
  Current log# 4 seq# 3647 mem# 1: /путь/o1_mf_4_5q6tor70_.log
на standby:
Wed Mar 31 15:05:51 2010
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
RFS[1]: Successfully opened standby log 16: 'путь/o1_mf_16_5p53z1pn_.log'
и тп. Визуально то есть наблюдаю пересылку новых появляющихся логов. Логи отлично пересылаются, но понятно ненакатываются (ибо огромный двухнедельный GAP)

В V$ARCHIVE_GAP - пусто. Каких либо попыток ликвидации GAP-а не наблюдается ни в алертлоге стендбая, ни в алертлоге primary

Версия: 10.2.0.4

Поведение выглядит весьма загадочным. Вопрос скорее не в том, что делать - бэкапы за две недели есть. Докатить через них standby не вопрос. Вопрос - почему Ораклу абсолютно пофик, что стендбай отстал и он не пытается ничего делать?
31 мар 10, 12:36    [8558310]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
как вы определяете что есть гап ?...
select PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS from V$MANAGED_STANDBY;
??
select max(sequence#) from v$archived_log
??
31 мар 10, 12:40    [8558343]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
stil
Member

Откуда: Кемерово
Сообщений: 1295
pravednik,

primary:
SQL> select PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS from V$MANAGED_STANDBY;

PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH      CLOSING               1       3647     376833        116
ARCH      CLOSING               1       3646     376833       1046
LGWR      WRITING               1       3648     347101          2

standby:
SQL> select PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS from V$MANAGED_STANDBY;

PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH      CLOSING               1       3647     376833        116
ARCH      CLOSING               1       3646     376833       1046
MRP0      APPLYING_LOG          1       2942       2125     409600
RFS       IDLE                  1       3648     350905          3
RFS       IDLE                  0          0          0          0
RFS       IDLE                  0          0          0          0

С архивлогами не все так однозначно:

standby:
SQL> select dest_id,max(sequence#)
from v$archived_log
where first_time between sysdate-30 and sysdate
group by dest_id;

   DEST_ID MAX(SEQUENCE#)
---------- --------------
         1           3647
         2           2934

primary:
SQL> select dest_id,max(sequence#)
from v$archived_log
where first_time between sysdate-30 and sysdate
group by dest_id;

   DEST_ID MAX(SEQUENCE#)
---------- --------------
         1           3647
         2           3647
Но:
SQL> select dest_id,max(sequence#)
from v$archived_log
where first_time between sysdate-30 and sysdate[b]-2[/b]
group by dest_id;

   DEST_ID MAX(SEQUENCE#)
---------- --------------
         1           3542
         2           2934

1. sysdate-30 - так как пару месяцев назад был reset log и нумерация обнулилась
2. На текущий момент файлы передаются и between sysdate-30 and sysdate для primary показывает одно значение

Есть еще один ньюанс, про который я не упомянул. Неделю назад были попытки запустить передачу логов (думали, что сторедж пофиксили). В v$archived_log (primary)
появилась запись о логе переданном якобы на dest_2 файл размера 0 на сервере standby присутствует (не смог записаться изза бэдов), но в v$archived_log (standby) записи об этом нет
31 мар 10, 13:20    [8558667]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
stil
Member

Откуда: Кемерово
Сообщений: 1295
SQL> select dest_name, 
                                  status, 
                                  archiver, 
                                  process,
                                  transmit_mode, 
                                  db_unique_name, 
                                  destination 
from V$ARCHIVE_DEST 
where status !='INACTIVE';

DEST_NAME          STATUS    ARCHIVER   PROCESS    TRANSMIT_MOD DB_UNIQUE_NAME DESTINATION 
------------         --------- ---------- ---------- ------------ ------------    ----------
LOG_ARCHIVE_DEST_1  VALID     ARCH     ARCH       SYNCHRONOUS   prm USE_DB_RECOVERY_FILE_DEST
LOG_ARCHIVE_DEST_2  VALID     LGWR     LGWR       PARALLELSYNC  stb stb
31 мар 10, 13:27    [8558756]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
Пин
Member

Откуда:
Сообщений: 335
stil,
Сделайте на стендбае.
select max(sequence#) from v$archived_log where applied='YES';


RFS будет работать даже с гигантским гапом, другое дело что если у вас нет архивлогов (удалены) на праймари или стендбае и нет бэкапа архивлогов то остаётся по сути всего два пути
1. Инкрементально рефрешить стендбай и пересозданием стендбай контролфайла.
2. Пересоздавать стендбай.
31 мар 10, 14:34    [8559312]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
debosh
Member

Откуда:
Сообщений: 326
Пин,

да его интересует, почему гап не резолвится.
У меня на девятке была похожая ситуация - после простоя стендабая текущие арклоги передавались нормально, а дырка ни в какую ни хотела заполняться. Причем втихую, без всякой ругани.
Вылечилось перезапуском боевой - благо было запланированный останов. После старта дыра на автомате заполнилась. Здесь же малость другой случай.
31 мар 10, 14:52    [8559486]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
debosh
Member

Откуда:
Сообщений: 326
2 TC
а в v$dataguard_stats ничего интересного нет?

и еще - V$ARCHIVE_GAP - точно на стэндбае смотрели? :)
ну мало-ли, может консоли перепутались :)
31 мар 10, 14:54    [8559514]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
stil
Member

Откуда: Кемерово
Сообщений: 1295
debosh
RFS будет работать даже с гигантским гапом, другое дело что если у вас нет архивлогов (удалены) на праймари или стендбае и нет бэкапа архивлогов то остаётся по сути всего два пути
1. Инкрементально рефрешить стендбай и пересозданием стендбай контролфайла.
2. Пересоздавать стендбай.

Да вот в том то и суть, что проблема не в "гигантскости". Архивлогов понятно, что заведомо нет (место позволяет хранить их не более чем за неделю), но есть инкрементальные бэкапы. Инкрементальный рефреш стендбая я собственно и планировал. Просто хотел ради интереса выяснить как Оракл отнесется к ситуации с гапом - заведомо превышающим доступные архивлоги. Ожидал ошибок каких то в алерте что ли То что вообще никак не прореагирует для меня было большим сюрпризом..

SQL> select max(sequence#) from v$archived_log
where first_time between sysdate-30 and sysdate
and applied='YES';

MAX(SEQUENCE#)
--------------
          2941

debosh
2 TC
а в v$dataguard_stats ничего интересного нет?

Пусто

debosh

и еще - V$ARCHIVE_GAP - точно на стэндбае смотрели? :)
ну мало-ли, может консоли перепутались :)

Точно :)
31 мар 10, 15:10    [8559638]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
jan2ary
Member

Откуда: Киев
Сообщений: 1780
Судя по тому, что MRP0 находится в состоянии APPLYING_LOG, до гапа он еще просто не добрался.
31 мар 10, 15:13    [8559664]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
stil
Member

Откуда: Кемерово
Сообщений: 1295
jan2ary
Судя по тому, что MRP0 находится в состоянии APPLYING_LOG, до гапа он еще просто не добрался.

И сколько времени будет добираться? Он в этом состоянии уже несколько часов..
31 мар 10, 16:00    [8560101]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
stil,

отслеживайте на стендбае изменения через V$MANAGED_STANDBY;

К примеру, какая сейчас картина ?
31 мар 10, 16:01    [8560111]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
stil
Member

Откуда: Кемерово
Сообщений: 1295
pravednik

К примеру, какая сейчас картина ?

Да собственно почти та же:
SQL> select PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS from V$MANAGED_STANDBY;

PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH      CLOSING               1       3655     376833        389
ARCH      CLOSING               1       3656     376833         78
MRP0      APPLYING_LOG          1       2942       2125     409600
RFS       IDLE                  1       3657     106528          2
RFS       IDLE                  0          0          0          0
RFS       IDLE                  0          0          0          0

Поменялось толкьо то, что касается новых логов MRP0 как висел на 2942 так и остался
31 мар 10, 16:17    [8560242]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
GL
Member

Откуда: Харьков
Сообщений: 1513
stil,

а на standby'е вообще процесс MRP0 жив? на 10.2.0.3 он любит время от времени упасть...
31 мар 10, 16:29    [8560334]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
Пин
Member

Откуда:
Сообщений: 335
jan2ary
Судя по тому, что MRP0 находится в состоянии APPLYING_LOG, до гапа он еще просто не добрался.

Очень спорное утверждение.

Автор, у меня помнится было нечто подобное, в момент возникновения гапа, сам оракл обозначил это единственной записью в алертлоге (внимательно просмотрите ещё раз алерт в районе 2942), логи при этом передавались и далее а вот новых сообщений уже не появлялось.
Версия тож 10.2.0.4. AIX конфиг без брокера.
31 мар 10, 16:33    [8560368]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
stil
Member

Откуда: Кемерово
Сообщений: 1295
GL
а на standby'е вообще процесс MRP0 жив?

Да даже если б отваливался - при перезапуске RECOVER MANAGED STANDBY должен был восстановиться

В общем дело решилось так:

Про отсутствие бэкапов архивлогов наврал - извиняюсь: архивлоги за посл месяц в бэкапе остались. На сервере standby - нашел файлик-архивлог с номером 2942 (в OMF-названии зашит). Но которого нет в v$archived_log. Попробовал каталогизировать посредством:
RMAN> catalog archivelog '/путь/o1_mf_1_2942_5t0l6q2m_.arc';
получил нечто вроде
Corrupt block seq: 2724 blocknum=216576.
Bad header found during backing up archived log
Data in bad block - seq:8760. bno:4194520. time:524780349
beg:2 cks:1025
calculated check value: 1025
Reread of seq=2724, blocknum=216576, file=/u02/ELTCSTBY/archivelog/2010_03_12/o1_mf_1_2724_5snb465k_.arc, found same corrupt
 data
Reread of seq=2724, blocknum=216576, file=/u02/ELTCSTBY/archivelog/2010_03_12/o1_mf_1_2724_5snb465k_.arc, found same corrupt
 data
Я так понял, что это тупо кусок архивлога который успел перенестись весь перед тем, как крякнул винт. Поэтому просто его снес. Перетащил бэкап с этим архивлогом на резерв, отресторил его. После перезапуска RECOVER MANAGED STANDBY - накат пошел.. После того как лог 2942 накатился - получил вот это в алерте:
Wed Mar 31 19:42:05 2010
Waiting for all non-current ORLs to be archived...
Media Recovery Log /u02/ELTCSTBY/archivelog/2010_03_31/o1_mf_1_2942_5v6jkpw0_.arc
Wed Mar 31 19:42:06 2010
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
Wed Mar 31 19:44:21 2010
Media Recovery Waiting for thread 1 sequence 2943
Fetching gap sequence in thread 1, gap sequence 2943-3045
Wed Mar 31 19:44:53 2010
FAL[client]: Failed to request gap sequence
 GAP - thread 1 sequence 2943-3045
 DBID 691650441 branch 708580592
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------

То есть GAP - thread 1 sequence 2943-3045, но в V$ARCHIVE_GAP - по прежнему пусто почему то. Хм..

Ради спортивного интереса попробовал ресторить архивлоги прямо на PRIMARY (не переносить бэкапсеты с ними). В принципе теперь поведение предсказуемое: как только oracle видит пояляющиеся из бэкапа архивлоги - сразу передает их на резерв, где они благополучно подхватываются и накатываются..

Сейчас потренируюсь накатывать стендбай инкрементальными бэкапами с PRIMARY. Но это уже другая история Эту тему можно закрыть

P.S. Остались только два несущественных вопроса:
1) почему V$ARCHIVE_GAP всегда пустой? Зачем он вообще нужен?
2) при запросе из v$dataguard_stats на standby получил:
ORA-00604: error occurred at recursive SQL level 1
ORA-01427: single-row subquery returns more than one row
????
На Primary этой ошибки нет, но вьюха это ничего не возвращает
31 мар 10, 20:21    [8561411]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
jan2ary
Member

Откуда: Киев
Сообщений: 1780
Пин
jan2ary
Судя по тому, что MRP0 находится в состоянии APPLYING_LOG, до гапа он еще просто не добрался.

Очень спорное утверждение.

Никто не мешает оспаривать, только желательно аргументированно.
Спасибо.
31 мар 10, 20:26    [8561420]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
Пин
Member

Откуда:
Сообщений: 335
jan2ary
Пин
jan2ary
Судя по тому, что MRP0 находится в состоянии APPLYING_LOG, до гапа он еще просто не добрался.

Очень спорное утверждение.

Никто не мешает оспаривать, только желательно аргументированно.
Спасибо.

Да не вопрос, номер последнего переданного лога был 41, 42 - не был применён. стендбай дальше получает логи но не накатывает их, 42-го лога в полученных мы не видим. Вопрос 42 - гап или нет?
По моему мнению это гап. Теперь по поводу Вашего предположения. 41 уже со статусом apply=yes, на 42 MRP0 находится в состоянии APPLYING_LOG, тогда что значит Ваша фраза - не добрался? Если во вьюхах явно видно что он работает (по словам автора) уже две недели с 42.
31 мар 10, 21:22    [8561560]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18487
Не добрался, в данном контексте значит, что он так и не смог накатить текущий лог из-за кривого файла, а гап начнется только со следущего лога

Другой вопрос, почему v$archive_gap пустой. Частенько приходилось докатывать стендбаи с большими гапами (последний раз вчера, гап -- 25 гигов логов, это все гнать через тонкий канальчик на другой конец города), но, честно говоря, никогда не заглядывал в v$archive_gap. Всегда хватало alert.log
1 апр 10, 02:44    [8562297]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18487
Насчет v$archive_gap
standby alert.log
Thu Apr  1 09:55:45 2010
Media Recovery Log /opt/oracle/admin/prod/arch2/1_7379_669832596.dbf
Thu Apr 1 09:59:40 2010
Media Recovery Waiting for thread 1 sequence 7380
Fetching gap sequence in thread 1, gap sequence 7380-7380
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options

SQL> select * from v$archive_gap;

   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
         1          7380           7380

1 апр 10, 04:22    [8562332]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18487
Хм, а 10.2.0.4 хоть и пишет
standby alert.log
Thu Apr  1 13:24:39 2010
Fetching gap sequence in thread 1, gap sequence 29283-29290
Thu Apr 1 13:25:41 2010
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 2282
RFS[2]: Identified database type as 'physical standby'
но
SQL> select * from v$archive_gap;

no rows selected
1 апр 10, 06:30    [8562354]     Ответить | Цитировать Сообщить модератору
 Re: GAP на STANDBY. Непонятное поведение  [new]
debosh
Member

Откуда:
Сообщений: 326
stil

Bug 7119382 - V$DATAGUARD_STATS may return misleading or inconsistent results
* 10.2.0.4
* 11.1.0.7
fixed in * 11.1.0.7.2 (Patch Set Update), * 11.2.0.1 (Base Release)
1 апр 10, 06:44    [8562363]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить