مشاركة عبر

بنيات قاعدة بيانات Oracle على أجهزة Azure الظاهرية

  • مقالة

ينطبق على: ✔️ أجهزة Linux الظاهرية

تتضمن هذه المقالة معلومات حول نشر قاعدة بيانات Oracle عالية التوفر على Azure. بالإضافة إلى ذلك، يتعمق هذا الدليل في اعتبارات الإصلاح بعد كارثة. تم إنشاء هذه البنى استناداً إلى عمليات توزيع العملاء. ينطبق هذا الدليل فقط على Oracle Database Enterprise Edition.

إذا كنت مهتما بمعرفة المزيد حول تعظيم أداء قاعدة بيانات Oracle، فشاهد تصميم قاعدة بيانات Oracle وتنفيذها في Azure.

المتطلبات الأساسية

  • فهم المفاهيم المختلفة ل Azure مثل مناطق التوفر
  • Oracle Database Enterprise Edition 12c أو أحدث
  • الوعي بالآثار المترتبة على الترخيص عند استخدام الحلول الواردة في هذه المقالة

قابلية وصول عالية لقواعد بيانات Oracle

تُعد قابلية الوصول العالية في السحابة جزءاً مهماً من تخطيط وتصميم كل مؤسسة. يوفر Azure مناطقالتوفر ومجموعات التوفر لاستخدامها في المناطق التي لا تتوفر فيها مناطق التوفر. لمزيد من المعلومات حول كيفية تصميم السحابة، راجع خيارات التوفر لأجهزة Azure الظاهرية.

بالإضافة إلى الأدوات والعروض الأصلية على السحابة، توفر Oracle حلولا لقابلية الوصول العالية التي يمكن إعدادها على Azure:

يغطي هذا الدليل البنى المرجعية لكل من هذه الحلول.

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

Oracle RAC في السحابة

Oracle Real Application Cluster (RAC) هو حل من قبل Oracle لمساعدة العملاء على تحقيق إنتاجية عالية من خلال وجود العديد من المثيلات التي تصل إلى تخزين قاعدة بيانات واحد. هذا النمط هو بنية مشتركة للجميع. بينما يمكن استخدام Oracle RAC لقابلية الوصول العالية محليا، لا يمكن استخدام Oracle RAC وحده لقابلية الوصول العالية في السحابة. يحمي Oracle RAC فقط من حالات فشل مستوى المثيل وليس ضد حالات الفشل على مستوى الحامل أو على مستوى مركز البيانات. لهذا السبب، توصي Oracle باستخدام Oracle Data Guard مع قاعدة البيانات الخاصة بك، سواء كان مثيلا واحدا أو RAC، للحصول على قابلية وصول عالية.

يحتاج العملاء بشكل عام إلى اتفاقية مستوى خدمة عالية لتشغيل التطبيقات الهامة للمهمة. لا تعتمد Oracle حاليا أو تدعم Oracle RAC على Azure. ومع ذلك، يوفر Azure ميزات مثل مناطق التوفر ونوافذ الصيانة المخططة للمساعدة في الحماية من حالات الفشل على مستوى المثيل. بالإضافة إلى هذه العروض، يمكنك استخدام Oracle Data Guard وOracle GoldenGate وOracle Sharding للحصول على أداء ومرونة عالين. يمكن أن تساعد هذه التقنيات في حماية قواعد البيانات الخاصة بك من الفشل على مستوى الحامل ومركز البيانات والفشل الجغرافي السياسي.

عند تشغيل قواعد بيانات Oracle على مناطق توفر متعددة باستخدام Oracle Data Guard أو GoldenGate، يمكنك الحصول على اتفاقية مستوى الخدمة في وقت التشغيل بنسبة 99.99٪. في مناطق Azure حيث لم تكن مناطق التوفر موجودة بعد، يمكنك استخدام مجموعات التوفر وتحقيق اتفاقية مستوى خدمة وقت التشغيل بنسبة 99.95٪.

إشعار

يمكن أن يكون لديك هدف وقت تشغيل أعلى بكثير من اتفاقية مستوى الخدمة لوقت التشغيل التي توفرها Microsoft.

الإصلاح بعد كارثة لقواعد بيانات Oracle

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

بالنسبة إلى Oracle Database Enterprise Edition، يعد Oracle Data Guard ميزة مفيدة للإصلاح بعد الكارثة. يمكنك إعداد مثيل قاعدة بيانات الاستعداد في منطقة Azure مقترنة وإعداد تجاوز فشل Data Guard للإصلاح بعد الكارثة. من أجل عدم فقدان البيانات، نوصي بنشر مثيل Oracle Data Guard Far Sync بالإضافة إلى Active Data Guard.

