راه اندازی دیتاگارد با کمک dbca
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 و …
و …
ریکاوری استندبای تا یک تاریخ یا 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’
ستون last_login در ویوی dba_users
اخرین بار چه زمانی کاربر usef به بانک login کرده است؟؟؟ در اوراکل 12c، بدون تنظیم هیچ پارامتر اضافه ای، به راحتی می توان به این سوال پاسخ داد:
select LAST_LOGIN,username from dba_users where username=’USEF’;
فراخوانی lobs با dblink در اوراکل 12cR2
در اوراکل 11g، با کمک dblink نمی توان فیلدی که از نوع داده lobs می باشد را به صورت زیر فراخواند:
select * from usef.tbl@db11g;
ORA-22992: cannot use LOB locators selected from remote tables
همچنین اگر جدول مورد نظر در اوراکل ماقبل از نسخه 12cR2 باشد و فراخوانی ان در نسخه 12cR2 انجام شود، کماکان با خطا مواجه خواهد شد:
–in 12cR2 to 11g
select * from tbl@db11g;
ORA-65510: Distributed LOB operations are not supported on pre-12.2 databases.
حال اگر طرفین 12cR2 باشند، این محدودیت برطرف خواهد شد:
select * from tbl@db12r2;
1 <CLOB>
چالشهای دیتاگارد در محیط Multitenant
پرسش: در محیط Multitenant، با ایجاد یک pdb جدید، چه اتفاقی برای دیتاگارد رخ خواهد داد؟ آیا دیتاگارد از حالت ریکاور خارج خواهد شد؟ چگونه میتوان در زمان انجام عملیات pdb cloning و یا remote hot clone ، دیتاگارد را در حالت همسان با بانک اصلی نگه داشت؟ و …
در این متن قصد داریم تا به این دسته از سوالات پاسخ دهیم و شیوه های مختلف ایجاد یک pdb و همچنین نحوه اثر گذاری ان را بر روی دیتاگارد، مورد بررسی قرار دهیم.
INHERIT PRIVILEGE
قبلا در مورد invoker right و definer right مطلبی را ارائه کردیم(ادرس مطلب) و نشان دادیم که استفاده از عبارت AUTHID CURRENT_USER چه مزیت امنیتی ای را به همراه دارد اما استفاده از invoker right در زمانی که مجوزهای invoker از definer بیشتر باشد، نقایصی را هم به لحاظ امنیتی در برخواهد داشت که در ادامه با ارائه مثالی، به این نقصان خواهیم پرداخت.
مجوز alter user در اوراکل 12c
با اهدای مجوز alter user به یک کاربر در اوراکل 11g، ان کاربر می تواند تغییراتی چون تغییر پسورد را برای کاربر sys اعمال کند. مثال زیر را ببینید:
SQL*Plus: Release 11.2.0.3.0 Production on Tue Jun 12 12:57:22 2018
SQL> create user usef identified by a;
User created.
SQL> grant connect,resource to usef;
Grant succeeded.
SQL> grant alter user to usef;
Grant succeeded.
SQL> conn usef/a
Connected.
SQL> alter user sys identified by a;
User altered.
در اوراکل 12c، این امکان برای کاربر usef از بین خواهد رفت:
SQL*Plus: Release 12.2.0.1.0 Production on Tue Jun 12 13:29:04 2018
SQL> alter user vahid identified by a;
User altered.
SQL> alter user sys identified by a;
ORA-01031: insufficient privileges
تغییر نام کاربر در اوراکل
برای تغییر نام یک کاربر در اوراکل، تا قبل از نسخه 11g، دستور مشخصی وجود نداشت و برای انجام این کار، نیاز بود تا از عملیات پرهزینه ای چون expdp/impdp، exp/imp و … استفاده کرد که البته استفاده از این روشها در بسیاری از محیطها، بسیار دشوار و تا حدودی نشدنی بود.