الأسئلة الشائعة- خدمة ترحيل قاعدة البيانات من Azure

Azure Database Migration Service هي خدمة مدارة بالكامل مصممة لتمكين عمليات الترحيل السلسة من مصادر قاعدة بيانات متعددة إلى أنظمة Azure Data الأساسية بأقل وقت تعطل. الخدمة حاليا في التوافر العام، مع تركيز جهود التطوير المستمرة على:

• الموثوقية والأداء.
• إضافة متكررة لأزواج المصدر-الهدف.
• استمرار الاستثمار في عمليات الترحيل الخالية من الاحتكاك.

تدعم الخدمة حاليا أزواج المصدر/الهدف المختلفة أو سيناريوهات الترحيل. للحصول على قائمة كاملة بحالة كل سيناريو ترحيل متوفر، راجع المقالة حالة سيناريوهات الترحيل التي تدعمها خدمة ترحيل قاعدة بيانات Azure.

عند الترحيل من SQL Server، تكون المصادر المدعومة لخدمة ترحيل قاعدة بيانات Azure هي SQL Server 2008 والإصدارات الأحدث. إذا كنت تستخدم Azure Data Studio مع ملحق ترحيل SQL، فإن المصادر المدعومة هي SQL Server 2008 من خلال SQL Server 2022.

يمكنك استخدام خدمة ترحيل قاعدة بيانات Azure لإجراء عمليات الترحيل دون اتصال بالإنترنت أو عبر الإنترنت. مع الترحيل دون اتصال بالإنترنت، يبدأ وقت تعطل التطبيق عند بدء الترحيل. مع الترحيل عبر الإنترنت، يقتصر وقت التعطل على الوقت الذي يجب تقليصه في نهاية الترحيل. نوصي بأن تختبر الترحيل في وضع عدم الاتصال بالإنترنت لتحديد ما إذا كان وقت التوقف مقبولاً أم لا؛ إذا لم يكن الأمر كذلك، فقم بالترحيل عبر الإنترنت.

Azure Database Migration Service هي الطريقة المفضلة لترحيل قاعدة البيانات إلى Microsoft Azure على نطاق واسع. لمزيد من المعلومات حول كيفية مقارنة خدمة ترحيل قاعدة بيانات Azure بأدوات ترحيل قاعدة بيانات Microsoft الأخرى، وللتوصيات حول استخدام الخدمة لسيناريوهات مختلفة، راجع تمييز أدوات وخدمات ترحيل قاعدة البيانات من Microsoft.

يساعد Azure Migrate في ترحيل الأجهزة الظاهرية المحلية إلى Azure IaaS. تقيم الخدمة ملاءمة الترحيل والتحجيم المستند إلى الأداء، وتوفر تقديرات التكلفة لتشغيل الأجهزة الظاهرية المحلية في Azure. يعد Azure Migrate مفيدا في عمليات ترحيل الرفع والتحويل لأحمال العمل المحلية المستندة إلى VM إلى أجهزة Azure IaaS الظاهرية. ومع ذلك، على عكس خدمة ترحيل قاعدة بيانات Azure، لا يعد Azure Migrate خدمة ترحيل قاعدة بيانات متخصصة تقدم لمنصات قاعدة بيانات Azure PaaS العلائقية مثل قاعدة بيانات Azure SQL أو مثيل Azure SQL المدار.

‏‏لا. لا تخزن خدمة ترحيل قاعدة البيانات بيانات العملاء.

بالنسبة لأهداف Azure SQL VM وAzure SQL MI، يستخدم DMS الترحيل الفعلي، أي باستخدام النسخ الاحتياطي والاستعادة. كما هو موضح أدناه، يحدد وضع الترحيل المختار كيفية الاحتفاظ بالبيانات متسقة بين المصدر والهدف.

