Re: Expanded chunk capacity mode in 9.40

Neil, Even when going to BC2, we don't scan and re-write the pages in the new format. We had a bit in the page that was used only in the physical log. With 9.4, we re-did how we managed the physical log so that we no longer needed that bit. So we are now using that bit to identify the page as being in new format. The conversion of the page from the old to new format is only taking about 6 'c' instructions to the IO path. Basically moving a few things arround on the page header. So I really doubt that it would cause any significant impact. M.P. "Neil Truby" <neil.truby@ardenta.com> wrote in message news:2pled0Fm4c5oU1@uni-berlin.de... > "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. > >

Madison Pruet wrote: > > Even when going to BC2, we don't scan and re-write the pages in the > new format. thanks for all the techie bits - i'm going to forward that to a few of my cow-orkers so they feel warm and fuzzy about using it. While we're on the subject of the physical log, when I tried moving it on two seperate yet very similar engines, it neglected to actually bounce itself. The onparams just returned to command like in less than a second. I thought, "huh?", re-issued the command, checked the online status. So i tried onmode -k and a re-start, and then it started to move the log as usual. Wierd. The only contributing factor I can think of is that I used a binary search to zero in on the absolutely largest possible plog that will fit into the target space - ie (with random numbers picked here) onparams -p -d plogdbs -s 199900 # response: too big onparams -p -d plogdbs -s 199800 # response - are you sure etc? N onparams -p -d plogdbs -s 199850 # response: are u sure? N When I found the size that was the smallest possible that was too big to fit, I had the best fit. So I ran it once more with X and noticed the behaviour described. On another build of a temporary engine, where I couldn't be bothered searching for the best fit, the engine bounced itself in the usual manner. I guess it's possible that my search ritual has confused something somewhere, but the confused state could only have been left somewhere deep in a bit of engine code... As for building a test-case and finding the true operator-cause, that'll have to wait for some other 60 seconds. Especially if nobody else can reproduce it easily.