TUNING DE REDO LOG

Pessoal,

Neste Post vamos falar um pouco sobre um assunto que tenho muito interesse, o Tuning do Banco Oracle.
Tuning é um assunto muito grande e complexo, por isso vou atacar neste Post apenas uma parte do Tuning do Redo Log, porém de forma objetiva e eficaz.

O tamanho e a quantidade dos REDO LOG's influenciam muito no desempenho de gravação do Banco. Tanto para um processo de importação de dados quanto para instruções DML.

Para melhoria de performance a Oracle recomenda que os arquivos de Redo Log estejam em um disco diferente do disco onde localiza-se os os arquivos de dados (Data Files) e que a troca dos arquivos de redo log seja feita entre 20 à 30 minutos no máximo, pois menos causa contenção de escrita e mais que 30 minutos aumenta muito o tempo de recuperação.

Como posso identificar de quanto em quanto tempo a troca do Redo Log está sendo realizada ?

Para isso você deve fazer uma regra de três no tamanho do redo:
Ex: você tem troca de redo a cada 10 minutos, o tamanho do seu redo log é de 100MB cada grupo.
Então você deve recriar com 300MB para que o tempo suba para 30 minutos.

A query que faz esta verificação é a seguinte:

select group#,
       thread#,
       to_char(first_time,'DD/MM HH24:MI') TROCA_REDO,
       (BYTES /1024/1024) TAMANHO_MB
  FROM V$LOG ORDER BY 2, FIRST_TIME;

Como faço para alterar o tamanho dos arquivos de Redo Log ?

Abaixo segue o procedimento para realizar a alteração:

-- Para verificar o arquivo de redo log corrente:

SELECT * FROM V$LOG;


-- Para alterar/recriar o arquivo de redo log ele deve estar com STATUS INATIVO, caso necessite forçar a troca do arquivo de Redo Log, execute o comando abaixo:

ALTER SYSTEM SWITCH LOGFILE;


-- Não é possível alterar o tamanho do Redo Log já existente, portanto deve-se eliminar o arquivo ou grupo de Redo Log:

ALTER DATABASE DROP LOGFILE GROUP <<numero_grupo>>;

Exemplo:
ALTER DATABASE DROP LOGFILE GROUP 1;


-- Agora basta adicionar o novo grupo de Redo Log com o novo tamanho:

ALTER DATABASE ADD LOGFILE GROUP <<numero_grupo>> ('<<caminho dos membros>>') size <<tamanho>>;

Exemplo:
ALTER DATABASE ADD LOGFILE GROUP 1 (‘\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01A.LOG’, ‘\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01B.LOG’) SIZE 200M;


A T E N Ç Ã O ! ! !

Por padrão ao criar a Instância Oracle é criado 3 grupos de Redo Log. Porém para que a mesma possa ser iniciada é necessário no mínimo 2 grupos de Redo Log.
Enfim, ao apagar, garanta que tenha ao menos 2 grupos de Redo Log, só apague novamente outro grupo após criar mais um novo !!



Galera é isso aí !!!  Espero que esse procedimento possa ajudar a todos caso seja necessário !!

Abraços e até o próximo post,

DIEGO GARCIA FRANCISCO
DBA Oracle
Oracle Database 11g Administrator Certified Associate
(21) 7925-4500 / (21) 8714-2496

DEFERRED_SEGMENT_CREATION

Olá pessoal,

Hoje vamos falar de um parâmetro incluído no oracle 11GR2 o DEFERRED_SEGMENT_CREATION, que é a criação adiada de segmento, ou seja, só é alocado segmento na tabela quando uma linha é inserida, por default esse parâmetro vem como TRUE.

Vamos ao exemplo:

SQL> CREATE TABLE B
2 (ID NUMBER);

Tabela criada.

SQL> select segment_name from user_segments where segment_name = 'B';
não há linhas selecionadas

SQL> INSERT INTO B
2 VALUES(1);
1 linha criada.

SQL> select segment_name from user_segments where segment_name = 'B';
SEGMENT_NAME
-------------------------------------------------------------------------
B

Veja que só trouxe resultado na view user_segments após o insert.

As vantagens desse parâmetro são:

1-Economia de espaço, pois evita a alocação de segmentos em tabelas vazias.
2-Na criação da tabela não ocorrerá erros referentes a falta de privilégios ou falta de espaço em tablespace.
3-As execuções de instruções DDL ficam mais rápidas, pois não é criado segmento em disco.

Para alterar o parâmetro a nível de instância utilize o comando abaixo:

ALTER SYSTEM SET DEFERRED_SEGMENT_CREATION=[TRUE | FALSE];

Também pode ser alterado a nível de sessão:

ALTER SESSION SET DEFERRED_SEGMENT_CREATION =[TRUE | FALSE];

E a nível de tabela:

CREATE TABLE T1 (id number) SEGMENT CREATION [IMMEDIATE | DEFERRED];

