การทำบันทึกของ sql Server 7.0, SQL Server 2000 และ SQL Server 2005 และ algorithms การเก็บข้อมูลขยายความน่าเชื่อถือของข้อมูล

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

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

สรุป

sql Server 7.0, SQL Server 2000 และ SQL Server 2005 restructure และ redesign algorithms เข้าสู่ระบบและข้อมูลจากรุ่นก่อนหน้านี้ของ Microsoft SQL Server เพื่อปรับปรุงความน่าเชื่อถือของข้อมูลและความถูกต้อง

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับแนวคิดพื้นฐานของเอ็นจิน SQL Server 7.0 และ SQL Server 2000 ดู " ARIES (อัลกอริทึมสำหรับการกู้คืนและหมาย Exploiting แยกต่างหาก): วิธีการกู้คืนทรานแซคชัน Supporting ความละเอียด-Granularity Locking และ Rollbacks บางส่วนใช้บันทึกข้อมูลการเขียนล่วงหน้า", ของธุรกรรม ACM บนระบบฐานข้อมูล เอกสารนี้ถูกเขียน โดย Chunder Mohan

เอกสารนี้เน้นเทคนิค SQL Server 7.0, SQL Server 2000 และ SQL Server 2005 เพื่อขยายความน่าเชื่อถือของข้อมูลและความถูกต้องตามที่เกี่ยวข้องกับความล้มเหลว

ขอแนะนำให้ คุณอ่านบทความต่อไปนี้ใน Microsoft Knowledge Base สำหรับ clarification เพิ่มเติมในแคช และสลับโหมดการสนทนาที่มีความล้มเหลว:
86903คำอธิบายของแคชตัวควบคุมดิสก์ใน SQL Server
46091การใช้ฮาร์ดดิสก์ตัวควบคุมการแคกับ SQL Server
234656ใช้ดิสก์ไดรฟ์แคกับ SQL Server

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

ก่อนที่จะเริ่มต้นการสนทนาที่ลึก บางส่วนของเงื่อนไขการใช้ตลอดบทความนี้ถูกกำหนดไว้ในส่วนต่อไปนี้
ยุบตารางนี้ขยายตารางนี้
ระยะเวลาข้อกำหนด
สำรองแบตเตอรีแบตเตอรีที่แยกต่างหาก และแปลสำรองฟังก์ชันโดยตรงอยู่ และควบคุม โดยกลไกการแคชเพื่อป้องกันข้อมูลสูญหาย
หมายเหตุ:ไม่มีไฟฟ้า (UPS) UPS แบบไม่รับประกันใด ๆ กิจกรรมการเขียน และสามารถถูกตัดการเชื่อมต่อจากอุปกรณ์แคช
แคชกลไกการจัดเก็บสื่อกลางที่ใช้ในการปรับการตั้งค่าการดำเนินการ I/O กายภาพ และการปรับปรุงประสิทธิภาพ
หน้าสกปรกเพจที่ประกอบด้วยการปรับเปลี่ยนข้อมูลที่ต้องถูก flushed เพื่อเก็บข้อมูลที่เสถียร สำหรับข้อมูลเพิ่มเติมที่เกี่ยวข้องกับเพสกปรกบัฟเฟอร์ ให้ดูที่เอกสารประกอบของ SQL Server หนังสือออนไลน์
ความล้มเหลวสิ่งที่อาจทำให้ดับไม่คาดคิดของกระบวนการของ sql server ตัวอย่างรวมถึง: พลังงานดับ การรีเซ็ตคอมพิวเตอร์ ข้อผิดพลาดของหน่วยความจำ ปัญหาฮาร์ดแวร์ กเตอร์ ขาดหายไปของไดรฟ์ ความล้มเหลวของระบบปฏิบัติการ และอื่น ๆ forth อื่น ๆ
ล้างบังคับให้มีบัฟเฟอร์การแคชเพื่อ stable การเก็บข้อมูล
latchวัตถุการซิงโครไนส์ที่ใช้ในการปกป้องความสอดคล้องกันมีอยู่จริงของทรัพยากร
เก็บ nonvolatileสื่อใด ๆ ที่ยังคงพร้อมใช้งานข้ามความล้มเหลวของระบบ
ยึดหมุดไว้หน้าหน้าที่ยังคงในข้อมูลการแคช และไม่สามารถถูก flushed เพื่อเก็บข้อมูลที่เสถียรจนกว่าจะมีการรักษาความปลอดภัยในตำแหน่งที่เก็บที่เสถียรระเบียนแฟ้มบันทึกที่เกี่ยวข้องทั้งหมด
เก็บเสถียรเหมือนเก็บ nonvolatile
เก็บ volatileสื่อที่จะไม่ยังคงยังข้ามความล้มเหลว
sql Server 2005, SQL Server 2000, SQL Server 7.0, SQL Server รุ่นก่อนหน้า และผลิตภัณฑ์ฐานข้อมูล mainstream จำนวนมากในตลาดใช้โพรโทคอลเขียนล่วงหน้าล็อก (WAL) ในวันนี้

