PSQL Vx Server Product Guide (v11)

Licensing

This section explains the licensing for Pervasive PSQL Vx Server and contains the following topics:

License Model

Pervasive PSQL Vx Server is designed to support highly virtualized environments. For instance, Vx Server includes support for Cloud computing (private, community, and hybrid), as well as for full virtualization, partial virtualization, and paravirtualization. Pervasive PSQL Vx Server has no restrictions on hosting, connection pooling, Internet or intranet use. No additional license is required for use with hypervisor features such as live migration, failover, fault tolerance (FT), high availability (HA), and disaster recovery.

The technological and operational differences that come with virtualized environments require a license model optimized for such environments. The user count license model used for Pervasive PSQL Server and Workgroup does not suffice. That model works well for traditional client/server applications in which many users or devices constantly add, update, and delete records from distinct individual desktops.

Instead, Pervasive PSQL Vx Server uses a license model that shifts the emphasis from how many users to how much work the database server processes. The model is based on capacity to accommodate license enforcement in virtualized environments. For example, each instance of Pervasive PSQL Vx Server has capacity limits on both the number of sessions in use and the data in use. (Also, each instance is identified by a virtual hostname and all virtual MAC addresses.)

Number of Sessions In Use (Session Count)

A “session” is defined as a client ID used by the transactional engine interface or a connection to the relational engine interface. “Client ID” is defined as a 16-byte structure that combines elements provided by the application, by the client platform, and by the database engine to uniquely identify a database transaction context.

The number of sessions in use is a count of the concurrent sessions. For brevity, “number of sessions in use” is also referred to “session count.” “Session count limit” is the maximum permitted number of concurrent sessions as granted by a license agreement.

Messages pertaining to session count are logged to the various Pervasive PSQL logging repositories. See Message Logging.

The database engine uses various sessions for its own internal processes, such as for accessing Pervasive PSQL system files, metadata files, dbnames.cfg, and default system databases. These internal sessions do not consume any session counts.

Data In Use

“Data in use” is defined as the total size of all concurrently open data files. (A data file is a file created by an application to provide the data processed by that application.) “Data in use limit” is the maximum permitted amount of all concurrently open data files as granted by a license agreement.

The value for data in use increases when a data file is first opened. Subsequent opens to an already open data file do not add to the total. Data in use also increases if an open file increases in size. Operations on an already open file continue to be permitted even if the size of the open file increases beyond the data in use limit.

The value for data in use decreases when a data file is closed by the final user to have the file open. Since more than one user can access the same data file, all opens must be closed before data in use decreases.

Messages pertaining to data in use are logged to the various Pervasive PSQL logging repositories. See Message Logging.

The database engine uses various files for its own internal processes, such as Pervasive PSQL system files, metadata files, dbnames.cfg, and default databases. Files used for internal processes do not increase the value for data in use.

Estimating Session Count and Data In Use

You may estimate the session count and data in use required for a given application as follows:

Pervasive Software provides a Web page to help you estimate session count and data in use. See www.pervasivedb.com. (Also note that the changes to Monitor help you estimate session count and data in use. See Monitor.)

In general, for the transactional interface and the SDK access methods that use it, every unique client ID used to open a data file uses one session. If the same client ID is used to open all files, only one session count is consumed. If every file is opened with a distinct client ID, each open action uses one session count.

In general, for the relational interface and the SDK access methods that use it, every database connection with at least one table in use uses one session. A database connection without any tables in use does not consume any sessions. Once the database is connected and one session is counted, all subsequent operations on tables in that database are covered under that one session and do not use additional session counts.

Once a database file is open, certain SQL queries may involve other databases without consuming additional sessions. For example, if a query performs a JOIN with another database or builds a view that requires an underlying temporary table, no additional sessions are used. Note, however, that the additional open tables count toward total data in use.

Session Count, Data In Use, and Pervasive PSQL Utilities

To help you further estimate session count and data in use, the following table lists the Pervasive PSQL utilities that consume a session count. Only utilities that consume a session count are listed. The increase in data in use depends on the size of the file being acted upon by the session.

