منصة البيانات · SQL Server
ترحيل قواعد بيانات SQL Server: ترقية الإصدار والانتقال إلى السحابة دون توقف طويل
ترحيل قواعد بيانات SQL Server يكون في الغالب واحدًا من ثلاثة: ترقية إلى إصدار أحدث من SQL Server، أو نقل المحرك نفسه إلى خادم افتراضي في السحابة، أو الانتقال إلى خدمة مُدارة مثل Azure SQL تتغير معها قدرات الخادم. وتخطط إنتركي لكل منها من الرياض: تقييم أولًا، ثم تشغيل متوازٍ تبقى فيه القاعدة القديمة والجديدة على اتفاق، ثم تحويل على مراحل لكل منها شرط نجاح، مع خطة رجوع جُرِّبت مسبقًا، حتى لا يتوقف العمل بسبب النقل. وحين تكون أدوات Microsoft الأصلية هي الطريق الأقصر نستخدمها.
الملخص
نظرة سريعة
المشروع كله في جدول واحد، قبل التفاصيل.
- ما الذي يُنقل
- المخطط والإجراءات المخزنة والدوال ومهام SQL Server Agent وحسابات الدخول والبيانات، ومعها اتصالات التطبيقات التي تشير إليها
- المسارات الشائعة
- ترقية الإصدار؛ أو SQL Server على خادم افتراضي في السحابة؛ أو خدمة مُدارة: Azure SQL أو Amazon RDS for SQL Server أو Cloud SQL for SQL Server
- كيف يبقى التوقف قصيرًا
- تحميل أولي، ثم نسخ متماثل مستمر، ثم تشغيل متوازٍ، ثم تحويل على مراحل
- أين تبقى البيانات
- على بنيتكم داخل المملكة، أو في منطقة سحابية تُختار لكل فئة من البيانات
- طريقة التسعير
- لكل مشروع، بعد التقييم
- من يدعمه
- فريق البيانات في إنتركي، أثناء النقل وبعده
أي ترحيل لـ SQL Server تخططون له فعلًا
أغلب الطلبات التي تصلنا بعنوان «ترحيل SQL Server» تكون في الحقيقة واحدًا من أربعة أعمال، ولكل منها خطره. ويحدد التقييم أي هذه الأعمال يخص كل قاعدة بيانات، لأن البيئة الواحدة تحتاج كثيرًا إلى أكثر من مسار. فقد تُرقّى قاعدة على الخادم نفسه، وتنتقل أخرى إلى خدمة مُدارة، وتبقى ثالثة مكانها لأن نقلها لا يستحق الكلفة الآن.
- ترقية SQL Server. المحرك نفسه بإصدار أحدث، على الخوادم الحالية أو على خوادم جديدة. نقل البيانات سهل، والخطر في الاستعلامات والميزات التي يتغير سلوكها في الإصدار الأحدث.
- إعادة الاستضافة. نقل SQL Server كما هو إلى خادم افتراضي في Azure أو AWS أو Google Cloud. تبقى لكم السيطرة الكاملة على الخادم، ويبقى عليكم التحديث والنسخ الاحتياطي والتوافر العالي.
- خدمة مُدارة. Azure SQL Database أو Azure SQL Managed Instance أو Amazon RDS for SQL Server أو Cloud SQL for SQL Server. يتولى المزوّد جزءًا أكبر من المنصة، وفي المقابل تعمل بعض ميزات مستوى الخادم بطريقة مختلفة أو لا تعمل. وهنا يحتاج ترحيل SQL Server إلى السحابة إلى أكثر الفحص.
- الخروج من SQL Server. الانتقال إلى محرك آخر، وغالبًا لتغيير وضع التراخيص. هنا يُعاد كتابة المخطط والشيفرة المخزنة، فهو مشروع مختلف، وتشرحه صفحتنا عن الترحيل من SQL Server إلى PostgreSQL.
مقارنة الوجهات: ما الذي يبقى وما الذي يُفحص
| الوجهة | ما يبقى كما هو | ما تفحصونه قبل الالتزام |
|---|---|---|
| إصدار أحدث من SQL Server على خادم جديد | المحرك والأدوات وخبرة مديري قواعد البيانات لديكم | الميزات المتوقفة، وخطط الاستعلام تحت مستوى التوافق الجديد، وإبقاء الخادم القديم طريقًا للرجوع |
| إصدار أحدث من SQL Server على الخادم نفسه | أسماء الخوادم والتخزين ونصوص الاتصال | لا يوجد خادم قديم للرجوع إليه، فالرجوع هو نسخة احتياطية واستعادة جُرِّبتا |
| SQL Server على خادم افتراضي في السحابة | سيطرة كاملة على الخادم، قريبة مما هي عليه داخل المنشأة | المنطقة، وزمن الشبكة إلى التطبيقات التي تبقى مكانها، وطريقة احتساب التراخيص لدى المزوّد |
| Azure SQL Managed Instance | أغلب سلوك مستوى الخادم، مع تشغيل Microsoft للمنصة | كل ميزة تستخدمها القاعدة، مقابل وثائق Microsoft الحالية للخدمة |
| Azure SQL Database | قاعدة البيانات ولغة T-SQL فيها، قاعدةً مفردة أو ضمن مجموعة | كل ما يتجاوز القاعدة الواحدة: مهام Agent، والاستعلامات بين القواعد، والخوادم المرتبطة، والوصول إلى الملفات |
| Amazon RDS أو Cloud SQL for SQL Server | محرك SQL Server، ويتولى المزوّد النسخ الاحتياطي والتحديث | الإصدارات والطبعات والميزات التي تدعمها الخدمة، وفي أي المناطق |
لا يحسم أي صف في هذا الجدول القرار. فالإجابة تأتي من قراءة ما تستخدمه قاعدتكم فعلًا، وهي أول مهمة في التقييم.
ترقية SQL Server: انقلوا المحرك أولًا، وغيّروا السلوك لاحقًا
تبدو ترقية الإصدار الحالة الآمنة، وهي كذلك عادةً، بشرط الفصل بين أمرين. الأول إصدار المحرك. والثاني مستوى التوافق لقاعدة البيانات (compatibility level)، وهو يحكم جزءًا كبيرًا من سلوك محسّن الاستعلامات. فالقاعدة التي تنتقل إلى إصدار أحدث يمكن أن تحتفظ بمستوى توافقها القديم مدةً، فينتقل المحرك أولًا، ثم يأتي تغيير السلوك بعد اختباره. وتذكر وثائق Microsoft مستويات التوافق التي يدعمها كل إصدار، ونتحقق من وضعكم في التقييم.
اقرأ المزيد
وقبل الترقية نأخذ خط أساس من بيئة الإنتاج: أثقل الاستعلامات، ومدة كل منها، وأوقات الانتظار فيها. وبعد الترقية تُظهر القياسات نفسها على الإصدار الجديد هل تراجع شيء، استعلامًا استعلامًا، لا بحسب الشكاوى. ويشمل خط الأساس أيضًا مدة المهام الليلية وحجم السجلات ونمو الملفات، لأنها قد تتغير بعد الترقية دون أن يلاحظها أحد في الأيام الأولى. وإن لم يكن لديكم هذا السجل بعد، فإننا نجمعه عادةً عبر مراقبة SQL Server بـ Redgate Monitor.
وفي الجولة نفسها نبحث عن الميزات التي يصنّفها الإصدار المستهدف متوقفة أو محذوفة، وعن العناصر التي تعيش خارج القاعدة ويسهل نسيانها: مهام Agent، والخوادم المرتبطة، وحسابات الدخول، والشهادات، وخطط الصيانة.
روابط ذات صلةمراقبة SQL Server بـ Redgate Monitor
ترحيل SQL Server إلى Azure أو AWS أو Google Cloud من السعودية
الانتقال إلى السحابة يضيف أربعة أسئلة لا تطرحها الترقية.
- أين يجوز أن تكون البيانات. تصنيف بياناتكم هو الذي يحدد هل يجوز استضافة القاعدة خارج المملكة أصلًا. تشغّل Google Cloud منطقة في الدمام (me-central2). وأعلنت AWS عن منطقة في السعودية، ولا ينبغي أن تعتمد الخطة عليها حتى تظهر في قائمة مناطق AWS المتاحة. أما Azure وكل مزوّد آخر، فراجعوا قائمة المناطق الحالية يوم القرار، لا شريحة عن الخطط المستقبلية. ويشرح دليلنا عن إقامة البيانات في السعودية هذا القرار.
- أي خدمة. الخدمة المُدارة توفر عليكم عمل التشغيل وتأخذ جزءًا من السيطرة. والخادم الافتراضي يبقي السيطرة ويبقي العمل. والجدول أعلاه نقطة البداية، أما القرار فتحسمه الميزات التي تستخدمها القاعدة فعلًا.
- كيف تُحتسب التراخيص. يتغير ترخيص SQL Server بحسب الوجهة: فبحسب الخدمة، يكون الترخيص مضمّنًا في سعر المزوّد، أو يُنقل من اتفاقيتكم بحسب شروط Microsoft. احسموا ذلك مع المزوّد ومع جهة التراخيص لديكم في Microsoft قبل تقدير الحجم، لأنه قد يغيّر أي الوجهات أقل كلفة.
- الشبكة إلى ما يبقى مكانه. والتطبيقات التي تبقى داخل المنشأة بينما تنتقل القاعدة ستتأثر بالشبكة بينهما. فالتطبيقات التي ترسل طلبات صغيرة كثيرة لكل شاشة هي أول ما يُختبر، ومعها المهام التي تنقل ملفات كبيرة بين القاعدة وخوادم أخرى، لأن أثر الشبكة يظهر فيها أولًا.
أدوات ترحيل SQL Server، وأين يأتي دور iblync
في النقل المماثل تكون الطرق الأصلية في الغالب هي الأقصر: النسخ الاحتياطي والاستعادة، أو شحن السجلات (log shipping)، أو نسخة متماثلة تُرقّى عند التحويل، أو أدوات Microsoft نفسها للترحيل إلى Azure. فإذا كان المصدر والهدف كلاهما SQL Server، ووُجد مسار أصلي مدعوم يغطي إصداراتكم ونافذة التوقف لديكم، فهذا المسار عادةً أقل كلفة وأفضل دعمًا، وننصحكم به. ولا نضيف إلى مشروعكم أداة جديدة ليس لها عمل واضح فيه.
اقرأ المزيد
أما iblync، منصة إنتركي لترحيل البيانات ونسخها، المبنية في السعودية، فيأتي دوره حين يقصر المسار الأصلي: تشغيل متوازٍ طويل تنتقل فيه الخدمات واحدة بعد أخرى، أو نقل بين سحابتين أو إلى محرك مختلف، أو مدة يقبل فيها الطرفان الكتابة، أو نافذة توقف أقصر من أن تتسع لاستعادة القاعدة كاملة. وقائمة الموصلات المنشورة لـ iblync تشمل SQL Server. وهو يتحكم في معدله حتى لا ينافس النسخ المتماثل الإنتاج، وإذا غاب الهدف تنتظر التغييرات في طابور بدل أن تضيع. ونتحقق في التقييم من الإصدار والطبعة وزوج المصدر والهدف الذي يحتاجه مشروعكم، وحين لا يكون نظام ما مغطًّى بعد تُبنى له موصلات مخصصة.
روابط ذات صلةiblync
كيف تنفذ إنتركي ترحيل قواعد بيانات SQL Server
-
التقييم.
الإصدارات والطبعات والحجم ومعدل التغيير والميزات المستخدمة والمهام وحسابات الدخول والتطبيقات المتصلة ونافذة التوقف ووضع إقامة البيانات. والنتيجة توصية مكتوبة، وقد تكون البقاء على الوضع الحالي.
-
اختيار المسار لكل قاعدة.
ترقية أو إعادة استضافة أو خدمة مُدارة أو محرك مختلف، مع كتابة الأسباب.
-
بناء الهدف واختباره.
المخطط والصلاحيات والمهام والإعدادات على الهدف، واختبارها على نسخة تشبه بيانات الإنتاج ومقابل خط الأساس.
-
التحميل والنسخ المتماثل.
تحميل أولي، ثم نسخ متماثل مستمر بالأدوات الأصلية أو بـ iblync، والإنتاج يعمل.
-
التشغيل المتوازي.
القاعدتان على اتفاق. ويمكن نقل القراءة أولًا، خدمةً بخدمة، بخطوات يمكن التراجع عنها.
-
التحويل عبر بوابات.
مزامنة أخيرة في نافذة متفق عليها، ثم عدد الصفوف والمجاميع الاختبارية، ثم قرار المتابعة أو الإيقاف من شخص مسمّى من جهتكم، ثم تنتقل الكتابة. وتُجرَّب خطة الرجوع قبل ذلك.
-
التثبيت والتسليم.
ضبط الأداء على الإصدار أو الخدمة الجديدة، وإثبات النسخ الاحتياطي والاستعادة، ثم التسليم لمديري قواعد البيانات لديكم أو تشغيل إنتركي للمنصة.
العمل مع فريق بيانات في الرياض
يعمل مهندسو البيانات في إنتركي من الرياض، في أيام العمل السعودية، بالعربية والإنجليزية. ونافذة التحويل تكون كثيرًا في ليلة عطلة نهاية الأسبوع بتوقيت السعودية، والذين خططوا لها هم أنفسهم على الاتصال. ويمكن أن تعمل أداة النسخ المتماثل وقاعدة الهدف والأدوات على بنية داخل المملكة إذا تطلّب تصنيف البيانات ذلك، ويسجّل التقييم أين ستكون كل قاعدة قبل أن تنتقل أي بيانات. وللاطلاع على المنهجية التي تقوم عليها هذه الصفحة، من التقييم إلى التسليم، راجعوا خدمات ترحيل قواعد البيانات لدينا.
روابط ذات صلةخدمات ترحيل قواعد البيانات
ما الذي يحدد الكلفة والمدة
تُقدَّم العروض لكل مشروع بعد التقييم، وكذلك الجدول الزمني. والعوامل هي عدد القواعد والخوادم، وحجمها ومعدل تغيرها، وعدد الميزات التي تتعامل معها الوجهة بطريقة مختلفة، وعدد التطبيقات التي يلزم اختبارها من جديد، ونافذة التوقف، ونموذج النشر وإقامة البيانات، ومن يشغّل المنصة بعد ذلك. وعلى سبيل التقدير التقريبي، تُقاس ترقية قاعدة واحدة إلى إصدار أحدث على المنصة نفسها بالأسابيع، وانتقال بيئة كاملة إلى خدمة سحابية مُدارة مع تعديلات في التطبيقات بالأشهر. ويستبدل التقييم بهذين التقديرين خطة فعلية. وحين يُستخدم iblync فإنه يُسعَّر بعرض سعر، بحسب نظام المصدر ونظام الهدف وحجم البيانات.
أسئلة شائعة
هل يمكن ترحيل SQL Server دون أن يتوقف العمل؟
الجزء الطويل يجري والإنتاج يعمل: تحميل أولي، ثم نسخ متماثل مستمر، ثم تشغيل متوازٍ. وما يبقى نافذة قصيرة مخططة للمزامنة الأخيرة وتحويل الكتابة، ونحدد مدتها في التقييم بحسب ما تحتمله تطبيقاتكم.
هل نرقّي SQL Server قبل نقله إلى السحابة، أم نفعل الأمرين معًا؟
تغيير واحد في كل مرة أسهل في الإثبات. فالجمع بينهما يوفر تحويلًا واحدًا، لكنه يصعّب تتبّع أي تراجع في الأداء. وإذا كانت الخدمة المُدارة تعمل أصلًا بمحرك أحدث، فالنقل هو الترقية، ويصبح خط الأساس قبل النقل وبعده هو المرجع.
أي وجهة تناسبنا: Azure SQL Database أم Managed Instance أم خادم افتراضي؟
الوجهة التي تسمح بها الميزات التي تستخدمها قاعدتكم، بكلفة التشغيل التي تريدونها. فالاعتماد على ميزات مستوى الخادم مثل مهام Agent والخوادم المرتبطة يتجه إلى Managed Instance أو خادم افتراضي، والقاعدة المستقلة بذاتها قد تناسبها Azure SQL Database. ونقرأ القاعدة ونكتب لكم الأسباب.
هل تبقى بيانات SQL Server داخل السعودية بعد النقل؟
نعم، إذا كانت الوجهة بنيتكم داخل المملكة أو منطقة سحابية فيها. تشغّل Google Cloud منطقة في الدمام، أما المزوّدون الآخرون فراجعوا قائمة مناطقهم الحالية يوم القرار. وسياسة التصنيف لديكم هي التي تحدد أي القواعد يجوز استضافتها في الخارج.
كم يكلّف ترحيل SQL Server، وكم يستغرق؟
يحدد التقييم الأمرين معًا: عدد القواعد وحجمها، والميزات التي تتعامل معها الوجهة بطريقة مختلفة، والتطبيقات التي يلزم اختبارها، ونافذة التوقف. ولا توجد قائمة أسعار منشورة. ويُسعَّر iblync، حين يُستخدم، بحسب نظام المصدر ونظام الهدف وحجم البيانات.
من يتولى قاعدة البيانات بعد انتهاء الترحيل؟
مديرو قواعد البيانات لديكم بعد تسليم موثّق، أو إنتركي من الرياض ضمن نطاق مكتوب للخدمات المُدارة. وفي الحالتين تكون المراقبة قائمة من أول يوم على المنصة الجديدة.
التالي
اقرؤوا بعد ذلك
الخطوة التالية
خطّطوا لترحيل SQL Server
أخبرونا بإصدارات SQL Server وطبعاته، والحجم التقريبي للبيانات، والوجهة التي تفكرون فيها، ونافذة التوقف التي سيمنحها العمل.
أو مباشرةً
+966-11-2180999 [email protected]أبراج التعاونية، البرج الشمالي، الطابق السابع، طريق الملك فهد، العليا، ص.ب. ٥٦٨٣٥، الرياض ١١٥٦٤، المملكة العربية السعودية