آموزش، مشاوره و پشتیبانی دیتابیس اوراکل

تست failover دیتاگارد 19.12 و خطای ORA-16629

داشتم تست failover و حداکثر پایداری برای اپلیکیشن رو انجام میدادم به دو نکته برخورد کردم.

اولین نکته اینه که شما اگه میخواین تست failover انجام بدید اگه تو دیتابیس primary و standby مکانیزم flashback فعال باشه میتونید بدون راه اندازی کامل standby از اول این کار رو انجام بدید ولی اگه flashback فعال نباشه باید از اول به طور کامل standby جدید راه اندازی بشه. به این مکانیزم REINSTATE گفته میشه

نحوه انجام با broker

ابتدا فعال بودن flashback رو در primary و standby چک میکنیم:

SELECT FLASHBACK_ON FROM V$DATABASE;

برای چک کردن وضعیت بهتره یکباره از دستور show configuration استفاده بکنیم:

DGMGRL> show configuration
Configuration - g90
Protection Mode: MaxAvailability
Members:
tehrang - Primary database
tehran - Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 91 seconds ago)

حالا باید دیتابیس fail شده رو که به مدار و حالت mount ببریم:

SQL> startup mount
ORACLE instance started.
Total System Global Area 4294964072 bytes
Fixed Size 9143144 bytes
Variable Size 2634022912 bytes
Database Buffers 1644167168 bytes
Redo Buffers 7630848 bytes
Database mounted.

ادامه مطلب...
۱۰ آبان ۰۰ ، ۰۸:۴۶ ۰ نظر
مهدی غفاری

ساخت سرویس جدید در سناریو دیتاگارد بدون زیرساخت Grid

تو سناریوی اوراکل دیتاگارد ما یک مدار دیتابیسی تشکیل میدیم که هر وقت سرور اصلی در سایت A از دسترس خارج شد اپلیکیشن با وقفه کوتاهی بتونه به سرور دوم در سایت B متصل بشه (تو سناریو حداکثر پایداری بهتره اپلیکیشن های ریپورت به دیتاگارد متصل نشن و برای سناریو اکتیو دیتاگارد یک دیتاگارد مجزا و مختص به ریپورت به صورت آبشاری راه اندازی بشه که بار روی سرور اصلی هم نباشه)

جهت انجام خودکار این سناریو به طوری که اپلیکیشن به یک سرویس جدا وصل بشه و وابسته به سرویس و IP در هر Instance در مواقع Failover و Switchover نباشه میتونید به شیوه زیر عمل کنید:

ادامه مطلب...
۰۸ آبان ۰۰ ، ۱۴:۰۱ ۰ نظر
مهدی غفاری

داستانهای واقعی: افزایش فضای shared pool

یک RAC سه نود بر روی اوراکل نسخه 12.2 داریم. مدتی بود در وقت های پیک کاری اپلیکیشن، با ویت ایونت gc current block 2-way و ... و با مقدار بالا برخورد میکردم به نحوی که کارکرد اپلیکیشن رو مورد تاثیر خود قرار داده بود. از طرفی تمام موارد مرتبط با GC در کلاستر رو با دقت و وسواس بالا با توجه به آخرین Best Practiceها پیکربندی و بازبینی کرده بودم (به خصوص پارامترهای مرتبط با LMS مانند GCS_SERVER_PROCESSES) و با مانیتورینگ شبکه و سرعت Interconnect هام از سرعت و وضعیت خوب اونها مطمئن بودم همچنین با توجه به مشاهدات محیطی به این نتیجه رسیده بودم که در طول 2 ماه کارکرد اپلیکیشن تنها در انتهای بازه های پیک اپلیکیشن این مشکل دیده میشد پس این موضوع کنجکاوی من رو برای این که بفهمم مشکل کجا بود بیشتر کرد.

تو بررسی هام از طریق Memory Advisor در Enterprise Manager متوجه شدم که در این روزها فضای shared pool به طرز قابل توجهی بالا میره و فضای buffer cache بسیار کوچیک میشه پس با این فرض همه چیز منطقی به نظر میومد. چون با رشد فضای shared pool فضای کافی برای buffer cache نبود.

زمانی که سیستم در وضعیت و پرفورمنس مناسب قرار داشت

 

ادامه مطلب...
۲۷ مهر ۰۰ ، ۰۷:۴۵ ۴ نظر
مهدی غفاری

VMware در مقابل Oracle - ذخیره سازی - تاثیر Cache Page Size

مقدار پیش فرض پیکربندی Page Size کش در دستگاه CLARiiON CX3‐40 برابر 8K است. این پیکربندی تاثیر مستقیم بر خواندن ترتیبی بلاک های کوچکتر از مقدار بلاک های cache را دارد. توصیه EMC این است که مقدار پیکربندی اندازه کش با بلاک سایزهای نوشته شده بر روی دیسک یکسان باشد. نتایج نشان می دهد این کار 226 درصد بهبود تعداد عملیات های I/O را در هر ثانیه ایجاد می کند.

عملیات خواندن ترتیبی I/O در هر ثانیه برای مقادیر 4K در خواندن ترتیبی با کش سایز متفاوت از بلاک سایز (نمودار بالاتر عملکرد بهتر را نشان می دهد)

شکل پایین نشان دهنده هزینه CPU برای هر عملیات I/O در تکنولوژی VMFS و RDM با 4K و 8K و مقدار 8K برای سایز کش است. ما از هزینه CPU در RDM با سایز کش 4K نیز تست گرفتیم و مقایسه این تکنولوژی ها رو باهم بر روی 4K و 8K سایز کش انجام دادیم. همانطور که مشاهده می کنید وقتی سایز کش با بلاک سایز یکی است هزینه CPU نزدیک 70 درصد در هر دو تکنولوژی VMFS و RDM بهبود یافته است.

هزینه عملیات CPU برای خواندن ترتیبی 4K با کش سایزهای متفاوت (نمودار پایینتر عملکرد بهتر را نشان می دهد).

۲۵ مهر ۰۰ ، ۱۰:۰۷ ۰ نظر
مهدی غفاری

VMware در مقابل Oracle - ذخیره سازی - نتیجه گیری

نتیجه گیری

