Mandatory Profile در اوراکل 21c

همانطور که می دانید از طریق پروفایل می توان برای هر کاربر در دو سطح مصرف منابع و password complexity محدودیتهایی را اعمال کرد. پروفایلها در سطح کاربر قابل تنظیم هستند و هر کاربر می تواند تنها یک پرفایل داشته باشد.

در اوراکل 21c نوع جدیدی از پروفایل تحت عنوان Mandatory Profile ارائه شد که در سطح root container قابل ایجاد است و می توان این دسته از پروفایلها را برای یک یا چند pdb تنظیم کرد که در این صورت، پالیسی مربوط به این پروفایل، برای همه کاربران موجود در آن pdb اعمال خواهد شد.

Mandatory Profile صرفا قرار است در زمینه تنظیم پسورد برای کاربران محدودیت ایجاد کند به این صورت که مثلا پسورد کاربر حداقل n کارکتر داشته باشد. این قبیل محدودیتها از طریق ایجاد یک FUNCTION و تنظیم پارامتر PASSWORD_VERIFY_FUNCTION(در پروفایل) قابل اعمال هستند.

(بیشتر…)

اوراکل 21c – اعمال فوری تغییرات در Unified Audit Policy

تا قبل از اوراکل نسخه 21c، هرگونه تغییر در یک Unified Audit Policy، برای sessionهای متصل به دیتابیس اعمال نمی شد و برای اثرپذیری فوری تغییرات audit policy، باید کاربران متصل به دیتابیس را مجبور به log out کرد تا بعد از اتصال مجدد به دیتابیس، مطابق با قوانین جدید audit شوند. این محدودیت را در سناریوی زیر توضیح دادیم.

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production

–session 1:

SQL> create user vahid identified by a;

User created.

SQL> grant create session to vahid;

Grant succeeded.

SQL> grant select on usef.tbl1 to vahid;

Grant succeeded.

SQL> create audit policy audpolselect actions select on usef.tbl1;

Audit policy created.

–session 2:

SQL> conn vahid/a@192.168.56.22:1521/pdb1

Connected.

–session 1:

SQL> audit policy audpolselect by vahid;

Audit succeeded

–session 2:

SQL> show user

USER is “VAHID”

SQL> select count(*) from usef.tbl1;

  COUNT(*)

———-

         3

فعال شدن audit policy قبل از اجرای دستور select، منجر به audit کاربر vahid نخواهد شد:

SQL> select dbusername,action_name,unified_audit_policies from unified_audit_trail where unified_audit_policies like ‘%AUDPOLSELECT%’;

no rows selected

(بیشتر…)

اوراکل 21c – آماده سازی مقدمات راه اندازی دیتاگارد با Broker

در اوراکل 21c می توان با کمک Data Guard Broker محیط دیتابیس primary را برای راه اندازی Data Gaurd آماده کرد. قرار دادن دیتابیس در مود archivelog، فعال کردن force logging، تنظیم پارامترها، ایجاد Standby Redo Log و … صرفا با اجرای یک دستور در محیط Broker انجام می شود. این دستور PREPARE DATABASE FOR DATA GUARD است که در قسمت زیر نحوه اجرای آن را به همراه عملیاتی که انجام می دهد، مشاهده می کنید:

DGMGRL> PREPARE DATABASE FOR DATA GUARD WITH DB_UNIQUE_NAME IS db21c

DB_RECOVERY_FILE_DEST_SIZE is “550G”

DB_RECOVERY_FILE_DEST is “/oracle21c/FRA”;

(بیشتر…)

اوراکل 21c- مقایسه explain plan با کمک تابع compare_explain

در اوراکل 21c تابعی با نام compare_explain به dbms_xplan اضافه شد که امکان مقایسه بین explain planهای دو دستور را فراهم می کند. در قسمت انتهایی گزارش(Comparison Results) این تابع، تفاوت دو plan نمایش داده خواهد شد.

مثال زیر را ببینید.

SQL> create table mytbl as select * from dba_objects;

Table created

SQL> create index ind1_object_id on mytbl(object_id);

Index created

SQL> explain plan  set statement_id = ‘Plan1’  for select /*+ full(mytbl) */ * from mytbl where object_id=9;

Explained

SQL> explain plan  set statement_id = ‘Plan2’ for select /*+ index(mytbl) */ * from mytbl where object_id=9;   

Explained

SQL> VARIABLE varvar1 varchar2(9000)

SQL> exec :varvar1 := dbms_xplan.compare_explain(‘Plan1′,’Plan2’);

PL/SQL procedure successfully completed.

(بیشتر…)

Read-only Oracle Home در اوراکل 21c(تغییر مسیر دایرکتوری dbs و network)

