The workgroup database has (had) a limit of 65 connections. We have a customer that is about to open a second plant and based on user count, I suspect they may get pretty close to this limit. Currently they are running Work Group and I am trying to build a business case for the need to get to Enterprise. I am also trying to assess how they currently utilize their existing capacity.
Is it possible to access via the VSTs the connections that are used to make up this limit? If so, which VSTs should I consider.
My approach would be to write a small monitoring program that outputs these values to a file for analysis. The program would run every 5 minutes or so and sleep in between cycles.
Other ideas or thoughts welcome.
Thanks,
Bob
Have you looked at the license file (dbname.lic)? Aggregate information on user counts (total/interactive/batch, and current/hourly min/hourly max for each) is in the _License VST and at the top of each hour that data is written to the license file. It may serve your needs. Otherwise, you could roll your own code to look at that table. Other options are querying _Connect, if you need a breakdown of who the users are, or parsing the DB log and filtering out the logins and logouts to determine counts, high water marks, etc.
Bear in mind, if you choose to use _License, that its counts are wrong in some releases. A bug was introduced, in 10.2B01 I think, where the counts are wrong (they increment but do not decrement with every online backup). This was fixed in 10.2B05.
Thanks Rob. I should have recalled the LIC file for this. The hourly nature of that file gets me close enough to see we will have an issue in the near future.
I know that WG allows 49 users and up to 65 connections. I think I recall that the 49 number is a recommendation and that the 65 (or maybe it was 64) was a hard limit. I assume the LIC file handles just the user count. What additional resources should I look at to consider the 65 connections angle? The customer runs Corvu in 10.1C of OE and has a fair number of ODBC connections as well.
Ultimately, I need to help build the business case for needing this upgrade.
The other way around, Bob, the lic file only shows connections. "User" is a matter of license type and thus interpretation.
Frankly, at that level you should be looking at Enterprise anyway, whether you can slip under the user/connection count or not. If they have any growth at all, they are going to get there, so why not make the shift at a time when there needs to be some disruption and change anyway instead of waking up one day with the President not able to connect!
Thanks Thomas. So the LIC file shows the connections for Watchdog and the SQL (ODBC) connections as well? If so, then the LIC file is close enough for what I need.
FWIW, most of the PSC docs I have seen that compare WG and Enterprise talk of a soft limit of up to 49 users but a hard limit of 65 connections.
I agree totally that this customer needs to be at Enterprise. Should be there now, in my opinion. The new growth only accelerates that need. Ultimately, the transition and cost are hard to justify since the current hardware/software platform seems to run without too much end user complaint. The thought of hitting a limit is useful for me to help push this migration further along. As part of that, I need to know how close we actually are to hitting the wall both for my own piece of mind as well as for the purpose of moving on the Enterprise upgrade.
Someone else will have to comment on how the hard limit gets hit. The lic file is broken down by type of connection, to some extent, but, of course, the match of this to license terms and any hardcoded limits are up for grabs. E.g., for concurrent, batch processes don't count unless there are more of them than human users, so you could have 48 human users and 47 batch and supposedly that would be OK ... but no guarantees about whether you would hit any hard-coded connection limits. I would start by mining the .lic file and make a good scary case ... since you know it is for their own good anyway.
This is the info I have on WG limits; can't remember where I got it from. It allows "up to 5 batch jobs and 2 connections for each of 30 users (1 for the app, one for a query/reporting tool). 65 is a hard limit."
These links may help:
You can have up to 64 (the 65th would be reserved for proshut) shared memory connections to WGP DB. If you also have client server in the picture that would be 63 (login broker is going to take the 64th) either client server or mixed.
>> Ultimately, I need to help build the business case for needing this upgrade.
If they require more than above stated connections then that should be enough for a business case, no?
The VST in question would be _Connect.