Adding BLOB Chunks to DBSpaces

My question is I added the following chunk to a dbspace using the following command. onspaces -a dbspacename -p /dev/mapper/rawpartition -o 8 -s 5120000 How come now when I run onstat -d update it shows the chunk as half the size? 2560000 KB. Size Free 185f9328 9 5 4 2560000 2515097 PO- B /dev/mapper/rootvg-tempdbs1 Thanks!

>My question is I added the following chunk to a dbspace using the following command. > >onspaces -a dbspacename -p /dev/mapper/rawpartition -o 8 -s 5120000> >How come now when I run onstat -d update it shows the chunk as half the size? 2560000 KB. > >Size Free >185f9328 9 5 4 2560000 2515097 PO- B /dev/mapper/rootvg-tempdbs1 > >Thanks! The onspaces command value is in KB's, but onstat -d reports the free space in pages. Jacques Renaut IBM IDS APD team

So to get the KB size I have to multiply times the Page size. Which in this case is 2X. Is that always the case? Also what does the column bpages mean? Most of the chunks its blank besides two that have a path /usr/informix Thanks!

>So to get the KB size I have to multiply times the Page size. Which in this case is 2X. Is that always the case? > No, there are two reasons that might not hold. In your case, since this is a blobspace, when you create the blobspace you give it a page size for the blob pages. The second would be that starting in version 10 (if I remember right) the configurable page size feature was added for non-blobspace dbspaces. Prior to that feature page sizes were 2K or 4K depending on platform. After that feature, when you created the dbspace, you could set the page size for it (up to a max of 16k). >Also what does the column bpages mean? Most of the chunks its blank besides two that have a path /usr/informix There are three types of dbspaces, regular dbspaces, smart blob spaces, and blobspaces. I believe the bpage column would only be used for a blobspace. There should be more info in Chapter 15 of the Administrator's Reference for the different columns of onstat output. > >Thanks!

page size is 2k on UNIX and 4k on windows. You can specify non default page sized when you created dbspace. The page size must be between 2KB and 16KB and must be a multiple of the default page size. Regards, -Ping --- On Wed, 5/13/09, DAMIAN PECNIK <damian.pecnik@pgnmail.com> wrote: > From: DAMIAN PECNIK <damian.pecnik@pgnmail.com> > Subject: Re: Adding BLOB Chunks to DBSpaces [15745] > To: ids@iiug.org > Date: Wednesday, May 13, 2009, 11:23 AM > So to get the KB size I have to > multiply times the Page size. Which in this > case is 2X. Is that always the case? > > Also what does the column bpages mean? Most of the chunks > its blank besides > two that have a path /usr/informix > > Thanks! > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the > discussion forum. > >

Ok I have been reading the documentation on plog. It says that it is flushed at 75% and you should never worry about it being full. This is one of the dbspaces I am trying to add a chunk to. The first circumstance under which the physical log buffer is flushed to disk is during any checkpoint. Once the checkpoint is complete, the physical log is cleared. So why does the plog need more space? Is it not getting flushed?

Why do you think that the physical log dbspace needs more space? Are you looking at onstat -d? Was there some message in the message log (onstat -m) that has given you concern? First, the physical log is fixed size. It is initialized when the engine is brought online during normal startup (or at the end of a successful fast recovery after an abnormal shutdown) to the size specified in the ONCONFIG parameter PHYSFILE. The space allocated to the physical log is treated as a circular buffer of pages. When the physical log is 'cleared' at the end of a checkpoint that space doesn't show as free in onstat -d, it is still allocated to the physical log, it is just that the log begin pointer is reset to the log tail pointer location marking it as empty. Next, note that the physical log isn't flushed at 75% full, you misunderstood the documentation. There are several events which will trigger a checkpoint depending on the engine version. All versions prior to 11.50 trigger a checkpoint when the CKPTINTVL has expired or when the physical log is 75% full. The checkpoint will eventually complete and that will clear the physical log as described above. However, note that the log will continue to fill if there is update activity on the server during the checkpoint that cannot be blocked (due to sessions in critical section). If the physical log reaches 100% full before the checkpoint completes, no harm is done, however, some data is at risk should the server crash before the checkpoint completes. That is one reason that the server will complain if it thinks that the physical log is too small. These messages may be what you are seeing. In 11.50 and later, with non-blocking checkpoints, the physical log can overflow into a disk file (PLOG_OVERFLOW_PATH) to increase data consistency in case of a crash during a checkpoint. Checkpoints are triggered autonomically based on the engine's determination of how long it will take to recover in case of a crash compared to SLA settings you make in the ONCONFIG file to set your maximum desirable recovery time. IBM has determined that this autonomic feature requires that the physical log be at least 100% of the size of the buffer pool and the engine will complain if it is not big enough by that rubrick. You may be seeing those messages. In the latter cases, you can increase the size of the physical log and/or move it to a different dbspace by using onparams. The change does not take effect until you bounce the instance. If you have to increase the size of the physical log and it current dbspace (ROOTDBS by default) does not have enough contiguous free space for the new log (the physical log must be a single contiguous extent) then, yes, you will have to add another -possibly larger - chunk to that dbspace or move the log to another dbspace that does have enough contiguous space. Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, May 13, 2009 at 1:44 PM, DAMIAN PECNIK <damian.pecnik@pgnmail.com>wrote: > Ok I have been reading the documentation on plog. It says that it is > flushed > at 75% and you should never worry about it being full. This is one of the > dbspaces I am trying to add a chunk to. > > The first circumstance under which the physical log buffer is flushed to > disk > is during any checkpoint. Once the checkpoint is complete, the physical log > is > cleared. > > So why does the plog need more space? Is it not getting flushed? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001636c5b1c7851fcf0469cfb572