سرور Vmware ESX به شما 2 گزینه برای دسترسی و مدیریت دیسک پیشنهاد می دهد – VMFS و RDM. هر دو اینها از فایل سیستم کلاستر، اسامی کاربر پسند برای دیسک ها و فایل های اختصاص یافته شده پشتیبانی شده استفاده می کنند. هر دو VMFS و RDM از مهاجرت به وسیله vmotion پشتیبانی می کنند. این مطالعه مقایسه سرعت و کارایی را انجام داد و به غیر از تفاوت های ریز در سرعت و کارایی مورد دیگه ای پیدا نکرد.

برای تست لود دسترسی تصادفی بین VMFS و RDM در یک توان کاری I/O مشخص تفاوتی قابل محسوسی ندیدیم. در تست لود ترتیبی با سایز بلاک های I/O کوچک تکنولوژی RDM با افزایش کم توان کاری نسبت به VMFS برتری دارد. با این حال با افزایش سایز بلاک های I/O این گپ در توان کاری بین VMFS و RDM کمتر می گردد.

در تمام تست های لود با بلاک سایزهای متفاوت RDM هزینه مصرف CPU خیلی بهتری نسبت به VMFS دارد.

نتایج تست در این مطالعه نشان می دهد VMFS و RDM تقریبا یک لود کاری مشابه را در عملیات های I/O برای اکثر لودهای کاری ارائه می دهند. اما یک تفاوت در سرعت و کارایی I/O در لودهای کاری مواقعی است که CPU ماشین مجازی بر روی یک هاست با CPU کاملا رزرو شده اجرا گردد یا در این وضعیت بیافتد. البته این تفاوت فقط در اپلیکیشن هایی در دنیای واقعی قابل دیدن است که ماشین مجازی ها بخواهند از تمام ظرفیت منابع خود استفاده کنند. شما باید بسته به نوع سرویس انتخابی و SLA خود یکی از این 2 تکنولوژی را برای اپلیکیشن های Enterprise انتخاب کنید.

به هر حال چند نمونه براتون مثال می زنیم که بدونید چه اپلیکیشن هایی باید از RDM استفاده کنند:

  • اپلیکیشن های backup که به طور ترتیبی دیتا رو با یک بلاک سایز مشخص از دیسک می خوانند
  • اپلیکیشن های پایگاه داده که بار کاری بالایی بر روی دیتا دارند و نیازمند سرعت و کارایی زیاد هستند

به هر حال استفاده از تکنولوژی RDM نه فقط برای سرعت و کارایی این اپلیکیشن ها بلکه برای دسترسی سطح پایینتر به کنترلر دیسک به جای یک لایه سربار کنترلر مجازی توصیه میگردند.

سخت افزارهای مورد استفاده

  • ذخیره ساز: CLARiiON CX3‐40 (4Gbps)
  • حافظه: 4 گیگ برای هر پردازنده ذخیره ساز
  • دیسک های مورد استفاده: 25 دیسک برند segate 146 گیگ با سرعت 15K RPM با RAID 0
  • HBA برند QLA 2460 4Gbps

نرم افزار

  • مجازی ساز: ESX Server 3.5 (build 64607)

پیکربندی سیستم عامل مهمان

  • سیستم عامل: ویندوز سرور 2003 سرویس پک 2 معماری 32 بیتی با 512 مگابایت رم و 1 سی پی یو سوکت
  • دیسک تست: 20 گیگابایت دیسک فرمت نشده

پیکربندی ذخیره ساز

  • کش خواندن: 1 گیگابایت برای هر پردازنده ذخیره ساز
  • کش نوشتن: 1.9 گیگابایت
  • RAID-0 گروه 1: 10 دیسک (10 گیگابایت LUN)
  • RAID-0 گروه 2: 15 دیسک (10 گیگابایت LUN)
  • ظرفیت MetaLUN: 20 گیگابایت

پیکربندی Iometer

  • تعداد عملیات های I/O ورودی و خروجی: 64
  • زمان اجرا: 5 دقیقه
  • زمان افزایش شیب: 60 ثانیه
  • تعداد workerهای خودکار: 1

۲۵ مهر ۰۰ ، ۰۹:۵۴ ۰ نظر
مهدی غفاری

VMware در مقابل Oracle - ذخیره سازی - تست لود

تست لود تصادفی

در این تست لود تصادفی برای تکنولوژی VMFS و RDM به جهت دسترسی به سرعت و کارایی بالا مد نظر است:

لود تصادفی ادغامی (50 درصد تست دسترسی خواندن و 50 درصد تست دسترسی نوشتن) (بالا بودن نمودار عملکرد بهتر را نشان می دهد)

دسترسی تصادفی خواندن برای عملیات I/O در هر ثانیه (بالا بودن نمودار عملکرد بهتر را نشان می دهد)

دسترسی تصادفی نوشتن برای عملیات I/O در هر ثانیه (بالا بودن نمودار عملکرد بهتر را نشان می دهد)

تست لود ترتیبی

برای خواندن ترتیبی با بلاک سایز 4K ما تغییراتی را در مقدار بلاک سایز کش در سخت افزار خود (CLARiiON CX3‐40) به مقدار 4k انجام داده ایم. البته برای باقی تست ها از همان مقدار پیش فرض 8K در بلاک سایز کش استفاده کرده ایم.

در سرور ESX 3.5 سرعت و کارایی لود ترتیبی تکنولوژی VMFS خیلی نزدیک به RDM برای تمام بلاک سایزهای تولیدی به جز 4K بود.اغلب اپلیکیشن ها با لود ترتیبی از بلاک سایزهایی با مقادیر بیشتر از 4K استفاده می کنند. هر 2 تکنولوژی های VMFS و RDM تقریبا عملکردی مشابه در سرعت و کارایی داشتند.

هر 2 تکنولوژی های VMFS و RDM توان کاری (throughput) بالایی را از خود نشان دادن به جز مواردی که باری نزدیک 300 مگابایت در ثانیه در حال اجرا بود.

تست لود خواندن ترتیبی عملیاتهای I/O بر حسب ثانیه (بالا بودن نمودار عملکرد بهتر را نشان می دهد)

تست لود نوشتن ترتیبی عملیات های I/O بر حسب ثانیه (بالا بودن نمودار عملکرد بهتر را نشان می دهد)

جداول پایین میزان توان کاری (throughput) بر حسب ثانیه را برای VMFS و RDM مکتوب کرده اند. میازن توان کاری(throughput) بر حسب (عملیات های IO * سایز دیتا) با نمایش مقدارهای متناظر است:

