Re: I/O error trying to recover log backup

Hi Martin,

Maybe let us continue with trying to solve this using command line, since
using DB Manager GUI introduces another possibility of errors (i.e. I don't
the commands that it is executing behind the scenes). So the question is: I
create standby using the scripts below. Why is log volume (LOG_001) not
being created? This is probably the cause of this error that I mentioned:

ERR
-24988,ERR_SQL: SQL error
-902,I/O error
3,Database state: OFFLINE
6,Internal errorcode, Errorcode 9050 "disk_not_accessible"
20017,RestartFilesystem failed with 'I/O error'

DB version: 7.6.00.27 on SUSE 10.0, 64-bit

DB folder contents (you can see backup files here, owner sdb):
---------------------------
burvisdb2:/opt/sdb/data/wrk/BURVIS # ls -l
total 102275
drwxrwx---  3 sdb sdba      544 Jan 22 17:19 .
drwxrwx---  6 sdb sdba      616 Jan 22 17:12 ..
-rw-r-----  1 sdb root  3670016 Jan 22 17:12 BURVIS_COM
-rw-r-----  1 sdb root  4128768 Jan 22 17:12 BURVIS_LOG.001
-rw-r-----  1 sdb root   262144 Jan 22 17:12 BURVIS_LOG.002
-rw-rw----  1 sdb sdba 81920000 Jan 22 17:12 DAT_001
drwxrwxrwx  4 sdb sdba      128 Jan 22 17:18 DIAGHISTORY
-rw-rw----  1 sdb sdba  1021262 Jan 22 17:19 KnlMsg
-rw-rw----  1 sdb sdba  1021262 Jan 22 17:15 KnlMsg.old
-rw-rw----  1 sdb sdba    28672 Jan 22 17:19 KnlMsgArchive
-rw-rw----  1 sdb sdba      566 Jan 22 17:12 dbm.knl
-rw-rw----  1 sdb sdba      388 Jan 22 17:12 dbm.mdf
-rw-rw----  1 sdb sdba      373 Jan 22 17:14 dbm.mmm
-rw-rw----  1 sdb sdba     5984 Jan 22 17:19 dbm.prt
-rw-rw----  1 sdb sdba   819234 Jan 22 17:19 dbm.utl
-rw-rw----  1 sdb sdba   844478 Jan 22 17:19 knldiag
-rw-rw----  1 sdb sdba     3161 Jan 22 17:19 knldiag.err
-rw-rw----  1 sdb sdba   844478 Jan 22 17:15 knldiag.old
-rw-rw----  1 sdb sdba   106496 Jan 22 17:19 knldump
-rw-rw----  1 sdb sdba  9920512 Jan 22 17:19 knltrace


The scripts:

############## create_db_standby.sh ########################
#!/bin/bash
export DB_DATABASE=BURVIS

echo "drop database $DB_DATABASE"
_o=`cat <<EOF | dbmcli -d $DB_DATABASE -u dbm,dbm 2>&1
db_offline
db_drop
quit
EOF`
_test=`echo $_o | grep OK`
if [ "$_test" = "" ]; then
        echo "Could not drop database $DB_DATABASE" 1>&2
fi

echo "create database $DB_DATABASE"
_o=`cat <<EOF | dbmcli 2>&1
db_create BURVIS dbm,dbm
quit
EOF`
_test=`echo $_o | grep OK`
if [ "$_test" = "" ]; then
        echo "Could not create database $DB_DATABASE" 1>&2
        exit 1
fi

echo "set db parameters"
dbmcli -d $DB_DATABASE -u dbm,dbm -i create_db_standby.sql

echo "recover database"
_o=`cat <<EOF | dbmcli -uUTL -d $DB_DATABASE -u dbm,dbm 2>&1
recover_start burvis
recover_start burvlog LOG 001
quit
EOF`
_test=`echo $_o | grep OK`
if [ "$_test" = "" ]; then
        echo "Could not recover database $DB_DATABASE" 1>&2
        exit 1
fi