• الترحيل دون اتصال: أثناء الترحيل دون اتصال إلى أهداف Azure SQL VM وAzure SQL MI، يبدأ وقت تعطل التطبيق عند بدء الترحيل. سيقوم DMS باستعادة جميع ملفات النسخ الاحتياطي إلى الهدف، طالما تم نقل أحدث ملف/ملفات احتياطية من المصدر إلى تخزين شبكة SMB أو إلى حاوية Azure blob (وفقا لتكوين الترحيل). إذا تم أخذ النسخ الاحتياطي باستخدام خيار CHECKSUM، فإن عملية استعادة DMS تنفذ تلقائيا التحقق من الصحة. في حالة عدم وجود المجموع الاختباري، يتم التحقق من سلامة النسخ الاحتياطي بشكل صريح قبل الاستعادة. وهذا يضمن أن ملف الاستعادة مطابق لملف النسخ الاحتياطي ومن ثم يكون له نفس البيانات. يمكنك التحقق من جميع ملفات النسخ الاحتياطي بما في ذلك اسم ملف النسخ الاحتياطي الأخير من المصدر مع تطبيق/استعادة ملف النسخ الاحتياطي على الهدف الموضح في صفحة مراقبة ترحيل DMS والتحقق من صحة المجموع الاختباري الخاص بها.

• الترحيل عبر الإنترنت: أثناء الترحيل عبر الإنترنت إلى أهداف Azure SQL VM وAzure SQL MI، يبدأ وقت التعطل بمجرد بدء نقل الترحيل جنبا إلى جنب مع إيقاف التطبيق. سيقوم DMS باستعادة جميع ملفات النسخ الاحتياطي إلى الهدف، طالما تم نقل أحدث ملف/ملفات احتياطية من المصدر إلى تخزين شبكة SMB أو إلى حاوية Azure blob (وفقا لتكوين الترحيل). بعد الضغط على زر الانتقال، يعرض DMS عدد ملفات/ملفات النسخ الاحتياطي المعلقة (إن وجدت) الموجودة على تخزين شبكة SMB أو حاوية كائن ثنائي كبير الحجم Azure ولا تزال يتعين تطبيقها/استعادتها على الهدف. إذا تم أخذ النسخ الاحتياطي باستخدام خيار CHECKSUM، فإن عملية استعادة DMS تنفذ تلقائيا التحقق من الصحة. في حالة عدم وجود المجموع الاختباري، يتم التحقق من سلامة النسخ الاحتياطي بشكل صريح قبل الاستعادة. وهذا يضمن أن ملف الاستعادة مطابق لملف النسخ الاحتياطي ومن ثم يكون له نفس البيانات. يمكنك التحقق من جميع ملفات النسخ الاحتياطي بما في ذلك اسم ملف النسخ الاحتياطي الأخير من المصدر مع تطبيق/استعادة ملف النسخ الاحتياطي على الهدف الموضح في صفحة مراقبة ترحيل DMS والتحقق من صحة المجموع الاختباري الخاص بها.

بالنسبة لأهداف Azure SQL DB، يقوم DMS بالترحيل المنطقي في حالة Azure SQL DB، أي أنه ينسخ البيانات من جداول قاعدة بيانات SQL المصدر ويكتبها في جداول قاعدة بيانات Azure SQL الهدف. نظرا لأن DMS يدعم الترحيل دون اتصال فقط إلى Azure SQL DB، يبدأ وقت تعطل التطبيق عند بدء الترحيل. يمكنك مراقبة عدد الصفوف المقروءة والتحقق من صحتها (من جدول قاعدة البيانات المصدر) ونسخها (مكتوبة لاستهداف جدول Azure SQL DB) من صفحة مراقبة الترحيل. كتأكيد إضافي، يمكنك تشغيل TSQL أدناه للحصول على المجموع الاختباري في قواعد البيانات المصدر والوجهة والتحقق من تطابق بيانات المصدر واستعادتها.

  "SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
  

ملاحظة: شريطة عدم كتابة أي تطبيق/تطبيقات إلى المصدر أو قاعدة بيانات الهدف. يمكنك أيضا الاستفادة من أدوات مثل أداة مقارنة قاعدة البيانات لمقارنة البيانات.

تحتوي القائمة التالية على موارد Azure التي قد يتم إنشاؤها خلف الكواليس لتنفيذ ترحيل البيانات. قد تختلف الخدمات المستخدمة حسب سيناريو الترحيل.

