ล็อกของธุรกรรม grows โดยไม่คาดคิด หรือใช้ทั้งหมดบนคอมพิวเตอร์ที่ใช้ SQL Server

การแปลบทความ การแปลบทความ
หมายเลขบทความ (Article ID): 317375 - ผลิตภัณฑ์ที่เกี่ยวข้องในบทความนี้
ขยายทั้งหมด | ยุบทั้งหมด

เนื้อหาบนหน้านี้

สรุป

ใน SQL Server 7.0 ใน SQL Server 2000 และ ใน SQL Server 2005 กับการตั้งค่า autogrow แฟ้มล็อกธุรกรรมสามารถขยายโดยอัตโนมัติ

โดยทั่วไป ขนาดของแฟ้มล็อกธุรกรรม stabilizes เมื่อคุณสามารถเก็บจำนวนสูงสุดของธุรกรรมที่เกิดขึ้นระหว่าง truncations ในล็อกธุรกรรมที่ทริกเกอร์ checkpoints หรือธุรกรรมการสำรองข้อมูลแฟ้มบันทึก

อย่างไรก็ตาม ในบางกรณีอาจล็อกธุรกรรมกลายเป็นมากมีขนาดใหญ่ และรันเกินจำนวนช่องว่าง หรือกลายเป็นทั้งหมด โดยทั่วไป คุณได้รับข้อความแสดงข้อผิดพลาดต่อไปนี้เมื่อธุรกรรมที่บันทึกแฟ้มใช้เนื้อที่ดิสก์ที่มีอยู่ และไม่สามารถขยายอีก:
ข้อผิดพลาด: 9002 ความรุนแรง: สถานะ 17 : 2
แฟ้มบันทึกสำหรับฐานข้อมูล ' % * ls' จะเต็ม
ถ้าคุณใช้ SQL Server 2005 คุณได้รับข้อความแสดงข้อผิดพลาดที่คล้ายกับข้อความต่อไปนี้:
ข้อผิดพลาด: 9002 ความรุนแรง: สถานะ 17 : 2
ล็อกธุรกรรมสำหรับฐานข้อมูล ' % * ls' จะเต็ม เมื่อต้องการทราบสาเหตุช่องว่างในบันทึกไม่สามารถถูก reused ดูคอลัมน์ log_reuse_wait_desc ใน sys.databases
ทำเครื่องนอกเหนือจากการข้อความข้อผิดพลาดนี้ SQL Server อาจหมายสงสัยฐานข้อมูลเนื่องจากความไม่มีช่องว่างสำหรับให้ขยายล็อกธุรกรรม สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการแก้ไขสถานการณ์นี้ ให้ดูที่หัวข้อ "เนื้อที่ดิสก์ไม่เพียงพอ" ใน SQL Server หนังสือออนไลน์

นอกจากนี้ ขยายล็อกธุรกรรมอาจทำในสถานการณ์ต่อไปนี้:
  • แฟ้มล็อกธุรกรรมที่มีขนาดใหญ่มาก
  • ธุรกรรมอาจล้มเหลว และอาจเริ่มการทำงานเพื่อย้อนกลับ
  • ธุรกรรมอาจใช้เวลานานให้เสร็จสมบูรณ์
  • ปัญหาประสิทธิภาพการทำงานที่อาจเกิดขึ้น
  • การบล็อกอาจเกิดขึ้น

สาเหตุต่างๆ

ขยายล็อกธุรกรรมอาจเกิดขึ้นเนื่องจากความเหตุผลหรือสถานการณ์ต่อไปนี้:หมายเหตุ:ใน SQL Server 2005 คุณสามารถตรวจทานนี้log_reuse_waitและlog_reuse_wait_descคอลัมน์ที่มีมุมมอง sys.databases ของแค็ตตาล็อกเพื่อตรวจสอบสิ่งต่าง ๆ ต่อไปนี้:
  • เหตุใดพื้นที่การบันทึกของธุรกรรมจะไม่ reused
  • เหตุใดล็อกธุรกรรมไม่สามารถถูกตัดทอน

ธุรกรรม uncommitted

ธุรกรรมที่ชัดเจนยังคง uncommitted ถ้าคุณออกชัดเจนยอมย้อนกลับสั่งหรือไม่ นี้ส่วนใหญ่มักเกิดขึ้นเมื่อโปรแกรมประยุกต์ออกเป็นยกเลิกหรือคำสั่งทำลาย SQL Transact โดยไม่มีคำสั่งย้อนกลับที่สอดคล้องกัน ยกเลิกธุรกรรมที่เกิด ขึ้น แต่จะไม่ย้อนกลับ ดังนั้น SQL Server ไม่สามารถตัดทอนทุกธุรกรรมที่เกิดขึ้นหลังจากนี้เนื่องจากธุรกรรมการยกเลิกที่ยังคงเปิดอยู่ คุณสามารถใช้การอ้างอิง DBCC OPENTRAN Transact-SQL เพื่อตรวจสอบว่า มีคชันที่ใช้งานอยู่ในฐานข้อมูลในเวลาที่เฉพาะสำหรับข้อมูลเพิ่มเติมเกี่ยวกับสถานการณ์สมมตินี้เฉพาะ คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความในฐานความรู้ของ Microsoft:
295108ธุรกรรมที่ไม่สมบูรณ์อาจเก็บล็อกและการบล็อก case จำนวนขนาดใหญ่
171224การศึกษาวิธีการทำงานของคำสั่ง Transact SQL ทำลาย
นอกจากนี้ ให้ดูหัวข้อ "DBCC OPENTRAN" ใน SQL Server หนังสือออนไลน์

สถานการณ์ที่อาจทำให้ธุรกรรม uncommitted:
  • การออกโปรแกรมประยุกต์ที่สันนิษฐานว่า ข้อผิดพลาดทั้งหมดทำให้ rollbacks
  • การออกโปรแกรมประยุกต์ที่ไม่เสร็จสมบูรณ์นำเข้าบัญชีลักษณะการทำงานของ SQL Server เมื่อคุณย้อนกลับธุรกรรมที่มีชื่อหรือแบบซ้อนพิเศษธุรกรรมมีชื่อ ถ้าคุณพยายามที่จะย้อนกลับธุรกรรมชื่อ inner คุณได้รับข้อความแสดงข้อความแสดงข้อผิดพลาดต่อไปนี้:
    เซิร์ฟเวอร์: ข่าวสารเกี่ยวกับ 6401 ระดับ 16 สถานะ 1 บรรทัด 13 ไม่สามารถย้อนกลับ InnerTran ไม่มีธุรกรรมหรือ savepoint ของชื่อที่พบ
    หลังจากที่ SQL Server สร้างข้อความข้อผิดพลาด มันยังคงมีอยู่ไปยังคำสั่งถัดไป นี่คือ โดยการออกแบบ สำหรับข้อมูลเพิ่มเติม ให้ดูที่หัวข้อ "ธุรกรรมซ้อน" หรือ "ภายใน SQL Server" ใน SQL Server หนังสือออนไลน์

    Microsoft แนะนำต่อไปนี้เมื่อคุณออกแบบโปรแกรมประยุกต์ของคุณ:
    • หนึ่งหน่วยในธุรกรรมที่เปิดเท่านั้น (พิจารณาความเป็นไปได้ว่า กระบวนการอื่นอาจเรียก yours)
    • ตรวจสอบ @@ TRANCOUNT ก่อนที่คุณออกยืนยันการ ย้อนกลับการ การส่งคืน สินค้า หรือเป็นคำสั่งที่คล้ายกัน หรืองบ
    • รหัสของคุณ ด้วย assumption ว่า TRANCOUNT @@ อื่นอาจ "nest" yours และวางแผนสำหรับ outer @@ TRANCOUNT การโรกลับเมื่อเกิดข้อผิดพลาดของเขียน
    • ตรวจทาน savepoint และทำเครื่องหมายตัวเลือกสำหรับธุรกรรม (เหล่านี้ไม่ปลดล็อก)
    • ทำการทดสอบเสร็จสมบูรณ์
  • โปรแกรมประยุกต์ซึ่งช่วยให้การโต้ตอบผู้ใช้ภายในธุรกรรม ซึ่งทำให้ธุรกรรมที่เปิดทิ้งไว้เป็นเวลานาน สาเหตุการบล็อคและธุรกรรมที่บันทึกเรขาคณิตเนื่องจากไม่สามารถถูกตัดทอนธุรกรรมที่เปิด และมีเพิ่มธุรกรรมใหม่ลงในบันทึกหลังจากธุรกรรมที่เปิด
  • An application that does not check @@TRANCOUNT to verify that there are no open transactions.
  • Network or other errors that close the client application connection to SQL Server without informing it.
  • Connection pooling. After worker threads are created, SQL Server reuses them if they are not servicing a connection. If a user connection starts a transaction and disconnects before committing or rolling back the transaction, and a connection thereafter reuses the same thread, the previous transaction still stays open. This situation results in locks that stay open from the previous transaction and prevents the truncation of the committed transactions in the log, which results in large log file sizes.For more information about connection pooling, click the following article number to view the article in the Microsoft Knowledge Base:
    164221How to enable connection pooling in an ODBC application

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. For additional information about what to do when you receive this type of error message is provided in the "More Information" section in this article. Additionally, it takes a lot of time and SQL Server overhead to roll back large transactions.

