مشاركة عبر

أداء قاعدة بيانات Oracle على وحدات تخزين مفردة لـ Azure NetApp Files

  • مقالة

تتناول هذه المقالة المواضيع التالية حول Oracle في السحابة. قد تكون هذه الموضوعات ذات أهمية خاصة لمسؤول قاعدة البيانات أو مهندس السحابة أو مهندس التخزين:

  • عندما تقود حمل عمل معالجة المعاملات عبر الإنترنت (OLTP) (في الغالب إدخال/إخراج عشوائي) أو حمل عمل معالجة تحليلية عبر الإنترنت (I/O تسلسلي في الغالب)، كيف يبدو الأداء؟
  • ما الفرق في الأداء بين عميل Linux kernel NFS (kNFS) العادي وعميل NFS المباشر الخاص ب Oracle؟
  • فيما يتعلق بالنطاق الترددي، هل أداء وحدة تخزين Azure NetApp Files واحدة كافية؟

هام

للنشر الصحيح والمثلى ل Orace dNFS، اتبع إرشادات التصحيح الموضحة هنا.

بيئة الاختبار والمكونات

يوضح الرسم التخطيطي التالي البيئة المستخدمة للاختبار. للاتساق والبساطة، تم استخدام أدلة المبادئ Ansible لنشر جميع عناصر سرير الاختبار.

Oracle testing environment

تكوين الجهاز الظاهري

استخدمت الاختبارات الإعداد التالي للجهاز الظاهري:

  • نظام التشغيل:
    RedHat Enterprise Linux 7.8 (wle-ora01)
  • أنواع المثيلات:
    تم استخدام نموذجين في الاختبار - D32s_v3 D64s_v3
  • عدد واجهات الشبكة:
    وضع واحد (1) في الشبكة الفرعية 3
  • الاقراص:
    تم وضع ثنائيات Oracle ونظام التشغيل في قرص متميز واحد

تكوين Azure NetApp Files

استخدمت الاختبارات تكوين Azure NetApp Files التالي:

  • حجم تجمع السعة:
    تم تكوين أحجام مختلفة من التجمع: 4 تيرابايت، 8 تيبي بايت، 16 تيبي بايت، 32 تيبي بايت
  • مستوى الخدمة:
    Ultra (128 ميجابايت/ ثانية من النطاق الترددي لكل 1 تيرابايت من سعة وحدة التخزين المخصصة)
  • وحدات التخزين:
    تم تقييم اختبار وحدة تخزين واحد واثنين

منشئ حمل العمل

استخدمت الاختبارات حمل العمل الذي أنشأ SLOB 2.5.4.2. SLOB (معيار Oracle الصغير السخيف) هو منشئ حمل العمل المعروف في مساحة Oracle المصممة للإجهاد واختبار النظام الفرعي الإدخال/الإخراج مع حمل عمل الإدخال/الإخراج الفعلي المخزن مؤقتا SGA.

لا يدعم SLOB 2.5.4.2 قاعدة البيانات القابلة للتوصيل (PDB). على هذا النحو، تمت إضافة تغيير إلى البرامج النصية setup.sh و runit.sh لإضافة دعم PDB إليه.

يتم وصف متغيرات SLOB المستخدمة في الاختبارات في الأقسام التالية.

حمل العمل 80٪ SELECT، تحديث 20٪ | الإدخال/إخراج عشوائي – slob.conf المتغيرات

UPDATE_PCT=20
SCAN_PCT=0
RUN_TIME=600
WORK_LOOP=0
SCALE=75G
SCAN_TABLE_SZ=50G
WORK_UNIT=64
REDO_STRESS=LITE
LOAD_PARALLEL_DEGREE=12

حمل العمل 100٪ SELECT | الإدخال/إخراج التسلسل – slob.conf المتغيرات

UPDATE_PCT=0
SCAN_PCT=100
RUN_TIME=600
WORK_LOOP=0
SCALE=75G
SCAN_TABLE_SZ=50G
WORK_UNIT=64
REDO_STRESS=LITE
LOAD_PARALLEL_DEGREE=12

