🚀 Master SQL Server Transaction Log Management — The Smart, Secure, Automated Way!

Stop Log Bloat: Safe, Enterprise-Grade SQL Transaction Log Management (Step-by-Step) - FreeLearning365.com

STOP! 🚨 Your SQL Server Log File is Out of Control - The RIGHT Way to Manage It

Is your SQL log file consuming all your disk space? 😱 Learn the safe, automated way to manage transaction log growth without breaking your backup chain. Free script included! #SQLServer #LogManagement #DBA

Introduction: The DBA's Nightmare - The 500GB Log File That Ate Your Server 💀

It's 3 AM. Your monitoring system alerts: "Disk C: at 99% capacity." You investigate and find a single .ldf file has ballooned to hundreds of gigabytes. Panic sets in. Do you shrink it? Will it break something? How did this happen?

If you've faced this scenario, you're not alone. Transaction log management is one of the most misunderstood aspects of SQL Server administration. In this guide, we'll give you not just an automated solution, but more importantly, the knowledge to use it safely and effectively.

⚠️ Critical Disclaimer: Read This Before Proceeding

Shrinking log files is generally NOT a best practice. It should be treated as an emergency procedure, not regular maintenance. Frequent shrinking leads to:

Virtual Log File (VLF) fragmentation - causing performance degradation
Immediate regrowth - the very problem you're trying to solve
Potential data loss if not handled correctly

The proper long-term solution is:

Proper backup strategy (Transaction log backups for FULL recovery)
Right-sizing your log file from the beginning
Monitoring growth patterns

Use this script for emergency situations only or in development environments.

The Emergency Log Management Script 🚑

SQL

  
    -- =====================================================-- Procedure: spLogClear - EMERGENCY Transaction Log Management-- Description: Use ONLY for emergency log file reduction.--              Not recommended for regular maintenance.-- Author: FreeLearning365.com-- Usage: EXEC [dbo].[spLogClear]-- =====================================================

