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

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

Introduction

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

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

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

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

Concepts SQL Server

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

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

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

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

Role in Replication

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

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

Troubleshooting

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

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

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

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

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

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

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

Q&A

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