1. تكوين Oracle Fusion Middleware DR على Oracle Cloud باستخدام قاعدة بيانات ذاتية
  2. تكوين حل DR باستخدام Oracle Autonomous Database

تكوين حل DR باستخدام Oracle Autonomous Database

لضمان استمرارية الأعمال في حالة وقوع كوارث، ستحتاج إلى تنفيذ إستراتيجية استعادة القدرة على العمل بعد الكوارث (DR) لتطبيقات Oracle WebLogic Suite الخاصة بك. يوفر هذا الحل حماية البيانات ويمكنك من استخدام Oracle Autonomous Database للتبديل بسرعة إلى النظام البديل بأقل قدر من فقدان البيانات والإنتاجية.

يمكنك إعداد نظام استعادة القدرة على العمل بعد الكوارث وإدارته يستخدم Oracle Autonomous Database كقاعدة بيانات لـ Oracle WebLogic Server for Oracle Cloud Infrastructure أو Oracle SOA Suite on Marketplace أو أي خدمة أخرى متوسطة المستوى Oracle Cloud Infrastructure (OCI) تستخدم Oracle Fusion Middleware.

توفر Oracle Autonomous Database Serverless وOracle Exadata Database Service on Dedicated Infrastructure ميزة قاعدة البيانات البديلة للقطات. يتيح لك هذا فتح قاعدة البيانات البديلة مؤقتًا للقراءة والكتابة. عند تحويل قاعدة البيانات البديلة إلى قاعدة بيانات بديلة للقطات، يمكن تحديثها بالكامل. تستمر في تلقي بيانات redo من قاعدة البيانات المصدر البعيدة (لذلك تظل محميًا ضد DR)، لكنها لا تطبق redo حتى يتم تحويلها مرة أخرى إلى قاعدة بيانات بديلة فعلية. يتم التراجع عن جميع التغييرات التي تم إجراؤها في قاعدة البيانات البديلة للقطات عند تحويلها إلى قاعدة البيانات البديلة الفعلية مرة أخرى. استخدم هذه الميزة لتزويد النظام ذي الطبقة المتوسطة في المنطقة البديلة. يمكنك أيضًا استخدام هذه الميزة أثناء دورة حياة نظام DR للتحقق من النظام البديل دون إجراء تبديل كامل.

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

قبل البدء

هناك العديد من الموجزات الفنية لـ Oracle Maximum Availability Architecture (MAA) التي تصف كيفية إعداد نظام استعادة البيانات بعد الكوارث (DR) لـ Oracle WebLogic Server for Oracle Cloud Infrastructure وOracle SOA Suite في السوق عندما تستخدم أنظمة البرامج الوسيطة هذه Oracle Base Database Service.

تستخدم منهجيات Oracle WebLogic Server for Oracle Cloud Infrastructure وOracle SOA Suite في السوق وOracle Fusion Middleware DR نموذجًا نشطًا سلبيًا. النظام الأساسي هو مركز بيانات Oracle Cloud Infrastructure (OCI)، ونظام ثانوي في مركز بيانات OCI مختلف وعن بُعد.

راجع ما يلي لمزيد من التفاصيل والهيكلية لكل حالة:

توفر الأوراق الواردة أعلاه تفاصيل متعمقة وخطوات إعداد وإدارة، بالإضافة إلى العديد من الاعتبارات الأخرى، من أجل Oracle WebLogic Server for Oracle Cloud Infrastructure وOracle SOA Suite في السوق.

بالإضافة إلى الموجزات الفنية، تأكد من معرفتك بمفاهيم Oracle Cloud Infrastructure (OCI) وإدارتها، بما في ذلك الشبكات ومثيلات الحوسبة وموازنة التحميل وOracle Autonomous Database قبل متابعة التحليل والخطوات الموضحة في هذا الكتاب.

