Amigos,

Desejo a todos um ótimo natal, curta muito as férias, festas e tenha uma ótima passagem para 2.009!

Queria agradecer a todos, iMasters, GPO, ENPO, TWS, Affinia, Pellegrino, SQL Magazine e todos os profissionais e leitores, um abraço especial para a equipe da iMasters pelo presente e carta de natal. Recebi e gostei muito. Muito obrigado.

PS: Estou de férias e só volto dia 12 de Janeiro/2009.

CURTAM BASTANTE! SE BEBER, NÃO DIRIJA!!!

Feliz Natal e próspero ano novo a todos.

Abraços,

Os organizadores da ENPO já disponibilizaram as palestras em vídeo que fizeram parte dessa última edição. Abaixo estou postando a minha palestra.

http://video.google.com/videoplay?docid=8521428875400605543

Para mais informações

ENPO - www.enpo-br.org

GPO - www.profissionaloracle.com.br

No site terá mais palestrars disponível para download e suas respectivas apresentações.

Abraços,

A GPO já colocou a disposição em seu website a apresentação sobre a ferramenta RMAN que foi utilizada para a palestra na V ENPO para consulta dos profissionais. Acho legal realizarem o download do power point, pois a apresentação traz mais detalhes sobre a ferramenta e técnicas de backup e recover.

Para fazer o download, basta clicar aqui. E caso tenha dúvidas ou sugestões, fique a vontade para entrar em contato.

Abraços,

Demorei um pouco para postar como foi o Encontro Nacional de Profissionais Oracle que ocorreu no sábado passado (29/11/2008)  na FIAP, pois estava numa correria danada e precisando um pouco de descanso.

Bom, como todas as edições da ENPO, tivemos ótimas palestras, oportunidade de conhecer diversos profissionais oracle, aumentando a rede social e agregar conhecimentos.

Nessa edição, tive o prazer para poder palestrar sobre um tema bem discutido, que é backup e recover com RMAN. Bem, a apresentação tinha bastante slides e o assunto é extenso, tive 1 hora para contar os conceitos básicos da arquitetura da ferramenta rman e suas principais funcionalidades, foi um pouco corrido, mas acho que deu para o público conhecer e entender um pouco sobre essa maravilhosa ferramenta. Em breve a apresentação estará disponível no site da ENPO e GPO.

Tivemos outras palestras bem interessantes também, como do nosso parceiro de blog e comunidade Oracle Ricardo Portilho que discutiu sobre o Load Balance em RAC, que teve uma apresentação bastante divertida (principalmente a imagem do balanceamento de cerveja entre a mulher e o homem), tive o prazer de conhecer pessoalmente, e é um cara super gente fina! Vale a recomendação de conhecer o blog dele também aqui na GPO com contéudo bem legal.

Outras palestras como o Chiappa, que discutiu um pouco sobre a utilização e o modo de utilizar a ferramenta SQL*Plus, o nosso velho e bom amigo de todos os dias, tivemos também Roberto Serson, ou show man Oracle, falando um pouco sobre Expressões Regulares, que se existe um desenvolvedor que gosta da trabalhar com a metodologia POG, ao conhecer as expressões regulares, ninguem mais irá dar manutenção em seus códigos! =D

Para o público, tivemos ainda uma boa visão geral de como trabalha o Oracle Spatial, que teve como palestrante o profissional Marcos Couto, de como o BI trabalha no geral como o Francisco Piedade, que detalhou e mostrou experiência no assunto.

E como todo palestrante, abaixo segue a imagem do meu novo trófeu recebido pelos organizadores da ENPO, que será guardado com muito carinho.

Gostei da participação da galera no geral, e desculpas por não ter dado muita atenção ao pessoal que veio tirar dúvidas durante os coffee breaks ou me esperado para almoçar, pois estava muito corrido o dia e muita gente comigo também, então estava díficil administrar tudo, quem quizer ainda discutir alguma coisa, fique a vontade de mandar e-mails para mim.

E agradeço aos organizadores (Fernanda, Morgado e Willians) pela oportunidade e aos amigos, tanto da iMasters, Affinia, Pellegrino, GPTI, IBTA e aos leitores em geral que compareceram ao evento.

