#اوراکل

بررسی ویژگی Unified Auditing
همانطور که می دانید، ثبت وقایع برای نسخه های قبل از اوراکل 12c، از طریق standard auditing امکان پذیر است. با کمک این شیوه از auditing، می توان تمامی عملیات کاربران حاضر در بانک اطلاعاتی را مانیتور نمود (البته به غیر از کاربرانی که با مجوز sysdba به بانک لاگین کرده اند.) این شیوه از auditing در کنار مزیتهای فراوانی که به همراه دارد، با محدودیتهایی هم روبروست، محدودیتهایی نظیر:

1.امکان دستکاری راحت audit record توسط کاربر sys

2.عدم ثبت وقایع کاربر sys در جدولی از بانک

3.عدم امکان auditing بر اساس role کاربران

4.عدم پارتیشن بندی پیش فرض جدول aud$ و مشقتهای حذف بازه ای اطلاعات آن(delete + HWM)

5.عدم امکان auditing بر اساس مولفه هایی چون rman، datapump، sqlldr و …

6.عدم امکان auditing بر مبنای host name، ip address و …

و …
نکته: در محیطی که چند نفر مسئولیت پشتیبانی بانک را بر عهده دارند و بعضی از آنها از تسلط کافی برخوردار نیستند، ثبت وقایع برای کاربر sys می تواند مفید باشد البته دور زدن auditing برای فردی که از دانش کافی در این زمینه برخوردار است، به سادگی قابل انجام خواهد بود و برای کنترل چنین فردی، ناگزیر باید از یک ابزار بیرونی مانند database vault استفاده کرد.

با آمدن اوراکل 12c، در زمینه auditing بهبودهایی حاصل شد و با ارائه قابلیتunified auditing ، بسیاری از محدودیتهای standard auditing برطرف شد.
در این متن به بررسی این قابلیت جدید اوراکل، خواهیم پرداخت.

همانطور که از نام این ویژگی برمی اید، قرار است با کمک unified auditing، سطوح مختلف auditing از قبیل sys auditing، FGA auditing، standard auditing و … تنها در یک جدول ذخیره شوند.

ادامه متن را در ادرس زیر مطالعه بفرمایید:

http://www.usefzadeh.com/2018/08/26/unified-auditing/

#کتاب_لینوکس

Linux Bible 9th Edition

تعداد صفحات: 900

#اوراکل
پارامتر read_only_open_delayed
با قرار دادن tablespace در وضیعت read only، کماکان وجود دیتافایلهای این tablespace در زمان open شدن بانک، مورد بررسی قرار می گیرد:

SQL> alter tablespace tbs01 read only;

SQL> shut immediate;

[oracle@hkm2 ~]$ mv /18c/base/oradata/CDB/CDB/datafile/o1_mf_tbs01_fro24f2b_.dbf /18c/base/oradata/CDB/CDB/datafile/o1_mf_tbs01_fro24f2b_old.dbf

SQL> startup force;
ORA-01157: cannot identify/lock data file 17 - see DBWR trace file

برای ممانعت از سخت گیری بانک در این زمینه، می توان از پارامتر read_only_open_delayed استفاده کرد که با مقداردهی این پارامتر از false به true، در دسترس بودن دیتافایلی که tablespace آن در وضیعت read only قرار دارد، چک نخواهد شد:

SQL> alter system set read_only_open_delayed=true scope=spfile;
System altered.

SQL> startup mount force;
SQL> alter database open;
Database altered.

بعد از قرار گرفتن دیتابیس در وضیعت open، خطای عدم دسترسی مربوط به دیتافایل شماره 17، در alert log مکررا مشاهده خواهد شد:

ORA-01186: file 17 failed verification tests
ORA-01157: cannot identify/lock data file 17 - see DBWR trace file

#کتاب_لینوکس
Linux System Administration Recipes

تعداد صفحات: 280

ایجاد physical standby با کمک دستور dbca

نکاتی در مورد دستور tnsping

#کتاب_لینوکس

Linux-101-Hacks

تعداد صفحات: 140

نگاهی گذرا به administrative privilegeها در اوراکل

#کتاب_لینوکس

A Practical Guide to Linux Commands, Editors and Shell Programming (4th Edition)

تعداد صفحات: 1200

Guidelines for Indexing Foreign Keys

WITH SESSION SHUTDOWN clause

How To Find Out Which Port Number A Process Is Using In Linux???

a built-in package(standard)

#اوراکل_12c
ویژگی Multi Instance Redo Apply

در اوراکل 11g با پیاده سازی دیتاگارد به صورت کلاستر، تنها نودی که دستور alter database manage recover بر روی ان اجرا شده(برای اولین بار!)، مسئولیت اعمال کردن redoها را برعهده خواهد داشت و مابقی نودها می توانند برای گزارش گیری، تهیه بکاپ و یا دریافت redo (یا آرشیو) و… مورد استفاده قرار بگیرند.

در اوراکل 12cR2، بهبودی در این زمینه رخ داد که می توان با کمک آن، همه نودها را در recovery سهیم کرد. این قابلیت که (Multi Instance Redo Apply (MIRA نام دارد، امکان اعمال redoها را با کمک چند instance ممکن می سازد.

ادامه متن را در ادرس زیر مطالعه بفرمایید:

http://www.usefzadeh.com/2018/09/24/ویژگی-multi-instance-redo-apply/

انتقادات، پیشنهادات و نظرات سازنده خود را با ما در میان بگذارید:

@vahidusefzadeh