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

۹۲ مطلب با کلمه‌ی کلیدی «اوراکل» ثبت شده است

تست 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.

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

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;

 

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

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

راهنمای کلی

جدول زیر توضیحاتی در رابطه با best practices های اعلامی توسط شرکت Vmware برای پایگاه داده اوراکل ارائه می کند:

ردیف

توصیه شده

علت توصیه

1

فعال سازی jumbo frames برای ذخیره ساز های مبتنی بر IP مانند iSCSI یا NFS

فعال سازی Jumbo frame ها بر روی بستر شبکه باعث افزایش ظرفیت بار ترافیک شبکه و بزرگتر شدن هر پکیج می شوند. این ویژگی همیشه برای افزایش پرفورمنس پیشنهاد می گردد.

2

ساخت یک datastore اختصاصی برا سرویس دهی مجزا به پایگاه داده

ایجاد datastore های اختصاصی همانند ایجاد LUNهای اختصاصی برای پایگاه داده در زمان استفاده از تکنولوژی VMFS است. با انجام این کار سرعت IO ورودی و خروجی افزایش خواهد یافت.

3

استفاده از تکنولوژی VMware RDM برای دیتابیس اوراکل

برای استفاده بهتر و بالا بردن سرعت استفاده از تکنولوژی RDM برای دیتابیسها با لود بالا توصیه میگردد.

4

استفاده از تکنولوژی Vmware vSphere VMFS برای دیتابیس اوراکل

برای مدیریت بهتر فضا و استفاده از تکنولوژی های Vmware HA استفاده از VMFS در دیتابیسهای تست و آزمون و با لود پایین توصیه میگردد.

5

تراز بودن سکتورهای VMFS با دیسک های سخت افزاری

مانند تمام فایل سیستم های رایج فایل سیستم VMFS نیز اگر در پارتیشن بندی پارتیشن align دیسک ها نشود می تواند مشکلاتی در ذخیره سازی (تا 40 درصد افت سرعت) و خواندن اطلاعات (تا 25 درصد افت سرعت) برایش رخ دهد. توصیه شرکت Vmware ساخت VMFSها تنها با استفاده از رابط VMware vCenter است تا به صورت خودکار پارتیشنهای ساخته شده align شوند.

6

استفاده از Oracle ASM

تکنولوژی Oracle ASM ادغام فناوری فایل سیستم های کلاستری و مدیریت فضای منطقی برای مدیریت فایلهای دیتابیس اوراکل است. ASM ساده سازی مثال زدنی جهت ذخیره سازی فایل های دیتابیس هنگام اضافه شدن یک سخت افزار جدید ذخیره سازی بدون پایین اومدن سرعت و یا قطعی دارد.

7

هنگام پیکربندی پایگاه داده اوراکل از مستندات فنی و best practice های شرکت سازنده ذخیره ساز استفاده کنید

تکنولوژی Oracle ASM نمی تواند محل مطلوب جهت ذخیره سازی داده ها را بر روی دیسک های خوب در لحظه مشخص کند. پس Oracle ASM جایگزینی برای عدم داشتن مشاور و کارشناس ذخیره سازی متخصص نیست.

8

استفاده از متخصص های ذخیره سازی در طراحی زیرساخت ذخیره سازی پایگاه داده

شما جهت طراحی مطلوب حداقل نیازمند افراد با تخصص های: مدیر پایگاه داده اوراکل، مدیر ذخیره سازی با تخصص بر روی تجهیزات مورد استفاده، مدیر شبکه، مدیر Vmware و مدیر محصول هستید.

9

استفاده از آداپتورهای پاراویرچوالیزیشن SCSI جهت ذخیره سازی دیتافایلهای پایگاه داده اوراکل با لود کاری بالا

این کنترل به صورت پاراویرچوالیزیشن جهت پشتیبانی از لود بالای ذخیره سازی IO و حداقل مصرف پردازش به خصوص برای محیط های دارای SAN طراحی شده است.

مفاهیم ذخیره سازی در VMware

ذخیره سازی مجازی در Vmware  را می توان در 3 لایه خلاصه سازی کرد:

  1. لایه ذخیره ساز که در پایینترین بخش قرار دارد، شامل دیسک های فیزیکی است که به صورت دیسک های منطقی و یا LUNهای جداگانه به لایه بعدی داده شده اند.
  2. لایه بعدی توسط vSphere برای ماشین مجازی تعریف میگردد. LUNهای قابل دسترس برای هاست ESX / ESXi به صورت datastore رزرو شده اند و پارتیشن های ایجادی به صورت فایلهای VMFS در اختیار ماشین مجازی قرار میگیرند.
  3. لایه بعدی پارتیشن های ایجادی در سیستم عامل ماشین مجازی مهمان هستند که بر روی فایلهای VMFS یا به صورت مستقیم بر روی لایه اول قرار دارند.

