11 de abr. de 2013


Olá a todos!

Tenho andado bastante sobrecarregado no trabalho e em outras atividades, o que tem resultado em pouco tempo de dedicação a posts aqui no blog.

Mas vou superar isso! hehehe

Bom... Hoje vou falar sobre algo bem básico que são as tarefas de um Administrador de Banco de Dados.

Identificar um DBA não é uma tarefa fácil, mesmo porque “tudo sempre é culpa do DBA”. Se ocorre um crash no banco no banco, chamam o DBA, até aí tudo bem, mas o DBA também pode ser chamado se a rede falhar, se os servidores derem uma pane ou se ocorrer um erro na aplicação, se a impressora está sem tinta ou se o telefone está com defeito...hehe (esses últimos acredito que qualquer profissional de T.I. está sujeito). Brincadeiras a parte, imaginasse que algumas dessas situações estão relacionadas às funções do DBA porque praticamente qualquer falha no ambiente de T.I. impede que os usuários finais acessem o banco de dados, logo faz do DBA o primeiro ponto de contato natural.

Abstraindo essas expectativas excessivas , seguindo as orientações da Oracle, que inclusive é cobrado no exame (1Z0-052 na versão 11G) para a certificação OCA, as tarefas de um DBA se resumem, segundo John Watson, basicamente nas seguintes:

Avaliar o hardware do servidor de banco de dados
Este item diz respeito à realização de previsões precisas relacionadas  à quantidade de memória, espaço em disco e CPU. O DBA deverá saber dimensionar os recursos necessáriaos para garantir que as aplicações serão bem executadas sem demandar recursos desnecessários, mantendo assim um desempenho bom sem extrapolar o orçamento disponível.

Instalar e manter o software Oracle
A instalação de um banco de dados Oracle e a criação de instâncias, é algo básico para um DBA, mas é de fundamental importância que este saiba também realizar instalações de patches críticos e patches de manutenção. Obviamente que antes de se implantar uma atualização em ambiente de produção, os patches devem ser adequadamente testados, uma vez que o DBA é o responsável pelo bom funcionamento do ambiente de banco de dados.

Planejar o banco de dados
Configurar o armazenamento físico de um banco de dados podem impactar na performance dos sistemas e seu gerenciamento. O DBA deve também estar ciente do impacto de diferentes estruturas de armazenamento nos dispositivos, como sistemas de discos e fitas.

Monitorar e ajustar o desempenho do banco de dados
Essa é uma atividade que deve ser contínua e frequente para os sistemas de banco de dados. Um bom DBA será capaz de antecipar os problemas de desempenho e corrigi-los antes que surjam, sempre trabalhando de forma proativa através, por exemplo, da realização de tuning (de configuração e de queries).

Auxiliar os desenvolvedores nos projetos de aplicações e ajustes de SQL
Alguns DBAs gastam muito tempo ajustando SQL, porém há quem diga (e particularmente concordo) que essa tarefa é função dos programadores. Onde o DBA pode participar, é ajudando a identificar as áreas com problemas para que eles (os desenvolvedores possam) resolver, e evitar problemas futuros.

Manter contato com fornecedores, usuários finais, desenvolvedores, gerentes e outros grupos de suporte
Como técnico com enfoque mais completo do ambiente, o DBA deve ter um papel de “liderança” na coordenação de planejamentos e ações de todos os grupos envolvidos no ambiente de T.I.

Realizar backup, restaurar e recuperar o banco de dados
Possivelmente a tarefa mais importante de um DBA é essa. O DBA deve criar rotinas que deverão garantir a disponibilidade do ambiente de banco de dados, preferencialmente combinando o mais próximo possível de 100% de tempo de atividade e 0% de perda de dados.
Não há certo ou errado, apenas a conformidade (ou a falha dela) aos objetivos combinados, e para garantir que a tarefa será bem sucedida, testes frequentes devem ser realizados.