Operations: DBCC DBREINDEX and CREATE INDEX

Because of the changes in the recovery model in SQL Server 2000, when you use the Full recovery mode and you run DBCC DBREINDEX, the transaction log may expand significantly more compared to that of SQL Server 7.0 in an equivalent recovery mode with the use of SELECT INTO or BULK COPY and with "Trunc. Log on chkpt." off.

Although the size of the transaction log after the DBREINDEX operation might be an issue, this approach provides better log restore performance.

While restoring from transaction log backups

This is described in the following Microsoft Knowledge Base article:
232196Log space used appears to grow after restoring from backup

If you set SQL Server 2000 to use Bulk-Logged mode and you issue a BULK COPY or SELECT INTO statement, every changed extent is marked and then backed up when you back up the transaction log. Although this permits you to back up transaction logs and recover from failures even after you perform bulk operations, this adds to the size of the transaction logs. SQL Server 7.0 does not include this feature. SQL Server 7.0 only records which extents are changed, but it does not record the actual extents. Therefore, the logging takes up significantly more space in SQL Server 2000 than in SQL Server 7.0 in Bulk-Log mode but not as much as it does in Full mode.

Client applications do not process all results

ถ้าคุณออกแบบสอบถามไปยัง SQL Server และคุณไม่จัดการผลลัพธ์ในทันที คุณอาจจะเก็บล็อก และลดการเกิดพร้อมกันบนเซิร์ฟเวอร์ของคุณ

ตัวอย่างเช่น suppose คุณออกแบบสอบถาม ที่ต้องแถวจากเพจทั้งสองการเติมข้อมูลผลลัพธ์ของการตั้งค่า sql Server แยกวิเคราะห์ compiles และรันการสอบถาม ซึ่งหมายความ ว่า การล็อกที่ใช้ร่วมกันจะวางบนเพจทั้งสองที่ประกอบด้วยแถวที่คุณต้องมีการตอบสนองการสอบถามของคุณ นอกจากนี้ สมมติว่า แถวทั้งหมดไม่พอดีกับแพคเก็ต SQL Server TDS หนึ่ง (วิธีการที่เซิร์ฟเวอร์สื่อสารกับไคลเอนต์) แพคเก็ต TDS จะกรอกข้อมูล และส่งไปยังไคลเอนต์ ถ้าแถวทั้งหมดจากหน้าแรกที่พอดีกับแพคเก็ต TDS, SQL Server ออกล็อกที่ใช้ร่วมกันบนหน้านั้น แต่ออกจากการล็อกที่ใช้ร่วมกันบนสองหน้า sql Server รอสำหรับไคลเอ็นต์ร้องขอข้อมูลเพิ่มเติม (คุณสามารถทำได้ โดยใช้ DBNEXTROW/DBRESULTS, SQLNextRow/SQLResults หรือ FetchLast/FetchFirst อย่าง) แล้ว

