بانک اطلاعاتی اوراکل با هر نسخه جدیدی که ارائه می کند معمولا بسیاری باگهای ایجاد شده در نسخه های قبلی را رفع و همراه با آن ویژگی های جدیدی را هم عرضه می کند به همین منوال، در نسخه 12c، بیش از 500 ویژگی جدید را ارائه کرده است که در این مقاله سعی داریم تا بعضی از این ویژگی ها را مورد بررسی قرار دهیم البته از مهمترین ویژگی این نسخه، Pluggable Database می باشد که در مقاله دیگری در مورد ان مطالبی آورده شد و در این مقاله به این ویژگی مهم نخواهیم پرداخت(مقاله مذکور در سایت www.usefzadeh.com موجود می باشد).
اجرای دستورات Sql در RMAN
بدون هیچ پیش شرطی می توان دستورات sqlای را در RMAN اجرا کرد:
RMAN> select status from v$instance;
STATUS
————
OPEN
RMAN> desc usef.a;
using target database control file instead of recovery catalog
Name Null? Type
—————————————– ——– —————————-
FILE# NUMBER
NAME VARCHAR2(513)
Multisection در زمان backp as copy
در صورت وجود BIGFILE Tablespace در یک بانک، استفاده از شیوه مرسوم بکاپ و ریکاوری آن هم در سطح tablespace، چندان کارا نخواهد بود شاید به همین دلیل از نسخه 11g عبارت SECTION SIZE به گزینه های دستور backup اضافه شد که می توان با استفاده از این عبارت، ابتدا فایل را به چند قسمت تقسیم کرده(بلاکهای همجوار در یک دسته قرار می گیرند) و در نهایت هر قسمت را به یک کانال مجزا سپرد تا به صورت موازی از یک فایل بکاپ تهیه شود این عبارت در نسخه 11g، در زمان بکاپ گیری به صورت backupset و level 0 قابل استفاده بود ولی بکاپهای از نوع backp as copy و level 1 را پشتیبانی نمی کرد که از نسخه 12c، این قابلیت هم به وجود آمد.
RMAN>create bigfile tablespace USEF_TBS1 DATAFILE ‘/u01/oracle/oradata/test/usef_tbs1.dbf’ SIZE 5000M;
RMAN> CONFIGURE DEVICE TYPE disk PARALLELISM 4;
RMAN> BACKUP as copy SECTION SIZE 2000M DATAFILE ‘/u01/oracle/oradata/test/usef_tbs1.dbf’ format ‘/u01/bkp/%U’;
channel ORA_DISK_1: starting datafile copy
input datafile file number=00007 name=/u01/oracle/oradata/test/usef_tbs1.dbf
backing up blocks 1 through 256000
channel ORA_DISK_2: starting datafile copy
input datafile file number=00007 name=/u01/oracle/oradata/test/usef_tbs1.dbf
backing up blocks 256001 through 512000
channel ORA_DISK_3: starting datafile copy
input datafile file number=00007 name=/u01/oracle/oradata/test/usef_tbs1.dbf
backing up blocks 512001 through 640000
output file name=/u01/bkp/data_D-TEST_I-2221058339_TS-USEF_TBS1_FNO-7_2erqk4lg tag=TAG20170121T223944
channel ORA_DISK_3: datafile copy complete, elapsed time: 00:00:55
output file name=/u01/bkp/data_D-TEST_I-2221058339_TS-USEF_TBS1_FNO-7_2erqk4lg tag=TAG20170121T223944
channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:35
output file name=/u01/bkp/data_D-TEST_I-2221058339_TS-USEF_TBS1_FNO-7_2erqk4lg tag=TAG20170121T223944
channel ORA_DISK_2: datafile copy complete, elapsed time: 00:01:35
همانطور که می بینید، در نهایت تنها یک فایل در مسیر /u01/bkp/data_D-TEST_I-2221058339_TS-USEF_TBS1_FNO-7_2erqk4lg ایجاد شد.
همچنین دستور زیر به صورت backup as copy از کل بانک اطلاعاتی بکاپ خواهد گرفت:
RMAN> BACKUP as copy SECTION SIZE 2000M database format ‘/u01/bkp/%U’;
duplicate با استفاده از backupset
از نسخه 11g قابلیتی با عنوان DUPLICATE ACTIVE STANDBY ارائه شد که بدون داشتن هیچ بکاپی، به صورت انلاین از بانک اصلی به صورت image as copy بکاپ گرفته و بر روی بانک مقصد ریکاوری را انجام می داد حال در نسخه جدید اوراکل، این امکان به وجود آمد تا duplicate با استفاده از backupset به جای image copy انجام شود. از مزیتهای انجام duplicate به شیوه backupset، می توان به نمونه های زیر اشاره کرد:
- ایجاد بار کمتر بر روی بستر شبکه
- امکان رمزنگاری داده قبل از انتقال آن برروی بستر شبکه
startup nomount;
rman target sys/sys@test auxiliary sys/sys@USEF12C
RMAN> duplicate database for standby from active database using backupset nofilenamecheck;
Starting Duplicate Db at 22-JAN-17
contents of Memory Script:
{
sql clone “alter system set control_files =
”/u01/oracle/oradata/TEST/controlfile/o1_mf_d89lyf2p_.ctl”, ”/u01/oracle/fast_recovery_area/TEST/controlfile/o1_mf_d89lyf6c_.ctl” comment=
”Set by RMAN” scope=spfile”;
restore clone from service ‘test’ standby controlfile;
}
renamed tempfile 1 to /u01/oracle/oradata/USEF12C/datafile/o1_mf_temp_%u_.tmp in control file
channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: using network backup set from service test
channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_1: restoring datafile 00001 to /u01/oracle/oradata/USEF12C/datafile/o1_mf_system_%u_.dbf
channel ORA_AUX_DISK_2: starting datafile backup set restore
channel ORA_AUX_DISK_2: using network backup set from service test
channel ORA_AUX_DISK_2: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_2: restoring datafile 00003 to /u01/oracle/oradata/USEF12C/datafile/o1_mf_sysaux_%u_.dbf
channel ORA_AUX_DISK_3: starting datafile backup set restore
channel ORA_AUX_DISK_3: using network backup set from service test
channel ORA_AUX_DISK_3: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_3: restoring datafile 00004 to /u01/oracle/oradata/USEF12C/datafile/o1_mf_undotbs1_%u_.dbf
channel ORA_AUX_DISK_3: restore complete, elapsed time: 00:00:03
channel ORA_AUX_DISK_3: starting datafile backup set restore
channel ORA_AUX_DISK_3: using network backup set from service test
channel ORA_AUX_DISK_3: specifying datafile(s) to restore from backup set
channel ORA_AUX_DISK_3: restoring datafile 00005 to /u01/oracle/oradata/USEF12C/datafile/o1_mf_usef_tbs_%u_.dbf
بازیابی جداول از بکاپ RMAN
با این ویژگی می توان تنها یک جدول خاص را با استفاده از بکاپ rman برگرداند. در زمان بازیابی جدول با این روش، ابتدا instanceای ایجاد شده و در پی آن tablespaceهایی که جدول مورد نظر به آنها وابسته است، بازیابی می شوند همچنین این جدول به روش data pump، در فایل dump ذخیره می شود که در هنگام بازیابی بر روی بانک اصلی، از این فایل استفاده می شود. در نهایت هم، همه فایلهای ایجاد شده اعم از دیتافایل و نیز دامپ فایل، حذف خواهند شد. البته این روش محدودیتهایی هم دارد از قبیل:
1. مالک جدول نباید sys باشد.
2. جدول نباید در SYSAUX و SYSTEM باشد.
3. بانک مقصد باید در حالت read/write و نیز در مود ارشیو قرار داشته باشد.
مثالی که در ادامه خواهد آمد، جدول usef.tbl1 را به 10 دقیقه قبل تر برمی گرداند. قبل از انجام ریکاوری، باید scn مربوط به ده دقیقه قبل را در بانک جاری بدست آورد:
select timestamp_to_scn(sysdate-10/24/60) from dual;
285697212528
حال با دستور زیر، عمل ریکاوری جدول tbl1 در بانک جاری انجام می شود:
RMAN> RECOVER TABLE usef.tbl1
UNTIL SCN 285697212528
AUXILIARY DESTINATION ‘/u01/aux’
DATAPUMP DESTINATION ‘/u01/pump’
DUMP FILE ‘usef_tbl1.dat’
REMAP TABLE ‘USEF’.’TBL1′:’TBL9′;
RMAN-05026: WARNING: presuming following set of tablespaces applies to specified Point-in-Time
List of tablespaces expected to have UNDO segments
Tablespace SYSTEM
Tablespace UNDOTBS1
Creating automatic instance, with SID=’gtkj’
initialization parameters used for automatic instance:
db_name=TEST
db_unique_name=gtkj_pitr_TEST
compatible=12.1.0.2.0
restore clone datafile 1, 4, 3;
switch clone datafile all;
}
renamed tempfile 1 to /u01/aux/TEST/datafile/o1_mf_temp_%u_.tmp in control file
datafile 1 switched to datafile copy
input datafile copy RECID=4 STAMP=934128982 file name=/u01/aux/TEST/datafile/o1_mf_system_d8gm3738_.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=5 STAMP=934128982 file name=/u01/aux/TEST/datafile/o1_mf_undotbs1_d8gm373l_.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=6 STAMP=934128982 file name=/u01/aux/TEST/datafile/o1_mf_sysaux_d8gm374l_.dbf
{
set until scn 285697212528;
sql clone “alter database datafile 5 online”;
recover clone database tablespace “USEF_TBS”, “SYSTEM”, “UNDOTBS1”, “SYSAUX” delete archivelog;
alter clone database open resetlogs;
}
sql “create or replace directory TSPITR_DIROBJ_DPDIR as ”
EXPDP> . . exported “USEF”.”TBL1″ 5.304 KB 4 rows
EXPDP> Master table “SYS”.”TSPITR_EXP_gtkj_qgBa” successfully loaded/unloaded
EXPDP> Dump file set for SYS.TSPITR_EXP_gtkj_qgBa is:
EXPDP> /u01/pump/usef_tbl1.dat
IMPDP> Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
IMPDP> . . imported “USEF”.”TBL9″ 5.304 KB 4 rows
auxiliary instance file /u01/aux/TEST/datafile/o1_mf_temp_d8gm508s_.tmp deleted
auxiliary instance file /u01/aux/GTKJ_PITR_TEST/onlinelog/o1_mf_3_d8gm8j8v_.log deleted
auxiliary instance file /u01/aux/GTKJ_PITR_TEST/onlinelog/o1_mf_2_d8gm8hsb_.log deleted
auxiliary instance file /u01/aux/GTKJ_PITR_TEST/onlinelog/o1_mf_1_d8gm8h96_.log deleted
auxiliary instance file /u01/aux/GTKJ_PITR_TEST/datafile/o1_mf_usef_tbs_d8gm6pnp_.dbf deleted
auxiliary instance file /u01/aux/TEST/datafile/o1_mf_sysaux_d8gm374l_.dbf deleted
auxiliary instance file /u01/aux/TEST/datafile/o1_mf_undotbs1_d8gm373l_.dbf deleted
auxiliary instance file /u01/aux/TEST/datafile/o1_mf_system_d8gm3738_.dbf deleted
auxiliary instance file /u01/aux/TEST/controlfile/o1_mf_d8gm30lg_.ctl deleted
auxiliary instance file usef_tbl1.dat deleted
Finished recover at 24-JAN-17
همچنین با پارامتر NOTABLEIMPORT می توان از imort شدن جدول در بانک مقصد جلوگیری کرد که در نهایت همه دیتافایلهای مربوط به بانک موقت پاک می شوند ولی فایل دامپ کماکان باقی خواهد ماند. برای انجام ریکاوری به این شیوه، دستور قبلی به صورت زیر اصلاح می شود:
RMAN> RECOVER TABLE usef.tbl1
UNTIL SCN 285697212528
AUXILIARY DESTINATION ‘/u01/aux’
DATAPUMP DESTINATION ‘/u01/pump’
DUMP FILE ‘usef_tbl1.dat’
NOTABLEIMPORT;
بعد از اجرای دستور بالا، می توان با استفاده از دامپ ایجاد شده، جدول را به صورت دستی برگرداند:
impdp usef/abc directory=xx dumpfile=usef_tbl1.dat remap_table=tbl1:tbl4
Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 – 64bit Production
. . imported “USEF”.”TBL4″ 5.304 KB 4 rows
Job “USEF”.”SYS_IMPORT_FULL_01″ successfully completed at Tue Jan 24 21:05:02 2017 elapsed 0 00:00:01
FAR SYNC DATA GUARD
یکی از ویژگی های که در زمینه data guard از اوراکل 12c معرفی شد، FAR SYNC نام دارد که شباهتهایی هم به cascade standby دارد. پیاده سازی این ویژگی سبب می شود تا سرور سومی نقش واسط را بین سرور primary و data guard ایفا کند طوری که redoها از سرور primary به این سرور ارسال شده و سپس از آنجا به بانک گارد منتقل شود. استفاده از این قابلیت سبب می شود تا در صورت بالا بودن تعداد data guardها، سربار کمتری بر روی بانک primary ایجاد شود همچنین در صورت مشکلات شبکه ای بین بانک اصلی و گارد، این ویژگی می تواند مفید باشد.
بانک(instance) FAR SYNC شامل کنترل فایل، pfile، پسورد فایل و standby redo log file می باشد و در این بانک، خبری از data fileها نخواهد بود همچنین آرشیوها در این سرور ایجاد می شوند و این بانک تنها در حالت mount قرار خواهد گرفت.
در ادامه مراحل انجام، به صورت خلاصه آورده شده است:
1. تنظیم pfile برای هر سه بانک. پارامترهایی که باید بر روی هر سه بانک اعمال شوند:
پارامترهای بانک اصلی:
*.db_unique_name=test
*.log_archive_config=’DG_CONFIG=(test,usef_stb,far)’;
*.log_archive_dest_2=’service=far SYNC AFFIRM alternate=log_archive_dest_3 db_unique_name=far’
*.log_archive_dest_3=’service=usef_stb ASYNC max_failure=1 alternate=log_archive_dest_2 db_unique_name=usef_stb’
*.log_archive_dest_state_3=alternate
پارامترهای FAR SYNC:
*.db_unique_name=far
*.log_archive_config=’DG_CONFIG=(test,usef_stb,far)’;
*.log_archive_dest_2=’service=usef_stb ASYNC db_unique_name=usef_stb’;
*.fal_server=test;
*. control_files=’/u01/far.ctl’
پارامترهای data guard:
*.db_unique_name=usef_stb
*.log_archive_config=’DG_CONFIG=(test,usef_stb,far)’;
*.fal_server=far,test;
2. تنظیم فایل tns
بعد از تنظیم و یا ایجاد pfile، باید فایل tnsnames.ora را اصلاح کرد:
far =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.22.136.4)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(sid = far)))
USEF_STB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.22.136.6)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(sid= usef_stb)))
TEST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.22.137.82)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(sid = test)))
3. استارت بانک FAR
در این مرحله، برای بانک FAR کنترل فایلی را در primary ایجاد می کنیم و سپس آن را به سرور مربوط به بانک FAR منتقل می کنیم:
alter database create far sync instance controlfile as ‘/u01/far.ctl’;
بعد از منتقل شدن کنترل فایل به بانک FAR، آن را به حالت mount استارت می کنیم:
SQL> startup mount force;
Total System Global Area 1.2684E+10 bytes
Fixed Size 3724928 bytes
Variable Size 2013268352 bytes
Database Buffers 1.0637E+10 bytes
Redo Buffers 29827072 bytes
Database mounted.
البته در صورتی که این بانک به صورت open استارت شود، با خطای زیر مواجه می شویم:
ORA-16476: far sync instance does not allow Open operation
همچنین فایلهای standby logfile group را به این بانک اضافه می کنیم:
alter database add standby logfile group 20 size 100m;
alter database add standby logfile group 21 size 100m;
دستور زیر، نقش این بانک را نشان می دهد:
SQL> select database_role from v$database;
DATABASE_ROLE
—————-
FAR SYNC
4. راه اندازی بانک استندبای:
rman target sys/sys@test auxiliary sys/sys@usef_stb
duplicate target database for standby from active database nofilenamecheck;
به بانک استندبای، standby redo log را اضافه کرده و سپس آن را در وضیعت recover قرار می دهیم:
alter database add standby logfile group 25 size 100m;
alter database add standby logfile group 26 size 100m;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
نقش این بانک، به صورت زیر می باشد:
SQL> select database_role from v$database;
DATABASE_ROLE
—————-
PHYSICAL STANDBY
برای راه اندازی بروکر، می توان طریق زیر را طی کرد:
ابتدا پارامتر مربوط به بروکر را در هر سه بانک TRUE می کنیم:
alter system set dg_broker_start=true;
بقیه پیکربندی در بانک اصلی انجام می شود:
dgmgrl /
DGMGRL> CREATE CONFIGURATION hamsandb AS PRIMARY DATABASE IS test CONNECT IDENTIFIER IS test;
Configuration “hamsandb” created with primary database “test”
DGMGRL> ADD DATABASE usef_stb AS CONNECT IDENTIFIER IS usef_stb;
Database “usef_stb” added
DGMGRL> ADD FAR_SYNC far AS CONNECT IDENTIFIER IS far;
far sync instance “far” added
DGMGRL> enable configuration;
DGMGRL> edit database test set property redoroutes='(local:far sync)’;
Property “redoroutes” updated
DGMGRL> edit far_sync far set property redoroutes='(test:usef_stb)’;
Property “redoroutes” updated
DGMGRL> enable far_sync far;
Enabled.
DGMGRL> show configuration;
Configuration – hamsandb
Protection Mode: MaxPerformance
Members:
test – Primary database
far – Far sync instance
usef_stb – Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 54 seconds ago)
همچنین می توانیم حالت فعلی گارد را با دستور زیر تغییر دهیم:
DGMGRL> edit configuration set protection mode as MaxAvailability;
رفع گپ در استندبای از طریق شبکه
از اوراکل 10g این قابلیت وجود داشت که با استفاده از incremental backup، گپ ایجاد شده بین بانک اصلی و گارد را برطرف کرد منتهی ابتدا می بایست این بکاپ به صورت دستی از بانک اصلی گرفته شود و سپس از بانک اصلی به کمک سیستم عامل به سرور گارد منتقل و در نهایت ریکاوری انجام شود. در نسخه جدید، نقش سیستم عاملی dba حذف شده و بدون درگیری dba و تنها با استفاده از چند دستور ساده، گپ ایجاد شده بین بانک اصلی و گارد برطرف می شود:
–in primary:
SQL> select max(sequence#),thread# from v$archived_log group by thread#;
MAX(SEQUENCE#) THREAD#
————– ———-
98 1
–in stb:
select max(sequence#),thread#,applied from gv$archived_log group by thread#,applied order by thread#;
MAX(SEQUENCE#) THREAD# APPLIED
————– ———- ———
98 1 YES
shutdown abort
–primary:
alter system switch logfile;
alter system switch logfile;
SQL> select max(sequence#),thread# from v$archived_log group by thread#;
MAX(SEQUENCE#) THREAD#
————– ———-
101 1
!rm -rf /u01/arch/1_10*
SQL> startup mount force;
ORACLE instance started.
Total System Global Area 3154116608 bytes
Fixed Size 3715784 bytes
Variable Size 956304696 bytes
Database Buffers 2181038080 bytes
Redo Buffers 13058048 bytes
Database mounted.
–in stb:
startup force;
SQL> alter database recover managed standby database;
ORA-00308: cannot open archived log ‘/u01/arch/1_100_916411681.dbf’
ORA-00308: cannot open archived log ‘/u01/arch/1_101_916411681.dbf’
startup force mount
rman target sys/sys@stb
RMAN> RECOVER DATABASE FROM SERVICE usef2 NOREDO ;
Starting recover at 05-JUL-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=93 device type=DISK
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service usef2
destination for restore of datafile 00001: /u02/oradata/usef2/datafile/system.257.916411579
channel ORA_DISK_1: restore complete, elapsed time: 00:01:06
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service usef2
destination for restore of datafile 00003: /u02/oradata/usef2/datafile/sysaux.256.916411533
channel ORA_DISK_1: restore complete, elapsed time: 00:01:05
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service usef2
destination for restore of datafile 00004: /u02/oradata/usef2/datafile/undotbs1.259.916411625
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: using network backup set from service usef2
destination for restore of datafile 00006: /u02/oradata/usef2/datafile/users.258.916411623
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
Finished recover at 05-JUL-16
STARTUP NOMOUNT force;
RMAN> RESTORE STANDBY CONTROLFILE FROM SERVICE usef2;
Starting restore at 05-JUL-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=362 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service usef2
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output file name=/u02/oradata/control01.ctl
Finished restore at 05-JUL-16
startup force;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
select max(sequence#),thread#,applied from gv$archived_log group by thread#,applied order by thread#;
MAX(SEQUENCE#) THREAD# APPLIED
————– ———- ———
108 1 YES
بازیابی دیتافایل بانک اصلی از استندبای
همانطور که می دانید در صورت استفاده از گارد، این قابلیت وجود دارد تا اگر دیتافایلی در بانک اصلی از بین رفته باشد، با دیتافایل موجود در سرور گارد، این فقدان را جبران کرد(البته بشرط سازگاری). برای انجام این کار در نسخه های قبلی، نیاز بود تا dba به صورت دستی و در سطح سیستم عامل این دیتافایل را از گارد به بانک اصلی و یا بالعکس کپی کند این کار در نسخه جدید، تنها با استفاده از یک دستور در محیط RMAN، قابل انجام می باشد.
SQL> create tablespace tbs1 datafile ‘/u01/test1.dbf’ size 10m;
SQL> !mv /u01/test1.dbf /u01/test2.dbf
rman target /
RMAN> RESTORE DATAFILE ‘/u01/test1.dbf’ FROM SERVICE stb;
Starting restore at 05-JUL-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=4 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service stb
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00005 to /u01/test1.dbf
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 05-JUL-16
البته می توان از شماره دیتافایل به جای نام آن استفاده کرد:
RMAN> RESTORE DATAFILE 5 FROM SERVICE stb;
Transport Database روی بستر شبکه
همانطور که می دانید برای انجامtransport در نسخه های قبلی، قسمت data pump به صورت دستی و در دو مرحله توسط dba انجام می شد که در این نسخه، امکان انجام این کار در یک مرحله فراهم شد:
1. در ابتدا، tablespaceهای غیر سیستمی را در حالت read only قرار می دهیم:
source> select name from v$datafile;
/u01/oracle/oradata/TEST/datafile/o1_mf_system_d89lvp27_.dbf
/u01/oracle/oradata/TEST/datafile/o1_mf_sysaux_d89ltlvp_.dbf
/u01/oracle/oradata/TEST/datafile/o1_mf_undotbs1_d89lx4f9_.dbf
/u01/oracle/oradata/TEST/datafile/USEF_TBS1.dbf
source> select name from v$tablespace;
SYSAUX
SYSTEM
UNDOTBS1
USEF_TBS
TEMP
source> alter tablespace USEF_TBS read only;
2. در مرحله دوم، باید دیتافایلهای مربوط به این tablespace را به سرور مقصد فرستاد:
source> scp -r /u01/oracle/oradata/TEST/datafile/USEF_TBS1.dbf 10.22.136.6:/u01/oracle/oradata
3. برای انجام مرحله impdp، باید database linkای را بر روی بانک مقصد ایجاد کرد:
destination> create public database link source_dblink connect to usef identified by abc using ‘test’;
4. در این مرحله، با استفاده از database link ایجاد شده، می توان متاداده مربوط به tablespace مورد نظر و نیز داده های غیر سیستمی ذخیره شده در tablespace سیستمی را به بانک مقصد منتقل کرد:
destination> impdp ali/ali full=y network_link=source_dblink transportable=always transport_datafiles=’/u01/oracle/oradata/USEF_TBS1.dbf’
Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 – 64bit Production
Starting “ALI”.”SYS_IMPORT_FULL_01″: ali/******** full=y network_link=source_dblink transportable=always transport_datafiles=/u01/oracle/oradata/USEF_TBS1.dbf
Estimate in progress using BLOCKS method…
. . imported “ORDDATA”.”ORDDCM_DOCS_TRANSIENT” 9 rows
. . imported “WMSYS”.”E$HINT_TABLE$” 75 rows
. . imported “SYSTEM”.”SCHEDULER_PROGRAM_ARGS_TMP” 12 rows
. . imported “SYS”.”AMGT$DP$AUDTAB$TBS$FOR_EXPORT” 2 rows
- برای تست درستی کار، در بانک مقصد از تعداد و نام datafileها پرس و جویی می گیریم:
destination> select name from v$datafile;
+DATA02/USEF12C/DATAFILE/system.290.933943353
+DATA02/USEF12C/DATAFILE/sysaux.335.933943307
+DATA02/USEF12C/DATAFILE/undotbs1.282.933943399
/u01/oracle/oradata/USEF_TBS1.dbf
+DATA02/USEF12C/DATAFILE/users.289.933943397
- در نهایت باید tablespaceهای غیرسیستمی در بانک مبدا، به حالت read write تبدیل شود:
source> alter tablespace USEF_TBS read write;
جابجایی و تغییر نام انلاین یک دیتافایل
در نسخه های قبلی اوراکل، جابجایی و تغییر نام با کمک سیستم عامل و بصورت افلاین(در سطح دیتافایل) انجام می شد که در نسخه 12c با ارائه ویژگی جدید، این میزان از down time از بین رفته و عملیات توسط اوراکل قابل انجام است همچنین اوراکل با ارائه این ویژگی، امکان انتقال دیتافایل از محیط non-asm به asm و برعکس را هم فراهم خواهد ساخت. ویوی V$SESSION_LONGOPS، میزان پیشرفت انتقال را نشان دهد.
مثال:
SQL> ALTER DATABASE MOVE DATAFILE ‘+DATA01/USEF/36A71C1B64C22204E055000000000001/DATAFILE/pdb1.273.916221379’ to ‘/u01/oracle/pdb1’;
SQL> ALTER DATABASE MOVE DATAFILE ‘/u01/oracle/pdb1’ to ‘/u01/oracle/pdb2.dbf’;
SQL> ALTER DATABASE MOVE DATAFILE ‘/u01/oracle/pdb1’ to ‘+DATA01’;
READ ANY TABLE
مجوز read any table که از نسخه 12c اضافه شده است همانند select any table می باشد با این تفاوت که تنها امکان مشاهده را به کاربر می دهد و قابلیتهای اضافه مربوط به مجوز select را ندارد.
به طور مثال، مجوز Select any table، علاوه بر قابلیت رویت اطلاعات، قابلیتهای زیر را هم ممکن می ساخت به مثال زیر توجه کنید:
SQL> create user s identified by s;
SQL> create user r identified by r;
SQL> grant select any table,create session to s;
SQL> grant read any table,create session to r;
با ورود کاربر r به بانک، این کاربر نخواهد توانست به صورت select .. for update به جدول مورد نظرش دستیابی پیدا کند:
SQL> connect r/r
Connected.
SQL> select * from usef.us_tb for update;
ORA-01031: insufficient privileges
در صورتی که کاربر s، جدول را به صورت select .. for update مشاهده و lock می کند:
SQL> conn s/s
Connected.
SQL> select * from usef.us_tb for update;
A
———-
8
Data Redaction
در صورتی که بخواهیم قسمتی از اطلاعات یک جدول، برای تعدادی از کاربران مخفی و یا غیرواقعی نشان داده شود، می توانیم از ویژگی data redaction استفاده کنیم به این صورت که کاربر ابتدا پرس و جویی را اجرا می کند، عملیات redact بر روی داده مورد نظر انجام می شود و در نهایت کاربر مورد نظر، داده را به آن شکلی که از قبل تعریف شده است، می بیند.
این ویژگی می تواند در زمینه بانکی کاربرد داشته باشد به طور مثال افرادی که صلاحیت لازم را ندارند، تنها قادر به مشاهده چهار رقم آخر شماره حساب افراد باشند به طور مثال، شماره 5892101039821398 برای کاربر غیرمطمئن، به صورت ********1398 دیده شود.
data redaction بار چندانی را به سیستم تحمیل نمی کند و در زمان بکاپ گیری(RMAN)، export و replication نادیده گرفته خواهد می شود.
تبدیل داده با استفاده از این ویژگی، در سطوح مختلفی قابل انجام می باشد(با استفاده از پارامتر FUNCTION_TYPE) که در ادامه در مورد دو سطح Full و Partial مطالبی را خواهیم آورد.
منظور از redaction در سطح full، تبدیل کامل داده مورد نظر به یک مقدار خاص می باشد که بسته به نوع داده آن ستون، این مقدار قابل تعریف می باشد. به طور مثال، ستونی که نوع داده آن VARCHAR2 باشد، حاصل redact شده برابر با ‘ ‘ خواهد شد و اگر نوع داده آن NUMBER باشد، به صورت پیش فرض، عدد 0 به کاربر نشان داده می شود همچنین نوع داده DATE، مقدار 01-JAN-01 را به کاربر نشان می دهد.
البته این مقادیر پیش فرض، با استفاده از پروسیجر DBMS_REDACT.UPDATE_FULL_REDACTION_VALUES قابل تغییر می باشند.
در سطح Partial، این امکان وجود دارد تا قسمتی از داده به شکل واقعی به کاربر نشان داده شود.
5892101039821398 è********1398
قبل از ارائه یک مثال در این زمینه، توجه به نکات زیر می تواند موثر باشد:
- هرکاربری که مجوز EXEMPT REDACTION POLICY را داشته باشد، recation برای آن لحاظ نخواهد شد.
- این ویژگی برای کاربر sys و هر کاربری که dba role را دارا باشد، لحاظ نخواهدشد(یعنی این افراد همیشه داده واقعی را خواهند دید).
- کاربری که داده واقعی رانمی بیند،در زمان اجرایCREATE TABLE AS SELECT، مجوز EXEMPT DDLREDACTIONPOLICY را لازم دارد تا داده واقعی را درجدول جدید داشته باشد.
مثال اول: در این مثال خواهیم دید که کاربری به نام usef2، به دلیل redact شدن اطلاعات، نخواهد توانست مقدار واقعی کد حقوقی افراد را ببیند.
create user usef2 identified by usef2;
grant select any table to usef2;
grant create session to usef2;
با افزودن policy زیر، کاربر usef2 نخواهد توانست مقادیر ستون SALARY_CODE را از جدول PERSON ببیند:
connect usef/usef
exec DBMS_REDACT.drop_policy(object_name => ‘person’,policy_name => ‘us_pol’);
BEGIN
DBMS_REDACT.add_policy(object_schema => ‘USEF’
,object_name => ‘PERSON’
,policy_name => ‘us_pol’
,expression => ‘SYS_CONTEXT(”USERENV”,”SESSION_USER”) != ”USEF2”’
,column_name => ‘SALARY_CODE’
,function_type => dbms_redact.FULL);
END;
مثال دوم: حال قصد داریم تنها سه رقم اخر کد پرسنلی افراد، به کاربرانی که مجوز لازم را ندارند، نمایش داده شود و 6 رقم ابتدایی، با عدد 9 پر شود:
exec DBMS_REDACT.drop_policy(object_name => ‘person’,policy_name => ‘us_pol’);
begin
DBMS_REDACT.ADD_POLICY(
object_schema => ‘USEF’,
object_name => ‘PERSON’,
column_name => ‘PER_CODE’,
policy_name => ‘us_pol’,
function_type => DBMS_REDACT.PARTIAL,
function_parameters => ‘9,1,6’,
expression => ‘1=1’ );
END;
انچه کاربر usef2 خواهد دید:
connect usef2/usef2
select PER_CODE from USEF.PERSON where id=’2025823837′;
999999357
Privilege Analysis
اهدای حداقلی مجوزها به کاربران می تواند از دغدغه های یک dba برای ایجاد محیطی امن باشد حال اگر تعداد کاربران و به تبع آن، تعداد خواسته ها زیاد باشد، قصور dba چندان دور از انتظار نخواهد بود. در نسخه جدید اوراکل(12c)، ویژگی جدیدی به نام privilege analysis ارائه شد که می توان از طریق آن، مجوزهای مورد استفاده کاربران را مانیتور کرد و در صورت مشاهده مجوزهای اضافی برای یک کاربر، dba می تواند آن مجوزها را از آن کاربر بگیرد. این کار با استفاده از پکیج DBMS_PRIVLEGE_CAPTURE در سطوح مختلف(DATABASE، ROLE، CONTEXT و ROLE_AND_CONTEXT) قابل مدیریت می باشد. مراحل انجام کار، به این صورت می باشد:
- ابتدا با استفاده از پروسیجر create_capture یک privilege analysis ایجاد می شود:
–database level
exec DBMS_PRIVILEGE_CAPTURE.create_capture(name => ‘us_capture’,type => DBMS_PRIVILEGE_CAPTURE.g_database);
— CONTEXT level
exec DBMS_PRIVILEGE_CAPTURE.create_capture(name=> ‘us_capture’,type=> DBMS_PRIVILEGE_CAPTURE.g_context,condition=> ‘SYS_CONTEXT(”USERENV”, ”SESSION_USER”) = ”USEF2”’);
— ROLE level
exec DBMS_PRIVILEGE_CAPTURE.create_capture( name => ‘us_role’,type=>DBMS_PRIVILEGE_CAPTURE.g_role,roles=> role_name_list(‘DBA’,’RESOURCE’));
— ROLE and CONTEXT level
exec DBMS_PRIVILEGE_CAPTURE.create_capture( name=> ‘us_role_cont’,type=> DBMS_PRIVILEGE_CAPTURE.g_role_and_context, roles=> role_name_list(‘DBA’, ‘RESOURCE’),condition=> ‘SYS_CONTEXT(”USERENV”, ”SESSION_USER”) IN (”USEF”,”USEF2”)’);
- برای شروع مانیتورینگ، از پروسیجر enable_capture استفاده می شود:
exec DBMS_PRIVILEGE_CAPTURE.enable_capture(‘us_capture’);
- در صورتی که مانیتورینگ به قدر ضرورت انجام گرفته باشد، استفاده از disable_capture سبب پایان دادن به مانیتورینگ خواهد شد:
exec DBMS_PRIVILEGE_CAPTURE.disable_capture(‘us_capture’);
- برای دیدن خروجی، از پروسجر generate_result استفاده می شود:
exec DBMS_PRIVILEGE_CAPTURE.generate_result(‘us_capture’);
همچنین ویوی dba_used_privs، نتیجه مانیتورینگ را نشان می دهد:
select capture,username,used_role,sys_priv from dba_used_privs l where l.capture=’us_capture’;
- برای حذف اطلاعات مانیتورینگ انجام شده از drop_capture استفاده می شود:
exec DBMS_PRIVILEGE_CAPTURE.drop_capture(name => ‘us_capture’);
مثال:
در این مثال قصد داریم تا مجوزهای مورد استفاده توسط کاربری به نام usef2 را مانیتور کنیم با فرض فقدان علم از مجوزهای لازم usef2، در ابتدا به این کاربر، نقش dba را می دهیم :
create user usef2 identified by usef2;
grant dba to usef2;
exec SYS.DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(name => ‘usef_capture’,type => dbms_privilege_capture.g_role_and_context,roles => role_name_list (‘DBA’),condition => ‘SYS_CONTEXT (”USERENV”,”SESSION_USER”)=”USEF2”’);
exec DBMS_PRIVILEGE_CAPTURE.enable_capture(‘usef_capture’);
در ادامه به صورت تست، با کاربر usef2 وارد بانک شده، و دستوراتی را اجرا می کنیم:
SQL> connect usef2/usef2;
Connected.
SQL> drop table usef.person3;
Table dropped.
SQL> alter tablespace usef_tbs offline;
Tablespace altered.
SQL> alter tablespace usef_tbs online;
Tablespace altered.
SQL> create view v_u as select * from v$datafile;
ORA-01031: insufficient privileges
SQL> create view v_u as select * from user_tables;
View created.
در نهایت مانیتورینگ را متوقف کرده و نیجه مانیتورینگ را مرور خواهیم کرد:
exec DBMS_PRIVILEGE_CAPTURE.disable_capture(‘usef_capture’);
exec DBMS_PRIVILEGE_CAPTURE.generate_result(‘usef_capture’);
حال مجوزهای که کاربر usef2 برای کارهای انجام شده از آنها استفاده کرده است، به صورت زیر می باشد:
SQL> select capture,username,used_role,sys_priv from dba_used_privs l where l.capture=’usef_capture’;
| CAPTURE | USERNAME | USED_ROLE | SYS_PRIV |
| usef_capture | USEF2 | DBA | CREATE VIEW |
| usef_capture | USEF2 | EM_EXPRESS_ALL | ALTER TABLESPACE |
| usef_capture | USEF2 | OLAP_DBA | DROP ANY TABLE |
| usef_capture | USEF2 | EM_EXPRESS_BASIC | CREATE SESSION |
همچنین است ویوی دیگری:
SQL> select username,sys_priv from dba_used_sysprivs l where l.username=’USEF2′;
| USERNAME | SYS_PRIV |
| USEF2 | ALTER TABLESPACE |
| USEF2 | DROP ANY TABLE |
| USEF2 | CREATE VIEW |
| USEF2 | CREATE SESSION |
نکته: ویوی dba_used_objprivs_path در این زمینه مفید می باشد.
RESOURCE ROLE و UNLIMITED TABLESPACE
در نسخه 11g زمانی که به کاربری RESOURCE role داده می شد، همراه با آن، مجوز unlimited tablespace هم وجود داشت و کاربر قادر بود حتی در tablespace system هم اطلاعاتی را ذخیره کند. در نسخه 12c، مجوز unlimited tablespace از این role گرفته شده است. مثال زیر را ببینید:
نسخه 11g:
SQL> create user usef identified by usef;
SQL> grant connect,resource to usef;
connect usef/usef
SQL> create table us_t tablespace system as select * from user_objects;
Table created.
نسخه 12c:
SQL> create user usef identified by usef;
SQL> grant connect,resource to usef;
connect usef/usef
SQL> create table us_t tablespace system as select * from user_objects;
ORA-01950: no privileges on tablespace ‘SYSTEM’
Information Lifecycle Management (ILM)
ویژگی ILM، سیاستی برای کاهش فضای مصرفی و بهبود کارایی می باشد که با فشرده سازی قسمتهایی از سگمنت که کمتر مورد استفاده و دستیابی قرار می گیرند و نیز انتقال سگمنتهای کم طرفدار به دیسک با هزینه کمتر، به این هدف دست می یابد. این کار با تقسیم داده به سه نوع hot، warm و cold انجام می شود به این صورت که، داده هایی که اخیرا وارد جدول شده اند و دستیابی به آنها نسبتا زیاد است، در دسته hot قرار می گیرند و دسته warm، داده های با اولویت کمتر را شامل می شود و در نهایت داده هایی که بسیار کم مورد دستیابی قرار می گیرند، در دسته cold قرار خواهند گرفت. شکل زیر این نکته را به روشنی نشان خواهد داد(داده های موجود در دسته hot در دیسک SSD قرار گرفته اند که بسیار پرهزینه تر و البته با کیفیت ترند):
دو ویژگی اصلی ILM در HEAT_MAP و ADO خلاصه می شود که در ادامه هر یک را به اختصار مورد بررسی قرار خواهیم داد.
HEAT MAP
برای پیاده سازی استراتژی ILM، نیاز است تا ویژگی Heat Map را فعال کرد تا از میزان دستیابی و اصلاح segmentها آماری در دست باشد تا از طریق آن، داده های پراستفاده از داده هایی که کمتر مورد استفاده قرار می گیرند، قابل تفکیک باشند. این ویژگی در سطح session و system قابل تنظیم می باشد و پارامتر مربوط به آن، HEAT_MAP می باشد. به مثال زیر توجه فرمایید:
SQL> alter system set heat_map=ON scope=both;
SQL> create table us_ilm as select * from v$datafile;
SQL> insert into us_ilm select * from v$datafile;
7 rows inserted
SQL> commit;
Commit complete
بعد از ایجاد جدول و درج داده در آن، با نگاهی به ویوی V$HEAT_MAP_SEGMENT، متوجه اخرین تغییرات این جدول خواهیم شد:
SELECT SUBSTR(OBJECT_NAME,1,20), SUBSTR(SUBOBJECT_NAME,1,20), TRACK_TIME, SEGMENT_WRITE, FULL_SCAN FROM V$HEAT_MAP_SEGMENT;
| SUBSTR(OBJECT_NAME,1,20) | SUBSTR(SUBOBJECT_NAME,1,20) | TRACK_TIME | SEGMENT_WRITE | FULL_SCAN |
| US_ILM | 1/30/2017 10:40:44 AM | YES | NO |
همانطور که خروجی پرس وجوی قبلی نشان می دهد، هنوز جدول مورد نظر، full table scan نشده است به همین جهت، دستور زیر را اجرا می کنیم:
select * from us_ilm;
پرس و جوی زیر به ما خواهد گفت که این جدول، به صورت full table scan مورد دستیابی قرار گرفته است:
SELECT SUBSTR(OBJECT_NAME,1,20), SUBSTR(SUBOBJECT_NAME,1,20), TRACK_TIME, SEGMENT_WRITE, FULL_SCAN, LOOKUP_SCAN FROM V$HEAT_MAP_SEGMENT;
| SUBSTR(OBJECT_NAME,1,20) | SUBSTR(SUBOBJECT_NAME,1,20) | TRACK_TIME | SEGMENT_WRITE | FULL_SCAN |
| US_ILM | 1/30/2017 10:43:55 AM | YES | YES |
در نتیجه باید گفت که با فعالسازی این ویژگی(HEAT MAP)، اطلاعات دقیقی را در مورد زمان اصلاح و نیز کیفیت دستیابی به سگمنتها در اختیار خواهیم داشت این آمارها برای ویژگی ADO که در ادامه مورد بررسی قرار می گیرد، ضروری می باشد.
برای غیرفعالسازی heat map و حذف آمارهای مربوط به آن، از دستورات زیر استفاده می شود:
ALTER SYSTEM SET HEAT_MAP = OFF;
exec DBMS_ILM_ADMIN.CLEAR_HEAT_MAP_ALL;
Automatic Data Optimization (ADO)
این ویژگی امکان جابجایی و فشرده سازی اشیاها را متناسب با آمارهای heat map فراهم می سازد. سیاستهای مربوط به ILM ADO را می توان در موارد زیر خلاصه کرد:
1. فشرده سازی: داده در چه صورتی و به چه مدلی فشرده شود(COMPRESSION TIERING)
2. انتقال: شی در چه صورتی و به کدام tablespace منتقل شود(STORAGE TIERING)
همچنین این سیاستها در سطوح زیر قابل اعمال می باشند:
Tablespace: سیاستهای ADO بر روی همه جداول موجود در یک tablespace اعمال خواهد شد.
مثال: اشیایی که در us_tbs موجود هستند در صورت عدم تغییر به مدت 6 ماه، فشرده خواهند شد.
ALTER TABLESPACE us_tbs DEFAULT ROW STORE COMPRESS BASIC SEGMENT AFTER 6 MONTHS OF NO MODIFICATION;
Segment : سیاستهای ADO بر روی سگمنت مشخص شده اعمال خواهد شد.
مثال: اگر جدول tbl_us بعد از 6 ماه هیچ تغییری نکند، فشرده خواهد شد.
ALTER TABLE tbl_us ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH SEGMENT AFTER 6 MONTHS OF NO MODIFICATION;
Row: سیاستهای ADO بر روی سطرهای مشخص شده در یک جدول اعمال خواهد شد.
ALTER TABLE part_us MODIFY PARTITION part1 ILM ADD POLICY ROW STORE COMPRESS ADVANCED ROW AFTER 30 DAYS OF NO MODIFICATION;
همچنین سه پروسیجر زیر برای مدیریت ILM مورد استفاده قرار می گیرند:
1. CUSTOMIZE_ILM: برای تغییر پارامترها و سیاستهای ILM، از این پروسیجر استفاده می شود. برای مثال، برای تغییر حد و آستانه tablespace از نظر درصد استفاده، می توان از این پروسیجر استفاده کرد:
exec dbms_ilm_admin.customize_ilm(parameter => dbms_ilm_admin.TBS_PERCENT_FREE,value => 25);
exec dbms_ilm_admin.customize_ilm(parameter => dbms_ilm_admin.TBS_PERCENT_USED,value => 75);
دستور بالا مشخص می کند که اگر درصد فضای استفاده شده توسط tablespace به 75 برسد، سیاستهای وضع شده، اعمال خواهد شد.برای مشاهده لیست کامل پارامترها، دستور زیر قابل استفاده می باشد:
col name FOR a18
SELECT * FROM DBA_ILMPARAMETERS;
NAME VALUE
—————— ———-
ENABLED 1
RETENTION TIME 30
JOB LIMIT 2
EXECUTION MODE 2
EXECUTION INTERVAL 1
TBS PERCENT USED 75
TBS PERCENT FREE 25
POLICY TIME 0
2. PREVIEW_ILM: سیاستهای وضع شده مربوط به ILM مورد بررسی قرار می گیرند تا در صورتی که شرایط قید شده به وجود آمد، task مربوط به آن اجرا شود.
3. dbms_ilm.EXECUTE_ILM: task ADO ایجاد شده در مرحله قبلی، اجرا خواهد شد.
در ادامه، فشرده سازی و جابجایی هر یک در مثالی جداگانه مورد بررسی قرار می گیرند:
STORAGE TIERING
مثالی که در ادامه خواهد آمد، نشان خواهد داد که چگونه با استراتژی ILM، جدولی که مدتها عملیات DML بر روی آن انجام نشده است، از tablespace با دیسک بهتر به tablespace ای دیگر با دیسک کم هزینه تری منتقل می شود.
- ابتدا دو tablespace ایجاد می کنیم که یکی بر روی دیسک گران قیمت تری قرار گرفته است:
create tablespace expensive_disk datafile size 5m ;
create tablespace INEXPENSIVE_disk datafile size 100m ;
همچنین جدولی را بر روی expensive_disk ایجاد می کنیم و با درج اطلاعاتی آن را به حد استانه tablespace می رسانیم(چگونگی تعیین و تغییر حد استانه، قبلا ذکر شده است):
create table us_storage tablespace expensive_disk as select 1 as ll ,rownum “ss”,level “dd”,Length(rownum) “gg” from dual connect by level <1;
insert into us_storage select 1 as ll ,rownum “ss”,level “dd”,Length(rownum) “gg” from dual connect by level <100000;
commit;
- با دستور زیر، سیاستی را وضع می کنیم که اگر ADO اجرا شودو tablespace expensive_disk به حد آستانه رسیده باشد، جدول مورد نظر از tablespace جاری به INEXPENSIVE_disk منتقل شود:
select tablespace_name from dba_segments where segment_name=’US_STORAGE’;
EXPENSIVE_DISK
alter table us_storage ilm add policy tier to INEXPENSIVE_disk;
- همچنین با دستور زیر، سیاستهای وضع شده ADO برای کاربر جاری را مورد بررسی قرار می دهیم که بعد از بازبینی، درصورت لزوم، taskای ایجاد می شود:
declare
v_task_id number:=0;
BEGIN
dbms_ilm.preview_ilm(task_id => v_task_id,ilm_scope => dbms_ilm.SCOPE_SCHEMA);
dbms_output.put_line(‘task id = ‘ || v_task_id);
if v_task_id is null then
dbms_output.put_line(‘task id is null’);
end if;
END;
/
task ایجاد شده را می توان با دستور زیر مشاهده کرد:
select task_id, policy_name, object_owner, object_name, selected_for_execution from user_ilmevaluationdetails order by task_id desc ;
| TASK_ID | POLICY_NAME | OBJECT_OWNER | OBJECT_NAME | SELECTED_FOR_EXECUTION |
| 3 | P2 | USEF | US_STORAGE | SELECTED FOR EXECUTION |
همچنین است دستور زیر:
select task_id, state, to_char(creation_time,’dd-mon-yyyy hh24:mi:ss’) creation_time from user_ilmtasks where task_id=3;
| TASK_ID | STATE | CREATION_TIME |
| 3 | INACTIVE | 30-jan-2017 13:27:50 |
- درمرحله آخر task ایجادشده را اجرا می کنیم:
exec dbms_ilm.execute_ilm_task(task_id => 3,execution_mode => dbms_ilm.ILM_EXECUTION_ONLINE,execution_schedule => dbms_ilm.SCHEDULE_IMMEDIATE);
PL/SQL procedure successfully completed
با نگاهی دوباره به محل ذخیره شدن جدول us_storage، خواهیم دید که این جدول به tablespace جدید منتقل شده است:
select tablespace_name from dba_segments where segment_name=’US_STORAGE’;
INEXPENSIVE_DISK
COMPRESSION TIERING
همانطور که آورده شد، سیاستهای ADO در سطوح مختلفی قابل انجام است(tablespace، table و row) در ادامه مثالی را در مورد سیاست فشرده سازی ADO در سطح سطر خواهیم دید:
- با دستور زیر سیاستی را بر روی جدول مورد نظر وضع خواهیم کرد که اگر بیشتر از 3 روز بر روی رکوردهای آن DMLای صورت نگیرد، آن رکوردها، فشرده خواهند شد:
Alter table person2 Ilm add policy Row store compress advanced row after 3 days of no modification;
حال برای شبیه سازی و تنها برای نمایش چگونگی فشرده سازی در این مثال، زمان استارت heat_map را به 5 روز قبل تغییر می دهیم تا اطلاعات روزهای قبل را هم معتبر لحاظ کرده باشیم:
EXEC dbms_ilm_admin.set_heat_map_start(start_date => SYSDATE – 5);
- همانند مثال قبلی، سیاستهای ADO را مورد بررسی قرار می دهیم و در صورت نیاز، اجرا می کنیم:
declare
v_task_id number:=20;
BEGIN
dbms_ilm.preview_ilm(task_id => v_task_id,ilm_scope => dbms_ilm.SCOPE_SCHEMA);
dbms_output.put_line(‘task id = ‘ || v_task_id);
if v_task_id is null then
dbms_output.put_line(‘task id is null’);
end if;
/
END;
دستور زیر، نتیجه اجرای بلاک قبلی را نشان خواهد داد:
select task_id, policy_name, object_owner, object_name, selected_for_execution from user_ilmevaluationdetails order by task_id desc ;
| TASK_ID | POLICY_NAME | OBJECT_OWNER | OBJECT_NAME | SELECTED_FOR_EXECUTION |
| 6 | P3 | USEF | PERSON2 | SELECTED FOR EXECUTION |
- خروجی دستور بالا نشان می دهد که جدول person2، شرایط لازم را برای اجرای ADO دارد پس با دستور زیر، task ایجاد شده را اجرا می کنیم تا در صورت لزوم، فشرده سازی را انجام دهد:
exec dbms_ilm.execute_ilm_task(task_id => 6,execution_mode => dbms_ilm.ILM_EXECUTION_ONLINE,execution_schedule => dbms_ilm.SCHEDULE_IMMEDIATE);
PL/SQL procedure successfully completed
نتیجه فشرده سازی را می توان در جدول COMPRESSION_STAT$ مشاهده کرد.
با استفاده از ADO، انواع مختلفی از فشرده سازی قابل انجام می باشد، که در زیر نام آنها را خواهیم دید:
ROW STORE COMPRESS [BASIC]
ROW STORE COMPRESS ADVANCED
COLUMN STORE COMPRESS FOR QUERY LOW / HIGH
COLUMN STORE COMPRESS FOR ARCHIVE LOW / HIGH
برای نمایش همه policyها، از ویوهای DBA_ILMPOLICIES و DBA_ILMDATAMOVEMENTPOLICIES استفاده می شود.همچنین برای فعال و غیرفعالسازی همه policyهای یک شی، از دستورات زیر استفاده می شود:
ALTER TABLE tab1 ILM ENABLE_ALL;
ALTER TABLE tab1 ILM DISABLE_ALL;
برای حذف این policyها، می توان از دستور زیر استفاده کرد:
ALTER TABLE tab1 ILM DELETE_ALL;
غیرفعال سازی logging بهنگام impdp
در صورتی که قصد داشته باشیم اطلاعات dumpfileای را با سرعت بیشتری به بانک وارد کنیم از نسخه 12c این امکان وجود دارد تا logging را در هنگام import غیرفعال کنیم:
impdp directory=usef dumpfile=c.dmp schemas=usef TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y
Import: Release 12.1.0.2.0 – Production on Tue Jul 5 15:02:28 2016
. . imported “USEF”.”COM_LOC” 533.490 MB 226333 rows
در صورت استفاده از data guard در این محیط(در بانکی که ورود اطلاعات در آنجا انجام می شود)، اطلاعات import شده به سمت data guard منتقل نخواهد شد و با رجوع به این جدول در سمت data guard، با خطای زیر مواجه می شویم:
select count(*) from usef.com_loc
ORA-01578: ORACLE data block corrupted (file # 6, block # 555)
ORA-01110: data file 6: ‘/u02/oradata/usef2/datafile/users.258.916411623’
ORA-26040: Data block was loaded using the NOLOGGING option
البته اگر بانک در حالت force logging باشد، امکان استفاده از چنین ویژگی وجود ندارد(معمولا قبل از راه اندازی data guard، اوراکل تاکید دارد تا این گزینه فعال شود).
این ویژگی در سطح ایندکس هم قابل استفاده می باشد:
TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y:INDEX
پارامتر views_as_tables در data pump
با این ویژگی، امکان گرفتن دامپ از ویو هم مهیا می شود و در نهایت می توان این ویو را در بانک مقصد به صورت جدول وارد(import) کرد.
expdp usef/abc@pdb1 directory=usef dumpfile=test.dmp views_as_tables=usef_view1
Export: Release 12.1.0.2.0 – Production on Sat Jul 2 10:41:26 2016
Starting “USEF”.”SYS_EXPORT_TABLE_01″: usef/********@pdb1 directory=usef dumpfile=test.dmp views_as_tables=usef_view1
Total estimation using BLOCKS method: 16 KB
. . exported “USEF”.”USEF_VIEW1″ 163.3 KB 5086 rows
Master table “USEF”.”SYS_EXPORT_TABLE_01″ successfully loaded/unloaded
Job “USEF”.”SYS_EXPORT_TABLE_01″ successfully completed at Sat Jul 2 10:41:38 2016 elapsed 0 00:00:11
برگرداندن ویو به صورت جدول در بانک مقصد:
impdp usef/abc@pdb1 directory=usef dumpfile=test.dmp views_as_tables=usef_view1
Import: Release 12.1.0.2.0 – Production on Sun Jul 3 09:40:23 2016
Starting “USEF”.”SYS_IMPORT_TABLE_01″: usef/********@pdb1 directory=usef dumpfile=test.dmp views_as_tables=usef_view1
. . imported “USEF”.”USEF_VIEW1″ 163.3 KB 5086 rows
Job “USEF”.”SYS_IMPORT_TABLE_01″ successfully completed at Sun Jul 3 09:40:25 2016 elapsed 0 00:00:01
اعمال محدودیت برای اندازه PGA
با استفاده از پارامتر PGA_AGGREGATE_LIMIT، این امکان وجود دارد تا برای حداکثر میزان حافظه مصرفی هر session نظر داد:
SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=2G;
در صورتی که sessionی خواستار فضای بیشتری از مقدار مشخص شده باشد، با خطای زیر، مواجه و در نهایت کشته می شود:
ORA-00028: your session has been killed . ORA-04036
TRUNCATE TABLE CASCADE
در نسخه های قبلی، امکان truncate جدول master وجود نداشت:
truncate table usef.tbl1;
ORA-02266: unique/primary keys in table referenced by enabled foreign keys
با ویژگی جدید، این امکان به وجود آمد:
truncate table usef.tbl1 cascade;
select * from tbl2;
no row selected.
SESSION LEVEL SEQUENCES
از دیگر ویژگی های اوراکل در نسخه 12c، ایجاد sequence ای می باشد که در سطح session مقدار می گیرد.
CREATE SEQUENCE seq_new START WITH 1 INCREMENT BY 1 SESSION;
session 1:
select seq_new.nextval from dual;
1
session 2:
select seq_new.nextval from dual;
1
برای تغییر حالت این sequence از سطح session به سطح global، باید از دستور زیر استفاده کرد:
alter sequence seq_new global;
alter sequence seq_new session;
DDL LOGGING
پارامتر enable_ddl_logging که از اوراکل 12c اضافه شد قابلیت لاگ گیری از دستورات DDLای را در فایلی مجزا ارائه می دهد دستورات DDLای از قبیل:
CREATE|ALTER|DROP|TRUNCATE TABLE
DROP USER
CREATE|ALTER|DROP PACKAGE|FUNCTION|VIEW|SYNONYM|SEQUENCE
مثال:
SQL> create table aaa(a number(8));
cat /u01/oracle/diag/rdbms/usef2/usef2/log/ddl/log.xml
<msg time=’2016-07-09T13:03:23.258+04:30′ org_id=’oracle’ comp_id=’rdbms’
msg_id=’opiexe:4383:2946163730′ type=’UNKNOWN’ group=’diag_adl’
level=’16’ host_id=’localhost.localdomain’ host_addr=’::1′>
<txt>create table aaa(a number(8))
</txt>
</msg>
TEMPORARY UNDO
از نسخه های قبلی اوراکل برای مدیریت undo segment مربوط به global temporary table از undo tablespace پیش فرض بانک استفاده می شود این نکته سبب می شود تا برای انجام عملیات DMLای بر روی global temporary table، الزاما باید بانک در وضیعت read write قرار بگیرد این در صورتی است که اطلاعات این جداول معمولا در زمان ریکاوری کاربردی ندارند و نیازی به بازیابی آنها نخواهیم داشت به همین دلیل، در نسخه جدید اوراکل مفهومی به نام temporary undo ارائه شد که استفاده از آن سبب می شود تا undo segment مربوط به global temporary table، در temporary tablespace ذخیره شود.
این اتفاق دو ثمره خواهد داشت؛ اول اینکه، از global temporary table می توان در حالت open read only هم استفاده کرد و دوم اینکه، Redo و undo کمتری ایجاد می شود و در نتیجه علاوه بر بهینه تر شدن کارایی، در فضای مصرفی دیسک برای بانک و backup، صرفه جویی خواهد شد.
برای استفاده از این ویژگی، می توان پارامتر temp_undo_enabled را در سطح session و یا instance فعال کرد.
SQL> alter session set temp_undo_enabled=true;
در ادامه نشان خواهیم داد که چگونه این ویژگی امکان انجام عملیات DML را در محیط Physical standby فراهم می کند.
–in prim:
SQL> conn usef/abc
Connected.
SQL> alter system set temp_undo_enabled=true scope=both;
SQL> create global temporary table US_GTT on commit preserve rows as select * from v$datafile;
حال بر روی Physical standby، عملیات درج قابل انجام است:
–in stb
SQL> conn usef/abc
Connected.
SQL> alter system set temp_undo_enabled=true scope=both;
SQL> insert into US_GTT select * from v$datafile;
4 rows created.
ستون نامریی
با این ویژگی می توان ستونی را در جدول قرار داد که به صورت پیش فرض قابل مشاهده نباشد و دسترسی به آن، تنها با ذکر نام آن ستون ممکن باشد. ستونی با چنین ویژگی را حتی با describe کردن جدول هم نمی توان مشاهده کرد:
create table usef.tbl_invis(id number,name varchar2(9),sal number INVISIBLE);
SQL> desc usef.tbl_invis;
Name Null? Type
—————————————– ——– —————————-
ID NUMBER
NAME VARCHAR2(9)
البته می توان از SET COLINVISIBLE ON کمک گرفت تا این ستون با desc قابل مشاهده باشد. در زمان درج اطلاعات به این جدول، تنها با ذکر نام ستون، می توان اطلاعات را به آن اضافه کرد:
SQL> insert into usef.tbl_invis values(1,’usef’,2500);
ORA-00913: too many values
SQL> insert into usef.tbl_invis(id,name,sal) values(1,’usef’,2500);
1 row created.
SQL> commit;
Commit complete.
همچنین در هنگام گرفتن پرس و جو، باید ستون مربوطه به صراحت ذکر شود تا در خروجی قابل رویت باشد:
SQL> select * from usef.tbl_invis;
ID NAME
———- ———
1 usef
1 usef
SQL> select id,name,sal from usef.tbl_invis;
ID NAME SAL
———- ——— ———-
1 usef
1 usef 2500
برای اینکه ستون نامرئی از حالت INVISIBLE خارج شود، می توان از دستور زیر استفاده کرد:
SQL> ALTER TABLE usef.tbl_invis MODIFY (sal VISIBLE);
افزایش ظرفیت VARCHAR2
با تنظیم پارامتر max_string_size به EXTENDED می توانیم ظرفیت VARCHAR2 و NVARCHAR2 را از 4000 به 32767 افزایش دهیم(البته با ایجاد محدودیتهایی) مقدار دیگر این پارامتر STANDARD می باشد که اندازه این نوع از انواع داده ها را به مقدار آنها در نسخه های قبلی تنظیم می کند برای استفاده از ویژگی جدید باید دستورات زیر را اجرا کرد:
SQL> startup upgrade
SQL>@?/rdbms/admin/utl32k.sql
DOC> Perform a “SHUTDOWN ABORT” and
DOC> restart using UPGRADE.
no rows selected
DOC> The following statement will cause an “ORA-01722: invalid number”
DOC> error if the database does not have compatible >= 12.0.0
DOC> Set compatible >= 12.0.0 and retry.
Package altered.
Package altered.
SQL> alter system set max_string_size=EXTENDED;
SQL> create table usef_tbl1(a varchar2(30000));
ایندکسهای نامرئی
با این ویژگی، می توان بر روی ستونهای مشخص، انواع مختلفی از ایندکسها را ایجاد کرد که تنها یکی از آنها مرئی(visible) باشد و بقیه باید نامرئی(invisible) باشند در صورتی که در نسخه های قبلی اوراکل، به هنگام ایجاد ایندکس دوم بر روی ستونهای مشابه، با خطای ORA-01408 مواجه می شدیم.
برای استفاده از ایندکسهای invisible، باید پارامتر optimizer_use_invisible_indexes برابر با true باشد البته اگر این پارامتر برابر با false باشد(مقدار پیش فرض)، optimizer در زمان ایجاد plan، به ایندکسهای نامرئی توجهی نخواهد کرد.
استفاده از این قابلیت(چند ایندکس روی یک ستون)، تست و تغییر بین انواع مختلف از ایندکسها، آسان تر مدیریت خواهد شد هر چند که نگهداری آن هزینه دارد. به مثال زیر توجه کنید:
SQL> create bitmap index usef.indx3 on usef.tbl1(name) INVISIBLE;
SQL> create index usef.indx2 on usef.tbl1(name);
SQL> create index usef.indx4 on usef.tbl1(name) reverse INVISIBLE;
alter system set optimizer_use_invisible_indexes=true;
SQL> set autotrace traceonly explain statistics
select * from usef.tbl1;
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
————————————————————————————–
| 0 | SELECT STATEMENT | | 4 | 232 | 1 (0)| 00:00:01 |
| 1 | BITMAP CONVERSION TO ROWIDS | | 4 | 232 | 1 (0)| 00:00:01 |
| 2 | BITMAP INDEX FAST FULL SCAN| INDX3 | | | | |
——————————————————————————–
همچنین می توان با دستورات زیر، در مورد مرئی یا نامرئی بودن ایندکسها نظر داد:
alter index usef.indx2 invisible;
alter index usef.indx3 visible;
Online DDL
در نسخه های قبلی، زمانی که عملیات DML بر روی جدولی انجام می شد، امکان انجام بعضی از کارهای DDLای وجود نداشت از قبیل:
ALTER INDEX UNUSABLE
SET COLUMN UNUSED
DROP INDEX
DROP CONSTRAINT
در نسخه 12c، این امکان به وجود آمد تا با استفاده از عبارت online در حین انجام این عملیات، عملیات با خطا متوقف نشود(البته همراه با محدودیتهایی):
in 11g:
delete usef.tbl1;
drop index usef.indx2;
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
in 12c:
delete usef.tbl1;
drop index usef.indx2 ONLINE;
wait….
همچنین است موارد زیر:
alter index usef.indx4 unusable online;
alter table TBL1 set unused column b online;
alter table TBL1 drop constraint BB online;
Full Database Caching
در نسخه های قبل از 12c، این قابلیت وجود داشت تا سگمنتهای خاصی که به کررات مورد استفاده قرار می گیرند را برای ماندن بیشتر در حافظه، انتخاب کنیم این کار در صورت انتخاب درست، می توانست سبب بهتر شدن کلی کارایی شود. حال در نسخه 12c این قابلیت به وجود امد تا این اتفاق در سطح کل بانک اطلاعاتی قابل انجام باشد(البته در صورت امکان) شاید در زمان دسترسی به حافظه کافی، این قابلیت کارا و موثر باشد.
SQL> startup mount force;
SQL> ALTER DATABASE FORCE FULL DATABASE CACHING;
Database altered.
برای بررسی اینکه بانک اطلاعاتی در این حالت قرار دارد یا نه، می توان از دستور زیر استفاده کرد:
SQL> SELECT FORCE_FULL_DB_CACHING FROM V$DATABASE;
FOR
—
YES
حال برای غیرفعال سازی این ویژگی، می توان از دستور زیر استفاده کرد:
SQL> startup mount force;
SQL> alter database no force full database caching;
Database altered.
Identity Column
در صورتی که بخواهیم ستونی از یک جدول به صورت خودکار مقدار بگیرد، این ویژگی موثر خواهد بود. به طور مثال، ستون کلید اصلی را می توان با استفاده از این قابلیت، مقدار دهی کرد. در نسخه های قبلی این کار با استفاده از sequence هم قابل انجام بود. البته اوراکل این ویژگی را هم با استفاده از sequence مدیریت می کند و با استفاده از این ویژگی، sequnceای را ایجاد خواهد کرد. مثال زیر این نکته را به شکل مبسوط تری بیان خواهد کرد:
CREATE TABLE us_person(
id NUMBER GENERATED AS IDENTITY,
name varchar(333),
last_name varchar(333));
بلافاصله بعد از ایجاد جدول، با رجوع به user_sequences خواهیم دید که sequence جدیدی برای مدیریت این موضوع ایجاد شده است:
select sequence_name from user_sequences;
ISEQ$$_93073
البته در انتهای نام sequence، شماره جدول مورد نظر وجود دارد:
select sequence_name from user_sequences l where l.sequence_name like ‘%’||(select object_id from dba_objects where object_name=’US_PERSON’);
به صورت تست، مقادیری را وارد جدول می کنیم تا رفتار این فیلد را مشاهده کنیم:
insert into us_person(name,last_name) values(‘vahid’,’usefzadeh’);
commit;
select * from us_person;
1 vahid usefzadeh
همچنین می توان محدوده و مقدار ابتدایی و انتهایی را برای فیلد مورد نظر مشخص کرد:
id number(9) GENERATED ALWAYS AS IDENTITY START WITH 50 INCREMENT BY 10 MAXVALUE 9999
پروسس LREG
LREG(Listener Registration Process) نام پروسس جدیدی است که در نسخه 12c به وجود آمد و مسئولیت رجیستر کردن لیسنر را بر عهده دارد. این کار در نسخه های قبلی به عهده PMON بود. با دستور زیر، پروسس مورد نظر را در لینوکس خواهیم دید:
ps -eaf|grep lreg|grep -v grep
oracle 4069 1 0 2016 ? 00:07:59 asm_lreg_+ASM
oracle 12382 1 0 10:09 ? 00:00:01 ora_lreg_usef12c
In-Archive Database
با این ویژگی می توان رکوردهای جدول را به دو سطح فعال(active) و غیرفعال(non-active) تقسیم کرد که رکوردهای غیرفعال، از دید کاربر پنهان خواهند بود. این کار برای زمانی کاربرد دارد که قسمتی از یک جدول بسیار بزرگ، به ندرت مورد دستیابی قرار می گیرد. با فعال سازی این ویژگی در سطح جدولی خاص، ستونی نامریی به نام ORA_ARCHIVE_STATE به جدول اضافه می شود که وضیعت هر رکورد را از نظر فعال یا غیر فعال بودن مشخص می کند.
به صورت پیش فرض، با فعال سازی این ویژگی برای یک جدول، هیچ رکوردی غیرفعال نخواهد شد به عبارتی دیگر،ORA_ARCHIVE_STATE=0 می باشد که برای فعال سازی archiving رکوردها، باید این مقدار را به یک مقدار غیر صفر تغییر داد.
به مثال زیر توجه فرمایید:
SQL> alter table usef.tbl6 row archival;
SQL> col ORA_ARCHIVE_STATE format a10
SQL> select ORA_ARCHIVE_STATE,a,b from usef.tbl6;
ORA_ARCHIV A B
———- ———- ———-
0 10 5
0 9 1
SQL> update usef.tbl6 l set ORA_ARCHIVE_STATE = DBMS_ILM.ARCHIVESTATENAME(1) where A=10 ;
خروجی دستور زیر نشان می دهد که دستور بالا سبب پنهان سازی رکورد مورد نظر از دید کاربر شده است:
SQL> select ORA_ARCHIVE_STATE,a,b from usef.tbl6;
ORA_ARCHIV A B
———- ———- ———-
0 9 1
به صورت پیش فرض رکوردهای غیرفعال در خروجی پرس و جو دیده نمی شوند که می توان در سطح یک session این امکان را فراهم کرد تا این رکوردها هم قابل رویت باشند:
SQL> alter session set ROW ARCHIVAL VISIBILITY = ALL;
برای غیرفعالسازی این ویژگی هم از دستور زیر استفاده می شود:
SQL> alter table usef.tbl6 no row archival;
همچنین می توان جدول را از ابتدا به صورت row archival ایجاد کرد:
create table us_arc (id number(9), name varchar2(10)) row archival;
مثالی دیگر: فرض کنید 800,000 رکورد را از جدول person که شامل 2,200,000 رکورد می باشد با این روش به حالت غیرفعال تبدیل می کنیم:
SQL> alter table usef.person row archival;
Table altered.
SQL> update usef.person set ORA_ARCHIVE_STATE = DBMS_ILM.ARCHIVESTATENAME(1) where to_char(to_date(enrolment_date,’YYYY/MM/DD’,’nls_calendar=persian’),’YYYY’,’nls_calendar=persian’) in (select to_char(to_date(enrolment_date,’YYYY/MM/DD’,’nls_calendar=persian’),’YYYY’,’nls_calendar=persian’) from usef.person where to_char(to_date(enrolment_date,’YYYY/MM/DD’,’nls_calendar=persian’),’YYYY’,’nls_calendar=persian’)in(‘1379′,’1385′,’1390′,’1392′,’1393’));
commit;
exec dbms_stats.gather_table_stats(ownname => ‘USEF’,tabname => ‘PERSON’);
برای بررسی این نکته، که آیا غیرفعالسازی رکوردهای غیرضروری در کارایی هم موثر بوده یا خیر، به نقشه اجرایی جدول در هر دو حالت نگاهی خواهیم انداخت:
–row archival:
SQL> select * from usef.person;
1469967 rows selected.
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————-
| 0 | SELECT STATEMENT | | 1469K| 416M| 26416 (1)| 00:00:02 |
|* 1 | TABLE ACCESS FULL| PERSON | 1536K| 435M| 26416 (1)| 00:00:02 |
—————————————————————————-
1 – filter(“PERSON”.”ORA_ARCHIVE_STATE”=’0′)
Statistics
———————————————————-
369 recursive calls
0 db block gets
287964 consistent gets
87577 physical reads
573744 redo size
229390215 bytes sent via SQL*Net to client
1078519 bytes received via SQL*Net from client
97999 SQL*Net roundtrips to/from client
32 sorts (memory)
0 sorts (disk)
1469967 rows processed
–no row archival:
SQL> alter session set ROW ARCHIVAL VISIBILITY = ALL;
SQL> select * from usef.person;
2255208 rows selected.
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————-
| 0 | SELECT STATEMENT | | 2255K| 638M| 26410 (1)| 00:00:02 |
| 1 | TABLE ACCESS FULL| PERSON | 2255K| 638M| 26410 (1)| 00:00:02 |
—————————————————————————-
Statistics
———————————————————-
344 recursive calls
0 db block gets
337461 consistent gets
89535 physical reads
0 redo size
350927520 bytes sent via SQL*Net to client
1654369 bytes received via SQL*Net from client
150349 SQL*Net roundtrips to/from client
20 sorts (memory)
0 sorts (disk)
2255208 rows processed
Enterprise Manager Database Express
EM DB Express ابزار گرافیکی است که می تواند برای مانیتورینگ بانک اطلاعاتی مورد استفاده قرار بگیرد این ابزار نسبت به DB Control که در اوراکل 11g موجود بود، قابلیتهای بسیار کمتری دارد به طوری که با وجود ابزارهای گرافیکی همانند Grid/Cloud control شاید کمتر کسی به سراغ این روش مانیتورینگ برود البته سربار بسیار کمتری را هم برای بانک اطلاعاتی ایجاد می کند. برای مشاهده پورت مورد استفاده EM DB Express، از دستور زیر استفاده می کنیم:
SQL> select dbms_xdb_config.gethttpsport() port from dual;
PORT
———-
5502
اگر خروجی دستور بالا null بود، می توانیم با دستور زیر پورتی را برای EM در نظر بگیریم:
SQL> exec dbms_xdb_config.sethttpsport (5502);
PL/SQL procedure successfully completed.
در نهایت هم با لینک زیر وارد EM خواهیم شد:
باید در نظر داشت که پارامتر dispatchers برای XDB فعال شده باشد:
SQL> show parameter dispatchers
NAME VALUE
—————- ——————————
dispatchers (PROTOCOL=TCP) (SERVICE=usef2XDB)
همچنین listener باید رجیستر شده باشد که در این صورت در خروجی lsnrctl status خطوط زیر هم قابل مشاهده خواهد بود:
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=localhost)(PORT=5502))(Security=(my_wallet_directory=/u01/oracle/admin/usef2/xdb_wallet))(Presentation=HTTP)(Session=RAW))
Instance “usef2”, status READY, has 1 handler(s) for this service…
Service “usef2XDB” has 1 instance(s).
Instance “usef2”, status READY, has 1 handler(s) for this service…
The command completed successfully
ویژگی های جدید SecureFile در 12c
1. parallel DML: در نسخه 11g برای LOB segmentای که در جدول پارتیشن وجود داشته باشد، امکان parallel DML وجود دارد و در نسخه 12c، این امکان برای جداول پارتیشن نشده هم به وجود آمد(البته برای SecureFile).
alter session force parallel dml;
insert into usef.sec_lob select * from usef.aks;
2. پیش فرض شدن SecureFile برای ذخیره سازی LOB: با آمدن 12c پارامتر db_securefile مقدار پیشفرض PREFERRED به خود گرفت تا هر Lob segmentای که ساخته می شود، به صورت SecureFile باشد.
3.وقتی که جدولی با استفاده از datapump به اوراکل 12c منتقل میشود ، lobsegment آن را می توان به صورت SecureFile ایجادکرد:
TRANSFORM=LOB_STORAGE:SECUREFILE|BASICFILE|DEFAULT|NO_CHANGE
با تنظیم این پارامتر به SecureFile می توان به این هدف رسید:
impdp hr/hr DIRECTORY=dpdump_dir DUMPFILE=hr.dmp TRANSFORM=LOB_STORAGE:SECUREFILE
ویژگی جدید MV در 12c
out of place refresh: در نسخه های قبل از اوراکل 12c، معمولا بروزرسانی به طور مستقیم در جدول مربوط به MV اتفاق می افتاد(ابتدا اطلاعات حذف می شدند و سپس در همان session اطلاعات جدید درج می شد) به بیانی دیگر، بروزرسانی تنها به صورت in place (در جا) اتفاق می افتد که مرحله delete آن ممکن بود متناسب با حجم جدول، زمان زیادی را بگیرد در نسخه 12c این امکان بوجود امد تا بدون تغییر جدول اصلی مربوط به mv، بروزرسانی صورت بگیرد که این شکل از بروزرسانی، Out of Place نام دارد.
شیوه بروزرسانی Out of Place به این شکل است که جدولی به صورت موقت ساخته می شود که شامل اطلاعات بروز شده می باشد و این جدول با جدول جاری mv جایگزین می شود. همچنین بروزرسانی باید به صورت non-atomic انجام پذیرد.
exec DBMS_MVIEW.REFRESH(‘MV1’, method => ‘FAST’, atomic_refresh => TRUE, out_of_place => TRUE);
ORA-20000: ORA-32355: out-place refresh cannot be used in atomic mode
البته این روش محدودیتهایی هم دارد که بزرگترین آن، عدم پشتیبانی complete refresh به صورت از راه دور می باشد. به طور مثال:
CREATE MATERIALIZED VIEW MV1 REFRESH fast ON DEMAND AS select * from ag1@amad_test;
exec DBMS_MVIEW.REFRESH(‘MV1’, method => ‘COMPELETE’, atomic_refresh => FALSE, out_of_place => TRUE);
ORA-32354: cannot refresh materialized view USEF.MV1 using out-of-place complete refresh
ORA-06512: at “SYS.DBMS_SNAPSHOT”, line 2821
ORA-06512: at “SYS.DBMS_SNAPSHOT”, line 3058
ORA-06512: at “SYS.DBMS_SNAPSHOT”, line 3017
ORA-06512: at line 2
از محدودیتهای دیگر آن، می توان به عدم پشتیبانی از ON COMMIT refresh، نوع داده LOB و atomic_refresh و همچنین mvهایی که روی آنها materialized view log، triggersو یا constraint تعریف شده اند، نام برد.
بروزرسانی به شیوه out of place در شیوهای بروز رسانی مختلف اعم از comlete، force و fast قابل انجام می باشد. شیوه انجام این مدل از بروزرسانی به صورت زیر می باشد:
exec DBMS_MVIEW.REFRESH(‘MV1’, method => ‘COMPLETE’, atomic_refresh => FALSE, out_of_place => TRUE);
پرس و جوی زیر در هنگام اجرای بروزرسانی اجرا شده است و نشان می دهد که جدولی موقت با اسم RV$18E8A، برای این کار ایجاد شده است:
select owner,segment_name,segment_type,bytes from dba_segments l where segment_name like ‘%RV%’;
USEF RV$18E8A TABLE 22020096
آمارگیری بعد از درج انبوه
در نسخه 11g، زمانی که CATS اجرا می شد، در پایان انجام آن، آماری از جدول ایجاد شده، ثبت نمی شد:
create table us_tbl1 as select * from dba_source;
SELECT table_name,num_rows FROM dba_tables WHERE table_name = ‘US_TBL1’;
| TABLE_NAME | NUM_ROWS |
| US_TBL1 |
حال اگر همین دستور در نسخه 12c اجرا شود، نتیجه چیزی دیگری خواهد بود(البته استثناهایی هم در این زمینه وجود دارد):
create table us_tbl1 as select * from dba_source;
SELECT table_name,num_rows FROM dba_tables WHERE table_name = ‘US_TBL1’;
| TABLE_NAME | NUM_ROWS |
| US_TBL1 | 326024 |
همچنین می توان با هینت NO_GATHER_OPTIMIZER_STATISTICS، از این کار جلوگیری کرد:
create table us_tbl1 as select /*+ NO_GATHER_OPTIMIZER_STATISTICS */ * from dba_source ;
Scrubbing Disk Group
با دستور ALTER DISKGROUP .. SCRUB در محیط ASM، این امکان وجود دارد تا logical data corruption کشف شود و نیز در صورتی که افزونگی دیسک گروه برابر با high و یا normal باشد، این خرابی برطرف خواهد شد(repair).
این دستور می تواند در سطح دیسک گروه، دیسک و یا فایل استفاده شود:
در سطح دیسک گروه:
SQL> ALTER DISKGROUP DATA01 SCRUB POWER LOW;
Diskgroup altered.
در سطح فایل:
SQL> ALTER DISKGROUP DATA01 SCRUB FILE ‘+DATA01/USEF12C/DATAFILE/usef_tbs.282.934463987’ REPAIR POWER HIGH FORCE;
Diskgroup altered.
نکته: power می تواند یکی از مقادیر AUTO، LOW،HIGH و یا MAX را به خود اختصاص دهد. همچنین عبارت force سبب می شود تا در صورت بار بالا بر روی سیستم و نیز غیرفعال بودن scrubbing در سطح سیستم، مانع انجام عملیات نشود.
سوییچ –val در دستور srvctl
سوییچ eval در دستور srvctl و یا crsctl سبب می شود تا دستور مورد نظر، بدون اینکه اجرا شود، نتیجه اجرای در خروجی مشخص شود(به نوعی شبیه سازی صورت می گیرد) برای مثال می خواهیم بدانیم با stop کردن بانک usef2، چه اتفاقی رخ خواهد داد، دستور زیر این مسئله را شبیه سازی می کند:
[oracle@rac1 ~]$ srvctl stop database -d usef2 -eval
Database usef2 will be stopped on node rac1
ذخیره دیتافایل در ACFS
همانطور که می دانید، کلاستر فایل سیستم(ACFS) بر روی ASM قرار می گیرد و منابع آن توسط گرید مدیریت می شود و بسیاری از فایلها از قبیل فایلهای application، فایلهای اجرایی، trace file، alert log و حتی نرم افزار اوراکل را می توان در ACFS ذخیره کرد ولی ویژگی مهمی که از اوراکل 12c به آن اضافه شد، پشتیبانی از database fileها می باشد البته کماکان نمی توان گرید را بر روی آن نصب کرد.
برای استفاده از این ویژگی می توان از asmca یا command line استفاده کرد که در این قسمت دستوراتی را که برای ایجاد فضایی با سیستم فایل ACFS در اوراکل 12.1 استفاده شده را می بینید:
- فرض کنید یک DISKGROUP با نام usef وجود دارد که در حال حاضر مونت می باشد:
ASMCMD [+] > lsdg
State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED EXTERN N 512 4096 1048576 7152 3608 0 3608 0 Y USEF/
[root@rac1 ~]# oracleasm createdisk usef /dev/sdg1
Writing disk header: done
Instantiating disk: done
CREATE DISKGROUP usef EXTERNAL REDUNDANCY DISK ‘/dev/oracleasm/disks/USEF’ SIZE 1019M ATTRIBUTE ‘compatible.asm’=’12.1.0.0.0′,’au_size’=’1M’;
مقداری که compatible.asm می گیرد باید بزرگتر از 12.1 باشد البته برای 11gR2 باید بزرگتر از 11.2 باشد.
- باید بر روی اینDISKGROUP یک volumeبسازیم و سپس آن را فعال کنیم:
ALTER DISKGROUP USEF ADD VOLUME volume11 SIZE 819200K;
alter diskgroup USEF enable volume ‘volume11’;
با دستور زیر، مشخصات این volume را خواهیم دید :
ASMCMD [+] > volinfo -G USEF volume11
Diskgroup Name: USEF
Volume Name: VOLUME11
Volume Device: /dev/asm/volume11-151
State: DISABLED
Size (MB): 832
Resize Unit (MB): 64
Redundancy: UNPROT
Stripe Columns: 8
Stripe Width (K): 1024
Usage:
Mountpath:
- با دستور زیر volume را به فرمت ACFS تبدیل می کنیم:
[root@rac1 ~]# /sbin/mkfs -t acfs /dev/asm/volume11-151
mkfs.acfs: version = 12.1.0.2.0
mkfs.acfs: on-disk version = 39.0
mkfs.acfs: volume = /dev/asm/volume11-151
mkfs.acfs: volume size = 872415232 ( 832.00 MB )
mkfs.acfs: Format complete.
- پوشه ای که می خواهیم فضا به آن مونت شود را ایجاد کرده و با دستور acfsutil، مشخصات فضای acfs را ثبت می کنیم این دستور به نوعی وظایف /etc/fstab را انجام می دهد.
[root@rac1 ~]# mkdir /acfs_usef
[root@rac1 ~]# chown -R oracle.oinstall /acfs_usef/
[root@rac1 ~]# /sbin/acfsutil registry -a /dev/asm/volume11-151 /acfs_usef
acfsutil registry: ACFS-03132: mount point /acfs_usef already exists in the Oracle Registry as:
Mount Object:
Device: /dev/asm/volume1-194
Mount Point: /acfs_usef
Disk Group: USEF_GRP1
Volume: VOLUME1
Options: none
Nodes: all
برای مونت کردن این فضا، از دستور زیر استفاده می کنیم:
[root@rac1 ~]# /bin/mount -t acfs /dev/asm/volume1-194 /acfs_usef
[root@rac1 ~]# df -h /acfs_usef/
Filesystem Size Used Avail Use% Mounted on
/dev/asm/volume1-194 832M 79M 754M 10% /acfs_usef
در نهایت برای ایجاد دیتافایل بر روی acfs، از دستور زیر استفاده می کنیم:
alter tablespace USEF_TBS add datafile ‘/acfs_usef/test2.dbf’ size 10m;