TAHA
11-24-2009, 09:14 PM
استفاده از راهکارهايي چون افزایش تعداد سرورها یا ارتقای سرورهای موجود در پردازنده قدرتمندتر، حافظه بیشتر، هارددیسک های سریع تر و حتی ارتقای ارتباطات شبکه ای یا امثال آن از جمله ترفند هایی هستند که برای رفع معضل سرعت، مورداستفاده قرار می گیرند. در این مقاله به یکی از روش های توسعه طولی، نگاهی می افکنیم.
ممکن است پس از طی چند سال و درج هزاران رکورد در جداول یک بانک اطلاعاتی، سرعت جستجو در میان اطلاعات درج شده،سرعت درج اطلاعات جدید یا تغییر و حذف آن ها کند شود و مدیران یا برنامه نویسان این بانک ها را به ایجاد دگرگونی در برخی قسمت های بانک ناچار نماید.دو روش معمول برای مواجهه با چنین پدیده ای وجود دارد: روش اول یعنی توسعه عرضی ( Scale up ) که ترجیحا باید مقدم بر روش دوم مورد استفاده قرار گیرد، با استفاده از ساز وکار هایی مثل ایجاد انواع ایندکس ها بر روی جداول یا دید ( view )های بانک، کوتاه نمودن و کم حجم تر کردن تریگرها، به حداقل رساندن تعداد دستورات SQL که در هر فرایند وجود دارد، پرهیز از استفاده بی موقع و مکرر از توابع تعریف شده توسط کاربر و غیره می توان تا حدودی مشکل را برطرف نمود. اما در برخی موارد با تمام این تمهیدات باز هم اشکالات و وقفه هایی در سرعت و عملکرد سیستم، مدیران بانک های اطلاعاتی را ناگزیر می کند برای حل مشکل به روش دوم یعنی توسعه طولی ( Scale out ) رو بیاورند.
در این روش، استفاده از راهکارهایی چون افزایش تعداد سرورها یا ارتقای سرورهای موجود در پردازنده قدرتمندتر، حافظه بیشتر، هارددیسک های سریع تر و حتی ارتقای ارتباطات شبکه ای یا امثال آن از جمله ترفند هایی هستند که برای رفع معضل سرعت، مورداستفاده قرار می گیرند. در این مقاله به یکی از روش های توسعه طولی، نگاهی می افکنیم.
صورت مسئله
فرض کنید شما دارای یک بانک اطلاعاتی در حال کار، روی یک سرور هستید و در طول روز حدود پانصد کاربر به طور متناوب مشغول کار با این بانک هستند. کاملا آشکار است که هر چه سعی کنید با استفاده از سازوکارهای توسعه عرضی ( مثل ایندکس گذاری و امثال آن )، سرعت و کارایی سیستم را افزایش دهید، باز هم برای ارائه گزارش های مطلوب و استاندارد و حتی برای ایجاد یک محیط کارا و کاربرپسند برای استفاده از آن، مجبور می شوید برای اتفاقاتی که ممکن است در اثر ترافیک سنگین عملیات کاربران اتفاق بیفتد، فکر دیگری بکنید. یعنی حتی اگر سرور شما یک کامپیوتر قدرتمند با دو پردازنده Xeon، چهار گیگابایت حافظه و یک هارددیسک سریع باشد، باز هم قطعا در پاره ای از اوقات تصادم انبوه درخواست های موردنیاز کاربران در یک زمان، باعث بروز مسائلی چون قفل شدن برخی رکوردهای بانک (locking ) یا مسدود شدن برخی درخواست ها به دلیل عدم وجود زمان کافی برای پردازش آن ( Timeout Blocking ) می شود.
انتخاب راه حل
راه حل مسئله با استفاده از روش توسعه طولی، افزودن به تعداد سرورهایی است که به شکلی نقش پردازشگر اطلاعات را بازی می کنند. در این روش، سه راه حل مختلف وجود دارد که با اتکا به آن ها می توان تعداد سرورها، سرورهای لایه واسط (Application Server ) و سرورهای بانک اطلاعاتی (Database Server ) را افزایش داد. با این کار ترافیک و سنگینی پردازش فقط روی سرور لایه واسط یا سرور بانک اطلاعاتی کاهش می یابد و به نحوی پدیده توازن بار (Load Balancing ) چند سرور صورت می گیرد. در ادامه به بررسی هر سه راه حل مذکور می پردازیم.
راه حل یکم: کپی برداری (Cloning )
در این راه حل به سادگی می توان به جای استفاده از یک سرور لایه واسط که نقش پردازش اطلاعات را بازی می کند، از چندین سرور برای انجام دادن عمل مذکور استفاده نمود. سرورهای لایه واسط عمدتا محل فعالیت کامپوننت ها ( COM) یا وب سرورها هستند. بنابراین اگر بتوان تعداد آن ها را افزایش داد و هر دسته از کاربران را به سمت یکی از این سرورها هدایت نمود، عملکرد پردازشی سرورهای لایه واسط افزایش می یابد و در نتیجه تا حدود زیادی از بروز سرعت در سیستم جلوگیری می شود. ضمن این که اگر هر کدام از این سرورها نیز با مشکل روبه رو شوند، می توان به صورت موقت کاربران آن را به سمت یک سرور دیگر هدایت کرد و از ایجاد وقفه در کار آن ها جلوگیری نمود. ( شکل 1 )
http://pnu-club.com/imported/mising.jpg
شکل 1
راه حل دوم: تقسیم بندی(Partitioning )
این راه حل به دو روش تقسیم می شود:
روش یکم: افزایش سرورهای لایه واسط
در این روش نیز تعداد سرورهای لایه واسط افزایش می یابد. اما بر خلاف راه حل قبل که چند سرور کاملا مشابه، نقش یکسانی را در پردازش درخواست های کاربران ایفا می کردند، این بار هر کدام از سرورهای لایه میانی صرفا عمل خاصی را انجام می دهند که سایر سرورها از انجام دادن آن معافند. مثلا اگر قبلا تنها یک سرور، هم محل فعالیت COM ها بود و هم نقش یک وب سرور را بازی می کرد، اکنون دو وظیفه مذکور را بین دو سرور مختلف ( و شاید با ویژگی ها و توانایی های مختلف ) تقسیم می کنیم. یا به عنوان مثالی دیگر اگر تا کنون تنها یک سرور لایه میانی هم شامل COM هایی بود که با استفاده از اشیای ADO ، دسترسی به سرور پایگاه را فراهم می آوردند و هم شامل COM های دیگری که اعمال محاسباتی پیچیده را انجام می داد، اکنون می توان این دو وظیفه را بین دو سرور مختلف به ترتیب با نام هایی چون Data Access و Business Logic تقسیم کرد.
نقطه قوت این روش این است که علاوه بر تقسیم ترافیک و پردازش میان دو یا چند سرور جداگانه، امکان جداسازی کاربران بر اساس نوع استفاده آن ها از اطلاعات و فراهم ساختن سرورهایی با کاربرد مختلف جهت انجام دادن وظایف متعدد وجود دارد و در نتیجه ضریب امنیت دسترسی یا پردازش اطلاعات نیز بالاتر می رود. نقطه ضعف آن هم این است که در صورت از کار افتادن یکی از این سرورهای لایه میانی، سایر سرورهای این لایه نمی توانند به سرعت جایگزین آن شوند و وظیفه آن را به طور موقع بر عهده بگیرند. ( شکل 2 )
http://pnu-club.com/imported/mising.jpg شکل 2
روش دوم :تقسیم سرور پایگاه داده
در این روش، به جای سرورهای لایه میانی، سرور پایگاه داده به دو یا چند سرور تقسیم می شود تا حجم فرایند ( Transaction) های داخلی و پرس و جو های همزمان روی آن سرور کاهش پیدا کند. برای استفاده از این روش، در نظر گرفتن یک نکته اساسی، بسیار مهم است. این نکته، تشخیص اشتراک یا عدم اشتراکی بودن داده ها میان کاربران مختلف است. بدین معنی که یک مدیر پایگاه داده باید بداند که آیا می توان داده ها را به چند دسته تقسیم کرد و هر دسته را روی یک سرور جداگانه برای کاربرد مختلف قرار داد یا نه. به عنوان مثال، اگر شرکتی دارای یک سیستم جامع، شامل سه زیرسیستم انبار، فروش و حسابداری باشد، می تواند جداول دیدها و ارتباطات مربوط به هر یک از این سه زیر سیستم را در یک پایگاه داده روی یک سرور جداگانه قرار دهد ت هر یکی از آن ها در دسترس مسئولان انبار، فروش و حسابداری شرکت قرار گیرد.
سوالی که در اینجا مطرح می شود این است که اگر این سه زیر سیستم با یکدیگر در ارتباط باشند، باید چه کرد؟ مثلا فرض کنید که مسئول انبار برای خروج یک کالا از انبار باید بتواند به داده هایی از جداول مربوط به سیستم فروش دست یابد. بنابراین باید در این روش، راهی وجود داشته باشد تا در عین جدا بودن اطلاعات مذکور از یکدیگر، امکان استفاده کاربران مختلف از یکی از آن ها یا تلفیقی از آن ها نیز فراهم گردد.
در SQL Server نسخه 2000 برای این کار امکاناتی پیش بینی شده است. به عنوان مثال، شما با استفاده از قابلیت Linked server قادر خواهید بود یک بانک اطلاعاتی مقیم در یک سرور دیگر را طوری به یک بانک اطلاعاتی سرورتان پیوند بزنید که گویی هر دو در یک سرور قرار دارند.پس از این کار حتی می توانید پرس و جوهایی انجام دهید که از لینک کردن چند جدول و یا دید از هر دو بانک اطلاعاتی حاصل شود. به این قابلیت، جستجوی توزیع شده یعنی Distributed Query گفته می شود.
علاوه بر این خاصیت دیگری در این نسخه تعبیه شده است که امکان انجام دادن یک فرایند واحد روی چند بانک اطلاعاتی موجود در چند سرور مختلف را فراهم می کند(Distributed Transaction ). این قابلیت ها به گونه ای است که حتی امکان تعریف روابط وابستگی از طریق کلیدهای اولیه و کلید های خارجی میان بانک های مذکور نیز وجود دارد و یا مثلا ساخت یک دید با استفاده از لینک کردن جداول موجود در چند سرور نیز میسر گشته که به آن Distributed Portioned View گفته می شود.
به هر حال، بسیاری از راه حل های مربوط به "توزیع" در SQL Server برای استفاده همزمان از قدرت و قابلیت چندین سرور در نظر گرفته شده است. درشکل سه مثالی را مشاهده می کنید که در آن به صورت بسیار ساده جدول مشتریان یک شرکت به دلیل زیاد بودن و قابل جدا کردن اطلاعات آن، به سه دسته مشتریان شرق، غرب و مرکز کشور تقسیم بندی شده و هر کدام در عین ارتباط با یکدیگر و با کاربران، بر روی یک سرور مجزا قرار گرفته اند .(شکل 3 )
http://pnu-club.com/imported/mising.jpg شکل 3
راه حل سوم: Replication
این راه حل نیز مشابه روش دوم Partitioning است. اما بر خلاف آن روش که سرور بانک اطلاعاتی را به چند سرور حاوی اطلاعات مختلف مورد نیازشان تقسیم می کردیم، در اینجا چند سرور بانک اطلاعاتی با استفاده از سازوکار Replication دقیقا شامل اطلاعات یکسان و همانند می باشند.
به عنوان مثال فرض کنید در یک شرکت بزرگ که دارای سه واحد اصلی فروش، انبار و حسابداری است، سه سرور بانک اطلاعاتی کاملا یکسان در نظر گرفته شده که هر یک از واحد ها داده های موردنیازشان را از جداول مربوط به خودشان از سروری که به آن ها اختصاص یافته دریافت می کنند و هر گاه تغییری را در آن اطلاعات به وجود آوردند، یا در همان لحظه باید در کلیه سرورهای دیگر نیز اعمال شود و یا طبق یک برنامه زمانبندی شده، در زمان دیگری مثلا در ساعات غیر اداری ک میزان ترافیک اطلاعات کاهش می یابد، به دیگر سرورها منتقل شود.اگر بخواهیم تغییر اطلاعات در همان لحظه به دیگر سرورها اعمال شود، می توان از Replication نوع فرایندی (Transactional) استفاده کرد.
در این روش با استفاده از قابلیتی به نام تغییر دو مرحله ای اطلاعات یا اصطلاحا Two Phase Commit هر تغییری بلافاصله در سایر سرورها نیز لزوما اعمال می شود. اما اگر بخواهیم تغییرات در زمان خاصی و به تعداد معمولی ( مثلا دو یا سه بار طی شبانه روز ) به سرورهای دیگر منتقل شود، می توان از Replication نوع ادغام استفاده کرد .(شکل 4)
بنابراین در این حالت هر سرور ضمن داشتن آخرین اطلاعات مربوط به واحد خود، آخرین اطلاعات رسیده از سایر سرورها (یا واحدهای دیگر) را نیز دارد.
لازم به ذکر است که عملیات انتقال اطلاعات با استفاده از Replication نکات و مسائل فنی فراوانی دارد که به تنهائی در قالب چند مقاله قابل بررسی است.
http://pnu-club.com/imported/mising.jpg شکل 4
منبع : sqliran.com
ممکن است پس از طی چند سال و درج هزاران رکورد در جداول یک بانک اطلاعاتی، سرعت جستجو در میان اطلاعات درج شده،سرعت درج اطلاعات جدید یا تغییر و حذف آن ها کند شود و مدیران یا برنامه نویسان این بانک ها را به ایجاد دگرگونی در برخی قسمت های بانک ناچار نماید.دو روش معمول برای مواجهه با چنین پدیده ای وجود دارد: روش اول یعنی توسعه عرضی ( Scale up ) که ترجیحا باید مقدم بر روش دوم مورد استفاده قرار گیرد، با استفاده از ساز وکار هایی مثل ایجاد انواع ایندکس ها بر روی جداول یا دید ( view )های بانک، کوتاه نمودن و کم حجم تر کردن تریگرها، به حداقل رساندن تعداد دستورات SQL که در هر فرایند وجود دارد، پرهیز از استفاده بی موقع و مکرر از توابع تعریف شده توسط کاربر و غیره می توان تا حدودی مشکل را برطرف نمود. اما در برخی موارد با تمام این تمهیدات باز هم اشکالات و وقفه هایی در سرعت و عملکرد سیستم، مدیران بانک های اطلاعاتی را ناگزیر می کند برای حل مشکل به روش دوم یعنی توسعه طولی ( Scale out ) رو بیاورند.
در این روش، استفاده از راهکارهایی چون افزایش تعداد سرورها یا ارتقای سرورهای موجود در پردازنده قدرتمندتر، حافظه بیشتر، هارددیسک های سریع تر و حتی ارتقای ارتباطات شبکه ای یا امثال آن از جمله ترفند هایی هستند که برای رفع معضل سرعت، مورداستفاده قرار می گیرند. در این مقاله به یکی از روش های توسعه طولی، نگاهی می افکنیم.
صورت مسئله
فرض کنید شما دارای یک بانک اطلاعاتی در حال کار، روی یک سرور هستید و در طول روز حدود پانصد کاربر به طور متناوب مشغول کار با این بانک هستند. کاملا آشکار است که هر چه سعی کنید با استفاده از سازوکارهای توسعه عرضی ( مثل ایندکس گذاری و امثال آن )، سرعت و کارایی سیستم را افزایش دهید، باز هم برای ارائه گزارش های مطلوب و استاندارد و حتی برای ایجاد یک محیط کارا و کاربرپسند برای استفاده از آن، مجبور می شوید برای اتفاقاتی که ممکن است در اثر ترافیک سنگین عملیات کاربران اتفاق بیفتد، فکر دیگری بکنید. یعنی حتی اگر سرور شما یک کامپیوتر قدرتمند با دو پردازنده Xeon، چهار گیگابایت حافظه و یک هارددیسک سریع باشد، باز هم قطعا در پاره ای از اوقات تصادم انبوه درخواست های موردنیاز کاربران در یک زمان، باعث بروز مسائلی چون قفل شدن برخی رکوردهای بانک (locking ) یا مسدود شدن برخی درخواست ها به دلیل عدم وجود زمان کافی برای پردازش آن ( Timeout Blocking ) می شود.
انتخاب راه حل
راه حل مسئله با استفاده از روش توسعه طولی، افزودن به تعداد سرورهایی است که به شکلی نقش پردازشگر اطلاعات را بازی می کنند. در این روش، سه راه حل مختلف وجود دارد که با اتکا به آن ها می توان تعداد سرورها، سرورهای لایه واسط (Application Server ) و سرورهای بانک اطلاعاتی (Database Server ) را افزایش داد. با این کار ترافیک و سنگینی پردازش فقط روی سرور لایه واسط یا سرور بانک اطلاعاتی کاهش می یابد و به نحوی پدیده توازن بار (Load Balancing ) چند سرور صورت می گیرد. در ادامه به بررسی هر سه راه حل مذکور می پردازیم.
راه حل یکم: کپی برداری (Cloning )
در این راه حل به سادگی می توان به جای استفاده از یک سرور لایه واسط که نقش پردازش اطلاعات را بازی می کند، از چندین سرور برای انجام دادن عمل مذکور استفاده نمود. سرورهای لایه واسط عمدتا محل فعالیت کامپوننت ها ( COM) یا وب سرورها هستند. بنابراین اگر بتوان تعداد آن ها را افزایش داد و هر دسته از کاربران را به سمت یکی از این سرورها هدایت نمود، عملکرد پردازشی سرورهای لایه واسط افزایش می یابد و در نتیجه تا حدود زیادی از بروز سرعت در سیستم جلوگیری می شود. ضمن این که اگر هر کدام از این سرورها نیز با مشکل روبه رو شوند، می توان به صورت موقت کاربران آن را به سمت یک سرور دیگر هدایت کرد و از ایجاد وقفه در کار آن ها جلوگیری نمود. ( شکل 1 )
http://pnu-club.com/imported/mising.jpg
شکل 1
راه حل دوم: تقسیم بندی(Partitioning )
این راه حل به دو روش تقسیم می شود:
روش یکم: افزایش سرورهای لایه واسط
در این روش نیز تعداد سرورهای لایه واسط افزایش می یابد. اما بر خلاف راه حل قبل که چند سرور کاملا مشابه، نقش یکسانی را در پردازش درخواست های کاربران ایفا می کردند، این بار هر کدام از سرورهای لایه میانی صرفا عمل خاصی را انجام می دهند که سایر سرورها از انجام دادن آن معافند. مثلا اگر قبلا تنها یک سرور، هم محل فعالیت COM ها بود و هم نقش یک وب سرور را بازی می کرد، اکنون دو وظیفه مذکور را بین دو سرور مختلف ( و شاید با ویژگی ها و توانایی های مختلف ) تقسیم می کنیم. یا به عنوان مثالی دیگر اگر تا کنون تنها یک سرور لایه میانی هم شامل COM هایی بود که با استفاده از اشیای ADO ، دسترسی به سرور پایگاه را فراهم می آوردند و هم شامل COM های دیگری که اعمال محاسباتی پیچیده را انجام می داد، اکنون می توان این دو وظیفه را بین دو سرور مختلف به ترتیب با نام هایی چون Data Access و Business Logic تقسیم کرد.
نقطه قوت این روش این است که علاوه بر تقسیم ترافیک و پردازش میان دو یا چند سرور جداگانه، امکان جداسازی کاربران بر اساس نوع استفاده آن ها از اطلاعات و فراهم ساختن سرورهایی با کاربرد مختلف جهت انجام دادن وظایف متعدد وجود دارد و در نتیجه ضریب امنیت دسترسی یا پردازش اطلاعات نیز بالاتر می رود. نقطه ضعف آن هم این است که در صورت از کار افتادن یکی از این سرورهای لایه میانی، سایر سرورهای این لایه نمی توانند به سرعت جایگزین آن شوند و وظیفه آن را به طور موقع بر عهده بگیرند. ( شکل 2 )
http://pnu-club.com/imported/mising.jpg شکل 2
روش دوم :تقسیم سرور پایگاه داده
در این روش، به جای سرورهای لایه میانی، سرور پایگاه داده به دو یا چند سرور تقسیم می شود تا حجم فرایند ( Transaction) های داخلی و پرس و جو های همزمان روی آن سرور کاهش پیدا کند. برای استفاده از این روش، در نظر گرفتن یک نکته اساسی، بسیار مهم است. این نکته، تشخیص اشتراک یا عدم اشتراکی بودن داده ها میان کاربران مختلف است. بدین معنی که یک مدیر پایگاه داده باید بداند که آیا می توان داده ها را به چند دسته تقسیم کرد و هر دسته را روی یک سرور جداگانه برای کاربرد مختلف قرار داد یا نه. به عنوان مثال، اگر شرکتی دارای یک سیستم جامع، شامل سه زیرسیستم انبار، فروش و حسابداری باشد، می تواند جداول دیدها و ارتباطات مربوط به هر یک از این سه زیر سیستم را در یک پایگاه داده روی یک سرور جداگانه قرار دهد ت هر یکی از آن ها در دسترس مسئولان انبار، فروش و حسابداری شرکت قرار گیرد.
سوالی که در اینجا مطرح می شود این است که اگر این سه زیر سیستم با یکدیگر در ارتباط باشند، باید چه کرد؟ مثلا فرض کنید که مسئول انبار برای خروج یک کالا از انبار باید بتواند به داده هایی از جداول مربوط به سیستم فروش دست یابد. بنابراین باید در این روش، راهی وجود داشته باشد تا در عین جدا بودن اطلاعات مذکور از یکدیگر، امکان استفاده کاربران مختلف از یکی از آن ها یا تلفیقی از آن ها نیز فراهم گردد.
در SQL Server نسخه 2000 برای این کار امکاناتی پیش بینی شده است. به عنوان مثال، شما با استفاده از قابلیت Linked server قادر خواهید بود یک بانک اطلاعاتی مقیم در یک سرور دیگر را طوری به یک بانک اطلاعاتی سرورتان پیوند بزنید که گویی هر دو در یک سرور قرار دارند.پس از این کار حتی می توانید پرس و جوهایی انجام دهید که از لینک کردن چند جدول و یا دید از هر دو بانک اطلاعاتی حاصل شود. به این قابلیت، جستجوی توزیع شده یعنی Distributed Query گفته می شود.
علاوه بر این خاصیت دیگری در این نسخه تعبیه شده است که امکان انجام دادن یک فرایند واحد روی چند بانک اطلاعاتی موجود در چند سرور مختلف را فراهم می کند(Distributed Transaction ). این قابلیت ها به گونه ای است که حتی امکان تعریف روابط وابستگی از طریق کلیدهای اولیه و کلید های خارجی میان بانک های مذکور نیز وجود دارد و یا مثلا ساخت یک دید با استفاده از لینک کردن جداول موجود در چند سرور نیز میسر گشته که به آن Distributed Portioned View گفته می شود.
به هر حال، بسیاری از راه حل های مربوط به "توزیع" در SQL Server برای استفاده همزمان از قدرت و قابلیت چندین سرور در نظر گرفته شده است. درشکل سه مثالی را مشاهده می کنید که در آن به صورت بسیار ساده جدول مشتریان یک شرکت به دلیل زیاد بودن و قابل جدا کردن اطلاعات آن، به سه دسته مشتریان شرق، غرب و مرکز کشور تقسیم بندی شده و هر کدام در عین ارتباط با یکدیگر و با کاربران، بر روی یک سرور مجزا قرار گرفته اند .(شکل 3 )
http://pnu-club.com/imported/mising.jpg شکل 3
راه حل سوم: Replication
این راه حل نیز مشابه روش دوم Partitioning است. اما بر خلاف آن روش که سرور بانک اطلاعاتی را به چند سرور حاوی اطلاعات مختلف مورد نیازشان تقسیم می کردیم، در اینجا چند سرور بانک اطلاعاتی با استفاده از سازوکار Replication دقیقا شامل اطلاعات یکسان و همانند می باشند.
به عنوان مثال فرض کنید در یک شرکت بزرگ که دارای سه واحد اصلی فروش، انبار و حسابداری است، سه سرور بانک اطلاعاتی کاملا یکسان در نظر گرفته شده که هر یک از واحد ها داده های موردنیازشان را از جداول مربوط به خودشان از سروری که به آن ها اختصاص یافته دریافت می کنند و هر گاه تغییری را در آن اطلاعات به وجود آوردند، یا در همان لحظه باید در کلیه سرورهای دیگر نیز اعمال شود و یا طبق یک برنامه زمانبندی شده، در زمان دیگری مثلا در ساعات غیر اداری ک میزان ترافیک اطلاعات کاهش می یابد، به دیگر سرورها منتقل شود.اگر بخواهیم تغییر اطلاعات در همان لحظه به دیگر سرورها اعمال شود، می توان از Replication نوع فرایندی (Transactional) استفاده کرد.
در این روش با استفاده از قابلیتی به نام تغییر دو مرحله ای اطلاعات یا اصطلاحا Two Phase Commit هر تغییری بلافاصله در سایر سرورها نیز لزوما اعمال می شود. اما اگر بخواهیم تغییرات در زمان خاصی و به تعداد معمولی ( مثلا دو یا سه بار طی شبانه روز ) به سرورهای دیگر منتقل شود، می توان از Replication نوع ادغام استفاده کرد .(شکل 4)
بنابراین در این حالت هر سرور ضمن داشتن آخرین اطلاعات مربوط به واحد خود، آخرین اطلاعات رسیده از سایر سرورها (یا واحدهای دیگر) را نیز دارد.
لازم به ذکر است که عملیات انتقال اطلاعات با استفاده از Replication نکات و مسائل فنی فراوانی دارد که به تنهائی در قالب چند مقاله قابل بررسی است.
http://pnu-club.com/imported/mising.jpg شکل 4
منبع : sqliran.com