The miscellaneous events are mostly related to the server's internal scheduling and housekeeping, such as backups, checkpoints, and merges.
Although you cannot post these events, you can cause events indirectly, for example, when requesting a backup, or when turning on Maintenance Mode in advanced replication setups. You can monitor these events as necessary.
SYS_EVENT_BACKUP
The system has started or completed a backup operation. The "state" parameter (NUMDATAINFO) indicates:
0: backup completed.
1: backup started.
Note that the server also posts a second event (SYS_EVENT_MESSAGES) when it starts or completes a backup.
A checkpoint operation has been requested (but has not yet started). Checkpoints are typically executed each time a certain number of log writes has completed.
If the user application's callback function returns non-zero, then the merge is not performed.
This event can be caught by the user only if the user is using shared memory access or linked library access.
Some type of server error has occurred. The message parameter (TEXTDATA) contains the error text. See Conditions or warnings that cause SYS_EVENT_ERROR for a list of server errors that can cause this event to be posted.
Some tasks have a priority of "idle" and are only run when the system is not running any other tasks. Because very low priority tasks may be running in an "idle" system, the system is not necessarily truly idle in the sense of not doing anything.
This event can be caught by the user only if the user is using shared memory access or linked library access.
When the sync mode changes from NORMAL to MAINTENANCE, the server will send this system event. The node_name is the name of the node in which maintenance mode started.
A single solidDB® server can have multiple "nodes" (catalogs).) For more details about sync mode, see SET SYNC MODE.
Parameters: node_name WVARCHAR.
SYNC_MAINTENANCEMODE_END
When the sync mode changes from MAINTENANCE to NORMAL, the server will send this system event. The node_name is the name of the node in which maintenance mode started.
A single solidDB® server can have multiple "nodes" (catalogs).) For more details about sync mode, see SET SYNC MODE.
Parmaeteers: node_name WVARCHAR
SYS_EVENT_MERGE
An event associated with the "merge" operation (merging data from the Bonsai Tree to the main storage tree) has occurred. The parameter STATE (NUMDATAINFO) gives more details:
This event is posted when the server has a message (error message or warning message) to log to solerror.out or solmsg.out. In this case, the TEXTDATA contains the message text and NUMDATAINFO the code. If the message to be written is an error, both SYS_EVENT_ERROR and SYS_EVENT_MESSAGES will be posted. If the message is only a warning, only SYS_EVENT_MESSAGES is posted. For a list of the warnings that can cause SYS_EVENT_MESSAGES, see Conditions or warnings that cause SYS_EVENT_MESSAGES.
The system has encountered an event related to process size memory limits.
The NUMDATAINFO parameter indicatest he current memory allocation in Kilobytes.
The TEXTDATA parameter can have one of the following values:
▪PROCESS_LIMIT_ABOVE - The amount ofavailable virtual memory is above the limit specified by using the Srv.ProcessMemoryLimit parameter
▪PROCESS_LIMIT_BELOW - The amount of available virtual memory is below the limit specified by using the Srv.ProcessMemoryLimit parameter
▪PROCESS_LOW_LEVEL_ABOVE - The amount of available virtual memory is above the limit specified by using the Srv.ProcessMemoryLowPercentage parameter
▪PROCESS_LOW_LEVEL_BELOW - The amount of available virtual memory is below the limit specified by using the Srv.ProcessMemoryLowPercentage parameter
▪PROCESS_WARNING_LEVEL_ABOVE - The amount of available virtual memory is above the limit specified by using the Srv.ProcessMemoryWarningPercentage parameter
▪PROCESS_WARNING_LEVEL_BELOW- The amount of available virtualbelow the limit specified by using the memory is below the limit specified by using the Srv.ProcessMemoryWarningPercentageparameter
This event indicates that there are rows that need to be merged from the Bonsai Tree to the main storage tree. The rows parameter (NUMDATAINFO) indicates the number of non-merged rows in the Bonsai Tree.
This event is posted when a START AFTER COMMIT (SAC) fails. The application can wait for this event and use the job ID (which is in the NUMDATAINFO field) to retrieve the error message from the system table SYS_BACKGROUNDJOB_INFO. (The job ID in NUMDATAINFO matches the job ID that is returned when the START AFTER COMMIT statement is executed.)