ผู้ขายต้องการเรียกใช้งาน MSDB ทุก ๆ 5 นาทีสำหรับแอปพลิเคชันธุรกิจ

เรามีผู้จำหน่ายบุคคลที่สามที่พยายามรวม 2 แอพพลิเคชั่นที่ต่างกันซึ่งทั้งคู่อยู่ในอินสแตนซ์ของ SQL Server ของเราด้วย 150+ ฐานข้อมูลอื่น ๆ และพวกเขาต้องการสร้างงาน MSDB เพื่อ "ซิงค์" แอพพลิเคชั่น ต้องการเรียกใช้ทุกนาที)

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

ฉันต้องการให้งาน MSDB สงวนไว้สำหรับงาน DBA ให้มากที่สุดเพื่อลดความยุ่งเหยิงที่นั่นและยังมีการสืบค้น MSDB ที่ช้าเมื่อดูประวัติงานด้วยงานแอคทีฟสุด ๆ เช่นนี้ (ซึ่งยังจมอยู่และเลื่อนประวัติงานสำคัญของ สิ่งที่สำคัญกว่าเช่นประวัติการสำรองข้อมูล) แต่แล้วอีกครั้งบางทีการตั้งค่าของฉันผิดและฉันต้องทำให้บางพื้นที่สำหรับ Application Tier ใน MSDB และพับแขนเสื้อของฉันและแก้ไขปัญหาประวัติงานสละเวลาตลอดไปในการโหลดเมื่อฉันต้องการเก็บรายการประวัติเพิ่มเติมเพื่อจับภาพ สิ่งสำคัญเช่นการสำรองข้อมูล (หรือล้างรายการงานที่ใช้งานมากเกินไป)

ปัญหาอื่นที่ฉันมีคือตอนนี้ฉันต้องให้สิทธิ์ผู้ดูแลระบบ "sysadmin" นี้แทนสิทธิ์ "dbo" เฉพาะบน DBs ของพวกเขาเท่านั้นเมื่อพวกเขาทำการอัปเกรดผ่าน GUI และหวังว่าพวกเขาจะไม่ระเบิดอินสแตนซ์ที่ภารกิจสำคัญของฉัน ฐานข้อมูลคือ (หนึ่งในข้อเสียของการรวม)

ฉันเดาว่าฉันสามารถใส่พวกเขาในอินสแตนซ์ "แยก" อื่นที่เราใส่ผู้ขายทั้งหมดที่เล่นไม่ดี แต่จากนั้นเราต้องกำหนดค่าแอปพลิเคชันใหม่ให้ชี้ไปที่อินสแตนซ์ SQL ใหม่ ( ถอนหายใจไม่น่าเสียดาย

ผู้ขายได้ส่งคืนข้อกังวลของฉันไปแล้วเกี่ยวกับวิธีการทริกเกอร์ที่ไม่ดี ดังนั้นฉัน "googled" บนนี้เล็กน้อยและว่างเปล่าขึ้นมา มีใครเห็นลิงก์ออกบ้าง "ดูเผด็จการ" ว่านี่เป็นความคิดที่ไม่ดีและฉันสามารถอ้างอิงได้หรือไม่ หรือฉันควรยอมรับแนวทางของพวกเขา?

ฉันไม่เชื่อว่าฉันเคยโพสต์ในฟอรัม sql ก่อนที่จะขอความช่วยเหลือดังนั้นหวังว่าคำถามของฉันจะถูกวางกรอบอย่างถูกต้อง

แก้ไข: เรากำลังเรียกใช้ SQL Server 2008 Enterprise R2 x64 SP1 (ขอบคุณที่ชี้ให้เห็นว่าฉันลืมพูดถึงรุ่น!) อืมหวังว่าพวกเขาไม่จำเป็นต้องเปลี่ยนสคริปต์อัพเกรด MSDB เมื่อเราไปเป็นเวอร์ชั่นที่ใหม่กว่า

ขอบคุณที่สละเวลา! รวย

IMO ผู้ขายของคุณกำลังติดตามอย่างถูกต้อง

งานเลเยอร์ของแอปพลิเคชันต้องการให้เขาทำซ้ำคุณสมบัติ SQL Agent ที่ไม่อยู่ในกล่อง (เช่นตรรกะไม่ให้ทำงานที่รันอยู่แล้วมาพร้อมกับโซลูชันการจัดเก็บความปลอดภัยและข้อมูลรับรองรวมผลลัพธ์ของงานด้วย การรายงานข้อผิดพลาดและการติดตามผลลัพธ์ใน SQL ฯลฯ ฯลฯ ฯลฯ ) และที่สำคัญที่สุดคือให้บริการสำรองข้อมูล / HA / DC สำหรับการจัดตารางเวลา คุณไม่ต้องการของคุณเรื่องการกู้คืนภัยพิบัติที่จะเป็น 'และหลังจากที่คุณเสร็จสิ้นการฟื้นตัวเซิร์ฟเวอร์การสแตนด์บายไปสร้างเหล่านี้ 50 NT งานจัดตารางเวลา' ดังนั้นเขาจึงถูกผลักดันกลับจากการใช้ตัวกำหนดตารางระบบมันไม่มีคุณสมบัติและความสามารถที่ Agent มี

เขายิ่งถูกกว่ามากในการผลักดันสิ่งกระตุ้นกลับ การแทนที่งานตามช่วงเวลาด้วยทริกเกอร์แบบซิงโครนัสจะเพิ่มเวลาในการตอบสนองการร้องขอเพิ่มการเชื่อมโยงและการมีเพศสัมพันธ์ (คิดว่าสคีมาเปลี่ยนแปลง ... ) เพิ่มความเสี่ยงในการหยุดทำงานเนื่องจากปัญหาการซิงค์ เพิ่มปัญหาการหยุดชะงักอย่างมาก (เนื่องจากมีการปรับปรุงข้ามระหว่างผู้ติดตาม / ผู้ติดตาม) และมีปัญหาอีกมากมาย

ทางออกที่ง่ายที่สุดคืองานของ Agent และmsdbไม่ได้สงวนไว้สำหรับ DBA วิธีแก้ปัญหาที่น่าสนใจมากขึ้นคือการใช้ตัวจับเวลาการสนทนาและการเปิดใช้งานภายในซึ่งจะมีข้อได้เปรียบกว่างานตัวแทนส่วนใหญ่เกิดจากการกักกัน (ทุกอย่างอยู่ในแอพ DB, คิดว่าทำมิเรอร์ล้มเหลว) ลังเลที่จะลองสิ่งที่ต้องใช้ความรู้เฉพาะทาง BTW ฉันหวังว่าคุณจะไม่ได้หมายถึงหนึ่งในงานทุก 5 นาทีต่อ DB

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

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

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

และไม่มีอะไรเลวร้ายอย่างแท้จริงเกี่ยวกับทริกเกอร์ แต่เช่นเดียวกับส่วนใหญ่ของ T-SQL เป็นไปได้มากที่จะเขียนโค้ดที่ทำงานได้อย่างน่ากลัว ฉันเขียนบทความเกี่ยวกับข้อผิดพลาดทั่วไปของตัวกระตุ้นถ้าสิ่งนั้นช่วยได้

การเขียนทริกเกอร์ที่ทำงานได้ดี