Abraços,

Em Novembro terá a 5° Edição da ENPO (Encotro Nacional de Profissionais Oracle) em São Paulo, que irá ocorrer na faculdade FIAP (www.fiap.com.br), é sempre importante ressaltar que nesses eventos podemos criar e melhorar nosso network, assim como agregar mais informações sobre os produtos e mercado Oracle.

O evento irá contar com palestras e stands de parceiros voltados ao mercado Oracle. O GPO também estará para marcar presença e compartilhar conhecimentos Oracle para seus convidados.

O cronograma das palestras esse ano está abordando assuntos bem interessantes, que variam desde RAC (Real Application Cluster) , RMAN (Recovery Manager), BI (Bussiness Inteligence), SQL*PLUS, Oracle Spatial e a utilização de Expressões Regulares no 10g e 11g.

Esse ano vocês irão ter que me aturar um pouco, irei palestrar sobre RMAN - Vilão ou Héroi? Vamos falar sobre as funcionalidades, entender a arquitetura, como funciona os backups para bancos em ARCHIVELOG e NOARCHIVELOG, tipos de backup incrementais e recover, catálogo de recuperação, dicas do dia-a-dia, as técnicas que podemos aplicar como o TSPITR (Tablespace Point-In-Time Recover), Migration Platform, Duplicate DP e Transportable Tablespace.

Espero que o público da ENPO goste desse assunto, vou procurar abordar a maioria das funcionalidades do RMAN. E também teremos outros 5 palestras que realmente são sensacionais, como, Chiappa falando sobre SQL*PLUS, como sempre digo:

“DBA que é DBA, usa SQL*PLUS”

Irá nos fornecer informações de como dominar essa ferramenta, teremos também palestra sobre RAC comPaulo Shorr, que na ENPO do início do ano fez uma ótima apresentação sobre RAC com caso de estudo, teremos o Roberto Serson discutindo sobre a utilização de Expressões regulares no 10g e 11g, assim como outras palestras sobre Oracle Spatial, que é um produto fantástico e BI que é uma área que está crescendo cada vez mais, que está com um ótimo mercado.

Então, fica o convite para todos e se encontramos na 5º Edição da ENPO.

Abraços,

Uma dos maiores problemas de realizar uma recuperação completa ou uma restauração de um banco de dados para um novo servidor, é o problema de mencionar o DBID (Database Identifier - Identificação do banco de dados) para o catálogo do RMAN.

Pois, para conseguir uma restauração da base, é necessário mencionar o DBID ao catálogo de recuperação para conseguir associar o banco de dados no catálogo e posteriormente restaurar e recuperar seus backups sets.

Agora, vamos mencionar quais os meios que podemos encontrar o DBID de um banco de dados.

1. Dicionário de dados

Podemos realizar um simples select na view v$database para conseguir a informação, veja.

SQL> select dbid from v$database;

      DBID
----------
4263396950

1 linha selecionada.

2. RMAN - Inicío de sessão

O DBID também é informado quando você conecta ao RMAN, lembrando, que o DBID será informado se o banco de dados estiver em MOUNT ou OPEN, se apenas com NOMOUNT, não será informado, pois não irá ler o arquivo de controle, ou control file. Exemplo.

[oracle@PELSPOWMS2 ~]$ rman

Recovery Manager: Release 10.2.0.1.0 - Production on Thu Oct 23 17:15:23 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

RMAN> connect target ‘rman/##########@wmssp.world’;

connected to target database: WMSSP (DBID=4263396950)

RMAN>

3. RMAN - Usando o comando List incarnation

Outro modo de se conseguir o DBID do banco de dados, é após logar-se no banco de dados target e estar conectado ao catálogo de recuperação, utilizar o comando LIST INCARNATION, exemplo:

RMAN> list incarnation;
List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
8451    8458    WMSSP    4263396950       PARENT  1          30/06/2005 19:09:40
8451    8452    WMSSP    4263396950       CURRENT 446075     27/02/2008 09:03:20

