วิธีการแก้ไขปัญหาประสิทธิภาพการทำงานของแบบสอบถามเฉพาะกิจใน SQL Server

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

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

สรุป

บทความนี้อธิบายวิธีการแก้ไขปัญหาประสิทธิภาพการทำงานช้าของแบบสอบถามเฉพาะกิจโฆษณาที่เกิดขึ้นพร้อมกันหลายใน Microsoft SQL Server ถ้าคุณไม่ได้กำหนดแหล่งที่มาโดยละเอียดของปัญหาของคุณ ดูบทต่อไปนี้ความใน Microsoft Knowledge Base ก่อนที่จะดำเนินต่อ:
224587วิธีการแก้ไขปัญหาประสิทธิภาพการทำงานโปรแกรมประยุกต์กับ SQL Server

บทความนี้อนุมานว่า คุณใช้ 224587 กิโลไบต์เพื่อจำกัดขอบเขตของปัญหา และคุณมีการจับภาพการบันทึกการตรวจสอบประสิทธิภาพการทำงานของ Windows NT และ Profiler SQL ติดตามรายละเอียดที่คอลัมน์ตัวนับ เหตุการณ์ และข้อมูล

ลักษณะของปัญหาประสิทธิภาพการทำงาน

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

    อย่างรวดเร็วคุณสามารถค้นหาการบล็อกโดยการตรวจสอบblkคอลัมน์ในผลลัพธ์ของการsp_whoระบบการจัดเก็บกระบวนการ ถ้าการblkคอลัมน์ไม่ใช่ศูนย์สำหรับหมายเลขของขั้นตอนของระบบรหัส (SPIDs) ไม่มีการบล็อค
  • ในบางสถานการณ์ หน่วยความจำของเซิร์ฟเวอร์เป็น stressed และคุณอาจได้รับข้อความแสดงข้อผิดพลาดที่คล้ายกับข้อผิดพลาดต่อไปนี้:
    ข้อผิดพลาด: 701 ความรุนแรง: สถานะ 17 : 1
    หน่วยความจำระบบไม่เพียงพอที่จะเรียกใช้แบบสอบถามนี้ได้
    หรือ
    msg 8645 ระดับ 17 สถานะ 1 กระบวนงาน บรรทัด 1
    การหมดเวลาขณะรอสำหรับทรัพยากรหน่วยความจำในการดำเนินการแบบสอบถาม re-run แบบสอบถาม

ปรับปรุงในแบบสอบถาม compilations

เนื่องจากการปรับปรุงในสถาปัตยกรรมของระบบที่เริ่มต้นใน SQL Server 7.0 เฉพาะแบบสอบถาม optimizer คุณอาจสังเกตเห็นความแตกต่างในการใช้ทรัพยากรของระบบ โดยเปรียบเทียบกับ SQL Server รุ่นก่อนหน้าของโปรแกรมประยุกต์ โดยเฉพาะอย่างยิ่ง SQL Server 7.0 อาจแสดงเพิ่มขึ้นในการใช้งาน CPU หรือหน่วยความจำ แต่ SQL Server รุ่นก่อนหน้านี้ได้โดยทั่วไปดิสก์ IO ถูกผูกไว้ การเปลี่ยนแปลงเหล่านี้สามารถถูกสืบค้นกลับการสัดส่วนที่สอง:
  • ตัวเชื่อมที่แฮและผสาน
  • เวลาการคอมไพล์ของแบบสอบถาม
เวอร์ชันก่อนหน้าของ SQL Server relied บนวนซ้ำซ้อนการวนซ้ำกว่าการดำเนินการตัวเชื่อมอย่างสมบูรณ์ ตัวเชื่อมวนซ้ำซ้อนกันใช้ดิสก์ IO inherently นำมาเริ่ม SQL Server 7.0 ตัวเชื่อมที่แฮและผสานถูกใช้งาน ตัวเชื่อมที่แฮและผสานทำมากกว่าปริมาณในหน่วยความจำตัวเชื่อมวนซ้ำซ้อนกันที่ไม่ใช่การประมวลผล ผลลัพธ์นี้แบบลอจิคัล CPU นั้น และใช้หน่วยความจำเป็นสูงเมื่อมีใช้เทคนิคต่าง ๆ เหล่านี้เข้าร่วม สำหรับข้อมูลเพิ่มเติมเกี่ยวกับตัวเชื่อมที่แฮและผสาน ให้ดูที่หัวข้อ "ตัวเชื่อมแฮทำความเข้าใจเกี่ยวกับ" และ "ตัวเชื่อมเวียนทำความเข้าใจเกี่ยวกับ" ใน SQL Server 7.0 หนังสือออนไลน์

