onstat -g iof: gfd and chunk number

Greetings. I am *SO* sure I have asked this question before but I can't locate it within the forum so here I go, perhaps again. When I enter the command: onstat -g iof, the first line of each chunk's I/O stats looks something like this: gfd pathname bytes read page reads bytes write page writes io/s 3 root_file 1548288 756 286720 140 626.0 (Sorry, I can't make the columns line up unless you paste the 2 lines into a text editor with a fixed-width font.) There are two things missing from this output: - The complete path of the chunk, which would avoid confusion in the unlikely event of an admin creating identical symlinks in different directories - An offset, which would distinguish multiple chunks created at different locations within a raw character device file (or even cooked file). (I have actually encountered this condition at a client and had to untangle their setup. Fun project!) A possible cure is to map the gfd (global file descriptor) above to a chunk number. I already have seen that if there is no gap in chunk numbers, the gfd is the chunk number + 2. However, this is not reliable; if there is a gap in the chunk numbers, e.g. chunk 5 had been dropped before the most recent engine bounce, this simple formula falls apart. Chunk[4] would be open as gfd[6] and chunk[6] would be open as gfd[7] (rather than gfd[8]). (Ah, he finally gets to the point!) Is there a totally reliable way to map a chunk's gfd number to its chunk number? Thanks much! -- Jacob (with the long-winded fingers :-)

For a reliable way to map gfd to unix path names look at s= ysmaster:sysiohistory table John F. Miller III STSM, Lead&nbs= p; Architect [1]miller3@us.ibm.c= om 503-747-1366 IBM Informix Dynamic Server (IDS) <= font color=3D"#990099">-----ids-bounces@iiug.org wrote: ----- >To: ids@iiug.org >From: "JACOB SALOMON" >Sent by: ids-bou= nces@iiug.org >Date: 10/22/2014 03:14PM >Subject: onstat -g iof= : gfd and chunk number [34022] > >Greetings. I am *SO* sure = I have asked this question before but I >can't locate it within the = forum so here I go, perhaps again. When >I enter the command: onsta= t -g iof, the first line of each chunk's >I/O stats looks something = like this: gfd pathname bytes read page >reads bytes write page wri= tes io/s 3 root=5Ffile 1548288 756 286720 >140 626.0 (Sorry, I can= 't make the columns line up unless you paste >the 2 lines into a tex= t editor with a fixed-width font.) There are >two things missing fr= om this output: - The complete path of the >chunk, which would avoid= confusion in the unlikely event of an admin >creating identical sym= links in different directories - An offset, >which would distinguish= multiple chunks created at different >locations within a raw charact= er device file (or even cooked file). >(I have actually encountered = this condition at a client and had to >untangle their setup. Fun pro= ject!) A possible cure is to map the >gfd (global file descriptor) = above to a chunk number. I already have >seen that if there is no ga= p in chunk numbers, the gfd is the chunk >number + 2. However, this = is not reliable; if there is a gap in the >chunk numbers, e.g. chunk= 5 had been dropped before the most recent >engine bounce, this simp= le formula falls apart. Chunk[4] would be >open as gfd[6] and chunk[= 6] would be open as gfd[7] (rather than >gfd[8]). (Ah, he finally g= ets to the point!) Is there a totally >reliable way to map a chunk's= gfd number to its chunk number? >Thanks much! -- Jacob (with the = long-winded fingers :-) >********************************************= ************************* >********** Forum Note: Use "Reply" to p= ost a response in the >discussion forum. References 1. 3D"mailto:miller3@us.ibm.com"

Thanks, John; it was a worthy effort and should have been so simple. The problem, Brutus, is not with our version but with our client. :-) On second thought, the problem *is* with our version! My client is still on 11.5 with heels dug in against an upgrade to even 11.7; sysiohistory does not exist in release 11.5. (Even an activist DBA like me needs to refrain from unilaterally upgrading a machine he doesn't own. These guys won't let me have a little fun! ;-) However, onstat -g iof is *still* getting its information from SOMEWHERE. If I could find a sysmaster table (most likely a view) that included the gfd of each open chunk file I think it's a good bet that it would include the chunk number on which to join to syschunks. All that said, I was hoping to find a non-SQL way to accomplish this. I want the script I'm writing to be useable even while a restore is running (and SQL cannot work then.) And with the above said, I was hoping to make it useful outside my own environment. In my case, I have an easy solution because of a naming convention I imposed here: Just from looking at the path name of a chunk you can see the name of the server, dbspace, primary or mirror, and which chunk number it is within its dbspace. And all offsets are 0. But I have worked in environments where they had created godzillions of chunks at different offsets in one huge device file. There, the raw output of onstat -g iof was unhelpful because they all had the same file name. (That it's sans path is a separate issue.) I want my new utility (not revealing yet) to be able to work in even such a nutty environment and even when SQL is unavailable. BTW, with my naming convention, if I were willing to use SQL (and give up on that ability to run when not quite on-line) I could get all the info I wanted from a couple of syschk<xxx> views in sysmaster. But this easy way out is not the general solution I seek. (Whew! Still with me, folks? :) -- Jacob S. (In pursuit of the most undomesticated, semi-aquatic avian yet)

Hi, Probably not portable nor what you want ... but perhaps something to consider? The gfds are the offset into the open files for the process ... bear in mind things like sqlexplain.out and (as can be seen) the message file will also get a gfd For example: > onstat -g iof | grep "^[0-9]"3 rootdbs 10551296 5152 2291712 1119 1228.1 4 physdbs 24576 12 2269184 1108 370.1 5 logdbs 139264 68 4960256 2422 842.3 6 tempdbs_01 6144 3 22528 11 155.0 7 tempdbs_02 6144 3 77824 38 121.9 8 sbspace_01 34816 17 8192 4 925.3 9 datadbs_01 5173248 2526 0 0 3202.0 10 datadbs_02 2152448 1051 0 0 979.1 jj-prepsuse-a:/home/informix # ps -ef | grep oninit | grep " 1 " informix 4570 1 0 15:52 ? 00:00:03 oninit jj-prepsuse-a:/home/informix # ls -l /proc/4570/fd total 0 lr-x------ 1 root root 64 Oct 23 15:56 0 -> /dev/null l-wx------ 1 root root 64 Oct 23 15:56 1 -> /data/IBM/informix/jj_prepsuse_a_1/logs/online.con l-wx------ 1 root root 64 Oct 23 15:52 2 -> /data/IBM/informix/jj_prepsuse_a_1/logs/online.con lrwx------ 1 root root 64 Oct 23 15:56 256 -> /data/IBM/informix/jj_prepsuse_a_1/chunks/rootdbs lrwx------ 1 root root 64 Oct 23 15:56 257 -> /data/IBM/informix/jj_prepsuse_a_1/chunks/physdbs lrwx------ 1 root root 64 Oct 23 15:56 258 -> /data/IBM/informix/jj_prepsuse_a_1/chunks/logdbs lrwx------ 1 root root 64 Oct 23 15:56 259 -> /data/IBM/informix/jj_prepsuse_a_1/chunks/sbspace_01 lrwx------ 1 root root 64 Oct 23 15:56 260 -> /data/IBM/informix/jj_prepsuse_a_1/chunks/datadbs_01 lrwx------ 1 root root 64 Oct 23 15:56 261 -> /data/IBM/informix/jj_prepsuse_a_1/chunks/datadbs_02 lr-x------ 1 root root 64 Oct 23 15:56 3 -> /opt/IBM/informix/ids1210/msg/en_us/0333/isam.iem lrwx------ 1 root root 64 Oct 23 15:56 4 -> anon_inode:[eventpoll] lrwx------ 1 root root 64 Oct 23 15:56 5 -> socket:[21980] lrwx------ 1 root root 64 Oct 23 15:56 6 -> socket:[20176] lrwx------ 1 root root 64 Oct 23 15:56 7 -> socket:[20177]

Jon, That was BEAUTIFUL! But you were correct; it is not potable or even usable in my situation. For starters, your great advice about looking for the oninti process with "1" in the C column was quite effective. However, that's where the portability ends. In my case: $ ps -ef | grep oninit | grep " 1 " root 24542 24534 1 12:47:25 ? 56:08 oninit informix 24531 8318 1 12:47:22 ? 111:30 oninit informix 24536 24534 1 12:47:23 ? 34:34 oninit OK, 24531 happens to be VP[1] in onstat -g glo so that's as good a process to trace: $ ls -l /proc/24531/fd /proc/24531/fd: Permission denied OK, I need to sudo to root. Here goes: # ls -l /proc/24531/fd | headtotal 128767 c--------- 1 root sys 13, 2 Oct 23 12:00 0 --w--w---- 1 informix informix 32799506 Oct 23 11:26 1 s--------- 0 root root 0 Oct 23 12:10 10 s--------- 0 root root 0 Oct 23 12:12 100 s--------- 0 root root 0 Oct 23 12:12 101 s--------- 0 root root 0 Oct 23 12:12 102 s--------- 0 root root 0 Oct 23 12:12 103 s--------- 0 root root 0 Oct 23 12:12 104 s--------- 0 root root 0 Oct 23 12:12 105 Not a file path in sight, as opposed to Jon's more accommodating Unix flavor. BTW, I this server has well over 300 chunks. The unmolested ls command yields 293 file descriptors, of which some are sdtdin/out/err and some are the message/console log files. So on my box (Solaris 10) this just ain't gonna fly. And even if it gave me the info that Jon got from his OS, I have the issues of: - How to throw a sudo command into the middle of an executing script; a method I know not. - In my environment, user informix has not been granted sudo privs. (Only us DBAs have it.) <Sigh> OK, Sancho, I think we yield this battle to the windmills. Let us seek out a battle we can win. -- Jacob S (Leaving the wild geese to their own pursuits)