هایپروایزر شرکت Vmware یا همان VMware ESXi دارای 2 روش ایجاد دسترسی جهت ذخیره سازی بر روی دیسک های Local یا SAN است.

Virtual Machine File System (VMFS)

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

مزیت فایل سیستم کلاستر VMFS پشتیبانی از تکنولوژی های ESXi نظیر vSphere vMotion, DRS و vSphere HA جهت مدیریت حداکثر پایداری ماشینهای مجازی در سطح Host است.

سیاست پیش‌فرض شرکت Vmware استفاده از VMDK به صورت صفر شده thick provisioned lazy zeroed است که در آن بلاک های پدر VMFS با هر بار درخواست write با مقدار 1 مگابایت گرفته می‌شوند.

در اینجا با توجه به درخواست گرفتن فضا بعد از هر درخواست سرویس یک نوع پنالتی جهت جریمه write برای vmdk وجود دارد که می‌تواند بر عملیات‌های پایگاه داده در زمان پیک اثر منفی بگذارد، مثل عملیات‌های write و read که ازtablespace  یا tempdb های موقت استفاده میکنند و یا بارگذاری بالک از جداول و ایندکس ها.

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

روش اول Thin Provisioned

از مزایای ایجاد کردن Thin Provisioned می توان به سرعت بالای ایجاد (Faster Provision) و اشغال فضای دیسک بر اساس بالا رفتن میزان فضای مورد نیاز VM اشاره کرد. در کنار این مزایا ، معایبی نیز به Thin Provisioned وارد است که از جمله آنها می توان به کاهش کارایی VM با توجه به Overhead ای که Metadata ها بر روی VM دارند و همچنین Overhead ای که فرآیند های نوشتن بر روی دیسک برای این ساختار ایجاد می کنند اشاره کرد از طرفی اگر ظرفیت VM شما به اندازه ای بالا برود که از Provision در نظر گرفته بیشتر شود باعث ایجاد Downtime و اشغال زیاد منابع VM خواهد شد.

از همه مهمتر اینکه شما اگر دیسک های مجازی خود را در حالت Thin Provisioned قرار دهید دیگر نمی تواند از امکانات Clustering در ساختار مجازی سازی خود استفاده کنید. زمانیکه VSphere یک دیسک Thin Provisioned ایجاد می کند فقط مقدار کمی Metadata در Datastore ذخیره می کند.

در این حالت هیچگونه فضایی بصورت یکباره از Datastore گرفته نمی شود ، زمانیکه فرآیند نوشتن بر روی دیسک انجام می شود ، VSphere ابتدا اطلاعات مربوط به Metadata ای که مربوط به فایل VMDK است را بروز می کند و در نهایت بلوک های جدیدی از داده را از Datastore دریافت و در آن اطلاعات را می نویسد. این عملیات در محل هایی که فرآیند های نوشتن و خواندن زیادی انجام می شود باعث بالا رفتن Overhead می شود.

Thin Provision ها دارای پایینترین کارایی از نظر سیستم در بین سه حالت و قالب دیسک هایی هستند که در VMware وجود دارد. البته در کنار همین معایب در محیط هایی که محدودیت استفاده از فضا دارند این نوع دیسک بسیار کاربردی است، دیسک های Thin Provisioned قابلیتی دارند که شما می توانید تا زمانیکه فضای واقعی دیسک شما پر نشده است از فضای مجازی موجود بر روی دیسک استفاده کنید.

 

برای مثال شما اگر 10 عدد VM داشته باشید که هر کدام از آنها به 50 گیگابایت فضا نیاز داشته باشند اما فضای Datastore شما تنها 100 گیگابایت باشد شما می توانید هر 10 عدد VM را با ظرفیت 50 گیگابایت ایجاد و راه اندازی کنید. در این حالت به یکباره فضا از Datastore دریافت نمی شود

و به مرور زمان با اضافه شدن حجم داده ها به VM ها تا مرز 100 گیگابایت شما می توانید از همه VM های خود همزمان استفاده کنید. اینکار باعث کاهش هزینه ها می شود ، برعکس Thick Provision که به یکباره با در نظر گرفتن فضا ، همه فضا را به یکباره از Datastore می گیرد.

روش دوم Thick Provision Lazy Zeroed