يتم التحقق من الخطوات والأمثلة في هذا الكتيب باستخدام Oracle WebLogic Server لـ OCI وOracle SOA Suite في السوق للسيناريوهات التالية:
  • Oracle Autonomous Data Guard في Oracle Exadata Database Service on Dedicated Infrastructure، باستخدام ميزة Snapshot Standby لإعداد إجراءات مواجهة الكوارث.
  • Oracle Autonomous Data Guard على Oracle Autonomous Database Serverless، باستخدام ميزة Snapshot Standby لإعداد إجراءات مواجهة الكوارث.
  • Oracle Autonomous Data Guard على Oracle Autonomous Database Serverless، باستخدام النسخ القابلة للتجديد عن بُعد لإعداد إجراءات مواجهة الكوارث.

معظم الخطوات شائعة للسيناريوهات الثلاثة. تختلف بعض الخطوات فقط وتكون خاصة بكل حالة.

يجب ألا يكون من الصعب تعديل الخطوات لأي نظام Oracle WebLogic Server أو Oracle Fusion Middleware يستخدم Oracle Autonomous Database.

البنية

يوضح مخطط البنية هذا هيكل نظام استعادة القدرة على العمل بعد الكوارث (DR) الخاص بالنُهج المستخدمة في هذا الكتاب. يتم استنساخ جميع معلومات وقت التشغيل والتكوين وبيانات التعريف الموجودة في قاعدة البيانات الأساسية من المنطقة 1 إلى المنطقة 2 مع Oracle Autonomous Data Guard. تستخدم منهجيات Oracle WebLogic Server for Oracle Cloud Infrastructure وOracle SOA Suite في السوق وOracle Fusion Middleware DR نموذجًا نشطًا سلبيًا. النظام الأساسي هو مركز بيانات Oracle Cloud Infrastructure (OCI)، ونظام ثانوي في مركز بيانات OCI مختلف وعن بُعد.

يتم استنساخ تكوين مجال Oracle WebLogic باستخدام دليل مرحلة Oracle Cloud Infrastructure File Storage (OCI File Storage) في المنطقة الأساسية، والذي يتم استنساخه بدليل مرحلة تخزين ملفات OCI في المنطقة الثانوية. بعد ذلك، يتم نسخ التكوين إلى دليل المجال الحقيقي في الدليل الثانوي. تقدم النسخة المباشرة من المجال مخاطر يتم تجنبها باستخدام دليل مرحلي. ونظرًا لأن نسخ الملفات هي عملية غير عملية، يتم إجراء أول نسخة إلى دليل المرحلة. يتم التحقق من الملفات أولاً في هذا الدليل الوسيط ثم يتم نقلها إلى نطاق Oracle WebLogic الحقيقي (النهائي).

فيما يلي وصف wls-dr-adb.png
وصف الشكل التوضيحي wls-dr-adb.png

wls-dr-adb-oracle.zip

يعتبر الهيكل نموذجًا لما يستخدمه Oracle WebLogic Server أو Oracle SOA أو بيئات استعادة القدرة على العمل بعد الكوارث في Oracle Fusion Middleware في OCI. لتوفير الطبقة الوسطى البديلة وعمليات دورة الحياة مثل اختبار المرحلة الثانوية، يمكنك تحويل Oracle Autonomous Database البديلة إلى قاعدة بيانات اللقطات البديلة أو استخدام استنساخ قابل للتجديد عن بُعد.

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

