การทำความเข้าใจเกี่ยวกับ INF: และการแก้ไขปัญหาการบล็อคของ SQL Server

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

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

สรุป

ในบทความนี้ เงื่อนไข "การเชื่อมต่อ" หมายถึงเดียวสู่เซของฐานข้อมูล แต่ละการเชื่อมต่อปรากฏเป็นแบบเซสชัน ID (SPID) SPIDs เหล่านี้แต่ละจะมักเรียกว่ากระบวนการ ถึงแม้ว่าคุณไม่ได้บริบทที่ใช้ในการประมวลผลที่แยกต่างหากในควรที่ปกติ ควร SPID แต่ละประกอบด้วยทรัพยากรของเซิร์ฟเวอร์และโครงสร้างข้อมูลที่จำเป็นสำหรับการบริการร้องขอการเชื่อมต่อแบบเดี่ยวจากไคลเอนต์ที่กำหนด โปรแกรมประยุกต์ไคลเอนต์หนึ่งอาจมีการเชื่อมต่ออย่าง น้อยหนึ่งรายการ จากมุมมองของ SQL Server ไม่มีความแตกต่างระหว่างการเชื่อมต่อหลายจากแอพลิเคชันไคลเอนต์เดียวบนคอมพิวเตอร์ไคลเอนต์เดียวและหลายการเชื่อมต่อจากแอปพลิเคชันไคลเอนต์หลายหรือคอมพิวเตอร์ไคลเอนต์หลายครั้ง การเชื่อมต่อหนึ่งสามารถบล็อกการเชื่อมต่ออื่น คำนึงถึงว่าพวกเขา emanate จากแอพลิเคชันเดียวกันหรือโปรแกรมประยุกต์ที่แยกต่างหากในคอมพิวเตอร์ไคลเอนต์ที่แตกต่างกันสองเครื่อง

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

บล็อกจะมีลักษณะ unavoidable ของใด ๆ เกี่ยวจัดการระบบฐานข้อมูล (RDBMS) โดยขึ้นอยู่กับการล็อกเกิดพร้อมกัน บน SQL Server บล็อกเกิดเมื่อ SPID หนึ่งบรรจุการล็อกทรัพยากรเฉพาะ และ SPID ที่สองพยายามรับชนิดล็อกขัดแย้งในการใช้ทรัพยากรเดียวกัน โดยทั่วไป กรอบเวลาซึ่งจะ SPID แรกล็อกทรัพยากรมีขนาดเล็กมาก เมื่อคุณออกล็อก การเชื่อมต่อที่สองเป็นไพ่อิสระเพื่อขอรับการล็อกของตนเองในทรัพยากร และประมวลผลการดำเนินต่อ นี่คือ ลักษณะการทำงานแบบปกติ และอาจเกิดขึ้นหลายครั้งทั่วทั้งหลักสูตรวันที่มีผลต่อประสิทธิภาพของระบบไม่ noticeable

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

สำหรับแบบสอบถามในการดำเนินการภายในทรานแซคชัน ระยะเวลาที่ล็อกถูกเก็บไว้ได้ระบุตามชนิดของแบบสอบถาม ระดับการแยกธุรกรรม และว่าหรือไม่มีล็อกคำแนะนำจะใช้ในการสอบถาม สำหรับคำอธิบายของล็อก คำแนะนำในการล็อก และระดับการแยกธุรกรรม ดูหัวข้อต่อไปนี้ใน SQL Server หนังสือออนไลน์:
  • การล็อกในโปรแกรมฐานข้อมูล
  • ล็อกกำหนดเองและการกำหนดรุ่นของแถว
  • โหมดการล็อก
  • ความเข้ากันได้ของล็อก
  • แถวที่ขึ้นอยู่กับการกำหนดรุ่นความแยกต่างหากในโปรแกรมฐานข้อมูล
  • การควบคุมการธุรกรรม (โปรแกรมของฐานข้อมูล)
เมื่อล็อก และการบล็อกการเพิ่มไปยังจุดไม่มีผลต่อประสิทธิภาพของระบบ detrimental จะโดยปกติเนื่องจากหนึ่งเนื่องจากสาเหตุต่อไปนี้:
  • SPID มีการล็อกในชุดของทรัพยากรสำหรับรอบระยะเวลาก่อนที่จะนำออกใช้ให้เป็นแบบขยาย การบล็อกชนิดนี้เพื่อแก้ไขตัวเองเมื่อเวลาผ่านไป แต่อาจทำให้เกิดการลดประสิทธิภาพการทำงาน
  • SPID มีการล็อกในชุดของทรัพยากร และไม่เคยออกได้ การบล็อกชนิดนี้ไม่สามารถแก้ไขตัวเอง และป้องกันการเข้าถึงทรัพยากรที่ได้รับผลกระทบ indefinitely
ในการแรกสถานการณ์ข้างต้น ปัญหาการบล็อคแก้ไขตัวเองเมื่อเวลาผ่านไป ตาม SPID ออกในการล็อก อย่างไรก็ตาม สถานการณ์ที่สามารถ fluid มากที่เป็นสาเหตุ SPIDs ที่แตกต่างกันการบล็อคทรัพยากรอื่นเมื่อเวลาผ่านไป การสร้างเป็นเป้าหมายของการเคลื่อนไหว ด้วยเหตุผลนี้ สถานการณ์เหล่านี้จะยากต่อการแก้ไขปัญหาโดยใช้โปรแกรมจัดการไซต์องค์กรเซิร์ฟเวอร์ SQL หรือแต่ละการสอบถาม SQL ผลลัพธ์สถานการณ์ที่สองในสถานะที่สอดคล้องกันที่สามารถทำได้ง่ายขึ้นเพื่อวิเคราะห์

กำลังรวบรวมข้อมูลการบล็อก

เมื่อต้องการ counteract อุปสรรคในการแก้ไขปัญหาการบล็อค ผู้ดูแลฐานข้อมูลสามารถใช้สคริปต์ SQL ที่ constantly ตรวจสอบสถานะของการล็อค และการบล็อกใน SQL Server สคริปต์เหล่านี้สามารถให้ snapshots ของอินสแตนซ์ที่ระบุช่วงเวลา เลขนำหน้าไปรูปภาพโดยรวมของปัญหา คำอธิบายเกี่ยวกับวิธีการตรวจสอบการบล็อก มีสคริปต์ SQL ดูบทความในฐานความรู้ของ Microsoft ต่อไปนี้:
271509วิธีการตรวจสอบการบล็อก ใน SQL Server 2005 และ SQL Server 2000
สคริปต์ในบทความนี้จะทำงานด้านล่าง โดยเป็นไปได้ วิธีการสำหรับการรับข้อมูลนี้จาก Studio จัดการเซิร์ฟเวอร์ SQL ถูกกำหนด
  1. ระบุ SPID (หมายเลขเซสชัน) ในหัวของกลุ่มที่การบล็อคและรายงานของ SQL
    นอกเหนือจากการใช้สคริปต์นี้ในบทความฐานความรู้ที่ระบุไว้ก่อนหน้านี้ คุณสามารถระบุหัวของกลุ่มที่การบล็อค โดยใช้ลักษณะการทำงานที่ให้ผ่าน Studio จัดการเซิร์ฟเวอร์ SQL เมื่อต้องการทำเช่นนี้ ให้ใช้วิธีการใดวิธีการหนึ่งต่อไปนี้:
    • คลิกขวาวัตถุเซิร์ฟเวอร์ ขยายรายงาน:ขยายรายงานมาตรฐานแล้ว คลิกกิจกรรม – ธุรกรรมการบล็อกทั้งหมด. รายงานนี้แสดงธุรกรรมที่ศีรษะของบล็อกการเชื่อมต่อ If you expand the transaction, the report will show the transactions that are blocked by the head transaction. This report will also show the "Blocking SQL Statement" and the "Blocked SQL Statement."
    • Use DBCC INPUTBUFFER(<spid>) to find the last statement that was submitted by a SPID.</spid>
  2. Find the transaction nesting level and process status of the blocking SPID.
    The transaction nesting level of a SPID is available in the @@TRANCOUNT global variable. However, it can be determined from outside the SPID by querying thesysprocessestable as follows:

    SELECT open_tran FROM master.sys.sysprocesses WHERE SPID=<blocking SPID number>
    go
    						
    The value returned is the @@TRANCOUNT value for the SPID. This shows the transaction nesting level for the blocking SPID, which in turn can explain why it is holding locks. For example, if the value is greater than zero, the SPID is in the midst of a transaction (in which case it is expected that it retains certain locks it has acquired, depending on the transaction isolation level).

    You can also check to see if any long-term open transaction exists in the database by using DBCC OPENTRANdatabase_name.

Gathering SQL Server Profiler Trace Information

In addition to the above information, it is often necessary to capture a Profiler trace of the activities on the server to thoroughly investigate a blocking problem on SQL Server. If a SPID executes multiple statements within a transaction, only the last statementthat was submitted will show in the report, input buffer, or activity monitor output. However, one of the earlier commands may be the reason locks are still being held. A Profiler trace will enable you to see all of the commands executed by a SPID within the current transaction. The following steps help you to set up SQL Server Profiler to capture a trace.
  1. Open SQL Server Profiler.
  2. ในการแฟ้ม:เมนู ให้ชี้ไปที่ใหม่แล้ว คลิกTrace.
  3. ในการทั่วไปtab, specify a trace name and a file name to capture the data to.

    สิ่งสำคัญThe trace file should be written to a fast local or shared disk. Avoid tracing to a slow disk or network drive. Also make sure Server processes trace data is selected.
  4. ในการEvents Selectionแท็บ คลิกเพื่อเลือกนั้นShow all eventsและShow all columnsกล่องกาเครื่องหมายไว้
  5. ในการEvents Selectiontab, add the Event types that are listed in Table 1 to your trace.

    Additionally, you may include the additional Event types that are listed in Table 2 for further information. If you are running in a high-volume production environment, you may decide to use only the events in Table 1, as they are typically sufficient to troubleshoot most blocking problems. Including the additional events in Table 2 may make it easier to quickly determine the source of a problem (or these events may be necessary to identify the culprit statement in a multi-statement procedure). However, including events in Table 2 will also add to the load on the system and increase the trace output size.
Table 1: Event types
ยุบตารางนี้ขยายตารางนี้
HeadingEvent
Errors and Warningsข้อยกเว้น
Errors and Warningsความสนใจ
Security AuditAudit Login
Security AuditAudit Logout
SessionsExisting Connection
กระบวนงานที่เก็บไว้RPC: เริ่มต้น
TSQLSQL:BatchStarting

Table 2: Additional Event types
ยุบตารางนี้ขยายตารางนี้
HeadingEvent
ธุรกรรมDTCTransaction
ธุรกรรมSQLTransaction
กระบวนงานที่เก็บไว้RPC: เสร็จสมบูรณ์แล้ว
TSQLSQL:BatchCompleted
กระบวนงานที่เก็บไว้SP:StmtStarting
กระบวนงานที่เก็บไว้SP:StmtCompleted

For more information about using the SQL Server Profiler, please see SQL Server Books Online.

การระบุและการแก้ไขทั่วไปที่การบล็อกเหตุการณ์

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

การดูผลลัพธ์ของสคริปต์การบล็อค

ตรวจสอบsys.sysprocessesผลลัพธ์การตรวจสอบ heads ของ chains ที่การบล็อค
ถ้าคุณไม่ได้ระบุโหมดรวดเร็วสำหรับสคริปต์ที่การบล็อค จะส่วนชื่อ "SPIDs ที่ศีรษะของ chains การบล็อค" ที่แสดงรายการ SPIDs ที่จะบล็อก SPIDs อื่น ๆ ในการแสดงผลของสคริปต์
SPIDs at the head of blocking chains
ถ้าคุณได้ระบุตัวเลือกที่รวดเร็ว คุณสามารถกำหนดยังคงว่า heads ที่การบล็อค โดยดูsys.sysprocessesเอาพุตและตามลำดับชั้นของ SPID ที่รายงานในคอลัมน์ที่ถูกบล็อค
ตรวจสอบsys.sysprocessesการแสดงผลสำหรับข้อมูลเกี่ยวกับ SPIDs ที่หัวของกลุ่มที่การบล็อค
มีความสำคัญสำหรับประเมินที่ตัวเลือกต่อไปนี้sys.sysprocessesฟิลด์:

สถานะ:

คอลัมน์นี้แสดงสถานะของ SPID ที่เฉพาะ โดยทั่วไป การใช้งานสถานะบ่งชี้ว่า SPID ที่เสร็จสิ้นการดำเนินการ และกำลังรอสำหรับโปรแกรมประยุกต์เพื่อที่ส่งการสอบถามหรือชุดอื่น arunnable,เรียกใช้หรือsos_scheduler_yieldสถานะบ่งชี้ว่า SPID ที่มีอยู่ในขณะนี้ดำเนินแบบสอบถาม ตารางต่อไปนี้ให้คำอธิบายโดยย่อของค่าสถานะต่าง ๆ
ยุบตารางนี้ขยายตารางนี้
สถานะ:ความหมาย
background:SPID กำลังเรียกใช้งาน พื้นหลังเช่นการตรวจหา deadlock
ใช้งานSPID จะไม่อยู่ในขณะนี้จึง ซึ่งมักจะระบุว่า SPID ที่กำลังรอให้คำสั่งจากแอพลิเคชัน
เรียกใช้มีการเรียกใช้ SPID อยู่บนตัวจัดกำหนดการ
runnableSPID อยู่ในคิว runnable ของตัวจัดกำหนดการและกำลังรอการเรียกใช้ตัวจัดกำหนดการเวลา
Sos_scheduler_yieldSPID ถูกเรียกใช้ แต่มีใจ yielded ชิ้นของเวลาในการจัดกำหนดการการอนุญาต SPID อื่นเพื่อขอรับตัวจัดกำหนดการเวลา
หยุดชั่วคราวSPID กำลังรอเหตุการณ์ เช่นล็อกหรือแบบ latch
ย้อนกลับSPID อยู่ในการย้อนกลับของทรานแซคชัน
Defwakeupบ่งชี้ว่า SPID ที่กำลังรอสำหรับทรัพยากรที่อยู่ในระหว่างการลง ฟิลด์ waitresource ควรบ่งชี้ว่า ทรัพยากรมีการสอบถาม

Open_tran

ฟิลด์นี้บอกระดับการซ้อนธุรกรรมของ SPID หากค่านี้ไม่มากกว่า 0, SPID อยู่ภายในธุรกรรมที่เปิด และอาจจะเก็บล็อกที่ได้รับ โดยคำสั่งใด ๆ ภายในธุรกรรม

Lastwaittype, waittype และ waittime

กระบวนการlastwaittypeฟิลด์ถูกแสดงเป็นสตริการwaittypeฟิลด์ ซึ่งก็คือคอลัมน์ไบนารีภายในที่สำรองไว้ ถ้าการwaittypeมี 0x0000, SPID ไม่อยู่ในขณะรออะไรและlastwaittypeค่าที่บ่งชี้ล่าสุดwaittypeว่า SPID นั้นได้ ถ้าการwaittypeไม่ใช่ศูนย์lastwaittypeมูลค่าปัจจุบันที่บ่งชี้waittypeของ SPID

สำหรับคำอธิบายโดยย่อของข้อความที่แตกต่างกันlastwaittypeและwaittypeค่า ดูบทความในฐานความรู้ของ Microsoft ต่อไปนี้:
822101คำอธิบายของคอลัมน์ในตาราง master.dbo.sysprocesses ใน SQL Server 2000 และ SQL Server 2005 waittype และ lastwaittype
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับsys.dm_os_wait_statsดู SQL Server หนังสือออนไลน์

กระบวนการwaittimeค่าที่สามารถใช้เพื่อกำหนดว่า SPID ทำให้ความคืบหน้า เมื่อแบบสอบถามกับแบบsys.sysprocessesตารางส่งกลับค่าในการwaittimeคอลัมน์ที่มีน้อยกว่าwaittimeค่าจากแบบสอบถามก่อนหน้านี้ของsys.sysprocessesนี้บ่งชี้ว่า และล็อกก่อนหน้านี้ได้รับมา และออกใช้ที่อยู่ในขณะนี้ กำลังรอล็อกใหม่ (สมมติ waittime ใช่ศูนย์) ซึ่งสามารถถูกตรวจสอบ โดยเปรียบเทียบwaitresourceระหว่างsys.sysprocessesการแสดงผล

Waitresource

ฟิลด์นี้บ่งชี้ว่า ทรัพยากรที่กำลังรอการ SPID ตารางต่อไปนี้แสดงรายการทั่วไปwaitresourceรูปแบบและความหมายของตนเอง:
ยุบตารางนี้ขยายตารางนี้
ทรัพยากรรูปแบบ:ตัวอย่าง:
ตาราง:DatabaseID:ObjectID:IndexIDแท็บ: 5:261575970:1
ในกรณีนี้ ID 5 ของฐานข้อมูลได้pubsฐานข้อมูลตัวอย่างและวัตถุ 261575970 รหัสได้ชื่อเรื่องตารางและ 1 เป็นดัชนีคลัสเตอร์
หน้าDatabaseID:FileID:PageIDหน้า: 5:1:104
ในกรณีนี้ ID 5 ของฐานข้อมูลเป็นpubsแฟ้ม 1 หมายเลขแฟ้มข้อมูลหลัก และหน้า 104 เป็นหน้าของการชื่อเรื่องตาราง:

เมื่อต้องการระบุ id ของวัตถุที่อยู่ในหน้า ใช้คำสั่ง PAGE DBCC (dbid, fileid, pageid, output_option) และดู m_objId ตัวอย่าง::
DBCC TRACEON ( 3604 )
DBCC PAGE ( 5 , 1 , 104 , 3 )
คีย์:DatabaseID:Hobt_id (ค่าแฮสำหรับดัชนีคีย์)KEY: 5:72057594044284928 (3300a4f361aa)

ในกรณีนี้ ฐานข้อมูลหมายเลข 5 คือ Pubs, Hobt_ID 72057594044284928 ที่สอดคล้องกับคลัสเตอร์ไม่ index_id 2 สำหรับ(id 261575970 วัตถุชื่อเรื่องตาราง) Use the sys.partitions catalog view to associate the hobt_id to a particular index id and object id. There is no way to unhash the index key hash to a specific index key value.
RowDatabaseID:FileID:PageID:Slot(row)RID: 5:1:104:3

In this case, database ID 5 is pubs , file ID 1 is the primary data file, page 104 is a page belonging to the titles table, and slot 3 indicates the row's position on the page.
การคอมไพล์DatabaseID:ObjectID [[COMPILE]]TAB: 5:834102012 [[COMPILE]] This is not a table lock, but rather a compile lock on a stored procedure. Database ID 5 is pubs, object ID 834102012 is stored procedure usp_myprocedure. See Knowledge Base Article 263889 for more information on blocking caused by compile locks.
Other columns

The remainingsys.sysprocessescolumns can provide insight into the root of a problem as well. Their usefulness varies depending on the circumstances of the problem. For example, you can determine if the problem happens only from certain clients (hostname), on certain network libraries (net_library), when the last batch submitted by a SPID was (last_batch), and so on.
Examine the DBCC INPUTBUFFER output.
For any SPID at the head of a blocking chain or with a non-zero waittype, the blocking script will execute DBCC INPUTBUFFER to determine the current query for that SPID.

In many cases, this is the query that is causing the locks that are blocking other users to be held. However, if the SPID is within a transaction, the locks may have been acquired by a previously executed query, not the current one. Therefore, you should also view the Profiler output for the SPID, not just the inputbuffer.

หมายเหตุ:Because the blocking script consists of multiple steps, it is possible that a SPID may appear in the first section as the head of a blocking chain, but by the time the DBCC INPUTBUFFER query is executed, it is no longer blocking and the INPUTBUFFER is not captured. This indicates that the blocking is resolving itself for that SPID and it may or may not be a problem. At this point, you can either use the fast version of the blocking script to try to ensure you capture the inputbuffer before it clears (although there is still no guarantee), or view the Profiler data from that time frame to determine what queries the SPID was executing.

Viewing the Profiler Data

Viewing Profiler data efficiently is extremely valuable in resolving blocking issues. The most important thing to realize is that you do not have to look at everything you captured; be selective. Profiler provides capabilities to help you effectively view the captured data. ในการคุณสมบัติกล่องโต้ตอบ (บนแฟ้ม:เมนู คลิกคุณสมบัติ), Profiler allows you to limit the data displayed by removing data columns or events, grouping (sorting) by data columns and applying filters. You can search the whole trace or only a specific column for specific values (on theแก้ไขเมนู คลิกค้นหา). คุณยังสามารถบันทึกข้อมูล Profiler ตาราง SQL Server (บนแฟ้ม:เมนู ให้ชี้ไปที่บันทึกเป็นแล้ว คลิกตาราง:) และรันการสอบถาม SQL จากนั้น

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

สิ่งที่จะค้นหา:
  • สิ่งที่คำสั่งได้ SPID ที่ที่หัวของกลุ่มการบล็อคที่ดำเนินการภายในธุรกรรมปัจจุบันหรือไม่
    กรองข้อมูลการสืบค้นกลับสำหรับ SPID เฉพาะที่อยู่ที่หัวของกลุ่มที่การบล็อค (ในนั้นแฟ้ม:เมนู คลิกคุณสมบัติแล้วในนั้นตัวกรองแท็บระบุค่า SPID) คุณสามารถตรวจสอบคำสั่งที่มีการทำงานก่อนที่จะเป็นครั้งที่มีการบล็อคการ SPIDs อื่น ๆ แล้ว ถ้าคุณมีเหตุการณ์ทรานแซคชัน พวกเขาสามารถระบุได้โดยง่ายเมื่อเริ่มต้นทรานแซคชัน มิฉะนั้น คุณสามารถค้นหานี้ข้อความคอลัมน์สำหรับ BEGIN, SAVE ส่ง หรือธุรกรรมย้อนกลับการดำเนินงาน ใช้แบบopen_tranค่าจากนั้นsysprocessesตารางเพื่อให้แน่ใจว่าสามารถให้คุณจัดการเหตุการณ์ของธุรกรรมทั้งหมด ทราบว่าคำสั่งที่ดำเนินการและบริบทธุรกรรมจะช่วยให้คุณสามารถกำหนดว่าทำไม SPID ถูกเก็บล็อก

    โปรดจำไว้ คุณสามารถลบเหตุการณ์และข้อมูลคอลัมน์ แทนที่การค้นหาที่เริ่มต้นทั้งสอง และเลือกเหตุการณ์ที่เสร็จสมบูรณ์ หนึ่ง หาก SPIDs ที่การบล็อคจะไม่กระบวนงานที่เก็บไว้ ออกแบบSP: เริ่มต้นหรือSP: เสร็จสมบูรณ์แล้วเหตุการณ์SQLBatchและrpcเหตุการณ์ที่จะแสดงการเรียกขั้นตอน ดูเหตุการณ์ SP เมื่อคุณต้องการดูว่าระดับของรายละเอียดเท่านั้น
  • ระยะเวลาของการสอบถามสำหรับ SPIDs ที่ศีรษะของบล็อก chains คืออะไร
    ถ้าคุณมีการให้เสร็จสมบูรณ์เหตุการณ์ข้างต้น การระยะเวลาคอลัมน์จะแสดงเวลาการดำเนินการแบบสอบถาม ซึ่งสามารถช่วยคุณระบุแบบสอบถามที่รันเป็นเวลานานที่เป็นสาเหตุการบล็อค การตรวจสอบสาเหตุแบบสอบถามกำลังทำงานช้าหรือไม่ ให้ดูCPU,Readและเขียนคอลัมน์ เช่นเดียว กับแผนการดำเนินการเหตุการณ์

categorizing เหตุการณ์จำลองการบล็อคที่ทั่วไป

ตารางด้านล่างแมปอาการทั่วไปสาเหตุของพวกเขา probable หมายเลขที่ระบุไว้ในนั้นสถานการณ์สมมติคอลัมน์ที่สอดคล้องกับหมายเลขในหัวข้อ "วิธีทั่วไปของบล็อกเหตุการณ์และการแก้ไข" ของบทความนี้ด้านล่าง กระบวนการWaittype,Open_Tranและสถานะ:คอลัมน์อ้างอิงถึงsysprocessesข้อมูล กระบวนการแก้ไขหรือไม่คอลัมน์บ่งชี้ว่า หรือ ไม่ บล็อกจะแก้ปัญหาในของตัวเอง

ยุบตารางนี้ขยายตารางนี้
สถานการณ์สมมติWaittypeOpen_Tranสถานะ:แก้ไขหรือไม่อาการอื่น ๆ
1ไม่ใช่ศูนย์>= 0runnableใช่ เมื่อเสร็จสิ้นการสอบถามคอลัมน์ Physical_IO, และ/CPU หรือ Memusage จะเพิ่มช่วงเวลา ระยะเวลาสำหรับการสอบถามจะสูงเมื่อเสร็จสิ้น
20x0000> 0ใช้งานไม่มี แต่สามารถถูก killed SPIDสัญญาณการดูแลจากอาจสามารถดูได้ใน Profiler ที่เกิดการสืบค้นกลับสำหรับ SPID นี้ การระบุการหมดเวลาการสอบถามหรือยกเลิก
30x0000> = 0runnableหมายเลข จะไม่แก้จนกว่าไคลเอ็นต์ fetches แถวทั้งหมด หรือปิดการเชื่อมต่อ spid สามารถถูก killed แต่การดำเนินการดังกล่าวอาจใช้เวลาเกินกว่า 30 วินาทีถ้าopen_tran= 0 และ SPID เก็บล็อกขณะที่ระดับการแยกธุรกรรมเป็นค่าเริ่มต้น (อ่าน COMMMITTED) นี้คือสาเหตุที่น่าจะ
4varies> = 0runnableหมายเลข จะไม่แก้จนกว่าไคลเอ็นต์การยกเลิกการสอบถาม หรือปิดการเชื่อมต่อ SPIDs สามารถ killed แต่อาจใช้เวลาถึง 30 วินาทีกระบวนการชื่อโฮสต์คอลัมน์ในsysprocessesสำหรับ SPID ที่หัวของกลุ่มที่บล็อกจะเท่ากับ SPID กำลังบล็อคอย่างใดอย่างหนึ่ง
50x0000> 0ย้อนกลับใช่สัญญาณแอความสนใจอาจสามารถดูได้ในการสืบค้นกลับ Profiler สำหรับ SPID นี้ การระบุการหมดเวลาการสอบถาม หรือเกิดการยกเลิก หรือเพียงแค่งบการย้อนกลับได้ถูกนำออกใช้
60x0000> 0ใช้งานEventually, เมื่อ Windows NT กำหนดเซสชันถูกใช้งานไม่มีความยาวอยู่ SQL Server จะใช้งานไม่ได้เชื่อมต่อกระบวนการlast_batchค่าในsysprocessesอยู่มากก่อนหน้าเวลาปัจจุบัน

เหตุการณ์จำลองที่มีการบล็อกที่พบโดยทั่วไปและวิธีแก้ไข

