Feedback
Did this article resolve your question/issue?

   

Article

How to query Database Startup Parameters that can be modified with VST's?

« Go Back

Information

 
TitleHow to query Database Startup Parameters that can be modified with VST's?
URL NameWhere-to-find-more-information-about-Database-Startup-Parameters
Article Number000109812
EnvironmentProduct: OpenEdge
Version: 11.5.x, 11.6, 11.7, 12
OS: All supported platforms
Other: Database Startup Parameters
Question/Problem Description
How to query Database Startup Parameters with VST's
How to update modifyable Database Startup Parameters programatically
Which VST can be used to increase database startup parameters online?
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
Starting in OpenEdge Release 11.5, database parameters can be queried with the _DbParams VST by their _DbParams-Name or _DbParams-Msg-Num values. 

The _DbParams VST should be used instead of the _Startup VST from previous versions. (Note: The _Startup VST was removed from the OpenEdge Database in OpenEdge 12).

Example 1: Specific Database Startup parameters can be queried by their _DbParams-Name
DEFINE VARIABLE cPmsgs AS CHARACTER NO-UNDO INITIAL 
'-L,-B,-B2,-S,-blocksize'.

DEFINE VARIABLE ix AS CHAR NO-UNDO. 
DEFINE VARIABLE ii AS INT NO-UNDO.

DO ii = 1 TO NUM-ENTRIES(cPmsgs):

    ASSIGN ix = (entry(ii,cPmsgs)). 

    FOR FIRST _DbParams NO-LOCK WHERE _DbParams._DbParams-Name =  ix.
        
        IF AVAILABLE _DbParams THEN 
        DISPLAY _DbParams-Desc SKIP.
   
    END.
END.
Example 2: Specific Database Startup parameters can be queried by their _DbParams-Msg-Num.
DEFINE VARIABLE cPmsgs AS CHARACTER NO-UNDO INITIAL '4239,17562,4241,4262'.

DEFINE VARIABLE ix AS INT NO-UNDO. 
DEFINE VARIABLE ii AS INT64 NO-UNDO.

DEFINE TEMP-TABLE ttDBParams NO-UNDO LIKE _DbParams.

DO ii = 1 TO NUM-ENTRIES(cPmsgs):

    ASSIGN ix = INTEGER(entry(ii,cPmsgs)). 

    FOR FIRST _DbParams NO-LOCK WHERE _DbParams._DbParams-Msg-Num =  ix: 
    IF AVAILABLE _DbParams THEN
    
        CREATE ttDBParams.
        BUFFER-COPY _DBParams TO ttDBParams.    
    END.
END.

FOR EACH ttDBParams:
DISP ttDBParams._DbParams-Name ttDBParams._DbParams-value SKIP.
END.

Database Startup parameters that can be updated in PROMON can almost all be updated with the associated  _DbParams VST and the value change is applied (as long as it's valid).  
Database Startup parameters that can be updated online with "PROUTIL -C increaseto" are typically not updatable with _DbParams.

The list of updatable _DbParams can be found by reporting on the _DbParams-Is-Modifiable field:
FOR EACH _Dbparams NO-LOCK WHERE _DbParams-Is-Modifiable = YES:
DISP _DbParams._DbParams-Name _DbParams-Is-Modifiable SKIP.
END.

Example 3: To change the updatable Database Client Notification poll time (-usernotifytime) with the _DbParams VST:
 
/* 1. Query the current value: */
FOR FIRST _DbParams NO-LOCK WHERE _DbParams._DbParams-Name = "-usernotifytime".
IF AVAILABLE _DbParams THEN 
        DISPLAY _DbParams-Desc _DbParams-Is-Modifiable SKIP.

/* 2. Update the current value: */
DO TRANSACTION:
FIND FIRST _DbParams WHERE _DbParams._DbParams-Name = "-usernotifytime".
ASSIGN _DbParams._DbParams-value = "3600". / * one hour * /
END.
  • Use Database Client Notification (-usernotifytime) to specify how often a client polls the database to see if a schema change is in process.
  • If no updates to schema are anticipated, due to index activation or rebuild, while the database is online, you can disable notification, or set the notification value to a very high number. If a change is required, the time between polls can be modified with PROMON or through the _DbParams VST.
  • When the -usernotifytime value is changed from 0 to a non-zero value, currently connected clients will not observe the change until the previous value has expired on their session; only new clients will poll to receive the new polltime value.
  • If the -usernotifytime is set to non-zero value then each client locks USR latch once per the -usernotifytime interval or once per 10 seconds if the -usernotifytime is less than 10 seconds which will cause USR latch contention. It should only be set to a low value when online schema changes are anticipated.
  • For ABL clients the minimum usernotifytime is effectively 10 seconds. 
    This limit is imposed because the client could be a remote client connected to multiple databases, and the network IO could be significant in extreme cases while synchronizing within the client process.

 
Workaround
Notes
References to Other Documentation:

Progress OpenEdge Database Administration -> Reference -> Database Startup Parameters -> Alphabetical listing of database startup parameters 

https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dmadm%2Fdatabase-client-notification-(-usernotifytime).html%23wwID0EI5RW

Progress Article(s):

 How To Find What Database Startup Parameters Are Used?  
How to find out what -n (Max users) value was specified for a connected database?
Last Modified Date4/1/2021 2:12 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.