Query compilation times are affected because the query optimizer has more options and information available than in earlier versions of SQL Server, including new hash and merge join techniques, improved search algorithms, and column statistics. This additional information permits the query optimizer to select the most efficient method to retrieve query data. However, the analysis and consideration of these new techniques and information requires processing time. This increased CPU usage may result in query compilation times that are longer than in earlier versions of SQL Server.

For most queries, this increase in compile time is offset by a decrease in execution time. The overall effect is that the query runs faster than in earlier versions of SQL Server. One exception, however, occurs with very small, simple, OLTP-type queries that have very low execution times. For these queries, the process of generating a query plan may have an equal or greater expense than the query execution. As a result, the query may perform slightly slower than in earlier versions of SQL Server. Because the difference is typically in milliseconds, these effects are not noticed for a particular query if it is executed individually. However, you may notice that overall system CPU usage is higher than in earlier versions of SQL Server if large numbers of ad-hoc queries are executed concurrently by a high number of users.

Develop parameterized queries

SQL Server 7.0 uses several new techniques, such as caching ad-hoc queries and automatic parameterization. However, the queries that SQL Server 7.0 automatically parameterizes are limited. Use the following methods to make sure that the query plans are parameterized and can be reused more effectively:
  • Parameter markersBoth the OLE DB and ODBC APIs permit parameters to be specified with a question mark when users submit queries. This can be very useful in any application, especially for middle-tier applications that have query generation modules where using stored procedures is not available. The query plan that is generated for queries that have parameter markers can be reused by any clients that execute the same query, even if different parameter values are specified. For more information, see the "Parameter Markers" topic in SQL Server 7.0 Books Online.
  • sp_executesqlกระบวนการsp_executesqlstored procedure is called by the OLE DB provider or ODBC driver when parameter markers are used in an application. However, it may also be called directly by the application or in another stored procedure to explicitly parameterize ad-hoc queries. This can be very useful in applications or batch files where the EXECUTE statement is used to execute dynamic SQL statements. Unlikesp_executesql, the EXECUTE statement does not permit parameterization. This limits the chance of query plan reuse. For more information, see the "sp_executesql (T-SQL)" and "Using sp_executesql" topics in SQL Server 7.0 Books Online.
  • Stored proceduresStored procedures have many benefits, including the ability to parameterize queries and reuse execution plans. For more information, see the "Stored Procedures" and "Programming Stored Procedures" topics in SQL Server 7.0 Books Online.

View the Performance Monitor data

Use the Performance Monitor log to determine which system resources are causing the bottleneck. The Performance Monitor log can give you an overall picture of the system and help focus your attention when you view the SQL Profiler data. Review the Performance Monitor data from the time when performance was good through the time that performance decreased. Determine the counter that was affected first, and then determine which of the following issues is most relevant to your situation:
  • Object: Process
    Counter: Processor
    Instance: SQL Server
  • Object: Processor
    ตัวนับ: %เวลาที่ตัวประมวลผล
    Instance: Check each processor instance
  • Object: SQL Server:Buffer Manager
    Counter: Free Buffers
  • Object: SQL Server:Buffer Manager
    Counter: Stolen Page Count
  • Object: SQL Server:Memory Manager
    Counter: Memory Grants Pending
  • Object: SQL Server:SQL Statistics
    Counter: SQL Compilations/sec
ถ้าที่ CPU ใช้ Compilations/วินาที ของ SQL และ บัฟเฟอร์ฟรี counters สูง มีหน่วยความจำให้รอ และ จำนวนเพจที่ถูกขโมยตัวนับเป็นระดับต่ำ ซึ่งแสดงว่า CPU bottleneck นั้น เน้นวิธี parameterize และแผนการสอบถามเพื่อหลีกเลี่ยงการต้นทุนของการสร้างแผนการสอบถามที่นำมาใช้ใหม่ได้อย่างมีประสิทธิภาพ และดูส่วน "จัดกลุ่มการสืบค้นกลับ Profiler SQL ตามคลาสของเหตุการณ์" ของบทความนี้ หากบัฟเฟอร์ฟรีและตัวนับ Compilations/วินาที ของ SQL เป็นระดับต่ำ และตัวนับจำนวนหน้าโจรกรรมและรอให้หน่วยความจำสูง SQL Server จะ constrained หน่วยความจำ เน้นในการค้นหาแบบสอบถามโดยที่ตัวเชื่อมแฮใช้ และสามารถเปลี่ยนการวนรอบตัวเชื่อม และดู "กลุ่ม Profiler SQL สืบค้นกลับ โดยระยะเวลา" ส่วนของบทความนี้ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับตัวนับเหล่านี้ ใช้ชื่อของตัวนับการค้นหาใน SQL Server 7.0 หนังสือออนไลน์

ดูข้อมูล Profiler SQL

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

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

นอกจากนี้คุณควรโฟกัสบนพื้นที่ที่คุณได้รับประโยชน์ที่มากที่สุด สัดส่วนต่อไปนี้จะช่วยเพิ่มประสิทธิภาพการทำงานของแอพลิเคชันแต่ไม่จำเป็นต้อง การระดับเดียวกันได้ ก่อนที่คุณใช้การเปลี่ยนแปลง กำหนดมีผลบังคับใช้วิธีการเปลี่ยนแปลงอาจเป็นตามบนสัดส่วนต่อไปนี้:
  • บ่อยครั้งลักษณะการทำงานของแบบสอบถาม
  • ปรับปรุงจำนวนแบบสอบถามสามารถถูกปรับปรุง
ตัวอย่างเช่น การลดเวลาการดำเนินการของแบบสอบถามหนึ่งจาก 1.5 วินาทีเพื่อวินาที 1.2 อาจไม่ได้เป็นประโยชน์ถ้าแบบสอบถามไม่ทำงานบ่อยตลอดทั้งวัน อย่างไรก็ตาม ถ้าแบบสอบถามจะดำเนินบ่อยครั้งมาก โดยผู้ใช้ที่เกิดขึ้นพร้อมกันจำนวนสูงสุด ปรับปรุงประสิทธิภาพการทำงานที่จะมีประสิทธิภาพมาก conversely การปรับปรุงการสอบถามหนึ่งจากนาทีที่ 6 ถึง 3 วินาทีอาจไม่ yield เป็นการเพิ่มประสิทธิภาพการทำงานโดยรวม noticeable ถ้าไม่ค่อยใช้งาน ใช้การจัดกลุ่มและการกรองเทคนิคใน Profiler SQL และความรู้ของแอพลิเคชันเพื่อประเมินลักษณะพิเศษของแบบสอบถามเฉพาะหรือวิธีดำเนินการก่อนที่คุณใช้การเปลี่ยนแปลงใด ๆ เน้นในการเปลี่ยนแปลงที่มีประสิทธิภาพมากที่สุดเป็นอันดับแรก และจากนั้น ทำตามการวนซ้ำกว่าที่ผ่านการสอบถามและกระบวนการอื่นจนถึงระดับที่ประสิทธิภาพได้ปรับปรุงอย่าง

หลังจากที่คุณบันทึกการสืบค้นกลับของ SQL Profiler ไปยังแฟ้มหรือตาราง การสืบค้นกลับใน Profiler SQL ที่เปิดใหม่อีกครั้ง และตรวจทานเนื้อหา การจัดกลุ่มการสืบค้นกลับ Profiler SQL ดำเนินการดังต่อไปนี้:
  • จัดกลุ่มการสืบค้นกลับ Profiler SQL ตามระยะเวลา:
    1. ในการแฟ้ม:เมนู คลิกคุณสมบัติ.
    2. คลิกการคอลัมน์ข้อมูลแท็บ และจากนั้นภายใต้กลุ่มคลิกสายเมื่อต้องการย้ายระยะเวลา. คลิกลงเมื่อต้องการเอาคอลัมน์อื่น ๆ ทั้งหมด
    3. คลิกการเหตุการณ์แท็บ และจากนั้น ลบเหตุการณ์ทั้งหมดยกเว้นSQL:StmtCompleted TSQLและTSQL RPC: เสร็จสมบูรณ์แล้ว. ซึ่งช่วยให้คุณเน้นในการสอบถามเท่านั้นในแบบที่มีการดำเนินการ
    4. คลิกตกลง.
    จัดกลุ่มตามช่วงเวลาที่อนุญาตให้ดู SQL ง่ายดายงบ ชุดงาน และกระบวนการที่กำลังทำงานที่ slowest ทบทวนการสืบค้นกลับเมื่อเกิดปัญหา และสร้างพื้นฐานของประสิทธิภาพที่ดี คุณสามารถกรองข้อมูลตามเวลาเริ่มต้นเพื่อหยุดการสืบค้นกลับส่วน ๆ ประสิทธิภาพการทำงานเป็นส่วนที่ดี และแยกต่างหากเมื่อประสิทธิภาพต่ำ ค้นหาการสอบถามกับระยะเวลายาวนานที่สุดเมื่อประสิทธิภาพไม่ดี สิ่งเหล่านี้จะเป็นไปได้มากที่สุดรากของปัญหา เมื่อมีลดประสิทธิภาพของระบบโดยรวม แบบสอบถามที่ดียิ่งสามารถแสดงช่วงเวลาที่ยาวได้เนื่องจากพวกเขากำลังรอสำหรับทรัพยากรระบบ

    Review the execution plans for the queries that most frequently have long durations. If you see that a hash join is being used, consider using the LOOP JOIN query hint to force a nested loop join for the query. If the execution time for the query using a loop join is less than, equal to, or even slightly higher than the execution time with the hash join, a loop join may be a better option if the computer is experiencing high memory and CPU usage. By reducing the stress on the resource bottleneck (CPU and memory), you can improve overall system performance. For more information about the LOOP JOIN query hint, see the "SELECT (T-SQL)" topic in SQL Server 7.0 Books Online.
  • Group the SQL Profiler trace by event class:
    1. ในการแฟ้ม:เมนู คลิกคุณสมบัติ.
    2. คลิกการData Columnstab, and then under theGroupsheading, clickUPto moveEvent Classและข้อความwithEvent Classon top. คลิกDOWNto remove all other columns under theGroupsส่วนหัว
    3. คลิกการเหตุการณ์tab, and then make sure that all the events are included.
    4. คลิกตกลง.

Types of events