RMAN>

Uma dica muito importante é sempre manter uma planilha com todos os bancos de dados, senhas e seus respectivos DBID armazenados após as criação do banco de dados para não correr risco de não saber o DBID do banco de dados criado.

Abraços,

Alguns profissionais iniciantes em Oracle, ainda tem muitas dúvidas sobre diversos conceitos de arquitetura do banco de dados Oracle, por isso, resolvi discutir sobre um ponto bem importante, O que é um Control file?

Tradução

Control file = Arquivo de Controle, tradução em português para a palavra que é muito utilizado na literatura Oracle brasileira.

Visão Geral

Contéudo

Um arquivo de controle possui diversas informações de um banco de dados que é requerida pela instância. Durante o processo de startup ou uma operação normal, somente o Oracle Server pode modificar as informações no arquivo de controle, deste modo, nenhum DBA ou usuário pode modificar seu contéudo.

As informações que o arquivo de controle possui são:

• Nome do banco de dados 
• Data de criação do banco de dados
• Os nomes e localizações de cada datafile e redo log associados ao banco de dados
• Informações sobre as tablespaces
• Possíveis datafiles com status offline
• O histórico de logs
• Sobre os archives gerados
• Backupsets e backup pieces, gerados pelo RMAN
• Backups de datafiles e informações de redo log
• Cópia de datafiles
• O valor atual do número da sequência do log
• Informações de checkpoint

Para cada datafile ou redo log que é adicionado, renomeado, modificado ou excluído do banco de dados, o arquivo de controle é atualizado pelo Oracle Server para garantir a modificação da estrutura física da base. Essas modificações pode ser:

• O Oracle pode identificar os datafiles e redo logs que foram abertos durante o processo de startup
• Identificar os arquivos que são necessários ou disponíveis em caso de recuperação do banco de dados

Portanto, para cada modificação na estrutura física do banco de dados, podendo ser feito atráves do comando ALTER DATABASE, é altamente recomendado que seja feito um backup do seu arquivo de controle para evitar possíveis problemas no próximo processo de startup do banco de dados.

Como o arquivo de controle armazena informações sobre os checkpoints, a cada três segundos, o processo de plano de fundo (CKPT) registra as posições do redo log, essas posições serão utilizadas posteriormente  durante um processo de recuperação do banco de dados, onde o Oracle irá dizer se todas as entradas dos grupos de redo log serão necessárias para realizar tal recuperação.

Referência

Oracle Concepts 10g

Abraços,

Uma dos principais conceitos sobre arquitetura física do Oracle, é a marca D’água, uma tradução de HWM  - High Water Mark, ele que indica o limite que uma tabela já ocupou de espaço físico no seu banco de dados. Mas, vamos um pouco mais a fundo.

O que é uma Marca D’água (HWM - High Water Mark)?

A marca d’água é o limite do número de blocos que uma tabela pode estar utilizando, resumindo para um conceito mais simples, toda vez que uma tabela recebe um INSERT (novos registros), essa marca na tabela aumenta dizendo ao Oracle Server a quantidade de blocos que a tabela está utilizando, automaticamente, a quantidade de blocos, multiplicado, pelo tamanho do db_block_size do banco de dados, diz o valor físico real que está sendo utilizado.

Mas, esse valor real não é o valor que o Oracle irá alocar, pois irá depender de alguns outros pontos, como:

• Se a tabela está sendo gerenciada por sí própria ou pela tablespace.
• Irá depender dos tamanhos dos extents, exemplo, INITIAL_EXTENT e NEXT_EXTENT.
• Também, irá depender do tipo de gerenciamento, se é SEGMENT MANAGEMENT AUTO ou UNIFORM.
• E a quantidade de blocos que um EXTENT pode suportar.

Vamos ver como funciona a marca d’água na prática, um alguns exemplos práticos.

Vou criar uma tabela simples, chamada TSTDBA.

SQL> create table TESTE (a varchar2(100) not null, b number(7) not null);

Tabela criada.

Agora, vamos analisar como está a estrutura para o Oracle, pois a tabela não possui nenhum valor e nenhuma estatística coletada.