Yes I am looking at onstat -d update. Also the script /cas/log/chkdbspace.log which I think is a GE Picture Perfect thing and not part of informix. Is the plog something else? onstat -d update IBM Informix Dynamic Server Version 9.40.UC3 -- On-Line -- Up 6 days 21:36:22 -- 194024 Kbytes Dbspaces address number flags fchunk nchunks flags owner name 17e8f7d8 1 0x20001 1 1 N informix rootdbs 1861e7c0 2 0x60001 2 1 N B informix basedbs 1861e910 3 0x20001 3 1 N informix llogdbs 1861ea60 4 0x20001 4 1 N informix plogdbs 1861ebb0 5 0x60001 5 2 N B informix tempdbs 1861ed00 6 0x20011 6 2 N B informix imagebbs 1861ee50 7 0x20001 7 1 N informix imagedbs 18620018 8 0x20001 8 1 N informix graphdbs 18620168 9 0x20011 9 1 N B informix graphbbs 9 active, 2047 maximum Waiting for server to update BLOB chunk statistics... Chunks address chunk/dbs offset size free bpages flags pathname 17e8f928 1 1 4 100000 94204 PO-- /dev/rrootdbs 1861d818 2 2 4 4797952 1113706 PO-B /dev/rbasedbs 1861d9a0 3 3 4 500000 235 PO-- /dev/rllogdbs 1861db28 4 4 4 16000 947 PO-- /dev/rplogdbs 1861dcb0 5 5 4 126000 124797 PO-- /dev/rtempdbs 1861de38 6 6 4 600064 0 600064 POB- /dev/rimagebbs 1861e018 7 7 4 19456 12299 PO-- /dev/rimagedbs 1861e1a0 8 8 0 15360 13780 PO-- /usr/informixdb/graphdbs 1861e328 9 9 0 240640 14996 15040 POB- /usr/informixdb/graphbbs 1861e4b0 10 6 4 550000 338066 550000 POB- /dev/mapper/rootvg-imagebbs1 1861e638 11 5 4 2560000 2559997 PO-B /dev/mapper/rootvg-tempdbs1 11 active, 32766 maximum Expanded chunk capacity mode: enabled /cas/log/chkdbspace.log One or more database spaces has exceeded 90% usage on lx000125. Please contact your system administrator. See below or check /cas/log/chkdbspace.log for the list of database spaces. 99% llogdbs 94% plogdbs 93% graphbbs