โพรโทคอลเขียนล่วงหน้าล็อก (WAL)

โพรโทคอลเงื่อนไขเป็นวิธีที่ excellent เพื่ออธิบาย WAL It is a specific and defined set of implementation steps necessary to ensure data is stored and exchanged properly and can be recovered to a known state in the event of a failure. Just as a network contains a defined protocol to exchange data in a consistent and protected manner, so too does the WAL describe the protocol to protect data.

The ARIES document defines the WAL as:
The WAL protocol asserts that the log records representing changes to some data must already be in stable storage before the changed data is allowed to replace the previous version of the data in nonvolatile storage. That is, the system is not allowed to write an updated page to the nonvolatile storage version of the page until at least the undo portions of the log records which describe the updates to the page have been written to stable storage.
For more information about Write-Ahead Logging, see the SQL Server Books Online documentation.

SQL Server and the WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0, and earlier SQL Server releases use the WAL protocol. To ensure proper committal of a transaction, all log records associated with the transaction must be secured in stable storage.

To clarify this, consider the following specific example (for this example assume that there is no index and the page affected is page 150).
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
Now break the activity down into simplistic logging steps:
ยุบตารางนี้ขยายตารางนี้
StatementActions performed
begin ธุรกรรมWritten to the log cache area but there is no need to flush to stable storage because the SQL Server has not made any physical changes.
INSERT INTO tblTest1. Data page 150 is retrieved into SQL Server data cache, if not already available.

2. The page islatched,pinnedและmarked dirty, and appropriate locks are obtained.

3. An Insert Log record is built and added to the log cache.

4. A new row is added to the data page.

5. The latch is released.

6. The log records associated with the transaction or page does not need to be flushed at this point because all changes remain in volatile storage.
COMMIT TRANSACTION1. A Commit Log record is formed and the log records associated with the transaction must be written to stable storage. The transaction is not considered committed until the log records are correctly assigned to stable storage.

2. Data page 150 remains in SQL Server data cache and is not immediately flushed to stable storage. When the log records are properly secured recovery can redo the operation if necessary.

3. Transactional locks are released.
Do not be confused with locking and logging. Although important, locking and logging are separate issues when dealing with the WAL. In the example above, SQL Server 7.0, SQL Server 2000, and SQL Server 2005 generally hold the latch on page 150 for the time necessary to perform the physical insert changes on the page, not the entire time of the transaction. The appropriate lock type is established to protect the row, range, page, or table as necessary. Refer to the SQL Server Books Online locking sections for more details on lock types.

Looking at the example in more detail, you might ask what happens when the LazyWriter or CheckPoint processes execute. SQL Server 7.0, SQL Server 2000, and SQL Server 2005 issue all appropriate flushes to stable storage for transactional log records associated with the dirty and pinned page. This ensures the WAL protocol a data page can never be written to stable storage until the associated transactional log records have been flushed.

SQL Server and stable storage

SQL Server 7.0, SQL Server 2000, and SQL Server 2005 enhance log and data page operations by including the knowledge of disk sector sizes (commonly 512 bytes).

To maintain the ACID properties of a transaction, the SQL Server must account for failure points. During a failure many disk drive specifications only guarantee a limited amount of sector write operations. Most specifications guarantee completion of a single sector write when a failure occurs.

SQL Server 7.0, SQL Server 2000, and SQL Server 2005 use 8-KB data pages and the log (if flushed) on multiples of the sector size. (Most disk drives use 512 bytes as the default sector size.) In the case of a failure, SQL Server can account for write operations larger than a sector by employing log parity and torn write techniques.

ตรวจหาเพ torn

