Recompilation กระบวนงานที่เก็บไว้ในการแก้ไขปัญหา

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

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

สรุป

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

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

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

เมื่อผู้ใช้เรียกกระบวนงานที่เก็บไว้ ถ้าไม่มี แล้วอยู่ในแคช SQL Server โหลดขั้นตอน และแบบสอบถามการคอมไพล์ราย วางแผน แผนที่คอมไพล์แล้วบันทึกไว้ในแคช และนำมาใช้ใหม่ โดยผู้เรียกในเวลาต่อมา ของกระบวนงานเก็บไว้จนกว่าการดำเนินการบางอย่างที่เกิดขึ้นเพื่อ ทำแผน และ บังคับให้เป็น recompilation การดำเนินการดังต่อไปนี้อาจทำให้เกิดการ recompilation ของคำ แผนของกระบวนงานที่เก็บไว้:
  • การใช้อนุประโยคด้วยคอมไพล์ใหม่ในกระบวนสร้าง หรือ คำชี้แจงการดำเนินงาน
  • Schema ที่มีการเปลี่ยนแปลงใด ๆ ของวัตถุถูกอ้างอิง รวมถึง การเพิ่ม หรือการปล่อยข้อจำกัด ค่าเริ่มต้น หรือกฎ
  • เรียกใช้งานsp_recompileสำหรับตารางที่ถูกอ้างอิง โดยขั้นตอน
  • การคืนค่าฐานข้อมูลประกอบด้วยกระบวนงานหรืออย่างใดอย่างหนึ่ง วัตถุอ้างอิงกระบวนงาน (ถ้าคุณกำลังทำฐานข้อมูลข้าม การดำเนินงาน)
  • แผนที่จะถูกคำนวณอายุไม่เพียงพอที่ทำให้เกิดกิจกรรม server เพียงพอแล้ว แค
ด้วยเหตุผลเหล่านี้ทั้งหมดสำหรับ recompiling กระบวนงานที่เก็บไว้ไม่มีอยู่ ในเวอร์ชันก่อนหน้านี้ และเกิดขึ้นจากแผนการคอมไพล์ใหม่ก่อนที่จะเริ่มต้น ดำเนินการขั้นตอน ใน SQL Server 7.0 นำมาใช้ลักษณะการทำงานใหม่ ซึ่งอาจทำให้เกิดกระบวนงานที่เก็บไว้ในการคอมไพล์ใหม่ในระหว่างการดำเนินการ ใหม่นี้ ลักษณะการทำงานช่วยให้มั่นใจว่า อาจัดรูปแบบที่มีแผนได้ดีที่สุดสำหรับแต่ละเสมอ คำชี้แจงเฉพาะภายในกระบวนงาน เหตุการณ์ต่อไปนี้อาจทำให้เกิดการ recompilation รันไทม์ของกระบวนงานที่เก็บไว้:
  • เปอร์เซ็นต์ของการเปลี่ยนแปลงข้อมูลในตารางที่ไม่เพียงพอ การอ้างอิงตามกระบวนงานที่เก็บไว้
  • กระบวนการ interleaves ข้อมูลคำจำกัดความภาษา (DDL) และการดำเนินงานภาษาการจัดการข้อมูล (DML)
  • กระบวนการทำการดำเนินการบางอย่างในแบบชั่วคราว ตาราง
สาเหตุเหล่านี้แต่ละที่กล่าวถึงในรายละเอียดต่อไปนี้ บทความ

ในบางกรณี ต้นทุนของ recompiling กระบวนงานที่เก็บไว้ มากกว่าประโยชน์ที่ได้รับมาจากการทำเช่นนั้น ที่โดยเฉพาะอย่างยิ่งสำหรับขนาดใหญ่ ขั้นตอน จำเป็นอย่างยิ่งหมายเหตุว่า เมื่ออยู่ที่ recompilation ทริกเกอร์ การทั้งหมดชุดงานหรือขั้นตอนคือ recompiled ซึ่งหมายความ ว่า ประสิทธิภาพการทำงาน การลดประสิทธิภาพคือสมส่วนโดยตรงกับขนาดของกระบวนงานหรือชุด สำหรับ ข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อนี้ ให้ดูหัวข้อ "เคล็ดลับ Transact SQL" ใน SQL เซิร์ฟเวอร์หนังสือออนไลน์


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

แบบฝึกหัดที่ดีที่สุด

เจ้าของควรเกิดกระบวนงานที่เก็บไว้ชื่อเมื่อคุณ ดำเนินการกับกระบวน ซึ่งช่วยให้ความคมชัดที่ดีกว่าและง่ายต่อการนำมาใช้ใหม่ของเครื่อง แผนปฏิบัติการที่มีอยู่ โดยผู้ใช้ปัจจุบัน ตัวอย่างเช่น ถ้าผู้ใช้ที่ไม่ได้ ปฏิบัติการกระบวนการเป็นเจ้าของ dbo งานเก็บไว้ (เรียกว่าเจ้าของฐานข้อมูล (dbo)myProcในตัวอย่างนี้) ในการpubsฐานข้อมูล ใช้คำสั่งต่อไปนี้:
exec dbo.myProc
				
แทนที่เป็นสาเหตุของสิ่งนี้:
exec myProc
				
เทคนิคนี้ช่วยลดสับสนเกี่ยวกับรุ่นอื่น ๆ ที่เป็นไปได้ของ กระบวนงาน โดยเจ้าของที่แตกต่างจาก standpoint ในการเขียนโค้ดและการบำรุงรักษา และ นอกจากนี้ ช่วยให้ SQL Server เพื่อเข้าถึงแผนปฏิบัติการสำหรับกระบวนงานที่เฉพาะเจาะจง เพิ่มเติมโดยตรง

