Transaction Log Internals and Troubleshooting

Similar documents
Visual Studio for SQL Developers

Turbo-Charged Transaction Logs. David Maxwell

Persistence Is Futile- Implementing Delayed Durability in SQL Server

Basics of SQL Transactions

Outline. Failure Types

Database Management System

) Intel)(TX)memory):) Transac'onal) Synchroniza'on) Extensions)(TSX))) Transac'ons)

CA485 Ray Walshe Google File System

Microsoft SQL Server Fix Pack 15. Reference IBM

Recoverability. Kathleen Durant PhD CS3200

The Google File System

Microsoft SQL Server Database Administration

System Malfunctions. Implementing Atomicity and Durability. Failures: Crash. Failures: Abort. Log. Failures: Media

In This Lecture. Transactions and Recovery. Transactions. Transactions. Isolation and Durability. Atomicity and Consistency. Transactions Recovery

ARIES (& Logging) April 2-4, 2018

Module 3: Creating and Managing Databases

Exchange 2010 Transaction Logs Not Truncated After Full Backup

ADMINISTERING MICROSOFT SQL SERVER CERTIFICATION QUESTIONS AND STUDY GUIDE

) Intel)(TX)memory):) Transac'onal) Synchroniza'on) Extensions)(TSX))) Transac'ons)

Orphans, Corruption, Careful Write, and Logging, or Gfix says my database is CORRUPT or Database Integrity - then, now, future

Crash Recovery CMPSCI 645. Gerome Miklau. Slide content adapted from Ramakrishnan & Gehrke

Percona Live September 21-23, 2015 Mövenpick Hotel Amsterdam

SQL Server 2014: In-Memory OLTP for Database Administrators

A tomicity: All actions in the Xact happen, or none happen. D urability: If a Xact commits, its effects persist.

RECOVERY CHAPTER 21,23 (6/E) CHAPTER 17,19 (5/E)

User Perspective. Module III: System Perspective. Module III: Topics Covered. Module III Overview of Storage Structures, QP, and TM

Mark Broadbent Principal Consultant SQLCloud SQLCLOUD.CO.UK

CS122 Lecture 15 Winter Term,

The DBA Survival Guide for In-Memory OLTP. Ned Otter SQL Strategist

Netcast

COS 318: Operating Systems. Journaling, NFS and WAFL

Transaction Management: Crash Recovery (Chap. 18), part 1

some sequential execution crash! Recovery Manager replacement MAIN MEMORY policy DISK

Atomicity: All actions in the Xact happen, or none happen. Consistency: If each Xact is consistent, and the DB starts consistent, it ends up

TempDB how it works? Dubi Lebel Dubi Or Not To Be

Crash Recovery Review: The ACID properties

Chapter 11: File System Implementation. Objectives

Crash Recovery. The ACID properties. Motivation

The Google File System

Topics. File Buffer Cache for Performance. What to Cache? COS 318: Operating Systems. File Performance and Reliability

) Intel)(TX)memory):) Transac'onal) Synchroniza'on) Extensions)(TSX))) Transac'ons)

Crash Recovery. Chapter 18. Sina Meraji

Scale out Read Only Workload by sharing data files of InnoDB. Zhai weixiang Alibaba Cloud

Journaling. CS 161: Lecture 14 4/4/17

Review: The ACID properties. Crash Recovery. Assumptions. Motivation. More on Steal and Force. Handling the Buffer Pool

Database Recovery Techniques. DBMS, 2007, CEng553 1

Transaction Management. Pearson Education Limited 1995, 2005

Database Technology. Topic 11: Database Recovery

Product Guide. McAfee Performance Optimizer 2.2.0

Chapter 17: Recovery System

Failure Classification. Chapter 17: Recovery System. Recovery Algorithms. Storage Structure

Recovery and Logging

SQL Server DBA Course Content

Google File System. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung Google fall DIP Heerak lim, Donghun Koo

Georgia Institute of Technology ECE6102 4/20/2009 David Colvin, Jimmy Vuong

goals monitoring, fault tolerance, auto-recovery (thousands of low-cost machines) handle appends efficiently (no random writes & sequential reads)

Lecture X: Transactions

Activant Solutions Inc. SQL Server 2005: Data Storage

COMPLETE ONLINE MICROSOFT SQL SERVER DATA PROTECTION

Operating Systems. Lecture File system implementation. Master of Computer Science PUF - Hồ Chí Minh 2016/2017

DBS related failures. DBS related failure model. Introduction. Fault tolerance

CS3600 SYSTEMS AND NETWORKS

Current Topics in OS Research. So, what s hot?

File Systems. CS170 Fall 2018

Proper Care and Feeding of your SQL MDB

Performance Monitoring AlwaysOn Availability Groups. Anthony E. Nocentino

ACID Properties. Transaction Management: Crash Recovery (Chap. 18), part 1. Motivation. Recovery Manager. Handling the Buffer Pool.

Manually Purge Transaction Logs Exchange 2007

Review: The ACID properties. Crash Recovery. Assumptions. Motivation. Preferred Policy: Steal/No-Force. Buffer Mgmt Plays a Key Role

