Re: When Informix dynamically allocates logical logs, do they dynamically unalloc?

NormaJean Sebastian via DBMonster.com wrote: > Hi all, > Haven't been tuning in much... that's the hazard of not getting the posting > directly to my mail-box anymore... > > anyway... > > I have seen IDS 9.4 (64 bit on Solaris) dynamically allocate locks. > It will do so, but not unalloc them. for example, if i have 1 mill locks, > and the activity blows past that, and IDS dynamically allocs more, say up > to 3.4 mill.... > well after the dust settles, the 3.4 mill locks are still there, it didn't > auto-drop back to the defined number (1 mill). Bouncing the DB sets it > back. That's more or less by design. > Tonight, I have witnessed our first dynamic log allocation (woooo hoooo... > pass the cigars!).... > IDS put it in rootdbs. we added more log space, and it started using that > as it's so smart :) > but I could not find info in the online manuals about what happens after > IDS doesn't need those dynamically alloc'd logs.... > i could not find that they would automatically unalloc. I'm 99% certain they don't auto-unalloc. > I suspect they do not auto-unalloc, just like the dynamic locks did not. > I suspect I have to manually drop them. Yes - me too. > I'm a bit squeamish about dropping anything in rootdbs. Why? Moving log logs out of rootdbs is good practice on systems big enough (with enough disk drives) to warrant the effort. It's pretty painless removing logs - you make sure they're backed up (not in use and not needed) and remove them, IIRC. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.01 -- http://dbi.perl.org/

academic discussion.... regarding dynamic locks: release notes (ids_unix_relnotes_9.40.txt), it says: Maximum locks per Dynamic Server system and database --Dynamic allocation so if we have locks at 2 mill, and it maxed at 3.4 mill.... if we change our setting to 5 million, would it max at ....6.4 mill?.... is it a function of how much space there is to hold the locks (we did see Vsegs allocating) or how big the internal field is to hold the locks (ie smallint, integer, etc)? and how much memory/space does 1 lock take? (we forget to change a table to page locking before this run, but i am still curious) Regarding dynamic logs, yup, you are right, they do not un-alloc. The engine was bounced twice overnight, and the rootdbs logs still live. onstat -l says:address number flags uniqid begin size used %used 1438c4f00 1 U-B---- 166801 110:3 5000 5000 100.00 ......... 143457188 10 U-B---- 166810 8:5053 5000 5000 100.00 ......... 143b4a550 303 U-B---- 166455 133:81449 5000 5000 100.00 The "Begin" address (chunk# : offset) therefore "110:3 " is in the logdbs onstat -d|grep ' 110 ' (chunkpath names abbreviated) 143b61820 110 8 762008 286557 1554 PO-- ..../physdev9/data23 onstat -d|grep ' 8 ' |head 143b6e7a8 8 0x2 8 2 M informixlogdbs and "8:5053" is in also in logdbs: 143b529b8 8 8 10114 175106 53 PO-- .../physdev3/data3 and "133:81449" is in rootdbs: 143b51d90 133 1 536574 349992 228553 PO-- ...dev1/data10 143b6d028 133 1 8 349992 0 MO-- ...dev15/data1 142787e58 1 0x20002 1 7 M informix rootdbs > > I'm a bit squeamish about dropping anything in rootdbs. > Why? Moving log logs out of rootdbs is good practice on systems big > enough (with enough disk drives) to warrant the effort. It's pretty > painless removing logs - you make sure they're backed up (not in use and > not needed) and remove them, IIRC. IIRC? yes, i agree and have moved logs from root, but i have practiced the "don't touch" root theory for so long, it's been years. and normally i only touch it early in the game when building the engine... you know... move the 3 logs out of root. OK... we'll whacky-whacky when activity slows down.