{"id":373,"date":"2017-11-13T23:12:53","date_gmt":"2017-11-13T21:12:53","guid":{"rendered":"http:\/\/blog.sqlora.com\/de\/?p=373"},"modified":"2018-04-06T13:53:45","modified_gmt":"2018-04-06T11:53:45","slug":"ilm-is-it-possible-to-mix-ado-policies-for-compression-and-storage","status":"publish","type":"post","link":"https:\/\/blog.sqlora.com\/de\/ilm-is-it-possible-to-mix-ado-policies-for-compression-and-storage\/","title":{"rendered":"ILM – ist es m\u00f6glich, ADO-Policies f\u00fcr Compression und Storage zu mischen?"},"content":{"rendered":"

Ich h\u00e4tte nie gedacht, dass ich oft \u00fcber Information Lifecycle Management schreiben werde, da ich eigentlich ein Entwickler bin und kein DBA. Ich denke, ILM ist schon ein Thema, das mehr f\u00fcr die DBA’s Relevanz hat. Auf der anderen Seite ist es immer eine gute Sache, wenn Entwickler und DBA’s die Arbeit von einander verstehen, oder? In unserem Training „12c New Features f\u00fcr Entwickler“<\/a>, von dem ich einer der Referenten bin, geben wir einen Einblick in die ILM Features. Das ist auch der Grund, warum ich mittlerweile schon den dritten Post dar\u00fcber schreibe: um einige unklar dokumentierte Fragen auch f\u00fcr mich selber zu kl\u00e4ren. <\/p>\n

Nachdem wir uns in vorherigen Beitr\u00e4gen die ADO Bedingungen f\u00fcr Storage Tiering Policies <\/a> sowie die Verwendung von benutzerdefinierten ILM ADO Bedingungen mit PL\/SQL<\/a> angeschaut haben, wollte ich die Frage kl\u00e4ren, ob es m\u00f6glich ist, die Storage und Compression Policies f\u00fcr ein Datensegment zu mischen? Es k\u00f6nnte durchaus Sinn ergeben, z.B. Daten auf ein kosteng\u00fcnstigeren Datentr\u00e4ger zu verschieben und gleichzeitig zu komprimieren. Ich bin schon paar Mal \u00fcber die Aussage gestolpert, das w\u00e4re nicht m\u00f6glich. Es ist aber sehr einfach zu pr\u00fcfen. So geht das: <\/p>\n

Wir starten mit demselben Setup, wie in vorherigen Beitr\u00e4gen \u00fcber ILM ( 1<\/a> and 2<\/a>) und definieren beide Policies f\u00fcr die Tabelle EMPLOYEE1<\/strong>: wir m\u00f6chten Daten nach zehn Tagen ohne Zugriff zum Tablespace LOW_COST_STORE<\/strong> verschieben und gleichzeitig komprimieren (basic). Um den Komprimierungseffekt zu best\u00e4tigen, zeigen wir die initiale Gr\u00f6\u00dfe des Datensegments an.<\/p>\n

\r\nSYS> SELECT owner, segment_name, tablespace_name, bytes, blocks\r\n  2    FROM dba_segments\r\n  3   WHERE segment_name = 'EMPLOYEE1';\r\n\r\nOWNER   SEGMENT_NAME  TABLESPACE_NAME   BYTES    BLOCKS\r\n------- ------------- ----------------- -------- --------\r\nSCOTT   EMPLOYEE1     USERS             327680   40\r\n\r\nSCOTT> ALTER TABLE scott.employee1\r\n  2  ILM ADD POLICY ROW STORE COMPRESS BASIC\r\n  3  SEGMENT AFTER 10 DAYS OF NO ACCESS;\r\n\r\nTable altered.\r\n\r\nSCOTT> \r\nSCOTT> -- Storage tiering with condition only to move to read-only tablespace\r\nSCOTT> ALTER TABLE scott.employee1\r\n  2  ILM ADD POLICY TIER TO low_cost_store READ ONLY\r\n  3  SEGMENT AFTER 10 DAYS OF NO ACCESS;\r\n\r\nTable altered.\r\n\r\nSCOTT> SELECT policy_name, action_type, scope, tier_tablespace, condition_type, condition_days\r\n  2    FROM user_ilmdatamovementpolicies;\r\n\r\nPOLICY_NAME ACTION_TYPE SCOPE\tTIER_TABLESPACE   CONDITION_TYPE    CONDITION_DAYS\r\n----------- ----------- ------- ----------------- ----------------- --------------\r\nP307\t    COMPRESSION SEGMENT                   LAST ACCESS TIME  10\r\nP308\t    STORAGE     SEGMENT LOW_COST_STORE    LAST ACCESS TIME  10\r\n\r\nSCOTT> \r\nSCOTT> SELECT policy_name, object_name, object_type, enabled\r\n  2    FROM user_ilmobjects;\r\n\r\nPOLICY_NAME OBJECT_NAME           OBJECT_TYPE\t    ENABLED\r\n----------- -------------------- ------------------ -------\r\nP307\t    EMPLOYEE1             TABLE\t            YES\r\nP308\t    EMPLOYEE1             TABLEE            YES\r\n<\/pre>\n
Zumindest keine Fehlermeldung, die Policies sind da und sind aktiviert. Scheint zu funktionieren. Aber werden die gew\u00fcnschten Aktionen wirklich ausgef\u00fchrt?  Wir setzen den Parameter f\u00fcr die Zeiteinheiten auf die Sekunden, setzen die Startzeit, lassen die Heat Map Information auf die Platte schreiben und warten mehr als 10 Sekunden:<\/p>\n
\r\nSCOTT> ----------------------------------------------------------------------------------------------------\r\nSCOTT> -- Triggering the Table to Move to Low Cost Storage\r\nSCOTT> ----------------------------------------------------------------------------------------------------\r\nSCOTT> -- 1. Switch ILM unit to seconds\r\nSCOTT> EXECUTE dbms_ilm_admin.customize_ilm(DBMS_ILM_ADMIN.POLICY_TIME, DBMS_ILM_ADMIN.ILM_POLICY_IN_SECONDS);\r\n\r\nPL\/SQL procedure successfully completed.\r\n\r\nSCOTT> -- 2. set start date\r\nSCOTT> EXECUTE DBMS_ILM_ADMIN.SET_HEAT_MAP_START(sysdate -50);\r\n\r\nPL\/SQL procedure successfully completed.\r\n\r\nSCOTT> EXECUTE dbms_ilm.flush_all_segments;\r\n\r\nPL\/SQL procedure successfully completed.\r\n\r\nSCOTT> EXECUTE  dbms_lock.sleep(15);\r\n\r\nPL\/SQL procedure successfully completed.\r\n<\/pre>\n
Nun f\u00fchren wir ILM manuell aus und schauen, was passiert:<\/p>\n
\r\nSCOTT> declare\r\n  2  v_executionid number;\r\n  3  begin\r\n  4    dbms_ilm.execute_ILM (ILM_SCOPE => dbms_ilm.SCOPE_SCHEMA,\r\n  5  \t\t execution_mode => dbms_ilm.ilm_execution_offline,\r\n  6  \t\t task_id   => v_executionid);\r\n  7  end;\r\n  8  \/\r\n\r\nPL\/SQL procedure successfully completed.\r\n\r\nSCOTT> ------------------------------------------------------------------------------\r\nSCOTT> -- Table EMPLOYEE1 is now moved to tablespace LOW_COST_STORE and compressed\r\nSCOTT> ------------------------------------------------------------------------------\r\nSCOTT> select tablespace_name, segment_name, bytes, blocks\r\n  2  from   user_segments\r\n  3  where  segment_name='EMPLOYEE1';\r\n\r\nTABLESPACE_NAME   SEGMENT_NAME\t BYTES\t  BLOCKS\r\n----------------- -------------- -------- ----------\r\nLOW_COST_STORE    EMPLOYEE1      131072\t  16\r\n\r\nSCOTT> SELECT compression, compress_for\r\n  2  FROM user_tables WHERE table_name = 'EMPLOYEE1';\r\n\r\nCOMPRESS COMPRESS_FOR\r\n-------- ------------------------------\r\nENABLED  BASIC\r\n<\/pre>\n
Und voil\u00e1, die Tabelle wurde verschoben und dabei komprimiert. Achten Sie darauf, wie die Gro\u00dfe des Segments um fast zwei drittel zur\u00fcckging. Die ILM Ausf\u00fchrungsinformationen im Data Dictionary best\u00e4tigen das:<\/p>\n
\r\nSCOTT> SELECT task_id, to_char(start_time, 'dd\/mm\/yyyy hh24:mi:ss') as start_time, u.STATE\r\n  2  FROM user_ilmtasks u;\r\n\r\n   TASK_ID START_TIME          STATE\r\n---------- ------------------- ---------\r\n       276 31\/10\/2017 17:14:38 COMPLETED\r\n\r\nSCOTT> \r\nSCOTT> select task_id,\tjob_name, job_state, to_char(completion_time, 'dd\/mm\/yyyy hh24:mi:ss') completion,\r\n  2  from user_ilmresults;\r\n\r\n   TASK_ID JOB_NAME     JOB_STATE                COMPLETION\r\n---------- ------------ ------------------------ ------------------------------\r\n       276 ILMJOB4438   COMPLETED SUCCESSFULLY   31\/10\/2017 17:14:39\r\n\r\nSCOTT> \r\nSCOTT> select task_id, policy_name, object_name, selected_for_execution from user_ilmevaluationdetails;\r\n\r\n   TASK_ID POLICY_NAME OBJECT_NAME     SELECTED_FOR_EXECUTION\r\n---------- ----------- --------------- ------------------------------------------\r\n       276 P307        EMPLOYEE1       SELECTED FOR EXECUTION\r\n       276 P308        EMPLOYEE1       SELECTED FOR EXECUTION\r\n\r\n<\/pre>\n
Offensichtlich hat es funktioniert. Nat\u00fcrlich m\u00fcssen die Policies bestimmten Regeln folgen und keine widersprechliche Bedingungen bzw. Aktionen haben. Eine \u00dcbersicht ist z.B. hier <\/a> zu finden. <\/p>\n","protected":false},"excerpt":{"rendered":"
Ich h\u00e4tte nie gedacht, dass ich oft \u00fcber Information Lifecycle Management schreiben werde, da ich eigentlich ein Entwickler bin und kein DBA. Ich denke, ILM ist schon ein Thema, das mehr f\u00fcr die DBA’s Relevanz hat. Auf der anderen Seite ist es immer eine gute Sache, wenn Entwickler und DBA’s die Arbeit von einander verstehen, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,3,22],"tags":[48,47,52],"class_list":["post-373","post","type-post","status-publish","format-standard","hentry","category-ilm","category-oracle","category-trivadis","tag-storage-tiering","tag-ilm","tag-kompromierung"],"_links":{"self":[{"href":"https:\/\/blog.sqlora.com\/de\/wp-json\/wp\/v2\/posts\/373","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.sqlora.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.sqlora.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.sqlora.com\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.sqlora.com\/de\/wp-json\/wp\/v2\/comments?post=373"}],"version-history":[{"count":10,"href":"https:\/\/blog.sqlora.com\/de\/wp-json\/wp\/v2\/posts\/373\/revisions"}],"predecessor-version":[{"id":383,"href":"https:\/\/blog.sqlora.com\/de\/wp-json\/wp\/v2\/posts\/373\/revisions\/383"}],"wp:attachment":[{"href":"https:\/\/blog.sqlora.com\/de\/wp-json\/wp\/v2\/media?parent=373"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.sqlora.com\/de\/wp-json\/wp\/v2\/categories?post=373"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.sqlora.com\/de\/wp-json\/wp\/v2\/tags?post=373"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}