Gerenciar os usuários do sistema e manter a segurança do banco de dados
Essa é outra parte crítica do trabalho do DBA. Como na tarefa de manter a disponibilidade do ambiente, para a atividade de segurança também não há certo e errado, apenas a conformidade com os acordos realizados. O DBA deve configurar os procedimentos que garantirão a conformidade e monitorar a seu funcionamento.

Bom pessoal...

Era isso que tinha para falar por hoje, o que obviamente não define a função de um DBA, mas trás características e funções interessantes. Vale lembrar que o amplo escopo da função de um DBA requer estudo contínuo e desenvolvimento pessoal, estudo do banco de dados Oracle e tecnologias relacionadas. Também requer vocação para educar e disseminar o conhecimento, talvez a parte mais gratificante do trabalho, por isso que escrevo e publico esses artigos aqui no blog.

Espero ter ajudado!

Até a próxima!

Referência:

WATSON, JOHN – OCA Oracle Database 11g – Administração I – Guia do Exame 1z0-052. Editora: BOOKMAN.

Raphael Fernandes, quinta-feira, abril 11, 2013

Sem comentários

4 de abr. de 2013

Muito boa noite a todos!!

Hoje vou compartilhar com vocês mais um problema que passei, e realmente fiquei preocupado até achar a solução. Foi algo muito interessante e acho que muitos já devem ter passado por problemas parecidos (ao menos em nível de stress).

A história é mais ou menos a seguinte...

Estou realizando um trabalho de padronização de TABLESPACES em todas as bases de dados Oracle da organização onde trabalho. Esse trabalho consiste basicamente em criar as “N” tablespaces, divididas por tamanhos de extents distintos, como por exemplo: TBS50MB, TBS100MB, TBS500MB, etc.

Para alocar as tabelas e índices em uma tablespaces compatível com o tamanho do objeto, foi realizado um cálculo (que não vem ao caso) para que a tabela “residisse” em uma tablespace compatível com seu tamanho. Essa alteração é importante para muitas coisas, inclusive para facilitar o gerenciamento e melhorar performance dos scripts contra esses objetos.

O procedimento que estava realizando, e ainda estou pois são muitas bases, era o seguinte:

        1- Criação das tablespaces “corretas”;
        2- Realização da movimentação das tabelas e índices das tablespaces “antigas” para as novas através dos scripts abaixo:
a.     ALTER TABLE OWNER.TBL_TABELA MOVE TABLESPACE TBS50MB;
b.    ALTER INDEX IDX_TBL_01 REBUILD TABLESPACE TBS50MB;
        3- Após mover todos os objetos da tablespace, realizava o drop da tablespace antiga com o comando:
a.       DROP TABLESPACE TBSOLD INCLUDING CONTENTS AND DATAFILES;
        4- Depois de dropar a tablespace, acessava o servidor da base em questão e realizava a exclusão física do datafile (pois às vezes não eram excluídos pelo comando acima) e às vezes tinha que “derrubar” e iniciar a instância para conseguir excluir o datafile. Fazia isso para liberar espaço em disco gasto desnecessariamente, uma vez que os datafiles não seriam mais utilizados.

Basicamente foi isso que estava fazendo (mas pode acreditar, não é tão simples quanto parece).

Foi então que em uma das execuções, acabei interrompendo o trabalho para fazer alguma outra coisa, e quando retornei para essa atividade, executei o descrito no passo 4 antes do passo 3, ou seja, excluí o datafile antigo (e vazio) fisicamente antes de dropar a tablespace. Resultado, quando tentei “levantar” a instância, não consegui, pois quanto realizei o startup, foi solicitado o datafile excluído acidentalmente.

Na hora que dei conta de que tinha feito uma besteira, fui logo verificar como estava o backup, pois seria o pior dos casos realizar o recovery da base. Obviamente comecei essa tarefa de padronização das tablespaces pelas bases de teste e desenvolvimento, o que me fez respirar mais tranquilo para manter a “estabilidade emocional” (hehe).

Conversei com um colega também DBA sobre o que tinha acontecido e começamos a ver as possibilidades de solução que tínhamos para a situação. Procurei na internet sobre o assunto, foi então que encontrei, em um blog, um artigo com a seguinte chamada: How Drop Tablespace and Recover Oracle Database When Accidentally Delete Datafile.

