7/18/2019 0000421644

http://slidepdf.com/reader/full/0000421644 1/3

SAP Note 

Header Data

Symptom 

The transaction log of the SQL Server is full. The following message is displayed in the error logof the SQL Server:Server: Msg 9002, Level 17, State 2, Line 1The log file for database '<SID>' is full. Back up the transaction log for the database to free upsome log space.

Other Terms 

9002, transaction log full, truncate log on checkpoint, bulk copy,bulk-logged, simple, recovery model, bulk-logged recovery model

Reason and Prerequisites 

The following provides information about functions of SQL Server 2000. If they differ from SQLServer 7, this will be specifically mentioned.

The transaction log of the SQL Server contains all of the information required to repeat (rollforward) the transactions that were executed and to cancel them out (roll back). Consequently, thelog file that is required for this must be larger than the ones required for other databases.Within the log, there is a differentiation between the active part, the inactive part, and theunused part of the log. The unused part is free space, which is available for saving transactions.

The inactive part is the area of the log that consists only of transactions that have already beencompleted and does not contain any parts of open transactions. With regard to time, the entireinactive part of the log always appears before the active part. The active part of the log is thearea that extends from the start of the oldest transaction that is still open up to the currentpoint of the log. Even if other transactions have already been completed and saved in the log sincethe start of the oldest transaction that is still open, these still belong to the active part.

For example:

The following shows the simplified version of the end of a transaction log.

------- ------- ------ ------ ------- -------- -------- ------... | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | ... |-------|-------|------|------|-------|--------|--------|------|... | Begin | Begin | Upd. | Upd. | Begin | Commit | Commit | Upd. |... | TA1 | TA2 | TA1 | TA2 | TA3 | TA3 | TA1 | TA2 | 

------- ------- ------ ------ ------- -------- -------- ------

At the time 107, transaction 2 (TA2) is the only active transaction. Therefore, the active part ofthe log stretches from 101, the start of the oldest transaction TA2 that is still open, up to 107,the last log entry that is written. The inactive part in this example is represented by all of theentries that are before entry 100 and entry 100.

If error 9002 occurs, the transaction log no longer provides enough space to include the currenttransactions. This type of log overflow may have the following causes:

1. The log is too small.

The transaction log is too small for the number of transactions involved. Increase thelog file to a size that corresponds to your transaction volume. A log file size of 3 GB or more isnot particularly unusual.

2. A log backup is not executed or is executed too infrequently.

The log is truncated during a log backup, which releases the space of the inactiveparts again for new entries. Schedule more frequent log backups to avoid this problem in future.

The file size of the log is not changed by a log backup. If the log increased whilethe workload was high, it is not reduced again by a log backup. To reduce a log, refer to Note363018.

3. Long-running or extensive transactions are in use.

Long-running or extensive transactions may prevent the log from being truncated

421644 - SQL error 9002: The transaction log is full  

Version  4 Validity: 19.04.2010 - active Language  English

Released On  20.04.2010 08:34:26

Release Status Released for Customer

Component  BC-DB-MSS Microsoft SQL Server

Priority  Recommendations / Additional InfoCategory  Consulting

7/18/2019 0000421644

http://slidepdf.com/reader/full/0000421644 2/3

because it can be truncated only before the oldest active transaction. You can use the command DBCCOPENTRAN to display long-running transactions.

For example:select getdate()DBCC OPENTRAN('PRD')

------------------------------------------------------2001-09-06 11:22:18.693(1 row(s) affected)

Transaction information for database 'PRD'.Oldest active transaction:SPID (server process ID) : 51UID (user ID) : 1Name : user_transaction LSN : (175:241:2) Start time : Aug 15 2001 11:11:34:643AM DBCC execution completed. If DBCC printed error messages, contact yoursystem administrator.

These transactions do not necessarily have to be triggered by the SAP system, but mayalso be triggered by the Enterprise Manager, the Query Analyzer or software from third-partysuppliers, for example.

