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

I raised the "problem" with Informix. My central point was that my experience with onunload/onload in the past has been that it is of comparable speed to ontape. Now it's 5x slower. I've recently moved sites and consequently moved from Solaris -> HP-UX. To parahrase the answer I got from Informix Tech Support, it's all to do with their product being much better suited to, and primarily developed on, Solaris, and therefore some utiltiy performance will be much better on Solaris. I'm not sure I believe this, but I'm clearly not going to get any further with it! Neil June Tong wrote in message <36354A6E.C9E8141C@hotmail.com>... >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 >> >