جدول میزان توان کاری برای لود تصادفی بر حسب مگابایت بر ثانیه

Random Write

Random Read

Random Mix

RDM (P)

RDM (V)

VMFS

RDM (P)

RDM (V)

VMFS

RDM (P)

RDM (V)

VMFS

Data Size (KB)

45.87

46.1

46.38

23.27

23.27

23.41

31.15

30.98

30.96

4

88.74

89.22

90.24

44.35

44.43

44.67

58.68

58.68

58.8

8

159.42

158.25

161.2

80.58

80.72

80.14

105.09

106.03

105.22

16

242.05

241.12

241.4

138.11

138.53

135.91

176.69

176.1

173.72

32

310.15

311.13

309.6

214.59

215.49

215.1

263.98

262.92

256.14

64

جدول میزان توان کاری برای لود کاری ترتیبی

Sequential Write

Sequential Read

RDM (P)

RDM (V)

VMFS

RDM (P)

RDM (V)

VMFS

Data Size (KB)

93.36

93.8

93.76

153

142.13

137.21

4

187.84

188.45

188.45

188.56

284.41

272.61

8

278.91

281.17

281.17

280.95

338.75

341.08

16

352.89

354.86

354.86

352.17

364.23

363.86

32

386.81

385.36

384.02

377.09

377.6

377.35

64

هزینه CPU

هزینه CPU براساس تعداد سایکل های CPU برای انجام یک عمل واحد I/O برای استفاده از توان کاری (به بایت) محاسبه میگردد. ما محاسبه سایکل های CPU را براساس استفاده ماشین مجازی از CPU فیزیکی برای اجرای تست لود کاری گرفته ایم. ما برای محاسبه لود کاری سربار مجازی سازی را نیز جهت مجازی سازی ماشینهای متفاوت براساس پراسس های سرور ESX حساب کرده ایم. توان CPU براساس MHz و تمام coreهای درگیر در سیستم رنک بندی میگردند. در این مطالعه معیارهای هزینه CPU براساس تعداد سایکل های CPU بر حسب واحدهای عملیاتی I/O در هر ثانیه دیده شده است.

نتیجه هزینه CPU عادی برای لودهای کاری متفاوت در شکل های زیر نمایش داده شده است. ما هزینه CPU را برای RDM (مپ کردن فیزیکی دستگاه ذخیره ساز به ماشین مجازی) برای هر تست لود کاری با مقایسه آن با تکنولوژی VMFS مشخص کرده ایم.

در تست لود تصادفی هزینه CPU تکنولوژی VMFS حدود 5 درصد بیشتر از هزینه CPU در تکنولوژی RDM بوده است.

همچنین در تست لود ترتیبی هزینه CPU تکنولوژی VMFS حدود 8 درصد بیشتر از هزینه CPU در تکنولوژی RDM بوده است.

مانند هر فایل سیستم دیگه ای VMFS نیز ساختمان داده را برای مپ شدن دیتا بر روی دیسک فیزیکی در خود ذخیره می کند.هر درخواست I/O برای دستسری به دیتای ذخیره سازی شده ابتدا باید یک درخواست برای لود متادیتا ارسال کند تا مپ بلاک های دیسک قبل از هر عملیات خواندن یا نوشتن در حافظه لود گردد. هربار انجام اینکار سایکل CPU را تعدادی بالاتر می برد. پس طبیعی است برای دسترسی به داده های زیاد در زمان کم ما نیاز به سایکل های خیلی بیشتری داریم. بر عکس VMFS تکنولوژی RDM نیازی به این مپ ندارد. وقتی دیتا به صورت مستقیم بر روی دیسک شما نوشته می شود سربار اضافه حذف میگردد و سایکل های CPU اضافه ای رخ نخواهد داد پس از نظر CPU تکنولوژی RDM خیلی بهتر از VMFS عمل می کند.

هزینه CPU عادی برای دسترسی تصادفی به صورت خواندن/نوشتن در انواع بلاک سایزها (نمودار کم بهتر است)

هزینه CPU عادی برای دسترسی تصادفی به صورت خواندن در انواع بلاک سایز ها (نمودار کم بهتر است)

هزینه CPU عادی برای دسترسی تصادفی فقط نوشتن در انواع بلاک سایزها (نمودار کم بهتر است)

هزینه CPU عادی برای دسترسی تصادفی فقط خواندن در انواع بلاک سایزها (نمودار کم بهتر است)

هزینه CPU عادی برای دسترسی تصادفی فقط نوشتن در انواع بلاک سایزها (نمودار کم بهتر است)

۲۵ مهر ۰۰ ، ۰۹:۳۴ ۰ نظر
مهدی غفاری

VMware در مقابل Oracle - ذخیره سازی - قسمت چهارم

خلاصه تست اجرایی توسط شرکت Vmware

نتیجه گیری نهایی تست شرکت Vmware در مقایسه استفاده از VMFS یا RDM به شرح زیر مکتوب شده است:

  • برای خواندن، نوشتن تصادفی (random) هر 2 تکنولوژی تقریبا نتایج مشابهی در عملیات های IO در ثانیه داشتند
  • در خواندن، نوشتن ترتیبی (sequential) سرعت VMFS خیلی نزدیک به RDM بود (به غیر از مواردی که بلاک سایزها 4k در نظر گرفته شده بود). هر 2 تکنولوژی ها توان عملیاتی (throughput) بالایی رو داشتند به غیر از مورد نوشتن 300 مگابایت در ثانیه که VMFS به خوبی در آن عمل نکرد.
  • در خواندن و نوشتن تصادفی (random) فایل سیستم VMFS نیازمند 5 درصد CPU بیشتر در هر cycle عملیات IO در مقایسه با RDM بود.
  • در خواندن و نوشتن ترتیبی (sequential) فایل سیستم VMFS نیازمند 8 درصد CPU بیشتر در هر cycle عملیات IO در مقایسه با RDM بود.

جهت مطالعه کامل سناریو تست به داکیومنت زیر مراجعه گردد:

Performance Characterization of VMFS and RDM Using a SAN: ESX Server 3.5 (vmware.com)

محیط تست