CLOUD-SCALE FILE SYSTEMS

EI 338: Computer Systems Engineering (Operating Systems & Computer Architecture)

Backup, Recovery, and System Availability

Tuesday, April 6, Inside SQL Server

The Google File System (GFS)

MySQL Architecture and Components Guide

CAS CS 460/660 Introduction to Database Systems. Recovery 1.1

Synergetics-Standard-SQL Server 2012-DBA-7 day Contents

SQL Server DBA Online Training

Overview of Transaction Management

SQL Server 2014 Training. Prepared By: Qasim Nadeem

Advanced Database Management System (CoSc3052) Database Recovery Techniques. Purpose of Database Recovery. Types of Failure.

Performance Monitoring AlwaysOn Availability Groups. Anthony E. Nocentino

Optimizing tempdb Performance

Recovery from failures

Backup types. Excerpted from

Performance Monitoring AlwaysOn Availability Groups. Anthony E. Nocentino

! Design constraints. " Component failures are the norm. " Files are huge by traditional standards. ! POSIX-like

File System Implementation. Sunu Wibirama

Distributed Systems 16. Distributed File Systems II

Managing Relativity SQL log files

DHANALAKSHMI COLLEGE OF ENGINEERING, CHENNAI

InnoDB: Status, Architecture, and Latest Enhancements

Deep Dive: InnoDB Transactions and Write Paths

McAfee Performance Optimizer 2.1.0

Problems Caused by Failures

GFS: The Google File System. Dr. Yingwu Zhu

Filesystem. Disclaimer: some slides are adopted from book authors slides with permission 1

6.830 Lecture 15 11/1/2017

2072 : Administering a Microsoft SQL Server 2000 Database

Database Management Systems Reliability Management

Transcription:

Transaction Log Internals and Troubleshooting September 3, 2015 Berlin, Germany Andrey Zavadskiy, Krasnodar, Russia MCSE/MCSD/MCT

About me Solutions architect, SQL &.NET developer 20 years in IT industry Worked with SQL Server since 7.0 back in 2001 Developed in C#, ASP.NET, MVC, JavaScript, SharePoint MCDBA, MCSE, MCSD MCT since 2008 PASS speaker http://andreyzavadskiy.com https://www.facebook.com/ andrey.k.zavadskiy @AndreyZavadskiy https://www.linkedin.com/in/ zavadskiy

About Krasnodar Regional center Was founded in 1793, renamed in 1920 Original name Yekaterinodar Catherine s gift Distances: Istanbul 929 km Moscow 1196 km Warsaw 1541 km Copenhagen 2200 km Brussels 2640 km Paris 2793 km Lisbon 3995 km 3

Contents Logical and physical architecture Transactions and transaction log Log file growing and truncation fragmentation Troubleshooting Delayed durability (SQL Server 2014) 4

Transaction Log. What for? Supports ACID properties Recovery in case of database crash or SQL Server startup Rolling a restored database, file, filegroup, or page forward to the point of failure Supporting transactional replication Supporting high availability and disaster recovery solutions 5

Logical Architecture Just a list of log records Identified by Log Sequence Number (LSN) 00000028 : 00000120 : 0002 number Log block number Log record number Log record contains: Info about transaction Before and after images Allocation information, etc. Can be viewed by fn_dblog() 6

Physical Architecture (1) Header 1 2 3 4 5 Active Active Inactive/ unused 8KB file header with metadata Consists of Virtual Log Files () has logical sequence number (FSeqNo) Minimum 2 s, minimal size = 248KB Filled by zero on creation Inactive/ unused Inactive/ unused 7

Physical Architecture (2) 1 2 3 4 5 Active Active Inactive/ unused Inactive/ unused Inactive/ unused Log blocks Log records Each is splitted into log blocks Log block size = from 512B to 60 KB Contains log records from multiple transactions 8

Transactions and Transaction Log Records all modifications made by each transaction Single transaction produces some log records Written to transaction log file Implements Write-Ahead Log (WAL) by default Can be changed by Delayed Durability 9

Transaction Commit All log records up to the LSN of LOP_COMMIT_XACT must be written to disk Waits for acknowledgement from the synchronous mirror or Availability Group server (if applicable) Release all locks placed by the transaction Acknowledge the commit to user 10

Transaction Log Flush SQL Server task LOGBUFFER wait Up to 128*60 KB buffers 64 bit 32*60 KB buffers 32 bit Commit Log cache for each database Log writer (async) WRITELOG wait Write complete Transaction log file 11

Transaction Log Writes Always writes sequentially Multiple log files doesn t give any performance benefit Limits on outstanding I/O: SQL Server version Prior to 2005SP1 2005SP1 2008R2 Quantity 64 bit 32 bit Amount, KB 8 8 480 32 8 480 (2005) 3840 (2008) 2012 and later 112 16 3840 12

Log File Operations Operation File size Number of Comment Growing Increasing (expands a log file according to growth parameters) Increasing (calculated by formula) Truncation Not changed Not changed Only marks inactive s as truncated Shrinking Can be reduced Can be reduced Depends on active s 13