Pessoal, isso foi um “achado”! (hehehe)

O autor expos uma situação muito parecida com a que vivi e descrevi acima, e a solução que ele apresentou foi mais ou menos a seguinte:

       1- Conectar no SQL*Plus como SYSDBA
a.       SQLPLUS /NOLOG
b.      CONNECT / AS SYSDBA
       2- O banco de dados deve estar no estado mount para conseguirmos executar o comando, então montemos o banco:
a.       STARTUP MOUNT;
        3- Em seguida, o comando que tornará o datafile off-line, e nos permitirá iniciar a instância (abrir o banco):
a.       ALTER DATABASE DATAFILE ' /opt/oracle/oradata/workspace/TBSOLD01.dbf' OFFLINE DROP;
        4- Agora vamos abrir o banco:
a.       ALTER DATABASE OPEN;
        5- Agora sim! Com a instância iniciada pude finalmente eliminar a tablespace do banco com o comando:
a.       DROP TABLESPACE TBSOLD INCLUDING CONTENTS AND DATAFILES;

É isso aí pessoal!

Realmente foi um susto o que ocorreu, um problema que pode acontecer com qualquer um (ou não... hehehe), mas felizmente foi tudo resolvido de forma tranquila.

Foi um ótimo aprendizado mas espero que vocês não passem por isso, porém caso ocorra, já sabem com solucionar, ok?!?!

Por hoje é só e até a próxima!

Referência:

MY DIGITAL LIFE - How Drop Tablespace and Recover Oracle Database When Accidentally Delete Datafile. Disponível em: http://www.mydigitallife.info/how-drop-tablespace-and-recover-oracle-database-when-accidentally-delete-datafile/. Acessado em: 04/04/2013.

Raphael Fernandes, quinta-feira, abril 04, 2013

1 comentário

2 de abr. de 2013


Olá a todos!

Hoje vou falar sobre particionamento de tabelas e índices no banco de dados Oracle, mas precisamente sobre uma situação que passei recentemente no trabalho.

Para entender a situação que passei, é necessário um conhecimento básico sobre particionamento de tabelas e índices no banco de dados Oracle. Particionamento é alvo de muitos artigos e documentos oficiais da Oracle, portanto não quero entrar nesse mérito, mas recomendo a leitura de Borovina e Legatti que explicam de forma clara e objetiva as definições e conceitos envolvidos. Também tem uma vasta documentação da Oracle disponível em vários artigos, um deles fala sobre: Particionamento no Banco de Dados Oracle 11g. Os links para esses artigos são citados nas referências desse post.

Agora vou apresentar de fato a situação que vivi:

Em uma instância Oracle 10g (na versão 10.2.0.3) tenho uma tabela particionada por lista.

A estrutura da tabela é mais ou menos a seguinte:

CREATE TABLE TBL_TABELA
(
COD NUMBER(9) NOT NULL,
CADASTRO NUMBER(9) NOT NULL,
MES NUMBER(2),
ANO NUMBER(4)
)
TABLESPACE TBS_DEFAULT

PARTITION BY LIST (ANO)
(
PARTITION P_2008 VALUES (2008) TABLESPACE TBS_P_2008,
PARTITION P_2009 VALUES (2009) TABLESPACE TBS_P_2009,
PARTITION P_2010 VALUES (2010) TABLESPACE TBS_P_2010,
PARTITION P_2011 VALUES (2011) TABLESPACE TBS_P_2011,
PARTITION P_DEFAULT VALUES (DEFAULT) TABLESPACE TBS_DEFAULT
);

Meu problema é que os dados dos anos diferentes de 2008,2009,2010 e 2011 cairão, obviamente, na partição default.

O que tenho que fazer, é criar partições para os anos de 2012 e 2013, porém a presença da partição DEFAULT me impede de fazer isso.

É importante saber que a partição default está com muitos dados (2012 e 2013) e não posso simplesmente dropar ela.

Essa era a minha situação problemática, que inclusive tentei ajuda no fórum de Rodrigo Almeida.

No início dessa semana, pesquisando sobre o assunto, achei uma técnica interessante para resolver o assunto.

Para inserir uma nova partição, com a presença de uma partição default, inicialmente criei as tablespaces para os anos de 2012 e 2013, conforme exemplo abaixo:

CREATE TABLESPACE TBS_2012 DATAFILE
  '/opt/oracle/oradata/workspace/tbs_2012.dbf' SIZE 2048M AUTOEXTEND OFF
NOLOGGING
ONLINE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 100M
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;

Em seguida utilizei o comando SPLIT PARTITION para realizer a divisão de uma partição, esse é o ponto crucial da solução do problema.

A sintaxe que utilizei foi mais ou menos a seguinte (para o ano de 2012):

ALTER TABLE TBL_TABELA
   SPLIT PARTITION P_DEFAULT  VALUES (2012)
   INTO  ( PARTITION P_2012 TABLESPACE    TBS_2012,PARTITION P_DEFAULT);


O resultado após a execução desse comando é uma partição P_2012 (que estará na tablespace TBS_2012) contendo os dados da tabela do ano de 2012 e os dados dos outros anos ficarão na partição P_DEFAULT (exceto para os anos que existem partições referentes), no meu caso apenas os dados de 2013.

Depois fiz a mesma coisa para a partição do ano de 2013, e pronto. Resolvida a situação!

Bom pessoal, por enquanto é isso.

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

Referências:

LEGATTI, EDUARDO - Oracle Blog - Um pouco sobre índices particionados no Oracle. Disponível em: http://eduardolegatti.blogspot.com.br/2011/12/um-pouco-sobre-indices-particionados-no.html. Acessado em: 02/04/2013.

BOROVINA, JOÃO MARCELO - Particionamento de Dados: Uma introdução aos conceitos e aplicação. Disponível em: http://www.devmedia.com.br/particionamento-de-dados-uma-introducao-aos-conceitos-e-aplicacao/7299. Acessado em 02/04/2013.

ALMEIDA, RODRIGO - Fórum: Problema com tabela particionada no Oracle 10g. Disponível em: http://www.rodrigoalmeida.net/forum/viewtopic.php?f=3&t=891&sid=2642261a63b71d2453109f92000e0a96 Acessado em: 01/04/2013.

Oracle Corporation - Particionamento no Banco de Dados Oracle 11g -Um artigo técnico da Oracle. Junho de 2007. Disponível em: http://www.oracle.com/technetwork/pt/database/enterprise-edition/documentation/particionamento-banco-de-dados-11g-432098-ptb.pdf. Acessado em: 31/03/2013.

Oracle Corporation - Maintaining Partitions. Disponível em: http://docs.oracle.com/cd/E11882_01/server.112/e25523/part_admin002.htm. Acessado em: 01/04/2013.

Raphael Fernandes, terça-feira, abril 02, 2013

Sem comentários

1 de abr. de 2013


Bom dia a todos!

Ontem estava lendo umas notícias, quando me deparei com uma que foge um pouco o assunto de banco de dados, mas é interessante por se tratar de tecnologia.

A notícia foi publicada 23/02/2013, e fala sobre ataques cibernéticos diante da “vulnerabilidade” da tecnologia JAVA. Na reportagem fala da ocorrências de ataques em empresas bastante conhecidas tais como: Apple, Facebook e Twitter; e que os criminosos que tentam invadir sistemas focaram na linguagem Java pois julgam que atualmente possui pontos de ataque mais fáceis.

A Oracle, que é a proprietária da linguagem Java (após a aquisição da Sun Microsystems) desde o ano de 2010, vem corrigindo os furos na linguagem, mas assim que as falhas são reparadas, novas são expostas, segundo a reportagem.

Confiram a matéria completa no site: http://www.advivo.com.br/blog/luisnassif/ataques-ciberneticos-expoem-oracle

É uma matéria interessante!

Fica a dica, e até a próxima!

Raphael Fernandes, segunda-feira, abril 01, 2013

Sem comentários