Fix SQL Server error 0XC0190058: Record too long for log

Quick answer

Break your operation into smaller batches or use trace flag 610 in SQL Server 2016 and older to reduce log record size. For SQL Server 2017+, the issue is rare but can still hit with MAX types.

Why this error shows up

You're running an operation—maybe a big index rebuild, a bulk insert with LOB data, or a large batch update—and SQL Server chokes. The error code 0XC0190058 maps to STATUS_TRANSACTION_RECORD_TOO_LONG. What happened is the log manager tried to write a log record bigger than SQL Server's internal limit of about 128 KB per record. This limit is hardcoded in older versions (pre-2016) and relaxed in 2016+ but still exists for certain operations. I've seen this most often in SQL Server 2014 and 2016 when someone runs a single INSERT INTO ... SELECT that writes thousands of rows, each containing large VARCHAR(MAX) or NVARCHAR(MAX) columns. The log record for a bulk insert in full recovery mode can balloon past the limit.

The important thing to understand: this isn't about transaction log file size or disk space. It's about the record's length within the log itself. So adding more space won't help.

Step-by-step fix

Identify the operation that triggered the error. Check SQL Server error log or application logs. Look for the exact batch or stored procedure. For example, you might see: Msg 9002, Level 17, State 4, Line 1 with the 0XC0190058 code. The operation usually involves a large number of rows or large columns.
Break it into smaller batches. This is the real fix 90% of the time. Instead of one UPDATE dbo.BigTable SET Col1 = 'value' for 1 million rows, do it in chunks of 10,000 rows per batch. Use a WHILE loop with SET ROWCOUNT or TOP. Here's an example:
```
DECLARE @BatchSize INT = 10000;WHILE 1 = 1BEGIN    UPDATE TOP (@BatchSize) dbo.BigTable    SET Col1 = 'value'    WHERE Col1 IS NULL;    IF @@ROWCOUNT = 0 BREAK;END
```
After running this, check if the error returns. You should see the update complete without hitting the log record limit.
If you're doing a bulk insert, use trace flag 610. This trace flag enables minimal logging for inserts into indexed tables in SQL Server 2016 and older. It reduces the size of each log record dramatically. Enable it with:
```
DBCC TRACEON(610, -1);
```
Then run your bulk insert. After you're done, disable it with DBCC TRACEOFF(610, -1). Note: this works only in full recovery mode if the target table is empty or has no indexes. For production systems, test first.
Switch to simple recovery model temporarily (if safe). If you're in full recovery and can accept the risk, change to simple recovery model for the duration of the operation. This reduces logging for bulk operations. Run:
```
ALTER DATABASE YourDatabase SET RECOVERY SIMPLE;-- Run your operation hereALTER DATABASE YourDatabase SET RECOVERY FULL;
```
Expected outcome: the operation completes, but you lose the ability to do point-in-time recovery for that period. Don't do this if you have a strict RPO.
Upgrade SQL Server if you're on pre-2016. Microsoft increased the log record size limit starting with SQL Server 2016 (13.x). If you're on 2014 or older, upgrading eliminates this error for most scenarios. Test your application on the new version first—I've seen cases where the error simply disappears after upgrading to 2016 SP2 or later.

Alternative fixes (when main steps fail)

Reduce column sizes. If you're logging large VARCHAR(MAX) values, consider using VARCHAR(8000) or splitting the data across rows. This reduces the per-record log size. Not always practical, but it works.
Use partitioning. For index rebuilds on huge tables, partition the table and rebuild one partition at a time. Each rebuild generates a smaller log record.
Disable nonclustered indexes temporarily. Before a bulk insert, drop nonclustered indexes, run the insert, then rebuild them offline. Each index update generates log records; fewer indexes means smaller records.

Prevention tip

The single best thing you can do: always write operations in batches of 10,000 rows or less when updating large tables. This isn't just for this error—it also prevents transaction log growth, reduces blocking, and makes rollback faster. Make it a habit. I've seen teams spend hours on this error when a simple TOP 10000 would have saved them.