• Azure Monitor
• جهاز Azure الافتراضي
• تخزين Azure
• ناقل خدمة Azure
• Azure Data Factory

داخليا، يحتفظ DMS بمخزن بيانات التعريف الذي يتضمن معلومات حول مواقع الشبكة وبيانات الاعتماد وملفات النسخ الاحتياطي والمهام المكتملة. يتم تشفير بيانات الاعتماد والحقول المحددة، مثل مفاتيح الحساب. يتم تجزئة البيانات، مثل أسماء الجداول التي قد يتم تضمينها في بيانات تتبع الاستخدام. قد تظهر أسماء المستخدمين في نص عادي في سجلات الخدمة ولكن كلمات المرور لن تظهر أبدا. يتم عزل بيانات تتبع الاستخدام حسب المنطقة، والتي تحكمها نهج الاستبقاء ومتاحة فقط للموظفين المصرح لهم داخل Microsoft لأغراض صالحة لاستكشاف الأخطاء وإصلاحها. تتبع أسماء موارد Azure، مثل أسماء الخادم وقاعدة البيانات، قواعد موارد Azure.

يستخدم DMS (الكلاسيكي) مواضيع ناقل خدمة Azure لتسهيل الاتصال بين طبقات الحوسبة. مواضيع ناقل خدمة Azure فريدة لكل مثيل DMS ويتم تشفير جميع البيانات الشخصية.

مثيل Azure SQL المدار وSQL Server على أجهزة Azure الظاهرية

يتم ترحيل المخطط والبيانات باستخدام النسخ الاحتياطي والاستعادة. العملاء لديهم خيار الاستعادة من مشاركة شبكة اتصال أو مباشرة من حاوية تخزين. قد يتم استهلاك ملف يحتوي على بيانات أداء Windows لتوفير توصيات اختيارية (ولكن مستحسنة للغاية) لتحجيم حمل العمل.

قاعدة بيانات Azure SQL

يتم تنفيذ عمليات الترحيل إلى قاعدة بيانات Azure SQL في خطوتين. الخطوة الأولى هي ترحيل المخطط. يستخدم DMS (كلاسيكي) كائنات إدارة SQL (SMO) لترحيل المخطط. الخطوة الثانية هي ترحيل البيانات الفعلي. يتم استخدام SqlBulkCopy لإجراء ترحيل البيانات. لا يدعم DMS ترحيل المخطط. يتم ترحيل البيانات باستخدام Azure Data Factory. اختياريا ولكن يوصى به بشدة، قد يتم استهلاك ملف يحتوي على بيانات أداء Windows لتوفير توصيات تغيير حجم حمل العمل.

قاعدة بيانات Azure لـ PostgreSQL

في هذا السيناريو، يستخرج المستخدم النهائي بيانات التعريف، في هذه الحالة المخطط، باستخدام pg_dump الأدوات المساعدة لسطر الأوامر و pg_restore . عند تكوين التقاط بيانات التغيير ل PostgreSQL، يستخدم pg_dump DMS داخليا ولإجراء pg_restore البذر الأولي ل CDC. يتم تخزين البيانات في تخزين مؤقت مشفر لا يمكن الوصول إليه إلا لمثيل DMS الخاص بك. قد يتم استهلاك ملف يحتوي على بيانات أداء Windows لتوفير توصيات اختيارية (ولكن مستحسنة للغاية) لتحجيم حمل العمل.

قاعدة بيانات Azure لـ MySQL

في هذا السيناريو، يتم استخراج المخطط وترحيله بواسطة DMS (كلاسيكي) باستخدام mysql-net/MySqlConnector. حيثما أمكن، يتم استخدام النسخ المتماثل ل Binlog MySQL لنسخ كل من تغييرات البيانات والمخطط. يتم استخدام التعليمات البرمجية المخصصة لمزامنة التغييرات حيث لا يمكن استخدام النسخ المتماثل ل binlog.

MongoDB إلى Azure Cosmos DB

