Um pouco de conceitos da Oracle sobre pfile e spfile

Olá pessoal!

O processo para inicialização de uma instância no banco Oracle é feito a partir da leitura do seu arquivo de inicialização, e os tipos desse arquivo é o assunto que vou abordar hoje.

Existem dois tipos de arquivos de inicialização para o Oracle: o PFILE (que é um arquivo texto conhecido também por init.ora) e o SPFILE que é um arquivo binário de parâmetros do servidor (conhecido como spfile.ora).

No post de hoje vou falar sobre alguns conceitos relacionados a esses arquivos, porém não vou entrar no detalhe sobre parâmetros, ou pelo menos não é minha ideia, pois o intuito desse artigo é falar sobre o que são esses arquivos, como e quando são usados.

O PFILE

Esse arquivo armazena os parâmetros de inicialização para "levantar" uma instância Oracle. Através desse arquivo, o DBA pode controlar a memória em seu banco de dados Oracle, atribuindo valores para os parâmetros de memória no arquivo INIT.ORA para o seu sistema. A localização deste arquivo varia, dependendo do sistema operacional em questão. Por exemplo:

 - No UNIX ou Linux, o init.ora poderá ser encontrado em: $ORACLE_HOME/dbs

 - No Windows, o diretório será: ORACLE_HOME/database

É possível que em alguns sistemas, exista mais de um arquivo init.ora, o que possibilita ter diferentes bases de dados com seus próprios parâmetros.

Por exemplo, initDESENV.ora pode controlar o banco de dados de desenvolvimento, initHML.ora o banco de dados de homologação, e initPROD.ora banco de dados de produção; ou ainda diferentes ambientes, como: initRH.ora, initFIN.ora, initADM.ora...

Como o PFILE é um arquivo de texto puro, ele pode ser editado no VI do UNIX ou no Notepad do Windows.

Para saber quais parâmetros podem ser alterados no PFILE, recomendo a leitura dos artigos: “INIT.ORA Parameters A-L” e “INIT.ORA Parameters M-Z” da TOAD WORLD.

O SPFILE (server parameter file)

O arquivo SPFILE é uma versão binária do PFILE. O SPFILE não pode ser alterado diretamente, porém através do comando ALTER SYSTEM é possível mudar alguns de seus parâmetros dinamicamente, ou seja, sem a necessidade de reiniciar o banco de dados. Para saber quais parâmetros podem ser alterados dinamicamente, pode-se executar uma consulta em uma view do schema SYS, conforme script abaixo:

SELECT * FROM V$PARAMETER;

O SPFILE possui algumas vantagens em relação ao PFILE, pois a Oracle criou procedimentos de otimização automática do banco baseadas no uso do SPFILE.

É possível verificar se existe o SPFILE com o seguinte comando:

SHOW PARAMETER SPFILE;

Para criar o SPFILE a partir do PFILE, pode-se utilizar os seguintes comandos:

CREATE SPFILE FROM PFILE;

ou

CREATE SPFILE FROM PFILE=’/U01/APP/ORACLE/PRODUCT/11.2.0/DBHOME_1/DBS/initSID.ORA’

ou

CREATE SPFILE=’/U01/APP/ORACLE/PRODUCT/11.2.0/DBHOME_1/DBS/spfileSID.ORA’ FROM PFILE=’/U01/APP/ORACLE/PRODUCT/11.2.0/DBHOME_1/DBS/initSID.ORA’

Após de qualquer um desses comandos, para efetivar a criação, é necessário reiniciar o banco:

SHUTDOWN IMMEDIATE;

STARTUP

Pode existir a necessidade, devido a alguma mudança dinâmica dos parâmetros do banco, que o DBA necessite gerar um novo init.ora (PFILE), a partir do SPFILE. O comando para realizar essa criação é:

CREATE PFILE FROM SPFILE;

Executando esse script, será criado um PFILE chamado init.ora no diretório $ORACLE_HOME/dbs (Linux/Unix) ou no $ORACLE_HOME/database (Windows).

É possível também que o DBA especifique um diretório de sua preferência para gravar o PFILE, basta executar comando:

CREATE PFILE=C:/TEMP/initTESTE.ORA FROM SPFILE;

Caso seja necessário iniciar um banco Oracle com o PFILE pode-se utilizar o seguinte comando:

STARTUP OPEN PFILE='/OPT/ORACLE/PRODUCT/9IR2/DBS/initSID.ORA'

Uma consulta interessante para saber se sua instância está utilizando o SPFILE ou PFILE, é apresentada abaixo:

SELECT DECODE (VALUE, NULL, 'PFILE', 'SPFILE') "INIT FILE TYPE" FROM SYS.V_$PARAMETER WHERE NAME = 'SPFILE';

É importante saber que para iniciar uma instância Oracle, os parâmetros de inicialização são buscados nos diretórios devidos (mencionados anteriormente com a variação entre UNIX e WINDOWS), na seguinte ordem:

1.  spfileSID.ora

2.  spfile.ora

3.  initSID.ora

4.  init.ora

Bom pessoal, por hoje é só!

Espero ter ajudado a entender um pouco sobre arquivos de inicialização no banco Oracle.

Sinta-se a vontade para deixar seu comentário com críticas, sugestões ou elogios sobre os artigos. Isso me ajuda a saber se agrado ou não com meus artigos e seus temas.

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

Referências:

ORACLE HOME. Disponível em: http://www.oracle-home.ro/Oracle_Database/Maintenance/PFILEvsSPFILE.html. Acessado em: 20/05/2013.

Carvalho, Pedro - Arquivos de Parâmetros PFILE e SPFILE do Oracle. Disponível em: http://www.pedrofcarvalho.com.br/PDF/ORACLE_SPFILE_PFILE.pdf. Acessado em: 20/05/2013.

Oracle - Starting Up a Database. Disponível em: http://docs.oracle.com/cd/B28359_01/server.111/b28310/start001.htm. Acessado em: 21/05/2013.

Oracle - Specifying Initialization Parameters. Disponível em: http://docs.oracle.com/cd/B28359_01/server.111/b28310/create005.htm. Acessado em: 21/05/2013.

TOAD WORLD - INIT.ORA Parameters A-L. INIT.ORA Disponível em: http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/ARC513A/Default.aspx. Acessado em: 21/05/2013.

TOAD WORLD - INIT.ORA Parameters M-Z. Disponível em: http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/ARC513B/Default.aspx. Acessado em: 21/05/2013.

TOAD WORLD - INIT.ORA Parameters. Disponível em: http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/ARC513/Default.aspx. Acessado em: 21/05/2013.

TOAD WORLD - Creating an SPFILE. Disponível em: http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/SPF1/Default.aspx. Acessado em: 21/05/2013.

Leia mais...

Recriação de índices - Rebuild Index

Olá pessoal!

Hoje vou falar um pouco sobre rebuild de índice no Oracle.

No dia 04/04/2013 postei uma situação que eu tinha vivido no trabalho. O nome do post foi: "Recuperar uma instância Oracleapós a exclusão acidental de um datafile". Em uma passagem do que escrevi, cito um comando (ALTER TABLE OWNER.TBL_TABELA MOVE TABLESPACE TBS50MB) que move uma tabela para outra tablespace (ou a mesma tablespace), porém em contrapartida torna os índices da tabela em questão "inutilizável", e é sobre isso que falarei agora!

Quando um índice está com status inutilizável (UNUSABLE), ele necessita ser reparado antes que possa ser usado. Diferentemente de um objeto PL/SQL por exemplo, pois quando é acessado a primeira vez o objeto é recompilado automaticamente pelo Oracle.

Para identificar se um índice está inutilizável, podemos usar a consulta abaixo:

SELECT owner, table_name, index_name

  FROM dba_indexes

WHERE status = 'UNUSABLE';

Mas o que fazer para tornar o ínidice utilizável novamente?

Bom pessoal...

A forma que vou usar para tornar um índice novamente preparado para utilização, é muito importante também para desfragmentar o índice (caso o mesmo esteja fragmentado).

O problema da fragmentação aparece quando atualizamos ou apagamos (update/delete)  dados de uma tabela. Se os campos alterados possuem índices associados, provavelmente o índice ficará fragmentado. Podemos dizer que a fragmentação é a existência de espaços não utilizados (ou disponíveis) no meio de um espaço utilizado. Isso porque os espaços que são liberados durante manipulação dos dados (update/delete) não são imediatamente reutilizado, o que resulta em “espaços livres" ou "blocos de dados espalhados nas tablespaces “.