Log File Growing (1) 1 2 3 4 5 Active Active Active Active Unused Start of Logical Log MinLSN End of Logical Log Last checkpoint SQL Server allocates so many s as needed to rollback the longest active transaction New s are filled by zero 14

Log File Growing (1) 1 2 3 4 5 Active Active Active Active Active 6 7 Unused Unused Start of Logical Log MinLSN Last checkpoint End of Logical Log SQL Server allocates so many s as needed to rollback the longest active transaction New s are filled by zero 15

Size Algorithm Used on log creation for all versions Used on log growth for SQL Server 2012 and earlier Depends on chunk size to be added Chunk size Size <= 1 MB 1Mb < Size <= 64 Mb Number of added Complicated, playing with first 248 KB s 4 s 64 Mb < Size <= 1Gb 8 s Size > 1G 16 s 16

New Size Algorithm Used only on log growth since SQL Server 2014 Depends on chunk size to be added: If the chunk size less than 1/8 of the current log size, create 1 equal to the growth size Otherwise, create s according to the old algorithm 17

Log File Growing (2) Log file has initial and maximum sizes Maximum size can be fixed or unlimited* Log file can be expanded manually or automatically If log autogrowth occurs: New s will be added and zero-initialized It leads to a wait in transaction processing 18

Inactive Log Record Log record becomes inactive when: The transaction that this log record is part of has committed The database pages changed by this transaction/log record have been written to disk by checkpoint The log record is not needed for a backup (full, differential, or log) The log record is not needed for any feature that reads the log (Database mirroring, AlwaysOn Group, Transactional replication, Change Data Capture) 19

Log Truncation (1) 1 2 3 4 5 Active Active Active Active Unused Start of Logical Log MinLSN End of Logical Log Last checkpoint is truncated when: It has NO active log records After checkpoint in simple/pseudo-full recovery model After log backup in full or bulk-logged recovery model 20

Log Truncation (2) 1 2 3 4 5 Inactive Inactive Active Active Unused Start of Logical Log MinLSN End of Logical Log Last checkpoint is marked as truncated is NOT filled with zero 21

Circular Nature of the Log 1 2 3 4 5 Active Inactive Active Active Active End of Logical Log Start of Logical Log MinLSN Last checkpoint Inactive can be overwritten Parity bits are flipped after roll-over 22

Shrinking Automatic Database AUTO_SHRINK option Manual DBCC SHRINKFILE Shrink unused s/space from the end of the log file Could shrink maximum to the first 2 s 23

Transaction Log Issues Excessive log growing and error 9002 Log shrinking fragmentation 24

Excessive Log Growing There are many reasons Look at log_reuse_wait_desc in sys.databases See section Factors That Can Delay Log Truncation in https://msdn.microsoft.com/en-us/ms190925.aspx How to correct: Reason LOG_BACKUP ACTIVE_BACKUP_OR_RESTORE Action Take a log backup frequently Re-evaluate the backup strategy/plan ACTIVE_TRANSACTION Kill erroneous or poorly written transaction REPLICATION Check transactional replication Consider using SIMPLE recovery model 25

Monitoring Transaction Log Space Performance Monitor Log File(s) Size (KB) Log File(s) Used Size (KB) Percent Log Used Log Growths DBCC SQLPERF(LOGSPACE) sys.dm_db_log_space_usage (since SQL Server 2012) 26

Error 9002 If log can t auto-grow: You will receive error 9002 Rolls back uncommitted transactions Stops activity (writing new transactions to log file) How to correct: Check the reason, then take a corresponding action Extend log file (if applicable) Add an additional log file 27

DEMO Excessive log growing and error 9002 Deleting additional log files 28

Log shrinking Steps: Run DBCC LOGINFO to estimate the number of s and last active Truncate log Make log backup for Full or Bulk-logged recovery model Make CHECKPOINT in Simple recovery model Wait for log roll-over and truncate again Run DBCC SHRINKFILE 29

Fragmentation are added during log growth Improper growth value leads to a big number of small or tiny s Truncated s can be in any place of transaction log Leads to fragmentation in sequence Causes problems in log activity, backups or readers If number of is hundreds or thousands, think about defragmentation 30

Removing Fragmentation Manually shrink file Repeat shrinking to reach minimum file size Change transaction log file size and/or autogrowth size should not be bigger than 500 MB Perform manual growing to get optimal log size 31

DEMO Shrinking log file Removing fragmentation 32

Delayed Durability in SQL Server 2014 Commit transactions BEFORE log flush Defined at database level Benefits: Reducing waits Increasing throughput by larger flush chunks Reducing contention for log I/O Disadvantages: Risk of data loss 33

Transaction Log Flush in Delayed Durability SQL Server task Commit Log cache for each database Log writer (async) Write complete Transaction log file 34

DEMO Speeding up transactions with Delayed Durability 35

Summary Place transaction log on separate fast physical disk Keep just one log file Monitor log size and performance Prevent log filling up Manage the number of s Think about upgrade to the latest SQL Server versions 36

Questions?

Thank you for attending!