ซึ่งหมายความ ว่า ล็อกที่ใช้ร่วมกันถูกเก็บไว้จนกว่าไคลเอ็นต์เหลือของข้อมูลที่ร้องขอ กระบวนการอื่นที่ร้องขอข้อมูลจากสองหน้าอาจจะถูกบล็อก

queries หมดเวลาก่อนที่ล็อกของธุรกรรมการขยายที่เสร็จสมบูรณ์ และคุณได้รับข้อความแสดงข้อผิดพลาดของ 'บันทึกเต็มรูปแบบ' เท็จ

ในสถานการณ์เช่นนี้ ถึงแม้ว่ามีพื้นที่ว่างดิสก์เพียงพอ คุณยังคงได้รับ "ออกจากพื้นที่" ข้อผิดพลาด

สถานการณ์นี้แตกต่างกันไปสำหรับ SQL Server 7.0 และ SQL Server 2000

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. SQL Server 7.0 returns error 9002 in this situation. This issue does not apply to SQL Server 2000.

In SQL Server 2000, if you have theauto-shrinkoption turned on for a database, there is an extremely small time during which a transaction log tries to automatically expand, but it cannot because theauto-shrinkfunction is running simultaneously. This may also cause false instances of error 9002.

Typically, the automatic expansion of transaction log files occurs quickly. However, in the following situations, it may take longer than usual:
  • Growth increments are too small.
  • Server is slow for various reasons.
  • Disk drives are not fast enough.

Unreplicated transactions

The transaction log size of thepublisherdatabase can expand if you are using replication. Transactions that affect the objects that are replicated are marked as "For Replication." These transactions, such as uncommitted transactions, are not deleted after checkpoint or after you back up the transaction log 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 thepublisherdatabase, the size of the transaction log may continue to expand as the number of non-replicated transactions increases. You can use the DBCC OPENTRAN Transact-SQL reference to identify the oldest non-replicated transaction.

For more information about troubleshooting unreplicated transactions, see the "sp_replcounters" and "sp_repldone" topics in SQL Server Books Online.

หากต้องการทราบข้อมูลเพิ่มเติม โปรดคลิกที่หมายเลขบทความต่อไปนี้เพื่อดูบทความใน Microsoft Knowledge Base::
306769FIX: Transaction log of snapshot published database cannot be truncated
240039FIX: DBCC OPENTRAN does not report replication information
198514FIX: Restore to new server causes transactions to remain in log

ข้อมูลเพิ่มเติม

The transaction log for any database is managed as a set of virtual log files (VLFs) whose size SQL Server determines internally based on the total size of the log file and the growth increment in use when the log expands. A log always expands in units of whole VLFs and it can only compress to a VLF boundary. A VLF can exist in one of three states: ACTIVE, RECOVERABLE, and REUSABLE.
  • ACTIVE: The active portion of the log begins at the minimum log sequence number (LSN) that represents an active (uncommitted) transaction. The active portion of the log ends at the last-written LSN. Any VLFs that contain any part of the active log are considered active VLFs. (Unused space in the physical log is not part of any VLF.)
  • RECOVERABLE: The portion of the log that precedes the oldest active transaction is only necessary to maintain a sequence of log backups for recovery purposes.
  • REUSABLE: If you are not maintaining transaction log backups, or if you already backed up the log, SQL Server reuses VLFs before the oldest active transaction.
When SQL Server reaches the end of the physical log file, it starts reusing that space in the physical file by issuing a CIRCLING BACK operation to the beginning of the files. In effect, SQL Server recycles the space in the log file that is no longer necessary for recovery or backup purposes. If a log backup sequence is being maintained, the part of the log before the minimum LSN cannot be overwritten until you back up or truncate those log records. After you perform the log backup, SQL Server can circle back to the beginning of the file. After SQL Server circles back to start writing log records earlier in the log file, the reusable portion of the log is then between the end of the logical log and active portion of the log.