โดยไม่มีคุณสมบัติชื่อเจ้าของ SQL Server ป้อน คอมไพล์รหัส และล็อคที่ใช้ในการคอมไพล์ในขั้นตอนบอก อย่างไรก็ตาม เพี้ยนพิจารณาแล้วว่า แผนใหม่นั้นไม่จำเป็น (สันนิษฐานว่าไม่ใช่อื่น สาเหตุที่ใช้), ดังนั้นจะไม่คอมไพล์ใหม่แผนณจุดนี้เนื่องจากการไม่มี ของคุณสมบัติ อย่างไรก็ตาม ขั้นตอนพิเศษของการคอมไพล์ล็อกบนเครื่อง กระบวนงานที่สามารถทำให้เกิดการช่วงชิงงานบนบล็อกในสถานการณ์รุนแรง ให้อ้างอิงถึง Q263889 INF: ถึง SQL บล็อกกำหนดเพื่อล็อกคอม [[ไพล์]] สำหรับรายละเอียดเพิ่มเติมในสถานการณ์นี้

ถ้าเจ้าของคุณเกิดการเรียกขั้นตอนกับ owner.procedure คุณทำได้ ไม่ต้องขอรับการล็อกการคอมไพล์ ดังนั้นการช่วงชิงงานบนจะลดลง

การระบุและการแก้ไขปัญหา

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

ดูข้อมูลของผู้สร้างโปรไฟล์

ของผู้สร้างโปรไฟล์ของเซิร์ฟเวอร์ SQL รวมถึงการSP:Recompileเหตุการณ์ที่คุณสามารถใช้การตรวจสอบจำนวน recompiles เกิดขึ้น ที่SP:Recompileเหตุการณ์ที่เกิดขึ้นเมื่อใดก็ ตามที่กระบวนงานที่เก็บไว้ที่ recompiles ในระหว่าง การปฏิบัติงาน
  • การจัดกลุ่มการสืบค้นกลับของผู้สร้างโปรไฟล์ โดยคลาสเหตุการณ์

    1. บนเครื่องแฟ้มเมนู คลิกคุณสมบัติ.
    2. บนเครื่องคอลัมน์ของข้อมูลแท็บ ใช้ปุ่มขึ้นเพื่อย้ายไปคลาสเหตุการณ์และข้อความภายใต้การกลุ่มหัวเรื่อง ด้วยคลาสเหตุการณ์ครั้งแรก ใช้ปุ่มลงเพื่อเอาคอลัมน์อื่น ๆ ภายใต้การกลุ่มหัวเรื่อง
    3. คลิกตกลง.
    หมายเลขของเช็คSP:Recompileเหตุการณ์

    คุณสามารถขยายกลุ่ม SP:Recompile เพื่อดู รายละเอียดของการเกิดขึ้นครั้งละ ที่ข้อความคอลัมน์ของเหตุการณ์บ่งชี้ชื่อของกระบวนงานที่เก็บไว้ ที่ recompiled ถ้าขั้นตอนหลายจะก่อให้เกิดการ recompiles เรียงลำดับ ด้วยจำนวนของการเกิด ถ้าคุณมีจำนวนมากSP:Recompileเหตุการณ์และคุณพบใช้ CPU สูง โฟกัสบน การแก้ไขกระบวนงานที่มีจำนวนสูงสุดของ recompiles หมายเหตุการ ระบบประมวลผลรหัส (SPID) และเวลาเริ่มต้นของการSP:Recompileเหตุการณ์สำหรับอินสแตนซ์หนึ่งของ procedure(s) ที่เก็บไว้เฉพาะ และ ทำตามขั้นตอนด้านล่าง

    ถ้าคุณไม่เห็นใด ๆSP:Recompileเหตุการณ์ แต่คุณยังคงประสบปัญหาประสิทธิภาพการทำงาน ดู บทความต่อไปนี้ในฐานความรู้ของ Microsoft:
    224587วิธีการ: การแก้ไขปัญหาประสิทธิภาพของโปรแกรมประยุกต์กับ SQL Server
  • ตรวจสอบคำชี้แจงที่ทริกเกอร์เหตุการณ์การคอมไพล์

    1. บนเครื่องแฟ้มเมนู คลิกคุณสมบัติ.
    2. บนเครื่องคอลัมน์ของข้อมูลแท็บ ใช้ปุ่มลงเพื่อเอาคอลัมน์อื่น ๆ ภายใต้การกลุ่มหัวเรื่อง
    3. บนเครื่องเหตุการณ์แท็บ เอาเหตุการณ์ทั้งหมดยกเว้นSP: เริ่มต้น,SP:StmtStarting,SP:RecompileและSP: เสร็จสมบูรณ์. ถ้าคุณยังไม่จับตัวSP:StmtStartingเหตุการณ์ คุณสามารถใช้แทนSP:StmtCompletedแต่ไม่รวมทั้งสองเนื่องจากวิธีการดังกล่าวดังนั้น doubles จำนวน ข้อมูลที่คุณต้องการค้นหา
    4. ถ้าคุณได้ระบุอินสแตนซ์ที่เฉพาะเจาะจงของคำ recompilation กระบวนการตรวจสอบ การจัดเก็บไว้คุณสามารถจำกัดข้อมูลคุณดูการ SPID และกรอบเวลาของการเกิดโดยใช้เฉพาะตัวกรองแท็บ
    5. คลิกตกลง.

    ที่SP:Recompileจะยกเหตุการณ์ต่อไปนี้โดยตรงSP:StmtStartedเหตุการณ์ของคำชี้แจงของกระบวนงานที่เก็บไว้ที่เกิดจากการ recompilation หลังจากเหตุการณ์การคอมไพล์เสร็จสิ้นแล้ว คุณจะเห็นการทำซ้ำของ ที่SP:StmtStartedเหตุการณ์ เพื่อบ่งชี้ว่า คำสั่งที่กำลังดำเนินการกับตัวใหม่ สร้างแผนการ

    พิจารณาตัวอย่างต่อไปนี้:
    use pubs
    go
    drop procedure RecompProc 
    go
    create procedure RecompProc as
    create table #t (a int)
    select * from #t
    go
    exec RecompProc
    						
    ถ้าคุณเรียกใช้รหัสนี้ในตัววิเคราะห์คำถาม และดูเหตุการณ์ข้างต้นใน การติดตามของผู้สร้างโปรไฟล์ คุณจะเห็นลำดับต่อไปนี้:

    ยุบตารางนี้ขยายตารางนี้
    คลาสเหตุการณ์ข้อความ
    SP: เริ่มต้นRecompProc
    SP:StmtStartingสร้างตารางการ# t (int)
    SP:StmtStartingเลือก * จาก# t
    SP:RecompileRecompProc
    SP:StmtStartingเลือก * จาก# t
    SP: เสร็จสมบูรณ์RecompProc


    คุณสามารถทราบทันทีที่คำสั่งที่ caused recompilation ที่มี:
    select * from #t
    						
    เพราะจะปรากฏทั้งก่อน และหลังการSP:Recompileเหตุการณ์

    ถ้าคุณได้จับภาพเท่านั้นSP:StmtCompletedเหตุการณ์ แต่ไม่SP:StmtStartingเหตุการณ์SP:Recompileจะแสดงโดยตรงก่อนการสั่งซึ่งทำให้เกิดเป็น ด้านล่างนี้:

    ยุบตารางนี้ขยายตารางนี้
    คลาสเหตุการณ์ข้อความ
    SP: เริ่มต้นRecompProc
    SP:RecompileRecompProc
    SP:StmtCompletedเลือก * จาก# t
    SP: เสร็จสมบูรณ์RecompProc


    คุณสามารถดูที่การSP:Recompileมียกเหตุการณ์ก่อนการSP:StmtCompletedเหตุการณ์สำหรับการ "เลือก * จาก# t " งบ ซึ่งเกิดจากการ recompilation ซึ่งทำให้ถูกต้อง เนื่องจากไม่สามารถกรอกคำชี้แจงจนถึง หลังจากที่มีสร้างแผนการสอบถามใหม่สำหรับการคอมไพล์ ทั้งหมดเหลือ ตัวอย่างนี้การใช้บทความSP:StmtStartingเหตุการณ์ ถ้าคุณจับเฉพาะSP:StmtCompletedเหตุการณ์ เพียงแค่อย่าลืมดูคำชี้แจงหลังจากSP:Recompileดังที่ได้อธิบายไว้ข้างต้น

    หมายเหตุว่า ถ้าคุณดำเนินการนี้ เฉพาะเก็บขั้นตอนหลายครั้ง SQL Server จะนำมาใช้ที่มีอยู่ วางแผนสำหรับกระบวนการนี้ นอกจากนี้คุณเท่านั้นจะเห็นเหตุการณ์การคอมไพล์ใหม่ในครั้งแรก การปฏิบัติการของกระบวนการ หรือ ถ้าคุณปล่อย และสร้างกระบวนการแต่ละตาราง เวลาที่คุณเรียกใช้สคริปต์ เหตุผลสำหรับการ recompilation ในเฉพาะนี้ กรณีที่ถูกกล่าวถึงใน "Recompilations ถึงครบกำหนดแทรกสลับข้อมูลข้อมูลนิยาม ส่วนนี้ภาษา (DDL) และข้อมูลการดำเนินงาน (DML) ของจัดการภาษา" บทความ นี่เป็นเพียงตัวอย่างเพื่อแสดงให้เห็นถึงวิธีการกำหนดซึ่งได้อย่างง่ายดาย คำชี้แจงเป็นสาเหตุที่ recompilation

