Как проверить успешность наката лога на стендбай?

Relic Hunter

Дата: 25.11.2009 02:36:10

Как проверить успешность наката лога на стендбай?

Вот кусок лога наката стендбая.

Step 3. Copy archive logs
Attempt [1]
1_6097_686336883.arc 4842KB sent to reportdb02

Step 3. Delete archive logs
############################################################
### Ship Logs End Time: Tue Nov 24 19:06:22 AST 2009 ###
############################################################

Step 4. Succeeded
 
Step 5. Recover standby
ORA-00279: change 631897987 generated at 11/24/2009 19:03:04 needed for thread
1
ORA-00289: suggestion : /u01/oraarch/hmsp/1_6098_686336883.arc
ORA-00280: change 631897987 for thread 1 is in sequence #6098
ORA-00278: log file '/u01/oraarch/hmsp/1_6098_686336883.arc' no longer needed
for this recovery
ORA-00308: cannot open archived log '/u01/oraarch/hmsp/1_6098_686336883.arc'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3


Step 5. Succeeded
 
Step 6. Check recovery
Step 6. Succeeded
############################################################
### Apply Logs End Time: Tue Nov 24 16:06:29 MST 2009 ###
############################################################

Видно, что доставлен лог 1_6097_686336883.arc, он накатился и оракел просит следующий 1_6098_686336883.arc, что есть нормальная ситуация.
Бывает, что лог накатиться не может, по причине пропуска предыдущего. Но оракел генерит теже коды ошибок.

Step 3. Copy archive logs
1_5976_686336883.arc 520KB sent to reportdb02
1_5977_686336883.arc 2267KB sent to reportdb02
 
Step 3. Delete archive logs
############################################################
### Ship Logs End Time: Fri Nov 20 03:05:09 AST 2009 ###
############################################################

Step 4. Succeeded
 
Step 5. Recover standby
ORA-00279: change 631407184 generated at 11/20/2009 02:03:08 needed for thread
1
ORA-00289: suggestion : /u01/oraarch/hmsp/1_5975_686336883.arc
ORA-00280: change 631407184 for thread 1 is in sequence #5975
ORA-00278: log file '/u01/oraarch/hmsp/1_5975_686336883.arc' no longer needed
for this recovery
ORA-00308: cannot open archived log '/u01/oraarch/hmsp/1_5975_686336883.arc'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3

Можно как-то определить такую ситуацию, кроме как парсить файл?

Вячеслав Любомудров

Дата: 25.11.2009 03:00:19

Ну, наверное, лучше таки заглядывать в v$archived_log на стендбае, v$archive_gap, v$dataguard_%
Но и это не помогает

standby alert.log

Fri Oct  2 12:46:25 2009
Media Recovery Log /u/app/oracle/admin/xxx/arch/1_23320_625940070.arc
Fri Oct  2 12:47:17 2009
Hex dump of (file 5, block 322802) in trace file /u/app/oracle/admin/xxx/bdump/xxx_p001_27304.trc
Corrupt block relative dba: 0x0144ecf2 (file 5, block 322802)
Bad header found during media recovery
Data in bad block:
 type: 6 format: 2 rdba: 0x01440cf2
 last change scn: 0x0002.189bfa04 seq: 0x1 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xfa040601
 check value in block header: 0x3fae
 computed block checksum: 0x0
Reread of rdba: 0x0144ecf2 (file 5, block 322802) found same corrupted data
Fri Oct  2 12:48:19 2009
Media Recovery Waiting for thread 1 sequence 23321 (in transit)
Fri Oct  2 12:57:21 2009
Primary database is in MAXIMUM PERFORMANCE mode
RFS[2]: Successfully opened standby log 12: '/u/app/oracle/oradata/xxx/sredo12.log'
Fri Oct  2 12:57:38 2009
Media Recovery Log /u/app/oracle/admin/xxx/arch/1_23321_625940070.arc
Fri Oct  2 12:58:51 2009
Media Recovery Waiting for thread 1 sequence 23322 (in transit)

В результате на стендбае битый блок, а накат не остановился. Т.е. с виду все красиво, но если бы пришлось переключиться на этот стендбай...

