1. บทนำสู่ SQL Server การทำซ้ำ
1.1 คืออะไร SQL Server การจำลองแบบ?
SQL Server การจำลองข้อมูล (Replication) คือชุดเทคโนโลยีสำหรับการคัดลอกและกระจายข้อมูลและวัตถุในฐานข้อมูลจากฐานข้อมูลหนึ่งไปยังอีกฐานข้อมูลหนึ่ง จากนั้นทำการซิงโครไนซ์ระหว่างฐานข้อมูลเพื่อรักษาความสอดคล้อง คุณสมบัตินี้ช่วยให้คุณสามารถสร้างและดูแลรักษาสำเนาข้อมูลหลายชุดในเซิร์ฟเวอร์และสถานที่ต่างๆ เพื่อให้มั่นใจได้ถึงความพร้อมใช้งานและความน่าเชื่อถือของข้อมูล
1.2 วัตถุประสงค์และประโยชน์ของการจำลองแบบ
SQL Server การจำลองข้อมูลช่วยตอบสนองความต้องการทางธุรกิจที่สำคัญหลายประการ และให้ข้อได้เปรียบอย่างมากสำหรับการจัดการฐานข้อมูลและการกระจายข้อมูล:
- การกระจายข้อมูลไปยังสถานที่ต่างๆ: การทำสำเนาข้อมูลช่วยให้คุณสามารถแบ่งปันข้อมูลระหว่างสำนักงานภูมิภาคหรือสถานที่ต่างๆ ทั่วโลก ช่วยเพิ่มประสิทธิภาพการดำเนินงานโดยทำให้มั่นใจได้ว่าสามารถเข้าถึงข้อมูลที่ต้องการได้ในแต่ละพื้นที่ ซึ่งจะช่วยลดความหน่วงของเครือข่ายและให้ประสิทธิภาพที่ดีขึ้นสำหรับผู้ใช้ที่กระจายอยู่ตามภูมิศาสตร์ต่างๆ
- ความพร้อมใช้งานสูง และการกู้คืนระบบหลังภัยพิบัติ: การทำสำเนาข้อมูลสำคัญไว้ในเซิร์ฟเวอร์หลายเครื่องจะช่วยเพิ่มความเสถียรและป้องกันความเสียหายจากฮาร์ดแวร์และภัยพิบัติ ในกรณีที่เซิร์ฟเวอร์หลักล้มเหลว สำเนาข้อมูลสามารถใช้เป็นแหล่งข้อมูลสำรอง ช่วยลดเวลาหยุดทำงานและการสูญเสียข้อมูลได้
- การกระจายโหลดและความสามารถในการปรับขนาด: การจำลองข้อมูลจะกระจายการอ่านข้อมูลไปยังเซิร์ฟเวอร์หลายเครื่อง ป้องกันไม่ให้เซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งกลายเป็นคอขวด วิธีนี้ช่วยเพิ่มประสิทธิภาพของระบบและช่วยให้โครงสร้างพื้นฐานของคุณสามารถขยายขนาดในแนวนอนได้เมื่อข้อมูลและความต้องการของผู้ใช้เพิ่มขึ้น
- การรายงานและการวิเคราะห์แบบเรียลไทม์: การถ่ายโอนการประมวลผลรายงานและการวิเคราะห์ไปยังเซิร์ฟเวอร์จำลองช่วยลดภาระงานของฐานข้อมูลหลัก ผู้ใช้สามารถเรียกใช้คำสั่งวิเคราะห์ที่ซับซ้อนกับข้อมูลแบบเรียลไทม์ได้โดยไม่ส่งผลกระทบต่อระบบปฏิบัติการ ทำให้มั่นใจได้ทั้งประสิทธิภาพและความทันสมัยของข้อมูล
- การบูรณาการและการรวมข้อมูล: การทำสำเนาข้อมูลช่วยให้สามารถรวมข้อมูลจากแหล่งต่างๆ เข้าไว้ในมุมมองเดียวที่ครบถ้วน ซึ่งมีประโยชน์อย่างยิ่งสำหรับองค์กรที่มีสำนักงานสาขาหลายแห่งที่ต้องการรวบรวมข้อมูลที่สำนักงานใหญ่ หรือสำหรับการสร้างคลังข้อมูลส่วนกลางจากระบบปฏิบัติการที่กระจายอยู่ตามสถานที่ต่างๆ
2. SQL Server สถาปัตยกรรมและส่วนประกอบการจำลองแบบ
SQL Server สถาปัตยกรรมการจำลองข้อมูลประกอบด้วยส่วนประกอบที่เชื่อมต่อกันหลายส่วนซึ่งทำงานร่วมกันเพื่อกระจายและซิงโครไนซ์ข้อมูลทั่วทั้งโครงสร้างพื้นฐานฐานข้อมูลของคุณ ส่วนนี้จะสำรวจส่วนประกอบหลัก ได้แก่ ผู้เผยแพร่ ผู้จัดจำหน่าย ผู้รับข้อมูล สิ่งพิมพ์ บทความ การสมัครรับข้อมูล และตัวแทนที่ประสานงานการไหลของข้อมูลระหว่างส่วนประกอบเหล่านั้น:
- สำนักพิมพ์: สำนักพิมพ์คือ SQL Server อินสแตนซ์ที่โฮสต์ฐานข้อมูลตั้งแต่หนึ่งฐานขึ้นไปซึ่งมีข้อมูลที่จะถูกจำลองแบบ โดยทำหน้าที่เป็นแหล่งข้อมูลหลักในโครงสร้างการจำลองแบบ
- จำหน่าย: ผู้จัดจำหน่ายคือ SQL Server อินสแตนซ์ที่จัดการการไหลของข้อมูลระหว่างผู้เผยแพร่และผู้รับข้อมูล อินสแตนซ์ตัวกระจายข้อมูลจะโฮสต์ฐานข้อมูลการกระจายข้อมูล ซึ่งจัดเก็บข้อมูลเมตาและธุรกรรมการจำลองแบบ
- สมาชิก: สมาชิกคือ SQL Server อินสแตนซ์ที่รับและจัดเก็บข้อมูลที่จำลองมาจากผู้เผยแพร่ อินสแตนซ์ผู้รับข้อมูลเพียงตัวเดียวสามารถรองรับฐานข้อมูลผู้รับข้อมูลได้หลายฐาน โดยแต่ละฐานจะรับข้อมูลจากแหล่งเผยแพร่ที่แตกต่างกัน
- เผยแพร่: เอกสารเผยแพร่จะระบุว่าข้อมูลใดบ้างที่จะถูกทำสำเนา และจะเผยแพร่ข้อมูลนั้นให้แก่สมาชิกอย่างไร นอกจากนี้ยังจัดกลุ่มบทความที่เกี่ยวข้องเข้าด้วยกัน และกำหนดวิธีการทำสำเนาที่ใช้กับข้อมูลทั้งหมดที่อยู่ในนั้น
- บทความ: บทความ (Article) เป็นองค์ประกอบพื้นฐานของการจำลองข้อมูล โดยเป็นตัวแทนของวัตถุฐานข้อมูลแต่ละรายการที่จะถูกแจกจ่ายให้กับผู้รับข้อมูล (subscribers)
- การสมัคร: การสมัครสมาชิกเป็นการสร้างความสัมพันธ์ระหว่างสิ่งพิมพ์และผู้สมัครสมาชิก โดยกำหนดวิธีการและเวลาในการส่งข้อมูลไปยังฐานข้อมูลปลายทาง
- ตัวแทน: เอเจนต์คือกระบวนการเฉพาะทางที่ทำหน้าที่เคลื่อนย้ายและซิงโครไนซ์ข้อมูลระหว่างส่วนประกอบการจำลองข้อมูล
3. ประเภทของ SQL Server การทำซ้ำ
SQL Server มีรูปแบบการจำลองข้อมูลหลายประเภท ซึ่งแต่ละประเภทได้รับการออกแบบมาเพื่อสถานการณ์การกระจายข้อมูลและความต้องการทางธุรกิจที่เฉพาะเจาะจง การทำความเข้าใจลักษณะ ข้อดี และข้อจำกัดของแต่ละประเภทเป็นสิ่งสำคัญในการเลือกวิธีการที่เหมาะสมสำหรับสภาพแวดล้อมของคุณ
3.1 การจำลองสแนปช็อต
การจำลองแบบสแนปช็อตจะบันทึกภาพข้อมูลที่จะเผยแพร่ ณ เวลาที่กำหนด จากนั้นจึงส่งสำเนาที่สมบูรณ์แบบไปยังผู้รับข้อมูล โดยจะไม่ตรวจสอบการเปลี่ยนแปลงในภายหลังจนกว่าจะมีการสร้างสแนปช็อตครั้งถัดไป การจำลองแบบสแนปช็อตเป็นรูปแบบการจำลองที่ง่ายที่สุด ทำให้เหมาะสำหรับสถานการณ์ที่ข้อมูลเปลี่ยนแปลงไม่บ่อย หรือในกรณีที่ยอมรับได้ว่าข้อมูลอาจล้าสมัยเล็กน้อย
กรณีการใช้งานทั่วไป ได้แก่ การแจกจ่ายข้อมูลอ้างอิง เช่น รายการราคาหรืออัตราแลกเปลี่ยนที่อัปเดตเป็นระยะ การจัดเตรียมชุดข้อมูลเริ่มต้นสำหรับคลังข้อมูล และสถานการณ์ที่การอัปเดตข้อมูลทั้งหมดดีกว่าการติดตามการเปลี่ยนแปลงแต่ละรายการ ตัวอย่างเช่น บริษัทอาจใช้การจำลองแบบสแนปช็อตเพื่อแจกจ่ายแคตตาล็อกผลิตภัณฑ์ที่อัปเดตแล้วไปยังสำนักงานสาขาวันละครั้ง
ข้อดีหลักของการจำลองแบบสแนปช็อตคือความเรียบง่าย ความต้องการการบำรุงรักษาต่ำ และความสามารถในการจำลองข้อมูลโดยไม่ต้องใช้คีย์หลัก อย่างไรก็ตาม มันก็มีข้อเสียที่สำคัญหลายประการ ได้แก่ ผลกระทบสูงเมื่อสร้างสแนปช็อตเนื่องจากการล็อกตาราง ความล่าช้าสูงระหว่างการอัปเดต และความไม่มีประสิทธิภาพสำหรับชุดข้อมูลขนาดใหญ่หรือข้อมูลที่เปลี่ยนแปลงบ่อย การแก้ไขใดๆ ที่ทำที่ฝั่งผู้รับข้อมูลจะสูญหายไปเมื่อมีการใช้สแนปช็อตครั้งถัดไป
3.2 การจำลองแบบธุรกรรม
การจำลองแบบธุรกรรม (Transactional replication) ส่งมอบการเปลี่ยนแปลงจากผู้เผยแพร่ไปยังผู้รับข้อมูลได้เกือบเรียลไทม์ โดยการจำลองธุรกรรมแต่ละรายการเมื่อเกิดขึ้น เริ่มต้นด้วยการสร้างภาพรวมเริ่มต้นเพื่อกำหนดค่าพื้นฐาน จากนั้นจะตรวจสอบบันทึกธุรกรรมอย่างต่อเนื่องเพื่อหาการเปลี่ยนแปลงในบทความที่เผยแพร่แล้ว และส่งมอบให้กับผู้รับข้อมูลทีละน้อย
การจำลองแบบธุรกรรมเหมาะอย่างยิ่งสำหรับสถานการณ์ระหว่างเซิร์ฟเวอร์ที่ต้องการปริมาณงานสูงและความหน่วงต่ำ กรณีการใช้งานทั่วไป ได้แก่ การปรับปรุงความสามารถในการขยายขนาดและความพร้อมใช้งานโดยการถ่ายโอนการดำเนินการอ่านไปยังเซิร์ฟเวอร์ผู้รับ การสนับสนุนคลังข้อมูลและการรายงานด้วยข้อมูลแบบเรียลไทม์ การรวมข้อมูลจากหลายไซต์เข้าไว้ในตำแหน่งส่วนกลาง และการถ่ายโอนการประมวลผลแบบกลุ่มไปยังเซิร์ฟเวอร์เฉพาะ ตัวอย่างเช่น แพลตฟอร์มอีคอมเมิร์ซอาจใช้การจำลองแบบธุรกรรมเพื่อรักษาความสอดคล้องกันของข้อมูลสินค้าคงคลังในฐานข้อมูลระดับภูมิภาค
ข้อดีของการจำลองแบบธุรกรรม ได้แก่ การส่งข้อมูลที่มีความหน่วงต่ำ ประสิทธิภาพการประมวลผลสูงสำหรับปริมาณธุรกรรมขนาดใหญ่ และความสามารถในการแก้ไขข้อมูลที่ไม่ต้องจำลองที่ฝั่งผู้รับ ข้อเสีย ได้แก่ ความซับซ้อนที่มากกว่าเมื่อเทียบกับการจำลองแบบสแนปช็อต ความจำเป็นต้องใช้คีย์หลักในตารางที่จำลอง และความเป็นไปได้ที่การจำลองจะล้มเหลวหากเกิดข้อขัดแย้ง เช่น การละเมิดคีย์หลักที่ฝั่งผู้รับ
3.3 การจำลองแบบผสาน (Merge Replication)
การจำลองแบบผสาน (Merge replication) ออกแบบมาโดยเฉพาะสำหรับสภาพแวดล้อมที่ผู้รับข้อมูลจำเป็นต้องทำงานแบบออฟไลน์หรือมีการเชื่อมต่อที่ไม่เสถียร จากนั้นจึงซิงโครไนซ์การเปลี่ยนแปลงเมื่อมีการเชื่อมต่อ การจำลองประเภทนี้ช่วยให้สามารถเปลี่ยนแปลงข้อมูลได้ทั้งที่ผู้เผยแพร่และผู้รับข้อมูลโดยอิสระ ติดตามการเปลี่ยนแปลงโดยใช้ทริกเกอร์และตารางเมตาเดต้า และผสานการแก้ไขโดยอัตโนมัติระหว่างการซิงโครไนซ์
การจำลองแบบผสาน (Merge replication) ออกแบบมาสำหรับแอปพลิเคชันบนมือถือและสภาพแวดล้อมเซิร์ฟเวอร์แบบกระจายที่เกิดการเปลี่ยนแปลงโดยอัตโนมัติ กรณีการใช้งาน ได้แก่ ระบบอัตโนมัติสำหรับฝ่ายขายที่ผู้ใช้มือถือทำงานแบบออฟไลน์และซิงโครไนซ์ในภายหลัง ระบบ ณ จุดขายที่ทำงานอย่างอิสระและรวบรวมข้อมูลเป็นระยะ และแอปพลิเคชันแบบกระจายที่หลายไซต์จำเป็นต้องอัปเดตข้อมูลที่ใช้ร่วมกัน ตัวอย่างเช่น เครือข่ายค้าปลีกอาจใช้การจำลองแบบผสานเพื่อให้แต่ละสาขาสามารถจัดการสินค้าคงคลังในพื้นที่ขณะที่ซิงโครไนซ์กับระบบคลังสินค้าส่วนกลางได้
ข้อดีของการจำลองแบบผสาน (merge replication) ได้แก่ การรองรับสมาชิกอิสระที่สามารถทำการเปลี่ยนแปลงได้ ความทนทานต่อการเชื่อมต่อเครือข่ายที่ไม่เสถียร และการแก้ไขข้อขัดแย้งที่ยืดหยุ่น ส่วนข้อเสีย ได้แก่ ความซับซ้อนที่มากขึ้นในการตั้งค่าและการบำรุงรักษา ภาระด้านประสิทธิภาพจากการติดตามเมตาเดต้าและทริกเกอร์ การเพิ่มคอลัมน์ตัวระบุที่ไม่ซ้ำกันลงในตาราง และศักยภาพในการเกิดข้อขัดแย้งที่ต้องได้รับการจัดการและแก้ไข
3.4 การจำลองแบบ Peer-to-Peer
การจำลองแบบ Peer-to-peer สร้างขึ้นบนพื้นฐานของการจำลองแบบธุรกรรม และช่วยให้เซิร์ฟเวอร์หลายตัว (สามโหนดขึ้นไป) สามารถทำหน้าที่เป็น Peer ที่เท่าเทียมกัน โดยแต่ละโหนดทำหน้าที่ทั้งเป็นผู้เผยแพร่และผู้รับข้อมูลพร้อมกัน ในโครงสร้างนี้ โหนดทั้งหมดจะเก็บสำเนาข้อมูลที่เหมือนกัน และสามารถจัดการทั้งการอ่านและการเขียนข้อมูลได้ ทำให้เกิดสภาพแวดล้อมแบบมัลติมาสเตอร์แบบกระจายอย่างแท้จริง
การจำลองแบบ Peer-to-peer เหมาะสำหรับแอปพลิเคชันที่ต้องการขยายขนาดการอ่านข้อมูลและมีความพร้อมใช้งานสูง ตัวอย่างการใช้งาน ได้แก่ แอปพลิเคชันเว็บที่กระจายการสืบค้นแคตตาล็อกไปยังหลายโหนดในขณะที่ยังคงรักษาความสอดคล้องของข้อมูล สถานการณ์ที่ต้องการการบำรุงรักษาหรือการอัปเกรดโดยไม่ต้องหยุดการทำงานโดยการปิดโหนดทีละโหนด และแอปพลิเคชันระดับโลกที่มีศูนย์ข้อมูลในภูมิภาคต่างๆ ตัวอย่างเช่น องค์กรสนับสนุนซอฟต์แวร์ทั่วโลกอาจใช้การจำลองแบบ Peer-to-peer ระหว่างสำนักงานในเขตเวลาที่แตกต่างกัน เพื่อให้แต่ละแห่งสามารถเข้าถึงข้อมูลปัจจุบันได้ในระดับท้องถิ่น
ข้อดีของการจำลองข้อมูลแบบ Peer-to-Peer ได้แก่ ประสิทธิภาพการอ่านที่ดีขึ้นผ่านการขยายขนาด ความพร้อมใช้งานที่สูงขึ้นด้วยโหนดที่ใช้งานอยู่หลายโหนด และความสอดคล้องของข้อมูลแบบเรียลไทม์ ข้อเสีย ได้แก่ ความต้องการใช้เวอร์ชัน Enterprise Edition ความซับซ้อนในการจัดการโครงสร้างแบบหลายโหนด ความจำเป็นที่จะต้องมี Schema และข้อมูลที่เหมือนกันในทุกโหนด และความเป็นไปได้ที่จะเกิดข้อขัดแย้งเมื่อการดำเนินการเขียนไม่ได้ถูกแบ่งส่วนอย่างเหมาะสม
3.5 การจำลองแบบสองทิศทาง
การจำลองแบบสองทิศทาง (Bidirectional replication) เป็นรูปแบบการจำลองแบบธุรกรรมเฉพาะที่ออกแบบมาสำหรับสภาพแวดล้อมที่มีเซิร์ฟเวอร์สองตัวโดยเฉพาะ ซึ่งเซิร์ฟเวอร์ทั้งสองจำเป็นต้องแลกเปลี่ยนการเปลี่ยนแปลงระหว่างกัน เซิร์ฟเวอร์แต่ละตัวจะเผยแพร่ข้อมูลและสมัครรับข้อมูลเดียวกันจากเซิร์ฟเวอร์อีกตัว ทำให้เกิดการซิงโครไนซ์แบบสองทางที่เรียบง่าย แม้ว่าการจำลองแบบ Peer-to-Peer จะรองรับสองโหนดได้เช่นกัน แต่การจำลองแบบสองทิศทางจะให้ประสิทธิภาพที่ดีขึ้นสำหรับสถานการณ์เฉพาะนี้
การจำลองแบบสองทิศทางเหมาะสมสำหรับสถานการณ์ที่ต้องการเซิร์ฟเวอร์ที่ใช้งานอยู่สองเครื่องพร้อมข้อมูลที่ซิงโครไนซ์กัน เช่น การกำหนดค่าแบบแอคทีฟ-แอคทีฟเพื่อความพร้อมใช้งานสูง หรือแอปพลิเคชันที่กระจายอยู่ตามภูมิศาสตร์ซึ่งแต่ละไซต์ต้องการสิทธิ์ในการเขียนข้อมูลในพื้นที่ การออกแบบโครงสร้างนี้จำเป็นต้องมีการออกแบบแอปพลิเคชันอย่างระมัดระวังเพื่อแบ่งส่วนการอัปเดตข้อมูลและป้องกันความขัดแย้ง
ข้อดีได้แก่ ประสิทธิภาพที่เหมาะสมที่สุดสำหรับสถานการณ์ที่มีเซิร์ฟเวอร์สองตัว การกำหนดค่าที่ง่ายกว่าเมื่อเทียบกับการจำลองแบบเพียร์ทูเพียร์ การซิงโครไนซ์แบบเรียลไทม์ และค่าใช้จ่ายในการทำงานที่ต่ำกว่าการจำลองแบบผสาน ข้อเสียได้แก่ ข้อจำกัดที่ต้องใช้เซิร์ฟเวอร์เพียงสองตัวเท่านั้น ขาดการแก้ไขข้อขัดแย้งในตัวซึ่งต้องอาศัยการออกแบบแอปพลิเคชันอย่างระมัดระวัง และความจำเป็นในการใช้กลยุทธ์การแบ่งพาร์ติชันที่เหมาะสมเพื่อป้องกันข้อขัดแย้ง
3.6 การสมัครสมาชิกที่สามารถอัปเดตได้
การสมัครสมาชิกที่สามารถอัปเดตได้นั้นช่วยขยายการจำลองแบบธุรกรรมเพื่อให้ผู้รับข้อมูลสามารถทำการเปลี่ยนแปลงข้อมูลที่จำลองไว้เป็นครั้งคราว ซึ่งการเปลี่ยนแปลงเหล่านั้นจะถูกส่งกลับไปยังผู้เผยแพร่และผู้รับข้อมูลรายอื่น ๆ แตกต่างจากการจำลองแบบผสานหรือโครงสร้างแบบเพียร์ทูเพียร์ที่ออกแบบมาสำหรับการอัปเดตแบบสองทิศทางบ่อยครั้ง การสมัครสมาชิกที่สามารถอัปเดตได้นั้นมีไว้สำหรับสถานการณ์ที่การไหลของข้อมูลหลักเป็นแบบทางเดียว (จากผู้เผยแพร่ไปยังผู้รับข้อมูล) แต่ผู้รับข้อมูลจำเป็นต้องทำการแก้ไขหรืออัปเดตเป็นครั้งคราว
การสมัครรับข้อมูลที่สามารถอัปเดตได้นั้นเหมาะสมกับสถานการณ์ที่การอัปเดตส่วนใหญ่เกิดขึ้นที่ผู้เผยแพร่ แต่จำเป็นต้องมีการอัปเดตเป็นครั้งคราวที่ผู้รับข้อมูล เช่น สำนักงานภาคสนามที่ส่วนใหญ่อ่านข้อมูล แต่จำเป็นต้องทำการแก้ไขหรืออัปเดตในระดับท้องถิ่น โครงสร้างดังกล่าวจำเป็นต้องมีการวางแผนอย่างรอบคอบเพื่อลดความขัดแย้งและรับประกันความสอดคล้องของข้อมูล
ข้อดีหลักๆ ได้แก่ การอนุญาตให้ดำเนินการเขียนข้อมูลได้ในขอบเขตจำกัดที่ฝั่งผู้รับข้อมูล ในขณะที่ยังคงรักษาคุณลักษณะด้านประสิทธิภาพของการจำลองแบบธุรกรรมไว้ได้ ข้อเสีย ได้แก่ ความซับซ้อนที่เพิ่มขึ้น โอกาสเกิดข้อขัดแย้งที่ต้องแก้ไข ค่าใช้จ่ายด้านประสิทธิภาพจากโปรโตคอลการยืนยันสองขั้นตอนในโหมดการอัปเดตทันที และข้อกำหนดที่ว่าตารางที่จำลองทั้งหมดต้องมีคีย์หลัก
3.7 การเปรียบเทียบการจำลองแบบต่างๆ
| ประเภทการจำลองแบบ | เวลาอัปเดต | จำนวนผู้เผยแพร่ | ทิศทาง | ใช้สถานการณ์สมมติ |
|---|---|---|---|---|
| ภาพย่อ | เจาะจงเวลา | 1 | ทิศทางเดียว (ผู้เผยแพร่ → ผู้ติดตาม) | ข้อมูลอ้างอิงที่เปลี่ยนแปลงไม่บ่อยนัก (รายการราคา อัตราแลกเปลี่ยน) |
| การทำธุรกรรม | ใกล้เวลาจริง | 1 | ทิศทางเดียว (ผู้เผยแพร่ → ผู้ติดตาม) | สถานการณ์ที่มีปริมาณงานสูง (สินค้าคงคลังอีคอมเมิร์ซ, คลังข้อมูล, การรายงาน) |
| ผสาน | เป็นระยะ (เมื่อเชื่อมต่อแล้ว) | 1 | การสื่อสารสองทิศทาง (ผู้เผยแพร่ ↔ ผู้รับข้อมูล) | แอปพลิเคชันบนมือถือ, พนักงานที่ทำงานนอกสถานที่ (ระบบอัตโนมัติสำหรับฝ่ายขาย, บริการภาคสนาม) |
| Peer-to-Peer | ใกล้เวลาจริง | หลายรายการ (3 รายการขึ้นไป) | สองทิศทาง (ทุกโหนด) | การใช้งานศูนย์ข้อมูลหลายแห่งทั่วโลก (สำนักงานทั่วโลกที่มีสิทธิ์เข้าถึงข้อมูลแบบอ่านและเขียนในแต่ละพื้นที่) |
| แบบสองทิศทาง | ใกล้เวลาจริง | 2 | การสื่อสารแบบสองทาง (ทั้งสองเซิร์ฟเวอร์) | การกำหนดค่าแบบแอคทีฟ-แอคทีฟสองศูนย์ข้อมูล (ความพร้อมใช้งานสูงแบบสองไซต์) |
| การสมัครสมาชิกที่สามารถอัปเดตได้ | ใกล้เวลาจริง | 1 | โดยหลักแล้วเป็นการอัปเดตทิศทางเดียว (มีการอัปเดตย้อนกลับบ้างเป็นครั้งคราว) | สำนักงานสาขาส่วนใหญ่มีหน้าที่อ่านข้อมูล แต่มีการปรับปรุงแก้ไขบ้างเป็นครั้งคราว (แก้ไขข้อผิดพลาดในท้องถิ่น) |
4. การตั้งค่า Setting SQL Server การทำซ้ำ
4.1 คุณสมบัติเบื้องต้นและข้อกำหนด
4.1.1 ข้อกำหนดด้านซอฟต์แวร์
SQL Server การจำลองต้องใช้สิ่งที่เข้ากันได้ SQL Server เวอร์ชันต่างๆ จะต้องเหมือนกันในทุกผู้เข้าร่วมในโทโพโลยี เวอร์ชันของผู้จัดจำหน่ายจะต้องเท่ากับหรือสูงกว่าเวอร์ชันของผู้เผยแพร่ และผู้รับข้อมูลสามารถมีเวอร์ชันห่างจากผู้เผยแพร่ได้ไม่เกินสองเวอร์ชัน ตัวอย่างเช่น SQL Server สำนักพิมพ์ปี 2016 สามารถจำลองแบบได้ SQL Server ผู้สมัครสมาชิกปี 2012, 2014, 2016, 2017 หรือ 2019
4.1.2 ข้อกำหนดด้านการอนุญาต
การกำหนดค่าการจำลองข้อมูลจำเป็นต้องมีสิทธิ์เฉพาะในแต่ละระดับ สมาชิกของบทบาทเซิร์ฟเวอร์คงที่ sysadmin สามารถดำเนินการกำหนดค่าการจำลองข้อมูลทั้งหมดได้ สำหรับสิทธิ์ที่ละเอียดกว่านั้น ผู้ใช้จำเป็นต้องเป็นสมาชิกของบทบาทฐานข้อมูล db_owner สำหรับฐานข้อมูลผู้เผยแพร่และผู้รับข้อมูล
4.2 ขั้นตอนที่ 1: กำหนดค่าการแจกจ่าย
การกำหนดค่าการแจกจ่ายเป็นขั้นตอนแรกในการตั้งค่า SQL Server การจำลองแบบ
เพื่อกำหนดค่าการแจกจ่ายโดยใช้ SQL Server สตูดิโอการจัดการ:
- เชื่อมต่อกับไฟล์ SQL Server ตัวอย่างใน SQL Server สตูดิโอการจัดการ
- ใน Object Explorer ให้คลิกขวาที่ การทำซ้ำ และเลือก กำหนดค่าการแจกจ่าย.
- ในตัวช่วยสร้างการกำหนดค่าการแจกจ่าย ให้คลิก ถัดไป ในหน้าต้อนรับ
- เกี่ยวกับ ผู้จัดจำหน่าย ในหน้านี้ โปรดเลือกตัวเลือกใดตัวเลือกหนึ่งต่อไปนี้ตามความต้องการด้านโครงสร้างเครือข่ายของคุณ:
- ผู้จัดจำหน่ายในพื้นที่: เลือก “ServerName จะทำหน้าที่เป็นผู้จัดจำหน่ายของตัวเอง” SQL Server จะสร้างฐานข้อมูลการแจกจ่ายและบันทึกข้อมูล” หากคุณต้องการให้ผู้เผยแพร่และผู้แจกจ่ายทำงานบนอินสแตนซ์เดียวกัน (อินสแตนซ์ปัจจุบัน) การกำหนดค่านี้ตั้งค่าได้ง่ายกว่าและเหมาะสำหรับสภาพแวดล้อมขนาดเล็กหรือเมื่อความหน่วงของเครือข่ายระหว่างผู้เผยแพร่และผู้แจกจ่ายอาจทำให้เกิดปัญหา
- ผู้จัดจำหน่ายระยะไกลเลือก “ใช้เซิร์ฟเวอร์ต่อไปนี้เป็นผู้จัดจำหน่าย” แล้วคลิก เพิ่ม หากต้องการถ่ายโอนกระบวนการกระจายข้อมูลไปยังอินสแตนซ์แยกต่างหาก ให้ระบุเซิร์ฟเวอร์ตัวกระจายข้อมูลระยะไกล การกำหนดค่านี้ช่วยเพิ่มประสิทธิภาพเมื่อปริมาณการจำลองข้อมูลสูง โดยการกระจายภาระงานไปยังเซิร์ฟเวอร์หลายเครื่อง คุณจะต้องระบุชื่อตัวกระจายข้อมูลระยะไกลและรหัสผ่านที่ผู้เผยแพร่จะใช้ในการเชื่อมต่อกับตัวกระจายข้อมูล
- คลิก ถัดไป เพื่อระบุตำแหน่งโฟลเดอร์สแนปช็อต ให้ใช้เส้นทาง UNC (เช่น \\servername\share\folder) แทนเส้นทางภายในเครื่อง เพื่อให้มั่นใจได้ว่าสามารถเข้าถึงได้ผ่านเครือข่าย
- เกี่ยวกับ ฐานข้อมูลการแจกจ่าย ในหน้านี้ ให้ยอมรับชื่อฐานข้อมูลการแจกจ่ายเริ่มต้น (โดยทั่วไปคือ “distribution”) หรือระบุชื่อที่กำหนดเอง จากนั้นกำหนดค่าตำแหน่งของไฟล์ข้อมูลและไฟล์บันทึก
- เกี่ยวกับ สำนักพิมพ์ ตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ปัจจุบันถูกเปิดใช้งานเป็นผู้เผยแพร่ หากคุณกำหนดค่าเซิร์ฟเวอร์ปัจจุบันเป็นผู้จัดจำหน่าย คุณสามารถเพิ่มผู้เผยแพร่เพิ่มเติมที่จะใช้ผู้จัดจำหน่ายนี้ได้
- ตรวจสอบขั้นตอนการทำงานของตัวช่วยสร้างและคลิก เสร็จสิ้น เพื่อกำหนดค่าการแจกจ่าย
4.3 ขั้นตอนที่ 2: สร้างเอกสารเผยแพร่
หลังจากกำหนดค่าการกระจายข้อมูลแล้ว ขั้นตอนต่อไปคือการสร้างการเผยแพร่ที่จะกำหนดว่าวัตถุข้อมูลใดบ้างที่จะถูกจำลองไปยังผู้รับข้อมูล
เพื่อสร้างสิ่งพิมพ์โดยใช้ SQL Server สตูดิโอการจัดการ:
- ใน Object Explorer ให้ขยาย การทำซ้ำ โฟลเดอร์
- คลิกขวาที่ สิ่งพิมพ์ท้องถิ่น และเลือก สิ่งพิมพ์ใหม่.
- โปรแกรมช่วยสร้างสิ่งพิมพ์ใหม่จะเริ่มทำงาน คลิกเลย ถัดไป ในหน้าต้อนรับ
- เลือกฐานข้อมูลที่คุณต้องการเผยแพร่จากรายการ ฐานข้อมูลสิ่งพิมพ์ หน้านี้จะช่วยให้สามารถเผยแพร่ข้อมูลไปยังฐานข้อมูลที่เลือกได้โดยอัตโนมัติ
- เกี่ยวกับ ประเภทสิ่งพิมพ์ ในหน้าดังกล่าว ให้เลือกประเภทการจำลองข้อมูล: สิ่งพิมพ์ Snapshot, สิ่งพิมพ์เชิงธุรกรรม, การตีพิมพ์แบบ Peer-to-Peerหรือ การรวมสิ่งพิมพ์.
- เกี่ยวกับ บทความ ขยายหน้า ตาราง เลือกโหนดและตารางที่จะรวมเป็นบทความ
- ขยายเพิ่มเติมได้ตามต้องการ วิธีการจัดเก็บ, เข้าชมหรือประเภทวัตถุอื่นๆ เพื่อรวมบทความเพิ่มเติม
- คลิก คุณสมบัติของบทความ เพื่อกำหนดค่าการกรองหรือการตั้งค่าเฉพาะบทความอื่นๆ
- เกี่ยวกับ กรองแถวในตาราง ในหน้าถัดไป ให้เพิ่มตัวกรองแถวหากจำเป็น
- เกี่ยวกับ ตัวแทนสแนปช็อต ในหน้านี้ ให้เลือกเวลาที่จะสร้างสแนปช็อต: ทันที ในเวลาที่กำหนด หรือตามตารางเวลา
- เกี่ยวกับ เจ้าหน้าที่รักษาความปลอดภัย ในหน้านี้ ให้ระบุบริบทด้านความปลอดภัยสำหรับ Snapshot Agent
- เกี่ยวกับ การกระทำของพ่อมด ใหเลือก สร้างสิ่งพิมพ์.
- ระบุชื่อสิ่งพิมพ์แล้วคลิก เสร็จสิ้น.
4.4 ขั้นตอนที่ 3: สร้างการสมัครสมาชิก
หลังจากสร้างสิ่งพิมพ์แล้ว ขั้นตอนต่อไปคือการสร้างการสมัครรับข้อมูลที่เชื่อมโยงสิ่งพิมพ์กับฐานข้อมูลผู้สมัครรับข้อมูล
การสมัครรับข้อมูลสามารถแบ่งออกเป็น การสมัครรับข้อมูลแบบพุช (จัดการโดยผู้จัดจำหน่าย) หรือการสมัครรับข้อมูลแบบพูล (จัดการโดยผู้สมัครรับข้อมูล) ความแตกต่างที่สำคัญคือ ตำแหน่งที่คุณสร้างการสมัครรับข้อมูลและตำแหน่งตัวแทนที่คุณเลือก ซึ่งจะเป็นตัวกำหนดการทำงานของการสมัครรับข้อมูล (พุชหรือพูล)
สำหรับการสมัครรับข้อมูลแบบพุช (จัดการโดยผู้จัดจำหน่าย):
- เกี่ยวกับ สำนักพิมพ์ เซิร์ฟเวอร์ ขยาย การทำซ้ำ -> สิ่งพิมพ์ท้องถิ่น.
- คลิกขวาที่สิ่งพิมพ์แล้วเลือก สมัครสมาชิกใหม่.
สำหรับการสมัครรับข้อมูลแบบดึงข้อมูล (Pull Subscription) (จัดการโดยสมาชิก):
- เกี่ยวกับ สมาชิก เซิร์ฟเวอร์ ขยาย การทำซ้ำ, คลิกขวา การสมัครสมาชิกในพื้นที่และเลือก สมัครสมาชิกใหม่.
- เกี่ยวกับ สิ่งพิมพ์ หน้าคลิก หา SQL Server สำนักพิมพ์ และเชื่อมต่อกับเซิร์ฟเวอร์ของผู้เผยแพร่
ขั้นตอนการใช้งานตัวช่วยสร้างทั่วไปสำหรับทั้งสองประเภทการสมัครสมาชิก:
- ในตัวช่วยสร้างการสมัครสมาชิกใหม่ ให้คลิก ถัดไป ในหน้าต้อนรับ
- เลือกสิ่งพิมพ์แล้วคลิก ถัดไป.
- เกี่ยวกับ ที่ตั้งตัวแทนจำหน่าย ในหน้าถัดไป ให้เลือกสถานที่ตั้งของตัวแทน:
- การสมัครรับข้อมูลแบบพุช: เลือก “เรียกใช้เอเจนต์ทั้งหมดที่ตัวกระจายสัญญาณ” – ตัวกระจายสัญญาณจะส่งการเปลี่ยนแปลงไปยังผู้สมัครรับข้อมูล
- ดึงการสมัครสมาชิก: เลือก “เรียกใช้เอเจนต์แต่ละตัวที่ผู้รับข้อมูล” – ผู้รับข้อมูลแต่ละรายจะดึงการเปลี่ยนแปลงจากตัวกระจายข้อมูล
- เกี่ยวกับ สมาชิก ในหน้านั้น ให้เลือกเซิร์ฟเวอร์สมาชิกที่มีอยู่ หรือคลิก เพิ่มสมาชิก เพื่อเพิ่มรายการใหม่
- สำหรับผู้สมัครใช้บริการแต่ละราย ให้เลือกฐานข้อมูลปลายทาง หรือสร้างฐานข้อมูลใหม่ หมายเหตุ: ฐานข้อมูลผู้สมัครรับข้อมูลต้องแตกต่างจากฐานข้อมูลผู้เผยแพร่ แม้ว่าจะใช้ชื่อเดียวกันก็ตาม SQL Server ตัวอย่าง.
- เกี่ยวกับ ความปลอดภัยของตัวแทนจำหน่าย ในหน้านั้น ให้คลิกปุ่มคุณสมบัติสำหรับแต่ละการสมัครใช้งานเพื่อกำหนดค่าบริบทด้านความปลอดภัย
- เกี่ยวกับ ตารางการซิงโครไนซ์ ในหน้านี้ ให้เลือกการซิงโครไนซ์แบบต่อเนื่องหรือการซิงโครไนซ์ตามกำหนดเวลา
- เกี่ยวกับ เริ่มต้นการสมัครรับข้อมูล ใหเลือก ทันที เพื่อเริ่มต้นการทำงานระหว่างการดำเนินการวิซาร์ดเสร็จสิ้น หรือ ในการซิงโครไนซ์ครั้งแรก.
- ตรวจสอบขั้นตอนการทำงานของวิซาร์ดแล้วคลิก เสร็จสิ้น.
5. การติดตามและจัดการ SQL Server การทำซ้ำ
5.1 การตรวจสอบการจำลองข้อมูลด้วย Replication Monitor
เพื่อเปิดใช้งาน Replication Monitor:
- In SQL Server สตูดิโอการจัดการ ขยาย การทำซ้ำ ใน Object Explorer
- คลิกขวาที่ การทำซ้ำ และเลือก เปิดใช้งานตัวตรวจสอบการจำลอง.
- หากไม่มีสำนักพิมพ์ใดลงทะเบียนไว้ โปรดคลิกที่นี่ เพิ่มผู้เผยแพร่ ในบานหน้าต่างด้านซ้าย
- Choose เพิ่ม SQL Server สำนักพิมพ์ และเชื่อมต่อกับเซิร์ฟเวอร์ของผู้เผยแพร่
- สำนักพิมพ์จะปรากฏในช่องด้านซ้าย พร้อมโหนดที่สามารถขยายได้สำหรับสิ่งพิมพ์และการสมัครรับข้อมูล
5.2 การติดตามประสิทธิภาพ
5.2.1 ความหน่วงของจอภาพ
ความหน่วงในการจำลองข้อมูล คือช่วงเวลาที่เกิดการเปลี่ยนแปลงที่ฝั่งผู้เผยแพร่ข้อมูล และการเปลี่ยนแปลงนั้นถูกนำไปใช้ที่ฝั่งผู้รับข้อมูล ตรวจสอบความหน่วงนี้เพื่อให้มั่นใจว่าข้อมูลมีความทันสมัยตรงตามความต้องการทางธุรกิจ
ใช้ Replication Monitor เพื่อดูเมตริกความหน่วงในแท็บ All Subscriptions คอลัมน์ Latency แสดงค่าความหน่วงเฉลี่ยเป็นวินาที สำหรับการจำลองแบบธุรกรรม โทเค็น Tracer จะให้การวัดความหน่วงที่แม่นยำยิ่งขึ้นโดยการแทรกธุรกรรมตัวบ่งชี้ที่ติดตามไปตลอดทั้งไปป์ไลน์การจำลอง
วิธีใช้โทเค็นติดตาม:
- ใน Replication Monitor ให้เลือกการเผยแพร่แบบธุรกรรม
- คลิก โทเค็นติดตาม แถบ
- คลิก ใส่ตัวติดตาม เพื่อแทรกธุรกรรมบ่งชี้
- ติดตามการเคลื่อนที่ของโทเค็นตั้งแต่ต้นทางจนถึงปลายทาง (จากผู้เผยแพร่) และปลายทาง (ผู้รับ)
- ตรวจสอบระยะเวลาที่ใช้ในแต่ละช่วงเพื่อระบุจุดที่เป็นปัญหาคอขวด
5.2.2 การตรวจสอบปริมาณงาน
ปริมาณข้อมูลที่ส่งผ่าน (Throughput) คือปริมาณข้อมูลที่ถูกจำลองในช่วงเวลาหนึ่ง โดยทั่วไปจะแสดงเป็นจำนวนธุรกรรมต่อวินาที หรือจำนวนคำสั่งต่อวินาที ตรวจสอบปริมาณข้อมูลที่ส่งผ่านเพื่อให้แน่ใจว่าการจำลองข้อมูลสามารถรองรับกิจกรรมของผู้เผยแพร่ได้ทัน
แม้ว่า Replication Monitor จะแสดงสถานะการซิงโครไนซ์ขั้นพื้นฐาน แต่จะไม่แสดงอัตราการส่งมอบและเมตริกปริมาณงานโดยละเอียดในส่วนติดต่อผู้ใช้แบบกราฟิก (GUI) ต้องใช้คำสั่ง T-SQL กับฐานข้อมูลการกระจายเพื่อตรวจสอบปริมาณงาน:
USE distribution
GO
-- Direct join to avoid subquery
SELECT TOP 20
h.time AS [Time],
a.name AS [Agent Name],
h.runstatus AS [Status],
h.delivered_transactions AS [Delivered Transactions],
h.delivered_commands AS [Delivered Commands],
h.delivery_rate AS [Delivery Rate (commands/sec)],
h.delivery_latency AS [Delivery Latency (ms)],
h.comments AS [Comments]
FROM MSdistribution_history h
JOIN MSdistribution_agents a ON h.agent_id = a.id
WHERE a.name LIKE '%MyPublication2%'
AND h.runstatus IN (2, 3, 4, 6)
ORDER BY h.time DESC
GO
รหัสสถานะ: 1 = เริ่มต้น, 2 = กำลังดำเนินการ, 3 = สำเร็จ, 4 = ว่าง, 5 = ลองใหม่, 6 = ล้มเหลว เปรียบเทียบอัตราการส่งกับอัตราการทำธุรกรรมของผู้เผยแพร่เพื่อระบุสถานการณ์ที่การจำลองข้อมูลล่าช้า ตัวนับประสิทธิภาพใน ตัวตรวจสอบประสิทธิภาพของ Windows ระบุตัวชี้วัดปริมาณงานเพิ่มเติมสำหรับตัวแทนการจำลองแบบแต่ละตัว
5.2.3 การระบุจุดคอขวด
ปัญหาคอขวดในการจำลองข้อมูลอาจเกิดขึ้นได้หลายจุดในโครงสร้างข้อมูล ที่ฝั่งผู้เผยแพร่ข้อมูล เวลาในการสร้างสแนปช็อตที่นานเกินไป หรือความล่าช้าของ Log Reader Agent อาจบ่งชี้ถึงข้อจำกัดด้านทรัพยากร ตรวจสอบการใช้งาน CPU หน่วยความจำ และการรับส่งข้อมูลดิสก์บนฝั่งผู้เผยแพร่ข้อมูลในระหว่างกระบวนการจำลองข้อมูล
ที่ศูนย์กระจายสินค้า ให้ตรวจสอบจำนวนธุรกรรมที่สะสมอยู่ในฐานข้อมูลการกระจายสินค้า หากมีคำสั่งที่ยังไม่ได้กระจายจำนวนมาก แสดงว่าศูนย์กระจายสินค้าไม่สามารถส่งมอบสินค้าได้ทันเวลา ตรวจสอบทรัพยากรเซิร์ฟเวอร์ของศูนย์กระจายสินค้า และพิจารณาใช้ศูนย์กระจายสินค้าแบบเฉพาะทางระยะไกลสำหรับกรณีที่มีปริมาณงานสูง
ที่ฝั่งผู้รับข้อมูล การเปลี่ยนแปลงอาจแสดงผลช้าเนื่องจากทรัพยากรไม่เพียงพอ ดัชนีไม่ครบ หรือข้อจำกัดที่ทำให้การแทรกข้อมูลช้าลง ควรตรวจสอบการใช้ทรัพยากรและประสิทธิภาพการสืบค้นข้อมูลของฝั่งผู้รับข้อมูลขณะที่ Distribution Agent ทำงานอยู่ ข้อจำกัดด้านแบนด์วิดท์ของเครือข่ายระหว่างส่วนประกอบต่างๆ ก็เป็นสาเหตุของปัญหาคอขวด โดยเฉพาะอย่างยิ่งสำหรับข้อมูลปริมาณมาก
5.3 การจัดการเอเจนต์การจำลองข้อมูล
5.3.1 การเริ่มต้นและหยุดเอเจนต์
วิธีการเริ่มหรือหยุดเอเจนต์การจำลองข้อมูล:
- In SQL Server สตูดิโอการจัดการ ขยาย SQL Server ตัวแทน -> งาน.
- ค้นหางานตัวแทนการจำลองข้อมูล (โดยทั่วไปชื่อจะระบุข้อมูลการเผยแพร่และผู้รับข้อมูล)
- คลิกขวาที่งานแล้วเลือก เริ่มงาน or หยุดงาน.
5.3.2 การกำหนดค่าโปรไฟล์เอเจนต์
โปรไฟล์ของเอเจนต์ประกอบด้วยชุดพารามิเตอร์ที่ควบคุมพฤติกรรมของเอเจนต์ SQL Server มีโปรไฟล์เริ่มต้นที่ปรับให้เหมาะสมสำหรับสถานการณ์ทั่วไป และคุณสามารถสร้างโปรไฟล์แบบกำหนดเองสำหรับความต้องการเฉพาะได้
วิธีการแก้ไขโปรไฟล์เอเจนต์:
- ใน Object Explorer ให้ขยาย การทำซ้ำ.
- คลิกขวาที่ การทำซ้ำ และเลือก คุณสมบัติผู้จัดจำหน่าย.
- คลิก ค่าเริ่มต้นของโปรไฟล์ ปุ่ม
- เลือกประเภทเอเจนต์ (สแนปช็อต, ตัวอ่านบันทึก, การกระจาย หรือ การรวม) จากเมนูแบบเลื่อนลง
- เลือกโปรไฟล์แล้วคลิก อสังหาริมทรัพย์ เพื่อดูค่าพารามิเตอร์
- คลิก โปรไฟล์ใหม่ เพื่อสร้างโปรไฟล์แบบกำหนดเองโดยอิงจากโปรไฟล์ที่มีอยู่แล้ว
- ปรับเปลี่ยนพารามิเตอร์ตามต้องการแล้วคลิก OK.
กำหนดโปรไฟล์ให้กับเอเจนต์โดยแก้ไขคุณสมบัติการสมัครสมาชิกและเลือกโปรไฟล์ที่ต้องการจากเมนูแบบเลื่อนลง "โปรไฟล์เอเจนต์"
5.3.3 พารามิเตอร์และการตั้งค่าเอเจนต์
พารามิเตอร์ของเอเจนต์ช่วยปรับแต่งประสิทธิภาพและพฤติกรรม พารามิเตอร์สำคัญสำหรับ Distribution Agent ได้แก่ CommitBatchSize (จำนวนธุรกรรมที่ใช้ต่อการคอมมิตแต่ละครั้ง), CommitBatchThreshold (จำนวนคำสั่งก่อนการคอมมิต), SubscriptionStreams (การเชื่อมต่อแบบขนานเพื่อการส่งมอบที่เร็วขึ้น) และ QueryTimeout (ระยะเวลาหมดเวลาสำหรับคำสั่ง)
สำหรับ Log Reader Agent พารามิเตอร์ที่สำคัญ ได้แก่ ReadBatchSize (จำนวนธุรกรรมที่อ่านต่อการสแกน), ReadBatchThreshold (จำนวนคำสั่งก่อนการส่งมอบ) และ PollingInterval (ระยะเวลาหน่วงระหว่างการสแกนบันทึก) ปรับพารามิเตอร์เหล่านี้ตามปริมาณธุรกรรมและความต้องการเวลาในการตอบสนอง
5.4 ข้อควรพิจารณาในการสำรองข้อมูลและกู้คืนข้อมูล
การสำรองข้อมูลฐานข้อมูลที่เกี่ยวข้องกับการจำลองแบบต้องพิจารณาเป็นพิเศษ สำหรับฐานข้อมูลผู้เผยแพร่ การสำรองข้อมูลแบบเต็มและบันทึกธุรกรรมเป็นประจำนั้นมีความสำคัญอย่างยิ่ง ให้ทำเครื่องหมายการสำรองฐานข้อมูลว่ารองรับการจำลองแบบโดยใช้ตัวเลือก WITH REPLICATION เมื่อทำการสำรองฐานข้อมูลในการจำลองแบบธุรกรรม สำรองข้อมูลฐานข้อมูลการกระจายอย่างสม่ำเสมอเพื่อปกป้องการกำหนดค่าการจำลองแบบ
เมื่อกู้คืนฐานข้อมูลผู้เผยแพร่ไปยังเซิร์ฟเวอร์เดียวกันด้วยชื่อเดียวกัน ให้ใช้ตัวเลือก WITH KEEP_REPLICATION เพื่อรักษาสถานะการจำลองข้อมูล ตัวเลือกนี้จะช่วยให้มั่นใจได้ว่าธุรกรรมที่ยังไม่ได้รับการประมวลผลโดย Log Reader Agent จะยังคงถูกทำเครื่องหมายสำหรับการจำลองข้อมูล ทำให้การจำลองข้อมูลดำเนินต่อไปโดยอัตโนมัติโดยไม่ต้องเริ่มต้นการสมัครรับข้อมูลใหม่
ในสถานการณ์การกู้คืนระบบหลังภัยพิบัติที่ไม่มีข้อมูลสำรอง ข้อมูลสำรองเสียหาย หรือไฟล์ฐานข้อมูลชำรุด อาจจำเป็นต้องใช้เครื่องมือการกู้คืนเฉพาะทาง DataNumen SQL Recovery สามารถดึงข้อมูลจากไฟล์ MDF และ NDF ที่เสียหายหรือไม่สามารถเข้าถึงได้ ซึ่งเป็นทางเลือกสุดท้ายเมื่อขั้นตอนการกู้คืนมาตรฐานล้มเหลว
สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับ SQL Server การสำรองข้อมูล โปรดดูที่หน้าของเรา คู่มือฉบับสมบูรณ์.
6. คำถามที่พบบ่อย (FAQ)
ถาม: การจำลองแบบสแนปช็อตและการจำลองแบบธุรกรรมแตกต่างกันอย่างไร?
A: การจำลองแบบสแนปช็อตจะคัดลอกข้อมูลทั้งหมด ณ จุดเวลาใดเวลาหนึ่ง แล้วนำไปใช้กับผู้รับข้อมูล เหมาะสำหรับข้อมูลที่มีการเปลี่ยนแปลงไม่บ่อยนัก ส่วนการจำลองแบบธุรกรรมจะเริ่มต้นด้วยสแนปช็อตเริ่มต้น จากนั้นจะจำลองธุรกรรมแต่ละรายการอย่างต่อเนื่องเมื่อเกิดขึ้น ทำให้ได้การซิงโครไนซ์แบบเรียลไทม์สำหรับข้อมูลที่มีการเปลี่ยนแปลงบ่อยครั้ง
ถาม: ฉันสามารถจำลองการทำงานระหว่างอุปกรณ์ต่างๆ ได้หรือไม่ SQL Server รุ่น?
ตอบ: ใช่ SQL Server การจำลองข้อมูลรองรับความเข้ากันได้ของเวอร์ชันภายในช่วงที่จำกัด เวอร์ชันของตัวกระจายต้องเท่ากับหรือสูงกว่าเวอร์ชันของผู้เผยแพร่ และเวอร์ชันของผู้รับสามารถอยู่ภายในสองเวอร์ชันของผู้เผยแพร่ ตัวอย่างเช่น หากผู้เผยแพร่คือ SQL Server ในปี 2016 ผู้สมัครสมาชิกสามารถเป็นได้ SQL Server ปี 2012, 2014, 2016, 2017 หรือ 2019
ถาม: ฉันจะจัดการกับข้อขัดแย้งในการจำลองแบบผสาน (merge replication) ได้อย่างไร?
A: การจำลองแบบผสาน (Merge replication) มีกลไกการตรวจจับและแก้ไขข้อขัดแย้งในตัว คุณสามารถกำหนดค่าตัวแก้ไขข้อขัดแย้งได้ในระดับบทความ โดยเลือกจากตัวแก้ไขที่มีอยู่แล้ว หรือใช้ตัวแก้ไขข้อขัดแย้งแบบกำหนดเอง โดยทั่วไปแล้ว ข้อขัดแย้งจะได้รับการแก้ไขโดยใช้วิธีการตามลำดับความสำคัญหรือตามเวลา พร้อมตัวเลือกในการบันทึกข้อขัดแย้งเพื่อตรวจสอบด้วยตนเอง
ถาม: การทำซ้ำส่งผลกระทบต่อประสิทธิภาพการทำงานอย่างไร?
A: การจำลองข้อมูลส่งผลกระทบต่อประสิทธิภาพในหลายด้าน ได้แก่ ผู้เผยแพร่ข้อมูลต้องแบกรับภาระเพิ่มเติมจากการติดตามการเปลี่ยนแปลงและการสร้างสแนปช็อต ผู้จัดจำหน่ายใช้ทรัพยากรในการจัดเก็บและส่งต่อธุรกรรม และแบนด์วิดท์เครือข่ายถูกใช้ไปในระหว่างการถ่ายโอนข้อมูล ผลกระทบจะแตกต่างกันไปตามประเภทของการจำลองข้อมูล โดยการจำลองสแนปช็อตจะทำให้เกิดการเปลี่ยนแปลงที่มีผลกระทบสูงเป็นระยะๆ ในขณะที่การจำลองธุรกรรมจะรักษาระดับการโหลดที่สม่ำเสมอและต่อเนื่องมากกว่า
ถาม: ฉันจะรักษาความปลอดภัยของโทโพโลยีการจำลองข้อมูลของฉันได้อย่างไร?
A: รักษาความปลอดภัยให้กับโครงสร้างการจำลองข้อมูลของคุณโดยการนำแนวทางปฏิบัติที่ดีที่สุดหลายประการมาใช้ เช่น การใช้การตรวจสอบสิทธิ์แบบ Windows หรือการตรวจสอบสิทธิ์ที่มีความปลอดภัยสูง SQL Server การตรวจสอบสิทธิ์ เข้ารหัสการเชื่อมต่อโดยใช้ TLS รักษาความปลอดภัยโฟลเดอร์สแนปช็อตด้วยวิธีการที่เหมาะสม NTFS กำหนดสิทธิ์การเข้าถึง กำหนดค่ารายการการเข้าถึงสิ่งพิมพ์ (PAL) เพื่อควบคุมการเข้าถึง ใช้บัญชีบริการแยกต่างหากที่มีสิทธิ์ขั้นต่ำที่จำเป็นสำหรับเอเจนต์การจำลองแต่ละตัว และตรวจสอบการตั้งค่าความปลอดภัยการจำลองเป็นประจำ
ถาม: ฉันสามารถจำลองข้อมูลไปยัง Azure SQL Database ได้หรือไม่?
A: ใช่ คุณสามารถจำลองข้อมูลไปยัง Azure SQL Database โดยใช้การจำลองแบบธุรกรรม (transactional replication) กับระบบภายในองค์กรได้ SQL Server หรือใช้ Azure SQL Managed Instance เป็นตัวเผยแพร่และตัวกระจายข้อมูล Azure SQL Database สามารถทำหน้าที่เป็นผู้รับข้อมูลได้ แต่ไม่สามารถทำหน้าที่เป็นตัวเผยแพร่หรือตัวกระจายข้อมูลได้ Azure SQL Database ไม่รองรับการจำลองแบบผสาน (Merge replication) และการจำลองแบบเพียร์ทูเพียร์ (Peer-to-Peer replication)
ถาม: ฉันจะตรวจสอบความล่าช้าในการจำลองข้อมูลได้อย่างไร?
A: ตรวจสอบความล่าช้าในการจำลองข้อมูลโดยใช้ Replication Monitor ใน SQL Server Management Studio แสดงเมตริกความหน่วงสำหรับแต่ละการสมัครใช้งาน นอกจากนี้ คุณยังสามารถสอบถามตารางฐานข้อมูลการแจกจ่าย เช่น MSdistribution_history และ MSrepl_commands ใช้ตัวนับประสิทธิภาพเฉพาะสำหรับเอเจนต์การจำลองแบบ หรือตั้งค่าการแจ้งเตือนตามเกณฑ์ความหน่วงเพื่อตรวจจับและแก้ไขความล่าช้าในการซิงโครไนซ์ได้อย่างทันท่วงที
ถาม: จะเกิดอะไรขึ้นเมื่อผู้ใช้งานออฟไลน์?
A: เมื่อผู้รับข้อมูลออฟไลน์ พฤติกรรมจะขึ้นอยู่กับประเภทของการจำลองข้อมูล สำหรับการจำลองแบบธุรกรรม ธุรกรรมจะสะสมอยู่ในฐานข้อมูลการกระจายจนกว่าผู้รับข้อมูลจะกลับมาออนไลน์ จากนั้นการซิงโครไนซ์จะเริ่มต้นใหม่ สำหรับการจำลองแบบผสาน การเปลี่ยนแปลงจะถูกติดตามทั้งสองฝั่งและผสานรวมเมื่อการเชื่อมต่อกลับมาใช้งานได้อีกครั้ง การตั้งค่าระยะเวลาการเก็บรักษาจะกำหนดระยะเวลาที่ข้อมูลจะถูกเก็บไว้ก่อนที่จะต้องเริ่มต้นใหม่
ถาม: ฉันจะเพิ่มบทความใหม่ลงในสิ่งพิมพ์ที่มีอยู่ได้อย่างไร?
A: หากต้องการเพิ่มบทความใหม่ลงในสิ่งพิมพ์ที่มีอยู่แล้ว ให้ใช้ SQL Server ใช้ Management Studio เพื่อแก้ไขคุณสมบัติการเผยแพร่และเลือกวัตถุเพิ่มเติม หรือใช้ stored procedure sp_addarticle หลังจากเพิ่มบทความแล้ว ให้สร้าง snapshot ใหม่และเริ่มต้นการสมัครรับข้อมูลทั้งหมดใหม่เพื่อให้แน่ใจว่าผู้สมัครรับข้อมูลได้รับบทความใหม่ การเปลี่ยนแปลงบางอย่างอาจต้องเริ่มต้นการสมัครรับข้อมูลใหม่ ขึ้นอยู่กับการตั้งค่าการเผยแพร่
ถาม: ฉันจะลบการจำลองข้อมูลออกจากฐานข้อมูลได้อย่างไร?
A: ลบการจำลองข้อมูลออกจากฐานข้อมูลโดยเริ่มจากการลบการสมัครรับข้อมูลทั้งหมดโดยใช้คำสั่ง sp_dropsubscription จากนั้นลบการเผยแพร่โดยใช้คำสั่ง sp_droppublication และสุดท้ายปิดใช้งานการเผยแพร่บนฐานข้อมูลโดยใช้คำสั่ง sp_replicationdboption หากเซิร์ฟเวอร์เป็นตัวกระจายข้อมูล ให้ปิดใช้งานการกระจายข้อมูลโดยใช้คำสั่ง sp_dropdistributor ควรสำรองข้อมูลฐานข้อมูลก่อนลบการกำหนดค่าการจำลองข้อมูลเสมอ
ถาม: อะไรคือความแตกต่างระหว่าง SQL Server การจำลองข้อมูลและกลุ่มความพร้อมใช้งาน AlwaysOn?
A: การจำลองข้อมูล (Replication) เป็นโซลูชันการกระจายและการบูรณาการข้อมูลที่ทำงานในระดับวัตถุ ในขณะที่ เสมอในกลุ่มความพร้อมใช้งาน เป็นโซลูชันที่มีความพร้อมใช้งานสูงและรองรับการกู้คืนจากภัยพิบัติ ซึ่งทำงานในระดับฐานข้อมูล
7 ข้อสรุป
SQL Server การจำลองข้อมูล (Replication) เป็นกรอบการทำงานที่แข็งแกร่งสำหรับการกระจายและการซิงโครไนซ์ข้อมูลระหว่างฐานข้อมูลและสถานที่ต่างๆ เทคโนโลยีนี้รองรับสถานการณ์ต่างๆ ผ่านประเภทการจำลองข้อมูลที่แตกต่างกัน
การเลือกกลยุทธ์การจำลองข้อมูลที่เหมาะสมนั้นขึ้นอยู่กับความต้องการเฉพาะของคุณ พิจารณาความถี่ในการเปลี่ยนแปลงข้อมูล ข้อกำหนดด้านความหน่วงแฝง ว่าผู้รับข้อมูลจำเป็นต้องทำการอัปเดตหรือไม่ ลักษณะของเครือข่าย และความต้องการความเป็นอิสระของผู้รับข้อมูล การจำลองแบบสแนปช็อตเหมาะที่สุดสำหรับข้อมูลอ้างอิงที่เปลี่ยนแปลงไม่บ่อยนักซึ่งความหน่วงแฝงไม่ใช่ปัญหาสำคัญ การจำลองแบบธุรกรรมเหมาะสำหรับสถานการณ์ที่มีปริมาณมากซึ่งต้องการความหน่วงแฝงต่ำและส่วนใหญ่เป็นการไหลของข้อมูลแบบทางเดียว
เลือกใช้การจำลองแบบผสาน (merge replication) เมื่อผู้รับข้อมูลต้องการการทำงานแบบอิสระพร้อมความสามารถในการทำงานแบบออฟไลน์และการซิงโครไนซ์แบบสองทิศทาง ใช้การจำลองแบบแบบเพียร์ทูเพียร์ (peer-to-peer replication) สำหรับการกระจายโหลดการอ่านข้อมูลไปยังโหนดที่ใช้งานอยู่หลายโหนดด้วยความสอดคล้องแบบเรียลไทม์ใกล้เคียง พิจารณาแนวทางแบบผสมผสานที่รวมการจำลองหลายประเภทเข้าด้วยกันสำหรับสถานการณ์ที่ซับซ้อนซึ่งมีความต้องการที่หลากหลาย
อ้างอิง
- เอกสารอย่างเป็นทางการจาก Microsoft: SQL Server การทำซ้ำ
- เอกสารทางการของ Microsoft: ประเภทของการจำลองข้อมูล
- เอกสารอย่างเป็นทางการจาก Microsoft: การจำลองแบบ Peer-to-Peer – การจำลองแบบธุรกรรม
เกี่ยวกับผู้เขียน
หยวน เซิง เป็นผู้ดูแลฐานข้อมูลอาวุโส (DBA) ที่มีประสบการณ์มากกว่า 10 ปีใน SQL Server สภาพแวดล้อมและการจัดการฐานข้อมูลองค์กร เขาประสบความสำเร็จในการแก้ไขปัญหาการกู้คืนฐานข้อมูลหลายร้อยกรณีในองค์กรด้านบริการทางการเงิน การดูแลสุขภาพ และการผลิต
หยวนมีความเชี่ยวชาญด้าน SQL Server การกู้คืนฐานข้อมูล โซลูชันความพร้อมใช้งานสูง และการเพิ่มประสิทธิภาพการทำงาน ประสบการณ์ภาคปฏิบัติอันกว้างขวางของเขาครอบคลุมการจัดการฐานข้อมูลหลายเทราไบต์ การนำ Always On Availability Groups มาใช้ และการพัฒนากลยุทธ์การสำรองและกู้คืนข้อมูลอัตโนมัติสำหรับระบบธุรกิจที่สำคัญต่อภารกิจ
ด้วยความเชี่ยวชาญทางเทคนิคและแนวทางปฏิบัติ Yuan มุ่งเน้นที่การสร้างคู่มือที่ครอบคลุมซึ่งจะช่วยให้ผู้ดูแลระบบฐานข้อมูลและผู้เชี่ยวชาญด้านไอทีแก้ไขปัญหาที่ซับซ้อน SQL Server ท้าทายอย่างมีประสิทธิภาพ เขาคอยติดตามข่าวสารล่าสุดอยู่เสมอ SQL Server การเปิดตัวและเทคโนโลยีฐานข้อมูลที่พัฒนาอย่างต่อเนื่องของ Microsoft ทดสอบสถานการณ์การกู้คืนเป็นประจำเพื่อให้แน่ใจว่าคำแนะนำของเขาสะท้อนถึงแนวทางปฏิบัติที่ดีที่สุดในโลกแห่งความเป็นจริง
มีคำถามเกี่ยวกับ SQL Server การกู้คืนหรือต้องการคำแนะนำในการแก้ไขปัญหาฐานข้อมูลเพิ่มเติมหรือไม่? หยวนยินดีต้อนรับ ข้อเสนอแนะและข้อเสนอแนะ เพื่อปรับปรุงทรัพยากรทางเทคนิคเหล่านี้