Recompilations เนื่องจากการปรับเปลี่ยนแถว

ถ้าเปอร์เซ็นต์ที่เพียงพอของข้อมูลในตารางมีการเปลี่ยนแปลง การอ้างอิงตามกระบวนงานที่เก็บไว้ตั้งแต่ครั้งที่แผนแบบสอบถามต้นฉบับถูก คอมไพล์สร้าง SQL Server จะใหม่กระบวนงานที่เก็บไว้เพื่อให้แน่ใจว่า มี แผนที่ขึ้นอยู่กับข้อมูลสถิติที่ทันสมัยที่สุด เป็นตัวอย่าง พิจารณา ขั้นตอนการจัดเก็บต่อไปนี้:
drop procedure RowModifications 
go
create procedure RowModifications as
-- assume SomeTable exists with the same definition as #t, 
-- and has over 1000 rows
create table #t (a int, b char(10))
select * from #t
insert #t select * from SomeTable
select count(*) from #t  where a = 37
go
exec RowModifications
exec RowModifications
				
สำหรับการดำเนินการที่สองของการRowModificationsขั้นตอน คุณจะเห็นเหตุการณ์ต่อไปนี้ในการ ของผู้สร้างโปรไฟล์:

ยุบตารางนี้ขยายตารางนี้
คลาสเหตุการณ์ข้อความ
SP: เริ่มต้นRowModifications
SP:StmtStartingสร้างตาราง# t (เป็น int, b char(10))
SP:StmtStartingเลือก * จาก# t
SP:StmtStartingแทรกการเลือก t # * จาก SomeTable
SP:StmtStartingเลือก count(*) จาก# t แบบ = 37
SP:RecompileRowModifications
UpdateStats อัตโนมัติแบบ
SP:StmtStartingเลือก count(*) จาก# t แบบ = 37
SP: เสร็จสมบูรณ์RowModifications

หมายเหตุ:การปฏิบัติการแรกจะแสดงเป็นSP:Recompileเหตุการณ์สำหรับการ "เลือก * จาก# t " คำสั่ง เหตุผลสำหรับการ recompilation ในกรณีเฉพาะนี้จะกล่าวถึงใน " Recompilations ครบกำหนดถึง แทรกสลับข้อมูลภาษานิยามข้อมูล (DDL) และภาษาการจัดการข้อมูล ส่วนการดำเนินงาน (DML)"ของบทความนี้ สำหรับตัวอย่างนี้ เน้นSP:Recompileแสดงข้างบนเนื่องจากเกิดขึ้นทุกครั้งที่มีกระบวนการ ดำเนินการ

