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

Hi, Neil, Sorry -- so slow replying to this one that it expired, forcing me to go dig it out of archives... My point is that even if your instance is newly created and has nothing else in it, onload is not trying to put the pages back where they came from. It doesn't attempt to maintain dbspace locations, it certainly doesn't restore the extent fragmentation. Therefore, even if all the same pages *are* available to it, it is still going to go through this big re-numbering of all the references. If your table was partnum 0x300005, and there aren't any other tables in the dbspace, it's still not going to re-use 0x300005. It's going to use 0x300002, because that's the first one that's available (I think), or maybe even 0x100003, because maybe you didn't specify that it should go in dbspace 3. And then it's going to have to create a new partition page for your table. I don't know that this accounts for all the difference in performance (5x is a lot), but I'm saying the two utilities are doing very different things. June -- june_t@hotmail.com Grounded in Palo Alto, living on M&M's (peanut) Original message: 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 >