Expanded chunk capacity mode in 9.40

'Que? When I run onstat -d it says at the end: Expanded chunk capacity mode: disabled. I cannot see any obvious information about this in the release notes directory. Being flat-out, I don't really have a chance to scour the manuals yet. Can anyone give me a brief rundown of what this mode offers, and if it's useful, how do I enable and use this feature? I can definitely make use of chunks or offsets > 2Gb here. Thanks in advance - I promise, busy not just lazy.

Andrew Hamm wrote: > > 'Que? > > When I run onstat -d it says at the end: > > Expanded chunk capacity mode: disabled. > > I cannot see any obvious information about this in the release notes > directory. Being flat-out, I don't really have a chance to scour the manuals > yet. > > Can anyone give me a brief rundown of what this mode offers, and if it's > useful, how do I enable and use this feature? I can definitely make use of > chunks or offsets > 2Gb here. > > Thanks in advance - I promise, busy not just lazy. to enable this new feature you must use onmode -BC Take a quick look into 8.40 Admin Ref & Guide Warning: point of no return! To switch back means oninit -i. In 9.40.UC2 and UC3 we had problems on large chunks when doing inplace alter table. Those are fixed in 9.40.*C4, though. Looks like our shop *must* enable it now to overcome the fact that one cannot have a multichunk physical log and running log mode ANSI in a biggish shop this triggers checkpoints more dense than we want to have them (1 hour we want, 50 mins we get) I would not switch large chunks on without excessive testing when there is no need to do so. dic_k -- Richard Kofler SOLID STATE EDV Dienstleistungen GmbH Vienna/Austria/Europe

Richard Kofler wrote: > > to enable this new feature you must use onmode -BC > Take a quick look into 8.40 Admin Ref & Guide ok - in 9.40 I see trhat onmode reports the existence of -BC flag but the online PDF admin and reference guide for 9.40 doesn't describe it at all. I assume you really meant 8.40 and not 9.40 manuals? If so I don't have them immediately to hand. > triggers checkpoints more dense than we want to have > them (1 hour we want, 50 mins we get) You mean you want to have a checkpoint only every hour, but you get one every 50 minutes? The alternative interpretation is too horrible to consider :-> Sounds like there's a little bit more write activity going on with large chunks. Ahh well - i'll stick to tradition for this job. Thanks for the pointers.

On Tue, 31 Aug 2004 02:45:32 -0400, Andrew Hamm wrote: The documentation IS in the Administrators Reference for 9.4 (no not 8.4), page 3-44 in the Utilities section under the section for the onmode command in a sub-heading entitles "Allow Large Chunks Mode". -BC 1 allows reversion to pre-9.4 mode if no large chunks or large offsets have yet been used. Only chunks which are modified or added to take advantage of large offset/size features are modified. -BC 2 modifies all existing chunks to the new addressing format. Reversion to pre-9.4 compatibility is not possible. Art S. Kagel > Richard Kofler wrote: >> >> to enable this new feature you must use onmode -BC Take a quick look into >> 8.40 Admin Ref & Guide > > ok - in 9.40 I see trhat onmode reports the existence of -BC flag > > but the online PDF admin and reference guide for 9.40 doesn't describe it at > all. I assume you really meant 8.40 and not 9.40 manuals? If so I don't have > them immediately to hand. > >> triggers checkpoints more dense than we want to have them (1 hour we want, >> 50 mins we get) > > You mean you want to have a checkpoint only every hour, but you get one > every 50 minutes? The alternative interpretation is too horrible to consider > :-> Sounds like there's a little bit more write activity going on with large > chunks. > > Ahh well - i'll stick to tradition for this job. Thanks for the pointers.

"Andrew Hamm" <ahamm@mail.com> wrote ... > 'Que? thanks all for the replies. Even with your pointers I cannot see any mention in the indexes... So how do people /feeeel/ about the expanded chunks? Any positive or negative experiences? Richard sounds very cautious but I apart from a suggestion that there's a bit more dirty pages generated (is that the correct interpretation?) how does it tend to stack up? I've got a small margin of time to decide to use it; and must also consider that I haven't done this even on any of my office machines so it's going to be a first, and it will be going live.

The reason for the onmode -BC was for migration. If we had not gone this route, we would have faced extensive down time during the migration to convert the pages into the new format. Understand, inside the engine, everything is in BC 2 format. However, on disk, the page may be in old format. We have the three modes for conversion/reversion reasons. Basically with the initial format BC 0, everything is in the 2GB limit format. With BC1, you can create new dbspaces in >2GB format. And in BC2, writes are always in >2GB format. This allows reversion to be possible always in BC0 state. If you are in BC1 state, then you can still revert, but must first drop dbspaces using big chunk format. This state allows you to use big chunk format for things like temporary dbspaces and such --- basically a means to gain a bit of confidence. Once you go to BC2, there is no reversion. Our goal was to minimize conversion/reversion time, which I think that we did. The conversion time to 9.4 is roughly the same time as from 9.2 to 9.3. We had to convert the partition page extent list from using physical addressiong (3-nibbles for chunk + 5 nibbles for chunk offset) to using dbspace relative addressing ( 2GB pages per dbspace). However, in memory and in oncheck, the dbspace relative address is converted to big chunk format. Again, all in the interest of minimizing conversion down-time. In any case, understand that internally, the 9.4 server is doing everything in big-chunk format. It's just the IO that does any conversion. M.P. "Andrew Hamm" <ahamm@mail.com> wrote in message news:2pkioiFm1cv9U1@uni-berlin.de... > "Andrew Hamm" <ahamm@mail.com> wrote ... > > 'Que? > > thanks all for the replies. Even with your pointers I cannot see any mention > in the indexes... > > So how do people /feeeel/ about the expanded chunks? Any positive or > negative experiences? Richard sounds very cautious but I apart from a > suggestion that there's a bit more dirty pages generated (is that the > correct interpretation?) how does it tend to stack up? I've got a small > margin of time to decide to use it; and must also consider that I haven't > done this even on any of my office machines so it's going to be a first, and > it will be going live. > >

"Andrew Hamm" <ahamm@mail.com> wrote in message news:2pkioiFm1cv9U1@uni-berlin.de... > "Andrew Hamm" <ahamm@mail.com> wrote ... > > 'Que? > > thanks all for the replies. Even with your pointers I cannot see any mention > in the indexes... > > So how do people /feeeel/ about the expanded chunks? Any positive or > negative experiences? No really negative exepriences, over multiple sites. Some suspicion on one very bust database that when large chunks were first enabled there was a transient slowdown (which one might intuitively expect, as each page has to be read, processed and re-written in entireity) for a day or two, but I'm not convinced. Positives? Well, there's no doubt that the administration is simpler - fewer keystrokes to add one 10Gbyte lv and chunk than 5 x 2Gbyte ones. And you need to set up fewer HPL unload files due to the removal of the 2GByte limit (although you have to remember to enable largefiles on your systems). But, as I've said before - and I know I'm in a moinority of about one - I don't see the large chunks as a feature that's going to fundamentally change my life.

"Neil Truby" <neil.truby@ardenta.com> wrote in message news:2pldfqFm77ndU1@uni-berlin.de... > > No really negative exepriences, over multiple sites. Some suspicion on one > very bust ... Sorry, busy, not bust. That bloody receptionist .... > database that when large chunks were first enabled there was a > transient slowdown (which one might intuitively expect, as each page has to > be read, processed and re-written in entireity) Having read Madison's subsequent post I'm not sure that this is true now.