ในตัวอย่างนี้, "เลือก count(*) จาก# t ซึ่งเป็น = 37" ทำให้ recompilation ของกระบวนการเนื่องจากการเปลี่ยนแปลงจำนวนของแถว เนื่องจากตารางถูกสร้างขึ้น สถานะการออนไลน์ของเครื่องUpdateStats อัตโนมัติเหตุการณ์นี้ยืนยันว่า recompilation ที่มีครบกำหนดแถว การปรับเปลี่ยน ที่ข้อความคอลัมน์แสดงคอลัมน์มีสถิติ การปรับเปลี่ยน

เมื่อมีสร้างตาราง t # จำนวนแถวที่เป็นศูนย์ แผนการสำหรับต้นฉบับ "เลือก * จาก# t " พัฒนาขึ้นกับจำนวนแถวที่ รวมทั้งการวางแผนสำหรับแบบสอบถาม "เลือก count (*)" อย่างไรก็ตาม ก่อน "เลือก count(*)" จะดำเนินการ 1000 แถวใหม่จะถูกแทรกลงในตาราง t # เนื่องจากมีการเปลี่ยนแปลงจำนวนข้อมูลเพียงพอ อาจัดรูปแบบที่ recompiles ขั้นตอนเพื่อให้แน่ใจว่า ได้เลือกแผนประสิทธิภาพมากที่สุดสำหรับการ คำชี้แจง Recompilation นี้จะเกิดขึ้นในทุก ๆ การปฏิบัติการของที่เก็บไว้ ดูขั้นตอนเนื่องจากการแทรก 1000 แถวจะเสมอได้เป็น ความสำคัญต่อพอ warrant recompilation

อัลกอริทึมของ sql SERVER ใช้ในการตรวจสอบว่า แผนควร recompiled เป็นอัลกอริทึมที่เดียวกัน ใช้สำหรับการปรับปรุงอัตโนมัติสถิติตามที่อธิบายไว้ในบทความต่อไปนี้ในการ ฐานความรู้ของ Microsoft:
195565INF: วิธีการทำ SQL Server 7.0 และ SQL Server 2000 Autostats งาน
ในตัวอย่างข้างต้น กระบวนงานที่เก็บไว้มีขนาดเล็ก พอว่า recompilation ที่จะต้องไม่มีลักษณะพิเศษที่สามารถในการ ประสิทธิภาพการทำงาน อย่างไรก็ตาม ถ้าคุณมีกระบวนงานจัดเก็บขนาดใหญ่ที่ทำ กิจกรรมคล้ายคลึงกันที่เป็นผลในหลาย recompilations คุณอาจสังเกตเห็นการ การลดประสิทธิภาพ

วิธีการต่อไปนี้ที่มีอยู่เพื่อ counteract recompilations เนื่องจากการปรับเปลี่ยนแถว:
  • ดำเนินการโดยใช้คำสั่งsp_executesql.
    นี่คือวิธีการที่ต้องการ คำสั่งที่เรียกใช้โดยการsp_executesqlกระบวนงานที่เก็บไว้จะไม่มีการคอมไพล์เป็นส่วนหนึ่งของกระบวนงานที่เก็บไว้ วางแผน ดังนั้น เมื่อดำเนินการคำสั่ง SQL Server จะมีอิสระในการ ใช้แผนการที่มีอยู่ในแคชสำหรับคำชี้แจง หรือสร้างขึ้นใหม่ใน รันไทม์ ในกรณีใดกรณีหนึ่ง มีแผนสำหรับกระบวนงานที่เก็บไว้เรียก รับผลกระทบและไม่ต้องมี recompiled

    งบดำเนินการ จะมีผลเหมือนกับ อย่างไรก็ตาม มันจะไม่แนะนำ โดยใช้การดำเนินการ คำชี้แจงไม่เป็นวิธีที่มีประสิทธิภาพเป็นการใช้sp_executesqlเนื่องจากไม่ได้อนุญาตให้สำหรับ parameterization ของเครื่อง การสอบถาม

    ที่RowModificationsสามารถเขียนกระบวนงานที่กำหนดไว้ข้างต้นไปใช้sp_executesqlดังนี้:

    drop procedure RowModifications2 
    go
    create procedure RowModifications2 as
    set nocount on
    -- assume SomeTable exists with the same definition as #t, 
    -- and has over 1000 rows
    create table #t (a int, b char(10))
    select * from #t
    insert #t select * from SomeTable
    exec sp_executesql N'select count(*) from #t where a = @a', 
                       N'@a int', @a =  37
    go
    exec RowModifications2
    exec RowModifications2
    						

    สำหรับการดำเนินการที่สองของการRowModifications2ขั้นตอน คุณจะเห็นเหตุการณ์ต่อไปนี้ในการ ของผู้สร้างโปรไฟล์:

    ยุบตารางนี้ขยายตารางนี้
    คลาสเหตุการณ์ข้อความ
    SP: เริ่มต้นRowModifications2
    SP:StmtStartingสร้างตาราง# t (เป็น int, b char(10))
    SP:StmtStartingเลือก * จาก# t
    SP:StmtStartingแทรกการเลือก t # * จาก SomeTable
    SP:StmtStartingexec sp_executesql N'select count(*) จาก# t ซึ่งเป็น =@เป็น ', N'@a int', @แบบ = 37
    SP: เริ่มต้น
    SP:StmtStartingเลือก count(*) จาก# t แบบ = @การ
    UpdateStats อัตโนมัติแบบ
    SP:StmtStartingเลือก count(*) จาก# t แบบ = @การ
    SP: เสร็จสมบูรณ์
    SP: เสร็จสมบูรณ์RowModifications2


    ขอให้สังเกตว่ามีไม่มีSP:Recompileเหตุการณ์สำหรับตัวRowModifications2กระบวนการ มีอยู่ทั้งหมดSP: เริ่มต้นเมื่อต้องการSP: เสร็จสมบูรณ์เหตุการณ์สำหรับตัวsp_executesqlเรียกบริบท และการUpdateStats อัตโนมัติเหตุการณ์สำหรับคอลัมน์แบบ. อย่างไรก็ตาม เนื่องจากการเรียกนี้ไม่มีบริบทของที่เก็บไว้ กระบวนการ การRowModifications2กระบวนงานที่ไม่จำเป็นต้อง recompiled ในกรณีนี้

    สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้เครื่องsp_executesqlกระบวนงาน เก็บไว้ดู "sp_executesql (T-SQL)" และ "การใช้ sp_executesql"ของหัวข้อใน SQL Server Books Online
  • ใช้ sub-procedures เพื่อดำเนินการคำสั่งที่อยู่ สาเหตุที่ recompilations
    ในกรณีนี้ คำชี้แจงอาจทำให้ยังคงเป็น recompilation แต่แทนที่เป็น ของ recompiling ใหญ่เรียกเก็บกระบวนการ มันจะคอมไพล์ใหม่ sub-procedure เล็กน้อยเท่านั้น
  • ใช้ตัวเลือกการวางแผนการรักษา
    ตารางชั่วคราวได้ กฎพิเศษเกี่ยวกับ recompilations ซึ่ง ในบางกรณี อาจเพิ่มเติม stringent ที่นอกเหนือจากอัลกอริทึมการ recompilation เป็นค่าเริ่มต้น คุณสามารถใช้การทำให้การวางแผน ตัวเลือกการพักผ่อนเพดานตารางชั่วคราวกลับไปอัลกอริทึมการเริ่มต้น สำหรับข้อมูลเพิ่มเติม ให้ดู "การหลีกเลี่ยง Recompilation โดยการใช้เก็บแผน ส่วนตัวเลือก"ของบทความนี้
