O background é em homenagem a este estimável(ou lastimável) OS.
O background é em homenagem a este estimável(ou lastimável) OS.
Simple Write-Up
Monday, March 30, 2009
Saturday, March 28, 2009
Thursday, March 19, 2009
Segmet Advisor em bloco PL/SQL
Olá,
Abaixo segue um exemplo do uso do Segment Advisor dentro do bloco PL/SQL e ao final as views que devem ser consultadas para recuperar as recomendações.
--Inicio do bloco pl/sql
variable id number ;
BEGIN
DECLARE
name_task varchar2(100);
desc_task varchar2(500);
obj_id number ;
begin
execute immediate 'alter table cmt.userdocuments enable row movement';
--name_task := 'Segment Advisor example on userdocuments' ;
name_task :=''; --vai ser gerado pelo creaste task
desc_task := 'Teste do uso de segment advisor na tabela userdocuments';
dbms_advisor.create_task(
advisor_name => 'Segment Advisor',
task_id => :id,
task_name => name_task,
task_desc => desc_task );
/*dbms_advisor.create_object(
task_name => name_task,
object_type =>'TABLE',
attr1 => 'CMT',
attr2 => 'USERDOCUMENTS',
-- attr3 => null,
-- attr4 => null,
-- attr5 => null,
obj_id => obj_id) ;*/
dbms_advisor.create_object(name_task,'TABLE','CMT','USERDOCUMENTS',NULL,NULL,obj_id) ;
dbms_advisor.set_task_parameter(
task_name => name_task,
parameter => 'recommend_all',
value => 'TRUE');
dbms_advisor.execute_task (name_task) ;
end;
END;
select owner,task_id,task_name,type,message,more_info from dba_advisor_findings
where task_id = 28198
select owner,task_id,task_name,benefit_type
from dba_advisor_recommendations
where task_id = 28198
select owner,task_id,task_name,command,attr1
from dba_advisor_actions
where task_id = 28198
Abaixo segue um exemplo do uso do Segment Advisor dentro do bloco PL/SQL e ao final as views que devem ser consultadas para recuperar as recomendações.
--Inicio do bloco pl/sql
variable id number ;
BEGIN
DECLARE
name_task varchar2(100);
desc_task varchar2(500);
obj_id number ;
begin
execute immediate 'alter table cmt.userdocuments enable row movement';
--name_task := 'Segment Advisor example on userdocuments' ;
name_task :=''; --vai ser gerado pelo creaste task
desc_task := 'Teste do uso de segment advisor na tabela userdocuments';
dbms_advisor.create_task(
advisor_name => 'Segment Advisor',
task_id => :id,
task_name => name_task,
task_desc => desc_task );
/*dbms_advisor.create_object(
task_name => name_task,
object_type =>'TABLE',
attr1 => 'CMT',
attr2 => 'USERDOCUMENTS',
-- attr3 => null,
-- attr4 => null,
-- attr5 => null,
obj_id => obj_id) ;*/
dbms_advisor.create_object(name_task,'TABLE','CMT','USERDOCUMENTS',NULL,NULL,obj_id) ;
dbms_advisor.set_task_parameter(
task_name => name_task,
parameter => 'recommend_all',
value => 'TRUE');
dbms_advisor.execute_task (name_task) ;
end;
END;
select owner,task_id,task_name,type,message,more_info from dba_advisor_findings
where task_id = 28198
select owner,task_id,task_name,benefit_type
from dba_advisor_recommendations
where task_id = 28198
select owner,task_id,task_name,command,attr1
from dba_advisor_actions
where task_id = 28198
Segment Advisor and Shrink database segnments online.Porque usar esta feature?
by Julio Cesar Correa
Shrink database segnments
Para que possamos compactar o espaço causado pela fragmentação baixo da HWM(high water mark).Depois do shrink a HWM é movida para baixo
e assim colocando disponivel o espaço que antes não poderia ser utilizado.
Quando é feito um insert/apdate em que a tabela é aumentada(tamanho em blocos).A HWM informa a quantidade de blocos alocados para este segmento.
O caso pe que quando acontece um delete/update em que o tamanho sda tabela fisica é diminuido, a HWM não é atualizada para baixo,ou seja,não é atualizada
com a informação que diminuiu de tamanho.Portanto existe espaço livre neste segmento,mas ele não pode ser utilizado.
Até que executemos um online segment shrink,que vai ajustar a marca d'agua ou HMW.
O segmento tem que ser elegível ao online segment shrink.Caso não seja,o DBA poderá usar online table redefinition via EM ou DBMS_REDEFINITION.
Vantagens:
- Pode ser feita on-line.
- Podem ocorrer queries e DML's normalmente no segmento,porem no final da operação os DML's serão bloqueados por um curto perido de tempo.
- Os indices são mantidos,porem só é possivel usá-lo no final da operação.
- Não requer mais espaço para a operação(diferente de online table redefinition)
Restrições:
1. os seguimentos devem estar em uma tablespace LMT(locally managed tablespace) com ASSM(automatic segment space management).
2. todos os seguimentos dentro do intem um são elegíveis exceto: IOT's,tabelas com materialized views baseada em rowid e tabelas com indices
baseados em função(function-based indexes)
requerimentos:
Habilitar a movimentação de linhas na tabela.
ALTER TABLE table_name ENABLE ROW MOVEMENT ;
--Inicio do bloco pl/sql
variable id number ;
DECLARE
name_task varchar2(100);
desc_task varchar2(500);
obj_id number ;
BEGIN
--execute immediate 'alter table cmt.userdocuments enable row movement';
begin
name_task := '' ;
desc_task := 'Teste do uso de segment advisor na tabela userdocuments';
dbms_advisor.create_task(
advisor_name => 'Segment Advisor',
task_id => :id,
task_name => name_task,
task_desc => desc_task );
/*dbms_advisor.create_object(
task_name => name_task,
object_type =>'TABLE',
attr1 => 'CMT',
attr2 => 'USERDOCUMENTS',
attr3 => null,
attr4 => null,
attr5 => null,
obj_id => obj_id) ; */
dbms_advisor.create_object(name_task,'TABLE','CMT','USERDOCUMENTS',NULL,NULL,obj_id) ;
dbms_advisor.set_task_parameter(
task_name => name_task,
parameter => 'recommend_all',
value => 'TRUE');
dbms_advisor.execute_task (name_task) ;
end;
END;
Shrink database segnments
Para que possamos compactar o espaço causado pela fragmentação baixo da HWM(high water mark).Depois do shrink a HWM é movida para baixo
e assim colocando disponivel o espaço que antes não poderia ser utilizado.
Quando é feito um insert/apdate em que a tabela é aumentada(tamanho em blocos).A HWM informa a quantidade de blocos alocados para este segmento.
O caso pe que quando acontece um delete/update em que o tamanho sda tabela fisica é diminuido, a HWM não é atualizada para baixo,ou seja,não é atualizada
com a informação que diminuiu de tamanho.Portanto existe espaço livre neste segmento,mas ele não pode ser utilizado.
Até que executemos um online segment shrink,que vai ajustar a marca d'agua ou HMW.
O segmento tem que ser elegível ao online segment shrink.Caso não seja,o DBA poderá usar online table redefinition via EM ou DBMS_REDEFINITION.
Vantagens:
- Pode ser feita on-line.
- Podem ocorrer queries e DML's normalmente no segmento,porem no final da operação os DML's serão bloqueados por um curto perido de tempo.
- Os indices são mantidos,porem só é possivel usá-lo no final da operação.
- Não requer mais espaço para a operação(diferente de online table redefinition)
Restrições:
1. os seguimentos devem estar em uma tablespace LMT(locally managed tablespace) com ASSM(automatic segment space management).
2. todos os seguimentos dentro do intem um são elegíveis exceto: IOT's,tabelas com materialized views baseada em rowid e tabelas com indices
baseados em função(function-based indexes)
requerimentos:
Habilitar a movimentação de linhas na tabela.
ALTER TABLE table_name ENABLE ROW MOVEMENT ;
--Inicio do bloco pl/sql
variable id number ;
DECLARE
name_task varchar2(100);
desc_task varchar2(500);
obj_id number ;
BEGIN
--execute immediate 'alter table cmt.userdocuments enable row movement';
begin
name_task := '' ;
desc_task := 'Teste do uso de segment advisor na tabela userdocuments';
dbms_advisor.create_task(
advisor_name => 'Segment Advisor',
task_id => :id,
task_name => name_task,
task_desc => desc_task );
/*dbms_advisor.create_object(
task_name => name_task,
object_type =>'TABLE',
attr1 => 'CMT',
attr2 => 'USERDOCUMENTS',
attr3 => null,
attr4 => null,
attr5 => null,
obj_id => obj_id) ; */
dbms_advisor.create_object(name_task,'TABLE','CMT','USERDOCUMENTS',NULL,NULL,obj_id) ;
dbms_advisor.set_task_parameter(
task_name => name_task,
parameter => 'recommend_all',
value => 'TRUE');
dbms_advisor.execute_task (name_task) ;
end;
END;
DBMS_SCHEDULER - Alteração de atributo do JOB
Um exemplo simples de alteração de um atributo de um JOB via DBMS_SCHEDULER.
C:\Documents and Settings\jcorrea>sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Sex Mar 6 10:34:37 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
idle> conn jccorrea@cmt
Informe a senha:
Conectado.
jccorrea@CMT> select repeat_interval from dba_scheduler_jos
2
jccorrea@CMT> select repeat_interval from dba_scheduler_jobs
2 where job_name='EXEC_PRC_SEARCH_DUP_TSN';
REPEAT_INTERVAL
------------------------------------------------------------------------------------------
----------
FREQ = WEEKLY ; INTERVAL= 1
jccorrea@CMT> begin
2 dbms_scheduler.set_scheduler_attribute('EXEC_PRC_SEARCH_DUP_TSN','REPEAT_INTERVAL','F
REQ = DAILY; interval=1');
3 end;
4 /
dbms_scheduler.set_scheduler_attribute('EXEC_PRC_SEARCH_DUP_TSN','REPEAT_INTERVAL','FREQ =
DAILY; interval=1');
*
ERRO na linha 2:
ORA-06550: line 2, column 1:
PLS-00306: wrong number or types of arguments in call to 'SET_SCHEDULER_ATTRIBUTE'
ORA-06550: line 2, column 1:
PL/SQL: Statement ignored
jccorrea@CMT> begin
2 dbms_scheduler.set_attribute('EXEC_PRC_SEARCH_DUP_TSN','REPEAT_INTERVAL','FREQ = DAIL
Y; interval=1');
3 end;
4 /
Procedimento PL/SQL concluÝdo com sucesso.
jccorrea@CMT> select repeat_interval from dba_scheduler_jobs
2 where job_name='EXEC_PRC_SEARCH_DUP_TSN';
REPEAT_INTERVAL
------------------------------------------------------------------------------------------
----------
FREQ = DAILY; interval=1
jccorrea@CMT>
Abs,
C:\Documents and Settings\jcorrea>sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Sex Mar 6 10:34:37 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
idle> conn jccorrea@cmt
Informe a senha:
Conectado.
jccorrea@CMT> select repeat_interval from dba_scheduler_jos
2
jccorrea@CMT> select repeat_interval from dba_scheduler_jobs
2 where job_name='EXEC_PRC_SEARCH_DUP_TSN';
REPEAT_INTERVAL
------------------------------------------------------------------------------------------
----------
FREQ = WEEKLY ; INTERVAL= 1
jccorrea@CMT> begin
2 dbms_scheduler.set_scheduler_attribute('EXEC_PRC_SEARCH_DUP_TSN','REPEAT_INTERVAL','F
REQ = DAILY; interval=1');
3 end;
4 /
dbms_scheduler.set_scheduler_attribute('EXEC_PRC_SEARCH_DUP_TSN','REPEAT_INTERVAL','FREQ =
DAILY; interval=1');
*
ERRO na linha 2:
ORA-06550: line 2, column 1:
PLS-00306: wrong number or types of arguments in call to 'SET_SCHEDULER_ATTRIBUTE'
ORA-06550: line 2, column 1:
PL/SQL: Statement ignored
jccorrea@CMT> begin
2 dbms_scheduler.set_attribute('EXEC_PRC_SEARCH_DUP_TSN','REPEAT_INTERVAL','FREQ = DAIL
Y; interval=1');
3 end;
4 /
Procedimento PL/SQL concluÝdo com sucesso.
jccorrea@CMT> select repeat_interval from dba_scheduler_jobs
2 where job_name='EXEC_PRC_SEARCH_DUP_TSN';
REPEAT_INTERVAL
------------------------------------------------------------------------------------------
----------
FREQ = DAILY; interval=1
jccorrea@CMT>
Abs,
Considerações sobre Undo Tablespace
Abaixo uma reposta que enviei no fórum de discussão sobre duvidas com undo tablespace.
Colega,Undo Tablespaces não armazenam objetos(ex. table,index),mas sim armazenam "imagens" de uma transação(do dado propriamente dito) antes deste dado ser modificado,isto para promover um situação chamada de leitura consistente.além de outras funcionalidades que ela tem como Rollback,Oracle Flashback Query e principalmente Recover Database.
Primeiro você deveria se perguntar porque você precisa mexer com uma tablespace que está lá "quietinha".
Você pode ter mais de uma Undo Tablespace no seu banco,mas só uma pode ser "setada" como ativa,e é esta que o seu " Oracle" vai usar para gerenciar Rollback,recover,flashback ,você estiver usando essa feature.Você pode criar uma nova Undo Tbs e dar um DROP na antiga.Você pode dar um RESIZE no datafile e redimensionar sua undo tbs.Você pode alterar os parametros com UNDO_RETENTION = XXX com ALTER SYSTEM SET,pode dar um ALTER TABLESPACE , e alterar uma tablespace com RETENTION GUARANTEE ou NOGUARANTEE(isso tem que ser analisado com cuidado),primcipalmente se o seu banco é de "PROD".Enfim tem uma serie de coisas que você pode fazer com Undo Tablespace,dependendo é claro da sua NECESSIDADE.
Pelo que você mencionou você está usando UNDO_RETENTION com um valor especificado em 900(segundos).
Dê uma olhada na DBA_TABLESPACES para ver se você está usando RETENTION GUARANTEE ou não.Isso pode afetar muito,principalmente se sua TABLESPACE não foi criada com AUTOEXTEND.
Algumas coisas interessantes que você deve saber é que:
-Se sua tablespace está com AUTOEXTEND ela crescerá conforme a necessidade do seu banco Oracle.Senão você terá que dimensionar manualmente o datafile.
- Se estiver com RETENTION GUARANTEE,o Oracle vai "preservar"garantindo a 'imagem" do seu dado antigo pelo periodo especificado no UNDO_RETENTION.Senão estiver com a opção GUARANTEE ,caso o Oracle necessite de espaço para uma imagem de uma nova transação,e sua tablespace não estiver com AUTOEXTEND ele irá sobrescrever as imagens das suas transações anteriores "expiradas" e "else if" ainda não tiver espaço suficiente o Oracle vai começar a sobrescrever as imagens anteriores "não-expiradas"(então começa um problemão).
Resposta a uma questão sobre Materialized view e External Table
Olá,
Estes dias surgiu um pergunta no grupo de discussão Oracle_Br,uma pergunta de uma pessoa que estava estudando sobre Performance Tunning.
A questão era sobre criar uma Materialized View sobre uma External Table.
Não sei porque e nem como surgiu esta questão ,mas resolvi fazer um teste para ver no que dava.Encontrei um post no forum internacional em que Donald Burleson cita que nunca fez isso,mas afirmava que o que poderia dar problema no ponto de vista de arquitertura do Oracle é a atualização(refresh) desta MVIEW.
O unico ponto interessante que achei nesta questão seria o fato de que se pudesse gerar um arquivo externo novo,digamos que seja uma arquivo diario e que a MVIEW automaticamente fizesse o refresh dos dados.
Abaixo os codigos da criação da external table e da materialized view que enviei para o forum para exemplo:
Segue os testes que acabei de fazer a respeito da questão.
Está mal formatado porque eu copiei e colei,mas dá para seguir a logica e os comandos
- Criei o arquivo .txt
[oracle@TAHITI dir_work]$ vi test_ext_t
[oracle@TAHITI dir_work]$ ls
- Criei o diretorio
SQL> create directory dir_work as '/u02/oradata/lab/dir_work'
2 ;
Directory created.
-Concedi as permissões
SQL> grant read,write on directory dir_work to public;
Grant succeeded.
Criei a tabela externa com base no arquivo e no diretorio
SQL> create table test_ext
2 (name varchar2(15),
3 sobrenome varchar2(15),
4 idade number(2))
5 organization external
6 (default directory dir_work
7 access parameters
8 ( records delimited by newline
fields terminated by '|'
9 10 )
11 location('test_ext_t.txt')
12 );
Table created.
-Alterei a tabela porque troquei as palavras chaves rs
SQL> alter table test_ext
2 access parameters
3 ( records delimited by newline
4 fields terminated by '|'
5 );
Table altered.
-Alterei o nome do arquivo,senão.. "don't work"
[oracle@TAHITI dir_work]$ mv text_ext_t.txt test_ext_t.txt
[oracle@TAHITI dir_work]$ exit
exit
- Testei uma consulta na rabela externa
SQL> select * from test_ext;
NAME SOBRENOME IDADE
--------------- --------------- ----------
julio correa 22
SQL>
Criei uma mview de teste
SQL> create materialized view test_mv_on_ext
2 build immediate
3 as select * from test_ext;
Materialized view created.
-Testei a query na mview criada anteriormente
SQL>
SQL> select * from test_mv_on_ext;
NAME SOBRENOME IDADE
--------------- --------------- ----------
julio correa 22
-Outro teste de criação de mview
-Tentativa de refresh na mview
SQL> begin
2 dbms_refresh('test_mv_on_ext2');
3 end;
4
Esta ultima ficou executando,mas não me retornou nada,nem mesmo errro.
O problema deve estarna hora do refresh.Por se tratar de um arquivo,caso você gere outro arquivo com o mesmo nome no diretorio, o Oracle não saberá disto.
Não sei se isto funciona,nunca fiz.Mais vou tentar um refresh ok?
Abs,
Julio Cesar Correa
Estes dias surgiu um pergunta no grupo de discussão Oracle_Br,uma pergunta de uma pessoa que estava estudando sobre Performance Tunning.
A questão era sobre criar uma Materialized View sobre uma External Table.
Não sei porque e nem como surgiu esta questão ,mas resolvi fazer um teste para ver no que dava.Encontrei um post no forum internacional em que Donald Burleson cita que nunca fez isso,mas afirmava que o que poderia dar problema no ponto de vista de arquitertura do Oracle é a atualização(refresh) desta MVIEW.
O unico ponto interessante que achei nesta questão seria o fato de que se pudesse gerar um arquivo externo novo,digamos que seja uma arquivo diario e que a MVIEW automaticamente fizesse o refresh dos dados.
Abaixo os codigos da criação da external table e da materialized view que enviei para o forum para exemplo:
Segue os testes que acabei de fazer a respeito da questão.
Está mal formatado porque eu copiei e colei,mas dá para seguir a logica e os comandos
- Criei o arquivo .txt
[oracle@TAHITI dir_work]$ vi test_ext_t
[oracle@TAHITI dir_work]$ ls
- Criei o diretorio
SQL> create directory dir_work as '/u02/oradata/lab/dir_work'
2 ;
Directory created.
-Concedi as permissões
SQL> grant read,write on directory dir_work to public;
Grant succeeded.
Criei a tabela externa com base no arquivo e no diretorio
SQL> create table test_ext
2 (name varchar2(15),
3 sobrenome varchar2(15),
4 idade number(2))
5 organization external
6 (default directory dir_work
7 access parameters
8 ( records delimited by newline
fields terminated by '|'
9 10 )
11 location('test_ext_t.txt')
12 );
Table created.
-Alterei a tabela porque troquei as palavras chaves rs
SQL> alter table test_ext
2 access parameters
3 ( records delimited by newline
4 fields terminated by '|'
5 );
Table altered.
-Alterei o nome do arquivo,senão.. "don't work"
[oracle@TAHITI dir_work]$ mv text_ext_t.txt test_ext_t.txt
[oracle@TAHITI dir_work]$ exit
exit
- Testei uma consulta na rabela externa
SQL> select * from test_ext;
NAME SOBRENOME IDADE
--------------- --------------- ----------
julio correa 22
SQL>
Criei uma mview de teste
SQL> create materialized view test_mv_on_ext
2 build immediate
3 as select * from test_ext;
Materialized view created.
-Testei a query na mview criada anteriormente
SQL>
SQL> select * from test_mv_on_ext;
NAME SOBRENOME IDADE
--------------- --------------- ----------
julio correa 22
-Outro teste de criação de mview
-Tentativa de refresh na mview
SQL> begin
2 dbms_refresh('test_mv_on_ext2');
3 end;
4
Esta ultima ficou executando,mas não me retornou nada,nem mesmo errro.
O problema deve estarna hora do refresh.Por se tratar de um arquivo,caso você gere outro arquivo com o mesmo nome no diretorio, o Oracle não saberá disto.
Não sei se isto funciona,nunca fiz.Mais vou tentar um refresh ok?
Abs,
Julio Cesar Correa
Monday, March 09, 2009
Index Monitoring
Let's go.
O Oracle fornece uma visão chamada V$OBJECT_USAGE onde podemos verificar os INDEXES que estão sendo monitorados.O ideal é monitorar os INDEXES por um tempo que o DBA tenha certeza que todas as operações possíveis(aproximadamente) tenham sido executadas.Digamos que você tenha uma rotina mensal,quinzenal e etc.O ideia é esperar esta rotina acontecer para que tenha certeza que os principais cenários tenham ocorrido.
Para habilitar a monitoração em um INDEX ,executamos o comando abaixo:
ALTER INDEX owner.index_name MONITORING USAGE ;
Após o comando ser executado com sucesso.
Conectado com o owner do INDEX monitorado,verifique a V$OBJECT_USAGE ,que estará lá a data de inicio de monitoramento bem como uma coluna USE que pode estar como TRUE ou FALSE.Estando como TRUE ,quer dizer que o seu INDEX está sendo utilizado.Estando como FALSE ele não está sendo utilizado,portanto pode ser excluído do banco de dados.
Para tirar um INDEX do monitoramento execute o comando:
ALTER INDEX index_name NOMONITORING;
Abs,
O Oracle fornece uma visão chamada V$OBJECT_USAGE onde podemos verificar os INDEXES que estão sendo monitorados.O ideal é monitorar os INDEXES por um tempo que o DBA tenha certeza que todas as operações possíveis(aproximadamente) tenham sido executadas.Digamos que você tenha uma rotina mensal,quinzenal e etc.O ideia é esperar esta rotina acontecer para que tenha certeza que os principais cenários tenham ocorrido.
Para habilitar a monitoração em um INDEX ,executamos o comando abaixo:
ALTER INDEX owner.index_name MONITORING USAGE ;
Após o comando ser executado com sucesso.
Conectado com o owner do INDEX monitorado,verifique a V$OBJECT_USAGE ,que estará lá a data de inicio de monitoramento bem como uma coluna USE que pode estar como TRUE ou FALSE.Estando como TRUE ,quer dizer que o seu INDEX está sendo utilizado.Estando como FALSE ele não está sendo utilizado,portanto pode ser excluído do banco de dados.
Para tirar um INDEX do monitoramento execute o comando:
ALTER INDEX index_name NOMONITORING;
Abs,
Wednesday, March 04, 2009
Subscribe to:
Posts (Atom)