Basicamente, a sintaxe que vou apresentar aqui é:

ALTER INDEX owner.nome_do_indice REBUILD;

Mas vamos fazer com que esse script seja gerado para todos os indices que estão inutilizáveis no banco.

SELECT    ' alter index '

       || owner

       || '.'

       || index_name

       || ' rebuild; '

  FROM dba_indexes

 WHERE status = 'UNUSABLE';

A projeção dessa query pode ser usado para reconstruir os índices, e pode também desfragmentar o índice. Não necessariamente a desfragmentação do índice ocorrerá pois dependerá da disponibilidade de espaço livre da tablespace.

Por hoje é só!

Espero ter contribuído e agregado algum conhecimento a você leitor.

Fico grato por você ler meu post, e indico a leitura dos demais artigos publicados.

Um grande abraço e até a próxima!

Leia mais...

Explicação sobre RAID

Muito bom dia, pessoal!

Hoje vou compartilhar rapidamente com vocês uma figura que vi e achei muito interessante. Se trata de uma "explicação" sobre RAID que encontrei no blog do sábio DBA Ricardo Portilho.

Muito legal e se assemelha muito com a realidade!!

Confiram na figura abaixo.

Figura 1 - Entendendo o que é RAID. (Fonte: Blog do Portilho)

Referência:

Blog do Portilho - GPO Blogs. Entendendo RAID. Dsponível em: http://profissionaloracle.com.br/blogs/portilho/2009/07/28/entendendo-raid/ Acessado: 09/05/2013.

Leia mais...

Um pouco sobre redo log file e archive

Olá, meus caros!

Recentemente passei por um problema na empresa onde trabalho e achei um tema interessante para se abordar aqui no blog. Resumidamente a situação foi a seguinte: um dos servidores de banco de dados foi inesperadamente desligado, e quando a máquina foi ligada, no momento em que tentávamos “levantar” uma instância, não foi possível pois um dos arquivos de redo log estava corrompido. Foi uma situação muito tensa, pois era uma base importante para o negócio da empresa. Não vou entrar no detalhe do que aconteceu, tampouco falar da solução, mas motivado pelo problema ocorrido vou falar hoje um pouco sobre redo log file e archive.

Bom, pessoal...

Para começar, acho de extrema importância conhecermos algumas estruturas do banco. São elas: log buffer, log writer e archiver. Basicamente, o primeiro (log buffer) é uma área de memória pequena onde são gravadas instruções de desfazer uma alteração (comando DML) disparada contra a base, antes de essa instrução ser gravada no disco (no redo log file). Eu escrevi algo sobre essa estrutura com um pouco mais de riqueza no artigo: [Hard Parse]Parte 01 - Execução de comandos DML. O log writer é o processo de background responsável pela gravação do conteúdo do log buffer no redo log file. O archiver também é um processo de background, porém sua existência está condicionada a uma configuração da instância (ARCHIVELOG). O archiver copia o conteúdo dos arquivos de redo log (que são arquivos cíclicos e reutilizáveis – falarei melhor sobre isso) em arquivos chamados de archives (ou redo log arquivado). Cada uma dessas estruturas podem ser alvo de bastante discussão e conteúdo, que não focarei nesse post, mas é importante que entendamos ao menos o básico para não nos atrapalharmos mais adiante em outras explicações.

Redo Log File

Esse arquivo é uma cadeia contínua e cronológica de cada vetor de alteração (“instruções” para desfazer um DML de alteração – insert, update, delete). Uma utilidade de fácil entendimento desses arquivos é na recuperação de uma base após um problema que necessite “voltar” o backup. Para que não haja perda de trabalho até o momento do crash ou erro, os arquivos de redo log podem ser aplicados ao backup para refazer o trabalho, adiantando-os no tempo até o momento em que o dano ocorreu.

John Watson afirma que o redo log pode ser dividido em dois tipos: redo log online e o redo log arquivado (os archives).

