Type:
Known Issue
Summary:
Microsoft SQL 2022 introduced a different method of file space initialization for LDF files of a SQL database that circumvents Encryptionizer processing. This can result in Log file corruption in some circumstances. See below with details of the SQL 2022 LDF file initialization, and how to work around the issue.
This fix is now available in the latest version of Encryptionizer 2509.1.9.51225 for those affected by this issue. If your licenses are covered by support, you will be able to download the latest version from your License Portal Contact NetLib Security support for more information.
Additional Information:
Affects: SQL Server 2022 (all editions) and later
Encryptionizer Products: all versions through 2501.1.7.50217 (note: Release 2509.1.9.1225 and later properly address LDF IFI)
SQL Server 2022 introduced a change to how it expands transaction log files (LDF files) when it runs out of space in an existing file. When SQL Server grows the file in an increment of 64 MB or less, SQL Server by default no longer initializes the new region of the file with zeros or nulls. Instead the Windows Operating system simply expands the file using a process called Instant File Initialization (IFI). Because Encryptionizer only captures the I/O from the SQL process itself, the LDF file may contain a mix of encrypted user data and unencrypted uninitialized data. This can sometimes cause SQL to mark the database suspect when the LDF is scanned during a database recovery. NOTE: There are no issues known with IFI and MDF files.
A database recovery could be triggered by restarting SQL Server, by bringing a database online that had previously been taken offline, or by attaching a database that had previously been detached from the server.
Note: While the database is online, all data written by SQL is encrypted, and the database functions without issue.
Here is more information from Microsoft on IFI and how it applies to Transaction Log files:
Microsoft.com: Instant file initialization and the transaction log
Steps to take:
- Here is a query to quickly determine which databases might be impacted:
Select DB_NAME(mf.database_id) as DatabaseName,
mf.name as LogicalFileName,
mf.growth * 8 / 1024 as AutoGrowthMB
FROM sys.master_files AS mf
WHERE mf.type_desc = 'LOG'
and mf.is_percent_growth = 0
- For any databases with the autogrowth factor of 64Mb or lower, you should change the autogrowth of your transaction logs to greater than 64 MB. This will ensure that all data written to the LDF file is written by the SQL Server process and automatically encrypted by Encryptionizer. 64 MB autogrowth is the default setting for new databases.
- If the autogrowth factor for a database is already greater than 64MB, no further action is needed.
- Back up your databases after changing the growth factor. Even if there is corruption in an LDF file, a backup will be uncorrupted.
- If you would like a SQL procedure to help you identify and change the transaction log autogrowth factor on your databases, please contact NetLib Security Support.
The NetLib Security Team is investigating methods to address this issue and will issue a patch when available.