solidDB Help : Programming : Diagnostics and troubleshooting SQL : Measuring and improving performance of START AFTER COMMIT statements
  
Measuring and improving performance of START AFTER COMMIT statements
Background tasks can be controlled with SSC-API and admin commands, see solidDB Server Control (SSC) API. The task type SSC_TASK_BACKGROUND is used for tasks that execute statements that are started with START AFTER COMMIT statements. You can give this task type higher priority or lower priority, or you can suspend this task type.
Note that there might be more than one of these tasks, but you cannot control them individually. In other words, if you call the SSCSuspendTaskClass for SSC_TASK_BACKGROUND, all the background tasks are suspended.
Analyzing failures in START AFTER COMMIT statements
There is a limit on the number of uncommitted START AFTER COMMIT statements that can exist simultaneously, that is, transactions in which the START AFTER COMMIT statement was executed but has not yet been committed. At this point, the body of the START AFTER COMMIT statement — for example, the procedure call — has not yet even started to execute. If the maximum is reached, then an error is returned when the next START AFTER COMMIT statement is executed. The maximum number of uncommitted START AFTER COMMIT statements is configurable in solid.ini by using the Srv.MaxStartStatements parameter, see Srv section.
If a statement cannot be started, the reason is logged in the system table SYS_BACKGROUNDJOB_INFO. Only failed START AFTER COMMIT statements are logged in this table. For more details about this table, see SYS_BACKGROUNDJOB_INFO.
The user can retrieve the information from the table SYS_BACKGROUNDJOB_INFO by using either an SQL SELECT statement or by calling the system procedure SYS_GETBACKGROUNDJOB_INFO. The stored procedure SYS_GETBACKGROUNDJOB_INFO returns the row that matches the given JOBID of the START AFTER COMMIT statement. For more details about SYS_GETBACKGROUNDJOB_INFO, see SYS_GETBACKGROUNDJOB_INFO.
If you want to be notified when a statement fails to start, you can wait on the system event SYS_EVENT_SACFAILED. For details about this event, see Miscellaneous events. The application can wait for this event and use the JOBID to retrieve the error message from the system table SYS_BACKGROUNDJOB_INFO.
Go up to
Diagnostics and troubleshooting SQL