تدعم هذه البنية المكونات التالية:

  • Region (المنطقة)

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

  • مجال التوفر

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

  • مجال الخطأ

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

  • شبكة السحابة الافتراضية (VCN) والشبكة الفرعية

    شبكة السحابة الافتراضية (VCN) هي شبكة قابلة للتخصيص ومحددة بالبرامج قمت بإعدادها في منطقة Oracle Cloud Infrastructure. توفر لك شبكات VCN، مثلها مثل شبكات مراكز البيانات التقليدية، تحكمًا كاملاً في بيئة شبكتك. يمكن أن يحتوي VCN على العديد من كتل CIDR غير المتداخلة التي يمكنك تغييرها بعد إنشاء VCN. يمكنك تقسيم شبكة سحابية افتراضية (VCN) إلى شبكات فرعية، يمكن تحديد مجال لها إلى منطقة أو إلى نطاق إتاحة. وتتكون كل شبكة فرعية من نطاق متجاور من العناوين التي لا تتداخل مع الشبكات الفرعية الأخرى في شبكة السحابة الافتراضية (VCN). يمكنك تغيير حجم الشبكة الفرعية بعد إنشائها. يمكن أن تكون الشبكة الفرعية عامة أو خاصة.

  • موازن التحميل

    توفر خدمة Oracle Cloud Infrastructure Load Balancing توزيع حركة المرور التلقائي من نقطة إدخال واحدة إلى خوادم متعددة في الواجهة الخلفية.

  • نطاق Oracle WebLogic

    النطاق هو وحدة الإدارة الأساسية لطبعات WebLogic Server. يتكون النطاق من طبعة واحدة أو أكثر من طبعات خادم WebLogic (والموارد المرتبطة بها) تقوم بإدارتها باستخدام خادم إدارة واحد. يتم تكوين نطاق Oracle WebLogic بعد أفضل ممارسات Oracle Maximum Availability Architecture (MAA) للتوفر العالي.

  • بوابة التوجيه الديناميكي (DRG)

    DRG هو جهاز توجيه ظاهري يوفر مسارًا لحركة مرور الشبكة الخاصة بين VCNs في نفس المنطقة، بين VCN وشبكة خارج المنطقة، مثل VCN في منطقة Oracle Cloud Infrastructure أخرى، أو شبكة محلية، أو شبكة في موفر سحابة آخر.

  • قائمة السرية

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

  • Oracle Cloud Infrastructure File Storage

    توفر خدمة Oracle Cloud Infrastructure File Storage نظام ملفات شبكة متين وقابل للتوسع وآمن على مستوى المؤسسات. يمكنك الاتصال بنظام ملفات خدمة تخزين الملفات من أي جهاز بدون أنظمة تشغيل أو جهاز افتراضي أو مثيل حاوية في شبكة السحابة الافتراضية (VCN). تدعم خدمة تخزين الملفات بروتوكول نظام ملفات الشبكة 3.0 (NFSv3). تدعم الخدمة بروتوكول مدير قفل الشبكة (NLM) لوظيفة قفل الملفات.

    يستخدم Oracle Cloud Infrastructure File Storage التخزين المكرر ثنائي الاتجاه، الموجود في نطاقات خطأ مختلفة، لتوفير التكرار لحماية البيانات المرنة. البيانات محمية بترميز إزالة البيانات. تم تصميم الخدمة لتلبية احتياجات التطبيقات والمستخدمين الذين يحتاجون إلى نظام ملفات من فئة المؤسسات عبر مجموعة واسعة من حالات الاستخدام.

  • Autonomous Database

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

  • Oracle Autonomous Database on Dedicated Exadata Infrastructure المخصصة

    Oracle Autonomous Database on Dedicated Exadata Infrastructure هي Oracle Autonomous Database مع سحابة قاعدة بيانات خاصة في السحابة العامة. باستخدام قاعدة البيانات المخصصة لديك، تحصل على خدمة حوسبة وتخزين وشبكة وقاعدة بيانات مخصصة بالكامل، مما يوفر أعلى مستويات الأمان والعزل والحوكمة.

  • Oracle Autonomous Database Serverless

    Oracle Autonomous Database Serverless هي Oracle Autonomous Database. لديك قاعدة بيانات مرنة تمامًا حيث تدير Oracle بشكل مستقل جميع جوانب دورة حياة قاعدة البيانات من وضع قاعدة البيانات إلى النسخ الاحتياطي والتحديثات.

  • حماية البيانات

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

  • Oracle Autonomous Data Guard

    يتيح Oracle Autonomous Data Guard لقاعدة البيانات البديلة (peer) توفير حماية البيانات وإجراءات مواجهة الكوارث لمثيل Autonomous Database الخاص بك. وهي توفر مجموعة شاملة من الخدمات التي تنشئ قاعدة بيانات بديلة واحدة أو أكثر وتحتفظ بها وإدارتها وتراقبها لتمكين قواعد بيانات Oracle الإنتاجية من البقاء متاحة دون انقطاع. يحتفظ Oracle Data Guard بقواعد البيانات البديلة هذه كنسخ من قاعدة بيانات الإنتاج. بعد ذلك، إذا أصبحت قاعدة بيانات الإنتاج غير متاحة بسبب انقطاع مؤقت مخطط أو غير مخطط، يمكنك تبديل أي قاعدة بيانات بديلة إلى دور الإنتاج، مع تقليل وقت التوقف المرتبط بالانقطاع المؤقت.

  • لقطة بديلة

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

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

  • استنساخ قابل للتجديد

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