For additional information, see the "Transaction Log Physical Architecture" topic in SQL Server Books Online. Additionally, you can see an excellent diagram and discussion of this on page 190 of "Inside SQL Server 7.0" (Soukup, Ron. Inside Microsoft SQL Server 7.0, Microsoft Press, 1999), and also in pages 182 through 186 of "Inside SQL Server 2000" (Delaney, Kalen. Inside Microsoft SQL Server 2000, Microsoft Press, 2000).SQL Server 7.0 and SQL Server 2000 databases have the options to autogrow and autoshrink. You can use these options to help you to compress or expand your transaction log.

For more information about how these options can affect your server, click the following article number to view the article in the Microsoft Knowledge Base:
315512Considerations for Autogrow and Autoshrink configuration in SQL Server
There is a difference between the truncation versus the compression of the transaction log file. When SQL Server truncates a transaction log file, this means that the contents of that file (for example, the committed transactions) are deleted. However, when you are viewing the size of the file from a disk space perspective (for example, in Windows Explorer or by using thedircommand) the size remains unchanged. However, the space inside the .ldf file can now be reused by new transactions. Only when SQL Server shrinks the size of the transaction log file, do you actually see a change in the physical size of the log file.

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการล็อกธุรกรรมการลดขนาด คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความในฐานความรู้ของ Microsoft:
256650วิธีการลดขนาดล็อกธุรกรรมของ SQL Server 7.0
272318ลดขนาดแฟ้มบันทึกของธุรกรรมใน SQL Server 2000 ด้วย DBCC SHRINKFILE
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้งานในล็อกธุรกรรม SQL Server 6.5 คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความในฐานความรู้ของ Microsoft:
110139สาเหตุของการกรอกข้อมูลอัพล็อกธุรกรรมของ SQL

วิธีการค้นหาแบบสอบถามที่ใช้พื้นที่การบันทึกใน SQL Server 2005 จำนวนมาก

ใน SQL Server 2005 คุณสามารถใช้มุมมองการจัดการไดนามิก sys.dm_tran_database_transactions (DMV) เพื่อสอบถามซึ่งใช้เนื้อที่จำนวนมากพื้นที่การบันทึกการค้นหา คอลัมน์ต่อไปนี้ในการ sys.dm_tran_database_transactions DMV จะเป็นประโยชน์:
  • database_transaction_log_bytes_used
  • database_transaction_log_bytes_used_system
  • database_transaction_log_bytes_reserved
  • database_transaction_log_bytes_reserved_system
  • database_transaction_log_record_count
คุณสามารถสอบถามคอลัมน์ sql_handle ของ sys.dm_exec_requests DMV เพื่อให้ได้รับข้อความคำสั่งที่แท้จริงที่จะจำนวนมากพื้นที่การบันทึก คุณสามารถทำได้ โดยเข้าร่วม sys.dm_tran_database_transactions DMV และ sys.dm_tran_session_transactions DMV บนคอลัมน์ transaction_id และจากนั้น ทำการเพิ่มการเข้าร่วมเพิ่มเติมเกี่ยวกับ sys.dm_exec_requests บนคอลัมน์ session_id

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ sys.dm_tran_database_transactions DMV แวะไปที่เว็บไซต์ของ Microsoft สำหรับนักพัฒนาเครือข่าย (MSDN) ต่อไปนี้:
http://msdn2.microsoft.com/en-us/library/ms186957.aspx
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ sys.dm_tran_session_transactions DMV ไปที่ MSDN เว็บไซต์ต่อไปนี้:
http://msdn2.microsoft.com/en-us/library/ms188739.aspx
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ sys.dm_exec_requests DMV ไปที่ MSDN เว็บไซต์ต่อไปนี้:
http://msdn2.microsoft.com/en-us/library/ms177648.aspx

คุณสมบัติ

หมายเลขบทความ (Article ID): 317375 - รีวิวครั้งสุดท้าย: 17 กันยายน 2554 - Revision: 4.0
ใช้กับ
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Workgroup
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
Keywords: 
kbinfo kbmt KB317375 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:317375

ให้ข้อเสนอแนะ

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com