إذا كان تطبيقك يسمح زمن الانتقال، ففكر في إعداد مثيل Data Guard Far Sync في منطقة توفر مختلفة عن قاعدة بيانات Oracle الأساسية. اختبر التكوين بدقة. استخدم وضع الحد الأقصى لقابلية الوصول لإعداد النقل المتزامن لملفات الإعادة إلى مثيل Far Sync. ثم يتم نقل هذه الملفات بشكل غير متزامن إلى قاعدة بيانات الاستعداد.

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

عند استخدام قواعد بيانات Oracle Standard Edition، هناك حلول ISV تسمح لك بإعداد قابلية وصول عالية والتعافي من الكوارث، مثل DBVisit Standby.

بنيات مرجعية

Oracle Data Guard

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

عند استخدام Oracle Data Guard، يمكنك أيضا فتح قاعدة البيانات الثانوية لأغراض القراءة فقط. يسمى هذا التكوين Active Data Guard. قدمت Oracle Database 12c ميزة تسمى مثيل Data Guard Far Sync. يسمح لك هذا المثيل بإعداد تكوين دون فقد لبيانات قاعدة بيانات Oracle دون الحاجة إلى المساس بالأداء.

إشعار

يتطلب Active Data Guard ترخيصاً إضافياً. هذا الترخيص مطلوب أيضاً لاستخدام ميزة Far Sync. اتصل بممثل Oracle لمناقشة الآثار المترتبة على الترخيص.

Oracle Data Guard مع تجاوز فشل البدء السريع

يمكن أن توفر Oracle Data Guard مع تجاوز فشل البدء السريع (FSFO) مرونة أكبر من خلال إعداد الوسيط على جهاز منفصل. يقوم كل من وسيط Data Guard وقاعدة البيانات الثانوية بتشغيل المراقب ومراقبة قاعدة البيانات الأساسية لوقت التعطل. يسمح هذا النهج بالتكرار في إعداد مراقب Data Guard أيضا.

مع إصدار قاعدة بيانات Oracle 12.2 وما فوق، من الممكن أيضا تكوين عدة مراقبين بتكوين وسيط Oracle Data Guard واحد. يوفر هذا الإعداد توفرا إضافيا، في حالة توقف مراقب واحد ووقت تعطل قاعدة البيانات الثانوية. Data Guard Broker خفيف الوزن ويمكن استضافته على جهاز ظاهري صغير نسبياً. لمزيد من المعلومات حول Data Guard Broker ومزاياه، راجع مفاهيم Oracle Data Guard Broker.

المخطط التالي هو بنية مُوصى بها لاستخدام Oracle Data Guard على Azure مع مناطق قابلية الوصول. تتيح لك هذه البنية الحصول على اتفاقية مستوى الخدمة لوقت تشغيل جهاز ظاهري بنسبة 99.99%.

رسم تخطيطي يوضح بنية مُوصى بها لاستخدام Oracle Data Guard على Azure مع مناطق التوفّر.

في الرسم التخطيطي السابق، يصل نظام العميل إلى تطبيق مخصص مع خلفية Oracle باستخدام الويب. يتم تكوين الواجهة الأمامية للويب في موازنة التحميل. تقوم الواجهة الأمامية للويب بإجراء مكالمة إلى خادم التطبيقات المناسب لتنفيذ العمل. يقوم خادم التطبيقات بالاستعلام عن قاعدة بيانات Oracle الأساسية. تم تكوين قاعدة بيانات Oracle باستخدام جهاز ظاهري محسّن للذاكرة فائق الترابط مع وحدات معالجة مركزية افتراضية أساسية مقيدة لتوفير تكاليف الترخيص وزيادة الأداء. يتم استخدام العديد من الأقراص المتميزة أو الفائقة (الأقراص المُدارة) للأداء وقابلية الوصول العالية.

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

يمكنك إعداد مراقبين آخرين أو قواعد بيانات احتياطية في منطقة توفر مختلفة، AZ 1، في هذه الحالة، عن المنطقة الموضحة في البنية السابقة. وأخيرا، تراقب Oracle Enterprise Manager (OEM) قواعد بيانات Oracle لوقت التشغيل والأداء. يسمح لك OEM أيضا بإنشاء تقارير أداء واستخدام مختلفة.

