View Source

IDERA SQL Compliance Manager provides the following new features and fixed issues.

IDERA, Inc. customers have the sole responsibility to ensure their compliance with the laws and standards affecting their business. IDERA, Inc. does not represent that its products or services ensure that customer is in compliance with any law. It is the responsibility of the customer to obtain legal, accounting, or audit counsel as to the necessary business practices and actions to comply with such laws.

5.9 New Features

Performance Enhancements

Collection Service Multithread Event File Capture Processing

SQL Compliance Manager 5.9 improved the event file capturing mechanism by enabling parallel event file processing performed by the Collection Service. Before the SQL Compliance Manager 5.9 release, several areas appeared to be functioning single-threaded. With the SQL Compliance Manager 5.9 release, the Collection Service can now process multiple files simultaneously. This change enhances the performance and scalability of SQL Compliance Manager and significantly lowers the impact on the monitored systems while maintaining data integrity.

Console Application Performance Improvements

SQL Compliance Manager 5.9 improved the console application response state to avoid and eliminate areas that caused "Non-Responding" conditions. In addition, streamlining the SQL Compliance Manager index structure and query efficiency improved the console application's response time significantly, resulting in a quicker response time. These enhancements reduce latencies and improve the overall usability of the SQL Compliance Manager console.

Enhanced Report and Console Performance with Large Repositories

SQL Compliance Manager 5.9 improved upon reports and console performance for large repositories by modifying the SQL Compliance Manager repository index structure and query efficiency to refine the console application response time. As a result, the SQL Compliance Manager console application presents a faster response time when running Reports with the index structure and query improvements. For more information, visit the Index rebuild operation page.

Inheritance Mechanism Adjustments

SQL Compliance Manager version 5.9 introduces a more simplified inheritance mechanism by providing users with flexible customization options when configuring the audit activities settings for both the Server-Level and the Database-Level audit settings. Users can now audit Server-Level audit activities and have unique settings configured separately at the Database-Level in case needed.

The Database-Level Privileged Users settings are dependent on the Server-Level Privileged Users settings and the Audited Activity settings. In SQL Compliance Manager 5.9, whenever Privileged Users are set on the Server-Level, they are automatically displayed on the Database-Level Privileged Users as pre-selected Privileged Users and can only be edited at Server-level. Visit the Audited Database Properties window - Privileged User tab for more information.

Alerts

Timeframe Configuration

SQL Compliance Manager 5.9 introduces a new addition to the alert rules wizard by including the new timeframe configuration feature, allowing users to specify alerts to trigger only for certain rules and for certain specific timeframes. In addition, to help users capture what matters the most, SQL Compliance Manager 5.9 adds a new screen to the Alert Rule wizard where users can decide to keep the alert rule active within a specified time and for specific days. For more information, visit the Alert Rule Timeframe tab.

SQL Compliance Manager 5.9 improved the alert rules wizard by including the ability to limit the number of notification alerts sent via email by setting up a time interval to receive email alerts with a summarized list of the accumulated alerts which occurred during the selected time interval. For more information, visit the Alert Actions tab.

5.9 Fixed Issues

Exporting Audit Settings now successfully includes an export of the Server Level Trusted Users configured.
Resolved the issue where the SQL Server Properties window displayed the version as Unknown for registered SQL Server 2019 instances. Now, the correct version is shown.
Resolved the issue where auditing stopped working when a user-configured Sensitive Column auditing without first selecting the DML or SELECT option caused the SQLcompliance Agent to have problems creating the sp_SQLcompliance_AuditXE stored procedure.
Resolved the issue and now events get captured for sensitive columns when Select and DML are enabled at the database level Audited activities on fresh and upgraded setups.
The DML Activity (Before-After) report shows accurate results regardless of the collection method being set to Extended Events or SQL Tracing.
The DML\SELECT filters are now working correctly when auditing SQL Server 2019 and no longer prevent DML and SELECT activities from being audited accordingly.
The following error is no longer observed when attempting to run DML changes on a table configured for Before-After auditing in the software. "The DELETE permission was denied on the object 'SQLcompliance_Changed_Data_Table'."
The retention period of the Activity Log is now configurable. It is set to a default of 60 days which can be modified in the SQLcomplianceCollectionService.exe.config file, in the MAX_ACTIVITY_LOGS_AGE flag.
Console loading times are faster now at both console startup and when navigating to the Audit Events view of the audited server or database.
Event details on INSERT and DELETE events, audited not as INSERT INTO or DELETE FROM executions, are no longer missing the Target Object Name information, showing the name of the database object affected by the audited DML change.
Reports deployed to SQL Server Reporting Services now show corresponding logins in the Login dropdown filter when these are set to run against an archived database.
Reports no longer show a syntax error when executed either from the console application or SQL Server Reporting Services.
The permissions check for the SQL Server service account permissions on the Agent Trace Files folder no longer fails when the SQL Server is running under the NETWORK SERVICE service account.
Data types have been updated in the tables saving Before-After data to prevent the tables from filling up with event data too soon. This would have prevented new events from processing otherwise, as a result.
The console application logging is no longer showing a collation conflict error, as shown below: "Cannot resolve the collation conflict between "SQL_Latin1_General_CP1_CI_AS" and "Latin1_General_CI_AS" in the equal to operation."