پیش نمایشی از نسخه 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 نشده بودند.

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

خطای ORA-39232: invalid remap function: C

مدتی میگذره که از من درخواست کرده بودند دیتای برخی جداول رو Mask کنم. تو بین سولوشن‌های اوراکل ۲ تا سولوشن نظر من رو به خودش جلب کرد.

سولوشن اول

استفاده از OEM

توجه کنید شما برای استفاده از این سولوشن نیازمند تهیه لایسنس OEM به صورت جداگانه هستید. توی داکیومنتی که در پایین اشاره کردم اوراکل به صورت کامل این قابلیت OEM رو به همراه مثال توضیح داده همچنین شما می‌تونید از بخش subsetting گذر کنید.

https://docs.oracle.com/database/121/DMKSB/intro.htm#DMKSB-GUID-24B241AF-F77F-46ED-BEAE-3919BF1BBD80

سولوشن دوم

اسفاده از پارامتر کامندی REMAP_DATA در Oracle Data Pump

توی این مطلب به سولوشن دوم می‌پردازیم.

این ویژگی در کامند expdp به شما این امکان رو میده که یک remap فانکشن رو مشخص کنید که مقدار اصلی ستون تهیه شده رو به عنوان منبع ورودی فانکشن در نظر بگیره و مقدار remap شده از فانکشن رو باز گردونه و در فایل dump جایگذاری بکنه. یکی از استفاده‌های رایج از این ویژگی Mask کردن دیتا برای جا به جایی دیتا از یک سیستم عملیاتی به یک محیط توسعه است.

قدم اول ساخت remap فانکشن

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

نکته: این فانکشن برای ۴ دیتا تایپ VARCHAR2, NUMBER, FLOAT, BLOB با در نظر گرفتن حروف فارسی نوشته شده. همچنین در دیتاتایپ BLOB صرفاً عملیات پاک سازی دیتا انجام میشه

https://gist.github.com/mghaffari94/53583fcbac03df98c8cb3bca24263e61

CREATE OR REPLACE PACKAGE C##MAHDI_GH.OBFUSCATING IS
     FUNCTION VAR(R IN VARCHAR2) RETURN VARCHAR2;
     FUNCTION NUM(R IN NUMBER) RETURN NUMBER;
     FUNCTION FLO(R IN FLOAT) RETURN FLOAT;
     FUNCTION CLEAR_BLOB(col blob) RETURN BLOB;
  END;
/
=======================================================
CREATE OR REPLACE PACKAGE BODY C##MAHDI_GH.OBFUSCATING
IS
    FUNCTION VAR (R IN VARCHAR2)
        RETURN VARCHAR2
    AS
    BEGIN
        RETURN (TRANSLATE (
                    R,
                    'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890!@#$%^&*()_+-=\/ابپتثجچحخدذرزژسشصضطظعغفقکگلمنوهی',
                    'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxضصثیسشبلفغاریبلفثقهتلیاستیذزلیفثهس'));
    END;


    FUNCTION NUM (R IN NUMBER)
        RETURN NUMBER
    AS
        S   NUMBER;
    BEGIN
        S := R * 2 / 1 + 10;

        RETURN (S);
    END;

    FUNCTION FLO (R IN FLOAT)
        RETURN FLOAT
    AS
        S   FLOAT;
    BEGIN
        S := R * 2 / 1 + 10;

        RETURN (S);
    END;

    FUNCTION CLEAR_BLOB (col IN BLOB)
        RETURN BLOB
    AS
        b1   BLOB := EMPTY_BLOB ();
    BEGIN
        RETURN b1;
    END clear_blob;
END;
/

قدم دوم

طبق داکیومنت اوراکل توی مرحله دوم باید به شکل زیر از این فانکشن‌ها برای remap دیتا استفاده کنید:

https://docs.oracle.com/database/121/SUTIL/GUID-B1D13216-93D3-4FFC-A0BB-082E133FD2B9.htm#SUTIL861

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sutil/oracle-data-pump-export-utility.html#GUID-B1D13216-93D3-4FFC-A0BB-082E133FD2B9

REMAP_DATA=[schema.]tablename.column_name:[schema.]pkg.function

یک مثال طبق داکیومنت به این شکل هستش:

REMAP_DATA=HB.USER.FIRST_NAME:C##HB.OBFUSCATING.VAR

حالا شما می‌تونید از این پارامتر در ابزار expdp به شکلی که نیاز دارید استفاده کنید. ۲ روش کلی برای استفاده از پارامترها در expdp وجود داره.

روش اول

به شکل ۱ دستور واحد

[oracle@test par]$ expdp C##HB@pdb directory=backup dumpfile=OBFUSCATING_001.dmp logfile=OBFUSCATING_001.log schemas=HB REMAP_DATA=HB.USER.TITLE:C##HB.OBFUSCATING.VAR

روش دوم

استفاده از پارامتر فایل

[oracle@test par]$ expdp C##HB@pdb directory=backup dumpfile=OBFUSCATING_001.dmp logfile=OBFUSCATING_001.log schemas=test2 parfile=/home/oracle/par/01.par

همونطور که در syntax دستور در داکیومنت مشخص هستش شما باید اسم جدول با اسم ستون هر کدوم از ستونهایی که نیاز دارید Mask بشوند رو در دستور وارد کنید. اینجا اگه تعداد زیادی جدول با ستون داشته باشید ممکنه اذیت بشید.

من برای حل این مشکل یک dynamic query نوشتم که به جز ستون‌های مشخص شده که نباید Mask دیتا بر روی اونها انجام بشه باقی ستون‌ها دستورش نوشته بشه

select x from (select 'REMAP_DATA='||OWNER || '.' || table_name || '.' || COLUMN_NAME || ':C##MAHDI_GH.OBFUSCATING.VAR"' x from all_tab_columns 
where OWNER='HB'
and COLUMN_NAME not in ('ID', 'MOBILE_NUMBER', 'USERNAME', 'USER_ID', 'IS_VERIFIED_MOBILE')
and DATA_TYPE not in ('TIMESTAMP(6)', 'DATE', 'LONG')
and DATA_TYPE = 'VARCHAR2');

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

من تمام ستون هایی که میخواستم رو با داینامیک کویری درآوردم و به دستور expdp با روش اول یعنی به شکل یک دستور دادم.

شما می‌تونید به ۲ صورت زیر از این دستور استفاده کنید و اینجا فرقی نداره از کدوم روش استفاده کنید.

REMAP_DATA=HB.USER.TITLE:C##MAHDI_GH.OBFUSCATING.VAR, HB.KEY.NO:C##HB.OBFUSCATING.NUM

REMAP_DATA=HB.USER.TITLE:C##MAHDI_GH.OBFUSCATING.VAR REMAP_DATA=HB.KEY.NO:C##HB.OBFUSCATING.NUM

مساله ای که پیش میاد من بیش از ۱۵۰ ستون رو باید در یک خروجی data pump با هم mask کنم. وقتی این دستورات رو کنار هم بذارید مثلا با ابزاری مانند ++notepad و بخواهید اکسپورت رو اجرا کنید فقط تعداد محدودی از این ورودی ها مورد قبول دستور expdp میگردد. این به دلیل محدودیت ابزار expdp برای قبول ورودی از خط فرمان برای بیشتر از ۱۵۰۰ کاراکتره.