في المناطق التي لا يتم فيها دعم مناطق التوفر، يمكنك استخدام مجموعات التوفر لنشر قاعدة بيانات Oracle بطريقة متوفرة بشكل كبير. تتيح لك مجموعات قابلية الوصول تحقيق وقت تشغيل جهاز ظاهري بنسبة 99.95%. المخطط التالي هو بنية مرجعية لهذا الاستخدام:

رسم تخطيطي يوضح قاعدة بيانات Oracle باستخدام مجموعات التوفر مع Data Guard Broker - FSFO.

إشعار

  • نظرا لوجود مثيل واحد فقط من الشركات المصنعة للمعدات الأصلية (OEM) التي يتم نشرها، فليس عليك وضع Oracle Enterprise Manager VM في مجموعة توفر.
  • الأقراص الفائقة غير مدعومة حالياً في تكوين مجموعة قابلية الوصول.

Oracle Data Guard Far Sync

يوفر Oracle Data Guard Far Sync إمكانية الحماية من فقدان البيانات لـ Oracle Databases. تتيح لك هذه الإمكانية الحماية من فقدان البيانات في حالة فشل جهاز قاعدة البيانات. يجب تثبيت Oracle Data Guard Far Sync على جهاز ظاهري منفصل. Far Sync هو مثيل Oracle خفيف الوزن يحتوي فقط على ملف تحكم وملف كلمة مرور وملف spfile وسجلات الاستعداد. لا توجد ملفات بيانات أو ملفات سجل إعادة.

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

المخطط التالي عبارة عن بنية قابلية وصول عالية باستخدام Oracle Data Guard Far Sync:

رسم تخطيطي يوضح قاعدة بيانات Oracle باستخدام مناطق التوفر مع Data Guard Far Sync و Broker - FSFO.

في البنية السابقة، هناك مثيل Far Sync تم نشره في نفس منطقة التوفر مثل مثيل قاعدة البيانات لتقليل زمن الانتقال بين الاثنين. في الحالات التي يكون فيها التطبيق حساساً لزمن الانتقال، يتم وضع استخدام قاعدة البيانات ومثيل أو مثيلات Far Sync في مجموعة موضع قريب.

الرسم التخطيطي التالي هو بنية تستخدم Oracle Data Guard FSFO و Far Sync لتحقيق قابلية وصول عالية والتعافي من الكوارث:

رسم تخطيطي يوضح قاعدة بيانات Oracle باستخدام مناطق التوفر للتعافي من الكوارث مع Data Guard Far Sync و Broker - FSFO.

Oracle GoldenGate

تمكِّن GoldenGate تبادل البيانات ومعالجتها على مستوى العمليات بين منصات متعددة وغير متجانسة عبر المؤسسة. إنه ينقل العمليات المثبتة من خلال تكامل بيانات العمليات والحد الأدنى من النفقات العامة على البنية الأساسية الحالية. تمنحك بنيته النمطية المرونة لاستخراج سجلات البيانات المحددة وتغييرات المعاملات والتغييرات في لغة تعريف البيانات (DDL) ونسخها نسخا متماثلا عبر طبولوجيا مختلفة.

يتيح لك Oracle GoldenGate تكوين قاعدة البيانات لقابلية وصول عالية من خلال توفير النسخ المتماثلة ثنائية الاتجاه. يسمح لك هذا الأسلوب بإعداد تكوين متعدد الأشكال أو نشط-نشط. المخطط التالي هو بنية موصى بها لإعداد Oracle GoldenGate النشط-النشط على Azure. في البنية التالية، تم تكوين قاعدة بيانات Oracle باستخدام جهاز ظاهري محسّن للذاكرة فائق الترابط مع وحدات معالجة مركزية افتراضية أساسية مقيدة لتوفير تكاليف الترخيص وزيادة الأداء. تستخدم البنية عدة أقراص متميزة أو فائقة (أقراص مدارة) للأداء والتوافر.

رسم تخطيطي يوضح قاعدة بيانات Oracle باستخدام مناطق التوفر مع Data Guard Broker - FSFO.

إشعار

يمكن إعداد بنية مماثلة باستخدام مجموعات قابلية الوصول في المناطق التي لا تتوفر فيها مناطق قابلية وصول حالياً.

