سناریو‌های متعددی وجود دارد که در آن‌ها استفاده از SQL Server Replication گزینه مناسبی می‌باشد، به عنوان مثال، می‌توان از Replication برای کپی کردن داده‌ها به ماشین دیگری استفاده نمود تا پشتیبانی از گزارش‌گیری موردی (Ad Hoc) صورت گرفته و یا منبعی برای سرویس‌های تحلیلی Cube فراهم گردد. دو مزیت اصلی در این نحوه‌ی استفاده از Replication وجود دارد. اول اینکه با این کار Queryهای گزارش‌گیری پرهزینه از فرآیند تراکنش آنلاین یا OLTP جدا می‌شوند و Write Intensive OLTP Load در یک سیستم و Read-Intensive Reporting Load در سیستمی دیگر قرار خواهند گرفت.
مزیت دیگر برآمده از این واقعیت است که Replication را می‌توان به منظور Run نمودن پس از وقفه‌های مشخص زمانبندی نمود. برای مثال، می‌توان Replication را به صورت شبانه در جهت فراهم نمودن یک Snapshot از داده‌ها در محیط گزارش‌گیری، Run نمود. در نتیجه گزارش‌های شما بجای آنکه داده‌های مربوط به بخشی از روز را داشته باشد، صرفا حاوی داده‌های مربوط به یک روز کامل است و این بدان معناست که اجباری به ایجاد منطق اضافی برای مقابله با داده‌های ناقص امروز نمی‌باشد.
از طرف دیگر، می‌توان Replication تراکنشی را به منظور انتقال داده‌ها به گزارش‌ها به صورت Real-Time تنظیم نمود. اگرچه SQL Server همسان‌سازیِ همزمان (Synchronous Replication) ارائه نمی‌دهد، معمولا پس از تاخیر کوتاهی تغییرات در داده‌های منبع اعمال می‌شوند تا در داده‌های همسان‌سازی شده نشان داده شوند. هرچند میزان تاخیر به عوامل متعددی بستگی دارد، اما در اکثر موارد این تاخیر تنها چند ثانیه طول می‌کشد.
همچنین معمولا Replication توسط نیروی فروش سازمان‌ها بکار گرفته می‌شود. اکثر فروشندگان، لپ‌تاپ‌های خود را که حاوی داده‌های مهم شرکت می‌باشد به همراه خودحمل می‌نمایند و معمولا داده‌ها را در طول روز بروزرسانی می‌کنند. سپس اطلاعات جدید به پایگاه داده در سازمان ارسال می‌شود. از آن‌جایی که لپ‌تاپ‌ها غالبا متصل نیستند، اعمال تنظیمات Replication ممتد، برای اینگونه سناریوها گزینه مناسبی نمی‌باشد. آنچه سبب پیچیده‌تر شدن این مسئله می‌گردد آن است که داده‌های مشابه می‌توانند در مکان‌های متفاوتی به‌روزرسانی شوند. این خود سبب به وجود آمدن اختلالاتی می‌گردد که باید برطرف شوند. با استفاده از روش Merge Replication یا تکثیر ارغامی، SQL Server یک توپولوژی Replication را فراهم می‌نماید که دقیقا برای این نوع از سناریوها طراحی شده است.
همچنین می‌توان از Replication برای اهدافی مانند آرشیو نمودن داده‌ها و دسترسپذیری بالا یا High Availability استفاده نمود. برای مثال می‌توان یک نسخه از پایگاه داده کامپیوتر را روی یک سرور دیگر ذخیره نمود و آن را به طور خودکار در حالت Sync شده با پایگاه داده اصلی نگه داشت. حتی می‌توان سرور HA را در حالت Standby و نسخه دیتابیس را با سرور و دیتابیس گزارش‌گیری ترکیب نمود که در این صورت در هزینه‌های مربوط به سخت‌افزار و Licensing صرفه‌جویی می‌شود. این راه تا قبل از عرضه SQL Server 2012، تنها راه برای حفظ نسخه همسان‌سازی شده از دیتابیسی بود که برای درخواست‌های Read در دسترس قرار داشت.
البته لازم به ذکر است که SQL Server 2012 ویژگی Always-On را به معرفی نمود، که سبب ترکیب نمودن کلاستربندی و Mirroring و تبدیل آن به یک راهکار منعطف HA گردید. همچنین اجازه می‌دهد تا یک نسخه One-to-One از دیتابیس (یا گروه دیتابیس‌ها) داشته باشید که به صورت خودکار در حالت Sync شده با نسخه اصلی نگه داشته می‌شود. Always-On تکنولوژیی را بکار می‌گیرد که توسط سطوح ایزوله شده Snapshot در SQL Server 2005 معرفی شد تا بتواند دسترسی Read-Only را برای دیتابیسهای ثانویه فراهم آورد. دیگر آنکه، این ویژگی اجازه می‌دهد که همسان‌سازی به‌صورت همزمان، به منظور به حداکثر رساندن حفاظت، یا به‌صورت غیرهمزمان، به منظور کاهش تاثیر بر پایگاه داده اولیه، عمل نماید.
با استفاده از این ویژگی، همچنین می‌توان بیش از یک سرور ثانویه را پیادهسازی نمود. برای مثال ممکن است اولین سرور ثانویه در همان دیتاسنتری باشد که سرور اولیه قرار دارد. می‌توان سرور ثانویه را طوری تنظیم نمود تا به صورت همزمان برای مواردی که به سرعت Failover پیش می‌آید ، بروزرسانی گردد. ممکن است سرور ثانویه دیگری جهت اطمینان از به حداکثر رسیدن قابلیت Disaster Recovery در موقعیت مکانی Remote پیادهسازی شود، در این صورت می‌توان تنظیمات را طوری قرار داد تا به صورت غیرهم‌سان بروزرسانی گردد. بدین ترتیب، تاثیر بر دیتابیس اصلی به حداقل می‌رسد.
همه آنچه گفته شد را می‌توان چنین خلاصه کرد که اگر هدف، ایجاد یک نسخه کاملا مشابه با دیتابیس باشد، لزوما Replication در SQL Server 2012 روش مناسبی نیست، زیرا ویژگی Always-On مزیتی همچون انتقال داده‌های همزمان را ارائه می‌دهد و عین هم بودن هر دو پایگاه داده را تضمین می‌نماید.
اما اگر هدف، داشتن یک نسخه کپی one-to-one نباشد، Replication قابلیت انعطاف بیشتری را فراهم می‌نماید. می‌توان تنها زیرمجموعه‌ای از جدول‌ها را Replicate نمود و حتی ردیف‌ها را فیلتر کرد. می‌توان دو Subscription از Publicationهای موجود در دیتابیسهای جداگانه داشت که هرکدام به یک دیتابیس ارسال می‌شوند و در نتیجه جمع‌آوری داده‌ها از منابع گوناگون در یک مکان امکان‌پذیر می‌گردد. همچنین می‌توان منابع متعددی از داده‌ها را به صورت Bi-Directionally همسان‌سازی نمود. این کار اجازه می‌دهد که داده‌ها بتوانند در مکان‌ها دیگر نیز تغییر کنند و همچنین می‌توان کارهایی همچون تغییر داده‌های Replicate شده را در حین جابجایی نیز انجام داد یا اینکه بدون در نظر گرفتن حذفیات، صرفا ورود و بروزرسانی داده‌ها را Replicate نمود.
SQL Server می‌تواند داده‌ها را از یک دیتابیس به دیتابیس دیگری، در همان سرور یا سرور دیگری، Replicate نماید. سرور دوم ممکن است به لحاظ فیزیکی در همان ساختمان یا مکان دیگری قرار داشته باشد. همچنین SQL Server اجازه می‌دهد تا داده‌ها به دیتابیس دیگر سیستم‌های مدیریتی، همچون اوراکل نیز Replicate گردد.
اجزای Replication در SQL Server 2012
برای اینکه Replication بتواند به خوبی کار کند، نیاز به چندین جزء دارد. در شکل زیر خلاصه‌ای سطح بالا از اجزایی درگیر در تنظیمات Replication نشان داده شده است.
اجزای تشکیل دهنده Replication در SQL Server 2012
اجزای نشان داده شده در این شکل شامل یک Publisher و دیتابیس مربوط به آن می‌باشد. این پایگاه داده خود دارای Publicationی است که دو Article دارد. قسمت Setup نیز شامل یک Distributor و دیتابیس مربوط به آن می‌باشد. یک Subscriber و دیتابیس مربوط به آن هم در این قسمت قرار دارد که دارای Subscription می‌باشد. و بالاخره، این تنظیمات شامل Replication Agentهای لازم برای درایو نمودن این فرآیندها می‌باشد. همچنین در تنظیمات Replication تعداد کمی Job های نگهداری وجود دارد که در شکل نشان داده نشده است و در قسمت های بعدی این مقاله به بررسی هر یک از این اجزا خواهیم پرداخت.
ـــــــــــــــــــــــــــ
اجزای تشکیل دهنده SQL Server Replication – قسمت اول
اجزای تشکیل دهنده SQL Server Replication – قسمت دوم (پایانی)