مطالعه در محیط تست برای مقایسه VMFS و RDM در ESX Server 3.5 انجام شده است (آخرین مستند ارائه شده توسط شرکت VMware تا زمان نگارش مطلب) تست بر روی ماشین مجازی با یک سوکت با استفاده از ویندوز سرور 2003 نسخه EE SP2 به عنوان سیستم عامل ماشین مجازی انجام شده است. سرور ESX بر روی دیسک های لوکال SCSI پیکربندی شده است. 2 دیسک مجازی به ماشین مجازی متصل شده است یکی برای سیستم عامل و یکی برای محیط تست که بر روی آن عملیات های IO صورت می گیرد. لود ایجاد شده با استفاده از ابزار Iometer بوده که یک ابزار خیلی محبوب برای سنجش سرعت و کارایی IO سخت افزار است. لیست سخت افزارها و نرم افزارهای مورد استفاده در انتها آورده شده است.

برای تمام لود ها به غیر از تست لود 4K ترتیبی خواندن از کش پیشفرض با page size برابر 8K در لایه سخت افزار و raid controller استفاده شده است. در هر حال تست لود ترتیبی خواندن 4K با کش پیش فرض سرعت و کارایی خیلی پایینی هم در VMFS و هم در RDM دارد. شرکت EMC پیشنهاد می کند مقدار کش page size در ذخیره ساز (لایه کنترلر) برابر مقدا block size اپلیکیشن باشد (در این جا برای تست 4K باید کش را برابر 4K قرار دهیم.)

از این رو برای تست لود ترتیبی خواندن 4K با مقدار page size کش را برابر 4K میگذاریم. برای دیدن مقایسه در زمانی که مقدار کش برابر 4K و وقتی برابر 8K قرار داده شده است نمودارهای زیر را ملاحظه کنید.

مقایسه تست لود ترتیبی خواندن در هر ثانیه در زمان قراردادن مقدار 4K برای اپلیکیشن و قراردادن page size برابر مقدار پیش فرض و مقدار 4K (بالا بودن نمودار کارایی بهتری را نشان می دهد)

هزینه استفاده از CPU برای تست ترتیبی خواندن بلاک های 4K با بلاک های کش متفاوت (پایین بودن نمودار کارایی بیشتری را نشان می دهد)

لایه دیسک

 در این مطالعه پیکربندی لایه دیسک و نحوه قرار گیری آن ها به دقت انتخاب شده است. ما سرور را به صورت مستقیم با فیبر نوری و HBA به یک دستگاه SAN با مدل CLARiiON CX3‐40 متصل کردیم. ما 2 گروه RAID 0 بر روی SAN ایجاد کردیم یکی دارای 15 دیسک و دیگری دارای 10 دیسک. ما یک LUN با حجم 10 GB بر روی هر گروه RAID ایجاد کردیم. بعد یک metaLUN با حجم 20GB با استفاده از این 2 LUN 10GB ای پیکربندی شده است.

ما از این metaLUN جهت دیسک تست استفاده می کنیم. (metaLUN امکان بهم پیوستن (Aggregate) جهت افزایش سایز و سرعت را نسبت به LUN اصلی، فراهم می آورد.) دیسک های استفاده شده برای این تست تنها برای این تست لود I/O مورد استفاده قرار گرفته اند. ما یک دیسک مجازی بر روی دیسک های تست ایجاد کردیم و اون رو برای ماشین مجازی ویندوز مورد استفاده قرار دادیم. به دلیل استفاده از زیرساخت ESX و ایجاد datastore ماشین مجازی از نوع و نحوه چینش این دیسک ها اطلاعی ندارد و اون رو به عنوان یک دیسک فیزیکی شناسایی می کند.

شکل زیر پیکربندی دیسک مورد استفاده را نمایش می دهد. در تست VMFS ما از یک دیسک مجازی با فرمت VMDK برای ذخیره سازی به عنوان پارتیشن VMFS به عنوان دیسک تست استفاده کردیم. ولی در تست RDM ما یک فایل پیکربندی RDM برای ماشین مجازی ایجاد کردیم و مپ این فایل را به دیسک تست انجام دادیم. ما پیکربندی دیسک مجازی محیط تست رو با یک LSI SCSI HBA انجام دادیم.

خوشبختانه ابزار Iometer قابلیت این را دارد که بدون ساخت پارتشین و فایل سیستم در سیست عامل بر روی یک raw دیسک تست خواندن، نوشتن را نیز انجام دهد. پس ما بدون استفاده از فایل سیستم و فرمت این فضاها تست لود کار را انجام دادیم.

پیکربندی

ما پیکربندی سیستم عامل مهمان را با استفاده از درایور و کنترلر LSI Logic SCSI انجام دادیم.در حالت استفاده از VMFS ما یک دیسک مجازی به صورت Thick Provisioned Eager Zeroed که به عنوان راهکار برتر به جهت استفاده از فضا برای دیتا در VMFS است ساختیم.

در پیکربندی ماشین مجازی تمام پارامترها از حالت پیش فرض خود تبعی کرده اند، مگر پارامترهایی که خلاف آن ها این مستند بیان شده باشد.

ما در هر test case قبل از شروع به انجام آزمایش با استفاده از برنامه های خط فرمان تمام مقادیر دیسک مجازی را 0 کردیم. (VMkfstools با آپشن w)

مشخصات لود I/O

اپلیکیشن های سازمانی (Enterprise) به طور معمول و عمومی لود I/O با پترن های متفاوت تولید می کنند. پس ندازه blockهای انتقال داده شده در سرور هاست اپلیکیشن و ذخیره ساز ممکن است به طور متناوب تغییر یابد. نحوه طراحی و شیوه چینش دیسک ها و لایه فایل سیستم برای دسترسی به سرعت و کارایی بالا در لودهای کاری بسیار بسیار مهم است.

اپلیکیشن های کمی هستند که یک پترن دسترسی مشخص برای سایز block ها دارند. یک مثال برنامه های بک آپ هستند که از یک پترن برای خواندن ترتیبی بلاک ها استفاده می کنند. دیتابیس های OLTP برخلاف این اپلیکیشنها اکثرا بسیار random کار میکنند. به صورت طبیعی اپلیکیشنها بر روزی اندازه blockهای در حال انتقال تاثیر می گذارند.

Test Caseها

در این مطالعه، مشخصات لود سرعت و کارایی برای 2 تکنولوژی VMFS و RDM برای یک رنج از بلاک ها با پترن های متفاوت را مشخص می کنیم. سایز بلاک های انتقال داده شده بین 4KB, 8KB, 16KB, 32KB و 64KB انتخاب شده اند. پترن دسترسی مشخص شده توسط ما به صورت تصادفی عملیات خواندن و نوشتن و به صورت ترتیبی عملیات خواندن و نوشتن یا ترکیبی از خواندن و نوشتن را انجام می دهد.