يقوم DMS باستخراج البيانات وإدراجها من MongoDB في Cosmos DB. كما يوفر خيار استخراج البيانات من تفريغ BSON أو JSON.

بالنسبة إلى تفريغ BSON، يستخدم DMS البيانات بتنسيق bsondump داخل نفس المجلد داخل حاوية كائن ثنائي كبير الحجم. يبحث DMS فقط عن ملفات بيانات التعريف باستخدام التنسيق collection.metadata.json.

بالنسبة إلى عمليات تفريغ JSON، سيقوم DMS بقراءة الملفات الموجودة في مجلدات حاوية كائن ثنائي كبير الحجم المسماة بعد قواعد البيانات التي تحتوي عليها. داخل كل مجلد قاعدة بيانات، يستخدم DMS ملفات البيانات الموضوعة data في المجلد الفرعي فقط. يبحث DMS فقط في الملفات الموضوعة metadata في المجلد الفرعي والمسماة باستخدام تنسيق collection.json بيانات التعريف.

Oracle إلى قاعدة بيانات Azure ل PostgreSQL

مثل Oracle إلى قاعدة بيانات Azure SQL، في هذا السيناريو، يتم استهلاك تقرير AWR أو ملف Windows perfmon لتوفير توصيات اختيارية (ولكن مستحسنة للغاية) لتحجيم حمل العمل. ora2pg تستخدم المكتبة لاستخراج المخطط وترحيل البيانات يدويا بواسطة المستخدم الذي يقوم بالترحيل.

يعتمد DMS (كلاسيكي) على تكوين شبكة العملاء. إذا كان مصدر الترحيل يستخدم نقاط نهاية خاصة، فإننا نستخدم نقاط النهاية الخاصة، وهو التكوين المفضل. نستخدم نقاط النهاية العامة إذا كانت الخيار الوحيد.

يستخدم DMS ADF بشكل كبير خلف الكواليس لجدولة حركة البيانات وتنسيقها. بالإضافة إلى ذلك، لا يختلف وقت تشغيل التكامل المستضاف ذاتيا عن الوقت الذي ربما تستخدمه بالفعل لتدفقات ADF الخاصة بك. لمزيد من المعلومات حول مشكلات جدار الحماية والخادم الوكيل، راجع إنشاء وقت تشغيل تكامل مستضاف ذاتيا وتكوينه.

يتم تشفير جميع بيانات العملاء في حالة الراحة. تظهر بعض بيانات التعريف، بما في ذلك على سبيل المثال لا الحصر أسماء الخوادم المنطقية وأسماء قواعد البيانات، بالإضافة إلى حالة الترحيل وتقدم الترحيل في سجلات الخدمة غير المشفرة.

تتم حماية جميع البيانات المتنقلة بتشفير TLS 1.2 بشكل افتراضي. يحتاج العملاء القدامى الذين يحتاجون إلى إصدارات قديمة من TLS إلى تمكين الإصدارات المطلوبة في صفحة مدخل DMS (الكلاسيكي). بالنسبة إلى DMS، يمكن تكوين الجهاز الذي تم تثبيت وقت تشغيل التكامل المستضاف ذاتيا عليه للسماح بإعدادات TLS المطلوبة لاستيعاب العملاء القدامى. لمزيد من المعلومات حول تكوين TLS ل SQL Server، راجع KB3135244 - دعم TLS 1.2 ل Microsoft SQL Server.

حيثما أمكن، يتم استخدام نقاط النهاية الخاصة. إذا لم تكن نقاط النهاية الخاصة خيارا، يتم استخدام نقاط النهاية العامة للاتصال بين طبقات الخدمة. بغض النظر عن نوع نقطة النهاية، يتم تخصيص/تحديد نطاق جميع الموارد لمثيل معين من DMS وتأمينها ببيانات اعتماد فريدة.

نحن لا ندعم المفاتيح المدارة من قبل العملاء لتشفير البيانات داخل مستوى البيانات أو مستوى التحكم. ومع ذلك، يتم تشفير جميع بيانات العملاء الثابتة باستخدام مفاتيح تديرها الخدمة. تظهر بعض بيانات التعريف، بما في ذلك على سبيل المثال لا الحصر أسماء الخوادم المنطقية وأسماء قواعد البيانات، بالإضافة إلى حالة الترحيل والتقدم في سجلات الخدمة في نموذج غير مشفر.