لدى Oracle GoldenGate عمليات مثل الاستخراج والمضخة والنسخ المتماثل التي تساعدك على نسخ بياناتك بشكل غير متزامن من خادم قاعدة بيانات Oracle إلى آخر. تسمح لك هذه العمليات بإعداد نسخ متماثل ثنائي الاتجاه لضمان توفر عال لقاعدة البيانات الخاصة بك إذا كان هناك وقت تعطل على مستوى منطقة التوفر.

في الرسم التخطيطي السابق، تعمل عملية الاستخراج على نفس الخادم مثل قاعدة بيانات Oracle. تعمل عمليات مضخة البيانات والنسخ المتماثل على خادم منفصل في نفس منطقة التوفر. يتم استخدام عملية النسخ المتماثل لتلقي البيانات من قاعدة البيانات في منطقة قابلية الوصول الأخرى والالتزام بالبيانات إلى قاعدة بيانات Oracle في منطقة قابلية الوصول الخاصة بها. وبالمثل، ترسل عملية مضخة البيانات البيانات التي تستخرجها عملية الاستخراج إلى عملية النسخ المتماثل في منطقة التوفر الأخرى.

بينما يعرض الرسم التخطيطي للبنية السابقة عمليات مضخة البيانات والنسخ المتماثل التي تم تكوينها على خادم منفصل، يمكنك إعداد جميع عمليات Oracle GoldenGate على نفس الخادم، استنادا إلى سعة الخادم واستخدامه. راجع دائماً تقرير AWR والمقاييس في Azure لفهم نمط استخدام خادمك.

عند إعداد النسخ المتماثل ثنائي الاتجاه لـ Oracle GoldenGate في مناطق قابلية وصول مختلفة أو مناطق مختلفة، من المهم التأكد من أن زمن الانتقال بين المكونات المختلفة مقبول لتطبيقك. يمكن أن يختلف زمن الانتقال بين مناطق التوفر والمناطق. يعتمد زمن الانتقال على عوامل متعددة. نوصي بإعداد اختبارات الأداء بين طبقة التطبيق وطبقة قاعدة البيانات في مناطق أو مناطق توفر مختلفة. يمكن أن تؤكد الاختبارات أن التكوين يفي بمتطلبات أداء التطبيق الخاص بك.

يمكن إعداد الطبقة المسؤولة عن التطبيق في الشبكة الفرعية الخاصة بها ويمكن فصل الطبقة المسؤولة عن قاعدة البيانات إلى شبكة فرعية خاصة بها. عندما يكون ذلك ممكناً، ضع في الاعتبار استخدام Azure Application Gateway من أجل لموازنة حمل نسبة استخدام الشبكة بين خوادم التطبيقات. بوابة التطبيق هي موازن تحميل قوي لنسبة استخدام الشبكة على الويب. يوفر ترابط جلسة العمل المستندة إلى ملفات تعريف الارتباط التي تحافظ على جلسة عمل المستخدم على نفس الخادم، ما يقلل من التعارضات على قاعدة البيانات. بدائل Application Gateway هي Azure Load Balancer وAzure Traffic Manager.

Oracle Sharding

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

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

يعد Sharding مناسباً لتطبيقات OLTP ذات معدل النقل العالية التي لا يمكنها تحمل أي وقت تعطل. جميع الصفوف التي لها نفس مفتاح التقسيم مضمونة دائما لتكون على نفس الجزء. تزيد هذه الحقيقة من الأداء، وتوفر تناسقا عاليا. يجب أن تحتوي التطبيقات التي تستخدم التقسيم على نموذج بيانات محدد جيدا واستراتيجية توزيع البيانات، مثل التجزئة المتسقة أو النطاق أو القائمة أو المركبة. تصل الاستراتيجية في المقام الأول إلى البيانات باستخدام مفتاح التقسيم، على سبيل المثال، customerId أو accountNum. يسمح لك التقسيم أيضا بتخزين مجموعات معينة من البيانات بالقرب من العملاء النهائيين، مما يساعد على تلبية متطلبات الأداء والتوافق.

نوصي بنسخ الأجزاء نسخا متماثلا للحصول على قابلية وصول عالية والتعافي من الكوارث. يمكن إجراء هذا الإعداد باستخدام تقنيات Oracle مثل Oracle Data Guard أو Oracle GoldenGate. يمكن أن تكون وحدة النسخ المتماثل مقطعاً أو جزءاً من مقطع أو مجموعة من المقاطع. لا يؤثر انقطاع أو تباطؤ جزء واحد أو أكثر على توفر قاعدة بيانات مقسمة.