OK, I begin to understand your confusion. In your instance, it looks like someone set up separate dbspaces for the logical logs and for the physical log. This is not a bad thing, indeed it is a common recommendation and required for performance on a busy server if those dbspaces can be placed onto separate structures utilizing separate IO channels from the data dbspaces (or even from each other). However, unless someone has located data tables in those dbspaces along with the logical logs and physical logs, the physical log certainly will not expand unless you manually use onparams to increase its size. Similarly, unless you manually add new logical logs to the existing set of logs - or if you have the instance configured to automatically add a logical log if all of the current logs are full (a rarely used option BTW) - then neither will the logical logs expand beyond the space they are currently using. You have no fears for those dbspaces and there are many sites that operate with their logical and/or physical log dbspaces 100% full. No worries. The graphbbs blobspace on the other hand may actually need more space added to it, but you will have to determine that based on your current and future usage. If you have been keeping a history of how the free space in that dbspace has been drawn down over time you can estimate how much longer the free space that is there will last and plan accordingly. You should be tracking dbspace usage over time (as with many other telltales and metrics) so that you can plot them and compare them over time to understand the health of your server. Tools like AGS's Server Studio with Sentinel and (once you upgrade to 11.50) IBM's Open Admin Tool (OAT) can help you do that. OAT only works with IDS 11, not 9.40 (which by the way is out of support as of last month - you should upgrade while it is cheap - IBM has offered to upgrade anyone from any earlier version to IDS 11.50 for the price of a year's support only!) Server Studio does support IDS 9.40 (and all other version IB) and you got a free Basic function license along with your server when you bought it courtesy of IBM. Also when you enable SS for the first time, you can get a full feature 30 day trial also for free to see if the additional features are worth paying for. Contact AGS through their web site (www.serverstudio.com) for details. Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, May 13, 2009 at 2:59 PM, DAMIAN PECNIK <damian.pecnik@pgnmail.com>wrote: > Yes I am looking at onstat -d update. Also the script > /cas/log/chkdbspace.log > which I think is a GE Picture Perfect thing and not part of informix. Is > the > plog something else? > > onstat -d update> > IBM Informix Dynamic Server Version 9.40.UC3 -- On-Line -- Up 6 days > 21:36:22 > -- 194024 Kbytes> > Dbspaces > address number flags fchunk nchunks flags owner name > 17e8f7d8 1 0x20001 1 1 N informix rootdbs > 1861e7c0 2 0x60001 2 1 N B informix basedbs > 1861e910 3 0x20001 3 1 N informix llogdbs > 1861ea60 4 0x20001 4 1 N informix plogdbs > 1861ebb0 5 0x60001 5 2 N B informix tempdbs > 1861ed00 6 0x20011 6 2 N B informix imagebbs > 1861ee50 7 0x20001 7 1 N informix imagedbs > 18620018 8 0x20001 8 1 N informix graphdbs > 18620168 9 0x20011 9 1 N B informix graphbbs > 9 active, 2047 maximum > > Waiting for server to update BLOB chunk statistics... > > Chunks > address chunk/dbs offset size free bpages flags pathname > 17e8f928 1 1 4 100000 94204 PO-- /dev/rrootdbs > 1861d818 2 2 4 4797952 1113706 PO-B /dev/rbasedbs > 1861d9a0 3 3 4 500000 235 PO-- /dev/rllogdbs > 1861db28 4 4 4 16000 947 PO-- /dev/rplogdbs > 1861dcb0 5 5 4 126000 124797 PO-- /dev/rtempdbs > 1861de38 6 6 4 600064 0 600064 POB- /dev/rimagebbs > 1861e018 7 7 4 19456 12299 PO-- /dev/rimagedbs > 1861e1a0 8 8 0 15360 13780 PO-- /usr/informixdb/graphdbs > 1861e328 9 9 0 240640 14996 15040 POB- /usr/informixdb/graphbbs > 1861e4b0 10 6 4 550000 338066 550000 POB- /dev/mapper/rootvg-imagebbs1 > 1861e638 11 5 4 2560000 2559997 PO-B /dev/mapper/rootvg-tempdbs1 > 11 active, 32766 maximum > > Expanded chunk capacity mode: enabled > > /cas/log/chkdbspace.log > > One or more database spaces has exceeded 90% usage on lx000125. > Please contact your system administrator. > See below or check /cas/log/chkdbspace.log for the list of database spaces. > > 99% llogdbs > 94% plogdbs > 93% graphbbs > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001636c5a6de45e43f0469d0b129

Thank You. This site has been very quick and helpful in answering my questions. Although regarding upgrading to 11.4. I just started working on Informix in December as I was hired as Application Dev/support for GE Picture Perfect which uses informix. Before we had a contractor, business partner of GE do all of our work so I am trying to get up to speed on this so we can do more in house. I don't know what the deal is with our license or upgrading, but I will look into your suggestions. Thanks! Damian

One last question. I think the scrip that said by graphbbs dbspace was 90% full is wrong. It says it uses the Sys tables. My Output for onstat -d update for the graphbbs chunk is as follows. Chunks address chunk/dbs offset size free bpages flags pathname 1861e328 9 9 0 92160 5718 5760 If I am correct the bpages is 5760 and the amount of free bpages is 5718. That is not 90% usage. Perhaps the script is comparing the size column to free. but since this is a BLOB shouldn't it be bpages to free, does free mean free bpages in this case? Thanks