يتم تشفير جميع البيانات المتنقلة باستخدام تشفير TLS 1.2 بشكل افتراضي. تسمح صفحة مدخل DMS (الكلاسيكي) باستخدام الإصدارات القديمة من TLS للعملاء القدامى. بالنسبة إلى DMS، يمكن تكوين الجهاز الذي تم تثبيت وقت تشغيل التكامل المستضاف ذاتيا عليه للسماح بإدارة إعدادات TLS لاستيعاب العملاء القدامى. لمزيد من المعلومات حول تكوين TLS ل SQL Server، راجع KB3135244 - دعم TLS 1.2 ل Microsoft SQL Server.

لا نكشف عن إمكانية تشفير البيانات على مستوى التحكم أو البيانات باستخدام المفاتيح المدارة من قبل العملاء. يتم حذف جميع بيانات العميل في اللحظة التي يتم فيها حذف مثيل DMS باستثناء سجلات الخدمة. يتم الاحتفاظ بسجلات خدمة DMS لمدة 30 يوما فقط.

TDE

يدعم DMS ترحيل المفاتيح المدارة للعملاء (CMK) إلى Azure SQL لتشفير قاعدة البيانات الشفاف (TDE). للحصول على إرشادات خطوة بخطوة لترحيل مفاتيح TDE، راجع البرنامج التعليمي: ترحيل قواعد البيانات الممكنة ل TDE (معاينة) إلى Azure SQL في Azure Data Studio.

تشفير الخلية

تتم معالجة تشفير مستوى الخلية على مستوى المخطط. تقوم أدوات ترحيل المخطط بترحيل كافة كائنات المخطط بما في ذلك الوظائف والإجراءات المخزنة اللازمة لتنفيذ تشفير مستوى الخلية.

مشفر دومًا

لا يدعم DMS حاليا ترحيل Always Encrypted عبر السيناريوهات التي يتم فيها ترحيل صفوف البيانات الفردية بين المصدر والهدف. يتم ترحيل الأعمدة المشفرة عبر Always Encrypted كما هو متوقع في السيناريوهات التي تستخدم النسخ الاحتياطي/الاستعادة، مثل الانتقال إلى Azure SQL VM أو مثيل Azure SQL المدار من مثيل SQL Server موجود.

نحن لا ننفذ أي تحكم في الوصول على علم بالموقع يتجاوز ما هو متاح بالفعل في Azure. توجد جميع البيانات المقترنة بمثيل DMS في نفس المنطقة مثل مورد DMS.

يتم استخدام خدماتنا في بيئات مختلفة مع ضوابط داخلية وعمليات تجارية مختلفة. ينقل DMS البيانات من وإلى أي مكان يمكن للحساب الذي يستخدمه الوصول إليه. تقع على عاتق المستخدم مسؤولية فهم الأذونات وعناصر التحكم الداخلية للبيئة التي يعمل فيها. من المهم بشكل خاص التأكد من أن الحساب الذي يستخدمه DMS للاتصال بالمصدر لديه حق الوصول لمشاهدة جميع البيانات المراد ترحيلها من المصدر.

حقن VNET هو إجراء إضافة مورد Azure موجود داخل مستأجر Microsoft، إلى شبكة فرعية في VNet ضمن مستأجر العميل. تم اتباع هذا النهج مع DMS للسماح لنا بإدارة الحساب نيابة عن العميل، مع الحفاظ على الوصول إلى موارد العملاء. نظرا لأن الشبكة في اشتراك العميل، لا يمكن لشركة Microsoft إدارة الجهاز الظاهري بعد إصدار أوامر البدء أو الإيقاف أو الحذف أو التوزيع. تتطلب جميع إجراءات الإدارة الأخرى التي تحتاج إلى الوصول إلى الجهاز الظاهري طلب دعم وموافقة بدأها العميل.