############## create_db_standby.sql ###############
param_startsession
param_init
param_put MAXUSERTASKS 100
param_put DEFAULT_CODE UNICODE
param_put _UNICODE YES
param_checkall
param_commitsession
param_addvolume 1 LOG LOG_001 F 10000
param_addvolume 1 DATA DAT_001 F 20000
db_admin
medium_put burvis BURVIS_COM FILE DATA
medium_put burvlog BURVIS_LOG FILE LOG
###################################################

On 1/18/07, Brunzema, Martin <[email protected]> wrote:
>
>
>
> > -----Original Message-----
> > From: Eduard M [mailto:[email protected]]
> > Sent: Wednesday, January 17, 2007 12:09 PM
> > To: [email protected]
> > Subject: I/O error trying to recover log backup
> >
> > Now I get the following error trying to recover log backup.
> > The log files
> > are present, they are called BURVIS_LOG.001 and
> > BURVIS_LOG.002, owner sdb
> > user. I have a suspicion that this is because there is no log
> > volume file
> > itself in the directory (LOG_001). However I don't know why
> > that is. There
> > is also no log volume file (physically) on my master
> > database, although I've
> > created it in Database Manager and it shows there in the GUI.
> > ------
> > medium_put burvlog BURVIS_LOG FILE LOG
> >
> > burvis@burvisdb2:~/maxdb> dbmcli -d STANDBY -u dbm,dbm -uUTL
> > dbmcli on STANDBY>recover_start burvlog LOG 001
> > ERR
> > -24988,ERR_SQL: SQL error
> > -902,I/O error
> > 3,Database state: OFFLINE
> > 6,Internal errorcode, Errorcode 9050 "disk_not_accessible"
> > 20017,RestartFilesystem failed with 'I/O error'
> >
> > ---
> > dbmcli on STANDBY>
> >
> > knldiag.err:
> > ------------------------
> >
> > 2007-01-17 12:21:18                          --- Starting GMT
> > 2007-01-17
> > 10:21:18           7.6.00   Build 027-123-124-939
> > 2007-01-17 12:22:26 31672 ERR 11987 IO/READ  read error:
> > rc=0, wanted=8192,
> > 'NO ERROR(0)', try again
> > 2007-01-17 12:22:27 31672 ERR 11987 IO/READ  read error:
> > rc=0, wanted=8192,
> > 'NO ERROR(0)', try again
> > 2007-01-17 12:22:28 31664 ERR 11000 vattach  dev0_vattach
> > returned FALSE
> > 2007-01-17 12:22:28 31664 ERR 20027 IOMan    Attach error on
> > log volume 1:
> > Could not open volume
> > 2007-01-17 12:22:28 31664 ERR     3 Admin    Database state: OFFLINE
> > 2007-01-17 12:22:28 31664 ERR     6 KernelCo  +   Internal errorcode,
> > Errorcode 9050 "disk_not_accessible"
> > 2007-01-17 12:22:28 31664 ERR 20017 Admin     +
> > RestartFilesystem failed
> > with 'I/O error'
> > 2007-01-17 12:22:34     0 ERR 12009 DBCRASH  Kernel exited
> > due to signal
> > 0(Killed after timeout with state SERVER_KILL)
> > 2007-01-17 12:22:34                          ___ Stopping GMT
> > 2007-01-17
> > 10:22:34           7.6.00   Build 027-123-124-939
> >
>
> Hello Eduard,
>
> you need the logvolume on your shadow database. Otherwise a log-
> recovery is not possible.
> The best way to ensure a working shadow database is to create
> it from a databackup of the master database. You'll be able to
> do this using the installation wizard of the dbmgui. You only
> have to take care that you change some paths (e.g. RUNDIRECTORY
> and DIAG_HISTORY_PATH). If your are using absolute paths for
> your volumes (data and log) these needs also to be changed.
> You have the chance to change parameters within the installation
> wizard. At least do not restart the database but only recover the
> databackup. Then you are able to recover the logbackups as you
> need.
>
> Kind regards, Martin
>