Information Lifecycle Management (ILM) e Automatic Data Optimization (ADO)

Por Daniel Da Meda (OCM) e Alex Zaballa
Postado em Julho 2015

Revisado por Marcelo Pivovar - Solution Architect

Heat Map e ADO (Automatic Data Optimization) podem ser usados para otimizar a estratégia de ILM (Information Lifecycle Management).  O Automatic Data Optimization trabalha em conjunto com as seguintes funcionalidades para automatizar e efetivar as políticas de ILM:

• Partitioning
• Advanced Compression
• Hybrid Columnar Compression
• Online Move Data File
• Storage Tiering

ILM – Information Lifecycle Management

ILM pode ser definido como uma estratégia para administrar os dados no decorrer de seu ciclo de vida, a fim de reduzir custos de armazenamento, melhorar a performance de acesso e adaptar a retenção destes dados a regulamentações vigentes.
ILM é uma prática onde se aplicam políticas para administrar as informações de forma efetiva ao longo de seu ciclo de vida útil, o que possibilita alinhar o valor da informação ao negócio.
Segundo a Oracle, os clientes estão interessados em adotar a compressão de dados e storage tiering a fim de satisfazer suas necessidades de ILM. Enquanto que para muitos clientes a compressão dos dados se mostra suficiente, existe um subconjunto de clientes que preferem fazer uso de seus low-cost storage ou storages mais antigos, movendo  dados “dormentes” ou não ativos para os mesmos.

ADO – Automatic Data Optimization

As políticas ADO podem efetuar as seguintes tarefas de maneira automática sobre os dados, uma vez que estas se qualificam de acordo com um critério definido:

• Compressão de dados em múltiplos níveis
• Mover segmentos para outros storages

O ADO é completamente dependente de um novo recurso presente na versão 12c do banco de dados, o Heat Map.

Heat Map

Ele coleta automaticamente estatísticas que servirão como base para as ações do ADO. A granularidade vai do nível da tablespace para o nível do registro.
O que segue, é uma tentativa de quebrar uma política ADO em uma estrutura lógica WHAT->IF->WHEN->DO.
WHAT (escopo)

• Tablespace-level: Aplicado a tablespace e a todos os segmentos da tablespace;
• Group-level: Este escopo define que a ação da política também é estendida a qualquer Securefile LOB definido no segmento;
• Segment-level:
  • Table/Partition/Subpartition
  • Clustered Table
• Row-level: Políticas deste nível, só podem ser definidas com base no tempo de modificação.

IF  (operação específica)
Para cada um dos escopos definidos acima, o Heat Map pode controlar as seguintes operações:

• Data de Criação
• Data do acesso
• Data de modificação

WHEN (evento de disparo)

• Após 3 dias
• Após 1 ano
• Tablespace cheio
• Baixo acesso

DO (ação tomada pela política)

• Compression: ROW STORE COMPRESS ou HCC
• Tiering: Mover o objeto para um storage diferente
• Compression + Tiering: Ambas as ações podem ser executadas

Antes de mergulhar a fundo em mais detalhes e na sintaxe, vamos fazer uma analogia simples para entender o conceito de criação de uma política ADO.
Dada a estrutura  da política, pode-se fazer a seguinte analogia usando linguagem simples em Português para defini-la:
 “Comprimir a tablespace de nome tbs1 usando o algoritmo de compressão OLTP, uma vez que os dados são raramente acessados”.
A instrução acima em Português é equivalente a seguinte declaração no Oracle:

ALTER TABLESPACE tbs1 DEFAULT ILM ADD POLICY
ROW  STORE COMPRESS ADVANCED
SEGMENT AFTER 30 DAYS OF LOW ACCESS; 

As estatísticas de Heat Map podem ser visualizadas graficamente através do EM Cloud Control ou via database views.

A Figura 1 abaixo, mostra a representação gráfica do Heat Map com diferentes partições:

Pode-se verificar, na figura 1 acima, que as partições da tabela ORDER_ITEMS que estão sendo acessadas com mais frequência estão na cor vermelha.  Note que não é necessária a presença de políticas de ADO para que o Heat Map colete as estatísticas referentes a utilização dos objetos.
Em versões anteriores à 12c, o nível mais baixo de classificação era o segmento ou partição. Na versão 12c, podem-se classificar até mesmo os registros de uma tabela.
Estatísticas a nível de registro são gerenciadas in-line como parte do trabalho feito quando um processo modifica dados.
A nível de segmento, o acesso e modificações são rastreadas de acordo com a seguinte lista:

• Timestamp do último acesso
  • Fetch-by-rowid tracking: coleta os ROWIDs no acesso através de index range scan/fetch pelo ROWID.
  • Full-table-scan tracking
• Timestamp da última modificação

Todas as atividades a nível de segmento são automaticamente liberadas por persistência através do agendamento utilizando o DBMS_SCHEDULER que roda de hora em hora.

Para usar as políticas de ADO você deve habilitar o rastreamento de atividades, também conhecido como Heat Map. Existe um novo parâmetro de instância chamado HEAT_MAP:

SQL> alter system set heat_map = on scope=both;
System altered.

Ações do ADO

Segue abaixo as ações que uma política ADO pode automatizar:

• Comprimir os dados quando necessário (Compression)
• Mover os segmentos quando necessário (Tiering)

Compression

A primeira ação possível para uma política ADO é a compressão. Isso pode ocorrer quando os dados são inseridos, atualizados ou carregados através de bulk-load em uma tabela. Existem quatro tipos de compressão que podem ser executadas por uma política ADO.  É importante observar que a compressão HCC só pode ser executada quando se utiliza Storage Appliances/Servers específicos:

• ROW STORE COMPRESS [BASIC]
• ROW STORE COMPRESS ADVANCED

Nome novo dado para a compressão OLTP

• COLUMN STORE COMPRESS FOR QUERY LOW / HIGH

Fornece um maior nível de compressão do que o ROW STORE. Destina-se a situações em que as consultas são utilizadas frequentemente, porém não são esperados comandos DML.

• COLUMN STORE COMPRESS FOR ARCHIVE LOW / HIGH

Fornece um maior nível de compressão do que o ROW STORE. Destina-se a situações em que as consultas não são utilizadas frequentemente. Também não são esperados comandos DML.

Tiering

Outra ação possível de uma política ADO é o storage tiering, o que significa que os dados devem ser transferidos para um nível de armazenamento diferente. Pode ser um storage de armazenamento de menor custo, ou um storage de armazenamento de alta performance que utilize tecnologias de compactação como o HCC (Hybrid Columnar Compression).
O único escopo possível para a ação do tiering é o segmento.
Políticas a nível de segmento com ações de tiering são executadas apenas uma vez na vida da política. Uma vez que ele é executado, a política é desativada.

Criando políticas ADO

Fornece a capacidade de declarar políticas em diferentes níveis de escopo no banco de dados: tabela, objeto e registro. É um procedimento que executa as operações registradas para o objeto solicitado para levá-los ao estado necessário, sem qualquer intervenção do usuário.

Políticas de compressão sobre Tablespaces e Grupos

Comprimir a tablespace USER_DATA e todos os seus segmentos utilizando compressão OLTP após 30 dias de baixo acesso:

ALTER TABLESPACE USER_DATA ILM ADD POLICY
ROW STORE COMPRESS ADVANCED
SEGMENT AFTER 30 DAYS OF LOW  ACCESS;

Comprimir a tabela ORDER_ITEMS incluindo qualquer SecureFile LOB utilizando compressão OLTP após 90 dias sem modificações.

ALTER TABLE ORDER_ITEMS ILM ADD POLICY
ROW STORE COMPRESS ADVANCED
GROUP AFTER 90 DAYS OF NO  MODIFICATION;

Comprimir a partição ORDER_ITEMS_AUGUST_2014 da tabela ORDER_ITEMS incluindo qualquer SecureFile LOB utilizando compressão HCC ARCHIVE HIGH após 6 meses sem acesso.