สถานการณ์ต่าง ๆ ที่แสดงด้านล่างจะมีลักษณะปรากฏอยู่ในตารางด้านบน ส่วนนี้แสดงรายละเอียดเพิ่มเติมเมื่อใช้ รวมทั้งเส้นทางไปยังความละเอียด
  1. โดยที่กำลังทำเป็นปกติงานการบล็อคเกิดจากแบบสอบถาม ด้วยการปฏิบัติงานเวลาที่ยาว

    การแก้ไข:
    การแก้ไขปัญหาการบล็อกชนิดนี้ถูกใช้เพื่อ ค้นหาวิธีในการปรับการตั้งค่าการสอบถาม จริง คลาสนี้ของปัญหาการบล็อกอาจเพียงมีปัญหาประสิทธิภาพการทำงาน และคุณอาจต้อง pursue เป็นเช่นนั้น สำหรับข้อมูลเกี่ยวกับการแก้ไขปัญหาแบบสอบถามที่รันช้าเฉพาะ ดูบทความฐานความรู้ของ Microsoft ต่อไปนี้:
    243589How to troubleshoot slow-running queries on SQL Server 7.0 or on later versions
    For overall application performance troubleshooting, see the following Knowledge Base article:
    224587HOW TO: Troubleshoot Application Performance with SQL Server
    สำหรับข้อมูลเพิ่มเติม ให้ดูPerformance Monitoring and Tuning How-to TopicsSQL Server 2008 Books Online topic on the following MSDN Web site:
    http://msdn.microsoft.com/en-us/library/ms187830.aspx
    If you have a long-running query that is blocking other users and cannot be optimized, consider moving it from an OLTP environment to a decision support system.
  2. Blocking Caused by a Sleeping SPID That Has Lost Track of the Transaction Nesting Level

    This type of blocking can often be identified by a SPID that is sleeping or awaiting a command, yet whose transaction nesting level (@@TRANCOUNT,open_tranจากsysprocesses) is greater than zero. This can occur if the application experiences a query timeout, or issues a cancel without also issuing the required number of ROLLBACK and/or COMMIT statements. When a SPID receives a query timeout or cancel, it will terminate the current query and batch, but does not automatically roll back or commit the transaction. The application is responsible for this, as SQL Server cannot assume that an entire transaction must be rolled back simply due to a single query being canceled. The query timeout or cancel will appear as an ATTENTION signal event for the SPID in the Profiler trace.

    To demonstrate this, issue the following simple query from Query Analyzer:

    BEGIN TRAN 
    SELECT * FROM SYSOBJECTS S1, SYSOBJECTS S2
    
    -- Issue this after canceling query
    SELECT @@TRANCOUNT
    ROLLBACK TRAN
    						
    While the query is executing, click the redยกเลิกปุ่ม After the query is canceled, SELECT @@TRANCOUNT indicates that the transaction nesting level is one. Had this been a DELETE or an UPDATE query, or had HOLDLOCK been used on the SELECT, all the locks acquired would still be held. Even with the query above, if another query had acquired and held locks earlier in the transaction, they would still be held when the above SELECT was canceled.

    Resolutions:

    • Applications must properly manage transaction nesting levels, or they may cause a blocking problem following the cancellation of the query in this manner. This can be accomplished in one of several ways:
      1. ในตัวจัดการข้อผิดพลาดของแอพลิเคชันไคลเอนต์ ส่งการ IF @@ TRANCOUNT > 0 TRAN ย้อนกลับตามข้อผิดพลาดใด ๆ ถึงแม้ว่าโปรแกรมประยุกต์ของไคลเอ็นต์ไม่มั่นใจว่าธุรกรรมจะเปิดขึ้น นี่คือต้อง เนื่องจากกระบวนงานเก็บไว้ที่เรียกว่าระหว่างชุดงานไม่ได้เริ่มทรานแซคชันไม่ มีความรู้ของโปรแกรมประยุกต์ไคลเอนต์ หมายเหตุว่า เงื่อนไขบาง เช่นการยกเลิกแบบสอบถาม ป้องกันขั้นตอนการดำเนินการในอดีตงบปัจจุบัน ดังนั้นแม้ว่าขั้นตอนดังกล่าวมีตรรกะการตรวจสอบ IF ข้อผิดพลาด @@ <> 0 และยกเลิกธุรกรรม นี้ย้อนกลับจะไม่สามารถเรียกใช้รหัสในกรณีเช่นกัน
      2. ใช้ SET ON XACT_ABORT สำหรับการเชื่อมต่อ หรืออยู่ ในขั้นตอนการจัดเก็บไว้ใด ๆ ซึ่งธุรกรรมที่เริ่มต้น และจะไม่ล้างข้อผิดพลาดในการต่อไปนี้ ในกรณีของข้อผิดพลาดขณะทำงาน การตั้งค่านี้จะยกเลิกธุรกรรมที่เปิด และกลับการควบคุมไปยังไคลเอ็นต์ โปรดสังเกตว่า คำสั่ง T SQL ที่ตามใบแจ้งยอดซึ่งทำให้เกิดข้อผิดพลาดจะไม่สามารถดำเนินการ
      3. ถ้ามีการเชื่อมต่อร่วมกันถูกใช้ในโปรแกรมประยุกต์ที่เปิดการเชื่อมต่อ และเรียกใช้จำนวนแบบสอบถามเล็ก ๆ ก่อนที่จะนำออกใช้การเชื่อมต่อกับพูลโปรแกรม เช่นแอพพลิเคชันที่ขึ้นอยู่กับเว็บ กลับไป เป็นการชั่วคราวปิดใช้งานการเชื่อมต่อร่วมกันอาจช่วย alleviate ปัญหาจนกว่าจะมีการปรับเปลี่ยนแอพลิเคชันไคลเอนต์เพื่อจัดการข้อผิดพลาดอย่างเหมาะสม โดยการปิดใช้งานการเชื่อมต่อร่วมกัน นำออกใช้การเชื่อมต่อจะทำให้เกิด logout ที่มีอยู่จริงของการเชื่อมต่อ SQL Server อันเป็นผลในเซิร์ฟเวอร์ที่นำกลับธุรกรรมที่เปิดอยู่
      4. ถ้ามีการเชื่อมต่อร่วมกันถูกเปิดใช้งาน และเซิร์ฟเวอร์ปลายทางเป็น SQL Server 2000 การปรับรุ่นคอมพิวเตอร์ไคลเอนต์ เพื่อ MDAC 2.6 หรือใหม่กว่าอาจ beneficial คอมโพเนนต์ของ MDAC รุ่นนี้เพิ่มรหัสไปยังโปรแกรมควบคุม ODBC และผู้ให้บริการ OLE DB เพื่อให้การตั้งค่าการเชื่อมต่อจะถูก "ใหม่" ก่อนที่จะ reused เรียกข้อมูลนี้เพื่อ sp_reset_connection aborts ไหวเริ่มต้นเซิร์ฟเวอร์ใด ๆ (DTC ธุรกรรมที่เริ่มต้น โดยโปรแกรมประยุกต์ของไคลเอ็นต์ไม่ได้รับจาก) การตั้งค่าฐานข้อมูลเริ่มต้น ตัวเลือก SET และ forth อื่น ๆ โปรดสังเกตว่า การเชื่อมต่อถูกรีไม่เซ็ตจนกว่าจะมี reused จากประเภทการเชื่อมต่อ ดังนั้นเป็นไปได้ว่า ผู้ใช้สามารถเปิดทรานแซคชัน และการเชื่อมต่อกับประเภทการเชื่อมต่อที่นำออกใช้แล้ว แต่อาจไม่มี reused ข้อมูลดังกล่าวสำหรับเวลาหลายนาที ในช่วงเวลาซึ่งธุรกรรมจะเปิดทิ้งไว้ ถ้าการเชื่อมต่อไม่ถูก reused ธุรกรรมจะถูกยกเลิกเมื่อการเชื่อมต่อหมดเวลา และถูกลบออกจากประเภทการเชื่อมต่อ ซึ่ง จะดีที่สุดสำหรับแอพลิเคชันไคลเอนต์เพื่อยกเลิกธุรกรรมในการจัดการข้อผิดพลาดของตนเอง หรือใช้ SET ON XACT_ABORT เพื่อหลีกเลี่ยงการหน่วงเวลานี้อาจเกิดขึ้น
    • จริง คลาสนี้ปัญหาการบล็อคอาจยังมีปัญหาประสิทธิภาพการทำงาน และคุณอาจต้อง pursue เป็นเช่นนั้น ถ้าเวลาการดำเนินการแบบสอบถามสามารถมี diminished การหมดเวลาการสอบถามหรือยกเลิกจะไม่เกิดขึ้น ไม่สำคัญว่า โปรแกรมประยุกต์ไม่สามารถจัดการการหมดเวลา หรือสถานการณ์การยกเลิกเกิดควรจะขึ้น แต่คุณยังอาจได้รับประโยชน์จากการตรวจสอบประสิทธิภาพการทำงานของแบบสอบถาม
  3. บล็อกที่เกิดจาก SPID ที่ไม่มีแอพลิเคชันไคลเอนต์สอดคล้องกันได้ดึงแถวผลทั้งหมดให้เสร็จสมบูรณ์

    หลังจากการส่งแบบสอบถามไปยังเซิร์ฟเวอร์ โปรแกรมประยุกต์ทั้งหมดต้องทันทีดึงแถวผลลัพธ์ทั้งหมดให้เสร็จสมบูรณ์ ถ้าโปรแกรมประยุกต์ดึงแถวผลลัพธ์ทั้งหมด ไม่ล็อกสามารถถูกปล่อยบนตาราง การบล็อกผู้ใช้อื่น ถ้าคุณกำลังใช้โปรแกรมประยุกต์ที่ส่ง SQL transparently งบไปยังเซิร์ฟเวอร์ โปรแกรมประยุกต์ต้องดึงแถวผลลัพธ์ทั้งหมด ถ้าคุณไม่ (และ ถ้าคุณไม่สามารถกำหนดค่าการทำงาน), คุณอาจไม่สามารถแก้ปัญหาการบล็อคได้ เพื่อหลีกเลี่ยงปัญหา คุณสามารถจำกัดโปรแกรมประยุกต์ที่ poorly behaved เพื่อการรายงานหรือฐานข้อมูลสนับสนุนตัดสินใจ

    การแก้ไข:

    โปรแกรมประยุกต์ต้องมี re-written เพื่อดึงแถวทั้งหมดของผลการดำเนินการเสร็จสมบูรณ์
  4. บล็อกที่เกิดจาก Deadlock ไคลเอ็นต์/เซิร์ฟเวอร์ที่วางจำหน่าย

    ซึ่งแตกต่างจาก deadlock ที่ปกติ deadlock ที่วางจำหน่ายไม่ได้ใช้ตัวจัดการการล็อก RDBMS detectable นี่คือ due to fact ว่าเพียงหนึ่งทรัพยากรเกี่ยวข้องใน deadlock มีการล็อก SQL Server ด้านอื่น ๆ ของ deadlock อยู่ที่ระดับไคลเอนต์แอพลิเคชัน คาบ SQL Server ได้ไม่มีตัวควบคุม ต่อไปนี้คือ ตัวอย่างที่สองของวิธีนี้อาจเกิดขึ้น และวิธีที่เป็นไปได้แอพลิเคชันสามารถหลีกเลี่ยง

    1. การกระจายแบบไคลเอ็นต์/เซิร์ฟเวอร์ Deadlock กับไคลเอนต์ที่หนึ่งเธรด
      ถ้าไคลเอนต์มีการเชื่อมต่อที่เปิดหลาย และเธรดเดียวของการดำเนินการ deadlock ที่แจกจ่ายต่อไปนี้อาจเกิดขึ้น For brevity, the term "dbproc" used here refers to the client connection structure.

       SPID1------blocked on lock------->SPID2
        /\                         (waiting to write results         
        |                           back to client)
        |                                 |
        |                                 |                      Server side
        | ================================|==================================
        |     <-- single thread -->       |                      Client side
        |                                 \/ 
       dbproc1   <-------------------   dbproc2
       (waiting to fetch             (effectively blocked on dbproc1, awaiting
        next row)                     single thread of execution to run)
      								
      In the case shown above, a single client application thread has two open connections. It asynchronously submits a SQL operation on dbproc1. This means it does not wait on the call to return before proceeding. The application then submits another SQL operation on dbproc2, and awaits the results to start processing the returned data. When data starts coming back (whichever dbproc first responds -- assume this is dbproc1), it processes to completion all the data returned on that dbproc. It fetches results from dbproc1 until SPID1 gets blocked on a lock held by SPID2 (because the two queries are running asynchronously on the server). At this point, dbproc1 will wait indefinitely for more data. SPID2 is not blocked on a lock, but tries to send data to its client, dbproc2. However, dbproc2 is effectively blocked on dbproc1 at the application layer as the single thread of execution for the application is in use by dbproc1. This results in a deadlock that SQL Server cannot detect or resolve because only one of the resources involved is a SQL Server resource.
    2. Client/Server Distributed Deadlock with a Thread per Connection

      Even if a separate thread exists for each connection on the client, a variation of this distributed deadlock may still occur as shown by the following.

      SPID1------blocked on lock-------->SPID2
        /\                         (waiting on net write)        Server side
        |                                 |
        |                                 |
        | INSERT                          |SELECT
        | ================================|==================================
        |     <-- thread per dbproc -->   |                      Client side
        |                                 \/ 
       dbproc1   <-----data row-------   dbproc2
       (waiting on                     (blocked on dbproc1, waiting for it
        insert)                         to read the row from its buffer)
      								
      This case is similar to Example A, except dbproc2 and SPID2 are running a SELECT statement with the intention of performing row-at-a-time processing and handing each row through a buffer to dbproc1 for an INSERT, UPDATE, or DELETE statement on the same table. Eventually, SPID1 (performing the INSERT, UPDATE, or DELETE) becomes blocked on a lock held by SPID2 (performing the SELECT). SPID2 writes a result row to the client dbproc2. Dbproc2 then tries to pass the row in a buffer to dbproc1, but finds dbproc1 is busy (it is blocked waiting on SPID1 to finish the current INSERT, which is blocked on SPID2). At this point, dbproc2 is blocked at the application layer by dbproc1 whose SPID (SPID1) is blocked at the database level by SPID2. Again, this results in a deadlock that SQL Server cannot detect or resolve because only one of the resources involved is a SQL Server resource.
    Both examples A and B are fundamental issues that application developers must be aware of. They must code applications to handle these cases appropriately.

    Resolutions:

    Two reliable solutions are to use either a query timeout or bound connections.

    • Query Timeout
      When a query timeout has been provided, if the distributed deadlock occurs, it will be broken when then timeout happens. See the DB-Library or ODBC documentation for more information on using a query timeout.
    • Bound Connections
      This feature allows a client having multiple connections to bind them into a single transaction space, so the connections do not block each other. For more information, see the "Using Bound Connections" topic in SQL Server 7.0 Books Online.
  5. Blocking Caused by a SPID That Is in a "Golden," or Rollback, State

    A data modification query that is KILLed, or canceled outside of a user-defined transaction, will be rolled back. This can also occur as a side effect of the client computer restarting and its network session disconnecting. Likewise, a query selected as the deadlock victim will be rolled back. A data modification query often cannot be rolled back any faster than the changes were initially applied. For example, if a DELETE, INSERT, or UPDATE statement had been running for an hour, it could take at least an hour to roll back. This is expected behavior, because the changes made must be completely rolled back, or transactional and physical integrity in the database would be compromised. Because this must happen, SQL Server marks the SPID in a "golden" or rollback state (which means it cannot be KILLed or selected as a deadlock victim). This can often be identified by observing the output ofsp_who, which may indicate the ROLLBACK command. กระบวนการสถานะ:column ofsys.sysprocesseswill indicate a ROLLBACK status, which will also appear insp_whooutput or in SQL Server Management Studio Activity Monitor.
    การแก้ไข:

    You must wait for the SPID to finish rolling back the changes that were made.

    ถ้าเซิร์ฟเวอร์กำลังปิดลงใน midst ของการดำเนินการนี้ ฐานข้อมูลจะอยู่ในโหมดการกู้คืนเมื่อเริ่มใหม่ และคุณจะไม่สามารถเข้าถึงจนกว่าทั้งหมดเปิด ธุรกรรมจะถูกประมวลผล เริ่มต้นระบบกู้คืน essentially เดียวกันกับระยะเวลาสำหรับแต่ละธุรกรรมเป็นการกู้คืนของเวลาทำงานที่ใช้เวลา และฐานข้อมูลจะไม่สามารถเข้าถึงในระหว่างรอบระยะเวลาการทำงานนี้ ซึ่ง เซิร์ฟเวอร์ลงเพื่อแก้ไขคำ SPID ในสถานะย้อนกลับการบังคับให้มักจะ counterproductive

    เมื่อต้องการหลีกเลี่ยงสถานการณ์เช่นนี้ ไม่ทำใหญ่ชุด INSERT, UPDATE หรือลบการดำเนินการระหว่างชั่วโมงว่าง OLTP ระบบ ถ้าเป็นไปได้ ทำการดำเนินการเช่นในระหว่างรอบระยะเวลาของกิจกรรมที่ต่ำ
  6. บล็อกที่เกิดจากการเชื่อมต่อ Orphaned

    เริ่มต้นถ้า traps ของแอพลิเคชันไคลเอนต์หรือเวิร์กสเตชันของไคลเอ็นต์ถูกใหม่ เซสชันของเครือข่ายไปยังเซิร์ฟเวอร์อาจไม่มีการทันทียกภายใต้เงื่อนไขบางอย่างได้ จากมุมมองของเซิร์ฟเวอร์ ไคลเอนต์ยังคงมีอยู่ และยังอาจถูกรักษาใด ๆ ได้รับการล็อกสำหรับข้อมูลเพิ่มเติม ให้คลิกหมายเลขบทความต่อไปนี้ เพื่อดูบทความในฐานความรู้ของ Microsoft::
    137983วิธีการแก้ไขปัญหาการเชื่อมต่อ orphaned ใน SQL Server

    การแก้ไข:

    ถ้าแอพลิเคชันไคลเอนต์ได้มีการเชื่อมต่อ โดยไม่มีการล้างข้อมูลของทรัพยากรอย่างเหมาะสม คุณสามารถสิ้นสุด SPID ที่ โดยใช้คำสั่งทำลาย คำสั่งทำลายใช้ค่า SPID เป็นอินพุต ตัวอย่างเช่น การทำลาย SPID 9 เพียงแค่ออกคำสั่งต่อไปนี้:

    KILL 9
    						

    หมายเหตุ:คำสั่งทำลายอาจใช้เวลาถึง 30 วินาทีให้เสร็จสมบูรณ์ เนื่องจากถึงช่วงเวลาระหว่างการตรวจสอบสำหรับคำสั่งทำลาย

