ontape restore sleeping

We are running 9.20HC3 on an HP-UX 11.11 box. I am running an ontape -r on 1 dbspace. We have a cooked file system and it has been on the same chunk (out of 16) for 6 1/2 hours now. The onstat -g ses shows the physreco thread sleeping. tid name rstcb flags curstk status 82 ontape cd845c98 Y--P--M 34568 cd845c98 cond wait(sm_read) 86 physreco cd8456d8 -----R- 68360 cd8456d8 sleeping(secs: 1) It's been sleeping for over 1 hour now that since I started monitoring it. Is this normal? The last full restore of the whole instance took 18 hours. Shouldn't a single dbspace restore take considerably less? TIA Kevin

Hi, I assume you are restoring that one dbspace from a full level 0 archive. Yes, restore of a single dbspace takes considerably less time. However, since ontape is a "single threaded" utility (i.e. there's no parallelism), it can take quite a while until is has advanced the tape to the position where the data of the dbspace to restore begins. In fact this can take just as long as when restoring the whole system. When an archive media is slower than the disks (which normally is the case), then just reading the tape can take as long as reading the tape and writing the data to disk. All the while ontape is sequentially searching through the tape, the corresponding thread in the server engine is sitting around without work. That's why it's gone sleeping. You need OS system utilities to check that the ontape process is still progressing - you should see I/O activity on the tape device. [ ON-Bar is optimizing such processes with the help of a storage manager (SM). In this scenario, each dbspace is backed up as a separate SM object, where the SM keeps records of where the objects are stored. Therefore the SM can find an object much quicker than ontape ... ] Regards, Martin -- Martin Fuerderer IBM Informix Development Munich Data Management Solutions forum.subscriber@iiug.org wrote on 02.11.2004 10:49:27: > We are running 9.20HC3 on an HP-UX 11.11 box. I am running an ontape -r on 1 dbspace. > We have a cooked file system and it has been on the same chunk (out of 16) for 6 1/2 hours > now. The onstat -g ses shows the physreco thread sleeping. > > tid name rstcb flags curstk status > 82 ontape cd845c98 Y--P--M 34568 cd845c98 cond wait(sm_read) > 86 physreco cd8456d8 -----R- 68360 cd8456d8 sleeping(secs: 1) > > It's been sleeping for over 1 hour now that since I started monitoring it. Is this normal? The > last full restore of the whole instance took 18 hours. Shouldn't a single dbspace restore take > considerably less? > > TIA > > Kevin >