Cada banco de dados deve ter por definição pelo menos dois redo log online. Arquivos de redo log compõe um grupo de arquivo, e são conhecidos como membros. Um banco de dados requer ao menos dois grupos com pelo menos um membro para funcionar. Para um melhor desempenho, podem ser criados mais de dois grupos, e para uma maior segurança, deve-se criar mais de um membro por grupo (caso opte por essa configuração não é necessário se preocupar com desempenho ou sincronismo, pois o processo responsável irá gravar em todos os membros de forma paralela mantendo-os idênticos). A razão do requisito mínimo para o banco Oracle funcionar ser um mínimo de dois grupos é devido à situação de que enquanto um dos grupos (o de status current) está recebendo as alterações (através de comando do processo de background Log Writer – LGWR), o outro está sendo “arquivado” (pelo processo de background Archiver – ARCn), ou seja, está sendo gerado um Archive a partir de um Redo Log File com status inactive. Um passo a passo do processo pode ser o seguinte: ao tempo em que as sessões dos usuários atualizam registros (no buffer cache), elas também gravam vetores de alterações mínimos no redo log buffer, e o LGWR continuamente grava os dados desse buffer para os arquivos que compõem o grupo de arquivos de redo log atual (com status current). Por serem de tamanhos limitados, os redo log se alternam quando estiverem completamente cheios, tornando o outro grupo o atual. Se o banco de dados estiver configurado para gerar Archive (o que é uma segurança para que não haja perda de dados), os processos ARCn arquivarão (ou copiarão) os membros do redo log file que compõe o primeiro grupo. Quando o segundo grupo é totalmente preenchido, o LGWR mudará de volta para o primeiro (setará seu status como current) e irá sobrescrever seu conteúdo (que já foi arquivado), ao mesmo tempo, o ARCn começará a arquivar o segundo grupo (de status inactive). Basicamente é dessa forma que se dá esse processo, de forma cíclica (alternância de log) e reutilizando os membros dos grupos de redo log file.

É importante saber que é possível adicionar ou excluir redo log files (inclusive com tamanhos diferentes dos demais) a qualquer momento, sem a necessidade de reiniciar a instância.

Para criar um novo grupo de redo log file, podemos usar o comando abaixo:

ALTER DATABASE ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M;

Ou criar um novo grupo especificando o seu número:

ALTER DATABASE ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M;

E para adicionar um membro a um grupo, podemos utilizar o comando

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo' TO GROUP 2;

Ou de uma forma alternativa de identificar um grupo, que é identificando seus membros, conforme exemplo abaixo:

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo' TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo');

Para excluir um grupo do redo log file, segundo a Oracle, existem três restrições. São elas:

 - É necessário que a mais de dois grupos de redo log file, para após a exclusão ainda existirem o mínimo aceitável pelo banco de dados Oracle (conforme explicado anteriormente);

 - Só é possível excluir grupos de redo log com status inactive. Para excluir o grupo atual (current), é necessário primeiro alternar o log para torná-lo inactive.

 - Tenha certeza que o redo log file foi arquivado (se estiver no modo archive) antes de excluí-lo. Na view V$LOG é possível verificar se já ocorreu o arquivamento.

O comando da exclusão é o seguinte:

ALTER DATABASE DROP LOGFILE GROUP 3;

Para excluir um membro, deve-se atender aos requisitos citados para o grupo pois seguem as mesmas restrições. a Sintaxe é a seguinte:

ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';

Para forçar que o banco alterne o grupo de redo log atual, podemos utilizar o comando:

ALTER SYSTEM SWITCH LOGFILE;

Archive

Vamos falar um pouco sobre o tal redo log file arquivado, ou archive.