SQL> select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
  2  from dba_tables
  3  where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
---------- ------------------------------ ---------- ------------ ---------- -------------------
RODRIGO    TSTDBA

Até o momento, tudo sem surpresas para nós.

Então, vamos popular essa tabela com alguns registros, veja o exemplo.

SQL> l

  1  declare
  2     contador integer;
  3  begin
  4     contador := 1;
  5     while contador <= 1000 loop
  6             insert into TSTDBA values ('TESTE',contador);
  7             contador := contador + 1;
  8     end loop;
  9     commit;
 10* end;
SQL> /

Procedimento PL/SQL concluído com sucesso.

SQL> exec dbms_stats.gather_table_stats (ownname=>'RODRIGO',tabname=>'TSTDBA',estimate_percent=>null,method_opt=>'FOR ALL COLUMNS SIZE AUTO',degree=>6);

Procedimento PL/SQL concluído com sucesso.

Verifiquem que fiz um pequeno bloco PL/SQL para inserir dados em minha tabela, cerca de 1.000 registros. Após isso, preciso dizer ao Oracle, como a tabela está, seu volume e outras coisas mais, então, fiz um analyze na tabela para atualizar as informações estruturais dela no dicionário Oracle, ao fazer o analyze com o DBMS_STATS, o resultado do SELECT acima, agora é esse.

SQL> select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
  2  from dba_tables
  3  where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
---------- ------------------------------ ---------- ------------ ---------- -------------------
RODRIGO    TSTDBA                                  5            0       1000 06-10-2008 19:42:08

Veja, a nossa tabela está utilizando 5 blocos, o db_block_size do meu banco de dados é de 8KB, então, resumidamente, ele deveria estar utilizando cerca de 40KB, certo?

SQL> select 8192*5 from dual;

    8192*5
----------
     40960

Mas, se consultar o seu tamanho na dba_segments temos:

SQL> select segment_name, sum(bytes)/1024 from dba_segments where segment_name = 'TSTDBA' group by segment_name;

SEGMENT_NAME                                                                      SUM(BYTES)/1024
--------------------------------------------------------------------------------- ---------------
TSTDBA                                                                                         64

O resultado para o tamanho da tabela TSTDBA é 64KB, porque, o INITIAL_EXTENT da tabela é de 64KB, e como os 1.000 registros ocuparam apenas 40KB, um único extent consegui suportar.

SQL> select initial_extent/1024, next_extent from dba_tables where table_name = 'TSTDBA';

INITIAL_EXTENT/1024 NEXT_EXTENT
------------------- -----------
                 64

Pois bem! Rodrigo, e o tal do HWM, até onde está entrando nisso?

Vamos começar a brincar agora, veja que após o analyze, minha tabela TSTDBA está utilizando 5 blocos de dados, certo? Teoricamente, se eu fizer um TRUNCATE TABLE, eu não vou mais utilizar nenhum bloco, e minha marca d’água deveria baixar, mas, acontece isso:

SQL> truncate table TSTDBA;

Tabela truncada.

SQL> select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
  2  from dba_tables
  3  where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
---------- ------------------------------ ---------- ------------ ---------- -------------------
RODRIGO    TSTDBA                                  5            0       1000 06-10-2008 19:44:18

A minha tabela continua com se estivesse com 5 blocos, o que isso pode nos prejudicar:

• Esse exemplo é bem simples, mas para tabelas com milhares de registros, poderá influenciar os FULL-TABLES SCANS.
• Ao realizar um INSERT convencional, ou seja, sem o hint /* + APPEND */, ele irá procurar por bocos livres e irá consumir CPU e demorar um tempo para sua execução.
• Se minha marca d’água estiver muito alta, ou seja, estiver armazenando um alto valor de blocos utilizados, e você sabe, que ele não está utilizando tudo isso, você terá uma alocação de EXTENTS desnecessários no banco de dados, e isso irá ocupar espaço desnecessários.

 Caso eu quisesse diminuir o tamanho do meu segmento de tabela, eu não iria conseguir, pois além da marca d’água é inferior aos meus 64KB, pois bem, tente realizar um insert agora de 2.000.000 de registros e vamos ver o que acontece.

 SQL> declare
  2     contador integer;
  3  begin
  4     contador := 1;
  5     while contador <= 2000000 loop
  6             insert into TSTDBA values ('TESTE',contador);
  7             contador := contador + 1;
  8     end loop;
  9     commit;
 10  end;
 11  /