از مزایای ایجاد کردن Thick Provisioned Lazy Zeroed سرعت بیشتر ایجاد (Faster Provision) نسیت به Thick Provision Eager Zeroed است. این نوع دیسک های مجازی کارایی بهتری نسبت به Thin Provisioned دارند اما به نسبت سرعت ایجاد شدن آنها از Thin Provision کمتر است.

همچنین از دیگر معایب این نوع دیسک های مجازی کارایی و سرعت پایینتر نسبت به Thick Provisioned Eager Zero می باشد ، این نوع دیسک های مجازی همانند Thin Provisioned قابلیت Clustering از نوع FT را پشتیبانی نمی کنند اما کلاسترینگ از نوع HA را پشتیبانی می کنند.

زمانیکه VSphere یک دیسک از این نوع ایجاد می کند ، حداکثر اندازه ای که می تواند به فایل VMDK اختصاص دهد را به یکباره به آن می دهد اما دیگر هیچ کاری انجام نمی دهد. با دسترسی پیدا کردن به هر قسمت از بلاک های دیسک VSphere ابتدا بلاک را آماده و داده ها را در آن می نویسد.

سرعت و کارایی دیسک های مجازی که از نوع Thick Provisioned Lazy Zeroed هستند به دلیل ایجاد کردن Overhead در دیسک ها از Thick Provisioned Eager Zeroed کمتر است. بصورت خلاصه بعد از اینکه دیسک بصورت Lazy Zeroed ایجاد شد فضای متناسب با آن از Datastore گرفته می شود اما فضا پاکسازی نمی شود.

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

پیشنهاد شرکت Vmware جهت راه اندازی پایگاه داده RDBMS اوراکل بر روی هایپروایزر ESXi در صورت استفاده از تکنولوژی VMware vSphere Storage APIs و تمایل به VMFS استفاده از این نوع دیسکThick Provision Lazy Zeroed است.

مزایای VMware vSphere Storage APIs

  • افزایش سرعت کلون گیری با Hardware-accelerated (کلون گیری از بلاک ها به صورت Full Copy/XCOPY)
  • قابلیت مدیریت بهینه سازی لاک ها (این همان Atomic Test and Set [ATS] است)
  • صفر کردن نوشتن بلاک ها همانند صفر کردن فیزیکی دیسک ها
  • قابلیت دوباره گرفتن فضای دیسک ها برای استفاده از بلاک هایی که دیگر نیازی به آنها نیست
  • قابلیت پاک کردن بلاک ها برای استفاده از بلاک هایی که دیگر نیازی به آنها نیست

روش سوم Thick Provisioned Eager Zeroed

در این روش تمام فضای درخواستی با Overwrite شدن با 0 باعث کاهش ریسک های امنیتی بر روی این نوع دیسک های مجازی می شود.

با استفاده از این نوع دیسک شما می توانید از قابلیت های Clustering ای VMware Fault Tolerance استفاده کنید تنهای عیبی که می شود به این نوع دیسک گرفت زمان طولانی تر نسبت به سایر دیسک ها برای ایجاد شدن یا Provision Time بالاتر می باشد.

زمانیکه VSphere یک دیسک از نوع Provisioned Eager Zeroed ایجاد می کند ، حداکثر مقدار فضای ممکن برای دیسک را به یکباره به فایل VMDK اختصاص می دهد سپس تمامی فضاهایی که بر روی دیسک وجود دارند را صفر می کند. برای مثال اگر شما یک فایل VMDK را بصورت Thick Provisioned Eager Zeroed ایجاد کنید و 80 گیگابایت فضا برای آن در نظر بگیرید.

VSphere بلافاصله از دیسک شما 80 گیگابایت می گیرد و به فایل VMDK اختصاص می دهد و تمامی فضای 80 کیگابایت را با صفر پر می کند.زمانیکه تمامی فضاهای خالی با صفر پر شدند، Thick Provisioned Eager Zeroed مطمئن می شوند که در هنگام نوشتن اطلاعات داخل دیسک هیچگونه ریسک امنیتی به وقوع نمی پیوندد. Thick Provisioned Eager Zeroed Disk ها از بهترین کارایی در تمامی فایل های VMDK برخوردارند.

زمانیکه قرار است داده ای بر روی دیسک های Eager Zeroed انجام شود VSphere تنهای کاری که باید بکند نوشتن اطلاعات است و هیچ کار اضافی لازم نیست انجام شود ، همین امر باعث برتری این نوع دیسک نسبت به Thin Provisioned و Lazy Eager شده است.

