Does anyone have experience using OE Explorer to monitor a scripted database?
We are having quite a bit of difficultly with this product. More information can be found here: https://community.progress.com/community_groups/openedge_deployment/f/21/t/30883
I'm not seeing a lot of complaints from others about OE Explorer issues related to CPU so either we are doing something wrong or nobody is using the product (or at least not for a scripted database on HP-UX).
The problems seem to be primarily related to when we investigate "User Details" (ie. database connectivity information). Some of those web pages appear to operate by asynchronously pulling incremental information. We see that some of these screens seem to open up quickly, but then there is a ton of follow-up CPU activity in the java admin server process and it goes on for several minutes afterwards. Subsequent clicks in the OE Explorer pages are all extremely slow.
Please let me know if any of this sounds familiar and/or if there is a way to troubleshoot whatever that java admin server process is doing with our CPU. This is reproducible now in two different HP-UX environments, although nothing like this had happened in Windows (although they were managed database on that side of things). Any help would be very much appreciated.
Tom, in my original posting I pointed out that I never saw this type of performance issue in my experience with a 64 bit Windows database. Although I should also say that there were other differences aside from just the platform itself. On the windows side I am using a *managed* local database (not a "scripted" local database) , and it was "workgroup" license not "enterprise".
On both sides, my tests involve an extremely trivial number of users and activity (20 user connections, database running for a couple hours).
That's why I was hoping for some feedback from other OEE users to see if their experiences with the product (clicking on a user connection number) were good or bad (like I see in windows or HP-UX, respectively). I was interested to hear that a number of people prefer third-party tools for a better management experience than you get with OE's own tooling. But I'd really like to give OEE a fair shot. Especially since it is hard to explain to people (especially people that don't have their own personal experiences in OE ) that a third-party ProTop tool should be purchased rather than using something that comes with the shrink-wrapped product from Progress.
Matt, it was just a single click on a user number from the "Database Connections" tab. It hyperlinks over to the "User Details" and shows connectivity information for that user.
The table and index stats aren't always important to us so it is surprising that it caps out cores on the HP-UX server for about two minutes. This screenshot is another attempt. Note that the top of the screen comes back quickly in about 2 seconds (everything down thru "Active Transactions") but the "Table Activity" and "Index Activity" take another one or two minutes.
Below you can see the complete (filtered table and index activity). This refresh took two minutes.
The database is proserv'ed with -tablerangesize 900 -indexrangesize 2850
If I run the following, I get 1215. Let me know what other info you may need.
SELECT COUNT(*) FROM _file
> The database is proserv'ed with -tablerangesize 900 -indexrangesize 2850
> If I run the following, I get 1215. Let me know what other info you may need.
> SELECT COUNT(*) FROM _file
I think your -tablerangesize is not high enough. You haven't specified your -basetable/-baseindex so I assume they are set to 1.
An empty 11.6.3 database contains 175 _File records. So assuming you don't have extra system records for optional features (e.g. auditing or TDE) then I'd guess you have 1,040 application tables. So with TRS of 900 (assuming -basetable 1) you would be missing stats for at least your uppermost 140 tables ("at least" because there could be gaps in the object numbers).
You can set reasonable stats parameter values like this:
find last dictdb._file no-lock where _file._tbl-type = "T" use-index _file-number.
find last dictdb._index no-lock where not _index._index-name begins "_" use-index _index-number.
"Highest table number: " _file._file-number skip
"Highest index number: " _index._idx-num skip
Sample output:Highest table number: 468Highest index number: 904If you set -basetable to a value other than 1 then set -tablerangesize to (highest table # - basetable + 1). If you set -baseindex to a value other than 1 then set -indexrangesize to (highest index # - baseindex + 1).This approach provides minimum values. I like to pad these numbers by about 20 for tables and 40 for indexes, depending on how often the schema may change online.
I think I'm going to have to open a support case for HP-UX's admin server, and see if they can fix this stuff.
Today, once again, I unwittingly clicked on a user connection to see that user's connection details and the consequence is that now the java/adminserver process is now swamping on *five* cores at the same time and it has been over ten minutes. As far as I know, the only way to recover from this is to stop and restart admin server altogether. (I closed the webpage in which I made the mouse-click on the user, but that did not cancel whatever work is being done by admin server).