หมายเหตุ:ที่RowModificationsกระบวนงานที่มีกระบวนงานที่เป็นอย่างมากอย่างง่าย recompiled เนื่องจากการปรับเปลี่ยนแถว กรุณาตรวจทาน caveats ดังต่อไปนี้ เกี่ยวข้องกับตัวอย่างนี้:

  • ถึงแม้ว่าตัวอย่างใช้เป็นตารางชั่วคราว สถานการณ์นี้ ใช้กับกระบวนงานที่เก็บไว้ที่อ้างอิงตารางแบบถาวรเช่นเดียวกัน ถ้ามี ยอดเงินที่เพียงพอของข้อมูลในตารางการอ้างอิงมีการเปลี่ยนแปลงนับตั้งแต่ มีสร้างแผนการสอบถาม กระบวนงานที่เก็บไว้จะถูก recompiled ที่ ความแตกต่างในตารางชั่วคราวอย่างไรถือว่าสำหรับวัตถุประสงค์ recompilation อธิบายไว้ใน "การหลีกเลี่ยง Recompilation โดยการใช้ที่เก็บแผนตัว" ส่วนของบทความนี้
  • Executions แรกของกระบวนงานที่สองข้างต้นที่ทำให้ recompilation ในการเลือกครั้งแรกจาก t #ตารางชั่วคราว เหตุผล สำหรับ recompilation นี้จะถูกกล่าวถึงในการแทรกสลับ "Recompilations ถึงครบกำหนดข้อมูล ภาษานิยามข้อมูล (DDL) และการดำเนินงานภาษา (DML) การจัดการข้อมูล" ส่วนของบทความนี้
  • คำชี้แจง "เลือก count(*) จาก# t" ถูกใช้ในที่นี้ ตัวอย่าง แทนอย่างง่าย "เลือก * จาก# t " คำสั่ง เมื่อต้องการหลีกเลี่ยงการมากเกินไป recompilations, SQL Server ไม่พิจารณา recompiling "trivial แผน" (เช่น เป็นการเลือก * จากตาราง) เนื่องจากการปรับเปลี่ยนแถว

Recompilations เนื่องจากการแทรกสลับข้อมูลภาษานิยามข้อมูล (DDL) และจัดการข้อมูลการดำเนินงานของภาษา (DML)

ถ้า DDL มีดำเนินภายในกระบวนงานหรือชุดงาน การ ขั้นตอนหรือชุดคือ recompiled เมื่อไปถึง DML ที่ตามมาครั้งแรก ตาราง DDL เกี่ยวข้องกับการส่งผลกระทบต่อการดำเนินงาน

พิจารณาการ ทำตามตัวอย่างที่เก็บไว้ตามขั้นตอน:
drop procedure Interleave 
go
create procedure Interleave as
-- DDL
create table t1 (a int)
-- DML
select * from t1
-- DDL
create index idx_t1 on t1(a)
-- DML
select * from t1
-- DDL
create table t2 (a int)
-- DML
select * from t2
go
exec Interleave
				
ถ้าคุณเรียกใช้รหัสนี้ในตัววิเคราะห์คำถาม และดูเหตุการณ์ข้างต้นใน การติดตามของผู้สร้างโปรไฟล์ คุณจะเห็นลำดับต่อไปนี้:

ยุบตารางนี้ขยายตารางนี้
คลาสเหตุการณ์ข้อความ
SP: เริ่มต้นInterleave
SP:StmtStartingสร้างตาราง t1 (int)
SP:StmtStartingเลือก * จาก t1
SP:RecompileInterleave
SP:StmtStartingเลือก * จาก t1
SP:StmtStartingสร้างดัชนี idx_t1 บน t1(a)
SP:StmtStartingเลือก * จาก t1
SP:RecompileInterleave
SP:StmtStartingเลือก * จาก t1
SP:StmtStartingสร้างตาราง t2 (int)
SP:StmtStartingเลือก * จาก t2
SP:RecompileInterleave
SP:StmtStartingเลือก * จาก t2
SP: เสร็จสมบูรณ์Interleave


