Question

I have seen some stored procedures that wrap everything in a transaction.

begin transaction
    update
        table
    set
        column c = (column a * column b)
commit

Is this the right way to go about managing the transaction log? I’ve tried this with some stored procedures but it looks like the log just gets out of hand. What’s the best way to manage the transaction log when running a stored procedure that has multiple update/insert/alter statements in it?

Any help is greatly appreciated.

Answer 1

A SQL transaction is logged regardless if the query is implicitly wrapped in a transaction statement or recovery model. Depending on the recovery model the transaction will either remain in the log (full recovery mode) or be truncated (simple recovery mode). Regardless of the mode truncating the log does not shrink the file size.

Managing the log is not something that is typically handled in SQL queries within you application, rather a DBA task.

Transactions are stored to allow for recovery in the case of failure. Where you can step through transactions since your last backup to recreate the data at that point in time. Simple recovery mode does not allow this as the transaction is truncated immediately upon successful execution (COMMIT).

The log is typically truncated and shrunk upon backup. You can create SQL maintenance jobs to manage this.