1 / 11

T ransaction log grows unexpectedly

T ransaction log grows unexpectedly . SUMMARY. Error message . transaction log expansion may result in . A very large transaction log file. Transactions may fail and may start to roll back. Transactions may take a long time to complete. Performance issues may occur.

noma
Download Presentation

T ransaction log grows unexpectedly

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Transaction log grows unexpectedly

  2. SUMMARY Error message transaction log expansion may result in A very large transaction log file. Transactions may fail and may start to roll back. Transactions may take a long time to complete. Performance issues may occur. Blocking may occur. • Error: 9002, Severity: 17, State: 2The log file for database '%.*ls' is full. • If you are using SQL Server 2005, you receive an error message that is similar to the following: • Error: 9002, Severity: 17, State: 2The transaction log for database '%.*ls' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases • In addition to this error message, SQL Server may mark databases suspect because of a lack of space for transaction log expansion. For additional information about how to recover from this situation, see the "Insufficient Disk Space" topic in SQL Server Books Online.

  3. Causes • Uncommitted transactions • Extremely large transactions • Operations: DBCC DBREINDEX and CREATE INDEX • While restoring from transaction log backups • Client applications do not process all results • Queries time out before a transaction log completes the expansion and you receive false 'Log full' error messages • Unreplicated transactions

  4. Uncommitted transactions • Explicit transactions remain uncommitted if 1: We do not issue an explicit COMMIT or ROLLBACK command. Frequently occurs when 1: An application issues a CANCEL or a Transact SQL KILL command without a corresponding ROLLBACK command. 2: The transaction cancellation occurs, but it does not roll back; therefore, SQL Server cannot truncate every transaction that occurs after this because the aborted transaction is still open. ** You can use the DBCC OPENTRAN Transact-SQL reference to verify if there is an active transaction in a database at a particular time.

  5. Extremely large transactions • Log records in the transaction log files are truncated on a transaction-by-transaction basis. • If the transaction scope is large, that transaction and any transactions started after it are not removed from the transaction log unless it completes. This can result in large log files. • If the transaction is large enough, the log file might use up the available disk space and cause the "transaction log full" type of error message such as Error 9002. • Additionally, it takes a lot of time and SQL Server overhead to roll back large transactions.

  6. Operations: DBCC DBREINDEX and CREATE INDEX • When you use the Full recovery mode and you run DBCC DBREINDEX, the transaction log may expand significantly

  7. While restoring from transaction log backups • A standby (warm backup) server is a second server that can be brought online in the event of failure of the primary production server. • Monitor (with DBCC SQLPERF (LOGSPACE)) the transaction log space used on a standby server after each RESTORE WITH STANDBY of a transaction log, you will see the percentage of the log used apparently increasing. The percentage may appear to approach 100 percent usage and remain there. However, no matter how many logs are restored, the transaction log will not fill up, even if the transaction log is set at a fixed size with no growth allowed, • Drives should have some unused space and are not at full capacity.

  8. Client applications do not process all results • If you issue a query to SQL Server and you do not handle the results immediately, you may be holding locks and reducing concurrency on your server. • For example, suppose you issue a query that requires rows from two pages to populate your result set. SQL Server parses, compiles, and runs the query. This means that shared locks are placed on the two pages that contain the rows that you must have to satisfy your query. Additionally, suppose that not all rows fit onto one SQL Server TDS packet (the method by which the server communicates with the client). TDS packets are filled and sent to the client. If all rows from the first page fit on the TDS packet, SQL Server releases the shared lock on that page but leaves a shared lock on the second page. SQL Server then waits for the client to request more data . This means that the shared lock is held until the client requests the rest of the data. Other processes that request data from the second page may be blocked. • SQL Server TDS packet • application-level protocol called Tabular Data Stream (TDS) for communication between client applications and SQL Server.

  9. Queries time out before a transaction log completes the expansion and you receive false 'Log full' error messages • A query can cause the transaction log to automatically expand if the transaction log is almost full. This may take additional time, and a query may be stopped or may exceed its time-out period because of this. • If we have the auto-shrink option turned on for a database, there is an extremely small time during which a transaction log tries to automatically expand, but it cannot because the auto-shrink function is running simultaneously. This may also cause false instances of error 9002.

  10. Unreplicatedtransactions • The transaction log size of the publisher database can expand if you are using replication. • Uncommitted transactions, are not deleted after checkpoint or transaction log backup until the log-reader task copies the transactions to the distribution database and unmarks them. • If an issue with the log-reader task prevents it from reading these transactions in the publisher database, the size of the transaction log may continue to expand as the number of non-replicated transactions increases

  11. How to Stop Growing Log File Too Big • Convert the Recovery Model to Simple Recovery • Start Taking Transaction Log Backup • Shrink the transaction log (.LDF) files. • Perform a full-backup of your SQL Server databases. • Set the size of the log files to a large value to avoid the automatic expansion of the log file. • Configure the automatic expansion of log fils by using memory units instead of a percentage. • When defragmenting indexes use DBCC INDEXDEFRAG instead of DBCC DBREINDEX. Using DBCC DBREINDEX, the transaction log file might expand drasticly when your database is in Full recovery model. And the DBCC INDEXDEFRAG statement does not hold the locks for a long time, unlike the DBCC DBREINDEX statement.

More Related