Alguns pontos importantes sobre essa nova funcionalidade:

1- Só está disponível para a versão Enterprise Edition, então caso seja efetuado um export de um banco oracle 11GR2 Enterprise Edition para um banco oracle 11GR2 Standart Edition ou release/versão inferior, deve se usar o parâmetro compatibilidade (version) no expdp, pois se existir alguma tabela sem segmento, ocorrerá o erro ORA-00439: feature not enabled: Deferred Segment Creation. 

2- O utilitário EXP não reconhece tabelas sem segmentos, ou seja, se você utilizar o exp no banco 11GR2 e existir alguma tabela sem segmento, ela não será exportada.Então utilize o EXPDP ou então desabilite o parâmentro e force a criação de segmentos com o comando ALTER TABLE <<table_name>> ALLOCATE EXTENT. Esse problema foi corrigido no release 11.2.0.2.

3- No 11.2.0.2 o parâmentro também é válido para tabelas particionadas e foi adicionado 2 procedimentos ao pacote DBMS_SPACE_ADMIN para o gerenciamento de segmentos:

DBMS_SPACE_ADMIN.materialize_deferred_segments -> Força a criação de segmentos para tabela em que a criação dos segmentos foi adiada. Exemplo:

BEGIN
DBMS_SPACE_ADMIN.materialize_deferred_segments (
schema_name => 'TESTE'
table_name => 'TAB1',
nome_da_partição => NULL);
END;
/

DBMS_SPACE_ADMIN.drop_empty_segments -> Elimina os segmentos de tabelas sem linhas.
Exemplo:

BEGIN
DBMS_SPACE_ADMIN.drop_empty_segments (
schema_name => 'TESTE'
table_name => 'TAB1',
nome_da_partição => NULL);
END;
/

Até o próximo post.
Isabele Barros

CASE SENSITIVE ORACLE 11G

Olá Pessoal,

Nesse post estarei falando sobre o case sensitive, que foi implementado no oracle 11G.

A partir do oracle 11G a senha tem diferenciação entre letras maiúsculas e minúsculas.
O parâmetro que faz esse controle é o sec_case_sensitive_logon que por padrão é TRUE.

Exemplo:

SQL> CREATE USER TESTE IDENTIFIED BY TESTE;

Usuário criado.

SQL> conn TESTE/teste
ERROR:
ORA-01017: senha/nome do usuário inválido; log-on negado

SQL> conn TESTE/Teste
ERROR:
ORA-01017: senha/nome do usuário inválido; log-on negado

SQL> conn TESTE/TESTE
Conectado.

Para desabilitar essa funcionalidade basta executar o comando abaixo:

ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON= FALSE SCOPE=BOTH;

Outra mudança foi com relação a view dba_users, além de não tem incluída a informação do password, agora contém mais uma coluna a PASSWORD_VERSIONS:

Quando o valor da coluna está 10G, mesmo que o parâmetro sec_case_sensitive_logon esteja ativado, essa senha não será case sensitive.
Quando o valor da coluna está 10G 11G, a senha será case sessitive se o parâmetro sec_case_sensitive_logon estiver ativado.
Quando o valor da coluna está 11G, o usuário só poderá se conectar ao banco de dados se o parâmetro sec_case_sensitive_logon estiver ativado.

A alteração dessas informações pode ser realizada através do ALTER USER:

ALTER USER TESTE IDENTIFIED BY TESTE;

Valor da coluna PASSWORD_VERSIONS 10G 11G

ALTER USER TESTE IDENTIFIED BY VALUES '864B0E03A5061B6D';

Valor da coluna PASSWORD_VERSIONS 10G

ALTER USER TESTE IDENTIFIED BY VALUES 'S:C2876E5B7D4AF6281DB01D658FABB63E11C6BB9F8D501C73255484CC65B1';

Valor da coluna PASSWORD_VERSIONS 11G

As informações da senha criptografada você encontra na view SYS.USER$ nas colunas PASSWORD(10G) e SPARE4(11G).

Espero que tenha esclarecido um pouco sobre essas mudanças.

Até o próximo post.
Isabele Barros

Recover Desaster RMAN

********************************************************
 RESTAURAÇÃO EM DESASTRES DE BANCO DE DADOS
********************************************************

Fala galera !!!

Como é meu Post de estréia na MHDBA, não poderia falar de outro assunto se não o RMAN !!
Como todos sabem gosto muito desta ferramenta de Backup poderosa do Oracle.

Este Post mostra como recuperar um Banco de dados em outro servidor em casos de desastres/perdas de todo Banco de dados.

Tentarei sempre fazer um passo-à-passo em meus Posts para facilitar o entendimento e a execução do mesmo.
Vamos ao que interessa ...

NO NOVO SERVIDOR:

1- INSTALAR APENAS O SOFTWARE DO ORACLE SEM INSTANCIA.

