بانک اطلاعاتی اوراکل با هر نسخه جدیدی که ارائه می کند معمولا بسیاری از باگهای ایجاد شده در نسخه های قبلی را رفع کرده و همراه با آن ویژگی های جدیدی را هم عرضه می کند به همین منوال، در نسخه 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، می توان به نمونه های زیر اشاره کرد:

1. ایجاد بار کمتر بر روی بستر شبکه

امکان رمزنگاری داده قبل از انتقال آن برروی بستر شبکه

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;

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;

———-

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;

session 2:

select seq_new.nextval from dual;

برای تغییر حالت این 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

مثال:

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

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.

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;

————————————————————————————–

| 0 | SELECT STATEMENT | | 4 | 232 | 1 (0)| 00:00:01 |

| 1 | BITMAP CONVERSION TO ROWIDS | | 4 | 232 | 1 (0)| 00:00:01 |

——————————————————————————–

همچنین می توان با دستورات زیر، در مورد مرئی یا نامرئی بودن ایندکسها نظر داد:

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.

—————————————————————————-

| 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.

—————————————————————————-

| 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 خواهیم شد:

https://host_name:5502/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;

FAR SYNC DATA GUARD

در ادامه مراحل انجام، به صورت خلاصه آورده شده است:

1. تنظیم pfile برای هر سه بانک. پارامترهایی که باید بر روی هر سه بانک اعمال شوند:

پارامترهای بانک اصلی:

پارامترهای FAR SYNC:

پارامترهای data guard:

2. تنظیم فایل tns

بعد از تنظیم و یا ایجاد pfile، باید فایل tnsnames.ora را اصلاح کرد:

در این مرحله، برای بانک FAR کنترل فایلی را در primary ایجاد می کنیم و سپس آن را به سرور مربوط به بانک FAR منتقل می کنیم:

بعد از منتقل شدن کنترل فایل به بانک 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 استارت شود، با خطای زیر مواجه می شویم:

همچنین فایلهای standby logfile group را به این بانک اضافه می کنیم:

4. راه اندازی بانک استندبای:

به بانک استندبای، standby redo log را اضافه کرده و سپس آن را در وضیعت recover قرار می دهیم:

رفع گپ در استندبای از طریق شبکه

–in primary:

–in stb:

–primary:

–in stb:

بازیابی دیتافایل بانک اصلی از استندبای

Transport Database روی بستر شبکه

جابجایی و تغییر نام انلاین یک دیتافایل

مثال:

READ ANY TABLE

Data Redaction

Privilege Analysis

نکته: ویوی dba_used_objprivs_path در این زمینه مفید می باشد.

RESOURCE ROLE و UNLIMITED TABLESPACE

Information Lifecycle Management (ILM)

غیرفعال سازی logging بهنگام impdp

پارامتر views_as_tables در data pump

اعمال محدودیت برای اندازه PGA

با استفاده از پارامتر PGA_AGGREGATE_LIMIT، این امکان وجود دارد تا برای حداکثر میزان حافظه مصرفی هر session نظر داد:

در صورتی که sessionی خواستار فضای بیشتری از مقدار مشخص شده باشد، با خطای زیر، مواجه و در نهایت کشته می شود:

ORA-00028: your session has been killed . ORA-04036

TRUNCATE TABLE CASCADE در نسخه های قبلی، امکان truncate جدول master وجود نداشت:

ستون نامریی

دیدگاهتان را بنویسید لغو پاسخ

TRUNCATE TABLE CASCADE
در نسخه های قبلی، امکان truncate جدول master وجود نداشت: