DBQueue Processor configuration for test, development, or productive environments
You use the staging level of the One Identity Manager database to specify whether the database is a test database, development database, or a live database. A number of database settings are controlled by the staging level.
If you change the database's staging level, the following settings are configured.
Table 185: Default settings for development, test, and live environments
Maximum DBQueue Processor runtime
Maximum number of slots for the DBQueue Processor
Maximum number of slots according to the hardware configuration
The DBQueue Processor default configuration settings are configured for normal operation and do not normally need to be modified.
If several databases are operating in a managed instance in the Azure SQL Database, you can fix the number of slots. In the Designer, adjust the following configuration parameters.
QBM | DBServerAgent | CountSlotAgents: Exact number of slots. If the configuration parameter is set, the given number of slots are always set up. There is no internal calculation of the number of slots based on the hardware configuration. Changing the server's configuration has no effect. The value 15 is recommended.
NOTE: This configuration parameter is not recommended for implementing a database on an SQL Server. For implementing a database on an SQL Server, it is standard practice to use the hardware configuration to determine the slots.
The configuration settings are reduced for test environments and development environments because several databases may be located on a server. If it is necessary to change the settings for test environments or development environments for reasons of performance, you must modify the following configuration parameter settings in the Designer.
QBM | DBQueue | CountSlotsMax: Maximum number of slots to be used.
Use this configuration parameter to reduce the number of slots if required. Values lower than 5 are not permitted.
Exception: Enter a value of 0 for using the maximum number of slots available based on the hardware configuration.
QBM | DBQueue | KeepAlive: Maximum runtime of the central dispatcher. Tasks on slots currently in use are still processed when the timeout expires. Then the slot are stopped and the central dispatcher exits.
The lowest permitted value for runtime is 5 minutes; the maximum permitted value is 720 minutes.
Configuring notification behavior for DBQueue Processor initialization
If errors occur during initialization of the DBQueue Processor, messages are written to the application log. You can use the results display in the Microsoft Management Console, for example, to view the application log.
Use the QBM | DBServerAgent | CreateNotification configuration parameter to configure in which cases error messages are written to the application log. In the Designer, you can modify the configuration parameter as required.
Permitted values are:
0: No logging.
1: Only success messages are logged.
2: Only error messages are logged.
3: All messages are logged.
Reinitializing the DBQueue Processor
IMPORTANT: Select a user that you use for migrating the database to run the SQL queries.
You must run the QBM_PDBQueuePrepare procedure once manually when the server hardware has been extended and when custom DBQueue Processor tasks have been created.
You must run the QBM_PDBQueuePrepare and QBM_PWatchDogPrepare procedures once when you set up a reference database for test and development.
Use a suitable program for running SQL queries to run the following procedures in the reference database just once.
exec QBM_PDBQueuePrepare 0,1
Bulk processing in the DBQueue Processor
Table 186: Configuration parameter for bulk processing in the DBQueue Processor
QBM | DBQueue | DefaultRuntime
The configuration parameter species how the length of the DBQueue Processor run. The default value is 90 seconds.
QBM | DBQueue | ChangeLimitMin
The configuration parameter defines the lower limit for modifications (insert, change, or delete) within a single operation. The default value is 3000.
QBM | DBQueue | ChangeLimitMax
The configuration parameter defines the upper limit for modifications (insert, change, or delete) within a single operation. The default value is 50000.
Some DBQueue Processor procedures are marked for bulk processing to reduce the total time required for processing DBQueue tasks. If a lot of entries are marked for bulk processing in the DBQueue, the DBQueue Processor switches from single to bulk processing.
There is a mechanism implemented that is used to decide whether switching to bulk processing as opposed to single processing would result in time savings. To do this, 25 single task processes are run and the processing time is recorded. All other entries for the task are processed in bulk and the minimum and maximum load time required for advantageous bulk processing is defined. A self optimizing calculation procedure updates the load times. Use of this method means that the DBQueue Processor must first stabilize, especially after an initial schema installation or after system modifications such as memory expansion in the database server.
You can use the QBM | DBQueue | DefaultRuntime configuration parameter to specify the length of the DBQueue Processor run. The default value is 90 seconds. This corresponds to the time period that achieves the best load for the calculation procedure.
To prevent overloading when there is large amount of data, you can define limits for the result set. Control is realized using the QBM | DBQueue | ChangeLimitMin and QBM | DBQueue | ChangeLimitMax configuration parameters.