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.
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_PWatchDogPrepare
exec QBM_PDBQueuePrepare 0,1
Table 194: 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.
IMPORTANT: Do no change or delete predefined database schedules as it may lead to unexpected errors.
To process internal tasks by the SQL Server Agent, the DBQueue Processor is initialized during schema installation. The following database schedules are generated during the initialization phase:
-
QBM_PWatchDog on <database>
This database schedule takes over several functions in One Identity Manager.
-
It checks whether DBQueue Processor's central dispatcher is active and restarts it.
-
It controls validation and starting of schedules.
-
It starts a database schedule to remove complete processes from the DBQueue.
-
It starts the database schedule for maintenance work.
-
It checks at regular intervals, whether database single-user mode is still required and resets the setting if necessary.
This database schedule has an active schedule with a 1 minute interval.
-
QBM_PDBQueueProcess_Main on <database>
This database schedule is the DBQueue Processor's central dispatcher. The central dispatcher assumes control of processing and distributes DBQueue tasks to individual slots. Each time the central dispatcher is run, the number of currently available slots required for the current run is found. The central dispatcher starts database schedules for the currently available slots just once.
Only one database schedule at most is started for the central dispatcher. The central dispatcher's database schedule does not have an active schedule, but is started by the QBM_PWatchDog on <database> database schedule.
-
QBM_PDBQueueProcess<SlotNumber> on <database>
The maximum number of available slots is determined during the DBQueue Processor initialization phase.
-
In the case of productive databases, the number of maximum slots depends on the number of processors on the database server.
-
For test environments and development environments, the maximum number of slots is reduced.
-
If the QBM | DBServerAgent | CountSlotAgents configuration parameter is set, the exact number of the specified slot is always set up. There is no internal calculation of the number of slots based on the hardware configuration.
For more information, see DBQueue Processor configuration for test, development, or productive environments.
An associated QBM_PDBQueueProcess<SlotNumber> on <database> database schedule is set up for each slot. Each database schedule is set up with a process that runs the DBQueue tasks for exactly this slot. The database schedules associated to each slot do not have any active schedules. They are started by the central dispatcher.
-
QBM_PDBQueueProcess_Del on <database>
This database schedule removes processed DBQueue tasks. The database schedule does not have an active schedule, but is started through the QBM_PWatchDog on <database> database schedule.
-
QBM_PDBQueueProcess_Mnt on <database>
This database schedule processes maintenance tasks. The maintenance tasks pass your tasks on to the database schedule instead of running them themselves. This means that nothing changes on the scheduling of maintenance tasks. The database schedule does not have an active schedule, but is started through the QBM_PWatchDog on <database> database schedule. For detailed information about maintenance tasks, see the One Identity Manager Operational Guide.
Related topics