O banco Oracle garante que sua instância nunca fique corrompida, por meio dos redo log files, porém para garantir que não haja perda de dados após uma falha, é necessário ter um registro de todas as alterações aplicadas ao banco de dados desde o último backup. Por default, um banco de dados é criado em modo NOARCHIVELOG, o que significa que os redo log files são sobrescritos sem que tenha ocorrido o arquivamento dos seus dados. Quando alteramos o banco para o modo ARCHIVELOG, a Oracle afirma que é impossível que ocorra perda de dados (desde que os archives gerados após o último backup estejam disponíveis. Nesse modo, um novo processo de background (na verdade são quatro processos por default) será iniciado automaticamente: o Archiver (ARCn), isso nas versões do Oracle a partir do 10G.

É importante saber que a transição do modo NOARCHIVELOG para ARCHIVELOG (ou o contrário) só pode ser feita enquanto o banco está no modo mount após um shutdown e deve ser feito por um usuário com privilégio SYSDBA. Também é necessário fazer a configuração nos parâmetros de inicialização que controlam os nomes e os locais dos archives.

Para habilitar o modo ARCHIVELOG, podemos usar os comandos abaixo:

SQLPLUS /NOLOG

CONNECT / AS SYSDBA

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1=’LOCATION=/oracle/dbs/archives’ SCOPE=SPFILE;

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

Bom pessoal…

Por hoje é isso!

Espero ter ajudado no entendimento sobre o redo log file do Oracle e o Archive.

Grande abraço a todos e até a próxima.

Referências:

Oracle® Database Administrator's Guide - 11g Release 1 (11.1) - Creating Redo Log Groups and Members. Disponível em: http://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo003.htm. Acessado em 03/05/2013.

Oracle® Database Administrator's Guide - 11g Release 1 (11.1) - Dropping Redo Log Groups and Members. Disponível em: http://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo005.htm. Acessado em 03/05/2013.

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

Leia mais...

ODA - Oracle Database Appliance

Muito bom dia a todos!

Hoje vou fazer um breve comentário sobre a “tecnologia” da Oracle conhecida como ODA.

Para dar início, gostaria de informar que não trabalho com ODA, mas tenho estudado bastante sobre o sistema e o acho bastante interessante.

Bom...

ODA é a abreviação de Oracle Database Appliance, que segundo definição Oracle é um sistema projetado que consiste em hardware e software que economiza tempo e custo para os clientes, simplificando a implantação, manutenção e o suporte de soluções de banco de dados de alta disponibilidade.

Com essa tecnologia, a Oracle proporciona um sistema totalmente integrado de software, servidores, storage, e conectado à rede em um único equipamento que oferece serviços de alta disponibilidade em banco de dados, aplicável tanto para serviços operacionais (OLTP) quanto para aplicações gerenciais em data warehouse (OLAP). A figura 1 exibe a parte da frente de uma ODA.

Figura 1 - Frente da ODA. (Fonte: Oracle Corporation)

No vídeo abaixo é possível ter uma visão melhor do que é a ODA.

Falando um pouco dos recursos de uma ODA:

✔ Equipamento de banco de dados completamente integrado em um equipamento único
✔ Componentes com redundância e hot-swap: servidor, armazenamento, placa de rede, fonte e ventilador
✔ Sistema Operacional Oracle Linux
✔ Dois Servidores de banco de dados
✔ 24 núcleos de processadores
✔ 192 GB de memória
✔ 12 TB de armazenamento com triple-mirror (espelhamento triplo), oferecendo 4 TB de armazenamento em RAID-1
✔ 292 GB de armazenamento em drive de estado sólido
✔ Oracle Database, Enterprise Edition 11g

✔ Oracle Real Application Clusters ou Oracle Real Application Clusters One Node

✔ Oracle Automatic Storage Management (ASM)
✔ Oracle Enterprise Manager

Abaixo é possível conferir uma apresentação de Renato Martins sobre ODA.

O valor estimado para um sistema desse, segundo a 4Partner,  está a partir de R$ 260.000,00.

Para concluir, indico que assistam esse vídeo abaixo que trás uma explicação sobre a ODA com um toque de humor. É muito bom!

Bom pessoal, por hoje é só!

Espero ter ajudado.

Até a próxima

Fonte:

4Partner - Oracle Database Appliance. Fácil. Confiável. Acessível. Disponível em: http://oracledatabaseappliance.com.br/oracle/hardware/oracle-database-appliance/solucao-completa-de-hardware-e-software.html. Acessado em: 22/04/2013.

Oracle Corporation - About Oracle Database Appliance. Disponível em: http://docs.oracle.com/cd/E22693_01/doc.21/e22692/abtoda.htm. Acessado em: 22/04/2013.

Felipe do Carmo - Oracle Database Appliance. Disponível em: http://felipedocarmo.blogspot.com.br/2011/12/oracle-database-appliance.html. Acessado em: 2504/2013.

Leia mais...

Documentos úteis para um DBA

Olá a todos!

Hoje quero falar um pouco sobre algo que li recentemente em um artigo publicado em 2007 e achei bastante interessante. O artigo fala sobre alguns documentos que um DBA deve lidar. Esses documentos são úteis para organizar e gerenciar atividades do DBA, além do mais, um documento também serve de registro técnico sobre algo.

Bom...

Para começar queria deixar claro uma coisa... documentar é um trabalho muito chato!! Hehehe

Brincadeiras a parte, a documentação é algo de extrema importância, e temos que ter sempre em mente que criar ou atualizar um documento não é apenas um trabalho desnecessário que consome tempo e torna uma demanda mais lenta. Documentação é um item necessário e obrigatório em qualquer projeto, servindo a vários propósitos.  As metodologias estão aí para isso, e logicamente, devido à maturidade dos processos, agregam muito valor ao serviço.

É bastante normal na T.I. (vou corrigir isso, pois normal não é!!)... É bastante frequente na T.I. encontrar profissionais que não gostam de documentar, seja esse documento de qualquer natureza. Talvez seja uma cultura que trazemos da escola ou faculdade, mas que devemos mudar!

Li certa vez (não me recordo onde), que em termos de documentação nos serviços de T.I., as mulheres são muito mais comprometidas e responsáveis que os homens. E levando em consideração minha experiência profissional, eu concordo plenamente com isso! Não podemos generalizar, mas em uma visão superficial pode-se notar que mulheres são mais organizadas e dedicadas em trabalhos de documentação (obviamente existem exceções).

Segundo Pichiliani, “em geral, é difícil encontrar profissionais, em particular DBAs, que trabalhem com muita documentação. Isso se deve tanto à questão cultural como a questão que envolve a disponibilidade de tempo para criar e manter a documentação atualizada.”

A seguir é apresentada uma lista de documentos elencadas por Pichiliani, úteis tanto para quem trabalha tanto como DBA como analista ou desenvolvedor.

1) MER (Modelo Entidade Relacionamento)

