What are VST's ?
- VST's are a subset of the metaschema which are exposed through Virtual System Tables (VST) to describe database status and activity. VST's are documented in:
- Virtual System Tables provide ABL application access to almost all the database information that can be collected with the PROMON utility to monitor database status and activity.
- Virtual System Tables, have no physical records until the database manager generates them at runtime. This enables a 4GL application to retrieve information about database access when they are retrieved.
- All information for the VST's are in shared memory (when the database is served) or private memory (when accessed single user). Therefore a database blocks will not be evicted to retrieve the VST records and VST data don't get replicated from SOURCE to TARGET databases because they are not "real tables".
- VST record information can be saved to a temp-table for manipulation but as there are no physical records, cannot be used to store information:
- The database meta-schema on the other hand does have the _User-Misc character field expressly for the purpose of storing information:
When do VST's need to be updated ?
- VST's should be updated between Minor releases, Service Packs
- When a database is created and the meta schema is added to a void multi-volume database, Major version VST's are created. If a later Service Pack has been applied, update VST's
- When a database is migrated with conv dbutilities, VST's are updated as part the conversion routine. If a later Service Pack has been applied, update VST's
- When the database is managed by the AdminServer, the DBAGENT process needs updated VST's of the version the database is running, to communicate between the managed database and the AdminServer
How to update VST's
- Updating VST's is an offline operation:
$ PROUTIL <dbname> -C UPDATEVST
- PROUTIL -C UPDATEVST deletes all existing VST schema information, then recreates all the VSTs from the most current information so that new VST tables are added and existing vst's are updated with the current version.
- As a precaution, ensure a valid database backup before making schema changes.
- VST's are enabled since Progress 9, it is only necessary to enable VST's in previous versions with "proutil -C enablevst" before updating them
- OpenEdge 10.2B02, 11.0.0 or later, replication enabled source database can update vsts without having to disable replication first
Understanding and using updated VST's
Application code that uses VST's may need reworking
VST's are never 're-named', they are enhanced and with a Major version change, VST's that remain purely for backward compatibility are removed.
For example, In OpenEdge 12, application code that makes use of _Startup or _Statbase VST tables, will need to be re-written to use the _DbParams VST instead or it will fail to compile:
The _DBStatus VST can be used to query the current status of the database, this is particularly useful in for example to monitor Lock Table entries when isolating "Lock Table Overflow (915)"
The
_DbParams VST (OpenEdge 11.5) can be used to query and
update database startup parameters at runtime