ความหลากหลายในเวลาแทรกจำนวนมาก

ดังนั้นฉันจึงมีกระบวนการแทรกจำนวนมากเพื่อนำข้อมูลจากตารางการแสดงละครของเราและย้ายไปยังดาต้ามาร์ตของเรา

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

โต๊ะค่อนข้างใหญ่ 587,162,986 ที่มีขนาดข้อมูล 201GB และ 49GB ของพื้นที่ดัชนี ดัชนีคลัสเตอร์สำหรับตารางคือ

CREATE CLUSTERED INDEX ImageData ON dbo.ImageData
(
    DOC_ID ASC,
    ACCT_NUM ASC,
    MasterID ASC
)

และคีย์หลักคือ:

ALTER TABLE dbo.ImageData 
ADD CONSTRAINT ImageData 
PRIMARY KEY NONCLUSTERED 
(
    ImageID ASC,
    DT_CRTE_DOC ASC
)

ตอนนี้เราพบปัญหาที่BULK INSERTSSIS ทำงานช้าอย่างไม่น่าเชื่อ 1 ชั่วโมงเพื่อแทรกล้านแถว แบบสอบถามที่เติมตารางนั้นเรียงลำดับแล้วแบบสอบถามที่เติมจะใช้เวลาไม่ถึงนาทีในการเรียกใช้

เมื่อกระบวนการทำงานฉันสามารถดูแบบสอบถามรอแทรกกลุ่มซึ่งจะใช้เวลาทุกที่ 5-20 PAGEIOLATCH_EXวินาทีและแสดงประเภทของการรอคอย กระบวนการสามารถทำได้ครั้งละINSERTประมาณหนึ่งพันแถวเท่านั้น

เมื่อวานนี้ในขณะที่ทดสอบกระบวนการนี้กับสภาพแวดล้อม UAT ของฉันฉันพบปัญหาเดียวกัน ฉันรันกระบวนการสองสามครั้งและพยายามระบุสาเหตุของการแทรกที่ช้านี้ ทันใดนั้นเองมันก็เริ่มทำงานภายใน 5 นาที ดังนั้นฉันจึงวิ่งไปอีกสองสามครั้งพร้อมผลลัพธ์เดียวกัน นอกจากนี้จำนวนของเม็ดมีดจำนวนมากที่รอเป็นเวลา 5 วินาทีหรือมากกว่านั้นจะลดลงนับร้อยเป็น 4

ตอนนี้มันน่างงงวยเพราะมันไม่เหมือนว่าเรามีกิจกรรมที่ต้องทำมากมาย

CPU ในช่วงเวลาที่ต่ำ

เวลาที่ช้าลงจะมีการรอดิสก์น้อยลง

เวลาแฝงของดิสก์เพิ่มขึ้นจริง ๆ ในระหว่างกรอบเวลาที่กระบวนการทำงานภายใน 5 นาที

และ IO ต่ำกว่ามากในช่วงเวลาที่กระบวนการนี้ทำงานได้ไม่ดี

ฉันได้ตรวจสอบแล้วและไม่มีการขยายไฟล์เนื่องจากไฟล์เต็มเพียง 70% ไฟล์บันทึกยังคงมี 50% ที่จะไป DB อยู่ในโหมดการกู้คืนอย่างง่าย DB มีกลุ่มไฟล์เพียงกลุ่มเดียว แต่กระจายใน 4 ไฟล์

ดังนั้นสิ่งที่ฉันสงสัยA:เหตุใดฉันจึงเห็นช่วงเวลารอคอยขนาดใหญ่บนเม็ดมีดเหล่านั้น B:เวทมนต์อะไรที่ทำให้มันวิ่งเร็วขึ้น?

ข้อความด้านข้าง มันทำงานเหมือนอึอีกครั้งในวันนี้

อัปเดตมันถูกแบ่งพาร์ติชันในปัจจุบัน อย่างไรก็ตามมันทำในวิธีที่โง่ที่สุด

CREATE PARTITION SCHEME [ps_Image] AS PARTITION [pf_Image] 
TO ([FG_Image], [FG_Image], [FG_Image], [FG_Image])

CREATE PARTITION FUNCTION [pf_Image](datetime) AS 
RANGE RIGHT FOR VALUES (
      N'2011-12-01T00:00:00.000'
    , N'2013-04-01T00:00:00.000'
    , N'2013-07-01T00:00:00.000'
);

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

ปรับปรุง 2 สิ่ง เหล่านี้คือภาพรวมรอเมื่อกระบวนการทำงานไม่ดี

นี่คือการรอในช่วงเวลาที่ฉันสามารถเรียกใช้กระบวนการทำงานได้ดี

ระบบย่อยหน่วยเก็บข้อมูลเป็น RAID แบบพ่วงต่อแบบโลคัลไม่มี SAN ที่เกี่ยวข้อง บันทึกอยู่ในไดรฟ์อื่น Raid Controller คือ PERC H800 ที่มีขนาดแคช 1 GB (สำหรับ UAT) Prod คือ PERC (810)