Причем, стандартные методы ловли (парс на ORA-, error) пролетают, надо еще настраивать парс на corrupt, наверное

Relic Hunter

Дата: 25.11.2009 03:15:12

Вячеслав Любомудров

Ну, наверное, лучше таки заглядывать в v$archived_log на стендбае, v$archive_gap, v$dataguard_%
Но и это не помогает

Oracle 10g SE "unmanaged standby". В указанных вьюшках - пусто на стендбае.

Вячеслав Любомудров

Дата: 25.11.2009 03:33:08

Ну, парсить alert.log, наверное

standby alert.log

Tue Oct 21 17:35:25 2003
alter database recover automatic standby database
Media Recovery Start
Starting datafile 1 recovery in thread 1 sequence 40
Datafile 1: '/opt/oracle/admin/prod/data/system/system01.dbf'
...
Media Recovery Log
Media Recovery Log /opt/oracle/admin/prod/arch2/1_40.dbf
Media Recovery Log /opt/oracle/admin/prod/arch2/1_41.dbf
Media Recovery Log /opt/oracle/admin/prod/arch2/1_42.dbf
Errors with log /opt/oracle/admin/prod/arch2/1_42.dbf. -- Нету его
ORA-279 signalled during: alter database recover automatic standby database...

Tue Oct 21 17:58:51 2003
alter database recover automatic standby database
Media Recovery Start
Starting datafile 1 recovery in thread 1 sequence 42
Datafile 1: '/opt/oracle/admin/prod/data/system/system01.dbf'
...
Media Recovery Log
Media Recovery Log /opt/oracle/admin/prod/arch2/1_42.dbf
Errors with log /opt/oracle/admin/prod/arch2/1_42.dbf. -- До сих пор нет
ORA-279 signalled during: alter database recover automatic standby database...

Правда это тоже EE, но накат (и передача) ручной

Dimka9

Дата: 25.11.2009 04:07:47

умеешь ты обрадовать :)

судя по "наверное" у тебя такой проверки еще нет.

а оно никуда в v$ не идет (слабая надежда) ?

мелькала у меня мысль что alert.log нужно парсить не на предмет наличия ошибок, а вырезая "неошибочные" куски - но здесь просто грепом не обойтись.

зы
А интересно ЕМ ГЦ такую шнягу не пропустит?

Вячеслав Любомудров

Дата: 25.11.2009 04:28:21

Пропускает GC, к сожалению

Проверки пока нет, скорее всего и не будет (скажу по секрету, я вообще постоянно не парсю алерты, заметил случайно, у меня все логи на отдельный экранчик выводятся через colortail, я время от времени кидаю взгляд и все неровности сразу видны. Но если это будет ночью...).
Всегда думал, что при ошибке в накате накат должен остановится, приходим утром, видим это дело и устраиваем разбор полетов. Однако, не сраслось, как оказалось
Пока повесил еженедельный dbverify на стендбаях (боевые бэкапятся RMAN-ом, там поймается), но, видимо, придется рисовать парсинг (или искать где готовый, как-то

Ааз обмолвился, что они такое творили, аля DG для 7-ки) если ситуация еще повторится

Dimka9

Дата: 25.11.2009 04:41:01

по-моему они не такое творили: они делали ee из se скриптами. и вроде даже не от бедности, а бага была что стандбай вставал колом при каких то условиях.

ты про это? - этож у меня бага была :)

Вячеслав Любомудров

Дата: 25.11.2009 04:43:50

Что-то вроде того

kinky cat

Дата: 28.02.2012 09:53:56

Relic Hunter

Вячеслав Любомудров
Ну, наверное, лучше таки заглядывать в v$archived_log на стендбае, v$archive_gap, v$dataguard_% Но и это не помогает

Oracle 10g SE "unmanaged standby". В указанных вьюшках - пусто на стендбае.

займусь горобокопательством
как раз ковырял этот запрос
мониторится просто (странно что не было предложено) :


V$LOG_HISTORY displays log history information from the control file.

есс-но при накате он обновляется, и можно запросить его с mount стендбая