یکی از فیچرهای جدیدی که در اوراکل 18c ارائه شد Read-only Oracle Home بود که مطابق با آن، logfileها و فایلهای پیکربندی موجود در مسیر ORACLE_HOME نظیر listener.ora، sqlnet.ora، spfile.ora و … به دایرکتوریهای زیرشاخه ORACLE_BASE منتقل می شوند(عمده فایلهای پیکربندی، در زیر دایرکتوری network/admin و dbs قرار می گیرند).

انتقال فایلهای پیکربندی از ORACLE_BASE به ORACLE_HOME سبب شده تا نیاز به تغییر در فایلهای ORACLE_HOME به حداقل برسد به طوری که اگر یک Read-only Oracle Home را در پارتیشن read-only قرار دهیم، اوراکل بدون مشکل به کارش ادامه خواهد داد مگر آنکه نیاز به اعمال patch بر روی نرم افزار داشته باشیم که در این صورت باید پارتیشن را در حالت read write قرار دهیم.

(بیشتر…)

قابلیت Data Pump Checksum در اوراکل 21c

اوراکل در نسخه 21c این امکان را می دهد تا در هنگام گرفتن دامپ، checksumای در dump file قرار داده شود تا در هر زمان(به خصوص بعد از جابجایی)  بتوان اعتبار و صحت فایل دامپ را مورد بررسی قرار داد و با کمک این اطلاعات کنترلی از عدم خرابی dump fileها اطمینان حاصل کرد.

به این منظور، پارامتر CHECKSUM به لیست پارامترهای Data Pump اضافه شده و برای استفاده از این ویژگی باید در کنار دستور expdp پارامتر CHECKSUM را برابر با مقدار YES قرار داد:

(بیشتر…)

مستثنی کردن اطلاعات ستونهای از نوع LOB در دیتاپامپ

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

راهکار چیست؟

مستثنی کردن اطلاعات ستونهای از نوع LOB در زمان انجام عملیات export از اوراکل نسخه 12c به راحتی قابل کنترل است این کار با ایجاد ویو و استفاده از پارامتر views_as_tables قابل انجام است اما برای برگرداندن دامپ حاوی اطلاعات LOB، نمی توان از این راهکار استفاده کرد و در این صورت استفاده از پارامتر REMAP_DATA راهگشا خواهد بود.

(بیشتر…)

نکاتی در مورد نامگذاری اشیا در اوراکل

در این متن به مرور نکاتی در زمینه نامگذاری اشیا در دیتابیس اوراکل می پردازیم.

نکته 1: اشیاهای زیر namespace مختص به خود را دارند و امکان تکرار اسامی در بین این objectها وجود دارد:

Indexe – Constraint –  Cluster – Database trigger – Private database link – Dimension

مثال: با اجرای دستورات زیر، constraint و database link همنامی را ایجاد می کنیم:

SQL> alter table TBL1  add constraint name1 primary key (FILE#);

Table altered

SQL> create database link name1 connect to usef identified by pa using ‘mydb’;

Database link created

همچنین objectهای زیر namespace مشترکی دارند و تکرار اسامی در بین آنها، امکان پذیر نمی باشد:

TableView – SequencePrivate synonym Stand-alone procedure – Stand-alone stored function – Package – Materialized view – User-defined type

مثال: در این مثال می بینید که امکان استفاده از نام مشترک برای view و table وجود ندارد:

SQL> create table v1 as select * from v$datafile;

Table created

SQL> create view v1 as select * from dual;

ORA-00955: name is already used by an existing object

(بیشتر…)

بررسی تغییرات dbms_job در اوراکل 19c

تا قبل از اوراکل نسخه 10g، برای ایجاد جاب در محیط دیتابیس، از بسته dbms_job استفاده می شد در نسخه 10g بهبودی در این زمینه ایجاد شد و اوراکل با ارائه بسته dbms_scheduler، بسیاری از نقاط ضعف dbms_job را پوشش داد و عملا استفاده از این بسته را به حداقل رساند.

اما با این حال، کاربران می توانند کماکان از این بسته(dbms_job) برای تعریف جاب جدید و یا مدیریت جابهای قبلی(جابهای ایجاد شده در نسخه های قدیمی تر) استفاده کنند و حتی اوراکل هم برای زمانبندی بعضی از کارها، از همین بسته استفاده می کند.

(بیشتر…)

بهبودهای EZconnect در اوراکل 19c

زمانی که از پروتکل tcp/ip برای برقراری ارتباط با یک دیتابیس اوراکل استفاده می کنیم، اتصال به روش Easy Connect در مواردی می تواند جایگزین مناسبی برای فایل tnsnames.ora باشد. ساختار کلی Easy Connect تا قبل از اوراکل نسخه 19c، به صورت زیر می باشد:

host[:port][/service_name]

(بیشتر…)