ในกรณีนี้ recompiled กระบวนงานที่เก็บไว้ สามครั้งในระหว่างการปฏิบัติงาน เมื่อต้องการทำความเข้าใจเกี่ยวกับเหตุนี้เกิดขึ้น พิจารณาวิธี อาจัดรูปแบบ develops แผนสำหรับกระบวนงานที่เก็บไว้นี้:
  1. ในระหว่างการคอมไพล์ที่เริ่มต้นของกระบวนการ t1 ตาราง และ t2 ไม่มีอยู่ ดังนั้น ไม่มีแผนการสำหรับการสอบถามที่อ้างอิงถึงสิ่งเหล่านี้ สามารถสร้างตาราง พวกเขาต้องสร้างขึ้นในขณะดำเนินการ
  2. ขณะที่กระบวนงานดำเนินการสำหรับในครั้งแรก ครั้งแรก ขั้นตอนคือการ สร้างตาราง t1 ขั้นตอนถัดไปถูกเลือกจากตาราง t1--ซึ่ง ไม่มีไม่มีแผนสำหรับ ดังนั้น recompiled กระบวนการขั้นตอนนี้ไป พัฒนาแผนการสำหรับคำสั่ง select มีสร้างแผนการใช้พลังงานสำหรับปัจจุบัน เลือกจาก t1 รวมทั้งเลือกจาก t1 หลังการสร้างดัชนี ไม่มีแผน สามารถสร้างขึ้นสำหรับการเลือกจาก t2 เนื่องจากมี t2 ยังคงอยู่ ยัง
  3. ขั้นตอนต่อไปคือการ สร้างดัชนีบน t1 ต่อไปนี้ที่ ทำการเลือกอื่นบน t1 ซึ่งขณะนี้ มีแผนจากรายการแรก การคอมไพล์ใหม่ อย่างไรก็ตาม เนื่องจาก schema ของ t1 ได้ถูกเปลี่ยนแปลงนับตั้งแต่แผนนั้น ถูกสร้างขึ้น กระบวนการต้องสามารถ recompiled อีกครั้งเพื่อสร้างแผนใหม่ สำหรับการเลือกจาก t1 และเนื่องจาก t2 ยังคงไม่ได้ สามารถที่จะไม่มีแผน สร้างสำหรับการเลือกจาก t
  4. T2 ตารางถูกสร้างขึ้น และถูกเลือกจาก t2 ถัดไป ดำเนินการ เนื่องจากไม่มีแผนการที่มีอยู่สำหรับใบแจ้งยอด กระบวนการ recompiled แบบ ครั้งสุดท้าย
Recompilations เหล่านี้เกิดขึ้นในทุก ๆ การปฏิบัติการของที่เก็บไว้ กระบวนการ เมื่อต้องการลดการ recompilations ปรับเปลี่ยนขั้นตอนการทำ DDL ทั้งหมด การดำเนินการครั้งแรก ตาม ด้วยดำเนินการ DML ดังที่แสดงในตัวอย่างต่อไปนี้:
drop procedure NoInterleave 
go
create procedure NoInterleave as
-- All DDL first
create table t1 (a int)
create index idx_t1 on t1(a)
create table t2 (a int)
-- Then DML 
select * from t1
select * from t1
select * from t2
go
exec NoInterleave 
exec NoInterleave
				
การดำเนินการครั้งแรกของการNoInterleaveกระบวนงานจะแสดงเหตุการณ์ต่อไปนี้ในเว็บไซต์ของผู้สร้างโปรไฟล์:

ยุบตารางนี้ขยายตารางนี้
คลาสเหตุการณ์ข้อความ
SP: เริ่มต้นNoInterleave
SP:StmtStartingสร้างตาราง t1 (int)
SP:StmtStartingสร้างดัชนี idx_t1 บน t1(a)
SP:StmtStartingสร้างตาราง t2 (int)
SP:StmtStartingเลือก * จาก t1
SP:RecompileNoInterleave
SP:StmtStartingเลือก * จาก t1
SP:StmtStartingเลือก * จาก t1
SP:StmtStartingเลือก * จาก t2
SP: เสร็จสมบูรณ์NoInterleave


ในกรณีนี้ คำสั่ง DDL ทั้งหมดมีการจัดทำขึ้น ด้านหน้า คอมไพล์อาจัดรูปแบบที่รายนี้ขั้นตอนดังนี้:
  1. ในระหว่างการคอมไพล์ที่เริ่มต้นของกระบวนการ t1 ตาราง และ t2 ไม่มีอยู่ ดังนั้น ไม่มีแผนการสำหรับการสอบถามที่อ้างอิงถึงสิ่งเหล่านี้ สามารถสร้างตาราง พวกเขาต้องสร้างขึ้นในขณะดำเนินการ
  2. ขั้นตอนแรกที่ดำเนินการตามขั้นตอนเป็น DDL การดำเนินการ การสร้างตาราง t1 และ t2 รวมทั้งดัชนีบน t1
  3. ขั้นตอนต่อไปคือการ เลือกครั้งแรกจาก t1 เนื่องจากมี แผนไม่พร้อมใช้งานสำหรับคำสั่งนี้ select กระบวนการเป็น recompiled เนื่องจากทั้งหมดของวัตถุมีอยู่ แผนสร้างขึ้นสำหรับตัวเลือกทั้งหมด คำสั่งในขั้นตอนในขณะนี้
  4. ส่วนที่เหลือของขั้นตอนดำเนินการโดยใช้แผนการ สร้างขึ้น เนื่องจากมีการเปลี่ยนแปลงที่ไม่มีการอ้างอิงวัตถุ ไม่มีไม่มี จำเป็นต้องคอมไพล์ใหม่ตามขั้นตอนต่อไป