ایجاد لود آزمایشی

ما از Iometer که یک benchmarking tool معروف و محبوب است و به طور گسترده برای سخت افزارهای Intel جهت تست های سرعت و کارایی(performance) استفاده می گردد، برای ایجاد لود آزمایشی استفاده کردیم. Iometer توانایی تهیه و اجرای انواع تست های طراحی شده I/O را دارد. به این دلیل که ما طراحی یک تست مشخص برای سنجش سرعت و کارایی دیسک ماشین مجازی در یک دیوایس خام (raw) و VMFS را داریم از شبیه ساز لود basix برای تست های زیر استفاده می کنیم:

  • ابزار Iometer با مقادیر زیر جهت تست پیکربندی شده است:
    • انتقال بلاک ها با سایز: 4KB, 8KB, 16KB, 32KB و 64KB
    • درصد توزیع تصادفی یا ترتیبی برای هر سایز بلاک از 0 درصد تا 100 درصد توزیع
    • درصد توزیع میزان خواندن و نوشتن برای هر درخواست I/O از 0 درصد تا 100 درصد توزیع و یا حتی 50 درصد توزیع برای خواندن و 50 درصد توزیع برای نوشتن

 

  • پارامترهای زیر برای تمام حالات test case ثابت است:
    • تعداد عملیات های I/O ورودی و خروجی: 64
    • زمان اجرا: 5 دقیقه
    • زمان افزایش شیب: 60 ثانیه
    • تعداد workerهای خودکار: 1

نتایج تست سرعت و کارایی

در این بخش نتایج آنالیز تست سرعت و کارایی بر روی ماشین مجازی با یک پردازنده منتشر شده است:

معیارها

معیارهای مورد استفاده برای مقایسه بین VMFS و RDM برای I/O براساس تعداد عملیات ها در هر ثانیه، مقدار توان عملیاتی (برحسب MB بر ثانیه)، و هزینه CPU بر حسب MHz بر ثانیه است.

در این مطالعه ما گزارش معیارهای I/O را توسط معیارهای گفته شده با ابزار Iometer انجام دایدم و مقایسه را در هر بخش برای VMFS و RDM انجام دادیم. این معیارها با هزینه CPU برای هر واحد I/O با استفاده از فرمول زیر محاسبه شده اند:

تمام وضعیت های I/O و CPU جمع آوری شده توسط 2 نرم افزار Iometer و esxtop بوده اند:

  • Iometer – جمع آوری عملیات های I/O در هر ثانیه و مقدار توان عملیاتی در MB بر ثانیه
  • Esxtop – جمع آوری میانگین مصرف CPU از طریق محاسبه میزان CPU استفاده شده در ماشین مجازی در CPU فیزیکی

سرعت و کارایی

این بخش مقایسه سرعت و کارایی با مشخصات توضیح داده شده برای Test case را مورد ارزیابی قرار می دهد.

۲۵ مهر ۰۰ ، ۰۹:۲۶ ۰ نظر
مهدی غفاری

VMware در مقابل Oracle - ذخیره سازی - قسمت سوم

فعال یا غیرفعال کردن write protection در VMFS

همانطور که گفتیم VMFS یک فایل سیستم کلاستر شونده است. یکی از قابلیت های VMFS و هر فایل سیستم کلاستری پشتیبانی از عملیات multi-writer است. با فعالسازی این قابلیت هر دیسک مجازی VMFS می تواند به بیشتر از یک ماشین متصل باشد و همزمان توسط ماشین ها برا عملیات نوشتن و خواندن مورد استفاده قرار گیرد.

به شکل پیش فرض این قابلیت غیر فعال است. دلیل غیر فعال بودن این ویژگی به شکل پیش فرض این است که برخی از تکنولوژی های Vmware از این قابلیت پیشتیبانی نمی کنند و فعال بودن آن در سیستم عامل های زیادی به شکل پیش فرض پشتیبانی نمی شود.

لیست ویژگی های پشتیبانی شده و پشتیبانی نشده توسط این قابلیت

ویژگی پشتیبانی عدم پشتیبانی یادداشت
روشن کردن، خاموش کردن و ریستارت ماشین مجازی
Suspend VM ×
اضافه کردن hot دیسک مجازی تنها وقتی آداپتورها وجود داشته باشند
حذف کردن hot دیسک مجازی
افزایش hot سایز دیسک مجازی ×
connect و disconnect دستگاه ها
گرفتن snapshot × راهکارهای پشتیبان گیری مجازی همه از vStorage API ها استفاده می کنند. به عنوان مثال VMware Data Recovery یا vSphere Data Protection این موارد پشتیبانی نمی شوند.
گرفتن snapshotهای فوری از دیسک های مستقل پشتیبانی شده از vSphere 5.1 update2 به بعد
Clon گیری ×
Storage vMotion × دیسک های کلاستری نمی توانند با استفاده از Storage vMotion جا به جا شوند چون کل ماشین مجازی برای آغاز عملیات مهاجرت لازم است. 
Changed Block Tracking (CBT) ×
vSphere Flash Read Cache (vFRC) × نوشتن داده های موجود بر روی کش بر روی داده های قدیمی دیسک می تواند موجب خرابی یا از دست دادن داده شود
vMotion پشتیبانی فقط برای Oracle RAC صورت گرفته است و محدودیت 8 هاست را دارد

محدودیتها

  • هنگام استفاده از حالت multi-writer دیسک مجازی حتما باید در حالت eager zeroed thick باشد و نمی تون از حالت zeroed thick یا thin provisioned استفاده کرد. برای اطلاعات بیشتر به این لینک مراجعه کنید: https://kb.vmware.com/s/article/1033570
  • برای اضافه کردن hot دیسک مجازی باید فلگ رو موقتا بردارید.
  • وقتی در حال استفاده از حالت multi-writer هستید ماشین های مجازی نباید به کنترلرهای NVMe متصل باشند.
  • از vSphere 6.7 Update 1 به بعد ماشین ها با دیسک هایی با ویژگی multi-writer فعال می توانند بیشتر از 8 هاست را پشتیبانی کنند. برای فعالسازی این قابلیت شما باید ویژگی VMFS3/GBLAllowMW را فعال کنید.

