قابلیت Gradual Database Password Rollover

برای تغییر پسوردها شما میتوانید از قابلیت جدیدی که در نسخه 19.12 به بعد معرفی شده است (Gradual Database Password Rollover) استفاده کنید . در این روش امکان استفاده همزمان از رمز عبور قبلی و رمز عبور جدید برای مدت زمان مشخصی که در پروفایل آن کاربر تعریف میشود وجود دارد . در این فاصله زمانی میتوان نسبت به تعویض رمز عبور کاربر در پایگاه داده و بر روی تنظیمات برنامه اقدام نمود. پس از سپری شدن زمان مقرر شده امکان استفاده از رمز عبور قبلی وجود نخواهد داشت .

ابتدا پارامتر PASSWORD_ROLLOVER_TIME را در پروفایل کاربر تنظیم میکنیم . کمترین میزان برای پارامتر PASSWORD_ROLLOVER_TIME یک ساعت و بیشترین مقدار 60 روز میباشد . در این مثال مدت زمان یک ساعت در نظر گرفته شده است .

ALTER PROFILE USER_PROFILE LIMIT PASSWORD_ROLLOVER_TIME 1/24;

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

این پارامتر می تواند حداقل مقدار 1 ساعت (1/24) و حداکثر 60 روز را داشته باشد.

پسورد کاربر مورد نظر را تغییر داده .

ALTER USER USERSERVICES IDENTIFIED BY NEW_PASSWORD;

در این مرحله نسبت به تغییر پسورد در فایل های مربوط به تنظیمات برنامه اقدام کنید .
پس از تغییرات در تنظیمات برنامه در صورتی که مدت زمان پارامتر PASSWORD_ROLLOVER_TIME به اتمام رسیده باشد امکان استفاده از رمز عبور قبلی وجود ندارد . همچنین با استفاده از دستور زیر میتوان زودتر از موعد مقرر شده Policy تنظیم شده را منقضی نمود .

ALTER USER USERSERVICES EXPIRE PASSWORD ROLLOVER PERIOD;

جهت غیر فعال کردن این قابلیت کافیه مقدار پارامتر را به 0 تغییر داد.

ALTER PROFILE USER_PROFILE LIMIT PASSWORD_ROLLOVER_TIME 0;

تغییر UNDO_RETENTION در PDB

از نسخه  19.9  به بعد تغییر برخی از پارامتر ها (در اینجا پارامتر مورد نظر UNDO_RETENTION  میباشد ) در Container Root (CDB$ROOT)  منجر  به تغییر آن پارامتر در بقیه PDB ها نمیشود  . از نسخه 12.2.0.1 به صورت پیش فرض هر PDB  دارای UNDO_TBS  مخصوص به خود میباشد (منظور local undo only  که تنظیم پیش فرض به هنگام ساخت یک PDB  جدید است ) از این رو هر PDB تنظیم UNDO  مخصوص به خود را دارد. برای تغییر پارامتر UNDO_RETENTION در تمامی Instance از دستور زیر استفاده کنید .

ALTER SYSTEM SET UNDO_RETENTION=10 CONTAINER=ALL SCOPE=BOTH;

دستور بالا در محیط دیتاگارد به دلیل Read-Only  بودن PDB با خطا مواجه میگردد . در محیط دیتاگارد از دستور زیر استفاده میگردد .

ALTER SESSION SET CONTAINER=CDB$ROOT;
ALTER SYSTEM SET UNDO_RETENTION=10 SCOPE=BOTH;
ALTER SESSION SET CONTAINER=SHATOOTPDB;
ALTER SYSTEM SET UNDO_RETENTION=10 SCOPE=BOTH;

لازم به ذکر است که هنگام تغییر پارامتر های داخل PDB   اگر از SCOPE=SPFILE  و یا SCOPE=BOTH  استفاده شود ، آن تغییر  در Data Dictionary  های PDB  و فایل تعریف XML  آن PDB ذخیره میشود  و بر روی SPFILE  تغییری ایجاد نمیکند . برای مشاهده پارامتر های تغییر یافته داخل PDB   از کوئری زیر استفاده شود .

SELECT PS.DB_UNIQ_NAME , PS.PDB_UID , P.NAME AS PDB_NAME , PS.NAME , PS.VALUE$ 
FROM PDB_SPFILE$ PS JOIN V$PDBS P ON PS.PDB_UID = P.CON_UID;

لیست پارامتر ها با شرایط توضیح داده شده در این بخش (طبیعتا با اعمال هر Patch set  امکان تغییر این لیست وجود دارد )

_ROLLBACK_SEGMENT_COUNT
_SMU_TIMEOUTES
_SMU_DEBUG_MODE
_UNDO_DEBUG_MODE
_HIGHTHRESHOLD_UNDORETENTION
_UNDO_AUTOTUNE
UNDO_RETENTION
_COLLECT_TEMPUNDO_STATS

تست 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 اجرا می‌کنیم:

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