เราใช้การกู้คืนอย่างง่ายโดยไม่มีการสำรองข้อมูล มันถูกกู้คืนจากสำเนาการผลิตทุกคืน

นอกจากนี้เรายังได้ตั้งค่าIsSorted property = TRUEใน SSIS เนื่องจากข้อมูลเรียงลำดับแล้ว

sql-server sql-server-2012 ssis

— Zane
แหล่งที่มา

ASYNC_NETWORK_IOหมายความว่า SQL Server กำลังรอส่งแถวไปยังไคลเอนต์ ฉันสมมติว่าจะแสดงกิจกรรมของ SSIS ที่กินแถวจากตารางการแสดง

— Max Vernon

PAGEIOLATCH_EXและASYNC_IO_COMPLETIONกำลังแสดงว่ากำลังรับข้อมูลจากดิสก์ไปยังหน่วยความจำ นี่อาจเป็นตัวบ่งชี้ปัญหาของระบบย่อยดิสก์หรืออาจเป็นการแย่งชิงหน่วยความจำ SQL Server มีหน่วยความจำเท่าใด

— Max Vernon

ด้วยชื่อตารางของ ImageData คุณทำให้ฉันสงสัย - นิยามของตารางที่แท้จริงคืออะไร หากคุณกำลังดึงข้อมูล LOB คุณอาจได้รับการบัฟเฟอร์ลงดิสก์ (ซึ่งไปที่ BLOBTempStoragePath ซึ่งหากไม่ได้กำหนดไว้จะเป็นไดรฟ์ไดเรกทอรี% TEMP% ของผู้ใช้ที่กำลังดำเนินการหรือที่เรียกว่า C ไดรฟ์)

— billinkc

ไม่สามารถโพสต์คำจำกัดความของตารางได้ แต่เป็นข้อมูลที่เป็นเอกสารที่ถ่ายออกมา

— Zane

ฉันสงสัยว่ามันเป็นปัญหาการประมวลผลแบบขนาน ฉันขอแนะนำให้คุณปรับ MAXDOP ของคุณ (เริ่มจาก 1 ถึง 4) และดูว่าทุกอย่างเป็นไปอย่างไร ในทางตรงกันข้ามสำหรับวัตถุประสงค์ในการทดสอบฉันควรสร้างคำสั่ง BCP เพื่อแทนที่ SSIS และดูว่ามีความแตกต่างหรือไม่

— jyao

คำตอบ:

ฉันไม่สามารถชี้สาเหตุได้ แต่ฉันเชื่อว่าการเริ่มต้นแถวต่อแบทช์สำหรับการดำเนินการ BULK INSERT คือ "ทั้งหมด" การตั้งค่าขีด จำกัด ในแถวสามารถทำให้การดำเนินการย่อยง่ายขึ้นนั่นคือสาเหตุที่เป็นตัวเลือก (ที่นี่และกำลังดำเนินอยู่ฉันกำลังดูเอกสาร Transact-SQL "BULK INSERT" ดังนั้นจึงอาจเป็นไปได้สำหรับ SSIS)

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

ไม่ใช่เรื่องผิดที่จะมีฟังก์ชั่นพาร์ติชั่นที่วางส่วนแทรกปัจจุบันทั้งหมดลงในพาร์ติชั่นโต๊ะเดียว, แต่ฉันไม่เห็นว่ามันมีประโยชน์อย่างไรกับพาร์ติชั่นด้วยพาร์ติชั่นในกลุ่มไฟล์เดียวกัน. และการใช้วันที่และเวลาไม่ดีและจริง ๆ แล้วเสียสำหรับ datetime และ 'YYYY-MM-DD' โดยไม่มีสูตร CONVERT ที่ชัดเจนตั้งแต่ SQL Server 2008 (SQL อาจปฏิบัติเช่นนี้เป็น YYYY-DD-MM: อย่าล้อเล่น: อย่าตกใจ เพียงแค่เปลี่ยนเป็น 'YYYYMMDD' แก้ไข: หรือแปลง (วันที่, 'YYYY-MM-DDT00: 00: 00', 126) ฉันคิดว่าเป็น) แต่ฉันคิดว่าการใช้พร็อกซีสำหรับค่าวันที่ (ปีเป็น int หรือปี + ไตรมาส) เพื่อแบ่งพาร์ติชันจะทำงานได้ดีขึ้น

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

รู้สึกเหมือนการออกแบบที่แผนจะวางเนื้อหาของพาร์ติชัน 1 ในอนาคตและสร้างพาร์ติชันใหม่สำหรับข้อมูลใหม่เพิ่มเติม แต่ดูเหมือนว่าจะไม่เกิดขึ้นที่นี่ อย่างน้อยก็ไม่ได้เกิดขึ้นตั้งแต่ปี 2013

— Robert Carnegie
แหล่งที่มา

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

— Richard Herling
แหล่งที่มา