ส่วนต่อไปนี้มาจากการ SQL Server 7.0 หนังสือออนไลน์อธิบายตรวจหาเพ torn:
ตัวเลือกนี้ช่วยให้ SQL Server เพื่อตรวจหาการดำเนินการ I/O เอาต์มีสาเหตุจากความล้มเหลวในการใช้พลังงานหรือขาดหายไปของระบบอื่น เมื่อจริง มันทำให้บิตที่จะถูก flipped สำหรับแต่ละเซกเตอร์ 512 ไบต์ในเพจที่ฐานข้อมูล (KB) ของกิโลไบต์ 8 ทุกครั้งที่เพจที่ถูกเขียนลงดิสก์ ถ้ามีสักอยู่ในสถานะที่ไม่ถูกต้องเมื่อหน้าเป็นวันหลัง อ่าน โดย SQL Server จากนั้นเพจนี้ถูกเขียนไม่ถูกต้อง ตรวจพบหน้ากระดาษแบบ torn เพ torn มักจะถูกตรวจพบระหว่างการกู้คืนเนื่องจากเพใด ๆ ที่เขียนไม่ถูกต้องมีแนวโน้มที่จะสามารถอ่านได้ โดยการกู้คืน

แม้ว่าเพฐานข้อมูล SQL Server จะกิโลไบต์ 8 ดิสก์ทำการดำเนินการ I/O ที่ใช้กับเซกเตอร์ 512 ไบต์ ดังนั้น ภาค 16 ถูกเขียนขึ้นสำหรับแต่ละหน้าของฐานข้อมูล หน้ากระดาษแบบ torn อาจเกิดขึ้นได้หากระบบล้มเหลว (ตัวอย่างเช่น เนื่องจากถึงความล้มเหลวในการใช้พลังงาน) ระหว่างเวลาระบบปฏิบัติการเขียนเซกเตอร์ 512 ไบต์แรกไปยังดิสก์และความสมบูรณ์ของการดำเนินการ I/O กิโลไบต์ที่ 8 ถ้ามีการให้เสร็จสมบูรณ์แล้วเขียนเซกเตอร์แรกของเพจในฐานข้อมูลก่อนที่จะความล้มเหลว หน้าฐานข้อมูลบนดิสก์จะปรากฏตามที่ได้รับการปรับปรุง ถึงแม้ว่าอาจไม่ได้สำเร็จ

การใช้ดิสก์ที่สำรองแบตเตอรีคอนโทรลเลอร์ caches สามารถมั่นใจว่า ข้อมูลเสร็จสมบูรณ์ได้ถูกเขียนลงดิสก์ หรือไม่ได้เขียนทั้งหมดได้ ในกรณีนี้ ทำตรวจไม่ชุด torn หาเพไปจริง สำหรับนั้นไม่ถูกต้อง
หมายเหตุ:ตรวจหาเพ torn ไม่ได้เปิดใช้งาน โดยค่าเริ่มต้นใน SQL Server 7.0 ดูsp_dboptionสำหรับวิธีการเปิดใช้งานการตรวจสอบในระบบของคุณ

พาริตีล็อก

การตรวจสอบพาริตีล็อกจะคล้ายกันมากที่จะตรวจหาเพ torn แต่ละเซกเตอร์ 512 ไบต์ประกอบด้วยพาริตีบิต เสมอบิตพาริตีเหล่านี้จะเขียนกับระเบียนแฟ้มบันทึก และประเมินเมื่อทำการบันทึกแฟ้มบันทึกถูกดึงมา ด้วยการบังคับให้ล็อกเขียนบนเป็น 512 ไบต์ขอบ SQL Server 7.0, SQL Server 2000 และ SQL Server 2005 สามารถมั่นใจว่า committal การดำเนินงานเสร็จสมบูรณ์เขียนไปยังเซกเตอร์ของดิสก์ทางกายภาพ

การเปลี่ยนแปลงให้ความสอดคล้องของข้อมูลที่เพิ่มขึ้น แม้บน SQL Server รุ่นก่อนหน้านี้

SQL Server รุ่นก่อนหน้า 7.0