To see what types of events are occurring on the computer running SQL Server and how frequently the events occur, group by theEvent Classคอลัมน์ Search this column for the following events:
  • MISC: Prepare SQL and Exec Prepared SQL; CURSORS: CursorprepareaPrepare SQLevent indicates that an SQL statement was prepared for use with a default result set (client-side cursor) using SQLPrepare/SQLExecute (for ODBC) or ICommandText::Prepare/ICommandText::Execute (for OLE DB) with the default cursor options: forward only, read only, rowset size = 1. aCursorprepareevent indicates that a server-side cursor was prepared on an SQL statement using SQLPrepare/SQLExecute (for ODBC) or ICommandText::Prepare/ICommandText::Execute (for OLE DB) with the one of the previous cursor options set to a non-default value. AnExec Prepared SQLevent indicates that either of the previous types of existing prepared statements was executed. If you see frequent occurrences of these events, your application is using the prepare/execute model when it opens result sets. If so, you must determine if you are using the prepare/execute model correctly.

    Ideally, an application prepares an SQL statement once and executes it many times so that the optimizer does not have to compile a new plan each time the statement is executed. Each time you run a prepared statement, you save the cost of the query compilation. If you only plan to execute a query one time, Microsoft recommends that you not prepare it. Preparing and then executing an SQL statement requires three network roundtrips: one to prepare the statement, one to execute the statement, and one to unprepare the statement. Preparing server-side cursors requires at least five round trips: one to prepare the cursor, one to execute or open it, one or more to fetch from it, one to close it, and one to unprepare it. Executing the query only requires one roundtrip.

    To see how effectively your application uses the prepare/execute model, compare the number of times these two events (prepare and execute) occur. The number ofExec Prepared SQLevents should be much larger than the total ofPrepare SQLและCursorPrepareevents (at least three to five times larger is a good estimate). This indicates that prepared statements are being reused frequently enough to overcome the increased overhead to create them. If the number ofPrepare SQLและCursorPrepareevents is roughly equivalent to the number ofExec Prepared SQLเหตุการณ์ ซึ่งอาจระบุว่า โปรแกรมประยุกต์ที่ไม่ได้อย่างมีประสิทธิภาพใช้รูปแบบจำลอง/ดำเนินการเตรียม พยายามที่จะเตรียมคำสั่งหนึ่งครั้ง และนำมาใช้ใหม่ได้มากเท่าที่เป็นไปได้ คุณยังสามารถเปลี่ยนโปรแกรมประยุกต์ของคุณเพื่อเตรียมคำสั่งหนึ่งครั้ง และนำมาใช้คำสั่งเหล่านั้น

    โปรแกรมประยุกต์ต้องถูกโดยเฉพาะอย่างยิ่งเขียนใช้รูปแบบจำลอง/เตรียมใช้งานได้อย่างมีประสิทธิภาพ อายุการใช้งานของหมายเลขอ้างอิงคำสั่งที่พร้อมถูกควบคุม โดยระยะคุณเก็บ HSTMT เปิดใน ODBC หรือวัตถุ ICommandText ใน OLE DB หนึ่งวิธีปฏิบัติที่พบโดยทั่วไปคือ การขอรับ HSTMT ข้อ เตรียมคำสั่ง SQL ที่ ดำเนินการคำสั่งที่พร้อม ว่าง HSTMT งบสูญหายของหมายเลขอ้างอิงไปยังแผนพร้อมแล้ว ถ้าคุณทำเช่นนี้ คุณไม่ได้รับประโยชน์ใด ๆ จากแบบจำลอง/เตรียมใช้งาน ใน fact คุณอาจพบการลดประสิทธิภาพการทำงานเนื่องจากความค่าผลิตพิเศษของ roundtrips เครือข่าย โปรแกรมประยุกต์ต้องมีวิธี การแคช HSTMT หรือวัตถุ มีงบที่พร้อมหมายเลขอ้างอิง และ การเข้าถึงเพื่อใช้ใหม่ โปรแกรมควบคุมหรือผู้ให้บริการไม่ดำเนินการนี้โดยอัตโนมัติ โปรแกรมประยุกต์ที่รับผิดชอบในการใช้งาน การบำรุงรักษา และการใช้ข้อมูลนี้ ถ้าโปรแกรมประยุกต์ไม่สามารถทำเช่นนั้น ให้ลองใช้เครื่องหมายของพารามิเตอร์แทนการใช้เมธอด/ดำเนินการเตรียม
  • การใช้เครื่องหมายของพารามิเตอร์โปรแกรมประยุกต์สามารถใช้เครื่องหมายของพารามิเตอร์เพื่อปรับการตั้งค่าการใช้คำสั่ง SQL ของ Transact เดียวหลาย ๆ ครั้งด้วยการป้อนข้อมูลที่แตกต่างกันและค่าการแสดงผล ในครั้งแรกที่แบบสอบถามจะดำเนินการ ถูกเตรียมไว้เป็นแบบสอบถาม parameterized และ SQL Server สร้าง และเก็บแผน parameterized สำหรับแบบสอบถาม สำหรับการโทรศัพท์ในลำดับต่อมาเพื่อใช้ เป็นพารามิเตอร์เดิม หรือแบบสอบถามที่เดียวกัน SQL Server ไม่ได้มีการสร้างแผนการสอบถามใหม่ SQL Server สามารถใช้แผนการสอบถามที่มีอยู่ โดยแทนพารามิเตอร์การปัจจุบัน

    ถ้าแอพลิเคชันใช้ตัวแสดงพารามิเตอร์ที่ มีการเรียกไปยัง SQLExecDirect (ตัวอย่าง ODBC) หรือ ICommandText::Execute (สำหรับ OLE DB), โปรแกรมควบคุมหรือผู้ให้บริการโดยอัตโนมัติชุดคำสั่ง SQL และดำเนินการตามsp_executesqlการเรียก ไม่มีคำชี้แจงสิทธิ์ในการเตรียม และดำเนินการแยกต่างหาก เมื่อที่ SQL Server ได้รับการเรียกsp_executesqlมันโดยอัตโนมัติตรวจสอบแคกระบวนงานสำหรับแผนที่ตรงกัน และ reuses แผนนั้น หรือสร้างแผนใหม่

    การตรวจสอบว่าโปรแกรมประยุกต์ของคุณในขณะนี้ใช้เครื่องหมายของพารามิเตอร์ คุณสามารถค้นหานี้ข้อความคอลัมน์ในการสืบค้นกลับ Profiler SQL สำหรับ "sp_executesql" อย่างไรก็ตาม เนื่องจากsp_executesqlอาจถูกเรียกโดยตรง ไม่ทั้งหมดใช้เครื่องหมายของพารามิเตอร์ที่บ่งชี้ว่า อินสแตนซ์ได้

    สำหรับข้อมูลเพิ่มเติมเกี่ยวกับรูปแบบจำลอง/ดำเนินการเตรียม ให้ดูที่หัวข้อ "นำมาใช้ดำเนินการวางแผนแคและใหม่" ใน SQL Server 7.0 หนังสือออนไลน์ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับเครื่องหมายของพารามิเตอร์ ให้ดูที่หัวข้อ "การเครื่องหมายพารามิเตอร์" ใน SQL Server 7.0 หนังสือออนไลน์
  • SP: เสร็จสมบูรณ์แล้วคำสั่ง SQL แบบไดนามิกที่ดำเนินการ ด้วยคำสั่ง EXECUTE แสดงค่าเป็นการSP: เสร็จสมบูรณ์แล้วเหตุการณ์ที่ มีข้อความ "แบบไดนามิก SQL ขยายการSP: เสร็จสมบูรณ์แล้วเหตุการณ์ และค้นหาแล้วสำหรับเหตุการณ์ที่มี "SQL แบบไดนามิก" เป็นข้อความ ถ้าไม่มีเหตุการณ์เหล่านี้จำนวนมาก คุณอาจปรับปรุงประสิทธิภาพการทำงานของแอพลิเคชัน โดยการใช้sp_executesqlแทนการคำสั่ง EXECUTE กระบวนการsp_executesqlกระบวนงานที่เก็บไว้ช่วยให้ SQL Server เพื่อที่นำมาใช้แผนการดำเนินการถ้าแบบสอบถามเดียวกันจะดำเนินการอีกครั้ง โดยใช้พารามิเตอร์ที่แตกต่างกัน เมื่อคุณใช้คำสั่ง EXECUTE ไม่มี parameterized แผน และจะมีไม่ reused เว้นแต่แบบสอบถามจะดำเนินการอีกครั้ง โดยใช้พารามิเตอร์ที่เหมือนกัน

    การกำหนดแบบสอบถามหรือกระบวนการที่ใช้เหตุการณ์ SQL แบบไดนามิกกับ EXECUTE งบดุล การบันทึกย่อของ ID การเชื่อมต่อ และ เวลาที่เริ่มต้นของสำหรับแต่ละเหตุการณ์ ungroup สืบค้นกลับ (เอาออกคลาสของเหตุการณ์และข้อความจากนั้นกลุ่มส่วนหัว) หลังจากที่คุณ ungroup การสืบค้นกลับ มันจะเรียงลำดับตามลำดับที่ chronological คุณสามารถกรองการสืบค้นกลับ โดย ID การเชื่อมต่อ (บนตัวกรองแท็บ), แล้ว ลบคลาสของเหตุการณ์ทั้งหมดยกเว้นSP: เริ่มต้นและSP: เสร็จสมบูรณ์เหตุการณ์ของ readability ที่เพิ่มขึ้น คุณสามารถค้นหาสำหรับเวลาเริ่มต้นของเหตุการณ์แล้ว (บนแก้ไขเมนู คลิกค้นหา). ผลลัพธ์แสดงเมื่อเริ่มการทำงานเหตุการณ์ SQL แบบไดนามิก ถ้าเกิดเหตุการณ์ในกระบวนงานที่เก็บไว้ เหตุการณ์ปรากฏขึ้นระหว่างการSP: เริ่มต้นและSP: เสร็จสมบูรณ์แล้วเหตุการณ์สำหรับกระบวนการนั้น ถ้าเหตุการณ์ยังไม่เกิดขึ้นในกระบวนงานที่เก็บไว้ จะถูกดำเนินการตามการสอบถามเฉพาะกิจ และคุณสามารถใช้การอื่น ๆ ข้อมูลคอลัมน์(ชื่อโปรแกรมประยุกต์,NT ชื่อผู้ใช้และอื่น ๆ) เพื่อกำหนดตำแหน่งคำสั่งถูกดำเนินการ เมื่อต้องการกำหนดข้อความของคำสั่งและบริบทที่ถูกดำเนินการ คุณสามารถเพิ่มคลาสของเหตุการณ์ เช่นSQL:BatchCompletedและSQL:RPCCompleted.

    หลังจากที่คุณกำหนดที่มีการใช้คำสั่ง EXECUTE ให้ลองเปลี่ยนการเรียกsp_executesql. ตัวอย่างเช่น พิจารณาสถานการณ์สมมติต่อไปนี้ที่ EXECUTE มีใช้คำสั่งกับ SQL แบบไดนามิก ขั้นตอนเกี่ยวกับใช้ชื่อตาราง รหัส และ idValue เป็นพารามิเตอร์ค่านำเข้า แล้ว ดำเนินการคำสั่ง SELECT จากตารางที่ขึ้นอยู่กับค่า ID Using an EXECUTE statement, the procedure looks similar to the following code:
    drop proc dynamicUsingEXECUTE
    		  go create proc dynamicUsingEXECUTE @table sysname, @idName varchar(10),
    		  @idValue varchar(10) as declare @query nvarchar(4000) -- Build query string
    		  with parameter. -- Notice the use of escape quotes. select @query = 'select *
    		  from ' + @table + ' where ' + @idName + ' = ''' + @idValue + '''' exec (@query)
    		  go
    Assuming that the query is not automatically parameterized, if you execute this procedure against thetitlestable in thepubssample database two times with different values for the@idValueparameter, SQL Server must generate a separate query plan for each execution. ตัวอย่าง::
    exec dynamicUsingEXECUTE
    		  'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    		  'title_id', 'BU7832'
    หมายเหตุ:In this example, the query is simple enough that SQL Server can automatically parameterize it and actually reuse the execution plan. However, if this was a complex query that SQL Server may not automatically parameterize, SQL Server may not reuse the plan for the second execution if the@idValueparameter was changed. The following simple query limits the complexity of the example.

    You can rewrite this procedure to usesp_executesqlinstead of the EXECUTE statement. Support for parameter substitution makessp_executesqlmore efficient because it generates execution plans that are more likely to be reused by SQL Server. ตัวอย่าง::
    drop proc dynamicUsingSP_EXECUTESQL go create proc
    		  dynamicUsingSP_EXECUTESQL @table sysname, @idName varchar(10), @idValue
    		  varchar(10) as declare @query nvarchar(4000) -- Build query string with
    		  parameter select @query = 'select * from ' + @table + ' where ' + @idName + ' =
    		  @idValue' -- Now execute with parameter exec sp_executesql @query, N'@idValue
    		  varchar(10)', @idValue go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'MC2222' go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'BU7832'
    In this example, the first time that thesp_executesqlstatement is executed, SQL Server generates a parameterized plan for the SELECT statement fromtitleswithtitle_idas the parameter. For the second execution, SQL Server reuses the plan with the new parameter value. For more information aboutsp_executesql, see the "sp_executesql (T-SQL)" and "Using sp_executesql" topics in SQL Server 7.0 Books Online.
  • SP:RECOMPILESThis event indicates that a stored procedure was recompiled during execution. Many recompile events indicates that SQL Server is using resources for query compilation instead of query execution.
If you do not see any of these events, the application is executing only ad-hoc queries against SQL Server. Unless SQL Server determines that it can automatically parameterize certain queries or if the same parameters are used repeatedly, each query that is executed requires SQL Server to generate a new execution plan. SQL Server Performance Monitor should show many SQL Compilations/sec. This can be CPU-intensive for many concurrent users. To work around this issue, find the most frequently executed queries, and consider creating stored procedures for these queries, using parameter markers, or usingsp_executesql.

ข้อมูลอ้างอิง

For more information about monitoring and troubleshooting performance issues in SQL Server, click the following article numbers to view the articles in the Microsoft Knowledge Base:
224587วิธีการแก้ไขปัญหาประสิทธิภาพการทำงานโปรแกรมประยุกต์กับ SQL Server
224453INF: Understanding and resolving SQL Server 7.0 or 2000 blocking problems
243586recompilation กระบวนงานที่เก็บไว้ในการแก้ไขปัญหา
243589วิธีการแก้ไขปัญหาการทำงานที่ช้าการสอบถาม SQL Server 7.0 หรือใหม่กว่า
251004INF: วิธีการที่ตรวจสอบ SQL Server 7.0 บล็อก

คุณสมบัติ

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

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

 

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