หมายเหตุ:Executions ที่สอง และต่อมาทำให้การใช้ที่มีอยู่ สอบถามแผนและแคช และไม่ทำ recompilations ใด ๆ เลย กระบวนงานที่สร้าง เปลี่ยนแปลง หรือลบตารางที่ควรปรับเปลี่ยนเพื่อให้แน่ใจว่า คำสั่ง DDL ทั้งหมดจะอยู่ที่ตำแหน่งเริ่มต้นของกระบวนการ

Recompilations เนื่องจากการดำเนินงานของบางตารางชั่วคราว

การใช้ตารางชั่วคราวในกระบวนงานที่เก็บไว้อาจทำให้เกิดการ กระบวนงานที่เก็บไว้เพื่อ recompiled ทุกครั้งที่มีกระบวนการ ดำเนินการ

เมื่อต้องการหลีกเลี่ยงปัญหานี้ เปลี่ยนกระบวนงานที่เก็บไว้เพื่อให้เป็นไปตาม ข้อกำหนดดังต่อไปนี้:
  • คำสั่งทั้งหมดที่ประกอบด้วยชื่อของตารางชั่วคราว ให้อ้างอิงถึงตารางชั่วคราวที่สร้าง ในกระบวนงานที่เก็บไว้เดียวกัน และในที่ไม่มี การเรียกกระบวนงานที่เก็บไว้ที่เรียกว่า หรือในสายอักขระที่ดำเนินการโดยใช้การดำเนินการ คำชี้แจง หรือsp_executesqlกระบวนงานที่เก็บไว้
  • คำสั่งทั้งหมดที่ประกอบด้วยชื่อของตารางชั่วคราว ปรากฏตามไวยากรณ์หลังจากตารางชั่วคราวในกระบวนงานที่เก็บไว้ หรือ ทริกเกอร์
  • ไม่มีไม่มีคำชี้แจงประกาศเคอร์เซอร์เลือก คำสั่งอ้างอิงตารางชั่วคราว
  • คำสั่งทั้งหมดที่ประกอบด้วยชื่อของตารางใด ๆ ชั่วคราว นำหน้าคำชี้แจงปล่อยตารางที่อ้างอิงตารางชั่วคราว

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

การหลีกเลี่ยงการ Recompilation โดยใช้ตัวเลือกแผนเก็บไว้

แนะนำการใช้งานตารางชั่วคราวภายในกระบวนงานที่เก็บบาง complexities สำหรับอาจัดรูปแบบแบบสอบถาม จำนวนแถวและข้อมูลสถิติ แตกต่างกันของตารางสามารถไปอย่างมากตลอดอายุการใช้งานของที่เก็บไว้ การปฏิบัติตามขั้นตอน เพื่อให้แน่ใจว่า อาจัดรูปแบบที่ใช้แผนการที่ดีที่สุดในทั้งหมด กรณีที่เกี่ยวข้องกับตารางชั่วคราว อัลกอริทึมที่พิเศษถูกพัฒนาขึ้นเพื่อให้ข้อมูลเพิ่มเติม อื่นกับ recompilations อัลกอริทึมแจ้งว่า ถ้าเป็นตารางชั่วคราว สร้างขึ้นด้วยกระบวนงานที่เก็บไว้มีการเปลี่ยนแปลงมากกว่าหกครั้ง กระบวนการ จะเป็น recompiled เมื่อตารางชั่วคราวที่ใช้ในการอ้างอิงคำสั่งถัดไป

พิจารณาตัวอย่างต่อไปนี้:
drop procedure useKeepPlan 
go
create procedure useKeepPlan as
create table #t (a int, b char(3))
select * from #t
-- Make greater than 6 changes to #t
insert #t values (1, 'abc')
insert #t values (2, 'abc')
insert #t values (3, 'abc')
insert #t values (4, 'abc')
insert #t values (5, 'abc')
insert #t values (6, 'abc')
insert #t values (7, 'abc')
-- Now reference #t
select count(*) from #t 
--option (KEEP PLAN)
go
exec useKeepPlan
exec useKeepPlan
				
ในกรณีนี้ คุณจะเห็นเหตุการณ์ต่อไปนี้ในเว็บไซต์ของผู้สร้างโปรไฟล์สำหรับการ การปฏิบัติการที่สอง:

ยุบตารางนี้ขยายตารางนี้
คลาสเหตุการณ์ข้อความ
SP: เริ่มต้นuseKeepPlan
SP:StmtStartingสร้างตารางการ# t (int)
SP:StmtStarting-เจ็ดการแทรกคำสั่ง-
SP:StmtStartingเลือก count(*) จาก# t1
SP:RecompileuseKeepPlan
SP:StmtStartingเลือก count(*) จาก# t1
SP: เสร็จสมบูรณ์useKeepPlan

ขั้นตอนคือ recompiled ในเลือกที่เกิดขึ้น หลังจากการเปลี่ยนแปลงที่เจ็ดเพื่อ t #ตารางชั่วคราว

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

เก็บรักษาแผน เป็นสัดส่วน recompilations ของกระบวนงานที่เก็บไว้ที่เกิดจากการเปลี่ยนแปลงมากกว่าหก ชั่วคราวตารางภายในกระบวนการ และเปลี่ยนกลับไปมาตรฐาน อัลกอริทึมสำหรับ recompilation เนื่องจากการปรับเปลี่ยนแถวที่กล่าวถึงข้างต้นในการ ส่วนที่ "ครบกำหนด recompilations ชำระเพื่อปรับเปลี่ยนแถว" ของบทความนี้ เก็บรักษาแผน ป้องกันการ recompilations ทั้งหมด นั้นเพียงแค่ป้องกันปัญหาที่เกิดจาก การเปลี่ยนแปลงมากกว่าหกตารางชั่วคราวที่อ้างถึงในขั้นตอนการ ในการ ตัวอย่างข้างต้น ถ้าคุณลบข้อคิดเห็นจากบรรทัด "ตัวเลือก (เก็บแผนที่)" ใน กระบวนงานที่เก็บ การSP:Recompileเหตุการณ์จะไม่ถูกสร้างขึ้น