รุ่นของ sql server 7.0 ที่ไม่ใช่จึงไม่ให้พาริตีล็อกหรือสิ่งอำนวยความสะดวกการตรวจหา torn บิต ใน fact รุ่นดังกล่าวสามารถเขียนบันทึกหน้าเดียวกันหลายครั้งจนกว่าการบันทึกล็อกกรอกข้อมูลเพกิโลไบต์ 2 ล็อก ซึ่งสามารถแสดงถึงธุรกรรมที่มีกำหนดเรียบร้อยแล้ว ถ้าหน้าการบันทึกจะถูก rewritten ในระหว่างการเกิดความล้มเหลว มีเซกเตอร์ ด้วยธุรกรรมที่มีการยอมรับที่อาจไม่ได้รับ rewritten อย่างถูกต้อง

impacts ประสิทธิภาพการทำงาน

SQL Server รุ่นทั้งหมดเปิดแฟ้มบันทึกและข้อมูลที่ใช้ Win32CreateFileฟังก์ชัน กระบวนการdwFlagsAndAttributesรวมสมาชิกfile_flag_write_throughตัวเลือกเมื่อถูกเปิด โดย SQL Server
file_flag_write_through
แนะนำให้ระบบการเขียนผ่านแคใด ๆ ระหว่างกลาง และไปยังดิสก์โดยตรง ระบบยังคงสามารถแคชการดำเนินการเขียน แต่ไม่ lazily ล้างแฟ้มเหล่านั้น

ตัวเลือก FILE_FLAG_WRITE_THROUGH แน่ใจที่เมื่อการเขียนการดำเนินการกลับสำเร็จกรอกข้อมูลได้อย่างถูกต้องได้ถูกเก็บไว้ในที่เก็บที่เสถียร ซึ่งจัดตำแหน่งให้กับโพรโทคอล WAL ตรวจดูข้อมูล
หลายดิสก์ไดรฟ์ (SCSI และ IDE) ประกอบด้วย onboard caches ของ 512 KB, 1 เมกะ ไบต์ หรือใหญ่กว่า อย่างไรก็ตาม caches ไดรฟ์มักจะอาศัย capacitor มีและไม่สำรองแบตเตอรีโซลูชัน กลไกการแคเหล่านี้ไม่สามารถรับประกันรอบการเขียนข้อมูลผ่านพลังงาน หรือเลือกความล้มเหลวที่คล้ายกัน พวกเขารับประกันความสมบูรณ์ของการดำเนินการเขียนเซกเตอร์เท่านั้น นี่คือโดยเฉพาะอย่างยิ่งอยู่สาเหตุ torn เขียนและบันทึกการตรวจสอบพาริตีได้ภายใน SQL Server 7.0, SQL Server 2000 และ SQL Server 2005 ในขณะที่ไดรฟ์ต่อไปเพื่อขยายขนาด caches ที่จะมีขนาดใหญ่กว่า และพวกเขาสามารถแสดงยอดเงินที่มีขนาดใหญ่ของข้อมูลในระหว่างการเกิดความล้มเหลว

ผู้ผลิตฮาร์ดแวร์จำนวนมากมีวิธีแก้ไขปัญหาของตัวควบคุมดิสก์สำรองแบตเตอรี caches ตัวควบคุมเหล่านี้สามารถเก็บรักษาข้อมูลในแคชนานหลายวัน และแม้แต่อนุญาตให้ฮาร์ดแวร์แคเพื่อที่ถูกวางลงในคอมพิวเตอร์เครื่องที่สอง เมื่อมีการใช้พลังงานได้อย่างถูกต้อง จะคืนค่าข้อมูล unwritten ได้อย่างสมบูรณ์ flushed ก่อนที่จะได้รับอนุญาตเข้าถึงข้อมูลเพิ่มเติม จำนวนของแฟ้มเหล่านั้นอนุญาตให้เปอร์เซ็นต์ของการอ่านและแคชการเขียนเพื่อที่ถูกกำหนดสำหรับประสิทธิภาพที่ดีที่สุด บางอย่างประกอบด้วยพื้นที่จัดเก็บหน่วยความจำขนาดใหญ่ ใน fact สำหรับเซ็กเมนต์เจาะจงมากของตลาด ผู้ผลิตฮาร์ดแวร์บางอย่างให้ high-end สำรองแบตเตอรีดิสก์ระบบตัวควบคุม มี 6 GB แคชของการแค These can significantly improve database performance.

Advanced caching implementations will handle theFILE_FLAG_WRITE_THROUGHrequest by not disabling the controller cache because they can provide true rewrite capabilities in the event of a system reset, power failure, or other failure point.

I/O transfers without the use of a cache can be significantly longer due to the mechanical time needed to move the drive heads, spin rates, and other limiting factors.

