Database Management/Display Bug in OEE?

Posted by dbeavon on 17-Jan-2018 08:21


I have a question about the OEE interface that displays database control information (below). It shows all my secondary remote brokers ("SERV") but seems to provide misleading information where remote SQL servers are concerned. It only lists one of them (PID 22700).

Below you will see the list of user connections on that database. Note that there are "SERV" entries that correspond to all the "secondary" brokers listed in the screenshot above. But there are a lot of SQL servers too, only one of which was listed in the screenshot above.


The reason I ask is because I am trying to manage all those various broker/server database startup parameters (-n -Mi -Mn -Ma -Mpb -whatever) and reviewing the impact after the fact in OEE. But that strategy seems problematic since OEE seems to be lying to me in one of the screens that should be summarizing the running brokers.

My confusion is that the only SQL server that was listed in the first screenshot is PID 22700, which is one of many. I'm not sure why it is being singled out to be displayed, and its cohorts are not... Anyone help would be appreciated.

Thanks, David

Posted by Matt Baker on 17-Jan-2018 08:34

 
The first pic is from a screen that is quite old and has never been updated or reviewed in quite a while. I don’t know what the design was at the time it was written…which was many many years ago.  To answer the question: The SQL server selected is the last one returned by the database from the _connect table: in no particular order.
 
I’ll log a bug to get its functionality reviewed.
 
Is there something missing from the connections list page that is not useful?  Can we add/change something to make it more helpful.
 
 
 

Posted by Rob Fitzpatrick on 17-Jan-2018 11:55

I agree with you David that understanding DB broker startup parameters can be challenging, and not just for people who are new the the platform.  This is an area where the docs (dmadm and dpspr) could use an overhaul.

When you have multiple brokers you should set -Mpb (servers per broker) for each one.  The value of -Mn should then be (at least) the sum of all -Mpb values plus the number of secondary brokers.

The value of Mn determines the number of records in the _Servers VST (it is Mn + 1).  Each broker, 4GL server, and SQL server takes one record.

Each broker's -Mpb should be high enough for the number of servers you want it to spawn, and you should always specify -ServerType (4GL or SQL) on brokers.  Your Mpb values should determine Mn, not the other way around.

All Replies

Posted by Matt Baker on 17-Jan-2018 08:34

 
The first pic is from a screen that is quite old and has never been updated or reviewed in quite a while. I don’t know what the design was at the time it was written…which was many many years ago.  To answer the question: The SQL server selected is the last one returned by the database from the _connect table: in no particular order.
 
I’ll log a bug to get its functionality reviewed.
 
Is there something missing from the connections list page that is not useful?  Can we add/change something to make it more helpful.
 
 
 

Posted by dbeavon on 17-Jan-2018 11:08

Thanks for checking this out.  I think it would be nice to get some consistency between those managements screens.  I know that OEE isn't a top Progress priority, but it is currently the only graphical management tool that ships with the OE DBMS. (Assuming we don't look to a third-party options.)

I can use the connections list for now, but it isn't where I would think to go in order to review my brokers.  Also, I am extremely nervous about making additional mouse-clicks from the connections screen because those can lock up the java adminserver for long periods of time.  (I think the clicks on the brokers - SERV/SQSV - is probably OK, but for other types of database users the clicks will trigger adminserver to gather up user usage statistics and that is where the lock-ups occur).

I'm really not trying to nit-pick OEE, just use it for a specific purpose.  We are having issues with the various broker/server database startup parameters (-n -Mi -Mn -Ma -Mpb -whatever).  What we find is that on type of broker, eg SQSV, will consume all the -Mn servers that are available and prevent any new connections for the other type of broker, eg SERV.   There seem to be a lot of broker/server startup parameters, and several KB's about them.  But the KB's don't really explain them all very well.  At the moment my focus probably needs to be on "-Mn" and "-Mpb".  I think if -Mn is 20 then I need to set -Mpb to 10 so that ten SERV's and ten SQSV's can be started, without either of them choking out the other.  By default it seems like the "-Mpb" is treated as if it had the same value as "-Mn" which makes absolutely no sense since it leads to one type of broker choking out the other.

Posted by Rob Fitzpatrick on 17-Jan-2018 11:55

I agree with you David that understanding DB broker startup parameters can be challenging, and not just for people who are new the the platform.  This is an area where the docs (dmadm and dpspr) could use an overhaul.

When you have multiple brokers you should set -Mpb (servers per broker) for each one.  The value of -Mn should then be (at least) the sum of all -Mpb values plus the number of secondary brokers.

The value of Mn determines the number of records in the _Servers VST (it is Mn + 1).  Each broker, 4GL server, and SQL server takes one record.

Each broker's -Mpb should be high enough for the number of servers you want it to spawn, and you should always specify -ServerType (4GL or SQL) on brokers.  Your Mpb values should determine Mn, not the other way around.

Posted by dbeavon on 17-Jan-2018 12:18

Thanks Rob, this is helpful.  I saw messages about not having enough servers in the db logs.  But after that I was lost insofar as all those parameters are concerned.  Things work fine - normally - until all of a sudden users stop being able to make connections.  And the -n wasn't the problem since we were well under that limit (the client-side message seemed to indicate that we had exceeded available resources, presumably connections).

It might be nice if the logs said something like "... you ran out of servers.  Consider doubling -Mn to XX and, seeing as how you are using more than one type of broker, please consider setting -Mpb to XX/2.  While you are at it you, the database is using 90% of the available user connections (-n) so you may want to increase that too."  

This is all the type of stuff that the database should troubleshoot ("cognitively" to use the latest buzzword from Progress).  It can easily run some calcs on the real-life numbers and give me a recommendation.  I imagine a lot of tech support and consulting hours are consumed just to get a working set of broker/server parameters in place.

Posted by Rob Fitzpatrick on 17-Jan-2018 12:20

Agreed.

Posted by Matt Baker on 19-Jan-2018 07:58

From the screenshots I assume you are on 11.6.something.  There is a hotfix available soon for 11.6.4 that is being back-ported from 11.7 to address the performance and out of memory crash on those screens. 11.6.4.003.  Bug number is PSC00357066.

Posted by dbeavon on 19-Jan-2018 08:54

I am aware of that fix, I am looking forward to it.  

(In the past, what had happened is that someone would unwittingly click on the wrong user connection in OEE and cause massive CPU problems in production for a half hour.  Clicking on OEE web links is now an ethics violation that can get you fired. ;-)

This thread is closed