من أجل قابلية وصول عالية، يمكن وضع المقاطع الاحتياطية في نفس منطقة قابلية الوصول حيث يتم وضع المقاطع الأساسية. للإصلاح بعد كارثة، يمكن وضع المقاطع في وضع الاستعداد في منطقة أخرى. يمكنك أيضا نشر الأجزاء في مناطق متعددة لخدمة نسبة استخدام الشبكة في تلك المناطق. لمعرفة المزيد حول تكوين قابلية الوصول العالية والنسخ المتماثل لقاعدة البيانات المقسمة، راجع Shard-Level High Availability.

يتكون Oracle Sharding في المقام الأول من المكونات التالية. لمزيد من المعلومات، راجع نظرة عامة على تقسيم Oracle:

  • كتالوج القطع. قاعدة بيانات Oracle للأغراض الخاصة التي هي مخزن مستمر لجميع بيانات تكوين قاعدة بيانات Shard. يتم بدء جميع تغييرات التكوين مثل إضافة أو إزالة المقاطع وتعيين البيانات و لغات تعريف البيانات في قاعدة بيانات مقسمة في كتالوج المقسم. يحتوي كتالوج المقسم أيضاً على النسخة الرئيسية من كافة الجداول المكررة في SDB.

    يستخدم كتالوج المقسمة طرق العرض المادية لتكرار التغييرات تلقائياً على الجداول المكررة في كافة المقاطع. تعمل قاعدة بيانات كتالوج الأجزاء أيضا كمنسق استعلام يستخدم لمعالجة الاستعلامات والاستعلامات متعددة الأجزاء التي لا تحدد مفتاح التقسيم.

    نوصي باستخدام Oracle Data Guard مع مناطق التوفر أو مجموعات التوفر لتوفر كتالوج الأجزاء العالي كأفضل ممارسة. لا يؤثر توفر كتالوج الأجزاء على توفر قاعدة البيانات المقسمة. يؤثر وقت التعطل عن العمل في كتالوج المقسم فقط على عمليات الصيانة والاستعلامات متعددة التقسيم خلال الفترة القصيرة التي يكتمل فيها تجاوز فشل Data Guard. يستمر SDB في توجيه المعاملات عبر الإنترنت وتشغيلها. لا يؤثر انقطاع الكتالوج عليها.

  • مديرو الأجزاء. الخدمات الخفيفة التي تحتاج إلى نشرها في كل منطقة/منطقة توفر تتواجد فيها القطع الخاصة بك. مديرو التقسيم هم مديرو خدمات عالمية يتم توزيعهم في سياق Oracle Sharding. للحصول على قابلية وصول عالية، نوصي بنشر مدير جزء واحد على الأقل في كل منطقة توفر توجد فيها الأجزاء الخاصة بك.

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

    للحصول على توجيه عالي الأداء يعتمد على البيانات، توصي Oracle باستخدام تجمع اتصال عند الوصول إلى البيانات في قاعدة البيانات المقسمة. تدعم تجمعات اتصال Oracle والمكتبات الخاصة باللغات وبرامج التشغيل Oracle Sharding. لمزيد من المعلومات، راجع نظرة عامة على تجزئة Oracle.

  • خدمة عمومية. الخدمة العمومية مشابهة لخدمة قاعدة البيانات العادية. بالإضافة إلى جميع خصائص خدمة قاعدة البيانات، تحتوي الخدمة العمومية على خصائص لقواعد البيانات المقسمة. تتضمن هذه الخصائص ترابط المنطقة بين العملاء والتسامح مع تأخر التقسيم والنسخ المتماثل. يجب إنشاء خدمة عالمية واحدة فقط لقراءة/كتابة البيانات من وإلى قاعدة بيانات مقسمة. عند استخدام Active Data Guard وإعداد النسخ المتماثلة للقراءة فقط من الأجزاء، يمكنك إنشاء خدمة عمومية أخرى لأحمال العمل للقراءة فقط. يمكن للعميل استخدام هذه الخدمات العمومية للاتصال بقاعدة البيانات.

  • قواعد بيانات القطع. قواعد بيانات Shard هي قواعد بيانات Oracle الخاصة بك. يتم نسخ كل قاعدة بيانات باستخدام Oracle Data Guard في تكوين وسيط مع تمكين FSFO. لست بحاجة إلى إعداد النسخ المتماثل وتجاوز فشل Data Guard على كل مقطع. يتم تكوين هذا الجانب ونشره تلقائيا عند إنشاء قاعدة البيانات المشتركة. إذا فشل جزء معين، تفشل Oracle Sharing عبر اتصالات قاعدة البيانات من الأساسي إلى الاستعداد.