اعتبارات الطبقة الوسطى

تنطبق جميع الاعتبارات الواردة في Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery وSOA Suite في Oracle Cloud Infrastructure Marketplace Disaster Recovery للطبقة الوسطى في سيناريوهات Oracle Autonomous Database الموضحة في هذا المستند.

ضع في اعتبارك الجوانب التالية للطبقة الوسطى:

  • عنوان الواجهة الأمامية

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

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

    استخدم خدمة نظام أسماء النطاقات (DNS) المناسبة لاسم الواجهة الأمامية المطلوب تخطيطه لأي من الموقعين. على سبيل المثال، (خدمة Oracle Cloud Infrastructure DNS، أو DNS التجارية الأخرى، أو DNS المحلي، أو حل المضيفين المحليين).

  • بادئة اسم الطبعة

    أدخل Instance Name Prefix عند إعداد Oracle WebLogic Server لـ OCI أو Oracle SOA Suite في السوق. تُستخدم هذه الخاصية في تكوين أسماء جميع الموارد، بما في ذلك: اسم نطاق خادم WebLogic واسم المجموعة وأسماء خادم WebLogic وأسماء مضيف الأجهزة الافتراضية وما إلى ذلك.

    قم بتعيين Instance Name Prefix على نفس القيمة في أنظمة Oracle WebLogic Server الأساسية والثانوية، بحيث يكون لكل من النظامين نفس الاسم لموارد Oracle WebLogic. يضمن استخدام نفس الاسم الاتساق وهو مطلوب لاستعادة رسائل JMS وTLogs. كما أنه يبسط التخصيصات والعمليات في كلا الموقعين.

    يمكنك استخدام نفس Instance Name Prefix في طبعات متعددة في نفس عقد إيجار Oracle Cloud، طالما قمت بتكوينها في مناطق أو حجرات مختلفة. يتم عرض كل طبعة فقط في المنطقة والحيز الخاص بها.

    توفر عملية تزويد Oracle SOA Suite في Marketplace ميزة اختيارية تتيح لك تكوين أسماء مخصصة للمجال، والمجموعة، وخادم الإدارة، وبادئة الخادم المدار، وما إلى ذلك. وفي هذه الحالة، لا تُستمد الأسماء من الموقع Instance Name Prefix. تأخذ القيم المقدمة بدلاً من ذلك. يمكن استخدام هذه الميزة في منظومة إجراءات مواجهة الكوارث (DR) الموضحة في هذا المستند، ما دامت الأسماء المخصصة المتوفرة متماثلة في النظام الأساسي والأنظمة الاحتياطية.

  • ملفات مخصصة

    تتم مزامنة معظم تكوين نطاق Oracle WebLogic Server لـ OCI الذي يستخدمه WebLogic Cloud مبدئيًا عبر المواقع مع الاعتبارات التالية:

    ويحتفظ كل نظام WebLogic بعناوين JDBC URL الأصلية المستخدمة للاتصال بقاعدة البيانات المحلية، حتى بعد اكتمال إعداد DR. يتم تبديل بادئة المخطط فقط بحيث يشير كلا الموقعين إلى نفس المخططات (المخططات الأساسية).

    تقوم ميزة البنية الأساسية للمجال WebLogic تلقائيًا بتوزيع التكوين ضمن الدليل weblogic_domain_name/config على نقاط التوصيل الأخرى في نفس المجال.

    تتم مزامنة عمليات نشر التطبيقات المخصصة (ملفات الأذن/الحرب وخطط التوزيع، وما إلى ذلك) وكل شيء موجود ضمن دليل مجال Oracle WebLogic Administration Server (باستثناء البيانات المؤقتة) مبدئيًا عبر المواقع باستخدام الإجراءات الموضحة في هذا المستند. إذا كان Oracle WebLogic Administration Server يستخدم بيانات موجودة في نقاط توصيل أخرى أو خارج دليل المجال، فيجب نسخها يدويًا إلى الموقع الثانوي. يتم توفير تفاصيل إضافية حول استنساخ التكوين لاحقًا.