هناك العديد من المتطلبات الأساسية المطلوبة للتأكد من أن Azure Database Migration Service تعمل بسلاسة عند تنفيذ عمليات ترحيل قاعدة البيانات. تنطبق بعض المتطلبات الأساسية عبر جميع السيناريوهات (أزواج المصدر والهدف) التي تدعمها الخدمة، بينما المتطلبات الأساسية الأخرى فريدة لسيناريو معين.

تتضمن المتطلبات الأساسية لخدمة ترحيل قاعدة بيانات Azure الشائعة عبر جميع سيناريوهات الترحيل المدعومة الحاجة إلى:

• قم بإنشاء Microsoft Azure Virtual Network for Azure Database Migration Service باستخدام نموذج نشر Azure Resource Manager، والذي يوفر اتصالًا من موقع إلى موقع بالخوادم المصدر المحلية باستخدام إما ExpressRoute أو VPN.
• تأكد من أن قواعد مجموعة أمان الشبكة الظاهرية الخاصة بك لا تحظر المنفذ 443 ل ServiceTags من ServiceBus والتخزين وAzureMonitor. لمزيد من التفاصيل عن تصفية نسبة استخدام الشبكة للشبكة الظاهرية الخاصة بمجموعة أمان الشبكة (NSG)، راجع مقالتصفية نسبة استخدام الشبكة باستخدام مجموعات أمان الشبكة.
• عند استخدام جهاز جدار حماية أمام قاعدة (قواعد) البيانات المصدر، قد تحتاج إلى إضافة قواعد جدار الحماية للسماح لخدمة Azure Database Migration Service بالوصول إلى قاعدة (قواعد) البيانات المصدر للترحيل.

للحصول على قائمة بجميع المتطلبات الأساسية المطلوبة للتنافس على سيناريوهات ترحيل معينة باستخدام Azure Database Migration Service، راجع البرامج التعليمية ذات الصلة في وثائق Azure Database Migration Service.

قد تحتاج إلى إضافة قواعد جدار الحماية التي تسمح لخدمة ترحيل قاعدة بيانات Azure بالوصول إلى قاعدة البيانات المصدر للترحيل. عنوان IP للخدمة ديناميكي، ولكن إذا كنت تستخدم ExpressRoute، يتم تعيين هذا العنوان بشكل خاص بواسطة شبكة شركتك. أسهل طريقة لتحديد عنوان IP المناسب هي البحث في نفس مجموعة الموارد مثل مورد Azure Database Migration Service المتوفر للعثور على واجهة الشبكة المقترنة. عادة ما يبدأ اسم مورد واجهة الشبكة ببادئة NIC متبوعا بحرف فريد وتسلسل رقمي، على سبيل المثال، 'NIC-jj6tnztnmarpsskr82rbndyp'. بتحديد مورد واجهة الشبكة هذا، يمكنك مشاهدة عنوان IP الذي يجب تضمينه في قائمة السماح في صفحة مدخل Azure نظرة عامة على المورد.

قد تحتاج أيضا إلى تضمين مصدر المنفذ الذي يستمع إليه SQL Server في قائمة السماح. بشكل افتراضي، إنه المنفذ 1433، ولكن قد يتم تكوين SQL Server المصدر للاستماع إلى المنافذ الأخرى أيضا. في هذه الحالة، تحتاج إلى تضمين هذه المنافذ في قائمة السماح أيضا. يمكنك تحديد المنفذ الذي يستمع إليه SQL Server باستخدام استعلام Dynamic Management View:

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

يمكنك أيضا تحديد المنفذ الذي يستمع إليه SQL Server عن طريق الاستعلام عن سجل أخطاء SQL Server:

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

في حين أن العديد من برامج Microsoft التعليمية التي يمكن أن ترشدك خلال عملية إعداد شبكة ظاهرية، تظهر الوثائق الرسمية في المقالة Azure Virtual Network.

أثناء ترحيل قاعدة بيانات نموذجية وبسيطة، يمكنك:

1. إنشاء قاعدة (قواعد) بيانات هدف.
2. تقييم قاعدة (قواعد) البيانات المصدر.
   • بالنسبة إلى عمليات الترحيل المتجانسة، قم بتقييم قاعدة (قواعد) البيانات الحالية باستخدام DMA.
   • بالنسبة إلى عمليات الترحيل غير المتجانسة (من مصادر المنافسة)، قم بتقييم قاعدة البيانات (قواعد البيانات) الحالية باستخدام SSMA. يمكنك أيضا استخدام SSMA لتحويل كائنات قاعدة البيانات وترحيل المخطط إلى النظام الأساسي المستهدف.
3. إنشاء مثيل لخدمة Azure Database Migration Service.
4. إنشاء مشروع ترحيل يحدد قاعدة (قواعد) البيانات المصدر وقاعدة (قواعد) البيانات الهدف والجداول المراد ترحيلها.
5. بدء التحميل الكامل.
6. اختر التحقق اللاحق.
7. قم بإجراء تبديل يدوي لبيئة الإنتاج الخاصة بك إلى قاعدة البيانات الجديدة المستندة إلى السحابة.

إذا كنت تواجه مشكلة في الاتصال بنظام قاعدة البيانات المصدر أثناء العمل على الترحيل، فقم بإنشاء جهاز ظاهري في نفس الشبكة الفرعية للشبكة الظاهرية التي قمت بإعداد مثيل DMS الخاص بك بها. في الجهاز الظاهري، يجب أن تكون قادرا على تشغيل اختبار اتصال، مثل استخدام ملف UDL لاختبار اتصال ب SQL Server أو تنزيل Robo 3T لاختبار اتصالات MongoDB. إذا نجح اختبار الاتصال، فلا ينبغي أن تواجه مشكلة في الاتصال بقاعدة البيانات المصدر. إذا لم ينجح اختبار الاتصال، فاتصل بمسؤول الشبكة.

إذا أوقف المستخدم خدمة ترحيل قاعدة بيانات Azure (DMS) بشكل صريح أو إذا كانت الخدمة غير نشطة لمدة 24 ساعة، تكون الخدمة في حالة إيقاف أو إيقاف مؤقت تلقائي. في كل حالة، الخدمة غير متوفرة وفي حالة توقف. لاستئناف عمليات الترحيل النشطة، أعد تشغيل الخدمة.

يمكنك القيام ببعض الأشياء لتسريع ترحيل قاعدة البيانات باستخدام الخدمة:

بالنسبة إلى DMS(Classic)-

• استخدم مستوى التسعير متعدد الأغراض العامة لوحدة المعالجة المركزية عند إنشاء مثيل الخدمة للسماح للخدمة بالاستفادة من وحدات المعالجة المركزية الظاهرية المتعددة للتوازي ونقل البيانات بشكل أسرع.
• قم بتوسيع نطاق مثيل هدف قاعدة بيانات Azure SQL بشكل مؤقت إلى SKU الطبقة المتميزة أثناء عملية ترحيل البيانات لتقليل تقييد قاعدة بيانات Azure SQL التي قد تؤثر على أنشطة نقل البيانات عند استخدام وحدات SKU ذات المستوى الأدنى.

بالنسبة إلى DMS-

• إذا كنت تقوم بنسخ النسخ الاحتياطية من مشاركة الملفات المحلية إلى تخزين Azure blob OR أثناء إجراء الترحيل إلى قاعدة بيانات Azure SQL الهدف، فإن DMS يستخدم عقدة SHIR كحوسبة لها. لذا تأكد من مراقبة استخدام الموارد لعقدة SHIR هذه.
• قم بتحجيم مثيل هدف قاعدة بيانات Azure SQL بشكل مؤقت إلى SKU الطبقة المتميزة أثناء عملية ترحيل البيانات لتقليل تقييد قرص قاعدة بيانات Azure SQL التي قد تؤثر على أنشطة نقل البيانات عند استخدام وحدات SKU ذات المستوى الأدنى.
• لمزيد من المعلومات التفصيلية، راجع المدونة.

الخطوات التالية

• ما هي خدمة ترحيل قاعدة بيانات Azure.