امکان بهینه سازی و تفکیک اطلاعات کم کاربرد با جدید در نسخه ۱۲c پایگاه داده اوراکل
یکی از اهداف سیاست ILM ( چرخه عمر اطلاعات ) کاهش هزینه برای storage ، بهبود کارایی و زمان دسترسی به اطلاعات جاری همانند اطلاعات آرشیو شده است و همچنین نگهداری اطلاعات به اندازه کافی جهت حفظ و اجرای قوانین نظارتی و پیاده سازی درخواستهای مربوط به حفظ اطلاعات است.
گاهی اوقات رشد اطلاعات از خرید storage ها در سازمان ها پیشی می گیرد. به همین دلیل است که سازمانها بایستی جهت دستیابی به سیاست ها و اهداف ILM خود ، از امکاناتی مانند tiered storage ( دیسک چند سطحی) و یا compression tiering ( فشرده سازی چند سطحی) استفده می کنند.
در نحوه استفاده از فشرده سازی (compression) این موضوع باید در نظر گرفته شود که جهت فشرده سازی دیتابیس جاری یا OLTP می بایستی از سطوح پایین آن ( lower compression level) و جهت فشرده سازی اطلاعاتی که کمتر استفاده می شود و یا به ندرت تغییر پیدا می کند از سطوح بالاتر فشرده سازی (higher levels of compression) استفاده شود و یا به دیسک های ارزان تر منتقل گردد.
پایگاه داده اوراکل در نسخه ۱۲c ویژگی جدیدی به نام Heat Map معرفی کرده که اطلاعات را بر اساس چرخه و زمان استفاده از آن نشانه گذاری می کند و از آن برای توزیع دیتا استفاده می کند.
ADO )Automatic Data Optimization) از ویژگی Heat Map استفاده می کند و این امکان را فراهم می سازد تا این policy ها را بر روی Table space ها object های مختلف و حتی در سطح row نیز پیاده سازی نمود، که در آن شرایط ذخیره سازی اطلاعات در زمان فشرده سازی، به روز رسانی و حذف آنها بر اساس آمار به دست آمده در یک بازه زمانی مشخص می سازد.
آمار زمان واقعی دسترسی به دیتا را می توان در ویو V$HEAT_MAP_SEGMENT یافت و سپس دیتا با استفاده از DBMS_SCHEDULER_JOBS در جدولی مانند HEAT_MAP_STAT$ ریخته می شود که قابل مشاهده در ویو های DBA مانند DBA_HEAT_MAP_SEG_HISTOGRAM و DBA_HEAT_MAP_SEGMENT است.
ویژگی Heat Map در سطح Instance با تنظیم پارامتر HEAT_MAP =ON فعال نمود.
در این مرحله با یک مثال می توان نحوه استفاده از ویژگی HEAT_MAP و ADO را بررسی نمود.
در این مثال سیاست ILM ( چرخه عمر اطلاعات ) یک جدول با نام MYOBJECTS ر که در طول ۳۰ روز گذشته تغییری نداشته compress می کند.
بنابراین با فرض بالا اطلاعات قدیمی و بلا استفاده می تواند جهت ذخیره سازی بر روی دیسک فشرده شود و تا زمانی که این اطلاعات به طور منظم استفاده نشود تاثیری بر performance دیتابیس با ساختار OLTP نخواهد گذاشت.
یک procedure جهت مدیریت زمان استفاده از جدولی که واجد شرایط فعالیت ADO )compression) است می سازیم حتی اگر شرط گذشت ۳۰ روز نیز برقرار نباشد.
CREATE OR REPLACE PROCEDURE set_stat (object_id number,
data_object_id number,
n_days number,
p_ts# number,
p_segment_access number)
as
begin
insert into sys.heat_map_stat$
(obj#,
dataobj#,
track_time,
segment_access,
ts#)
values
(object_id,
data_object_id,
sysdate – n_days,
p_segment_access,
p_ts# );
commit;
end;
/
سپس دسترسی اجرای این procedure را به کاربر scott می دهیم :
SQL> grant execute on set_stat to scott;
SQL> alter system set heat_map=on scope=both;
پس از گذشت ۳۰ روز از فعال سازی این ویژگی آمار این اطلاعات را با استفاده از Automatic Data Optimization (ADO) بدست آورد.
exec dbms_ilm_admin.set_heat_map_start(start_date => sysdate – 30)
با کاربر scott وارد می شویم و جدول را پر می کنیم :
SQL> create table myobjects as select * from all_objects;
Table created.
SQL> declare
sql_test clob;
begin
for i in 1..5
loop sql_test := ‘insert /*+ append */ into scott.myobjects select * from scott.myobjects’;
execute immediate sql_test;
commit;
end loop;
end;
/
اندازه جدول uncompressed شده ۳۲۰ مگابایت است:
SQL> select sum(bytes)/1048576 from user_segments where
segment_name=’MYOBJECTS’;
SUM(BYTES)/1048576
——————
۳۲۰
SQL> select count(*) from myobjects;
COUNT(*)
———-
۲۳۶۰۲۸۸
حال بررسی می کنیم که ویژگی heat map برای جدول SCOTT.MYOBJECTS چه اطلاعاتی را جمع آوری نموده است:
SQL> alter session set nls_date_format=’dd-mon-yy hh:mi:ss’;
Session altered.
select OBJECT_NAME,SEGMENT_WRITE_TIME , SEGMENT_READ_TIME, FULL_SCAN
FROM dba_heat_map_segment
WHERE OBJECT_NAME=’MYOBJECTS’
AND OWNER = ‘SCOTT’;
OBJECT_NAME
——————————————————————————–
SEGMENT_WRITE_TIME SEGMENT_READ_TIME FULL_SCAN
—————— —————— ——————
MYOBJECTS
۰۹-sep-13 02:39:09
col “Segment write” format A14
col “Full Scan” format A12
col “Lookup Scan” format a12
select object_name, track_time “Tracking Time”,
segment_write “Segment write”,
full_scan “Full Scan”,
lookup_scan “Lookup Scan”
from DBA_HEAT_MAP_SEG_HISTOGRAM
where object_name=’MYOBJECTS’
and owner = ‘SCOTT’;
OBJECT_NAME
——————————————————————————–
Tracking Time Segment write Full Scan Lookup Scan
—————— ————– ———— ————
MYOBJECTS
۰۹-sep-13 02:40:14 NO YES NO
با این وجود جدول هنوز compress نشده است:
SQL> select compression, compress_for from dba_tables where table_name = ‘MYOBJECTS’ and owner = ‘SCOTT’;
COMPRESS COMPRESS_FOR
——– ——————————
DISABLED
حالا compression policy را بر روی جدول SCOTT.MYOBJECTS اعمال می کنیم:
ALTER TABLE scott.myobjects ILM ADD POLICY ROW STORE
COMPRESS ADVANCED SEGMENT AFTER 30 DAYS OF NO MODIFICATION;
کنترل این که policy اعمال شده است:
select policy_name, action_type, scope, compression_level,
condition_type, condition_days
from user_ilmdatamovementpolicies
order by policy_name;
POLICY_NAME
——————————————————————————–
ACTION_TYPE SCOPE COMPRESSION_LEVEL CONDITION_TYPE
———– ——- —————————— ———————-
CONDITION_DAYS
————–
P3
COMPRESSION SEGMENT ADVANCED LAST MODIFICATION TIME
۳۰
select policy_name, object_name, inherited_from, enabled
from user_ilmobjects;
POLICY_NAME
——————————————————————————–
OBJECT_NAME
——————————————————————————–
INHERITED_FROM ENA
——————– —
P3
MYOBJECTS
POLICY NOT INHERITED YES
select * from user_ilmpolicies;
POLICY_NAME
——————————————————————————–
POLICY_TYPE TABLESPACE ENABLED
————- —————————— ——-
P3
DATA MOVEMENT YES
حال شرایطی را شبیه سازی می کنیم که جدول MYOBJECTS به مدت ۳۰ روز تغییر نکند:
با استفاده از procedure به نام set_stat که قبلا ساخته شد ساعت heat map را ۳۰ روز به عقب برمی گردانیم. با کاربر SYS:
alter session set nls_date_format=’dd-mon-yy hh:mi:ss’;
declare
v_obj# number;
v_dataobj# number;
v_ts# number;
begin
select object_id, data_object_id into v_obj#, v_dataobj#
from all_objects
where object_name = ‘MYOBJECTS’
and owner = ‘SCOTT’;
select ts# into v_ts#
from sys.ts$ a,
dba_segments b
where a.name = b.tablespace_name
and b.segment_name = ‘MYOBJECTS’;
commit;
sys.set_stat
(object_id => v_obj#,
data_object_id => v_dataobj#,
n_days => 30,
p_ts# => v_ts#,
p_segment_access => 1);
end;
/
در این مرحله اطلاعاتی heat map که داخل حافظه بوده در جدول یا ویوی که بدون تغییر مانده می ریزیم:
بعد از restart دیتابیس عملکرد heat map را مشاهده می کنیم، آمار نشان می دهد که این جدول بیش از یک ماه است که تغییری نکرده است.
select object_name, segment_write_time
from dba_heat_map_segment
where object_name=’MYOBJECTS’;
OBJECT_NAME
——————————————————————————–
SEGMENT_W
———
MYOBJECTS
۱۰-AUG-13
در حالت عادی job های ADO به صورت خودکار اجرا می شود ، اما پروسجر DBMS_ILM.EXECUTE_ILM به صورت دستی اجرا می کنیم:
SQL> conn scott/tiger
Connected.
declare
v_executionid number;
begin
dbms_ilm.execute_ILM (ILM_SCOPE => dbms_ilm.SCOPE_SCHEMA,
execution_mode => dbms_ilm.ilm_execution_offline,
task_id => v_executionid);
end;
/
با پرس و جو از ویو USER_ILMTASKS می توان از نحوه اجرای job اطلاع پیدا کرد:
select task_id, start_time as start_time from user_ilmtasks;
TASK_ID
———-
START_TIME
—————————————————————————
۷
۰۹-SEP-13 02.50.24.895834 PM
select task_id, job_name, job_state, completion_time completion from user_ilmresults;
TASK_ID
———-
JOB_NAME
——————————————————————————–
JOB_STATE
———————————–
COMPLETION
—————————————————————————
۸
ILMJOB1116
JOB CREATED
select task_id, policy_name, object_name, selected_for_execution, job_name
from user_ilmevaluationdetails
where task_id=11;
TASK_ID
———-
POLICY_NAME
——————————————————————————–
OBJECT_NAME
——————————————————————————–
SELECTED_FOR_EXECUTION
——————————————
JOB_NAME
——————————————————————————–
۸
P3
MYOBJECTS
TASK_ID
———-
POLICY_NAME
——————————————————————————–
OBJECT_NAME
——————————————————————————–
SELECTED_FOR_EXECUTION
——————————————
JOB_NAME
——————————————————————————–
SELECTED FOR EXECUTION
ILMJOB1116
مشاهده کنید که جدول compress شده و اجرای ADO Job به پایان رسیده است.
select task_id, job_name, job_state, completion_time completion from user_ilmresults;
TASK_ID
———-
JOB_NAME
——————————————————————————–
JOB_STATE
———————————–
COMPLETION
—————————————————————————
۱۱
ILMJOB1118
COMPLETED SUCCESSFULLY
۰۹-SEP-13 03.26.44.408970 PM
select compression, compress_for FROM user_tables where table_name = ‘MYOBJECTS’;
COMPRESS COMPRESS_FOR
——– ——————————
ENABLED ADVANCED
و حجم جدول از ۳۲۰ مگابایت به ۶۰ مگابایت کاهش یافته است!
select sum(bytes)/1048576 from user_segments where segment_name=’MYOBJECTS’;
SUM(BYTES)/1048576
——————
۶۰
همچنین ILM Policy را می توان از جدول به طریق زیر حذف نمود.
alter table scott.myobjects ilm delete_all;
دیدگاه خود را ثبت کنید
تمایل دارید در گفتگوها شرکت کنید؟در گفتگو ها شرکت کنید.