Procedimento PL/SQL concluído com sucesso.

SQL> exec dbms_stats.gather_table_stats (ownname=>'RODRIGO',tabname=>'TSTDBA',estimate_percent=>null,method_opt=>'FOR ALL COLUMNS SIZE AUTO',degree=>6);

Procedimento PL/SQL concluído com sucesso.

SQL> select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
  2  from dba_tables
  3  where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
---------- ------------------------------ ---------- ------------ ---------- -------------------
RODRIGO    TSTDBA                               4654            0    2000000 06-10-2008 22:37:24

SQL> show parameters db_block_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_block_size                        integer     8192
SQL> select (8192*4654)/1024/1024 as "Tamanho" from dual;

   Tamanho
----------
 36,359375

SQL> select segment_name, sum(bytes)/1024/1024 from dba_segments where segment_name = 'TSTDBA' group by segment_name;

SEGMENT_NAME                                                                      SUM(BYTES)/1024/1024
--------------------------------------------------------------------------------- --------------------
TSTDBA                                                                                              37

Se quizer analisar melhor como ficou a distribuição, veja a dba_extents, abaixo vou mostrar apenas um pequeno resumo da quantidade de extents alocados e seus respectivo tamanho.

SQL> select segment_name, count(extent_id), sum(bytes)/1024/1024
  2  from dba_extents
  3  where segment_name = 'TSTDBA'
  4  group by segment_name;

SEGMENT_NAME         COUNT(EXTENT_ID) SUM(BYTES)/1024/1024
-------------------- ---------------- --------------------
TSTDBA                             52                   37

Bom, vimos que agora temos um valor legal de extents alocados, e mesmo após o TRUNCATE continuo com uma alocação de extents, que totaliza os 37MB da tabela, então, minha marca d’água está posicionado no 51° extent, que seria o limite do numeros de blocos alcançados.

Conseguimos entender como funciona a marca d’água, o que isso pode nos causar?

A chamada fragmentação de tabela, além da marca d’água elevar o número de extents no dicionário, prejudicando muitas vezes os planos de execução e os table full scans, vamos ter também perca de espaço físico para a tablespace, espaço que não poderam ser alocados por outro segmento. Vamos a uma demostração prática de como funciona a fragmentação.

SQL> select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
  2  from dba_tables
  3  where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
---------- ------------------------------ ---------- ------------ ---------- -------------------
RODRIGO    TSTDBA                               4654            0    2000000 06-10-2008 22:37:24

SQL> select segment_name, count(extent_id), sum(bytes)/1024/1024
  2  from dba_extents
  3  where segment_name = 'TSTDBA'
  4  group by segment_name;

SEGMENT_NAME         COUNT(EXTENT_ID) SUM(BYTES)/1024/1024
-------------------- ---------------- --------------------
TSTDBA                             52                   37

A minha tabela TSTDBA continua com seus 2.000.000 de registros, após o analyze acima, vimos que está a atual estrutura da tabela, e se realizarmos diversos DELETES em grandes quantidades, o que poderemos ter?

SQL> delete from TSTDBA where b between 10000 and 20000;

10001 linhas deletadas.

SQL> delete from TSTDBA where b between 50000 and 200000;

150001 linhas deletadas.

SQL> delete from TSTDBA where b between 400000 and 700000;

300001 linhas deletadas.

SQL> delete from TSTDBA where b between 1000000 and 1300000;

300001 linhas deletadas.

SQL> commit;

Commit concluído.

SQL> select segment_name, count(extent_id), sum(bytes)/1024/1024
  2  from dba_extents
  3  where segment_name = 'TSTDBA'
  4  group by segment_name;

SEGMENT_NAME         COUNT(EXTENT_ID) SUM(BYTES)/1024/1024
-------------------- ---------------- --------------------
TSTDBA                             52                   37

Vamos passar um analyze para validar toda a estrutura da tabela.

SQL> exec dbms_stats.gather_table_stats (ownname=>'RODRIGO',tabname=>'TSTDBA',estimate_percent=>null,method_opt=>'FOR ALL COLUMNS SIZE AUTO',degree=>6);

Procedimento PL/SQL concluído com sucesso.

Veja o resultado para os novos valores.

SQL> select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
  2  from dba_tables
  3  where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
---------- ------------------------------ ---------- ------------ ---------- -------------------
RODRIGO    TSTDBA                               4654            0    1239996 06-10-2008 23:09:01

A quantidade de extents não alterou depois de apagarmos diversos registros, isso causa a conhecida fragmentação do segmento, mesmo que após calcularmos a quantidade de registro exato da tabela.

SQL> select segment_name, count(extent_id), sum(bytes)/1024/1024
  2  from dba_extents
  3  where segment_name = 'TSTDBA'
  4  group by segment_name;

SEGMENT_NAME         COUNT(EXTENT_ID) SUM(BYTES)/1024/1024
-------------------- ---------------- --------------------
TSTDBA                             52                   37

Para resolvermos esse problema de fragmentação, bastamos reconstruir o mapa binário da tabela, para isso, apenas use um MOVE sem mencionar a tablespace que resolve nosso problema.

SQL> alter table TSTDBA move;

Tabela alterada.

SQL> select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
  2  from dba_tables
  3  where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
---------- ------------------------------ ---------- ------------ ---------- -------------------
RODRIGO    TSTDBA                               4654            0    1239996 06-10-2008 23:09:01

SQL> select segment_name, count(extent_id), sum(bytes)/1024/1024
  2  from dba_extents
  3  where segment_name = 'TSTDBA'
  4  group by segment_name;

SEGMENT_NAME         COUNT(EXTENT_ID) SUM(BYTES)/1024/1024
-------------------- ---------------- --------------------
TSTDBA                             38                   23

PRONTO! Veja que após nosso “rebuild” na tabela, liberamos cerca de 15MB para a tablespace, fazendo apenas uma reconstrução dos extents da tabela.

Existem muitos outros conceitos envolvidos sobre a alocação de extents, sem mencionar os freelists, gerenciamento das tablespaces e diferenças entre os segmentos de tabela e índice, tudo isso foi apenas um modo de ilustrar os problemas que podem causar perda de performance em nossos ambientes.

Existe uma matéria que escrevi para a iMasters algum tempo atrás que explica com um pouco mais de detalhes como funciona a arquitetura de armazenamento lógico do banco de dados Oracle, o artigo Arquitetura de armazenamento lógico, que sanar algumas dúvidas.

A idéia principal do post foi iniciar desde o conceito de HWM (High Water Mark) até sua fragmentação, passando por várias fases, para fornecer um melhor entendimento de como a arquitetura Oracle funciona.

Abraços,

