Checking the integrity of databases
Regularly check the integrity of the databases to detect any corruptions.
-
In SQL Server Management Studio, call the Stormshield_CheckDatabases stored procedure to check the SES Evolution databases, and optionally the system databases. Supply the following parameters, specific to your environment:
| Parameter | Description |
|---|---|
| FullCheck |
Enables or disables full database checking. This operation takes longer but detects more errors than a basic check. For example, for a database of approximately 200 GB, a full check takes about 30 minutes versus 10 minutes for a basic check. The time depends on the capacity of the machine, as well as the CPU and HD load at the time of checking. The value can be: 1: Full check enabled (Default value, recommended for a weekly or monthly interval). 0: Full check disabled (Value recommended for a daily interval). |
| IncludeSystemDatabases |
Includes or excludes checking of the SQL Server system databases. These databases are not linked to SES Evolution but are essential proper operation of SQL Server itself.
If this check has already been performed by another product or another maintenance plan on the same server, repeating it is not useful. |
Example of database integrity check:
In SQL Server Management Studio, run the check procedure only once:
-
Full check using the default parameters:
EXECUTE master.dbo.Stormshield_CheckDatabases;
-
Basic and faster check:
EXECUTE master.dbo.Stormshield_CheckDatabases @FullCheck = 0;
If the command fails, the steps to be taken will be determined by the error or warning messages returned by SQL Server. In most cases, Stormshield recommends restoring a backup of the database rather than having SQL Server repair the data. Indeed, repairing is likely to delete data.
Below is an example of messages returned by SQL Server in the event of corruption of the administration database data file:
[2024-07-14T22:30:45.7482429+02:00] Checking master...
[2024-07-14T22:30:46.0763424+02:00] Checking msdb...
[2024-07-14T22:30:46.5159005+02:00] Checking model...
[2024-07-14T22:30:46.6096237+02:00] Checking EsAdministration...
Msg 8939, Level 16, State 98, Line 3
Table error: Object ID 1483152329, index ID 1, partition ID 72057594055557120, alloc unit ID 72057594066436096 (type In-row data), page (1:7501). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -4.
Msg 8928, Level 16, State 1, Line 3
Object ID 1483152329, index ID 1, partition ID 72057594055557120, alloc unit ID 72057594066436096 (type In-row data): Page (1:7501) could not be processed. See other errors for details.
Msg 8978, Level 16, State 1, Line 3
Table error: Object ID 1483152329, index ID 1, partition ID 72057594055557120, alloc unit ID 72057594066436096 (type In-row data). Page (1:7249) is missing a reference from previous page (1:7501). Possible chain linkage problem.
Msg 8976, Level 16, State 1, Line 3
Table error: Object ID 1483152329, index ID 1, partition ID 72057594055557120, alloc unit ID 72057594066436096 (type In-row data). Page (1:7501) was not seen in the scan although its parent (1:7073) and previous (1:7665) refer to it. Check any previous errors.
CHECKDB found 0 allocation errors and 4 consistency errors in table 'IdentifierVersion' (object ID 1483152329).
CHECKDB found 0 allocation errors and 4 consistency errors in database 'EsAdministration'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (EsAdministration).
[2024-07-14T22:30:51.8276754+02:00] Checking EsLogs...