Re: dbload question

"Surfer!" wrote: > > Using Informix Online 7.30.UC3. > > Doing a dbexport/dbimport to create a new instance on the same machine > on new disks which will then become live. > > A table on the old instance is in one dbspace. Here is some edited > output from 'oncheck -pT': > > Current serial value 12097203 > First extent size 435120 > Next extent size 43512 > Number of pages allocated 773995 > Number of pages used 755554 > Number of data pages 353204 > > Type Pages > ---------------- ---------- > Free 18441 > Bit-Map 188 > Index 402162 > Data (Home) 353204 > ---------- > Total Pages 773995 > > The new instance has 3 dbspaces with the table fragmented by round- > robin. When it was loaded there was the following result (again edited > oncheck -pT output):> > Table fragment in DBspace dbspace_1 > > Current serial value 12088627 > First extent size 837923 > Next extent size 83792 > Number of pages allocated 499947 > Number of pages used 117682 > Number of data pages 117652 > Number of rows 4000155 > > Type Pages > ---------------- ---------- > Free 382265 > Bit-Map 30 > Index 0 > Data (Home) 117652 > ---------- > Total Pages 499947 > > In other words one extent has been created through the whole of the > extent for each of the three dbspaces! > > Does anyone have any light to shed on this? I'm sorry, what was the question? > Known bug? What is? > 'feature'? Erm... The figures look about right to me. I presume you have 3 of those fragments, each storing 117652 data pages, which matches up to the 353204 in the original table. Then the indexes are detached. The extent sizes didn't get used due to lack of contiguous space. In any case, they have been nearly doubled, giving 6 times the original storage! > PS we are going to specify the initial & next extent sizes to attempt to > resolve the problem. It would appear that you need to tune your extent sizes because they don't fit in those dbspaces, but what WAS the problem? Cheers, -- Mark. +----------------------------------------------------------+-----------+ | Mark D. Stock mailto:mdstock@mydas.freeserve.co.uk |//////// /| | http://www.informix.com http://www.informixhandbook.com |///// / //| | http://www.iiug.org +-----------------------------------+//// / ///| | |This email will self-destruct in |/// / ////| | |10 sec. If you received this email |// / /////| | |in error, sorry about the mess. |/ ////////| +----------------------+-----------------------------------+-----------+

In article <8pouc5$86v$1@news.xmission.com>, Mark D. Stock <mdstock@myda s.freeserve.co.uk> writes > >"Surfer!" wrote: >> >> Using Informix Online 7.30.UC3. >> >> Doing a dbexport/dbimport to create a new instance on the same machine >> on new disks which will then become live. >> >> A table on the old instance is in one dbspace. Here is some edited >> output from 'oncheck -pT': >> >> Current serial value 12097203 >> First extent size 435120 >> Next extent size 43512 >> Number of pages allocated 773995 >> Number of pages used 755554 >> Number of data pages 353204 >> >> Type Pages >> ---------------- ---------- >> Free 18441 >> Bit-Map 188 >> Index 402162 >> Data (Home) 353204 >> ---------- >> Total Pages 773995 >> >> The new instance has 3 dbspaces with the table fragmented by round- >> robin. When it was loaded there was the following result (again edited >> oncheck -pT output):>> >> Table fragment in DBspace dbspace_1 >> >> Current serial value 12088627 >> First extent size 837923 >> Next extent size 83792 >> Number of pages allocated 499947 >> Number of pages used 117682 >> Number of data pages 117652 >> Number of rows 4000155 >> >> Type Pages >> ---------------- ---------- >> Free 382265 >> Bit-Map 30 >> Index 0 >> Data (Home) 117652 >> ---------- >> Total Pages 499947 >> >> In other words one extent has been created through the whole of the >> extent for each of the three dbspaces! >> >> Does anyone have any light to shed on this? > >I'm sorry, what was the question? > >> Known bug? > >What is? > >> 'feature'? > >Erm... > >The figures look about right to me. I presume you have 3 of those >fragments, each storing 117652 data pages, which matches up to the >353204 in the original table. Then the indexes are detached. > >The extent sizes didn't get used due to lack of contiguous space. In any >case, they have been nearly doubled, giving 6 times the original >storage! > >> PS we are going to specify the initial & next extent sizes to attempt to >> resolve the problem. > >It would appear that you need to tune your extent sizes because they >don't fit in those dbspaces, but what WAS the problem? that the dbimport with no extent sizes specified (initial or next) went and created enormous extents which completely filled the new dbspaces, each of which was not a lot smaller than the original single dbspace. > >Cheers, -- Surfer!