Semana passada o nosso velho e bom amigo Metalink ficou de cara nova, e também com um apelido novo, chamado agora de My Oracle Support (Site: http://metalink.oracle.com), criado boa parte em Flash (Actions Scripts FORTES!) e com novas funcionalidades integradas ao SCM (Software Configuration Manager), apresentou uma cara bem bonita e uma razoável navegação.

Abaixo mostro um pequeno screenshot da nova tela inicial do Metalink, ou My Orale Support.

Ao acessar o metalink, algumas novidades apareceram como: Dashboard, Community, Reports e Collector. O mais bacana das opções é o Dashboard, que sumariza todas as informações da sua conta em uma única tela, tais informações como seus SR (Service Request - ou TAR), informações sobre suas bases que estão coletando informação pelo OCM (Oracle Configuration Manager), inventário e Projects . O screenshot mostra a tela de dashboards.

O metalink sempre foi o canal para entrar em contato com o suporte da Oracle, para aqueles problemas difíceis de se resolver, a qualidade do suporte não mudou muita coisa, continua o mesmo (Quem usa sabe!), porém ao abrir um SR (ou TAR), você pode ter mais integração com o suporte e informação disponível da sua conta em um pequeno boxtext, como apresentado abaixo.

O My Oracle Support está com bons recursos, entre eles, podemos destacar:

MapView

Ao abrir um SR, você já pode mencionar em qual banco de dados está o problema, atribuindo as informações que estão armazenadas no repositório da Oracle ao SR. Essas informações são retiradas dos relatórios de RDA ou pelos coletores do SCM.

PowerView

Um recurso do My Oracle Support que permite filtrar informações por região do aplicativo, customizando as informações que acordo com o seu interesse. As regiões podem ser Knowledge base, Projects, System, System Health e Service Request.

System Health

Um monitor que analisa a saúde de seus bancos de dados e aplicativos, como Application Server e EBS (E-Bussiness Suite), monitora informações de segurança, patch e recomendações. Ótimo para equipes que querem atuar com pró-atividade.

Web Seminars

Dentro da região Knowledge, existe a opção Tools and Training >  Training (Web Seminars). Uma ótima sacada da Oracle para seus profissionais. A intenção é fornecer seminários e treinamentos gratuitos para seus produtos de suporte, como RDA, SCM, E-Bussiness Diagnostics entre outros. Dessa forma, trabalhar de acordo com os padrões Oracle e entender todas as ferramentas e seus respectivos fluxos de chamado.

Esses são apenas alguns itens que gostei de comentar sobre a nova ferramente da Oracle de suporte, para quem já é assinante Metalink, vale a pena dar uma navegada no site e descobrir muito mais coisas. O site em sí ainda é meio lento, mesmo para quem usa conexão DSL ou dedicada está bom, mas, para quem não gostou mesmo do site e ainda prefere a versão antiga, em todas as páginas existe o Link para Classic Metalink.

Abraços,

Segue o script utilizado no post “Diminuindo físicamente um banco de dados Oracle” para consulta.

Resize_seguro

SQL> get c:\DBA\scripts\resize_seguro.sql 

  1  select file_name,
  2        ceil( (nvl(hwm,1)*8192)/1024/1024 ) smallest,
  3        ceil( blocks*8192/1024/1024) currsize,
  4        ceil( blocks*8192/1024/1024) -
  5        ceil( (nvl(hwm,1)*8192)/1024/1024 ) savings,
  6        ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) smallest_safe,
  7        ceil( blocks*8192/1024/1024) -
  8        ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) savings_safe
  9  from dba_data_files a,
 10      ( select file_id, max(block_id+blocks-1) hwm
 11          from dba_extents
 12         group by file_id ) b
 13  where a.file_id = b.file_id(+)
 14   and ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) < ceil( blocks*8192/1024/1024)
 15   and ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) > 100
 16  order by 4 desc;
 17  select 'alter database datafile ''' || file_name || ''' resize ' ||
 18        ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 )  || 'm;' cmd
 19  from dba_data_files a,
 20      ( select file_id, max(block_id+blocks-1) hwm
 21          from dba_extents
 22         group by file_id ) b
 23  where a.file_id = b.file_id(+)
 24   and ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) < ceil( blocks*8192/1024/1024)
 25   and ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) > 100

O resultado será igual ao abaixo:

SQL> @resize_seguro

FILE_NAME                                                      SMALLEST   CURRSIZE    SAVINGS SMALLEST_SAFE SAVINGS_SAFE
------------------------------------------------------------ ---------- ---------- ---------- ------------- ------------
/u02/app/oracle/oradata/finp/sysaux01.dbf                           191       2000       1809        229            1771
/u02/app/oracle/oradata/finp/system01.dbf                           264       2000       1736        316            1684

CMD
------------------------------------------------------------------------------------------------------------------------
alter database datafile '/u02/app/oracle/oradata/finp/system01.dbf' resize 316m;
alter database datafile '/u02/app/oracle/oradata/finp/sysaux01.dbf' resize 229m;

Todos as colunas foram comentadas no POST que foi utilizado o script, para melhor o entendimento do resultado gerado.

Abraços,