You cannot always avoid long-running or extensive transactions in an SAP system. Alarger log file is required to execute such transactions.

If the "autogrow" option is set for the log file and the error still occurs, the log cannot be

increased by the size that was set. There is either not enough space on the volume or the size thatwas set for the automatic growth is too large.

The Bulk-Logged Recovery Model 

This option does not deactivate the entire logging behavior for transactions or even only thetransaction log. Instead, it ensures that logging is minimal for special operations. In general,these operations are used only rarely or are not used at all in an SAP system. In the case of largedatasets, however, this minimal logging may also cause the log to increase considerably.All other database operations are still fully logged and, therefore, also cause the log size toincrease.Log backups that are generated in 'bulk-logged' mode can only be restored completely; a 'point-in-time' recovery is not supported.SQL Server 7:In SQL Server 7, the option is called 'Select into/bulk copy' and results in a similar behavior. InSQL Server 7, however, activating this option interrupts the chain of transaction backups. Logbackups that were generated in 'Select into/bulk copy' mode cannot be restored.

A continuous backup chain of log backups can be set up again only after the option has beendeactivated and a complete database backup has been executed.

The Simple Recovery Model 

This option causes the transaction log to be truncated if a checkpoint occurs. In general, the SQLServer regularly sets approximately one checkpoint every minute. A checkpoint is always set when thelog has reached a fill level of 70%.Long-running or very extensive database transactions may cause the log to fill up despite thisoption. These transactions may cause the active part to extend over the entire log file. In thiscase, it is not possible to automatically truncate the log. To be able to execute these transactionsdespite this, a larger log file is required.After resetting the option, you must carry out a full database backup because the chain ofconsecutive transaction backups was interrupted when you activated the option. You can carry outtransaction backups based on the full backup again only after the full backup has been carried out.SQL Server 7:In SQL Server 7, the option is called 'trunc. log on chkpt.' and results in the same behavior of theSQL Server

Solution 

You have several options to solve this problem:

1. If sufficient space is available on the current disk drive, increase the log file manuallyusing Note 363018. As an alternative, change the size of the "autogrow" option to a value thatcan still be used to increase the log file. The file is then automatically increased.

This change may solve the problem only temporarily because the space that is generallyavailable is not very large. Therefore, there is a risk that the space is also used up bytransactions before a log backup is completed.

2. Create an additional log file on another disk drive to increase the space available for

saving transactions. In this case, Note 363018 also provides the required information andcommands.

3. Backup the log or manually force the system to truncate the transaction log to remove theinactive parts from the log and free up space again within the log. If you are unsure about whatto do, a backup is always the better option.

Use the 'backup log' command with the 'with truncate_only' option to truncate the log.This does not cause the log to be saved, but only removes the inactive parts from the log.

7/18/2019 0000421644

http://slidepdf.com/reader/full/0000421644 3/3

 

For example:

backup log <SID> with truncate_only

After you have manually truncated the log, you must carry out a complete data backupbecause this interrupts the chain of transaction backups. As long as you have not carried out adatabase backup, the transactions will only be saved in the transaction log up to the nextcheckpoint (implicit Simple Recovery Model). The transactions are logged again normally and can besaved only after a full database backup has been carried out.

Other Attributes

Validity

This document is not restricted to a software component or software component version

References

This document refers to:

SAP Notes 

This document is referenced by:

SAP Notes (5) 

NT/INTEL

  MSSQLSRV

1420452 FAQ: Restore and recovery with MS SQL Server  

555223 FAQ: Microsoft SQL Server  

534036 SAP LT: System settings for conversions 

400251 Index creation fills up transaction log 

363018 File management for SQL Server  

400251 Index creation fills up transaction log 

363018 File management for SQL Server  

1420452 FAQ: Restore and recovery with MS SQL Server  

534036 SAP LT: System settings for conversions 

555223 FAQ: Microsoft SQL Server  

Operating system

Database System