Administrating and Developing with Informix
From archive: June 2010 X
A couple of weeks ago I asked about the usefulness of a Memory Profiler for Database Sessions. While I want to have another blog post on that perhaps hashing out what application developers would really like I wanted to about what we have as an option right now if we are trying to profile memory. While it often seems like we have very little info, we really have quite a bit, just as the Feature Request suggest, not always useful.
So what tools do we have at our disposal today for memory profiling?
onstat -g ses <session id>
You could probably make arguments for other onstat's but these really is it for memory profiling.
So let's take a quick look at onstat -g ses
In this instance we are going to do the following:
select * from customer;
On my server this happened to be session # 36, so let's take a quick peak.
So here we have the output. Make sure you see tid on line two of our output, happens to be 350. Thread ID, or tid, can be used for quite a few onstat commands all of which are useful.
Now where this can be useful from a memory profile section is the "Memory pools" section, specifically the list of the components. For all intents and purposes this is the breakout of you sessions memory. The bad news is that the components were all done based on internal structures instead of things that would make a little more sense to someone without code.
Still this at least give you something to pass to IBM Technical Support, to help you identify how Informix might actually be using memory.
This is helpful, but it also indicates why I've gotten as much feedback on the need for a session memory profiler.
One of the things that Rob Thomas talked about at IIUG this year was how there would be increased content for Informix. Developerworks is one of those locations and we have a relative new tutorial out on cloud computing.
If you are interested in Cloud Computing this is well worth the read, from an Informix standpoint.
So one of the reason for the infrequent postings of late have been vacation related, but some have been helping a customer out with security related issues. I think that all to often we dba's forgot the impact, directly and indirectly, that these mandated changes have on application developers. One such impact is in Data Privacy Laws. Ultimately what this means is that you soon will not, from a legal liability aspect, be allowed to restore a production server instance into a test environment to try and reproduce a problem. The solution to this is using some sort of app that transforms your data so that it is still valid for testing but has no direct association (besides say data distribution) to the actual real production data.
IBM has a very nice product to help you with this, which is Optim Data Privacy, and here at developerworks we have had 2 recent articles on the very topic.
So two tutorials. Let me know what you think of the content. Is this something you would like to see more of in Developerworks, tutorials about how IBM products rok with other IBM products?
MarkJamison 100000ESF6 4,297 Views
How much are you or your organization are considering application development on the iPad or iPhone, especially given the new OS which will allow multithreading?
Would OAT, or something like it, be a tool that you as a developer, or even an administrator like to have available on an iPhone or iPad? If you would like something like OAT, would it be fine as a web based app which you could use through safari, or would you prefer something native, if possible?
For those not familiar with OAT check out
Back to updates and potentially useful information. Many of you may be now writing apps for informix that are running on Clients and Servers using some form of LDAP for user Authentication. If you happen to using Active Directory for you chosen form of authentication, please check the following:
Microsoft already has a fix for the problem, but in the meantime if you are getting inexplicable -951 errors when attempting to connect to an Informix instance using Active Directory, this may be your culprit.
MarkJamison 100000ESF6 3,939 Views
Blogs, by there very nature, are often very self serving. I mean the blogger almost always writes about something he wants to talk about. But in order to be a sustainable blog that stays on topic you need feedback on what your readers want to see discussed/blogged.
So is there anything from an Informix Application Development standpoint you would like to be discussed.
And yes I'm saving this blog entry to re-post peridocially. I'm not out of ideas, and hope I never will be, but I value your opinion.
As you work supporting a database product, in my case the informix product line, you often find yourself working on stuff that may or may not be useful to many others besides the customer you are currently working for. While I see Unicode issues crop up across more than the normal customer I work with, I still haven't seen that many overall, so I cannot help but wonder if this is because Informix globalization is so well understood by developers, or if it is actually on the horizon still.
So would a discussion about application development considerations for Unicode be worthwhile?
I might blog on it anyway, but the more feedback means home much I should concentrate on blogging about it.
Hope everyone has had a couple of good weeks, I've been on vacation for most of it. Family reunions can be a lot of work let me tell you.
So one of the customers I support made an interesting feature request lately and I was interested in your feedback. As an application developer this particular customer feels he doesn't have enough tools at his disposal to know what the session was doing with the memory it is consuming. So his feature request was asking for a Session Memory profiler. Basically so he could know how much of memory is being used for temporary tables, how much is save by cursors, etc.
So my question to you all, is how valuable would you find a tool like this?
Is it just a little valuable? Very valuable?
Hoping for some good feedback from you all.