Re: restoring data with ontape...

ontape -r only writes pages that are actually used, yes. However, therewill be pages between extents that are not used such as extents that once belonged to tables that have been dropped. In this case since ontape uses lseek() to position for page writes there will be holes in the file that will fill in later as those free pages are allocated to extents. Since the chunk is a filesystem file and ontape (well actually the engine's oninit processes actually do the opening and writing) opened it for writing Linux truncated the file when it was opened and the current size just indicates the largest page address that was written to it. Everything is probably just fine. Art S. Kagel Gerald Backmeister wrote: > > Who can help me restoring my database correctly... > > We created a dbspace with a size of 1.8GB (onstat -d shows a size of 450.000 > pages > for that dbspace -> 1.843.200.000 Bytes). > These 1.8GB are stored in a linux-filesystem (no raw devices!). > > Now, we had to restore a complete level 0 archive. > After ontape restored the database, the file-size of the chunk was about > 1.1GB. > Onstat -d still shows 450.000 pages though. > > Was my backup restored completly? Does ontape only restore the data, > that was used in fact (the size of the chunk file does almost match the > value of > used bytes of the dbspace!)? > > Thanks in advance, > > Gerald