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

Neil, I had a similar result once whence I had mistakenly linked the dbspaces to the block special disk files rather than the raw devices. I was using ontape and was able to backup in 1 hour and took 12 hours to restore!! The problem was that the block special device uses the Unix cache! Hope this helps Silvester Valiente Informix DBA In article <6vcjda$77c$1@taliesin.netcom.net.uk>, "Neil Truby" <ntruby@netcomuk.co.uk> wrote: > 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 > > > > -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own