ALTER PROCEDURE [dbo].[spLogClear]ASBEGIN
    SET NOCOUNT ON;

    DECLARE 
        @DBName SYSNAME,
        @LogFileName SYSNAME,
        @StartTime DATETIME = GETDATE(),
        @Msg NVARCHAR(MAX),
        @ErrorMsg NVARCHAR(MAX),
        @SQL NVARCHAR(MAX),
        @OriginalRecoveryModel NVARCHAR(60),
        @CurrentRecoveryModel NVARCHAR(60);

    BEGIN TRY
        -- 🎯 SECTION 1: INITIALIZATION & VALIDATION
        -- ===========================================
        
        -- Dynamically detect current database context
        SET @DBName = DB_NAME();
        
        -- Safety Check: Prevent execution on system databases
        IF @DBName IN ('master', 'model', 'msdb', 'tempdb')
        BEGIN
            SET @Msg = 'CRITICAL: This procedure cannot be run on system databases. Attempted on: ' + @DBName;
            RAISERROR(@Msg, 16, 1);
            RETURN;
        END

        -- Detect the logical name of the transaction log file
        SELECT TOP 1 @LogFileName = name
        FROM sys.database_files
        WHERE type_desc = 'LOG';

        -- Safety Check: Ensure log file was found
        IF @LogFileName IS NULL
        BEGIN
            RAISERROR('Could not identify transaction log file for database: %s', 16, 1, @DBName);
            RETURN;
        END

        -- 🗒️ SECTION 2: AUDITING & RECOVERY MODEL MANAGEMENT
        -- ==================================================
        
        -- Capture original recovery model for restoration
        SELECT @OriginalRecoveryModel = recovery_model_desc 
        FROM sys.databases 
        WHERE name = @DBName;

        -- Log process initiation
        INSERT INTO log.LogShrinkAudit
        (DBName, LogFileName, StartTime, Status, Message)
        VALUES
        (@DBName, @LogFileName, @StartTime, 'Started', 
         'Emergency log shrink initiated. Original Recovery: ' + @OriginalRecoveryModel);

        PRINT 'Starting emergency log management for database: ' + @DBName;
        PRINT 'Log file name: ' + @LogFileName;
        PRINT 'Original recovery model: ' + @OriginalRecoveryModel;

        -- 🔄 SECTION 3: THE CORE LOG MANAGEMENT PROCESS
        -- =============================================
        
        -- ⚠️ STEP 3.1: TEMPORARY RECOVERY MODEL SWITCH
        -- WARNING: This breaks the log backup chain in FULL recovery!
        SET @SQL = N'ALTER DATABASE [' + @DBName + N'] SET RECOVERY SIMPLE;';
        EXEC(@SQL);
        PRINT 'Temporarily switched to SIMPLE recovery model.';

        -- ✅ STEP 3.2: CHECKPOINT - Flushes dirty pages to data file
        CHECKPOINT;
        PRINT 'Checkpoint completed.';

        -- 📉 STEP 3.3: SHRINK LOG FILE (THE MAIN EVENT)
        -- Parameter 0 = shrink to smallest possible size
        SET @SQL = N'DBCC SHRINKFILE (N''' + @LogFileName + N''', 0);';
        EXEC(@SQL);
        PRINT 'Log file shrink completed.';

        -- 🎯 STEP 3.4: RIGHT-SIZE THE LOG FILE (CRITICAL STEP!)
        -- Prevents immediate autogrowth. Adjust 1000MB based on your needs.
        SET @SQL = N'ALTER DATABASE [' + @DBName + N']
                    MODIFY FILE (NAME = N''' + @LogFileName + N''', 
                                SIZE = 1000MB, 
                                MAXSIZE = UNLIMITED, 
                                FILEGROWTH = 500MB);';
        EXEC(@SQL);
        PRINT 'Log file resized to prevent immediate regrowth.';

        -- 🔄 STEP 3.5: RESTORE ORIGINAL RECOVERY MODEL
        IF @OriginalRecoveryModel = 'FULL'
        BEGIN
            SET @SQL = N'ALTER DATABASE [' + @DBName + N'] SET RECOVERY FULL;';
            EXEC(@SQL);
            PRINT 'Recovery model restored to FULL.';
            
            -- ⚠️ CRITICAL: Take a FULL backup after restoring FULL recovery
            -- This establishes a new backup chain
            SET @Msg = 'IMPORTANT: Take a FULL database backup immediately to re-establish backup chain.';
            PRINT @Msg;
        END

        -- ✅ SECTION 4: SUCCESS REPORTING
        -- ===============================
        
        SET @Msg = N'Emergency log management completed successfully for database [' + @DBName + 
                   N']. Process completed at ' + CONVERT(NVARCHAR(30), GETDATE(), 120);
        
        INSERT INTO log.LogShrinkAudit
        (DBName, LogFileName, StartTime, EndTime, Status, Message)
        VALUES
        (@DBName, @LogFileName, @StartTime, GETDATE(), 'Success', @Msg);

        PRINT @Msg;
        PRINT '=== PROCESS COMPLETED SUCCESSFULLY ===';

    END TRY

    BEGIN CATCH
        -- ❌ SECTION 5: COMPREHENSIVE ERROR HANDLING
        -- ==========================================
        
        SET @ErrorMsg = 'ERROR [' + CAST(ERROR_NUMBER() AS NVARCHAR(10)) + ']: ' + 
                        ERROR_MESSAGE() + ' (Line: ' + CAST(ERROR_LINE() AS NVARCHAR(10)) + ')';

        PRINT 'PROCESS FAILED: ' + @ErrorMsg;

        -- Attempt to restore original recovery model on failure
        BEGIN TRY
            IF @OriginalRecoveryModel IS NOT NULL AND @OriginalRecoveryModel != 'SIMPLE'
            BEGIN
                SET @SQL = N'ALTER DATABASE [' + @DBName + N'] SET RECOVERY ' + @OriginalRecoveryModel + N';';
                EXEC(@SQL);
                PRINT 'Original recovery model restored after failure.';
            END
        END TRY
        BEGIN CATCH
            PRINT 'WARNING: Could not restore original recovery model after failure.';
        END CATCH

        -- Log the failure
        INSERT INTO log.LogShrinkAudit
        (DBName, LogFileName, StartTime, EndTime, Status, Message)
        VALUES
        (@DBName, ISNULL(@LogFileName, 'Unknown'), @StartTime, GETDATE(), 'Failed', @ErrorMsg);

        -- Re-throw error for external handling (e.g., SQL Agent)
        THROW;

    END CATCH
END
GO

Step-by-Step Implementation Guide 🛠️

Step 1. Prerequisites & Safety Checks

Create the Audit Table:

SQL

  
    CREATE SCHEMA [log];
GO

CREATE TABLE [log].[LogShrinkAudit](
    [AuditID] [int] IDENTITY(1,1) NOT NULL,
    [DBName] [sysname] NOT NULL,
    [LogFileName] [sysname] NOT NULL,
    [StartTime] [datetime] NULL,
    [EndTime] [datetime] NULL,
    [Status] [nvarchar](50) NULL,
    [Message] [nvarchar](max) NULL)

Permissions Required:
- ALTER DATABASE permission on the target database
- INSERT permission on the audit table
- Membership in db_owner role is typically required

Step 2. Initial Testing (SAFE MODE)

NEVER run this in production without testing first!

SQL

  
    -- TEST 1: Check what would happen (read-only check)-- Examine current log size and VLFsSELECT 
    name AS [LogFileName],
    size * 8.0 / 1024 AS [SizeMB],
    CASE WHEN size = max_size THEN 'FULL' ELSE 'GROWTH AVAILABLE' END AS [Status]FROM sys.database_files 
WHERE type_desc = 'LOG';

-- Check VLF count (high count = fragmentation)DBCC LOGINFO;

Step 3. Emergency Execution

Only proceed if you have a genuine emergency and understand the risks:

SQL

  
    -- Execute the emergency procedureEXEC [dbo].[spLogClear];

-- Monitor the audit logSELECT * FROM [log].[LogShrinkAudit] ORDER BY StartTime DESC;

-- ⚠️ CRITICAL POST-PROCESS STEP: Take a FULL backupBACKUP DATABASE [YourDatabase] 
TO DISK = 'D:\Backups\PostShrink_FullBackup.bak'WITH COMPRESSION, INIT;

Pros, Cons, and Best Practices 🤔

Aspect	Emergency Use Case 👍	Regular Use Risks 👎	Best Practice Alternative
Disk Space Recovery	Immediate space recovery from runaway log	VLF fragmentation causes poor performance	Proper log backups in FULL recovery model
Automation	Quick resolution during emergencies	Masks underlying problems	Monitor log growth and address root causes
Recovery Model	Allows space reclamation in FULL model	Breaks log backup chain - potential data loss	Size log appropriately from the start
Right-Sizing	Prevents immediate regrowth after shrink	Manual sizing may not match workload	Set appropriate autogrowth (not percentage)

The RIGHT Way: Long-Term Log Management Strategy 📈

Instead of regular shrinking, implement this

For FULL Recovery Model Databases

  
    -- Schedule frequent transaction log backupsBACKUP LOG [YourDatabase] 
TO DISK = 'D:\LogBackups\YourDatabase_Log.trn'WITH COMPRESSION;

Right-Size from Beginning

  
    -- Set appropriate initial size and growthALTER DATABASE [YourDatabase]MODIFY FILE (NAME = YourDatabase_Log, 
             SIZE = 4096MB, 
             FILEGROWTH = 1024MB); -- Fixed growth, not percentage

Monitoring & Alerting

  
    -- Regular monitoring querySELECT 
    name AS DatabaseName,
    (size * 8.0 / 1024) AS LogSizeMB,
    (CAST(used_space AS float) * 8 / 1024) AS UsedSpaceMB,
    (size * 8.0 / 1024) - (CAST(used_space AS float) * 8 / 1024) AS FreeSpaceMB
FROM sys.dm_db_log_space_usage
CROSS APPLY sys.databases 
WHERE sys.databases.database_id = sys.dm_db_log_space_usage.database_id;

Business Case & Limitations 🏢

Business Case: Prevents production outages due to disk space exhaustion. Maintains system availability during unexpected log growth scenarios.
Limitations
- Temporary solution - doesn't address root cause
- Performance impact - VLF fragmentation affects write performance
- Recovery implications - breaks the point-in-time recovery capability until a new full backup is taken
- Not a substitute for a proper backup strategy

"The truth your DBA won't tell you about log files"
"From panic to solution in 5 minutes"
"The emergency fix that saved our production server"
"Why your log file keeps growing (and how to stop it forever)"
"The shrink operation that won't get you fired"

Remember: This script is your emergency fire extinguisher - essential to have, but you hope you never need to use it! 🔥🚒

Alternative Approach

Executive summary/business case

Why this matters

Large or uncontrolled log files consume disk, slow backups, complicate restores, and amplify ransomware damage.
Frequent, ad-hoc shrinking causes fragmentation and performance problems.
The right approach: prevent log growth with a correct recovery model + frequent log backups, monitor, and only shrink when necessary with a documented, auditable process.

Business benefits

Predictable disk usage and lower storage costs.
Faster restores and improved availability.
Audit trail for operations (compliance & change control).

Key principles & best standard (short)

Prefer prevention over cure: take frequent transaction-log backups (FULL model) or use SIMPLE model only for dev/test.
Avoid routine shrinking: shrink only when required (e.g., after one-off huge operation, log growth due to long-running transaction, or DB restore/maintenance).
Logically plan growth settings: set sensible FILEGROWTH and INITIAL SIZE —Avoid tiny percent-based growth for large logs.
Automate monitoring & alerts: watch log_reuse_wait_desc , free space, and autogrowth events.
Audit & document any shrink operation. Record who ran it, why, and the before/after sizes.

Common causes of log growth

Long-running or uncommitted transactions
Replication, CHANGE_TRACKING, CDC, DB mirroring, AlwaysOn, long-running backups
Missing or infrequent log backups in the FULL recovery model
Bulk operations (index rebuilds, large loads)

Pros & Cons of shrinking logs

Pros

Instantly reclaims disk after one-time surge.
Useful after large one-off operations or restoring from a backup with a larger log.

Cons

Causes file fragmentation and potential performance degradation.
Shrinking regrows logs if operations continue — regrowth is expensive.
Not a long-term solution to recurring growth.

Best practices (step-by-step checklist before shrinking)

Investigate root cause: Check DBCC SQLPERF(LOGSPACE) and sys.databases log_reuse_wait_desc .
Fix underlying issue: e.g., schedule frequent log backups, commit/kill long transactions, disable/reconfigure features.
Take a transaction log backup (FULL model) to free up virtual log files (VLFs) if possible.
Delay shrinking until log is reusable (log_reuse_wait_desc = NOTHING).
Document & audit : always insert an audit record before/after shrink.
Shrink in a maintenance window and monitor performance, autogrowth.
Adjust file growth strategy: e.g., FILEGROWTH = 512MB for busy OLTP DBs, avoid 1% growth for large files.
Perform index maintenance afterwards if required (heavy shrink may impact fragmentation).

Security, permissions & masking sensitive fields

Do not run shrink scripts as sa unless required. Use a least-privilege account with ALTER DATABASE permissions or run as an approved operator via SQL Agent.
Mask sensitive values in audit/log tables (if you store server or path info that could reveal structure). Example: store ServerName hashed or store only the first/last 8 chars.
Record operator identity using SUSER_SNAME() or ORIGINAL_LOGIN() — but don’t store personal data that is not necessary.

Table design (you provided) — small improvements

Add a default StartTime and index for queries:

  
    ALTER TABLE log.LogShrinkAudit
ADD CONSTRAINT DF_LogShrinkAudit_StartTime DEFAULT (GETDATE()) FOR StartTime;

CREATE NONCLUSTERED INDEX IX_LogShrinkAudit_DBName_StartTime
ON log.LogShrinkAudit(DBName, StartTime DESC);

Masking note: if you log paths or server names and want to mask, store a hash: HASHBYTES('SHA2_256', @FullServerPath) (store varbinary) and keep mapping in a secure admin-only table.

Production-ready stored procedure (improved, audited, safe)

Key improvements over the original:

Detects log_reuse_wait_desc and refuses to shrink unless reason is NOTHING or explicit override given.
Optional @Force for documented emergency shrink with required @Reason param.
Records before/after sizes, VLF count, user who ran it.
Graceful error handling and throttled shrink (shrinks to target percent/size).
Avoids setting recovery model from FULL→SIMPLE→FULL automatically (dangerous) unless explicitly allowed.

Warning: Changing recovery model from FULL→SIMPLE causes break in log backup chain. Only do if you know consequences.

  
    -- ================================================-- dbo.spLogClear_Managed-- Safer, auditable transactional log cleanup procedure-- Usage: EXEC dbo.spLogClear_Managed @TargetSizeMB=1024, @Force=0, @AllowRecoveryChange=0, @Reason='...';-- ================================================CREATE OR ALTER PROCEDURE dbo.spLogClear_Managed
(
    @TargetSizeMB INT = 1024,            -- desired final size in MB (approx)
    @MinFreePercent INT = 10,            -- shrink only if free space percent > this
    @Force BIT = 0,                      -- 1 = allow shrink even if log_reuse_wait != NOTHING (use with caution)
    @AllowRecoveryChange BIT = 0,        -- 1 = allow temporary switch to SIMPLE (dangerous, breaks log chain)
    @Reason NVARCHAR(4000) = NULL        -- required if @Force = 1 or @AllowRecoveryChange = 1
)
ASBEGIN
    SET NOCOUNT ON;
    DECLARE @DBName SYSNAME = DB_NAME();
    DECLARE @LogFileName SYSNAME;
    DECLARE @StartTime DATETIME = GETDATE();
    DECLARE @BeforeSizeMB INT;
    DECLARE @BeforeUsedPercent DECIMAL(5,2);
    DECLARE @AfterSizeMB INT;
    DECLARE @SQL NVARCHAR(MAX);
    DECLARE @WaitDesc SYSNAME;
    DECLARE @Operator SYSNAME = SUSER_SNAME();
    DECLARE @AuditMsg NVARCHAR(MAX);

    BEGIN TRY
        -- 1. Log initial state: find log file
        SELECT TOP(1)
            @LogFileName = name
        FROM sys.database_files
        WHERE type_desc = 'LOG';

        -- 2. Get current log size & used percent
        SELECT
            @BeforeSizeMB = CAST(size/128.0 AS INT),
            @BeforeUsedPercent = CAST( ( (size - CAST(FILEPROPERTY(name,'SpaceUsed') AS INT)) * 100.0 / NULLIF(size,0) ) AS DECIMAL(5,2) )
        FROM sys.database_files
        WHERE type_desc = 'LOG' AND name = @LogFileName;

        -- 3. Determine log reuse wait reason
        SELECT @WaitDesc = log_reuse_wait_desc
        FROM sys.databases
        WHERE name = @DBName;

        -- 4. Audit start
        INSERT INTO log.LogShrinkAudit (DBName, LogFileName, StartTime, Status, Message)
        VALUES (@DBName, @LogFileName, @StartTime, 'Started',
                'Initiated by ' + ISNULL(@Operator,'Unknown') + '; log_reuse_wait_desc=' + ISNULL(@WaitDesc,'Unknown'));

        -- 5. Safety checks
        IF @Force = 0 AND @WaitDesc <> 'NOTHING'
        BEGIN
            SET @AuditMsg = 'Abort: log_reuse_wait_desc = ' + @WaitDesc + '. Use proper log backup or resolve wait reason before shrinking.';
            INSERT INTO log.LogShrinkAudit (DBName, LogFileName, StartTime, EndTime, Status, Message)
            VALUES(@DBName, @LogFileName, @StartTime, GETDATE(), 'Aborted', @AuditMsg);
            RETURN;
        END

        IF @Force = 1 AND (@Reason IS NULL OR LEN(@Reason) < 5)
        BEGIN
            THROW 51010, 'Force requested but @Reason is required (short justification).', 1;
        END

        -- 6. Optionally switch recovery model (DANGEROUS)
        IF @AllowRecoveryChange = 1
        BEGIN
            IF @Reason IS NULL OR LEN(@Reason) < 5
                THROW 51011, 'AllowRecoveryChange requires a justified @Reason.', 1;

            SET @SQL = N'ALTER DATABASE [' + @DBName + '] SET RECOVERY SIMPLE WITH NO_WAIT;';
            EXEC(@SQL);

            INSERT INTO log.LogShrinkAudit (DBName, LogFileName, StartTime, Status, Message)
            VALUES(@DBName, @LogFileName, @StartTime, 'Info', 'Recovery switched to SIMPLE temporarily. Reason: ' + @Reason);
        END

        -- 7. Do a checkpoint if in SIMPLE or after log backup
        CHECKPOINT;

        -- 8. Recompute size and used percent (safe check)
        SELECT
            @BeforeSizeMB = CAST(size/128.0 AS INT),
            @BeforeUsedPercent = CAST( ( (size - CAST(FILEPROPERTY(name,'SpaceUsed') AS INT)) * 100.0 / NULLIF(size,0) ) AS DECIMAL(5,2) )
        FROM sys.database_files
        WHERE type_desc = 'LOG' AND name = @LogFileName;

        -- 9. Check min free percent condition
        IF @BeforeUsedPercent <= (100 - @MinFreePercent)
        BEGIN
            -- compute target shrink size in pages (approx) using DBCC SHRINKFILE target in MB
            SET @SQL = N'DBCC SHRINKFILE ([' + @LogFileName + '], ' + CAST(@TargetSizeMB AS NVARCHAR(20)) + ');';
            EXEC(@SQL);

            -- Capture after size
            SELECT @AfterSizeMB = CAST(size/128.0 AS INT)
            FROM sys.database_files
            WHERE type_desc = 'LOG' AND name = @LogFileName;

            SET @AuditMsg = 'Shrink attempted. BeforeSizeMB=' + CAST(@BeforeSizeMB AS NVARCHAR(20)) +
                            '; AfterSizeMB=' + CAST(ISNULL(@AfterSizeMB, -1) AS NVARCHAR(20));
            INSERT INTO log.LogShrinkAudit (DBName, LogFileName, StartTime, EndTime, Status, Message)
            VALUES(@DBName, @LogFileName, @StartTime, GETDATE(), 'Success', @AuditMsg);
        END
        ELSE
        BEGIN
            SET @AuditMsg = 'Abort: insufficient free space in log to shrink safely. UsedPercent=' + CAST(@BeforeUsedPercent AS NVARCHAR(10));
            INSERT INTO log.LogShrinkAudit (DBName, LogFileName, StartTime, EndTime, Status, Message)
            VALUES(@DBName, @LogFileName, @StartTime, GETDATE(), 'Skipped', @AuditMsg);
        END

        -- 10. Restore recovery model if changed (only if @AllowRecoveryChange = 1)
        IF @AllowRecoveryChange = 1
        BEGIN
            SET @SQL = N'ALTER DATABASE [' + @DBName + '] SET RECOVERY FULL WITH NO_WAIT;';
            EXEC(@SQL);

            INSERT INTO log.LogShrinkAudit (DBName, LogFileName, StartTime, Status, Message)
            VALUES(@DBName, @LogFileName, GETDATE(), 'Info', 'Recovery switched back to FULL. Ensure you take a full + log backup to re-establish chain.');
        END
    END TRY
    BEGIN CATCH
        DECLARE @ErrMsg NVARCHAR(MAX) = ERROR_MESSAGE();
        INSERT INTO log.LogShrinkAudit (DBName, LogFileName, StartTime, EndTime, Status, Message)
        VALUES(@DBName, ISNULL(@LogFileName,'Unknown'), @StartTime, GETDATE(), 'Failed', @ErrMsg);
        THROW; -- re-throw for agent visibility
    END CATCH
END
GO

Usage examples

Normal safe run (abort if log is in use):

      
        EXEC dbo.spLogClear_Managed @TargetSizeMB=1024, @MinFreePercent=20;

Emergency (must supply reason):

      
        EXEC dbo.spLogClear_Managed @TargetSizeMB=512, @Force=1, @Reason='Emergency disk pressure after large archive load';

Temporary recovery change (dangerous; document and follow-up!):

      
        EXEC dbo.spLogClear_Managed @TargetSizeMB=512, @AllowRecoveryChange=1, @Reason='One-off maintenance, will take full backup after';

Alternatives & automation options

Preferred: Fix root cause (frequent log backups) — implement a schedule BACKUP LOG to reduce VLF usage.
Ola Hallengren — maintenance solution includes integrity checks, backup, and cleanup.
PowerShell approach: use Invoke-Sqlcmd to check state and issue shrink if needed; easier to integrate with vaults and monitoring.
Third-party: enterprise tools that manage log shipping, archiving, and unintrusive cleanup.

Monitoring & telemetry (what to alert on)

log_reuse_wait_desc ≠ NOTHING — alert when it grows continuously.
Rapid autogrowth events — alert on frequent autogrowth.
Free disk space thresholds.
Number of VLFs (very large counts cause performance issues) — use DBCC LOGINFO or DMV-based scripts.

Risk mitigation & rollback plan

Before : always take current full + log backup.
If the shrink fails or the DB becomes suspect: have an emergency restore plan; always test restores in staging.
After: if you changed the recovery model, take a full backup, then restart the log backup schedule to reestablish the chain.

Masking sensitive fields example

When inserting path/server info into logs, store only hashed values or partials:

  
    INSERT INTO log.LogShrinkAudit (DBName, LogFileName, StartTime, Status, Message)
VALUES(@DBName, HASHBYTES('SHA2_256', @LogFileName), GETDATE(), 'Started', 'Initiated by ' + SUSER_SNAME());

Store mapping in a separate secure table accessible only to auditors.

“Ransomware-resistant log strategy”
“Zero-trust backup & log hygiene”
“Immutable audit trail”
“Predictable storage, instant restoration”
“Proactive log management — not reactive surgery”