Sector ordering

A common technique used to increase I/O performance is sector ordering. To avoid mechanical head movement the read/write requests are sorted, allowing a more consistent motion of the head to retrieve or store data.

The cache can hold multiple log and data write requests at the same time. The WAL protocol and the SQL Server implementation of the WAL protocol require flushing of the log writes to stable storage before the page write can be issued. However, use of the cache might return success from a log write request without the data being written to the actual drive (that is, written to stable storage). This may lead to SQL Server issuing the data page write request.

With the write cache involvement, the data is still considered to be in volatile storage. However, from the Win32 APIWriteFilecall, exactly how SQL Server sees the activity, a successful return code was obtained. SQL Server or any process using theWriteFileAPI call can only deduce the data has correctly obtained stable storage.

For discussion purposes, assume that all sectors of the data page are sorted to write before the sectors of the matching log records. This immediately violates the WAL protocol. The cache is writing a data page before the log records. Unless the cache is fully battery-backed, a failure can cause catastrophic results.

When evaluating the optimal performance factors for a database server, there are many factors to consider. The foremost of these considerations is"Does my system allow valid FILE_FLAG_WRITE_THROUGH capabilities?"

หมายเหตุ:Any cache you are usingจำเป็นfully support a battery-backed solution. All other caching mechanisms are suspect to data corruption and data loss. SQL Server makes every effort to ensure the WAL by enabling FILE_FLAG_WRITE_THROUGH.

Testing has shown that many disk drive configurations may contain write caching without proper battery backup. SCSI, IDE, and EIDE drives take full advantage of write caches.

In many configurations, the only way to properly disable the write caching of an IDE or EIDE drive is with a specific manufacturer utility or by using jumpers located on the drive itself. To ensure that the write cache is disabled for the drive itself, contact the drive manufacturer.

SCSI drives also have write caches but these caches can commonly be disabled by the operating system. If there is any question, contact the drive manufacturer for appropriate utilities.

เขียนแค Stacking

เขียนแค Stacking จะเหมือนกับการจัดลำดับเซกเตอร์ คำจำกัดความต่อไปนี้ถูกนำมาโดยตรงจากการนำ IDE ไดรฟ์เว็บไซต์ผู้ผลิต:
โดยปกติ โหมดนี้ถูกใช้งานอยู่ เขียนแคชโหมดยอมรับในการโฮสต์การเขียนข้อมูลลงในบัฟเฟอร์จนกว่าบัฟเฟอร์ไม่เต็ม หรือโอนย้ายการโฮสต์เสร็จสมบูรณ์แล้ว

งานการเขียนดิสก์เริ่มต้นในการเก็บข้อมูลโฮสต์ดิสก์ Host write commands continue to be accepted and data transferred to the buffer until either the write command stack is full or the data buffer is full. The drive may reorder write commands to optimize drive throughput.

Automatic Write Reallocation (AWR)

Other common technique used to protect data is to detect bad sectors during data manipulation. The following explanation comes from the same leading IDE drive manufacturer Web site:
This feature is part of the write cache and reduces the risk of data loss during deferred write operations. If a disk error occurs during the disk write process, the disk task stops and the suspect sector is reallocated to a pool of alternate sectors located at the end of the drive. Following the reallocation, the disk write task continues until it is complete.
This can be a very powerful feature if battery backup is provided for the cache, allowing proper modification upon restart. It is preferable to detect the disk errors, but the data security of the WAL protocol would again require this to be done real time and not in a deferred manner. Within the WAL parameters, the AWR technique cannot account for a situation where a log write fails due to a sector error but the drive is full. The database engine must immediately know about the failure so the transaction can be properly aborted, the administrator can be alerted, and proper steps taken to secure the data and correct the media failure situation.

Data safety

There are several precautions a database administrator should take to ensure the safety of the data.
  • It is always a good idea to ensure that your backup strategy is sufficient to recover from a catastrophic failure. Offsite storage and other precautions are appropriate.
  • Test the database restore operation in a secondary or test database on a frequent basis.
  • Ensure that any caching devices can handle all failure situations (power outage, bad sectors, bad drives, system outage, lockups, power spike, and so forth).
  • Ensure that your caching device:
    • Has integrated battery backup.
    • Can reissue writes on power up.
    • Can be fully disabled if necessary.
    • Handles bad sector re-mapping realtime.
  • Enable torn page detection; it has little performance impact.
  • Configure RAID drives allowing for a hot swap of a bad disk drive, if possible.
  • Use newer caching controllers that allow addition of more disk space without restarting the OS. This can be an ideal solution.

