While using a script to "feed" a shadow database with logs, we quite often see, that a recover_cancel is issued, dbmcli returns with 0 but if another log is available and db_admin is executed, it fails with
>db_admin ERR -24783,ERR_WRONGDBSTATE: Operational state UNKNOWN of the database instance is unsuitable. -24779,ERR_DBSTATENEEDED4: Database instance must be in one of the operational states OFFLINE, ADMIN, STANDBY or ONLINE.
The script we use looks like
db_admin db_connect recover_start logsich log 14327 recover_replace logsich /archivelog/log 14328 recover_replace logsich /archivelog/log 14329 recover_replace logsich /archivelog/log 14330 recover_replace logsich /archivelog/log 14331 recover_replace logsich /archivelog/log 14332 recover_replace logsich /archivelog/log 14333 recover_replace logsich /archivelog/log 14334 recover_replace logsich /archivelog/log 14335 recover_replace logsich /archivelog/log 14336 recover_replace logsich /archivelog/log 14337 recover_cancel
If the script is started a minute later, it works flawlessly.
This behaviour creates quite a lot of false alarms (happens up to 10 times a day).
I know, I could simply add a sleep command, I just want to know, why recover_cancel returns 0 despite the database engine not having released yet the shared memory and is really offline.
Markus