VMware vSphere Virtual Volumes

نگرانی های بسیاری درباره استفاده از مجازی سازی برای سرویس پایگاه داده در بیزنس هایی با داده های چند ترابایتی وجود دارد. (مشکلات زیادی همانند تاخیرهای لایه CPU در محاسبه و یا استفاده نادقیق از منابع گزارش داده شده) از جمله موارد زیر:

  • بیزنس هایی با پایگاه داده های حساس و با حجم بالا و قابل افزایش با SLA بالا جهت حفط پرفورمنس
  • پایگاه داده ها با رشد سایز بالا که در طول زمان حجم بک آپ های آنها به سرعت افزایش پیدا می کند
  • محیط هایی که به طور منظم نیاز به گرفتن کلون و رفرش پایگاه داده از محیط عملیاتی به محیط آزمون و یا محیط توسعه دارند. حجم دیتابیس های بالا برای کلون گیری یا رفرش شدن بین محیط های مختلف نیازمند راهکارهای بهینه تر است.
  • پایگاه داده با حساسیت های مختلف نیازمند ذخیره سازهایی با پرفورمنس ها و ویژگی های مختلف هستند.
  • مشکلات در نسخه های قدیمی VMFS دلیل خوبی برای استفاده از RDM بودند ولی اکثر این مشلات رفع شده اند و دیگر وجود ندارند.

یک چلنج بزرگ برای بک آپ از دیتابیس های چند ترابایتی است. همچنین ورود حجم زیادی از دیتا در بازه زمانی کم نیز چالش بزرگی محسوب می گردد. در کل امکان گرفتن بک آپ های full از پایگاه داده های چند ترابایتی در Vmware وجود ندارد.

3 نوع سطح بندی متفاوت برای گرفتن بک آپ از دیتابیس اوراکل در vSphere وجود داره:

  • سطح اپلیکیشن (برای مثال استفاده از RMAN)
  • سطح vSphere (برای مثال استفاده از VMware snapshotها)
  • سطح ذخیره ساز (برای مثال استفاده از اسنپ شات ها در لایه ذخیره ساز، سینک و یا تقسیم دیسک ها و تکنلولوژیهای مشابه در برندهای مختلف سخت افزار)

راه حل های بک آپ مثل ORACLE RMAN و بک آپ از SQLها ارائه شده توسط دیتابیس اوراکل برای بک آپ بهترین سطح گارانتی شده برای گرفتن بک آپ هستند. اما در اغلب موارد سریعترین راه حل را ارئه نمی کنند.