ALTER TABLE ORDER_ITEMS MODIFY PARTITION  ORDER_ITEMS_AUGUST_2014 ILM ADD POLICY
COLUMN STORE COMPRESS FOR ARCHIVE HIGH
GROUP AFTER 6 MONTHS OF NO ACCESS;

Políticas de compressão sobre Segmentos e Registros

Comprimir a tabela ORDER_ITEMS utilizando compressão HCC ARCHIVE QUERY HIGH após 90 dias sem modificações.

ALTER TABLE ORDER_ITEMS ILM ADD POLICY
COLUMN  STORE COMPRESS FOR QUERY HIGH
SEGMENT  AFTER 90 DAYS OF NO MODIFICATION;

Comprimir a tabela ORDER_ITEMS utilizando compressão HCC ARCHIVE HIGH após 6 meses de baixo acesso.

ALTER TABLE ORDER_ITEMS ILM ADD POLICY
COLUMN  STORE COMPRESS FOR ARCHIVE HIGH
SEGMENT  AFTER 6 MONTHS OF LOW ACCESS;

Comprimir a tabela ORDER_ITEMS utilizando compressão OLTP após 6 meses sem acesso.

ALTER TABLE ORDER_ITEMS ILM ADD POLICY
ROW STORE  COMPRESS ADVANCED
SEGMENT  AFTER 6 MONTHS OF NO ACCESS;

Políticas de Storage Tiering

Políticas ADO de Storage Tiering representam a segunda ação que podem ser automatizadas utilizando o ADO. O único escopo possível para movimentação de dados é o segmento.
The following example below shows describes the creation of an ADO policy that is to move partition ORDER_ITEMS_AUGUST_2014 of table ORDER_ITEMS to a tablespace named SECONDARY_STORAGE when the source tablespace which contains the partition has reached the fullness threshold:

O exemplo a seguir mostra a criação de uma política ADO que irá mover a partição ORDER_ITEMS_AUGUST_2014 da tabela ORDER_ITEMS para uma tablespace chamada SECONDARY_STORAGE quando a tablespace de origem atingir o limite definido:
ALTER TABLE ORDER_ITEMS ILM MODIFY PARTITION ORDER_ITEMS_AUGUST_2014
ILM ADD POLICY TIER TO SECONDARY_STORAGE;

O limite da tablespace pode ser consultado e definido da seguinte maneira:

SELECT * FROM dba_ilmparameters;

NAME                      VALUE
------------------------- ----------
TBS PERCENT USED          85
TBS PERCENT FREE          25

Para alterar o limite da tablespace, utilize a package DBMS_ILM_ADMIN:

EXEC  DBMS_ILM_ADMIN.CUSTOMIZE_ILM(DBMS_ILM_ADMIN.TBS_PERCENT_FREE,15);

Existe uma opção para definir o segmento como READ ONLY após ser movido.

ALTER TABLE ORDER_ITEMS ILM ADD POLICY
TIER  TO SECONDARY_STORAGE
READ  ONLY;

ALTER TABLE ORDER_ITEMS MODIFY PARTITION  ORDER_ITEMS_AUGUST_2014 ILM ADD POLICY 
TIER TO SECOND_STORAGE
READ ONLY;

Políticas personalizadas

Políticas ADO também permitem uma maior flexibilidade aceitando funções criadas pelo usuário.

O exemplo a seguir demonstra uma função PL/SQL que irá “conduzir” uma política ADO:

CREATE FUNCTION CUSTOM_ILM_RULE 
(pcontext in  VARCHAR2(20) RETURN BOOLEAN
vdaysBeforeArchival    ERP_PARAMETERS.daysBeforeArchiving%TYPE;   
vlastArchivalDate      ERP_PARAMETERS.lastArchivalDate%TYPE;
BEGIN
  IF (pcontext = 'ERP_CONTEXT ') THEN
   BEGIN
     SELECT daysBeforeArchival,
            lastArchivalDate
     INTO vdaysBeforeArchival,
          vlastArchivalDate
     FROM  ERP_PARAMETERS
     WHERE  id = SYS_CONTEXT(pcontext, 'APPLICATION_ID ');
  IF  ((SYSDATE – vlastArchivalDate) >= vdaysBeforeArchival) THEN
     RETURN TRUE;
  END IF;
EXCEPTION
  WHEN  OTHERS THEN
  NULL;
  END;
ELSE
  RETURN  TRUE;
  END IF;
  RETURN FALSE;
END;

Em seguida, as políticas ADO podem ser criadas fazendo o uso da função acima como se segue:

ALTER TABLE ORDER_ITEMS ILM ADD POLICY
ROW  STORE COMPRESS ADVANCED
SEGMENT ON CUSTOM_ILM_RULE;

ALTER TABLE ORDER_ITEMS MODIFY PARTITION  ORDER_ITEMS_AUGUST_2014 
ILM  ADD POLICY
TIER  TO SECOND_STORAGE 
ON  CUSTOM_ILM_RULE;

Herança de Políticas

Observe as seguintes regras ao criar políticas ADO em vários escopos:

• A política a nível de filho substitui a política a nível pai com mesma ação
• A política a nível de tabela:
  • Substitui  a política a nível de tablespace
  • É herdada a nível de partição
• A herança é aditivo para diferentes ações em políticas

A view DBA_ILMOBJECTS mostra todas as políticas herdadas por um objeto. Existe um campo para indicar o nível de onde as políticas foram herdadas.

Exemplo:

SELECT POLICY_NAME “POLICY”, OBJECT_NAME,
SUBOBJECT_NAME “SUBOBJECT”,
OBJECT_TYPE,
INHERITED_FROM
ROM  DBA_ILMOBJECTS;

POLICY    OBJECT_NAME SUBOBJECT   OBJECT_TYPE     INHERITED_FROM
--------- ----------- ---------- ---------------  ----------------------------
P281      T1                     TABLE            TABLESPACE
P341      SALES                  TABLE            POLICY NOT INHERITED
P341      SALES       SALES_1994 TABLE  PARTITION TABLE
P341      SALES       SALES_1996 TABLE  PARTITION TABLE
P350      T3                     TABLE            POLICY NOT INHERITED
P360      SALES       SALES_1995 TABLE PARTITION  POLICY NOT INHERITED
P610      T4                     TABLE            POLICY NOT INHERITED
P281      T5                     TABLE            TABLESPACE

Exibindo os dados sobre as políticas ADO

Uma vez que as políticas ADO foram implementadas, as views do banco de dados podem ser utilizadas para verificar a configuração e também para monitorar. As views também podem confirmar se ações como a movimentação de dados e a compressão estão ocorrendo automaticamente.

A view DBA_ILMPOLICIES lista todas as políticas e seus status:

SELECT * FROM DBA_ILMPOLICIES;

POLICY_NAME POLICY_TYPE    TABLESPACE            ENABLED
----------- -------------- --------------------- -------
P281        DATA  MOVEMENT                       YES
P381        DATA  MOVEMENT                       YES
P400        DATA  MOVEMENT SECOND_STORAGE

SELECT policy_name,
action_type,
compression_level,
tier_tablespace TBS
FROM DBA_ILMDATAMOVEMENTPOLICIES;

POLICY_NAME          ACTION_TYPE COMPRESSION_LEVEL       TBS
-------------------- ----------- ----------------------- ---
P281                 COMPRESSION QUERY HIGH
P381                 COMPRESSION ADVANCED
P400                 STORAGE ITB 

SELECT policy_name POL,
action_type,
scope,
condition_type,
condition_days
FROM  DBA_ILMDATAMOVEMENTPOLICIES;

POL   ACTION_TYPE  SCOPE   CONDITION_TYPE         CONDITION_DAYS
----- -----------  ------- ---------------------- --------------
P341  COMPRESSION  GROUP   LAST MODIFICATION TIME             90
P342  COMPRESSION  ROW     LAST MODIFICATION TIME             30
P361  COMPRESSION  GROUP   LAST ACCESS TIME                  180
P381  COMPRESSION  SEGMENT LAST MODIFICATION TIME             90
P382  COMPRESSION  SEGMENT LOW ACCESS                        180
P401  COMPRESSION  SEGMENT LAST ACCESS TIME                  180
P402  STORAGE      SEGMENT                                     0
P321  COMPRESSION  SEGMENT LOW ACCESS                         30
P461  COMPRESSION  SEGMENT USER DEFINED                        0
P462  STORAGE      SEGMENT USER DEFINED                        0
P482  COMPRESSION  SEGMENT LAST MODIFICATION TIME             30
P681  COMPRESSION  GROUP   LAST ACCESS TIME                  180

Monitorando as estatísticas de Heat Map através das views

Uma vez que o Heat Map esteja habilitado, as estatísticas são coletadas para diferentes atividades. O ADO fará uso destas estatísticas para disparar ações após a avaliação.
Estas estatísticas podem ser visualizadas através do Enterprise Manager Total Cloud Control 12c ou através de views do banco de dados.

Nível de Segmento (Segment-Level)

• DBA_HEAT_MAP_SEG_HISTOGRAM
• DBA_HEAT_MAP_SEGMENT

O exemplo a seguir demonstra como a view DBA_HEAT_MAP_SEG_HISTOGRAM pode ser utilizada para monitorar as atividades a nível de segmento:

set  linesize 200
col  object_name  for a30
col  subobject_name for a30
set  pages 100
alter  session set nls_date_format='DD-MON-YY HH24:MI:SS';

SELECT  object_name, 
subobject_name,
track_time,
segment_write WRI,
full_scan FTS,
lookup_scan LKP 
FROM USER_HEAT_MAP_SEG_HISTOGRAM
WHERE object_name = 'ORDER_ITEMS'
ORDER BY track_time;

OBJECT_NAME                    SUBOBJECT_NAME                 TRACK_TIME         WRI FTS LKP
------------------------------ ------------------------------ ------------------ --- --- ---
ORDER_ITEMS                    ORDER_ITEMS_NOVEMBER_2014      22-AUG-14 23:08:11 NO  YES YES
ORDER_ITEMS                    ORDER_ITEMS_AUGUST_2014        22-AUG-14 23:08:11 NO  YES YES
ORDER_ITEMS                    ORDER_ITEMS_FUTURE             22-AUG-14 23:08:11 NO  YES YES
ORDER_ITEMS                    ORDER_ITEMS_OCTOBER_2014       22-AUG-14 23:08:11 NO  YES YES
ORDER_ITEMS                    ORDER_ITEMS_DECEMBER_2014      22-AUG-14 23:08:11 NO  YES YES
ORDER_ITEMS                    ORDER_ITEMS_PAST               22-AUG-14 23:08:11 NO  YES YES
ORDER_ITEMS                    ORDER_ITEMS_SEPTEMBER_2014     22-AUG-14 23:08:11 NO  YES YES
ORDER_ITEMS                    ORDER_ITEMS_NOVEMBER_2014      25-AUG-14 08:04:52 YES NO  NO
ORDER_ITEMS                    ORDER_ITEMS_FUTURE             25-AUG-14 08:04:53 YES NO  YES
ORDER_ITEMS                    ORDER_ITEMS_DECEMBER_2014      25-AUG-14 08:04:53 YES NO  YES

Verificando a última atividade nos segmentos:

set  linesize 200
col object_name  for a11
col  subobject_name for a25
set  pages 100
alter  session set nls_date_format='DD-MON-YY HH24:MI:SS';

SELECT  object_name,
subobject_name,
segment_write_time WRITE_T,
segment_read_time READ_T,
full_scan FTS_T,
lookup_scan LKP_T
FROM USER_HEAT_MAP_SEGMENT
WHERE object_name    = 'ORDER_ITEMS'
AND subobject_name = 'ORDER_ITEMS_DECEMBER_2014';

SUBOBJECT_NAME            WRITE_T            READ_T             FTS_T              LKP_T
------------------------- ------------------ ------------------ ------------------ ------------------
ORDER_ITEMS_DECEMBER_2014 25-AUG-14 08:04:53                    22-AUG-14 23:08:11 25-AUG-14 15:31:04
ORDER_ITEMS_DECEMBER_2014 25-AUG-14 08:04:53                    22-AUG-14 23:08:11 25-AUG-14 15:31:04
ORDER_ITEMS_DECEMBER_2014 25-AUG-14 08:04:53                    22-AUG-14 23:08:11 25-AUG-14 15:31:04
ORDER_ITEMS_DECEMBER_2014 25-AUG-14 08:04:53                    22-AUG-14 23:08:11 25-AUG-14 15:31:04
ORDER_ITEMS_DECEMBER_2014 25-AUG-14 08:04:53                    22-AUG-14 23:08:11 25-AUG-14 15:31:04
ORDER_ITEMS_DECEMBER_2014 25-AUG-14 08:04:53                    22-AUG-14 23:08:11 25-AUG-14 15:31:04
ORDER_ITEMS_DECEMBER_2014 25-AUG-14 08:04:53                    22-AUG-14 23:08:11 25-AUG-14 15:31:04
ORDER_ITEMS_DECEMBER_2014 25-AUG-14 08:04:53                    22-AUG-14 23:08:11 25-AUG-14 15:31:04

Nível de bloco (Block Level)

Uma vez que os registros são modificados, é possível monitorar o tempo de modificação dos blocos do banco de dados usando a função DBMS_HEAT_MAP.block_heat_map.

O exemplo a seguir utiliza a função DBMS_HEAT_MAP.block_heat_map para monitorar a última modificação dos blocos do banco de dados que pertencem a tabela ORDER_ITEMS:

set  linesize 200
col segment_name  for a30
col tablespace_name  for a30
set  pages 100
alter  session set nls_date_format='DD-MON-YY HH24:MI:SS'

SELECT  segment_name,
tablespace_name,
block_id,
writetime 

FROM table(dbms_heat_map.block_heat_map (owner=>'DDAMEDA',
segment_name=> 'ORDER_ITEMS',
partition_name=> NULL,
sort_columnid=>8,
sort_order=>'ASC'));

Nível de extensão (Extent Level)

Uma vez que os registros são modificados, as estatísticas agregadas por extensões podem ser consultadas usando a função DBMS_HEAT_MAP.EXTENT_HEAT_MAP. Esta função exibe o tempo mínimo e máximo a nível de extent.

A consulta a seguir mostra a data da última modificação de cada extent do segmento ORDER_ITEMS:

set  linesize 200
col segment_name  for a30
set  pages 100
alter  session set nls_date_format='DD-MON-YY HH24:MI:SS'

SELECT  segment_name,
block_id,
blocks,
max_writetime
FROM  table(dbms_heat_map.extent_heat_map ('DDAMEDA','ORDER_ITEMS'));

Acompanhamento da Execução

Os resultados das execuções dos jobs do ADO podem ser consultados através das seguintes views:

• DBA_ILMTASKS:  Esta view contém informações sobre as tarefas ADO.
• DBA_ILMEVALUTATIONDETAILS: Esta view contém informações detalhadas sobre a execução de tarefas ADO.
• DBA_ILMRESULTS: Esta view fornece informações sobre os jobs do ADO.

Exemplos:

SELECT  * FROM dba_ilmtasks;

TASK_ID TASK_OWNER STATE     CREATION_TIME START_TIME COMPLETION_TIME
------- ---------- --------- ------------- ---------- ---------------
100     DDAMEDA    INACTIVE  12-DEC-12
154     DDAMEDA    ACTIVE    11-DEC-12     12-DEC-12

SELECT  task_id,
policy_name,
object_name,
selected_for_execution,
job_name
FROM dba_ilmevaluationdetails;

TASK_ID  POLICY_NAME   OBJECT_NAME  SELECTED_FOR_EXECUTION      JOB_NAME
-------  ------------- ----------- --------------------------- ----------
18762   P281          EMPLOYEE    POLICY DISABLED
18542   P281          EMPLOYEE    SELECTED FOR EXECUTION      ILMJOB5002
18862   P301          EMPLOYEE    PRECONDITION NOT SATISFIED

SELECT  task_id,
cast(job_name as varchar2(20))
job_name,
job_state,
completion_time
FROM DBA_ILMRESULTS;

TASK_ID JOB_NAME  JOB_STATE              COMPLETION_TIME
------- --------- ---------------------- -----------------
669     ILMJOB59  COMPLETED SUCCESSFULLY 28/09/2011

Habilitando e Desabilitando o ADO e o Heat Map

Para ativar todas as políticas ADO de um objeto, podemos utilizar o seguinte comando:

ALTER  TABLE ORDER_ITEMS ILM ENABLE ALL;
ALTER  TABLE ORDER_ITEMS MODIFY PARTITION ORDER_ITEMS_AUGUST_2014 ILM ENABLE_ALL;

Para desativar todas as políticas ADO de um objeto:

ALTER  TABLE ORDER_ITEMS ILM DISABLE_ALL;

Para remover todas as políticas ADO de um objeto:

ALTER  TABLE ORDER_ITEMS ILM DELETE_ALL;
ALTER  TABLE ORDER_ITEMS MODIFY PARTITION ORDER_ITEMS_AUGUST_2014 ILM DELET_ALL;

Também é possível desligar o ADO sem desativar ou excluir quaisquer políticas, da seguinte forma:

exec  DBMS_ILM_ADMIN.DISABLE_ILM;
exec  DBMS_ILM_ADMIN.ENABLE_ILM;

Checando os parâmetros do ADO:

select * from DBA_ILMPARAMETERS where name='ENABLED';

NAME               VALUE
------------------ -------
ENABLED            1

Rastreamento de atividade

Para parar o rastreamento de atividade na sessão atual:

ALTER SESSION SET HEAT_MAP = OFF; 

Para parar o rastreamento de atividade na instância:

ALTER SYSTEM SET HEAT_MAP = OFF;

Para limpar todas as estatísticas de HEAT MAP:

exec DBMS_ILM_ADMIN.CLEAR_HEAT_MAP_ALL;
 

Referências

• Oracle Database VLDB and Partitioning Guide 12c Release 1 (12.1)
• Oracle Database Administrator's Guide 12c Release 1 (12.1)
• Oracle Database PL/SQL Packages and Types Reference 12c Release 1 (12.1) –

“DBMS_ILM”, “DBMS_ILM_ADMIN” , and “DBMS_HEAT_MAP” chapters

Oracle Learning Library

• Oracle Database 12c New Features Demo Series demonstrations:
  • Online data file Move
• Oracle By Example (OBE):
  • Setting Up Compression Tiering for Automatic Data Optimization
  • Setting Up Storage Tiering Automatic Data Optimization

Alex Zaballa, formado em Análise de Sistemas, é especialista em Banco de Dados Oracle com sólidos conhecimentos em Servidores de Aplicação e Sistemas Operacionais; trabalha com Oracle há 15 anos, é ORACLE ACE, certificado OCM Database 11G / Cloud e conta com mais de 140 outras certificações em produtos da Oracle. Alex também é fundador do Grupo de Usuários Oracle de Angola (GUOA) e membro do time OraWorld.

Daniel Da Meda, possui mais de 16 anos de experiência com tecnologias Oracle. Trabalhou como DBA sênior para múltiplas empresas na Europa onde morou por 7 anos. Dentre as empresas que atuou, destacam-se TimeWarner, Johnson&Johnson e British Film Institute. Dentre as certificações Oracle que possui, destaca-se o OCM 11g. É especialista em alta disponibilidade, escalabilidade e Performance Tuning. Juntamente com o Alex Zaballa, fundou em 2013, o grupo de Usuários Oracle de Angola (GUOA).

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle.