Oracle Data Guard 11g com VirtualBox – Parte 4
March 15, 2013

Parte 1

Parte 2

Parte 3

Parte 4

Parte 5

Parte 6

Na parte 4 da série vamos criar o banco primário, ou seja o banco produção do nosso ambiente de teste. O banco irá se chamar orcl, conforme a planilha abaixo apresentada na parte 3.

VMS DG

Criando o banco primário (produção)

Com a máquina virtual DB Primary iniciada e logado com o usuário oracle, a partir do prompt digite o comando DBCA.

dg120

 

Apenas clique em next.

dg121

 

dg122

 

Selecione e a opção de template de banco que desejar, no meu caso vou utilizar o “General Purpose”, com esse template além da criação ser mais rápida ele já vem com várias features instaladas fazendo ideal para nosso teste.

dg123

 

Hora de definir o nome para o nosso banco de dados: orcl

dg125

 

Desabilite a opção de criar o Enterprise Manager, estaremos fazendo isso depois.

dg126

 

Defina aqui uma senha para os usuário sys e system. No meu caso foi definido a senha oracle.

dg127

 

Obviamente essa senha não é recomendada, como mostra a mensagem abaixo (nunca usar esse tipo de senha em produção!!)

dg128

 

dg129

 

Desabilite a opção de archive para que a criação seja feita mais rápida. Vamos fazer isso posteriormente.

dg130

 

Para fins de teste, selecione a opção de colocar os schemas de teste no banco. Isso irá criar os owner SCOTT, HR etc …

dg131

 

 

 

Informe aqui a quantidade de memória que será utilizada pelo Oracle. No meu caso, como minha VM é 3G vou definir 1,5G para o oracle.

dg132

 

dg133

dg134

Aqui é mostrado um sumário de tudo que foi escolhido no banco de dados. Confirme tudo para iniciar a criação do banco.

dg135

dg136

 

Aqui a conclusão da criação do banco orcl:

dg137

Na próxima parte dessa série, iremos realizar os pré-requisitos do banco orcl para a criação do DataGuard.

Qualquer dúvida, post um comentário.

Abraço!

Protegendo o Oracle – Parte 3
February 14, 2013

No dia seguinte em que publiquei a parte 1 da série sobre segurança de banco de dados, meu amigo Gerson Vasconcelos Jr. enviou através do e-mail um trabalho que havia feito na faculdade que poderia ajudar a fazer os próximos post de segurança, e realmente .. o documento é fantástico! Tem várias notas muito bem explicadas de como configurar o Oracle para trabalhar de forma segura!

O Gerson para quem não sabe, além de ser um grande amigo e um grande DBA que essa carreira deu o privilégio de conhecer, o cara também é blogueiro, seu blog é o http://www.diaadiaoracle.com.br/ e ele escreve também no Grupo de Profissionais Oracle no blog Dia a Dia Oracle.

Como ele mesmo disse no e-mail: “Conhecimento é a única coisa que quando você divide, se multiplica!”, aqui está o trabalho e a apresentação do Gerson (claro pedi a permissão dele para divulgar):  http://flaviosoares.com/docs/security/trabalho_gerson

Entre as notas mencionadas por Gerson no trabalho, a que achei mais interessante foi sobre o parâmetro ULT_FILE_DIR, para quem não sabe esse parâmetro pode destruir seu ambiente! Caso o usuário oracle tenha privilégio, você pode criar um arquivo através do utilitário utl_file bem em cima de um arquivo crítico do SO, ae já sabe … adeus servidor! Mas, como contornar isso? Leia o trabalho, que lá o Gerson explica melhor! :)

Gersão, está devendo uma passada aqui em São Paulo para a gente tomar uma ein!  um abraço e muito obrigado mesmo!

Protegendo o Oracle – Parte 2
January 12, 2013

Parte 01 – 07_DICTIONARY_ACCESSIBILITY

Encontrando os password default

Não é novidade nenhuma que existem várias contas de usuários padrão no banco de dados Oracle, alguns deles até são criados com privilégios administrativos.

Usuários padrão são criados no momento da criação do banco e claro,  são registrados sem uma senha e já vem bloqueado por default, exceto para SYS e SYSTEM que são contas administrativas que quando criadas através do CREATE DATABASE, se não definidas as senhas, elas devem ficar:

SYS : CHANGE_ON_INSTALL)
SYSTEM : MANAGER

Se você acha que os usuários default do Oracle é uma lista pequena, está enganado, aqui é alguns dos usuários padrão que são instalado sempre que um banco ou uma feature do banco é instalada. Por exemplo, o usuário XDB somente é instalado quando o Oracle XMLDB é instalado:

SYS
SYSTEM
SYSMAN
OUTLN
TSMSYS
WKSYS
SCOTT
ADAMS
JONES
WKPROXY
OLAPSYS
OWBSYS
CLARK
BLAKE
HR
OE
SH
DEMO
ANONYMOUS
CSMIG
CTXSYS
DBSNMP
DIP
DMSYS
DSSYS
EXFSYS
LBACSYS
MDSYS
ORACLE_OCM
ORDPLUGINS
ORDSYS
PERFSTAT
XDB
MGMT_VIEW
SI_INFORMTN_SCHEMA

Porém para alguns deles (quase todos), existe uma senha padrão definida, como o famoso usuário SCOTT que possuí a senha padrão definida como TIGER.

Muitos ambientes Oracle tem o usuário SCOTT criado (e provavelmente até com a senha padrão definida), o que deixa o banco de dados muito vulnerável, imagina que com uma senha padrão definida, qualquer um a qualquer momento pode acessar o seu banco, somente acessando essa conta.

Ok, mais como me livro disto? Qual é a maneira de descobrir se os usuários na lista acima está com a senha padrão habilitada?

Somente a view DBA_USERS_WITH_DEFPWD pode te responder isso …

Logado no SQL*Plus com uma conta administrativa, execute a seguinte consulta de encontra a view DBA_USERS_WITH_DEFPWD

SQL> SELECT * FROM DBA_USERS_WITH_DEFPWD;

USERNAME
------------------------------
DIP
OUTLN
ORACLE_OCM
APPQOSSYS

SQL> select username, account_status from dba_users where username in (select username from dba_users_with_defpwd);

USERNAME                       ACCOUNT_STATUS
------------------------------ --------------------------------
APPQOSSYS                      EXPIRED & LOCKED
ORACLE_OCM                     EXPIRED & LOCKED
DIP                            EXPIRED & LOCKED
OUTLN                          OPEN

A primeira consulta, mostra que temos a lista completa dos usuários em que a senha padrão está definida. Na segunda consulta, é informado que apenas o usuário OUTLN que tem uma senha padrão está com o status da conta habilitado.

Mesma com uma conta bloqueada, deixar o usuário com uma senha padrão pode ser muito perigoso, imagina se alguém habilita uma dessas contas sem querer e não troca a senha?

Para mudar a senha não é segredo:

SQL> PASSWORD OUTLN
Changing password for OUTLN
New password: *********
Retype new password: ************
Password changed

São maneiras simples como essa que podem te livrar de uma dor de cabeça incrível. O DBA devem estar atento a tudo, inclusive a pequenos detalhes como este. Nem quero pensar que uma conta dessas caia em mãos erradas, imagina que uma conta dessas com privilégio administrativo, o de create/drop tablespaces por exemplo, esteja com a conta habilitada e password default e algum abelhudo consegue conectar com essa conta, já penso o estrago? …

É! … você pode dar adeus ao seu banco e rezar para ter backup …

Performance Tuning Utilities
January 9, 2013

Já ouviram falar de OSWatcher? LTOM? SQLTXPLAIN e OPDG?

Bom, se vocês nunca ouviram  falar dessas ferramentas chegou a hora de conhece-las.

A nota do metalink 438452.1 mostra essas e diversas outras ferramentas sobre performance tuning.

Bom apetite, aproveitem :)

Tudo no ar novamente!
January 4, 2013

O último post tinha avisado vocês sobre o problema da hospedagem!

Enfim, os links com as imagens quebradas, os links para os scripts e algumas outras coisas foram tudo restaurado!

E claro, os e-mails também voltaram: dba@flaviosoares.com

Um abraço e feliz 2013!

Mudança de hospedagem
December 28, 2012

Pessoal,

O blog está passando por uma mudança (forçada) de hospedagem, com isso alguns itens  não estão funcionando, como: a área de scripts, comentários,  links das imagens e o email contato@flaviosoares.com que ainda está em fase de migração.

Estou trabalhando nisso e acredito que muito em breve as coisas vão estar todas resolvidas.

Um abraço!

Segment Advisor Script v1.0
December 12, 2012

Só nós DBA’s sabem as inúmeras funções, sintaxes e comandos que precisamos decorar no nosso dia a dia e isso não é uma tarefa fácil, além do que, as soluções sempre precisam ser rapidamente propostas. Por isso que gosto de facilitar as coisas sempre que posso, assim como esse script, que além de simples ele realiza é uma formarápida os passos que nem sempre são lembrados, isso evita aquele tempão gasto procurando na documentação a sintaxe exata de tal procedimento. Qual DBA que nunca passou por isso que atire a primeira pedra!

O objetivo principal do script é facilitar a execução do Oracle Segment Advisor, de uma forma bem simples, apenas três argumentos e nada mais e o melhor de tudo: não é preciso criar qualquer tipo de objeto no banco de dados, todo trabalho é executado através de um bloco anônimo de PLSQL e o único requisito aqui é o bom e velho SQL*Plus.