Testing drives

To fully secure your data, you should ensure that all data caching is properly handled. In many situations, this means you must disable the write caching of the disk drive.

หมายเหตุ:Ensure that an alternate caching mechanism can properly handle multiple types of failure.

Microsoft has performed testing on several SCSI and IDE drives using theSQLIOStressutility. This utility simulates heavy asynchronous read/write activity to a simulated data device and log device. Test performance statistics show the average write operations per second between 50 and 70 for a drive with disabled write caching and an RPM range between 5,200 and 7,200.

For more information and details about theSQLIOStressutility, see the following article in the Microsoft Knowledge Base:
231619How to use the SQLIOStress utility to stress a disk subsystem such as SQL Server
Many PC manufacturers (for example, Compaq, Dell, Gateway, HP, and so on) order the drives with the write cache disabled. However, testing shows that this may not always be the case so always test completely.

Data devices

In all but non-logged situations, SQL Server will require only the log records to be flushed. When doing non-logged operations, the data pages must also be flushed to stable storage; there are no individual log records to regenerate the actions in the case of a failure.

The data pages can remain in cache until the LazyWriter or CheckPoint process flushes them to stable storage. Using the WAL protocol to ensure that the log records are properly stored ensures that recovery can recover a data page to a known state.

This does not mean that it is advisable to place data files on a cached drive. When the SQL Server flushes the data page(s) to stable storage, the log records can be truncated from the transaction log. If the data pages are stored on volatile cache, it is possible to truncate log records that would be used to recover a page in the event of a failure. Ensure that both your data and log devices accommodate stable storage properly.

Increasing performance

The initial question that arises is: "I have an IDE drive that was caching but when I disabled it, my performance became significantly less than expected -- why?"

หลายไดรฟ์ IDE ที่ทดสอบ โดย Microsoft ทำงานที่มีอัตรา RPM 5,200 และ SCSI ในไดรฟ์ที่มี RPM ของ 7,200 เมื่อคุณปิดการใช้งานการเขียน แคของไดรฟ์ IDE ประสิทธิภาพกลจะสามารถ ตัวคูณ

ไม่มีพื้นที่ที่ชัดเจนมากเพื่อเน้นความแตกต่างของประสิทธิภาพการทำงาน: "รายอัตราธุรกรรม"

ไม่มีธุรกรรมออนไลน์ที่หลายระบบ (OLTP) ที่ธุรกรรมสูงอัตราที่จำเป็นต้องมีการประมวลผล สำหรับระบบเหล่านี้ ให้ลองใช้ตัวควบคุมแคที่สามารถอย่างถูกต้องสนับสนุนการแคชการเขียน และใส่เพิ่มประสิทธิภาพการทำงานในขณะที่ตรวจดูความสมบูรณ์ของข้อมูล

เมื่อต้องการเปลี่ยนแปลงประสิทธิภาพการทำงานกับ SQL Server บนไดรฟ์ที่แคที่พบมาก อัตราธุรกรรมถูกเพิ่มโดยใช้ธุรกรรมที่ขนาดเล็ก

การทดสอบแสดงว่า กิจกรรมการเขียนที่สูงของบัฟเฟอร์มีขนาดเล็ก กว่า 512 KB หรือ เหนือ 2 MB อาจทำให้ประสิทธิภาพการทำงานช้าลง
ให้พิจารณาตัวอย่างต่อไปนี้:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
   INSERT INTO tblTest VALUES ('Test')
				
ต่อไปนี้คือ ผลลัพธ์การทดสอบตัวอย่างสำหรับ SQL Server ที่ใช้งาน:
SCSI(7200 RPM) 84 วินาที
SCSI(7200 RPM) 15 วินาที (ตัวควบคุม Caching)

IDE(5200 RPM) 14 วินาที (แคไดรฟ์ที่เปิดใช้งาน)
IDE(5200 RPM) 160 วินาที
ตัดทั้งชุดของการดำเนินงาน INSERT ในทรานแซคชันเดียวทำงานใน 4 วินาทีโดยประมาณในการตั้งค่าคอนฟิกทั้งหมด

