1. Transaction Log Fundamentals
Mark Van de Wiel | Chief Data Officer
#493 | Silicon Valley 2016

2. Transaction Log Fundamentals
Introduction
Concepts SQL Server
Role in Replication
Troubleshooting
Q&A
SQL SATURDAY | #493 | Silicon Valley 2016

3. Introduction

4. Transactional Databases – ACID
Atomicity
Entire transaction succeeds, or doesn’t at all
Consistency
Fulfill integrity constraints
Isolation
Independent of other ongoing transactions
Durability
Recoverable once committed
SQL SATURDAY | #493 | Silicon Valley 2016

5. ACID – Yet Performance Required
Atomicity
Consistency
Isolation
Durability
SQL SATURDAY | #493 | Silicon Valley 2016

6. Transaction Log – Atomicity and Durability
Transaction commit persists changes in log
Log write must succeed to return control back to application
But not when using SQL Server 2014 Delayed Transaction Durability
Performance considerations
Modified data blocks may still only be in memory
Log writes are sequential (not random)
SQL SATURDAY | #493 | Silicon Valley 2016

7. Transaction Log – Role in Recovery
Use consistent set of database files
If needed restore from backup
Replay transaction log
Also enables point-in-time recovery
Requires full trail of logs from begin till end
SQL SATURDAY | #493 | Silicon Valley 2016

8. Concepts SQL Server

9. SQL Server Transaction Log
Typically single logical file
Possibly multiple physical files (if required)
Split into multiple Virtual Logs
Overwritten all the time
But any open transaction cannot be overwritten
Automatically grows as needed
Truncation is moving the log “forward”
I.e. allowing overwrites
Virtual Log is the granularity
SQL SATURDAY | #493 | Silicon Valley 2016

10. SQL Server Transaction Log
LSN = Log Sequence Number
MinLSN is minimum LSN required for database-wise rollback
SQL SATURDAY | #493 | Silicon Valley 2016

11. SQL Server Transaction Log
Will grow if overwrite is not possible
SQL SATURDAY | #493 | Silicon Valley 2016

12. SQL Server Recovery Modes
Simple – limited recovery
No transaction log backup
No point-in-time recovery
Bulk – may lose data during recovery
Log most transactions but not bulk transactions
Used to speed up data warehouse loads
Full – no data loss during recovery
Log all transactions
SQL SATURDAY | #493 | Silicon Valley 2016

13. Role in Replication

14. Transactional Replication
Transaction log contains operations and data
Replication technology mines the log
Replays transactions on another system
Using regular SQL statements
SQL SATURDAY | #493 | Silicon Valley 2016

15. Replication Requirements
Supplemental logging – “articles”
Requires primary keys
Increases transaction log generation
Alternative Change Data Capture (CDC) if no primary keys
Continuous trail of logs
SQL SATURDAY | #493 | Silicon Valley 2016

16. Troubleshooting

17. Transaction Log Trouble
Growth – no truncation
Performance bottleneck
SQL SATURDAY | #493 | Silicon Valley 2016

18. No Truncation – Reasons
Query log_reuse_wait, log_reuse_wait_desc in sys.databases
Multiple reasons, including:
Active transaction
Including deferred transactions
AlwaysOn (and mirroring)
Replication
Log backup
Checkpoint
SQL SATURDAY | #493 | Silicon Valley 2016

19. Transactions Commit, or rollback Commit modes DML and DDL
Auto commit – default
Explicit begin/end transaction
Implicit begin/end transaction
DML and DDL
SQL SATURDAY | #493 | Silicon Valley 2016

20. AlwaysOn Apply transaction logs on another system
Running in recovery mode
SQL SATURDAY | #493 | Silicon Valley 2016

21. Checkpoints Write “dirty” pages to disk Update transaction log Types
Indicate a consistent point to roll forward from
Types
Automatic – through sp_configure
Indirect – if Revovery Time Objective (RTO) set
Manual – CHECKPOINT
Internal
SQL SATURDAY | #493 | Silicon Valley 2016

22. Performance Review transactions Re-direct reads through AlwaysOn
Unload using replication
Use faster hardware
SQL SATURDAY | #493 | Silicon Valley 2016

23. Transaction Log Fundamentals
Introduction
Concepts SQL Server
Role in Replication
Troubleshooting
Q&A
SQL SATURDAY | #493 | Silicon Valley 2016

24. Q&A

25. Mark Van de Wiel | Chief Data Officer
#493 | Silicon Valley 2016