ถ้าคุณลบข้อคิดเห็น จาก "ตัว (เก็บแผน)" บรรทัดในรหัสข้างต้น และดำเนินการได้ คุณจะ ดูเหตุการณ์ต่อไปนี้ในเว็บไซต์ของผู้สร้างโปรไฟล์:

ยุบตารางนี้ขยายตารางนี้
คลาสเหตุการณ์ข้อความ
SP: เริ่มต้นuseKeepPlan
SP:StmtStartingสร้างตารางการ# t (int)
SP:StmtStarting-เจ็ดการแทรกคำสั่ง-
SP:StmtStartingเลือก count(*) จากตัวเลือก# t1 (เก็บไว้ การวางแผน)
SP: เสร็จสมบูรณ์useKeepPlan


หมายเหตุไม่มีไม่มีSP:Recompileเหตุการณ์

การตั้งค่า recompilations เนื่องจากการบางคำสั่งที่ใช้ในกระบวนงานที่เก็บไว้

ชุดที่ 5 เลือกต่อไปนี้ถูกกำหนดเป็นเงินตามค่าเริ่มต้น:
  • ANSI_DEFAULTS
  • ANSI_NULLS
  • ANSI_PADDING
  • ANSI_WARNINGS
  • CONCAT_NULL_YIELDS_NULL
ถ้าคุณเรียกใช้คำสั่งชุดเพื่อตั้งค่าตัวเลือกใดตัวเลือกเหล่านี้เพื่อ ปิด กระบวนงานที่เก็บไว้จะถูก recompiled ทุกครั้งที่เรียกใช้ เหตุผลสำหรับการ นี่คือว่า การเปลี่ยนแปลงตัวเลือกเหล่านี้อาจมีผลต่อผลลัพธ์ของแบบสอบถามที่ทริกเกอร์ recompilation

พิจารณาตัวอย่างรหัสต่อไปนี้:
Use pubs
drop procedure test_recompile
go

create procedure test_recompile as
Set ANSI_DEFAULTS OFF
Select au_lname, au_fname, au_id from authors
where au_lname like 'L%'
--Option (Keep Plan)
Go
				
ในกรณีนี้ คุณจะเห็นเหตุการณ์ต่อไปนี้ในเว็บไซต์ของผู้สร้างโปรไฟล์ของ SQL สำหรับ ดำเนินการทั้งหมดของกระบวนงานที่เก็บไว้:
+---------------------------------------------------+
| Event Class     | Text                            | 
+---------------------------------------------------+
| SP:Starting     | test_recompile                  | 
+---------------------------------------------------+
| SP:StmtStarting | Set ANSI_DEFAULTS OFF           | 
+---------------------------------------------------+
| SP:StmtStarting | select au_lname, au_fname, au_id| 
+---------------------------------------------------+
| SP:Recompile    | test_recompile                  | 
+---------------------------------------------------+
| SP:StmtStarting | select au_lname, au_fname, au_id| 
+---------------------------------------------------+
| SP:Completed    | test_recompile                  | 
+---------------------------------------------------+
				
แทนตัวเลือกการตั้งค่ากับหนึ่งในห้าตัวเลือกการแสดงไว้ ด้านบนจะแสดงผลลัพธ์เดียวกัน ยัง โดยใช้ตัวเลือกของแผนการเก็บไว้ที่นี่ จะไม่ช่วยให้คุณหลีกเลี่ยงการ recompilation ที่ได้เนื่องจากสาเหตุที่ recompilation จากคำสั่งชุด

วิธีแนะนำเพื่อหลีกเลี่ยงการ recompilation คือไม่ให้ ใช้คำสั่งชุดที่ห้าเหล่านี้ในการจัดเก็บไว้ กระบวนการ สำหรับข้อมูลเพิ่มเติม ให้ดูบทความต่อไปนี้ในการ ฐานความรู้ของ Microsoft:
294942PRB: ชุด CONCAT_NULL_YIELDS_NULL อาจทำให้ขั้นตอนการคอมไพล์ที่เก็บไว้
อย่างไรก็ตาม เป็นไม่แนะนำ เรียกใช้ชุด คำสั่งการตั้งค่าตัวเลือกการเชื่อมต่อกับค่าเหมือนกับที่เก็บไว้ ขั้นตอน นั้นสามารถยังหลีกคอมไพล์ ทำให้เป็น:
Set ANSI_DEFAULTS OFF

exec test_recompile
				
การติดตามของผู้สร้างโปรไฟล์ของ SQL จะแสดงเหตุการณ์ SP:Recompile เพิ่มเติม

ตารางต่อไปนี้แสดงรายการบางคำชี้แจงการตั้งค่าทั่วไป และหรือไม่ หรือ การเปลี่ยนแปลงคำชี้แจงของชุดในกระบวนงานที่เก็บไว้ไม่ทำให้เกิดการคอมไพล์:
ยุบตารางนี้ขยายตารางนี้
การตั้งค่าคำสั่งคอมไพล์ใหม่
ชุด quoted_identifierไม่มี
ชุด arithabortYes
ชุด ansi_null_dflt_onYes
ชุด ansi_defaultsYes
ชุด ansi_warningsYes
ชุด ansi_paddingYes
ชุด concat_null_yields_nullYes
ชุด numeric_roundabortไม่มี
ชุด nocountไม่มี
ชุด rowcountไม่มี
ชุด xact_abortไม่มี
ชุด implicit_transactionsไม่มี
ชุด arithignoreไม่มี
ชุด lock_timeoutไม่มี
ชุด fmtonlyไม่มี

การอ้างอิง

308737INF: วิธีการระบุสาเหตุของ Recompilation ในเหตุการณ์ SP:Recompile

สำหรับข้อมูลเกี่ยวกับการใช้ SQL Server ของผู้สร้างโปรไฟล์ ดู SQL Server Books Online

คุณสมบัติ

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

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

 

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