Table 2 Session Count Used by Pervasive PSQL Utilities 
Pervasive PSQL Utility1
Condition and Session Count Used2
Bulk Data Utility (BDU)
One count for each table into which data is loaded.
See bdu in Pervasive PSQL User's Guide.
DDF Builder
One count for every database connected to and one count if the “Create Table Definition” action is performed. These counts are released when DDF Builder is exited.
See DDF Builder User’s Guide.
Function Executor
One count for every unique client ID used by Function Executor.
See Function Executor の概念 in Advanced Operations Guide.
Pervasive PSQL Control Center (PCC)
One count for each database opened by PCC. See データベース in Pervasive PSQL User's Guide.
Pvddl
One count for executing a script against a database.
See pvddl in Pervasive PSQL User's Guide.
1 Pervasive AuditMaster and Pervasive DataExchange, although not Pervasive PSQL utilities, each consume at most one session.
2 In all cases, the increase in data in use depends on the size of the file being acted upon by the session. Exact increases cannot be provided.

Behaviors When Limits Are Reached

The following table summarizes the expected behaviors and suggested corrective actions when the limits are reached for session count and data in use.

Table 3 Expected Behaviors When Limits Are Reached for Session Count and Data In Use
Limit Reached
Behavior
Corrective Action
Session Count
The database engine denies requests for new sessions and returns status code 161 to the application.
Sessions established before the session count limit was reached continue to work and are not interrupted or disconnected.
Messages pertaining to session count are logged to the various Pervasive PSQL logging repositories.
Apply an increase key for session count. An increase key can be applied at any time and does not require that you close sessions or stop the database engine. The increase is immediately available.
You may try closing some of the current sessions. However, this action requires that you know which sessions are safe to close without resulting in incorrect data, incomplete records or aborted transactions.
Data In Use
The database engine denies requests for new file opens and returns status code 161 to the application.1
Subsequent opens to an already open data file are permitted. That is, if a file is already open and data in use reaches or exceeds its limit, other users can still access the open file.
Note that data in use also increases if an open file increases in size. Operations on an already open file continue to be permitted even if the size of the open file increases beyond the data in use limit.
The value for data in use decreases when a data file is closed by the final user to have the file open. Since more than one user can access the same data file, all opens must be closed before data in use decreases.
Messages pertaining to data in use are logged to the various Pervasive PSQL logging repositories. For example, a message first alerts you when data in use reaches 90% of the data in use limit.
Apply an increase key for data in use. An increase key can be applied at any time and does not require that you close data files or stop the database engine. The increase is immediately available.
You may try closing some of the currently open data files. However, this action requires that you know which data files are safe to close without resulting in incorrect data, incomplete records or aborted transactions.
1 Status code 161 is returned if the file to be opened exceeds 110% of the data in use limit. A slight buffer above 100% is provided because an increase in data in use can also result from the growth of currently open data files.

Product Key and Increase Key

Because Pervasive PSQL Vx Server uses a capacity-based license model, it requires its own product key. You cannot authorize Pervasive PSQL Vx Server with a key for Pervasive PSQL Server or Pervasive PSQL Workgroup. Each instance of Pervasive PSQL Vx Server requires a key.

Session count and data in use are defined in the Pervasive PSQL Vx Server key issued by Pervasive Software or by an application vendor. Keys are available in various combinations of values for session count limit and data in use limit. See www.pervasivedb.com for details.

Increasing the Value for Session Count or Data In Use

Pervasive Software or an application vendor offers a key to increase session count limit, data in use limit, or both. (Conceptually, the key is the same as a user count increase (UCI) key for Pervasive PSQL Server or Pervasive PSQL Workgroup.)

You immediately increase the value for session count limit, data in use limit, or both when you apply the key. A restart of the database engine is not required. A permanent key must be present to apply an increase key. An increase key cannot be applied to a temporary key.

If you delete the permanent key, all increase keys associated with that key are also deleted.

Note that the database engine logs a message to the Pervasive PSQL logging repositories when the limit increases for session count or data in use. The message contains the current limit and usage. See also Message Logging. You can monitor the current, peak, and maximum values for session count and data in use with the Monitor utilities. See データベース リソースのモニター in Advanced Operations Guide.

Status Codes Affected

The wording, description, or both for the following status codes have changed to better address both license models (user count and capacity based).

Utilities Affected

The following utilities have changed to accommodate a capacity-based license model.

License Administrator (GUI and CLI)