اعتبارات قاعدة البيانات البديلة للقطات في Oracle Autonomous Database Serverless

عند تنفيذ هذا الحل، ضع في اعتبارك ما يلي عند تمكين قاعدة البيانات البديلة للقطات في قاعدة بيانات Oracle Autonomous Database Serverless.

  • الحد الزمني لقاعدة البيانات البديلة للقطات في بنية أساسية بدون خادم

    عند عدم إعادة توصيل قاعدة البيانات البديلة للقطات في Oracle Autonomous Database Serverless خلال 48 ساعة، تقوم قاعدة البيانات البديلة للقطات بإعادة الاتصال تلقائيًا بقاعدة البيانات المصدر.

  • العودة إلى نظير التعافي من الكوارث

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

  • آثار تكلفة قاعدة البيانات البديلة للقطات في Oracle Autonomous Database Serverless

    تتم فوترة استخدام وحدة المعالجة المركزية (CPU) البديلة للقطة على أساس عدد وحدات المعالجة المركزية (CPU) الأساسي وأي استخدام إضافي لوحدة المعالجة المركزية (CPU) في حالة تمكين حساب القياس الآلي. يتم تحديد عدد وحدات المعالجة المركزية الأساسية من خلال عدد وحدات المعالجة المركزية ECPU (وحدات المعالجة المركزية OCPU) إذا كانت قاعدة البيانات تستخدم وحدات OCPU) كما هو موضح في حقل عدد وحدات المعالجة المركزية ECPU أو حقل عدد OCPU في وحدة تحكم Oracle Cloud Infrastructure .

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

لمزيد من التفاصيل، راجع حول قواعد البيانات البديلة للقطات بعد الكوارث.

اعتبارات قاعدة البيانات البديلة للقطات في Oracle Autonomous Database on Dedicated Exadata Infrastructure

عند تنفيذ هذا الحل، يجب مراعاة ما يلي عند تمكين قاعدة البيانات البديلة للقطات في Oracle Autonomous Database on Dedicated Exadata Infrastructure.

  • الحد الزمني لقاعدة البيانات البديلة للقطات في بنية أساسية مخصصة

    عندما لا يتم تحويل قاعدة البيانات البديلة للقطات في Oracle Autonomous Database on Dedicated Exadata Infrastructure إلى قاعدة البيانات البديلة الفعلية في غضون 7 أيام، يتم تحويل قاعدة بيانات اللقطة البديلة تلقائيًا إلى قاعدة البيانات البديلة الفعلية.

  • إعادة التحويل إلى بديل فعلي

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

  • خدمات قاعدة البيانات عند التحويل إلى بديل للقطة

    في Oracle Autonomous Database on Dedicated Exadata Infrastructure، يعرض مربع الحوار "تحويل إلى قاعدة البيانات البديلة للقطات" خيارين:

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

لمزيد من التفاصيل، يرجى الاطلاع على حول Autonomous Data Guard.

اعتبارات النسخ القابلة للتجديد عن بُعد في Oracle Autonomous Database Serverless

فكر فيما يلي عند استخدام نسخة قابلة للتجديد من Oracle Autonomous Database Serverless لاختبار نظام Oracle WebLogic Server for Oracle Cloud Infrastructure أو Oracle SOA Suite on Marketplace أو Oracle Fusion Middleware الثانوي والتحقق منه.

  • دورة حياة النسخ القابلة للتجديد

    على عكس Oracle Data Guard البديل التقليدي، يتم تمكين النسخ القابلة للتجديد عن بُعد بشكل منفصل وإدارتها بشكل منفصل عن النسخة الأساسية والقاعدة الاحتياطية. وهو كيان مستقل بدورة حياته الخاصة يتجاوز عمليات التجديد التي تجعله متزامنًا مع قاعدة البيانات المصدر (الأساسي).

  • تخصيص موارد وحدة المعالجة المركزية

    لا يتم إنشاء النسخ القابلة للتجديد عن بُعد بناءً على تخصيص موارد وحدة المعالجة المركزية (CPU) للنظام الأساسي أو البديل. وهذا يعني أنه يجب تحديد خيارات OCPU للاستنساخ القابل للتجديد بشكل منفصل. يجب تكوين اختبارات حمل العمل يدويًا في النسخة القابلة للتجديد عن بُعد لمطابقة قدرة النظام الأساسي. ومن الناحية المثالية، يجب تكوين النسخة القابلة للتجديد عن بُعد بتكوين مطابق لقاعدة البيانات الأساسية بحيث يكون اختبار أحمال العمل واقعيًا في المرحلة الثانوية. وعلى الرغم من ذلك، فإن النسخ القابلة للتجديد عن بُعد "تنقل" تكوين التخزين المستخدم في الأساس.

  • المجموعات

    يتم تطبيق التصحيحات تلقائيًا أسبوعيًا على Oracle Autonomous Database Serverless، لكل فترة صيانة أسبوعية، لذلك توجد مزامنة مستمرة وقوية للتصحيحات بين النسخة الأساسية والبديلة والقابلة للتجديد عن بُعد.

  • حدود الخدمة

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

  • استنساخ قابل للتحديث عند التبديل

    عند حدوث تجاوز الفشل أو "تبديل غير قابل للعكس على الفور"، يجب إنشاء استنساخ قابل للتحديث يدويًا بشكل أساسي للحفاظ على النظام جاهزًا لعمليات الاختبار والصيانة في النظام الثانوي، مع حدود الخدمة المناسبة والإدارة والاعتبارات الأخرى). تفتقر النسخ القابلة للتجديد عن بُعد إلى التحكم في عكس الأدوار.

    بعد التبديل إلى الثانوية، لن يتمكن الاستنساخ القابل للتجديد الذي تم تكوينه من التجديد بعد الآن (بما أن مصدره أصبح الآن بديلاً) ويتم تعليمه على أنه غير متصل. بعد 24 ساعة يصبح استنساخ غير قابل للتجديد وغير متصل.

  • نافذة تجديد النُسخ القابلة للتجديد

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

  • وضع كتابة النُسخ القابلة للتجديد

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

اعتبارات tns_admin موقع مجلد التكوين

فكر فيما يلي في مجلد تكوين tns_admin.

  • استخدم موقعًا متسقًا لمجلد tns_admin

    تستخدم الطبقات الوسطى في النطاق WebLogic مجلدًا لتخزين حافظة Oracle Autonomous Database وملف tnsnames.ora. تشير الخاصية oracle.net.tns_admin إلى هذا المجلد في مصادر البيانات وملفات تكوين jps. يجب أن يكون مسار هذا المجلد هو نفسه في الطبقات الوسطى الأساسية والبديلة. إذا كان مسار المجلد مختلفًا، فقم بتغيير المجلد إما في المجلد الأساسي أو البديل، بحيث يستخدم نفس المجلد، قبل تشغيل اسكربتات إعداد استعادة القدرة على العمل بعد الكوارث (DR).

    ملاحظة:

    قد يتسبب ما يلي في وجود اختلافات بين الأساسي والبديل في موقع المجلد هذا:
    • طبعات Oracle SOA Suite في السوق المزودة قبل نهاية فبراير 2023 (قبل الإصدار 23.1.1) استخدم $DOMAIN_HOME/config/atp لمجلد tns_admin. بدءًا من الإصدار 23.1.1، الموقع هو $DOMAIN_HOME/config/tnsadmin.
  • مجلد tns_admin ضمن مجلد المجال config

    تحقق من موقع حافظة Oracle Autonomous Database في تكوين مصدر بيانات WebLogic. إذا لم تكن الحافظة موجودة ضمن الدليل DOMAIN_HOME/config، فلن يتم استنساخ التغييرات التي تم إجراؤها على محتويات دليل الحافظة بواسطة بنية Oracle WebLogic Server الأساسية إلى نقاط التوصيل الأخرى تلقائيًا. في هذه الحالات، يجب إما تغيير دليل الحافظة (وتحديث تكوينات مصادر البيانات المطلوبة)، أو نسخه يدويًا إلى نقاط توصيل أخرى عند تحديثه.