โปรแกรมประยุกต์ Involvement ในปัญหาการบล็อก

อาจมีการ tendency เพื่อเน้นปัญหาปรับค่าและแพลตฟอร์มฝั่งเซิร์ฟเวอร์เมื่อ facing ปัญหาการบล็อค อย่างไรก็ตาม นี้ไม่มักจะนำความละเอียด และสามารถ absorb เวลาและพลังงานที่ดียิ่งขึ้น โดยตรงในการตรวจสอบแอพลิเคชันไคลเอนต์และการสอบถามที่จะส่ง ไม่ว่าระดับการมองเห็นแอพลิเคชัน exposes เกี่ยวกับเรียกฐานข้อมูลกำลังทำ ปัญหาการบล็อค nonetheless มักต้องตรวจสอบที่ทั้งสองของคำสั่ง SQL ที่แน่นอนที่ส่งมา โดยแอพลิเคชันและแอพลิเคชันของการทำงานที่แน่นอนเกี่ยวกับการยกเลิกแบบสอบถาม การจัดการการเชื่อมต่อ การทั้งหมดที่กำลังฟื้นฟูทำแถว และอื่น ๆ ถ้าเครื่องมือการพัฒนาไม่อนุญาตการควบคุมการจัดการการเชื่อมต่อ การยกเลิกแบบสอบถาม การหมดเวลาการสอบถาม กำลังฟื้นฟูผลลัพธ์ และอื่น ๆ อย่างชัดเจน ปัญหาการบล็อคอาจไม่ได้ resolvable โอกาสนี้ควรเป็นกขนาด examined ก่อนที่จะทำการเลือกเป็นเครื่องมือการพัฒนาโปรแกรมประยุกต์สำหรับ SQL Server โดยเฉพาะอย่างยิ่งสำหรับสภาพแวดล้อม OLTP ทางธุรกิจที่สำคัญ

มีความสำคัญระมัดดีมากจะ exercised ระหว่างขั้นตอนการออกแบบและการดำเนินการของฐานข้อมูลและแอพลิเคชัน โดยเฉพาะ ปริมาณการใช้ทรัพยากร ระดับการแยก และความยาวเส้นทางของธุรกรรมจะถูกประเมินสำหรับแต่ละแบบสอบถาม แต่ละแบบสอบถามและธุรกรรมควรจะเป็น lightweight มากที่สุด ต้อง exercised discipline การจัดการที่ดีในการเชื่อมต่อ ถ้านี่คือไม่ทำ เป็นไปได้ว่า โปรแกรมประยุกต์อาจปรากฏขึ้นเพื่อ ให้ประสิทธิภาพการทำงานที่ยอมรับได้ที่หมายเลขต่ำของผู้ใช้ แต่ประสิทธิภาพอาจลดลงมากเป็นหมายเลขของผู้ใช้ scales upward

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

คุณสมบัติ

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

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

 

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