O MER, chamado também de modelo de dados ou diagrama de entidade-relacionamento, é a principal documentação de um banco de dados.  Nesse documento deve constar todas as entidades (com seus atributos, tipos de dados e restrições) do banco e seus relacionamentos. O MER pode ser de três tipos: conceitual, lógico e físico, e cada um desses têm uma particularidade. Não entrarei no detalhe, mas recomendo a leitura do artigo de Adail Faleiro, que aborda de forma objetiva o assunto.

2) Documento de Padrões de Variáveis

Utilizar nomes de fácil entendimento em classes, métodos, atributos, etc, é cada vez mais frequente como pré-requisito para quem trabalha com desenvolvimento. Sendo assim, utilizar padrões é sempre uma boa prática de desenvolvimento. Com foco em banco de dados, possuir um padrão de nomes para tabelas, colunas, restrições, procedimentos, funções e demais objetos de dados é muito importante. Segundo Pichiliani, a idéia é possuir um padrão eficaz que seja fácil de ser utilizado, além de fazer sentido no contexto de banco de dados. Para formalizar a adoção do padrão, Pichiliani recomenda criar um documento explicando os detalhes deste padrão tais como: se os nomes devem ser em português, se as palavras devem estar no plural ou se há um limite no tamanho da coluna.

3) Plano de Capacidade

Fiz um post recentemente sobre as tarefas de um DBA, e das atividades que cito (conforme orientação da própria Oracle) é a de “avaliar o hardware do servidor de banco de dados”, e de acordo com Pichiliani, além de economizar recursos, dimensionar os recursos necessários mostra que existe um controle não apenas para o ambiente atual, mas também para os recursos que podem ser necessários no futuro. Para que esse dimensionamento seja registrado (podendo evitar possíveis problemas), o DBA deve elaborar um documento de Plano de Capacidade. Neste documento, informações sobre espaço de armazenamento e crescimento médio dos ambientes, utilização de CPU, utilização de memória e outros requisitos técnicos; devem estar contidos para exibir o funcionamento do servidor atual e até embasar aquisição de novos recursos (hardware ou software).

4) Dicionário de dados

O dicionário de dados é um documento onde deve constar uma coleção de metadados que contém definições e representações de elementos de dados. Ele pode ser considerado um documento complementar ao MER. No documento deve conter algumas das seguintes informações definição sobre os objetos, perfis de usuários, papéis e privilégios, restrições de integridade, valores possíveis para um campo, quantidade típica de valores armazenados, etc. Vale lembrar que este documento deve sempre estar atualizado com a base de dados atual, para evitar desgastes e problemas.