يمكنك نشر وإدارة قواعد البيانات المقسمة من Oracle باستخدام واجهتين: Oracle Enterprise Manager Cloud Control GUI وأداة GDSCTL سطر الأوامر المساعدة. يمكنك حتى مراقبة المقاطع المختلفة للتأكد من قابلية وصولها وأدائها باستخدام التحكم في السحابة. ينشئ الأمر GDSCTL DEPLOY تلقائياً المقاطع والمستمعين المعنيين. بالإضافة إلى ذلك، يستخدم هذا الأمر تلقائياً تكوين النسخ المتماثل المستخدَم لقابلية وصول عالية على مستوى المقطع المحدد من قبل المسؤول.

هناك طرق مختلفة لتقسيم قاعدة بيانات:

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

لمزيد من المعلومات، راجع أساليب التقسيم.

تبدو قاعدة البيانات المقسمة مثل قاعدة بيانات واحدة للتطبيقات والمطورين. عند الترحيل إلى قاعدة بيانات مقسمة، خطط بعناية لفهم الجداول المكررة مقابل التقسيم.

يتم تخزين الجداول المكررة على جميع المقاطع، في حين يتم توزيع الجداول المقسمة عبر مقاطع مختلفة. نوصي بتكرار الجداول الصغيرة والأبعاد وتوزيع/تقسيم جداول الحقائق. يمكن تحميل البيانات في قاعدة البيانات المقسمة الخاصة بك باستخدام إما كتالوج مقسم كمنسق مركزي أو عن طريق تشغيل Data Pump على كل مقطع. لمزيد من المعلومات، راجع ترحيل البيانات إلى قاعدة بيانات مقسمة.

Oracle Sharding مع Data Guard

يمكن استخدام Oracle Data Guard للتقسيم باستخدام طرق التقسيم التي يديرها النظام ويحددها المستخدم والمركبة.

المخطط التالي هو بنية مرجعية لمشاركة Oracle مع Oracle Data Guard المستخدمة لقابلية وصول عالية لكل مقطع. يوضح مخطط البنية أسلوب التقسيم المركب. من المحتمل أن يختلف الرسم التخطيطي للبنية للتطبيقات ذات المتطلبات المختلفة لمحلية البيانات وموازنة التحميل والتوافر العالي والتعافي من الكوارث. قد تستخدم التطبيقات أسلوبا مختلفا للتقسيم. يتيح لك Oracle Sharding تلبية هذه المتطلبات والتوسع أفقياً وبكفاءة من خلال توفير هذه الخيارات. يمكن حتى استخدام بنية مماثلة باستخدام Oracle GoldenGate.

رسم تخطيطي يوضح تقسيم قاعدة بيانات Oracle باستخدام مناطق التوفر مع Data Guard Broker - FSFO.

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

في البنية السابقة، يتم استخدام التقسيم المركب لتقسيم البيانات جغرافيا وتوسيع نطاق طبقات التطبيق أفقيا. التقسيم المركب هو مزيج من التقسيم المُدار من قِبل النظام والمحدد من قِبل المستخدم، وبالتالي يقدم فائدة كلتا الطريقتين. في السيناريو السابق، يتم أولاً تقسيم البيانات عبر مساحات مقسمة متعددة مفصولة حسب المنطقة. بعد ذلك، يتم تقسيم البيانات بشكل أكبر باستخدام تجزئة متسقة عبر أجزاء متعددة في مساحة الأجزاء.

تحتوي كل مساحة مقسمة على مجموعات مقسمة متعددة. تحتوي كل مجموعة تجزئة على أجزاء متعددة وهي وحدة من النسخ المتماثل. تحتوي كل مجموعة مقسمة على جميع البيانات الموجودة في مساحة مقسمة. المجموعات المقسمة A1 وB1 هي مجموعات مقسمة أساسية، في حين أن المجموعات المقسمة A2 وB2 هي مجموعات احتياطية. قد تختار أن تكون الأجزاء الفردية هي وحدة النسخ المتماثل، بدلا من مجموعة الأجزاء.