پیشنهاد شرکت Vmware جهت راه اندازی پایگاه داده RDBMS اوراکل بر روی هایپروایزر ESXi در صورت عدم استفاده از تکنولوژی VMware vSphere Storage APIs و تمایل به VMFS استفاده از این نوع دیسک است.

نکته: در زمان راه اندازی Oracle RAC بر روی VMFS جهت شبیه سازی ذخیره سازی اشتراکی استفاده از Thick Provisioned Eager Zeroed الزامی است.

http://kb.vmware.com/kb/1034165

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

VMware در مقابل Oracle - پیروز میدان کیست؟

بحث نصب دیتابیس اوراکل بر روی VMware ESXi همیشه یکی از اون مواردی هستش که پیروزی در سازمان ها نداره! یکبار میخوام این بحث رو به صورت کاملا فنی و تکنیکی باز کنم تا باهم بیشتر به مزایا و معایب ماشین های مجازی اشراف داشته باشیم و بتونیم مثل هر تکنولوژی خوب دیگه ای در نرم افزار از دیدگاه فنی این موضوع رو بلد باشیم و بدون تعصب به مسیر خوبمون جهت ارائه سرویس هایی با کیفیت بالا و حداکثر پایداری ادامه بدیم.

 

VMware در مقابل Oracle - مقدمه

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

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

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

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

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

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

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

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

انتقال DATAPUMP با استفاده از DBLINK

یکی از روش های رایج برای انتقال اسکیما استفاده از Datapump اوراکل هستش. به طور معمول شما باید از سرور مبدا یک فایل Datapump تهیه کنید و با ابزارهایی مثل SCP اون رو به سرور مقصد انتقال بدید و سپس اقدام به IMPORT اون کنید.

یک روش ساده دیگه برای انجام این کار استفاده از TNS در سرور مقصد هستش به این ترتیب که شما اول یک DBLINK در سرور مبدا (در CDB و یا اون PDB) ایجاد میکنید بعد یک EXPORT با دی بی لینک بر روی سرور مقصد میگیرید که این عمل باعث این میشه که فایل شما روی سرور مقصد ایجاد بشه بعد اقدام به IMPORT فایل می کنید.

CREATE PUBLIC DATABASE LINK DBT_LINK
CONNECT TO system IDENTIFIED BY dba1
USING '<TNS_Origin>'

expdp system@<TNS_DEST> directory=DATA_PUMP_DIR LOGFILE=MyExpdp.log network_link=DBT_LINK schemas=MyRemoteDBSchema1,MyRemoteDBSchema2
impdp system@<TNS_DEST> directory=DATA_PUMP_DIR LOGFILE=MyImpdp.log schemas=MyRemoteDBSchema1,MyRemoteDBSchema2

http://www.oracle-wiki.net/startdocshowtousedatapumpoveradatabaselink

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

ایمیج های از پیش ساخه شده Oracle در Virtualbox

اوراکل یکسری ایمیج‌های از پیش ساخته شده برای virtualbox در دسترس developerها قرار داده که می‌تونید از طریق لینک‌های زیر به اونها دسترسی داشته باشید:

 

  

https://www.oracle.com/downloads/developer-vm/community-downloads.html

https://www.oracle.com/middleware/technologies/obiee-samples-downloads.html

https://www.oracle.com/middleware/technologies/obiee-samples-v506-downloads.html

۱۶ آبان ۹۹ ، ۱۷:۰۹ ۰ نظر
مهدی غفاری

نصب و راه‌اندازی اوراکل 20C بر روی Oracle Linux 7

امروز میخوایم نصب و راه‌اندازی اوراکل 20C (نسخه پیش‌نمایش سازمانی) بر روی اوراکل لینوکس ۷ رو جهت آزمایش نحوه نصب با هم انجام بدیم.

نسخه سیستم‌عامل محیط تست من Oracle Linux 7.5 و دیتابیس من LINUX.X64_200000_db_home نسخه پیش‌نمایش هستش

منابعی که من برای این نصب در نظر گرفتم با توجه به نوع نصب ۱۰۰ گیگ دیسک مجازی و ۸ گیگ رم بر روی پلتفرم VMware Workstation هستش

نصب لینوکس به صورت مینیمال انجام میشه (اگر در محیطهای عملیاتی قرار دارید پیشنهاد میشه نصب سیستم‌عامل توسط تیم پشتیبانی سیستم‌عامل صورت بگیره)

بعد از نصب سیستم‌عامل مراحل زیر را دنبال کنید

ویرایش فایل هاست

فایل /etc/hosts رو با توجه به محیط خودتون درست کنید:

[root@localhost ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
192.168.56.107 localhost localhost.localdomain

و همچنین فایل /etc/hostname:

[root@localhost ~]# cat /etc/hostname
localhost.localdomain

نصب اتوماتیک

من برای نصب از پکیج oracle-database-preinstall-19c به دلیل اینکه هنوز پکیج 20C در دسترس قرار نگرفته استفاده میکنم. نکته خوبی که در اینجا باید بهش اشاره کنم اینه که دیگه شما وابسه به سیستم‌عامل اوراکل لینوکس برای نصب این پکیج نیستید و می‌تونید این پکیج رو به شکل مستقیم از لینک زیر دانلود کنید و به راحتی اون رو روی ردهت/ سنت او اس نصب کنید تا کارهای مقدماتی برای نصب اوراکل انجام بشه:

# yum install -y https://yum.oracle.com/repo/OracleLinux/OL7/latest/x86_64/getPackage/oracle-database-preinstall-19c-1.0-1.el7.x86_64.rpm

با توجه به اینکه این پکیج خیلی از تنظیمات مورد نیاز رو به شکل نسبتا مناسبی انجام میده من برای این نصب نیازی به تغییر این پیکربندی‌ها نمی‌بینم ولی اگه شما در یک محیط عملیاتی حساس هستید حتما جهت مشاوره با من تماس بگیرید تا بهترین راهنمایی در محیط خود را داشته باشید.

کارهای تکمیلی

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

 

تغییر پسورد کاربر اوراکل

passwd oracle

تغییر حالت selinux

cat /etc/selinux/config
SELINUX=permissive
# setenforce Permissive

غیرفعال کردن فایروال

# systemctl stop firewalld
# systemctl disable firewalld

ساخت دایرکتوری‌های مورد نیاز

mkdir -p /u01/app/oracle/product/20.0.0/dbhome_1
mkdir -p /u02/oradata
chown -R oracle:oinstall /u01 /u02
chmod -R 775 /u01 /u02

تنظیم بش پروفایل کاربر اوراکل

mkdir /home/oracle/scripts
[oracle@localhost ~]$ cat /home/oracle/scripts/setEnv.sh
# Oracle Settings
export TMP=/tmp
export TMPDIR=$TMP
export ORACLE_HOSTNAME=localhost.localdomain
export ORACLE_UNQNAME=cdb1
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/20.0.0/dbhome_1
export ORA_INVENTORY=/u01/app/oraInventory
export ORACLE_SID=cdb1
export PDB_NAME=pdb1
export DATA_DIR=/u02/oradata
export PATH=/usr/sbin:/usr/local/bin:$PATH
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
export CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib
cat .bash_profile
# Oracle Settings
#. /home/oracle/scripts/setEnv.sh

ایجاد اسکریپت برای روشن و خاموش کردن صحیح دیتابیس

cat > /home/oracle/scripts/start_all.sh <<EOF
#!/bin/bash
. /home/oracle/scripts/setEnv.sh

export ORAENV_ASK=NO
. oraenv
export ORAENV_ASK=YES

dbstart \$ORACLE_HOME
EOF


cat > /home/oracle/scripts/stop_all.sh <<EOF
#!/bin/bash
. /home/oracle/scripts/setEnv.sh

export ORAENV_ASK=NO
. oraenv
export ORAENV_ASK=YES

dbshut \$ORACLE_HOME
EOF

chown -R oracle:oinstall /home/oracle/scripts
chmod u+x /home/oracle/scripts/*.sh

شروع نصب

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

به فولدر ORACLE_HOME تغییر جهت میدیم و نصاب رو اجرا میکنیم

[oracle@localhost ~]$ cd $ORACLE_HOME
[oracle@localhost ~]$ unzip -oq /home/oracle/LINUX.X64_200000_db_home.zip

مرحله اول

تو این مرحله گزینه set up software only رو انتخاب میکنیم.

نکته بسیار جالب داستان اینجاست که چون ما در حال نصب نسخه preview هستیم صفحه مربوط به وارد کردن ایمیل پشتیبانی ظاهر نمیگردد.

مرحله دوم

در این مرحله گزینه اول که مرتبط با نصب یک single instance هست رو انتخاب می‌کنیم:

مرحله سوم

من چون در حال برنامه تست فیچرهای EE هستم نسخه EE رو انتخاب می‌کنم:

مرحله چهارم تا آخر

حالا اسکریپتهای داده شده رو با کاربر root اجرا می‌کنیم:

اتمام نصب نرم‌افزار

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

پیش نمایشی از نسخه 20C دیتابیس اوراکل

اگه در جریان خبرهای دنیای اوراکل باشید قطعا از در راه بودن نسخه 20C دیتابیس اوراکل اطلاعات کافی دارید یکی از نسخه هایی که با ایده‌های جدید و نوآورانه وارد کار شده و مثل همیشه در دنیای دیتابیس ها یکه تازی می‌کنه.

از اوراکل 12C ورژن 12.1.0.2 کمپانی اعلام کرد معماری non-CDB در حال منسوخ شدن (deprecated) است و در نسخه 20C دیگر ما شاهد معماری non-CDB نیستیم، این یعنی نسخه 19C آخرین نسخه با معماری non-CDB است. توصیه من به همه سایت‌های اوراکلی در داخل و خارج این هستش که برای کمتر سوپرایز شدن در اسرع وقت از معماری CDB استفاده کنند. نکته خوب ماجرا اینه که از نسخه 19C شما می تونید بدون پرداخت هزینه لایسنس Multitenant به این ویژگی با محدودیت حداکثر ۳ pdb دسترسی داشته باشید.

همونطور که می‌دونید یکی از نسخه‌ها که با پشتیبانی بلند مدت (long term support) انتشار یافته است نسخه 19C تا انتهای سال ۲۰۲۶ است و البته مشخص نیست نسخه بعدی با پشتیبانی بلند مدت (long term support) کدوم نسخه و در چه زمانی است.

حالا نسخه 20C دیتابیس اوراکل مدتی هست اومده ولی در حال حاضر در دسترس عموم قرار نگرفته، تاریخ عرضه نسخه 20C جهت دسترسی عموم هنوز به شکل دقیق مشخص نشده ولی گفته شده در یکی از ماه‌های سال ۲۰۲۰ این نسخه انتشار پیدا میکنه. نسخه فعلی در مرحله preview قرار داره و به صورت محدود در اختیار تست قرار گرفته است و ابداً برای محیط عملیاتی قابل استفاده نیست.

نقل قول از تیم اوراکل:

Oracle Database 20c is available only for preview. It is not available for production use. Upgrades to or from Oracle Database 20c are not supported.

جهت تست نسخه‌ای برای من (برای پلتفرم لینوکس) ارسال شده در این مطلب می‌خواهیم با هم به ویژگی‌های جدید این نسخه سری بزنیم (نسخه ای که برای بنده ارسال شده فاقد نرم افزار grid است.)

همیشه بهترین منبع یادگیری سایت رسمی اوراکل هستش پس ازش غفلت نکنید:

https://docs.oracle.com/en/database/oracle/oracle-database/20/index.html

برای اینکه ببینیم چه ویژگی‌هایی در این نسخه پشتیبانی شده یا پشتیبانی اون‌ها تموم شده باید سری به لینک زیر بزنید:

https://apex.oracle.com/database-features

ویژگی‌های جدید این نسخه موراد بسیار زیادی هستش که می‌تونید همه اونها رو در مستند زیر مطالعه کنید به این علت که من باید تمام این ویژگی‌ها رو  در یک بازه زمانی کوتاه تست کنم شاید نتونم تمام این ویژگی‌ها رو مستند کنم البته تمام سعی‌ام رو میکنم مهمترین مواردشون رو در این ویلاگ مستند کنم.

دریافت
حجم: 1.21 مگابایت

 

به نظر من چندتا از این ویژگی‌های جذاب میتونه موارد زیر باشه:

Oracle Database Utilities

-- Oracle Data Pump Includes and Excludes in the Same Operation

-- Oracle Data Pump Parallelizes Transportable Tablespace Metadata Operations

-- Oracle Data Pump Provides Optional Index Compression

-- Oracle SQL*Loader Supports Native JSON Data Type

Oracle Multitenant

-- MAX_IDLE_BLOCKER_TIME Parameter

-- Expanded Syntax for PDB Application Synchronization

Security Solutions

-- SYSLOG Destination for Common Unified Audit Policies

-- Unified Audit Policies Enforced on the Current User

-- Auditing for Oracle XML DB HTTP and FTP Services

-- Oracle Blockchain Table

Oracle Advanced Security

-- Ability to Set the Default Tablespace Encryption Algorithm

-- Enhanced Database Availability with Zero Downtime to Switch Over to an Updated PKCS#11 Library

SQL

-- SQL Macros

-- Expression Support for Initialization Parameters

-- Enhanced SQL Set Operators

Upgrades and Migration

-- Oracle Database Automates Database Upgrades with AutoUpgrade

 

برای آپگرید به این نسخه هنوز طرحی از طرف اوراکل ارائه نشده اما پیشنهاد میکنم آپگرید مستقیم به نسخه 19C رو تا فرصت از پیش نرفته از دست ندید.

 

اگه با توجه به جدول بالا در حال حاضر قادر به ارتقای مستقیم نیستید حتما در مرحله اول patch کنید و یا از روشهای زیر استفاده کنید:

-- از طریق دستورات dbupgrade یا دستور جدید autoupgrade یا ویزارد DBUA

-- انتقال TBSها از طریق ویژگی full transportable یا traditional TTS

-- استفاده از DataPump و انتقال فایل با شبکه یا از طریق db link

 

خب اگه برای آپگرید آماده‌اید و در محیط‌های پیچیده که نیازمند دقت و دانش بالا جهت آپگرید بی دردسر است قرار دارید تیم ما میتونه به عنوان مشاور در کنار شما باشه. ما می‌تونیم:

 

-- آپگرید ۱ تا ۱۰۰ دیتابیس رو به شکل همزمان از A تا Z بدون مشکل انجام بدیم.

-- ما می‌تونیم طرح آپگرید رو برای شما آماده کنیم و فیچرهای جدیدی که می‌تونید در سایت خود داشته باشید رو بهتون اعلام کنیم.

-- اگه تو مراحل آپگرید نیاز به یک دیتابیس گارد فوری دارید روی ما حساب کنید.

-- انجام انواع سناریو PATH و حل تمام مشکلات ORA-600 سایت شما رو انجام بدیم.

 

 

شاد و پیروز باشید

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

طولانی شدن زمان های GC CR MULTIBLOCK REQUEST

ما یک RAC سه نود رو نگهداری می‌کنیم. به طور معمول کوئری‌های سنگین ما از نظر زمان اجرا خیلی باهم متفاوت هستند. به این علت که حجم دیتای بیزنس ما زیاد و دارای نوسان زیادی است در دیتای ما واریانسهای طبیعی زیادی وجود داره. با این حال خیلی از بلاکهای این نوسانها تا حدی توی حافظه RAC قرار دارند.

من یکسری تست‌ها انجام دادم که یه رخدادی رو به من نشون میده که میتونم اون رو به عنوان یک مشکل غیر منتظره در وبلاگم ثبت کنم.

تسک ما اجرای یک کوئری با چندین join هستش که باعث ایجاد هش جویان های زیادی در سیستم میشه

مشکل ما این بود که تاخیرهای مرتبط با گرفتن دیتا با Full Table Scan از روی دیسک کمتر از گرفتن دیتا از روی شبکه interconnect بود. در حقیقت به این معنی که همه بلوک ها روی node ای قرار می‌گیرند که از همه دورتر است پس wait های GC CR MULTIBLOCK REQUEST به مقدار زیادی بالا بودند.

میانگین waitهای scattered-read من به طور معمول ۸ میلی ثانیه و میانگین waitهای GC CR MULTIBLOCK REQUEST به طور معمول ۲۱ میلی ثانیه بود.

اگر هرکدام از جدول ها توسط یک کوئری از قبل فراخوانی شده بودند، یا کوئری‌های مشابه در همان روز از دیتابیس گرفته شده باشد و در نتیجه اوراکل محتوای جدول را در نود far-side (دورترین نود - نود ۳) قرار داده باشه اونوقت hash joinهای ما ۴۵ دقیقه طول میکشه و توسط wait ما (GC CR MULTIBLOCK REQUEST) محاصره میشه 

حالا اگه هر نود ما alter system flush buffer cache رو اجرا کنه که در نتیجه اتفاق خواندن از دیسک انجام میشه اونوقت همون کوئری وقتی دوباره اجرا بشه ۵ دقیقه طول میکشه و ایندفعه توسط wait ای به نام scattered/sequential read محاصره میشه

خواننده گرامی قبل از ادامه کار شما باید با Cache Fusion در RAC و مفاهیم Past Image و انواع Waitها در RAC آشنایی داشته باشید. سعی میکنم در مقاله ‌های بعدی به این موضوعات بپردازم.

وقتی اوراکل بلوک های درخواست شده رو از نود دور (far-side) به نود نزدیک (near-side) منتقل میکنه با فرض اینکه همه چیز به شکل صحیح پیکربندی شده باشه کلاستر اوراکل از شبکه private استفاده میکنه.

حقیقتاً به نظر من ۲۱ میلی ثانیه خیلی طولانی میاد بیشتر سیستم هایی که من دیدیم یا درباره اونها تحقیق کرده ام خوندن اطلاعاتشون بین ۸ تا ۱۰ میلی ثانیه طول میکشه در کل خوندن بلاک از interconnect باید کمتر از چند میلی ثانیه طول بکشه به عنوان یک اصل کلی این عدد برای سلامت RAC اوراکل بیش از حد مهم و بالاست هستش.

سوالی که برای من پیش میاد اینه که تحت چه شرایطی ممکنه wait یک کوئری با GC CR MULTIBLOCK REQUEST بیشتر از waitهای scattered-read باشه؟ (به عبارت دیگه چرا ممکنه انتقال بلوکها از طریق interconnect بیشتر از انتقال از طریق disk طول بکشه؟)

خب در جواب سوال باید بگم مقایسه بین انتقال اطلاعات در CR global cache بین نودها با خواندن از روی دیسک مثل مقایسه هویج و بادمجون ه.

یادمون باشه تحت خیلی از شرایط ممکنه این مشکل پیش بیاد اول از همه اینکه پیکربندی شبکه برای private امون چیه؟ آیا از اترنت گیگابیت استفاده میکنیم؟ (در کل بهتره از یک شبکه 10G یا Infiniband استفاده کنیم). آیا این شبکه private واقعا private ه یا شخص دیگه ای هم توی شبکه است؟ (در صورت شلوغی این شبکه خود این شبکه ممکنه باعث این چنین مشکلاتی بشه)

اوراکل توصیه میکنه حتما از jumbo frame برای این شبکه استفاده بشه خب با پیگیری های فراوان قبلاً در شبکه ما jumbo frame پیکربندی شده بود و این رخداد به تازگی و بدون تغییر در بیزنس اپلیکیشن رخ داده بود.

خب در ادامه باید بگم اوراکل در انتقال CR Global Cache یک read image واحد درخواست میکنه اونم به خاطر این که یک تراکنش ممکنه یک تغییری در بلوکی که در instance دیگه  وجود داره ایجاد کنه پس ما نیاز به خوندن یک ایمیج واحد داریم

ایمیج برداشته شده از روی دیسک در صورتی که هنوز commit نشده باشه همچنان نیاز داره که با session درخواستی به دیتابیس هماهنگ بشه پس تغییراتی که هنوز commit نشدند باید قبل از اینکه session بتونه ازشون استفاده بکنه rollback بشوند.

در غیر این صورت  ایمیج برداشته شده از روی دیسک یک بلوک current هستش که در این مورد ایمیج همونطور که هست و بوده در اون instance استفاده میشه و در مقیاسه با به دست آوردن ایمیج CR کار کمتری مورد نیازش هست و بار کمتری ایجاد میکنه (چون ایمیج CR باید به صورت منسجم از نودها فراخوانی بشه)

با تمام این توضیحات مشکل رو یا باید در شبکه جستجو میکردم یا در پیکربندی‌های اخیر - با این توضیح که قبلاً چنین مشکلی وجود نداشت و تست‌های انجام شده بر روی شبکه مشکلی رو نشون نمیداد سراغ پارامتر UNDO_RETENTION رفتم

یک توضیحی باید بدم که من برای گرفتن export از یکی از جداولمون که سایز بسیار زیادی داره (بیش از ۳ ترابایت) این پارامتر رو روی ۷ روز تنظیم کرده بودم

خب وقتی به یاد این پارامتر افتادم فهمیدم مشکل کجاست چون همین پارامتر قطعاً در رفتار کلاستر تفاوت ایجاد میکنه - مقدار من برابر ۷ روز بود پس دیتاها توی اینتنس ۱ لود شده و برای مدت طولانی در آینده گرفته میشوند اگه یک کوئری توی اینستنس ۲ اجرا بشه اوراکل ممکنه تصمیم بگیره که نیاز به یک read image منسجم داره ... خب همونطور که میدونید بازسازی مجدد بلاک مقداری زمان میبره به ویژه اگه حجم عظیمی از تغییرات در undo وجود داشته باشند چیزی که گیج کننده بود اینه که تراکنشی که تغییر رو ایجاد کرده باید تا الان وضعیت اش مشخص شده باشه پس به جای بلوک CR باید یک بلوک current درخواست میکرد ولی از اونجایی که بلوک CR به دفعات درخواست شده بود این موضوع نشون میده که تغییرات جداول مرتبط هنوز commit نشده بودند.

در نهایت با پایین آوردن مقدار این پارامتر به عدد دیفالت (۹۰۰) یا همون ۱۵ دقیقه این مشکل رو حل کردم.

۱۷ شهریور ۹۹ ، ۱۹:۵۴ ۲ نظر
مهدی غفاری