License Administrator displays the session count limit and data in use limit for a given key. You may also apply a key to increase the value for session count limit or data in use limit. A single increase key can increase both values depending on the key. See ライセンス管理 in Pervasive PSQL User's Guide for details.

Monitor

Monitor has the following changes pertaining to session count and data in use. The changes are summarized for the graphical user interface. The command line interface (bmon) contains similar changes where applicable. See データベース リソースのモニター in Advanced Operations Guide for details.

The changes to Monitor make it easier to estimate license requirements for session count and data in use. For example, Monitor displays the peak values for session count and data in use, and informs you how long the database engine has been running. Duration plus peak usage allows you to establish a more accurate baseline for estimating. When you estimate capacity, include the values determined from your peak conditions.

Message Logging

Messages pertaining to the capacity-based license model are logged to all of the logging repositories: Notification Viewer, PVSW.LOG, and the operating system event log. Any message logged to Notification Viewer is also logged to the operating system event log and to PVSW.LOG. Any message logged to the operating system event log is also logged to PVSW.LOG. If a message also includes a list of open files, the list is logged only to PVSW.LOG. See also Pervasive PSQL メッセージ ログ in Advanced Operations Guide.

The database engine logs a message when the capacity increases or decreases for session count or data in use. The message contains the current capacity and usage. You can monitor the current, peak, and maximum values for session count and data in use with the Monitor utility. See データベース リソースのモニター in Advanced Operations Guide.

Session Count

All messages pertaining to session count are informational. Session count messages inform you when session count reaches its limit, when session count returns to an acceptable range after a period of time, and when session count capacity changes.

If the total number of active concurrent sessions equals the session count limit, the database engine denies requests for new sessions and returns status code 161 to the application. Established sessions continue to work and are not interrupted or disconnected.

When a session closes all of its file handles, session count is decremented. No Reset operation is required to decrement the session count. Note, however, that unless a session is reset, it remains visible in the list of active sessions in Monitor even though the session does not increase session count. See ユーザー情報の表示 in Advanced Operations Guide.

Data In Use

Messages for data in use can be informational, warning, or error. When applicable, the messages advise you on corrective actions.

A message first alerts you when data in use reaches 90% of the data in use limit. This brings to your attention that data in use is approaching its limit and corrective action may soon be required. Additional messages—with escalating frequency—occur when the data in use limit reaches 100% or slightly exceeds 100%. (A buffer above 100% is provided because an increase in data in use can also result from the growth of currently open data files.)

For all of the message occurrences just discussed, the operation on the file is permitted. The messages are logged whether the file is first opened or already open and its size increases.

If the file to be opened exceeds 110% of the data in use limit, the database engine denies the open request and returns status code 161 to the application. The error message logged to PVSW.LOG and to the operating system event log lists the name of the file, its size, and the data in use limit. Files already open continue to be available and access to them is not interrupted or disconnected.

Access Methods Affected

The following SDK access methods have changed to accommodate a capacity-based license model.

DTI

DTO

All of the changes to DTO apply only to DTO2. See DTO2 in Distributed Tuning Objects Guide.

Application Changes Required

Typically, no application changes are required. If your application already works with Pervasive PSQL Server or Workgroup, it will also work with Pervasive PSQL Vx Server.

You need to revise your application if it uses DTI or DTO and you want to use the additional functionality for a capacity-based license model. See Access Methods Affected.

Key Validation

Pervasive PSQL Vx Server periodically verifies that the key for the database engine is still valid. The validation requires Internet connectivity.

If the periodic validation determines that a key is invalid, the key changes state from “active” to “failed validation.” The database engine functions normally for 30 days so that you have ample time to correct the failures.

Because you need to attend to a failed validation in a timely manner, the state change of the key is brought to your attention as soon as possible through various logging repositories used by Pervasive PSQL Vx Server. See Pervasive PSQL メッセージ ログ.

If you do not correct the causes of the failed validation before the allowed period ends, the key changes state again to “disabled.” The key is no longer valid and the database engine cannot access data files.

For example, if the network loses Internet connection, you have 30 days to restore connectivity and re-validate Pervasive PSQL Vx Server. Pervasive PSQL Vx Server logs messages to various message repositories to inform you that Internet connectivity has been lost. If Internet connectivity is not restored within the allowed period, the Pervasive PSQL Vx Server key becomes disabled.


Operating Requirements

Data Backup