في البنية السابقة، يتم نشر مدير خدمة عمومية (GSM) / مدير جزء في كل منطقة توفر لقابلية وصول عالية. نوصي بنشر مدير GSM/shard واحد على الأقل لكل مركز بيانات/منطقة. بالإضافة إلى ذلك، يتم نشر مثيل لخادم التطبيقات في كل منطقة قابلية وصول تحتوي على مجموعة مقسمة. يسمح هذا الإعداد للتطبيق بالحفاظ على زمن انتقال بين خادم التطبيقات وقاعدة البيانات/مجموعة المقسمة منخفضاً. في حالة فشل قاعدة بيانات، يمكن لخادم التطبيقات في نفس المنطقة مثل قاعدة بيانات الاستعداد معالجة الطلبات بعد حدوث انتقال دور قاعدة البيانات. تقوم Azure Application Gateway ومدير التقسيم بتتبع الطلب وزمن انتقال الاستجابة وطلبات المسار وفقاً لذلك.

من وجهة نظر التطبيق، يقدم نظام العميل طلبا إلى Azure Application Gateway أو تقنيات موازنة التحميل الأخرى في Azure، والتي تعيد توجيه الطلب إلى المنطقة الأقرب إلى العميل. تدعم Azure Application Gateway أيضاً جلسات العمل اللاصقة، لذلك يتم توجيه أي طلبات واردة من نفس العميل إلى نفس خادم التطبيقات. يستخدم خادم التطبيقات تجميع الاتصال في برامج تشغيل الوصول إلى البيانات. تتوفر هذه الميزة في برامج التشغيل مثل JDBC ODP.NET وOCI. يمكن لبرامج التشغيل التعرف على مفاتيح التقسيم المحددة كجزء من الطلب. Oracle Universal Connection Pool (UCP) يمكن لعملاء JDBC تمكين عملاء التطبيقات غير التابعين لـ Oracle مثل Apache Tomcat وIIS من العمل باستخدام Oracle Sharding. لمزيد من المعلومات، راجع نظرة عامة على تجمع UCP المشترك لتقسيم قاعدة البيانات.

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

Oracle Sharding مع GoldenGate

المخطط التالي هو بنية مرجعية لـ Oracle Sharding مع Oracle GoldenGate لقابلية وصول عالية لكل مقطع داخل المنطقة. على عكس البنية السابقة، تصور هذه البنية قابلية وصول عالية فقط داخل منطقة Azure واحدة، مع مناطق توفر متعددة. يمكنك نشر قاعدة بيانات مقسمة ذات قابلية وصول عالية متعددة المناطق، على غرار المثال السابق، باستخدام Oracle GoldenGate.

رسم تخطيطي يوضح تقسيم قاعدة بيانات Oracle باستخدام مناطق التوفر مع GoldenGate.

تستخدم البنية المرجعية السابقة طريقة تقسيم يديرها النظام لتجميع البيانات. نظراً لأن النسخ المتماثل لـ Oracle GoldenGate يتم على مستوى مجموعة، يمكن نسخ نصف البيانات المكررة إلى مقطع واحد إلى مقطع آخر. يمكن تكرار النصف الآخر إلى مقطع مختلف.

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

في البنية السابقة، تحتوي كل من المجموعة المقسمة أ والمجموعة المقسمة ب على نفس البيانات ولكنهما يوجدان في مناطق قابلية وصول مختلفة. إذا كان لكل من shardgroup A وshardgroup B نفس عامل النسخ المتماثل المكون من ثلاثة، يتم نسخ كل صف/مجموعة من الجدول المقسم ست مرات عبر مجموعتي الأجزاء. إذا كان لدى shardgroup A عامل نسخ متماثل من ثلاثة وكان لدى shardgroup B عامل نسخ متماثل من اثنين، يتم نسخ كل صف/مجموعة خمس مرات عبر مجموعتي الأجزاء.

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

في البنية السابقة، يتم توزيع مدير تقسيم/GSM في كل منطقة قابلية وصول من أجل قابلية وصول عالية. نوصي بنشر مدير GSM/shard واحد على الأقل لكل مركز بيانات أو منطقة. يتم نشر مثيل لخادم التطبيق في كل منطقة توفر تحتوي على مجموعة أجزاء. يسمح هذا الإعداد للتطبيق بالحفاظ على زمن انتقال بين خادم التطبيقات وقاعدة البيانات/مجموعة المقسمة منخفضاً. في حالة فشل قاعدة بيانات، يمكن لخادم التطبيقات في نفس المنطقة مثل قاعدة بيانات الاستعداد معالجة الطلبات بعد انتقال دور قاعدة البيانات. تقوم Azure Application Gateway ومدير التقسيم بتتبع الطلب وزمن انتقال الاستجابة وطلبات المسار وفقاً لذلك.