[oracle@test ~]$ expdp HB@pdb directory=backup dumpfile=HB_OBFUSCATING_001.dmp logfile=HB_OBFUSCATING_001.log schemas=HB remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR Export: Release 12.2.0.1.0 - Production on Sun Aug 23 18:55:44 2020Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.Connected to: Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit ProductionStarting "HB"."SYS_EXPORT_SCHEMA_01":  HB/********@ganjehpdb directory=backup dumpfile=HB_OBFUSCATING_001.dmp logfile=HB_OBFUSCATING_001.log schemas=HB remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR remap_data=HB.A.TITLE:HB.OBFUSCATING.VAR 
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/STATISTICS/MARKER
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/IDENTITY_COLUMN
Processing object type SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
. . exported "HB"."a"                        1.1 MB   1 rows
. . exported "HB"."b"                 1.1 MB   1 rows
. . exported "HB"."c"                  1.1 MB   1 rows
. . exported "HB"."e"                1.1 MB   1 rows
Master table "HB"."RT_SCHEMA_01" successfully loaded/unloaded
******************************************************************************
Dump file set for HB.SYS_EXPORT_SCHEMA_01 is:  /backup/HB_OBFUSCATING_001.dmpJob 
"HB"."SYS_EXPORT_SCHEMA_01" successfully completed at Sun Aug 23 18:57:15 2020 elapsed 0 00:01:31

به دلیل وجود این محدودیت شما نمی‌تونید از این روش برای mask ستونهای زیاد در یک اکسپورت واحد استفاده کنید. (یک راه حلی که ممکنه در اینجا به ذهن بیاد اینه که از هر جدول به صورت مجزا export تهیه بشه و در نهایت با n تا export اینکار انجام بشه.)

برای همین سراغ روش دوم یعنی فایل پارامتر می‌رویم.

با توجه به داکیومنت اوراکل استفاده از remap_data در پارامتر فایل به شکل زیر امکان پذیر هستش

https://docs.oracle.com/database/121/SUTIL/GUID-B1D13216-93D3-4FFC-A0BB-082E133FD2B9.htm#SUTIL861

[mehdi@test ~]$ cat parmeter.par

REMAP_DATA=datapump_test.test.col_01:datapump_remap_test.toggle_case
REMAP_DATA=datapump_test.test.col_02:datapump_remap_test.toggle_case

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

[root@db1 ~]# cat /home/oracle/parfile08.par
remap_schema=datapump_test.test.col_01:C##MAHDI_GH.OBFUSCATING.VAR
remap_schema=datapump_test.test.col_02:C##MAHDI_GH.OBFUSCATING.VAR
.
.
.

[oracle@db1 ~]$ expdp C##HB@pdb directory=backup dumpfile=OBFUSCATING_001.dmp logfie=/home/oracle/parfile11.par

Export: Release 12.2.0.1.0 - Production on Sun Aug 23 19:17:31 2020
Copyright (c) 1982, 2017, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
ORA-39001: invalid argument value
ORA-39232: invalid remap function: C

بعد از ساختن ۱۲ پارامتر فایل و خواندن API دیتا پامپ، سرچ‌های بسیار و بعد از ۴ ساعت مشکل رو پیدا کردم. به این دلیل که به دست آوردن تجربه بسیار گران است من این تجربه رو با شما به اشتراک میذارم تا شما هم از این تجربه بهره ببرید.

برای حل این مشکل کافیه از علامت دابل کوتیشن " در ابتدا و انتهای دستور remap_data استفاده کنید.

[root@db1 ~]# cat /home/oracle/par/02.par

REMAP_DATA="datapump_test.test.col_01:C##MAHDI_GH.OBFUSCATING.VAR"
REMAP_DATA="datapump_test.test.col_02:C##MAHDI_GH.OBFUSCATING.VAR"
.
.
.

در بین تلاش برای رفع این مشکل و در آخرین لحظات ناامیدی از این پارامتر کامند لاین داشتم می‌رفتم که از یک بلاک PL-SQL و API Data Pump استفاده و کار رو انجام بدم که خوشبختانه راه‌حل مشکل رو کشف کردم.

اطلاعات بیشتر برای نحوه کار با API

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/arpls/DBMS_DATAPUMP.html

و یک مثال کوچک که نوشتم

dbms_datapump.data_remap (handle => dph,
name => 'job',
table_name => test,
column => phone,
function => 'C##MAHDI_GH.OBFUSCATING.NUM',
schema => 'hb');

در نهایت همیشه اکثر مشکلات توسط یک اراده قوی قابل حل هستند. اگر از این مطلب استفاده کردید اون رو به DBA های دیگه هم معرفی کنید و اگه پیشنهاد همکاری برای من داشتید می‌تونید با من در تماس باشید.

 

شاد و خرم باشید

بدرود

بررسی هنگ کردن اوراکل

برای انجام این پروسه میشه از sqlplus  و با استفاده از دستور oradebug  اطلاعاتی را به دست آورد. فرمان oradebug hanganlyze اطلاعاتی را در فایل trace برای بررسی بیشتر ارائه خواهد کرد. روال کلی با استفاده از فرمان های  زیر است:

sqlplus / as sysdba
oradebug setmypid
oradebug unlimit
oradebug hanganlyze 3
oradebug dump ashdumpseconds 30
oradebug dump systemstate 266
oradebug tracefile_name

در مواقع هنگ کامل که با sqlplus / as sysdba به دیتابیس نمی توان متصل شد از سوئیچ زیر استفاده کنید:

sqlplus /nolog
set _prelim on

چک کردن سایز دیتابیس اوراکل NonCDB و CDB

می‌خوایم نحوه چک کردن سایز فعلی دیتابیس اوراکل رو برای Non-CDB و CDBها ببینیم. اکثرا این اطلاعات در نرم‌افزارهایی مثل Toad For Oracle به سادگی قابل روئیت هستند اما اگر شما در سایت عملیاتی باشید و دسترسی به ابزار نداشته باشید بهترین راهکار اجرای کوئری در sqlplus هستش.

محیط Non-CDB

چک کردن سایز اشغال شده دیتافایلها در دیسک:

select sum(bytes)/1024/1024 size_in_mb from dba_data_files;

چک کردن تمام فضای استفاده شده توسط سگمنت‌ها:

select sum(bytes)/1024/1024 size_in_mb from dba_segments;

چک کردن سایز اسکیماها در اوراکل:

select owner, sum(bytes)/1024/1024 Size_MB from dba_segments group by owner;

چک کردن فضای آزاد و فضای اشغال شده در دیتابیس:

select
"Reserved_Space(MB)", "Reserved_Space(MB)" - "Free_Space(MB)" "Used_Space(MB)","Free_Space(MB)"
from(
select
(select sum(bytes/(1014*1024)) from dba_data_files) "Reserved_Space(MB)",
(select sum(bytes/(1024*1024)) from dba_free_space) "Free_Space(MB)"
from dual );

چک کردن سایز تمام فایل‌های دیتابیس بعلاوه tempها و redoها:

select
( select sum(bytes)/1024/1024/1024 data_size from dba_data_files ) +
( select nvl(sum(bytes),0)/1024/1024/1024 temp_size from dba_temp_files ) +
( select sum(bytes)/1024/1024/1024 redo_size from sys.v_$log ) +
( select sum(BLOCK_SIZE*FILE_SIZE_BLKS)/1024/1024/1024 controlfile_size from v$controlfile) "Size in GB"
from
dual;

محیط CDB و دیتابیسهای PDB

چک کردن سایز PDB:

select con_id, name, open_mode, total_size from v$pdbs;

چک کردن سایز CDB:

select sum(size)/1024/1024/1024 from cdb_data_files;

منبع

https://smarttechways.com/2018/04/23/check-the-size-of-oracle-database-and-pdbs-database/

فعالسازی trace لیسینر اوراکل

یه مشکل نتورکی داریم ولی نمیدونیم مشکل دقیقا از کجاست؟؟ توی این مواقع به غیر از خوندن لاگ لیسینر توصیه میشه trace رو در سطح لیسینر فعال کنید که جزییات بیشتری رو بتونید آنالیز و tshot کنید.

فعالسازی با تنظیم:

پارمترهای listener.ora

DIAG_ADR_ENABLED_LISTNER=OFF 
TRACE_DIRECTORY_LISTENER = <path> 
TRACE_LEVEL_LISTENER = 16

پارامترهای sqlnet.ora

DIAG_ADR_ENABLED=OFF 
TRACE_LEVEL_SERVER = 16 
TRACE_DIRECTORY_SERVER = <path>

راه‌اندازی اوراکل ۱۹.۳ به صورت SingleInstance بر روی داکر

برای راه‌اندازی اوراکل ۱۹.۳ بر روی داکر ابتدا باید داکر را بر روی پلتفرم هاست خود نصب کنید. برای نصب داکر از وبسایت رسمی داکر شما نیاز به ساخت اکانت در داکر هاب دارید. بعد از ساخت اکانت و نصب Docker Desktop با کلیک بر روی اون داکر به سادگی اجرا میشه.

نحوه ایجاد پیکربندی Dataguard Broker در دیتابیس 12c

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

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

db_unique_name در دیتابیس اصلی: tehran

db_unique_name در دیتابیس دیتاگارد: yazd

نیازمندی‌های قبل از پیکربندی

استارت پروسس Dataguard broker DMON در دیتابیس اصلی (primary) و دیتاگارد (standby)

SQL> alter system set dg_broker_start=true sid='*'; 

 

توصیه‌های‌ اوراکل جهت ارتقای پایگاه داده رابطه‌ای

در حال حاضر نسخه 19c پایگاه‌داده رابطه‌ای اوراکل برای تمام پلتفرم‌ها در دسترس قرار داده شده است. اوراکل قراره از این نسخه برای مشتریان برتر تا جمعه، ۱۱ فروردین ۱۴۰۲ پشتیبانی طولانی مدت (Long Term Support) انجام بده همچنین پشتیبانی تمدید شده (Extended Support) خود را تا سه شنبه، ۱۱ فروردین ۱۴۰۵ برای این نسخه ارائه میدهد.

به منظور جلوگیری از خرید جدید محصول، به حداقل رساندن پروسه ارتقا در آینده و استفاده از ویژگی‌های جدید اوراکل شما رو تشویق میکند بدون تعلل به نسخه جدید 19c آپگرید کنید.

گزینه‌های ارتقای توصیه شده از طرف اوراکل:

اگه شما در حال حاظر از نسخه 11.2.0.4 یا 12.1.0.2 پایگاه داده اوراکل استفاده می‌کنید شما باید یک مجوز توافقنامه نامحدود که شامل پشتیبانی تمدید شده و ارتقا به نسخه 19c است را با پرداخت هزینه توافقنامه قبل از پچ کردن به نسخه جدید تهیه کنید. 

در جریان باشید آخرین نسخه پچ پایگاه‌داده اوراکل 11.2.0.4 در پلن پشتیبانی تمدید شده در آخرین روز از تاریخ پشتیبانی یعنی پنج شنبه، ۱۱ دی ۱۳۹۹ انتشار پیدا می‌کند،

همچنین آخرین پچ نسخه 12.1.0.2 پایگاه‌داده اوراکل شنبه، ۹ مرداد ۱۴۰۰ انشار پیدا می‌کند و از سه شنبه، ۸ مرداد ۱۳۹۸ آپگرید به نسخه 19c برای این مشتریان بدون هزینه خواهد بود.

ولی اگه در حال حاضر از نسخه 12.2.0.1 یا 18c پایگاه داده استفاده می‌کنید بهتره قبل از اینکه به آخرین روزهای پشتیبانی تصحیح خطای اوراکل برسید آپگرید کنید.

تاریخ پایان پشتیبانی تصحیح خطای اوراکل برای نسخه 12.2.0.1 جمعه، ۱۰ مرداد ۱۳۹۹ تعیین و برای نسخه 18c چهارشنبه، ۹ تیر ۱۴۰۰ تعیین شده است.

هدف اوراکل از این توصیه‌ها راهنمایی شماست که همیشه در دوره پشتیبانی Lifetime Support و Error Correction بمانید و از هزینه ارتقا در دوره Extended Support به نسخه جدید جلوگیری کنید.

برای سوالات خود درباره certified بودن محصول خود مانند Oracle E-Business Suite, Oracle JD Edwards, Oracle PeopleSoft, Oracle Siebel و ... به بخش Certification از اکانت متالینک خود مراجعه نمایید.

برای سوال در مورد نحوه فرآیند ارتقا و انجام آن در سایت‌های خود می‌توانید با ما در تماس باشید.

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

Release Schedule of Current Database Releases (Doc ID 742060.1)

اخبار داغ اوراکل: اعلام نیازمندی‌های نصب دیتابیس 19c بر روی لینوکس

اوراکل حداقل نیازمندی‌های اساسی را برای نصب کامل و موفق دیتابیس اوراکل 19c بر روی توزیع اوراکل لینوکس ۷ (یا بالاتر) یا توزیع ردهت سازمانی نسخه ۷ یا بالاتر پلتفرم ۶۴ بیتی اعلام کرد.

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

پیشنیازهای اعلامی مبنی بر نصب و راه‌اندازی دیتابیس اوراکل به صورت Single Instance بر روی File System است اگر محیط شما شامل RAC و یا ASM است برای دریافت مشاوره از طریق صفحه تماس با ما تماس بگیرید.

نیازمندی‌ها برای نصب و راه‌اندازی اوراکل 19c ریلیز ۶۴ بینی در اوراکل لینوکس ۷ ریلیز ۶۴ بیتی یا ردهت سازمانی نسخه ۷ و بالاتر

قبل از انجام نصب و راه‌اندازی حداقل نیازمندی‌های اعلام شده را برای جلوگیری از مشکلات در نصب با دقت مطالعه کنید.