Você pode conferir a primeira versão (sim, próximas poderão surgir) você pode fazer aqui.

Como usar Segment Advisor Script?

SYNTAX: { @run_sa “Owner Segment” “Segment Name” “Segment Type” }

Ele não precisa nada mais além do que três argumento:

1. “Owner Segment” :  O primeiro representa o nome do owner do segmento.

2. “Segment Name”:  O segundo representa o nome do segmento.

3. “Segment Type”:  O terceiro representa o tipo do segmento. Que pode ser um TABLE, INDEX etc …

Usando o Segment Advisor Script

Para explicar melhor vamos a um teste prático.

Primeiro de tudo, precisamos de uma tabela grande favorável para o teste que vamos fazer, para isso criei a tabela chamada TBIG dentro do schema FSOARES.

FSOARES@dbtst> create table tbig as select * from dba_source;

Table created.

FSOARES@dbtst> insert into tbig (select * from tbig);

633054 rows created.

FSOARES@dbtst> /

1266108 rows created.

FSOARES@dbtst> /

2532216 rows created.
...
FSOARES@dbtst> commit;
FSOARES@dbtst> @size tbig

SEGMENT_NAME                    SEGMENT_TYPE        SIZE_MB
------------------------------ ------------------ ---------------
TBIG                             TABLE              5,244.00

Pronto, temos agora uma tabela de 5G que está perfeita para o nosso teste. Vamos ver quantos registros temos:

FSOARES@dbtst> set timing on
FSOARES@dbtst> select count(*) from tbig;

COUNT(*)
----------
40515456

1 row selected.
Elapsed: 00:04:08.21

Ok, temos cerca de 40515456 registros e levamos cerca de 4 minutos para sabermos isso. Vamos agora apagar uns 98% dessa tabela deixando apenas alguns milhares de registro. Para fazer essa operação mais racional,  quero descobrir  quantos registros tenho por usuário nessa tabela, afim de deixar apenas os menores owners:

FSOARES@dbtst> select count(*), owner from tbig group by owner order by 1;

  COUNT(*) OWNER
---------- ------------------------------
       576 IX
       576 OUTLN
      1088 PM
      2176 FLOWS_FILES
      2176 HR
      2880 SYSTEM
     13696 OE
     14912 ORDPLUGINS
     19392 WMSYS
     70464 EXFSYS
    183808 ORACLE_OCM
    230528 DBSNMP
    231552 ORDSYS
    548288 XDB
    731264 OLAPSYS
   1258816 CTXSYS
   1340416 MDSYS
   2624256 APEX_030200
   9466112 SYS
  23772480 SYSMAN

20 rows selected.

Elapsed: 00:01:14.06
FSOARES@dbtst> delete tbig where owner NOT IN ('IX', 'OUTLN');                         
40514304 rows deleted.

Elapsed: 00:29:57.41
FSOARES@dbtst> commit;

Commit complete.

Elapsed: 00:00:00.01

Aqui, a nossa tabela TBIG está somente com os dados usuário IX e OUTLN, o resto dos outros usuário foi simplesmente apagado. Bom como temos agora apenas alguns registros vamos realizar aquele mesmo count para ver o a quantidade de registro, vamos ver agora o quanto tempo levará. Primeiro é claro, vamos remover a consulta do nosso cache.

FSOARES@dbtst> alter system flush shared_pool;

System altered.

FSOARES@dbtst> alter system flush buffer_cache;

System altered.

FSOARES@dbtst> select count(*) tbig

  COUNT(*)
----------
      1152

1 row selected.

Elapsed: 00:03:53.93

Temos agora cerca de mil registros e levamos quase o mesmo tempo para realizar o count da tabela quando ela estava com mais de 40 milhões de registro!? Como isso pode ser? Tivemos o mesmo tempo para contar de 0 a 1152 e de 0 a 40 milhões?

Bom, sem dúvidas há alguma coisa de errado com nosso segmento de tabela TBIG. É aí que entra o Segment Advisor, que vai nos aconselhar o que fazer com esse segmento.

Veja como é simples:

FSOARES@dbtst> @run_sa fsoares tbig table

---------------------------------------------------------------------------------
-- Segment Adviser Script v1.0 by Flavio Soares ( http://flaviosoares.com )

Running the Segment Advisor for Segment 
Owner   : FSOARES
Segment Name: TBIG
Segment Type: TABLE

Segment Advisor successfuly completed

For delete the task TaskName_FSOARES_cxdnLahXMf run: 
SQL> exec  dbms_advisor.delete_task('TaskName_FSOARES_cxdnLahXMf');

-- Showing the Segment Advice Recommendations for the object "table" "fsoares" "tbig"

 TABLESPACE_NAME   : USERS
 SEGMENT_OWNER     : FSOARES
 SEGMENT_NAME      : TBIG
 SEGMENT_TYPE      : TABLE
 PARTITION_NAME    :
 ALLOC_MB          :    5,244.00
 RECLAIM_MB        :    4,567.54
 USED_MB           :      676.46
 PCT_SAVE          : 87 %
 RECOMMENDATIONS   : Enable row movement of the table FSOARES.TBIG and perform shrink, estimated savings is 4789413285 bytes.
 SOLUTION 1        : alter table "FSOARES"."TBIG" shrink space
 SOLUTION 2        : alter table "FSOARES"."TBIG" shrink space COMPACT
 SOLUTION 3        : alter table "FSOARES"."TBIG" enable row movement

---------------------------------------------------------------------------------

Observe a recomendação, ele sugere realizar um shrink na tabela que ganharemos com isso cerca de 87% de espaço que hoje não está sendo utilizado. Opa!  … é 87% é um bom ganho, então vamos aplicar as recomendações sugeridas.

FSOARES@dbtst> alter table "FSOARES"."TBIG" enable row movement;

Table altered.

FSOARES@dbtst> alter table "FSOARES"."TBIG" shrink space;

Table altered.

Após as recomendações aplicadas, vamos agora executar novamente o count de encontro a tabela TBIG e observar o tempo:

FSOARES@dbtst> alter system flush shared_pool;

System altered.

FSOARES@dbtst> alter system flush buffer_cache;

System altered.

FSOARES@dbtst> select count(*) from tbig;

  COUNT(*)
----------
      1152

1 row selected.

Elapsed: 00:00:00.01

Depois da recomendação aplicada, o tempo simplesmente caiu para 0.01 segundos.

Viu como ficou bem mais simples utilizar o Segment Advisor agora com o run_sa.sql :)

Com apenas três argumentos e já temos nossas recomendações.

FSOARES@dbtst> @run_sa fsoares tbig table

---------------------------------------------------------------------------------
-- Segment Adviser Script v1.0 by Flavio Soares ( http://flaviosoares.com )

Running the Segment Advisor for Segment 
Owner   : FSOARES
Segment Name: TBIG
Segment Type: TABLE

Segment Advisor successfuly completed

For delete the task TaskName_FSOARES_cxdnLahXMf run: 
SQL> exec  dbms_advisor.delete_task('TaskName_FSOARES_cxdnLahXMf');

-- Showing the Segment Advice Recommendations for the object "table" "fsoares" "tbig"

 TABLESPACE_NAME   : USERS
 SEGMENT_OWNER     : FSOARES
 SEGMENT_NAME      : TBIG
 SEGMENT_TYPE      : TABLE
 PARTITION_NAME    :
 ALLOC_MB          :    5,244.00
 RECLAIM_MB        :    4,567.54
 USED_MB           :      676.46
 PCT_SAVE          : 87 %
 RECOMMENDATIONS   : Enable row movement of the table FSOARES.TBIG and perform shrink, estimated savings is 4789413285 bytes.
 SOLUTION 1        : alter table "FSOARES"."TBIG" shrink space
 SOLUTION 2        : alter table "FSOARES"."TBIG" shrink space COMPACT
 SOLUTION 3        : alter table "FSOARES"."TBIG" enable row movement

---------------------------------------------------------------------------------

Dúvidas, melhorias, bugs, recomendações serão muito bem vindas!

Um abraço e aproveitem!

Oracle 12c, amanhã?
December 11, 2012

Será o lançamento do Oracle 12c amanhã?

No dia 12/12/2012 ?

Será?

Só nos basta esperar …

Atenção no uso de ALTER TYPE .. RESET
December 11, 2012

O objetivo não é assustar mais o de sempre informar.

Bug 4421376 – Dump (kgldpo) after ALTER TYPE .. RESET

De acordo com a Oracle, existem casos em que quando o “ALTER TYPE RESET;” é executado podem ocorrer corrupção no dicionário de dados do seu banco, isso mesmo você “pode” ter uma corrupção no seu banco!

Para confirmar o problema, basta ver a mensagem kgldpo no seu dump quando um reset é disparado.  Oracle acredita que as versões abaixo da 11g podem ser afetadas com esse problema, porém confirma apenas na versão 10.2.0.4.

Sempre consulte o Oracle Supporte para qualquer conselho.

Mais detalhes:
Bug 4421376 – Dump (kgldpo) after ALTER TYPE .. RESET [ID 4421376.8]

São esses tipos de problemas, que existe um intenso apelo por parte da Oracle para sempre manter o seu banco atualizado e com seus os patch em dias, podendo evitar assim problemas extremamente graves como este.

Fotos do Oracle OpenWorld Latin America 2012
December 10, 2012

Next Page »