من وجهة نظر التطبيق، يقدم نظام العميل طلبا إلى Azure Application Gateway أو تقنيات موازنة التحميل الأخرى في Azure، والتي تعيد توجيه الطلب إلى المنطقة الأقرب إلى العميل. تدعم Azure Application Gateway أيضاً جلسات العمل اللاصقة، لذلك يتم توجيه أي طلبات واردة من نفس العميل إلى نفس خادم التطبيقات. يستخدم خادم التطبيقات تجميع الاتصال في برامج تشغيل الوصول إلى البيانات. تتوفر هذه الميزة في برامج التشغيل مثل JDBC ODP.NET وOCI. يمكن لبرامج التشغيل التعرف على مفاتيح التقسيم المحددة كجزء من الطلب. Oracle Universal Connection Pool (UCP) يمكن لعملاء JDBC تمكين عملاء التطبيقات غير التابعين لـ Oracle مثل Apache Tomcat وIIS من العمل باستخدام Oracle Sharding.

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

التحديث الجزئي والصيانة

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

يمكن أتمتة عملية التحديث الجزئي لنظام تشغيل الجهاز الظاهري باستخدام Azure Automation Update Management. يمكن أتمتة التحديث الجزئي لقاعدة بيانات Oracle وصيانتها وجدولتها باستخدام Azure Pipelines أو Azure Automation Update Management لتقليل وقت التعطل. لمزيد من المعلومات حول التسليم المستمر والنشرات الزرقاء / الخضراء، راجع تقنيات التعرض التدريجي.

اعتبارات البنى والتصميم

  • ضع في الاعتبار استخدام جهاز ظاهري محسّن للذاكرة فائق الترابط مع وحدات معالجة مركزية افتراضية أساسية مقيدة لجهاز Oracle Database ظاهري لتوفير تكاليف الترخيص وزيادة الأداء إلى أقصى حد. استخدم العديد من الأقراص المتميزة أو الفائقة (الأقراص المُدارة) للأداء وقابلية الوصول.
  • عند استخدام الأقراص المدارة، قد يتغير اسم القرص/الجهاز عند إعادة التشغيل. نوصي باستخدام UUID للجهاز بدلا من الاسم للتأكد من استمرار عمليات التحميل في قالب إعادة التشغيل. لمزيد من المعلومات، راجع إضافة نظام الملفات الجديد إلى /etc/fstab.
  • استخدم مناطق قابلية الوصول لتحقيق قابلية وصول عالية في المنطقة.
  • ضع في اعتبارك استخدام الأقراص الفائقة عند توفرها أو الأقراص المتميزة لقاعدة بيانات Oracle.
  • ضع في الاعتبار إعداد قاعدة بيانات Oracle في وضع الاستعداد في منطقة Azure أخرى باستخدام Oracle Data Guard.
  • ضع في الاعتبار استخدام مجموعات تعيين موضع التقارب لتقليل زمن الانتقال بين الطبقة المسؤولة عن التطبيق وقاعدة البيانات.
  • الحد الأقصى لعرض النطاق الترددي للشبكة ل Azure VMs (عادة) أعلى من الحد الأقصى لمعدل نقل القرص على نفس SKU. يمكنك تحقيق معدل نقل أعلى على نفس VM SKU أو استخدام وحدة SKU أصغر للجهاز الظاهري باستخدام تخزين شبكة عالي الأداء وزمن انتقال منخفض مثل Azure NetApp Files. لقاعدة البيانات.
  • قم بإعداد Oracle Enterprise Manager للإدارة والمراقبة والتسجيل.
  • ضع في اعتبارك استخدام Oracle Automatic Storage Management لإدارة التخزين المبسطة لقاعدة البيانات الخاصة بك.
  • استخدم Azure Pipelines لإدارة التحديث الجزئي والتحديثات لقاعدة البيانات الخاصة بك دون أي وقت تعطل.
  • قم بتعديل التعليمات البرمجية للتطبيق لإضافة أنماط سحابية أصلية قد تساعد تطبيقك على أن يكون أكثر مرونة. ضع في اعتبارك أنماطا مثل نمط إعادة المحاولة ونمط قاطع الدائرة والأنماط الأخرى المحددة في دليل أنماط تصميم السحابة.

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

راجع مقالات Oracle المرجعية التالية التي تنطبق على السيناريو الخاص بك.