Привет всем.

Ситуация печальная. Подвисла продуктивная база для SAP (db2 9.7.0.4). Остановить базу через force, не получилось. Перегрузили LPAR. База не поднялась, db2diag.log :

2013-01-17-10.13.15.309548+120 E1493989509A949 LEVEL: Critical
PID : 7602320 TID : 75304 PROC : db2sysc 0
INSTANCE: db2bip NODE : 000 DB : BIP
APPHDL : 0-63 APPID: *LOCAL.db2bip.130117081313
AUTHID : SAPBIP
EDUID : 75304 EDUNAME: db2agent (BIP) 0
FUNCTION: DB2 UDB, base sys utilities, sqeLocalDatabase::MarkDBBad, probe:10
MESSAGE : ADM14001C An unexpected and critical error has occurred:
"DBMarkedBad". The instance may have been shutdown as a result.
"Automatic" FODC (First Occurrence Data Capture) has been invoked and
diagnostic information has been recorded in directory
"/db2/BIP/db2dump/FODC_DBMarkedBad_2013-01-17-10.13.15.307549_0000/".
Please look in this directory for detailed evidence about what
happened and contact IBM support if necessary to diagnose the
problem.

После рестарта LPAR, в директории для оперативных журналов, обнаружилось подозрительно большое кол-во файлов, а именно - 258.

Поиск привел сюда.

В db2diag.log присутствует:

2013-01-17-06.51.31.060440+120 I1492667378A589 LEVEL: Info
PID : 33226854 TID : 4114 PROC : db2sysc 0
INSTANCE: db2bip NODE : 000 DB : BIP
EDUID : 4114 EDUNAME: db2loggr (BIP) 0
FUNCTION: DB2 UDB, data protection services, sqlpgadf, probe:510
DATA #1 : <preformatted>
Database is generating log files faster than they can be archived.
4 files left before reaching maximum allowable unarchived files.
Check that the archiving is working properly.
DB2 will wait up to 5 minutes

1. Почему могла возникнуть такая ситуация с активными журналами транзакций?
2. Спас ли в такой ситуации HADR (база не поднялась, переключились на standby)?

Укладываю часть лога с ошибками, c момента, когда база работала.

Приняли решение поднять базу из бэкапа и выполнить pint in time recovery.

m72, имелось ввиду это ?

Log retain for recovery status = RECOVERY
User exit for logging status = YES
Catalog cache size (4KB) (CATALOGCACHE_SZ) = 2560
Log buffer size (4KB) (LOGBUFSZ) = 2048
Log file size (4KB) (LOGFILSIZ) = 65536
Number of primary log files (LOGPRIMARY) = 20
Number of secondary log files (LOGSECOND) = -1
Changed path to log files (NEWLOGPATH) =
Path to log files = /db2/BIP/db2bip/NODE0000/SQL00001/SQLOGDIR/
Overflow log path (OVERFLOWLOGPATH) =
Mirror log path (MIRRORLOGPATH) =
First active log file = S1773243.LOG
Block log on disk full (BLK_LOG_DSK_FUL) = YES
Block non logged operations (BLOCKNONLOGGED) = NO
Percent max primary log space by transaction (MAX_LOG) = 0
Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 500
Percent log file reclaimed before soft chckpt (SOFTMAX) = 300
Log retain for recovery enabled (LOGRETAIN) = RECOVERY
User exit for logging enabled (USEREXIT) = OFF
HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC
First log archive method (LOGARCHMETH1) = DISK:/db2/BIP/log_archive/
Options for logarchmeth1 (LOGARCHOPT1) =
Second log archive method (LOGARCHMETH2) = VENDOR:/usr/tivoli/tsm/tdp_r3/db264/libtdpdb264.a
Options for logarchmeth2 (LOGARCHOPT2) = /db2/BIP/tdp_r3/vendor.env
Failover log archive path (FAILARCHPATH) = /db2/BIP/log_archive/log_failure/
Number of log archive retries on error (NUMARCHRETRY) = 5
Log archive retry Delay (secs) (ARCHRETRYDELAY) = 20
Log pages during index build (LOGINDEXBUILD) = OFF

Базу восстановили, файловая система и TSM ошибок не показали.

Вся это как минимум странно и ситуация может повториться, без PMR не обойтись. Жаль что в панике соблазнились на перезапуск LPAR, забыли собрать диагностическую информацию.

Не делайте так.

По поводу кол-ва активных логов, решили выставить параметр Number of secondary log files (LOGSECOND) = 0 и обойтись основными журналами. Посмотрим.

Марк хотелось бы прочитать Ваше мнение на счет этой ситуации.