สาเหตุเป็นจำนวนที่ใช้ในการล็อก flushes ที่จำเป็น ไม่ มีธุรกรรม INSERT แต่ละธุรกรรมใน และ ของตัวเอง และแต่ละครั้งบันทึกล็อกสำหรับธุรกรรมต้องเป็น flushed แต่ละ flush เป็น 512 ไบต์ในขนาด ซึ่งต้องการการขัดจังหวะโดยไดรฟ์กลที่สำคัญ

เมื่อมีใช้ธุรกรรมเดี่ยว สามารถถูกรวมระเบียนแฟ้มบันทึกสำหรับธุรกรรม และเขียนเดียว ใหญ่ขึ้นสามารถใช้การล้างระเบียนแฟ้มบันทึก gathered ขัดจังหวะโดยกลมากจะลดลง

คำเตือนไม่แนะนำให้ คุณเพิ่มขอบเขตของธุรกรรม ธุรกรรมที่รันเป็นเวลานานสามารถนำไปสู่การมากเกินไป และไม่ต้องการบล็อค ตลอดจนเพิ่ม overhead ใช้เคาน์เตอร์วัดประสิทธิภาพการทำงานของ SQL Server 7.0, SQL Server 2000 และ SQL Server 2005sql Server: ฐานข้อมูลเมื่อต้องการดูตัวนับตามล็อกธุรกรรม โดยเฉพาะอย่างยิ่งล็อกไบต์ Flushed/วินาทีสามารถบ่งชี้ว่า ธุรกรรมขนาดเล็กที่มีเลขนำหน้ากิจกรรมของดิสก์กลสูง

ดูคำสั่งที่เกี่ยวข้องกับบันทึก flush และระบุว่าถ้าจำนวนที่ใช้ในการล็อก flushes สามารถจะลดลง ในตัวอย่างข้างต้น ธุรกรรมเดี่ยวถูกใช้ อย่างไรก็ตาม ในหลายกรณี นี้สามารถนำการล็อคลักษณะการทำงานใน undesired ดูธุรกรรมการออก อาจบางเหมือนล้างกิจกรรมต่อไปนี้เพื่อดำเนินการชุดงานเพื่อลดขนาดแฟ้มบันทึกที่ใช้บ่อย และขนาดเล็ก:
BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
BEGIN
   INSERT INTO tblTest VALUES ('Test')

   if(0 = cast(@@IDENTITY as int) % 10)
   BEGIN
      PRINT 'Commit tran batch'
      COMMIT TRAN
      BEGIN TRAN
   END
END
GO

COMMIT TRAN
GO
				
เซิร์ฟเวอร์ sql 6xไม่อาจดูผลกระทบต่อประสิทธิภาพการทำงานเดียวกันจากการเขียนข้อมูลการล็อกธุรกรรมที่ใช้บ่อย และขนาดเล็ก เซิร์ฟเวอร์ sql 6xrewrites ล็อกกิโลไบต์ 2 หน้าเดียวกันเป็นธุรกรรมถูกกำหนดให้ ซึ่งสามารถลดขนาดของแฟ้มบันทึกมากเมื่อเปรียบเทียบกับ flushes ขอบเขตของเซกเตอร์ 512 ไบต์ใน SQL Server 7.0, SQL Server 2000 และ SQL Server 2005 การลดขนาดของแฟ้มบันทึกโดยตรงความเกี่ยวข้องกับขนาดของไดรฟ์กลกิจกรรม อย่างไรก็ตาม เป็น explained เหนือ 6 ของเซิร์ฟเวอร์ SQLxอัลกอริทึมอาจเปิดเผยธุรกรรมที่กำหนดให้
SQL Server ต้องใช้ระบบเพื่อสนับสนุน ‘ มีการจัดส่งไปยังสื่อที่เสถียร ’ ตาม outlined ภายใต้โปรแกรมตรวจทาน Microsoft SQL Server Always-On เก็บโซลูชันแก้ไข Foสำหรับข้อมูลเพิ่มเติมเกี่ยวกับความต้องการป้อนข้อมูล และผลลัพธ์สำหรับโปรแกรมของฐานข้อมูล SQL Server คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความในฐานความรู้ของ Microsoft:
967576ข้อกำหนดของโปรแกรมอินพุต/เอาท์พุตฐานข้อมูลของเซิร์ฟเวอร์ Microsoft SQL

คุณสมบัติ

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

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

 

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