قاعدة بيانات

إصدار Oracle المستخدم للاختبارات هو Oracle Database Enterprise Edition 19.3.0.0.

معلمات Oracle كما يلي:

  • sga_max_size: 4096M
  • sga_target: 4096
  • db_writer_processes: 12
  • awr_pdb_autoflush_enabled:صحيح
  • filesystemio_options: SETALL
  • log_buffer: 134217728

تم إنشاء PDB لقاعدة بيانات SLOB.

يوضح الرسم التخطيطي التالي مساحة الجدول المسماة PERFIO بحجم 600 غيغابايت (20 ملف بيانات، 30 غيغابايت لكل منها) تم إنشاؤها لاستضافة أربعة مخططات مستخدم SLOB. كان حجم كل مخطط مستخدم 125 غيغابايت.

Oracle database

مقاييس الأداء

كان الهدف هو الإبلاغ عن أداء الإدخال/الإخراج كما هو من خلال التطبيق. لذلك، تستخدم جميع الرسومات التخطيطية في هذه المقالة المقاييس التي تم الإبلاغ عنها بواسطة قاعدة بيانات Oracle عبر تقارير مستودع حمل العمل التلقائي (AWR). المقاييس المستخدمة في الرسومات التخطيطية هي كما يلي:

  • متوسط طلبات الإدخال/الثانية
    يتوافق مع مجموع متوسط طلبات قراءة IO/ثانية ومتوسط طلبات كتابة IO/ثانية من قسم ملف تعريف التحميل
  • متوسط IO MB/sec
    يتوافق مع مجموع متوسط قراءة IO MB/sec ومتوسط كتابة IO MB/sec من قسم ملف تعريف التحميل
  • متوسط زمن انتقال القراءة
    يتوافق مع متوسط زمن الانتقال لحدث انتظار Oracle "قراءة ملف db المتسلسلة" في ميكرو ثانية
  • عدد مؤشرات الترابط/المخطط
    يتوافق مع عدد مؤشرات ترابط SLOB لكل مخطط مستخدم

نتائج قياس الأداء

يصف هذا القسم نتائج قياس الأداء.

عميل Linux kNFS مقابل Oracle Direct NFS

كان هذا السيناريو قيد التشغيل على جهاز Azure الظاهري Standard_D32s_v3 (Intel E5-2673 v4 @ 2.30 غيغاهرتز). حمل العمل هو 75٪ SELECT و25٪ UPDATE، ومعظمهم من الإدخال/الإخراج العشوائي، ومع إصابة مخزن مؤقت لقاعدة البيانات بنسبة ~7.5٪.

كما هو موضح في الرسم التخطيطي التالي، قام عميل Oracle DNFS بتسليم معدل نقل يصل إلى 2.8x أكثر من عميل Linux kNFS العادي:

Linux kNFS Client compared with Oracle Direct NFS

يوضح الرسم التخطيطي التالي منحنى زمن الانتقال لعمليات القراءة. في هذا السياق، الازدحام لعميل kNFS هو اتصال مأخذ توصيل NFS TCP واحد تم إنشاؤه بين العميل وخادم NFS (وحدة تخزين Azure NetApp Files).

Linux kNFS Client compared with Oracle Direct NFS latency curve

كان عميل DNFS قادرا على دفع المزيد من طلبات الإدخال/الثانية بسبب قدرته على إنشاء مئات اتصالات مأخذ توصيل TCP، وبالتالي الاستفادة من التوازي. كما هو موضح في تكوين Azure NetApp Files، يسمح كل TiB إضافي من السعة المخصصة ب 128MiB/ ثانية إضافية من النطاق الترددي. تصدر DNFS بمعدل نقل 1 غيغابايت/ثانية، وهو الحد الذي يفرضه اختيار السعة 8 تيرابايت. ونظرا لمزيد من السعة، كان من شأن المزيد من معدل النقل أن يكون مدفوعا.

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

Linux kNFS Client compared with Oracle Direct NFS read latency

توفر المدرجات التكرارية نظرة ثاقبة ممتازة على زمن انتقال قاعدة البيانات. يوفر الرسم التخطيطي التالي طريقة عرض كاملة من منظور "القراءة التسلسلية لملف db" المسجلة، أثناء استخدام DNFS في أعلى نقطة بيانات التزامن (32 مؤشر ترابط/مخطط). كما هو موضح في الرسم التخطيطي التالي، تم تكريم 47٪ من جميع عمليات القراءة بين 512 ميكرو ثانية و1000 ميكرو ثانية، بينما تم تقديم 90٪ من جميع عمليات القراءة في زمن انتقال أقل من 2 مللي ثانية.

Linux kNFS Client compared with Oracle Direct NFS histograms

في الختام، من الواضح أن DNFS هو أمر لا بد منه عندما يتعلق الأمر بتحسين أداء مثيل قاعدة بيانات Oracle على NFS.

حدود أداء وحدة التخزين الفردية

يصف هذا القسم حدود أداء وحدة تخزين واحدة مع الإدخال/الإخراج العشوائي والإدائي/الإخراج التسلسلي.

إدخال/إخراج عشوائي

DNFS قادر على استهلاك نطاق ترددي أكبر بكثير مما يتم توفيره من خلال حصة أداء Azure NetApp Files 8-ТБ. من خلال زيادة سعة وحدة تخزين Azure NetApp Files إلى 16 تيرابايت، وهو تغيير فوري، زاد مقدار النطاق الترددي لوحدة التخزين من 1024 ميجابايت/ثانية بمقدار 2X إلى 2048 MiB/s.

يوضح الرسم التخطيطي التالي تكوينا لعبء عمل تحديد بنسبة 80٪ وتحديث 20٪، ونسبة إصابة المخزن المؤقت لقاعدة البيانات بنسبة 8٪. تمكنت SLOB من دفع وحدة تخزين واحدة إلى 200,000 طلب إدخال/إخراج NFS في الثانية. بالنظر إلى أن كل عملية بحجم 8 كيبيبايت، تمكن النظام قيد الاختبار من تقديم ~200,000 طلب IO/ثانية أو 1600 ميبي بايت/ثانية.

Oracle DNFS throughput

يوضح الرسم التخطيطي التالي لمنحنى زمن انتقال القراءة أنه مع زيادة معدل نقل القراءة، يزداد زمن الانتقال بسلاسة أسفل خط 1 مللي ثانية، ويضرب الركبة في المنحنى عند متوسط طلبات الإدخال والإخراج في الثانية 165,000 تقريبا عند متوسط زمن انتقال القراءة البالغ ~1.3 مللي ثانية. هذه القيمة هي قيمة زمن انتقال لا يصدق لمعدل الإدخال/الإخراج غير قابلة للتنفيذ مع أي تقنية أخرى تقريبا في Azure Cloud.

Oracle DNFS latency curve

الإدخال/إخراج تسلسلي

كما هو موضح في الرسم التخطيطي التالي، ليس كل عمليات الإدخال/الإخراج عشوائية بطبيعتها، مع الأخذ في الاعتبار النسخ الاحتياطي ل RMAN أو فحص الجدول الكامل، على سبيل المثال، كأحمال العمل التي تتطلب أكبر قدر ممكن من النطاق الترددي. باستخدام نفس التكوين كما هو موضح سابقا ولكن مع تغيير حجم وحدة التخزين إلى 32 تيرابايت، يوضح الرسم التخطيطي التالي أن مثيل Oracle DB واحد يمكن أن يدفع ما يزيد عن 3900 ميغابايت/ثانية من معدل النقل، بالقرب جدا من حصة أداء وحدة تخزين Azure NetApp Files البالغة 32 ТБ (128 ميغابايت/ثانية * 32 = 4096 ميغابايت/ثانية).

Oracle DNFS I/O

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

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