گرفتن snapshot از ماشین مجازی به صورت لحظه ای راه حل بک آپ گیری ایده آل تری شاید باشند اما مشکلاتی را نیز به همراه دارند به عنوان مثال در هنگام پاک کردن یک snapshot از ماشین مجازی با لود کاری بالا امکان متوقف شدن و یا هنگ کردن ماشین مجازی برای مدت طولانی وجود دارد. (http://kb.vmware.com/kb/1002836)

در این لحظه حتی اگر ماشین متوقف نشود این اقدام می تواند تاثیر منفی بر روی پرفورمنس ماشین مجازی بگذارد.

در بین این 3 سطح شاید بتوان گفت snapshotهای گرفته شده توسط لایه ذخیره ساز بی دردسرترین و سریعترین راه حل ممکن هستند اما متاسفانه گرفتن snapshot توسط لایه ذخیره ساز توسط لایه مجازی ساز قابل کنترل نیست بنابراین هیچ جزییاتی از این اقدام در لایه مجازی ساز قابل شناسایی و پیگیری نیست.

یک بک آپ ایده آل از نظر شرکت Vmware برای پایگاه داده های اوراکل (به غیر از بک آپ در سطح اپلیکیشن) با لود کاری بسیار ادغام 3 سطح پشتیبان گیری باهم است برای 2 سطح زیر شرکت VMware راهکار ادغام ارائه داده است:

  • باید بتوان عملیات backup و clone گیری از ماشین را در لایه مجازی ساز ایجاد کرد.
  • باید با سریعترین حالت ممکن snapshotهای فوری برپایه تکنولوژی های ذخیره ساز ایجاد کرد.

تکنولوژی VMware vSphere Virtual Volumes یک تکنولوژی و راه حل شرکت VMware برای این ادغام است.

برای اطلاعات بیشتر به لینک محصول مراجعه کنید:

https://www.vmware.com/products/vsphere/virtual-volumes.html

استفاده از VMware vSAN

vSAN یک راه حل نرم افزاری ذخیره سازی کاملا سازگار برای ایجاد یک زیرساخت ذخیره ساز (SAN) کاملا مجازی است، vSAN یک معماری نرم افزاری کامل برای ارائه زیرساخت مجازی SAN به صورت کامل به جهت استفاده در سرورهای مجازی است. این زیرساخت با گروه بندی دیسک های لوکال ماشین های سخت افزاری ارائه یک زیرساخت کامل را با استفاده از انواع دیسک های SSD به جهت استفاده به عنوان کش خواندن/ نوشتن و انواع دیسک های لوکال را ارائه می کند.

vSAN می تواند فقط از دیسک های SSD یا دیسک های 15k و یا فقط از یک گروه دیسک و یا ترکیبی از آنها به جهت ارائه زیرساخت مجازی SAN استفاده کند.

vSAN از معماری دیسک های چندگانه برای راه اندازی زیرساخت استفاده می کند که به جهت دستیابی به پرفورمنس بالا از دیسک های مبتنی بر فلش باری کش کردن داده و از باقی دیسک ها برای ذخیره سازی پایدار داده استفاده می کند. ادمین ها می توانند ویژگی های ذخیره سازی را همانند ظرفیت، سرعت و در دسترس پذیری را به عنوان یک پالیسی در سطح هر VMDK مشخص نمایند.این پالیسی ها به صورت داینامیک می توانند بهینه شوند بسته به لود سیستم و ماشین مجازی از منابع کمتر یا بیشتری استفاده کنند.

دیتابیس اوراکل به صورت single instance و cluster یا(RAC) می توانند بر روی vSAN راه اندازی شوند. به جهت دسترسی به پرفورمنس مطلوب شرکت VMware توصیه کرده کارشناس storage بر فرآیند راه اندازی این زیرساخت نظارت داشته باشد.

۰۴ مهر ۰۰ ، ۱۱:۰۱ ۰ نظر
مهدی غفاری

VMware در مقابل Oracle - ذخیره سازی - قسمت دوم

تکنولوژی VMware vSphere Flash Read Cache

قابلیت VMware vFRC از VMware VSPhere نسخه 5.5 به ESXi اضافه شد. vFRC یک بخشی از زیرساخت ذخیره ساز هاست ESXi است که برای مدیریت سخت افزارهای ذخیره ساز به شکل flash که به صورت لوکال به سرور اتصال پیدا کرده اند مورد استفاده قرار می گیرد. این سخت افزارها می توانند شامل انواع مختلفی باشند (فلش کارت های قابل اتصال به سرور، انواه هاردهای SSD به شکل SAS و SATA) زیرساخت فلش vSphere به عنوان یک بازوی کمکی از تمام منابع سخت افزاری معرفی شده به عنوان یک منبع واحد در صورت نیاز استفاده می کند در این فرآیند خواندن از دیسک های اصلی به شدت کاهش پیدا می کند.

زیرساخت فلش ساخته شده توسط vSphere برای 2 هدف می تواند استفاده شود:

  • استفاده از کش برای درخواست های IO ماشین های مجازی
  • ذخیره سازی فایلهای SWAP ماشین هاست ESXi

Raw Device Mapping

هایپروایزر Vmware همچنین از RDM پشتیبانی می کند. RDM قابلیت دسترسی ماشین مجازی را به صورت مستقیم به هارد دیسک local و یا دسترسی به LUNهای SAN از طریق فیبر نوری یا iSCSI را ممکن می کند. RDM از طریق ایجاد یک لینک در فایل VMFS به صورت پراکسی دسترسی ماشین را به سخت افزار ممکن می کند. فایلهای مپ ایجاد شده دسترسی به فضاهای ارائه شده توسط سخت افزار را ممکن می کنند.

فایل های مپ دیوایس های خام نیستند اونها در حقیقت ارجاع هایی برای پیکربندی صحیح ماشین مجازی هستند.

پیکربندی RDM به 2 شیوه ممکن است:

Virtual compatibility mode

در این حالت به صورت کامل مجازی سازی در ایجاد مپ بین دستگاه ذخیره ساز و ماشین مجازی پیشتیبانی می گردد، حالت virtual مزایای زیادی رو برای VMFS ها میاره مثل advanced file locking برای data protection و استفاده از snapshotها

Physical compatibility mode

در این حالت شما به اکثر ویژگی های سخت افزار خود به صورت مستقیم دسترسی دارید. Vmkernel تمام دستورات ارسالی سیستم عامل به SCSI را برای سخت افزار ذخیره ساز ارسال می کند که البته همین موضوع می توان تمام اطلاعات لایه سخت افزار ذخیره ساز شما را برای ماشین مجازی مهمان افشا کند.

مقایسه VMFS و RDM

برای تصمیم گیری در مورد این موضوع که فایل های دیتای پایگاه داده شما بر روی VMFS ایجاد شوند و یا بر روی RDM شما نیازی به مقایسه سرعت در محیط خود نیستید.

البته این موضوع خیلی مهم است که شما کدام شیوه دسترسی را برای ارتباط اپلیکیشن خود با سخت افزار خود انتخاب می کنید. انتخاب دسترسی صحیح سرعت و کارایی اپلیکیشن شما را تا حد بالایی در اپلیکیشن های enterprise افزایش می دهد.

این موضوع توسط تست های بسیار توسط Vmware تایید شده است که نتیجه سرعت بر روی VMFS یا همان RDM مجازی با RDM فیزیکی تقریبا در بیشتر حالات عمومی یکسان است:

 دریافت فایل (performance_char_vmfs_rdm)

شرکت Vmware به شدت استفاده از VMFS را توصیه می کند اما ممکن است در حالاتی نیاز به RDM باشد برخی از تفاوت های VMFS و RDM را گردآوری کردیم تا انتخاب مناسبتری برای پروژه خود داشته باشید:

(همچنین برای بحث کاملتر در مورد این موضوع به مستند زیر مراجعه کنید.)

 دریافت (vsphere-esxi-vcenter-server-storage-guide) 

VMFS RDM
هر فضا می تواند میزبان چندین ماشین مجازی باشد (یا به صورت اختصاصی فقط به یک ماشین مجازی اتصال یابد.) مپ کامل فضای هر LUN یا فضا به حداقل یک ماشین مجازی ممکن است 
دارای ابزارهای سیاست گذاری ساده جهت افزایش فضای ذخیره سازی و دارای انعطاف پذیری و مدیریتی بیشتر  به طور معمول همیشه نیازمند LUNهای بیشتر برای افزایش فضا هستید و حداکثر توان بهره برداری از 256 LUN را دارید

به طور کامل از از کلاستر کردن هایی که نیازمند رزرو در iSCSI نیستد پشتیبانی می کند. یکی از موارد عدم پشتیبانی Oracle RAC است. برای پشتیبانی از این حالات باید flag مرتبط multi-writer غیرفعال گردد.
https://kb.vmware.com/s/article/1034165

به شکل مرسوم تکنولوژی RDM جهت پشتیبان گیری های لایه پایین توسط نرم افزارهای خارجی و ابزارهای replication در سطح بلاک نیاز است
پایین بودن سرعت در عملیات multi write توسط چندین ماشین و امکان ایجاد data corruption تکنولوژی RDM جهت مهاجرت آسان یک دیتابیس فیزیکی به ماشین مجازی بسیار کمک کننده است. همچنین در صورت درخواست تیم ساپورت اوراکل به آسانی قابلیت مهاجرت از ماشین مجازی به ماشین فیزیکی وجود دارد.
قابلیت جا به جایی نود ها بین ماشین ها در کلاستر اوراکل قابل استفاده برای Microsoft Cluster Server و Oracle Cluster

۰۴ مهر ۰۰ ، ۰۹:۵۸ ۰ نظر
مهدی غفاری

خطای ORA-65114: space usage in container is too high در datapatch

داشتم PSU با شماره Patch 32904851 - Database Release Update 19.12.0.0.210720 رو اپلای میکردم، بعد از اپلای طبق معمول شروع به زدن datapatch اون کردم که موقع انجام عملیات به یه خطای عجیب برخورد کردم:


Current state of release update SQL patches:
Binary registry:
19.12.0.0.0 Release_Update 210716141810: Installed
PDB PDB3:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.16.581942 PM
PDB APIGWYDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB CDB$ROOT:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.07.436745 PM
PDB DEPLOYDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.18.406588 PM
PDB DFNDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB DSTCHDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB PDB1:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.10.490613 PM
PDB IMENDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.19.319451 PM
PDB OLTPDTNDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB PDB$SEED:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB PDB4:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.13.536972 PM
PDB PDB2:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.13.536972 PM
PDB SHATOOTCORE:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
PDB SVCGWYDB:
Applied 19.10.0.0.0 Release_Update 210108185017 successfully on 31-JAN-21 10.36.17.490873 PM
Adding patches to installation queue and performing prereq checks...done
Installation queue:
For the following PDBs: CDB$ROOT PDB1 PDB2 PDB3 PDB4
No interim patches need to be rolled back
Patch 32904851 (Database Release Update : 19.12.0.0.210720 (32904851)):
Apply from 19.10.0.0.0 Release_Update 210108185017 to 19.12.0.0.0 Release_Update 210716141810
No interim patches need to be applied
For the following PDBs: PDB$SEED DEPLOYDB IMENDB SVCGWYDB APIGWYDB OLTPDTNDB DFNDB DSTCHDB SHATOOTCORE
No interim patches need to be rolled back
Patch 32904851 (Database Release Update : 19.12.0.0.210720 (32904851)):
Apply from 19.10.0.0.0 Release_Update 210108185017 to 19.12.0.0.0 Release_Update 210716141810
No interim patches need to be applied
DBD::Oracle::st execute failed: ORA-65114: space usage in container is too high
ORA-06512: at line 2 (DBD ERROR: OCIStmtExecute) [for Statement "BEGIN
INSERT INTO sys.dba_registry_sqlpatch_ru_info
(patch_id,
patch_uid,
patch_descriptor,
ru_version,
ru_build_description,
ru_build_timestamp,
patch_directory)
VALUES
(:patch_id,
:patch_uid,
:patch_descriptor,
:ru_version,
:ru_build_description,
TO_TIMESTAMP(:ru_build_timestamp, 'YYMMDDHH24MISS'),
:patch_directory);
COMMIT;
END;" with ParamValues: :patch_descriptor=OCIXMLTypePtr=SCALAR(0x27bfd28), :patch_directory='PK........J.▒R..$▒....▒M......32904851_rollback.sql▒.[s.H.@▒▒+x.▒.▒l▒U.M▒▒x.%q.-▒,gfg_T.▒L..@▒VR▒▒▒ .!.▒:.U.▒C
+.8:▒▒▒▒▒e:▒Ц▒▒?▒▒g..▒.▒▒▒&▒▒▒▒T;L▒▒.{Y.
▒2ɴ▒.▒.f.#▒.:▒KӶlK▒▒{=~s<.kQ▒▒
▒▒.3▒W▒▒▒...|8.h▒▒|▒▒.m2▒s▒▒▒▒.▒v▒▒"▒r▒7..▒..▒.'▒O:о}▒.▒)gY.Es▒▒4+^▒i..▒▒▒X▒▒▒x▒=Ϳ▒3/Y▒`-..▒▒
.▒.ϵ.▒.▒.n..<▒.▒▒▒▒▒▒3M▒▒▒(▒^▒▒Ϋ▒.▒▒ū%EyR-
▒▒▒.▒O.,▒S▒_~9x▒▒.▒x▒▒.▒▒▒ѻ▒▒▒CD..▒p▒T▒▒▒/▒s.,_▒.▒{gڳ▒▒▒tz▒|▒#.&'▒▒▒Ë▒▒▒p▒▒▒▒▒▒.▒▒▒▒É▒z߾.▒.▒.▒▒▒w▒▒▒9?;ծ.▒]▒▒▒<x%▒▒?;;▒.▒.▒
▒▒▒▒▒.▒.^.▒T▒...
M.▒▒...,▒f1M..^...▒..▒▒7.▒ʍ^▒.▒▒{▒▒▒o.'▒▒y.▒Էx▒▒.▒2.▒.._.▒▒z▒▒.▒▒.▒.▒.▒.▒▒..▒W▒▒|▒▒▒▒▒.;"..▒▒▒..▒{٫▒.p)K[▒ɭ+A~▒▒▒R..zxr1>..▒tz|6▒
AG.▒▒▒.▒▒▒▒▒▒▒P^_▒▒;▒▒H.▒,▒B▒K▒.▒▒▒▒j13G.▒m▒▒Y*▒▒▒▒Y.▒.gVEu.2z/.▒▒.v▒vrv~▒▒▒X.....O.▒▒W▒n▒5▒▒▒.▒r▒x.a▒|▒
▒o▒=ٻ▒e"▒▒k.▒ir6..▒▒.
▒LQ.▒I&▒▒▒UAZ▒h8▒▒.▒▒.X▒.kh▒:▒i
'ө9▒.▒▒p▒/▒.▒▒..isf
▒▒.N▒Ӿm▒f.▒..▒▒▒-▒..▒▒▒?.▒VF▒O▒▒▒u▒.▒▒.X▒#▒4F▒..▒▒▒u▒v.▒▒6N▒Scd▒..▒..▒.3Mc▒8{.(.▒G▒▒▒▒▒▒H▒;.▒~▒VN.D}▒▒CX▒y..▒.▒8.Q▒▒▒<▒:.▒..`▒▒"1mk(os▒▒c.#▒g g.▒1▒▒.M...', :patch_id='32904851', :patch_uid='24343243', :ru_build_description='Release_Update', :ru_build_timestamp='210716141810', :ru_version='19.12.0.0.0'] at /u01/oracle/product/19c/db_1/sqlpatch/sqlpatch.pm line 5841.

Please refer to MOS Note 1609718.1 and/or the invocation log
/u01/oracle/cfgtoollogs/sqlpatch/sqlpatch_5848_2021_09_20_19_12_46/sqlpatch_invocation.log
for information on how to resolve the above errors.
SQL Patching tool complete on Mon Sep 20 19:13:09 2021

این خطا با دستورات زیر رفع شد:

alter pluggable database PDB1 storage unlimited;
alter pluggable database PDB2 storage unlimited;
alter pluggable database PDB3 storage unlimited;
alter pluggable database PDB4 storage unlimited;

 

۲۹ شهریور ۰۰ ، ۱۹:۳۳ ۰ نظر
مهدی غفاری