5) Política de segurança

De acordo com Pichiliani, um documento que informa a política de segurança é um objeto não necessariamente técnico que envolve os procedimentos, responsabilidades e atribuições relacionadas à segurança das informações e disponibilização delas. Geralmente documentos dessa natureza contêm regras de usuários e senhas, tais como: nível de dificuldade da senha, atualização periódica dela, bloquei após repetidas tentativas mal sucedidas.

6)  Acordo de nível de serviço (ANS) ou SLA (Service Level Agreement)

O SLA é um acordo firmado entre a área de T.I. e seu cliente, que descreve o serviço, suas metas de nível de serviço, além dos papéis e responsabilidades das partes envolvidas no acordo. Este acordo deve deixar claro quais serviços estão sendo oferecidos (serviços específicos) e o nível de cada serviço (horas de funcionamento, downtime, horário do suporte, etc). Segundo Pichiliani, e com foco em banco de dados, pode-se utilizar um SLA interno, onde o DBA se compromete a dar algum tipo de retorno (feedback) ao solicitante, nem que seja apenas a informação de que está ciente  da solicitação (mesmo que ainda não tenha uma solução para a situação). Acordo de nível de serviço é algo que está muito em alta no mercado de T.I., por isso sugiro a leitura da biblioteca ITIL V3.

7) Diagrama de arquitetura

Geralmente as organizações possuem diversos ambientes de banco de dados, que podem ser separados de acordo com sua utilidade, como por exemplo:

 - ambiente de desenvolvimento – banco utilizado por desenvolvedores e analistas de sistemas para criação de aplicativos;

 - ambiente de homologação – banco utilizado para realização de validações de usuários antes de implantação de um aplicativo;

 - ambiente de produção – onde os usuários finais trabalham com os dados reais dos sistemas.

O DBA deve elaborar um diagrama de arquitetura para facilitar o gerenciamento desses ambientes, onde deverá apresentar de forma gráfica, quais servidores pertencem ao ambiente de desenvolvimento, homologação e produção. Este tipo de diagrama contém informações relacionadas à estrutura arquitetural dos ambientes e é extremamente útil para quem não conhece a organização física e lógica dos componentes da rede e dos servidores.

8) Estratégia de Backup

Mais uma das tarefas de todo DBA que postei num artigo passado é a de “Realizar backup, restaurar e recuperar o banco de dados”. Todo DBA deve possuir uma estratégia de backup adequada que deve ser criada de acordo com as necessidades de recuperação e disponibilidade do sistema, ou seja, vai depender do quanto de downtime e tempo de recuperação é aceitável de acordado com os SLA’s. Esse tipo de documentação é importante para registro oficial sobre o que pode ser recuperado e em quais circunstâncias.

É isso aí, pessoal...

Obviamente existem vários outros documentos importantes para um DBA, mais esses são alguns dos mais interessantes, e que todo DBA deve manter.

Espero ter ajudado!

Até a próxima.

Referências:

Pichiliani, Mauro - Documentação do DBA – 11/06/2007. Disponível em: http://imasters.com.br/artigo/6392/sql-server/documentacao-do-dba/ . Acessado em: 18/04/2013

Faleiro, Adail Tiago Lima - Modelo Entidade Relacionamento (MER). Disponível em: http://www.devmedia.com.br/modelo-entidade-relacionamento-mer/19821. Acessado em: 19/04/2013.

Leia mais...

Vídeo sobre recuperação de desastre

Olá a todos!

Estava procurando um documento em minha máquina, quando me deparei com anotações que tinha realizado enquanto cursava minha especialização em banco de dados. As anotações eram da disciplina  “Contingência e Alta Disponibilidade”. Me lembrei de um vídeo muito interessante que o professor tinha exibido para a turma. O vídeo era sobre um teste de recuperação de desastre com uma solução da HP.

Foi então que comecei a procurar o vídeo e achei!

Confiram e tirem suas conclusões.

Esse vídeo está no youtube, mas seu endereço original está no site da HP.

Em breve, quando estiver com um tempinho a mais extra, falarei sobre algumas coisas que aprendi sobre contingência e alta disponibilidade, focando mais para a área de banco de dados.

Até a próxima!

Leia mais...

Tarefas de um administrador de banco de dados Oracle

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.

Leia mais...