2- CRIAR A MESMA ESTRUTURA DO OUTRO SERVIDOR. ( INCLUSIVE AS PASTAS - ADUMP,BDUMP.CDUMP,DPDUMP,PFILE E UDUMP )

3- COLOCAR O BACKUP RMAN NO MESMO CAMINHO ONDE ENCONTRAVA-SE NO ANTIGO SERVIDOR (INDICADO NO PARAMETRO db_recovery_file_dest).

4- SE FOR WINDOWS, CRIAR O SERVIÇO DO WINDOWS(ORACLE) COM O ORADIM.

   oradim -new -sid Instancia_do_banco -syspwd senha

CONTINUANDO ...


-- Entrar no Prompt de comando e executar os seguintes comandos:


SET ORACLE_SID=<<NOME DO BANCO NOVO>>

SQLPLUS SYS AS SYSDBA

SHUTDOWN IMMEDIATE;


-- Startando o RMAN e conectando no banco Target:

 RMAN

 RMAN> CONNECT TARGET SYS


-- Setando o DBID

 RMAN> SET DBID <<dbid_do_banco_origem>>;  -- DBID do banco que parou (ANTIGO).


-- Startando o Banco em Modo Nomount, já que o Control File ainda não foi restaurado 

 RMAN> STARTUP FORCE NOMOUNT PFILE '?/oradata/teste/initteste.ora';  -- Caminho init.ora


OBS.: SE EXISTIR, APAGAR OS ARQUIVOS DE REDO ANTIGOS EXISTENTES NA PASTA ORADATA.


-- Restaurando o Control file e alterando o Status do banco para MOUNT

 RMAN>   RESTORE CONTROLFILE FROM AUTOBACKUP;
          ALTER DATABASE MOUNT;


-- Restaurando o Banco e aplicando os archives necessários.

OBS.: Reparem que abri 3 Canais (Conexões) para que o processo de recuperação seja o mais rápido possível. A restauração trabalhará em paralelismo. Neste caso 3 forças ao invés de apenas 1.


RMAN>   RUN{
               ALLOCATE CHANNEL c1 DEVICE TYPE disk;
               ALLOCATE CHANNEL c2 DEVICE TYPE disk;
               ALLOCATE CHANNEL c3 DEVICE TYPE disk;
           RESTORE DATABASE;
      RECOVER DATABASE;}

Pronto !! Banco Restaurado e emprego mantido !!! rsrsrs

Mais ainda não acabou !!!


CONTINUANDO ...

-- Saia do Prompt do RMAN, vá até o sqlplus e abra o Banco de dados para apenas leitura e verifique se os dados estão corretos. 

 SQL> ALTER DATABASE OPEN READ ONLY;


 -- Após verificar se os dados estão corretos, abra o Banco resetando os Logs.

 RMAN> ALTER DATABASE OPEN RESETLOGS;


-- Não esqueça de criar o SPFILE e Startar o(s) LISTENER(s) do Banco.

CREATE SPFILE FROM PFILE='C:\oracle\admin\TL07\pfile\initTL07.ora';


LSNRCTL START <<NOME_DO_LISTENER>>


OBS.: Após todo esse processo o aconselhável é fazer um Backup Full do novo Banco de dados !!!

 FIM DO PROCESSO !!!

Galera é isso aí !!  Espero que possamos divulgar cada vez mais nossos conhecimentos e assim crescermos juntos na Profissão !!!
Lembrando:

     " Jesus faz milagre !!!  DBA faz Backup !!! "

Abraços,
DIEGO GARCIA FRANCISCO
DBA Oracle
Oracle Database 11g Administrator Certified Associate
(21) 7925-4500 / (21) 8714-2496

Verificar senha criptografada dos usuários no oracle 11G

Como trazer a senha que é armazenada na coluna PASSWORD da view DBA_USERS no Oracle 11g?

Galera, descobri isso há pouco tempo e achei interessante postar aqui. O Oracle 11g veio com algumas novidades na segurança, como o parâmetro case sensitive. Nas versões mais antigas do Oracle é possível extrair a senha criptografada dos usuários através da view DBA_USERS. No Oracle 11 a coisa é diferente, se você fizer o select retornará o campo PASSWORD em branco.

SQL> SELECT USERNAME, PASSWORD
2 FROM DBA_USERS
3 WHERE USERNAME='SYSTEM';

USERNAME PASSWORD
--------------- ------------------------------
SYSTEM<>

Analisando a view DBA_USERS, resolvi dar uns selects direto nas tabelas que ela se baseia, e encontrei a SYS.USER$. O Oracle 11g dificulta um pouquinho, mas conseguimos da nossa maneira tradicional, com nossos scripts dinâmicos, extrair a senha numa boa usando essa tabela. (claro, tendo privilégio de select para mesma).

Bom, caros amigos DBA'S...é isso. Achei interessante compartilhar. Desculpa se não tá muito bem explicado, mas sou péssimo em didática hehe

Grande abraço e até a próxima!