Re: Very slow running of onload on V7.24 UC6

I should have explained that the database is being loaded into a newly-created instance that has nothing else in it (other than the system tables). Given what you say about checking the pages being written to, I'm still at a loss to explain why onload's a factor of 5-10 slower. Thanks for your interest Neil June Tong wrote in message <36198880.14C8ED53@hotmail.com>... >Neil Truby wrote: > >> I've unloaded to DAT a database which is about 10 GBytes in size. This took >> about 2.5 hours. An ontape -s takes about the same time. I'm now doing the >> onload into another database, and it's incredibly slow. The onload is >> running at a rate of about 1000 disk writes per minute, i.e. it'll take >> about 16 hours to complete! By comparison, an ontape restore takes about >> 3 -4 hours. >> >> Why the disparity in time? I thought these binary write utilities did >> more-or-less the same things. Also why, according to onstat -D, is onload>> reading every page before writing to it ? > >Well, I don't know about the 4-5x difference in time, but I would definitely >expect ontape to be faster, assuming that your onunload was approximately the >same size (I mean, the database you onunload'ed was most of the data in your >instance, as opposed to having a huge instance with several databases, and only >onunload'ing one small one). > >Ontape writes all your pages to tape, and then puts them all back again, exactly >where it took them from. It doesn't care what, if anything, was on the page >it's writing to, because everything it needs is on the tape, and you're going to >lose everything that was there before. > >Onload writes just your database and table into an *existing* OnLine instance. >The tables are not going to go back to the same place they came from. For >example, if your table's partnum was 0x300005, and this new instance already has >a partnum 0x300005, obviously your table is going to need a new partnum. (In >fact, I'd bet it doesn't even attempt to put things in the same location.) So >now, everything that contained information on the table's partnum will have to >be modified. Likewise, if your table came from chunk 5, and spanned pages 100 - >500 of that chunk, but those pages are occupied, it will put your extent >somewhere else, and all the pages will have to be re-numbered. The Chunk Free >Lists have to be updated with the information on the new table that has been >added. The partition page will have to be updated with the information on the >extents. Ontape doesn't have any of these problems, because the old Chunk Free >List is restored, and all the information on it is still valid. > >Think of it as the difference between photocopying a manual, and just taking >certain sections from the manual and creating a new manual. Your new manual >will need the chapters re-numbered, and the table of contents and index >re-written, and all references to other pages will have to be changed. Same >sort of thing. > >June >-- >june_t@hotmail.com >Grounded in Palo Alto, living on Pepperidge Farm Double Chocolate Milano Cookies >