همانطور که می دانید؛ ایجاد گزارش awr در محیط ADG به صورت روتین امکان پذیر نمی باشد این اتفاق به دلیل عدم امکان ایجاد snapshot بر روی بانکی که در حالت read only قرار دارد، کاملا منطقی بنظر می رسد. در اوراکل 12cR2، راهکاری برای این مسئله اندیشیده شد و امکان تهیه این گزارش برای ADG هم فراهم شده است.
مانیتورینگ ایندکسها در اوراکل 11g و 12c
#پرسش: کدام یک از ایندکسها در بانک اطلاعاتی بلاستفاده و قابل حذف هستند؟ تعداد رجوع به یک ایندکس را چگونه می توان تعیین کرد؟
پاسخ: دست یافتن به پاسخ قسمت اول این سوال، در اوراکل نسخه 10g و 11g نسبتا کار ساده ای است این کار با اجرای یک دستور و همچنین طول کشیدن مدت زمانی از اجرای ان(گاها بیش از چند ماه)، قابل انجام خواهد بود.
ویژگی Multi Instance Redo Apply
در اوراکل 11g با پیاده سازی دیتاگارد به صورت کلاستر، تنها نودی که دستور alter database manage recover بر روی ان اجرا شده(برای اولین بار!)، مسئولیت اعمال کردن redoها را برعهده خواهد داشت و مابقی نودها می توانند برای گزارش گیری، تهیه بکاپ و یا دریافت redo (یا آرشیو) و… مورد استفاده قرار بگیرند.
در اوراکل 12cR2، بهبودی در این زمینه رخ داد که می توان با کمک آن، همه نودها را در recovery سهیم کرد. این قابلیت که (Multi Instance Redo Apply (MIRA نام دارد، امکان اعمال redoها را با کمک چند instance ممکن می سازد.
نگاهی گذرا به administrative privilegeها در اوراکل
نکاتی در مورد دستور tnsping
راه اندازی دیتاگارد با کمک dbca
پارامتر read_only_open_delayed
با قرار دادن tablespace در وضیعت read only، کماکان وجود دیتافایلهای این tablespace در زمان open شدن بانک، مورد بررسی قرار می گیرد:
SQL> alter tablespace tbs01 read only;
Tablespace altered.
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 و …
و …
ویژگی PDB RELOCATE
یکی از قابلیتهای جدید نسخه 12cR2، جابجایی(relocate) انلاین pdb از یک cdb به cdb دیگر می باشد. این کار مشابه ویژگی pdb hot clone می باشد که قبلا در مورد ان مطلبی ارائه شد(ایجاد انلاین pdb به صورت از راه دور)، با این تفاوت که در ویژگی pdb relocate، بعد از انجام عملیات کپی، pdb از بانک مبدا حذف خواهد شد و امکان باز بودن این pdb در هر دو cdb، ان هم در یک زمان وجود نخواهد داشت.
ریکاوری استندبای تا یک تاریخ یا scn مشخص
برای ریکاوری استندبای(با این فرض که استندبای عقب یا در حالت delay قرار دارد) تا یک تاریخ یا scn، مشخص می توان از دستور زیر استفاده کرد:
SQL> ALTER DATABASE RECOVER automatic standby database until time ‘2017-05-15 06:15:47’;
Database altered.
در این صورت با رسیدن ریکاوری به زمان تعیین شده، پیامی مشابه با پیام زیر، در alert log قابل مشاهده خواهد بود:
Incomplete Recovery applied until change 41254778 time 05/15/2017 06:15:47
Media Recovery Complete (DBSTEST)
Completed: ALTER DATABASE RECOVER automatic standby database until time ‘2017-05-15 06:15:47’