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

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

قابلیت 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

۲۰ ارديبهشت ۰۱ ، ۰۹:۵۰ ۰ نظر
مهدی غفاری

فعال سازی Fix Controlها

Fix Control ها باگ های رفع شده Optimizer میباشند که به صورت پیشفرض غیرفعال میباشند . دلیل غیر فعال بودن Fix Control ها این است که با تغییر تنظیمات مربوط به Optimizer امکان تغییر Plan دستورات SQL وجود دارد و Plan جدید ممکن است باعث بدتر شدن Performance گردد . با توجه به نیاز دیتابیس ها برای اعمال Patch set به صورت دوره ای پیشنهاد میگردد برای ثابت کردن Plan دستورات SQL ، از SQL Plan Management استفاده گردد .

نمایش Fix Control های موجود (خروجی به صورت خلاصه نمایش داده شده است .)

SET SERVEROUTPUT ON;
EXECUTE DBMS_OPTIM_BUNDLE.GETBUGSFORBUNDLE;
19.12.0.0.210720DBRU:
    Bug: 31459242,  fix_controls: 31459242
    Bug: 31082719,  fix_controls: 31082719
    Bug: 28708585,  fix_controls: 28708585
    Bug: 31821701,  fix_controls: 31821701
    Bug: 32107621,  fix_controls: 32107621
    Bug: 26758837,  fix_controls: 26758837
    Bug: 31558194,  fix_controls: 31558194
    Bug: 30781970,  fix_controls: 30781970
    Bug: 30142527,  fix_controls: 30142527
    Bug: 31143146,  fix_controls: 31143146
    Bug: 31961578,  fix_controls: 31961578
    Bug: 31496840,  fix_controls: 31496840
    Bug: 22387320,  fix_controls: 22387320
     ….
PL/SQL procedure successfully completed.

ادامه مطلب...
۲۰ ارديبهشت ۰۱ ، ۰۹:۳۴ ۰ نظر
مهدی غفاری

رفع خطای ORA-15124: ASM file name contains an invalid alias name در RMAN HOTCLONE

در ادامه عملیات داستان های واقعی: کلون گیری باگ دار بودم که در دیتابیس مقصد با خطای ORA-15124: ASM file name contains an invalid alias name مواجه شدم.


RMAN-08018: channel ORA_AUX_DISK_1: starting archived log restore to user-specified destination
RMAN-08508: archived log destination=+FRA
RMAN-08169: channel ORA_AUX_DISK_1: using network backup set from service CDB1
RMAN-08022: channel ORA_AUX_DISK_1: restoring archived log
RMAN-08510: archived log thread=1 sequence=8645
RMAN-08180: channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
RMAN-03091: Finished restore at 12-APR-22
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate PDB command at 04/12/2022 19:32:47
RMAN-05501: aborting duplication of target database
RMAN-06136: Oracle error from auxiliary database: ORA-15124: ASM file name '+DATA/FMSDB/B6E05B19F9FE428FE05301A4A8C02926/DATAFILE/cl_ezpdo1_mf_temp2_%u_.tmp' contains an invalid alias name

برای اینکه بفهمیم در دیتابیس اصلی چه دیتافایلهایی وجود دارد میتونیم از rman استفاده کنیم و مسیر فایلها رو ببینیم:

$rman target / log=srdc_rman_output_<date>.log
RMAN> set echo on;
RMAN> report schema;
RMAN> exit;

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

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

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