iMasters - Se��o: oracle

RMAN: customizando o seu backup

dbarodrigo@gmail.com (Rodrigo Almeida) — Mon, 08 Feb 2010 10:30:00 +0100

Um dos pontos fortes de trabalhar com o Recovery Manager (RMAN) � a possibilidade de alocar uma determinada quantidade de canais necess�rios no processo de Backup para melhorar o desempenho de I/O durante a tarefa, diminuindo o tempo do backup.

Os administradores de banco de dados (DBA) muitas vezes gostam de utilizar a aloca��o de canal manual para efetuar o backup e, com isso, torna-se necess�rio mencionar a cada canal (channel) alocado o caminho em que dever� ser gerado o backup set. Como o script abaixo:

run {
allocate channel t1 type disk format '/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman';
backup current controlfile tag 'BKP_CF';
release channel t1;
}

Perceba que durante a aloca��o do canal t1, � utilizada a cl�usula FORMAT, que posteriormente menciona o caminho e o nome do backupset que ser� gerado pelo RMAN. Pois bem, se voc� costuma utilizar 3, 4, 5 ou mais canais, em um �nico caminho de backup e usando sempre a mesma m�scara de nomenclatura de backup set, tornando os scripts fr�geis.

Vamos analisar o exemplo e dividir as tarefas e customizar o RMAN, a partir da cl�usula FORMAT. Veja:

Quantidade de canais = 3
Caminho de Backup = /u02/app/oracle/backup/rman
Nomenclatura de Backup set = bkp_%d_%t_%s.rman

Sobre a nomenclatura utilizada, segue a explica��o:

bkp_ = Nome inicial dos backupsets gerados, ou seja, definido por mim, � um valor fixo.
%d = Vari�vel do RMAN para identificar o nome do banco de dados.
%t = Vari�vel do RMAN para o Time Stamp do backup set.
%s = Vari�vel do RMAN para identificar a sequ�ncia do backup set.

Agora, vamos colocar na pr�tica essa customiza��o.

01. Logue-se no banco de dados usando o RMAN

[oracle@ORA11G ~]$ rman target /
Recovery Manager: Release 11.1.0.6.0 - Production on Thu Aug 6 
10:57:15
Copyright
 (c) 1982, 2007, Oracle. All rights reserved.
connected
 to target
 database: RADB (DBID=1241100324)

02. Configure o caminho e o nome do backup set no control file

As informa��es sobre a customiza��o do RMAN ser�o armazenadas no control file. Para configurar emita o comando abaixo:

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman';
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman';
new RMAN configuration parameters are successfully stored

03. Defina a quantidade de aloca��o de canal autom�tico

Para definir a quantidade de aloca��o de canais autom�ticos, quando executado qualquer script do RMAN para o banco de dados alvo, a estrat�gia � utilizar o PARALELISMO. E para configurar essa op��o, basta executar o passo abaixo:

CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters are successfully stored

04. Verifique as configura��es alteradas

show all;
using target database control file instead of recovery catalogRMAN configuration parameters for database with db_unique_name RADB are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BZIP2'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.1.0/db_1/dbs/snapcf_RADB.f'; # default

05. Teste o novo script

Agora, veja como ficou o script com as customiza��es que foram feitas. Em negrito est�o as novas configura��es realizadas para o RMAN.

run {
shutdown immediate;
startup mount;
backup database include current controlfile tag 'BKP_FULL';
alter database open;
}
database closeddatabase dismounted
Oracle instance shut down
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 644468736 bytes
Fixed Size 1301840 bytes
Variable Size 293601968 bytes
Database Buffers 343932928 bytes
Redo Buffers 5632000 bytes
Starting backup at 06/08/2009 11:26:16
allocated channel: ORA_DISK_1allocated channel: ORA_DISK_2allocated channel: ORA_DISK_3/u02/app/oracle/backup/rman/bkp_RADB_694178799_15.rman tag=BKP_FULL comment=NONE
channel ORA_DISK_3: backup set complete, elapsed time: 00:03:16
channel ORA_DISK_3: starting full datafile backup set
channel ORA_DISK_3: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_3: starting piece 1 at 06/08/2009 11:30:43
channel ORA_DISK_3: finished piece 1 at 06/08/2009 11:31:23
piece handle=/u02/app/oracle/backup/rman/bkp_RADB_694179009_16.rman tag=BKP_FULL comment=NONE
channel ORA_DISK_3: backup set complete, elapsed time: 00:00:40
channel ORA_DISK_1: finished piece 1 at 06/08/2009 11:34:13
piece handle=/u02/app/oracle/backup/rman/bkp_RADB_694178778_13.rman tag=BKP_FULL comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:07:48
channel ORA_DISK_2: finished piece 1 at 06/08/2009 11:35:04
piece handle=/u02/app/oracle/backup/rman/bkp_RADB_694178786_14.rman tag=BKP_FULL comment=NONE
channel ORA_DISK_2: backup set complete, elapsed time: 00:08:30
Finished backup at 06/08/2009 11:35:04
Starting Control File and SPFILE Autobackup at 06/08/2009 11:35:04
piece handle=/u01/app/oracle/flash_recovery_area/RADB/autobackup/2009_08_06/o1_mf_s_694178760_57otk638_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 06/08/2009 11:35:29
database opened
channel ORA_DISK_1: SID=154 device type=DISK

channel ORA_DISK_2: SID=153 device type=DISK

channel ORA_DISK_3: SID=151 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u02/app/oracle/oradata/RADB/system01.dbf
channel ORA_DISK_1: starting piece 1 at 06/08/2009 11:26:26
channel ORA_DISK_2: starting full datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00002 name=/u02/app/oracle/oradata/RADB/sysaux01.dbf
input datafile file number=00004 name=/u02/app/oracle/oradata/RADB/users01.dbf
channel ORA_DISK_2: starting piece 1 at 06/08/2009 11:26:34
channel ORA_DISK_3: starting full datafile backup set
channel ORA_DISK_3: specifying datafile(s) in backup set
input datafile file number=00005 name=/u02/app/oracle/oradata/RADB/example01.dbf
input datafile file number=00003 name=/u02/app/oracle/oradata/RADB/undotbs01.dbf
channel ORA_DISK_3: starting piece 1 at 06/08/2009 11:26:47
channel ORA_DISK_3: finished piece 1 at 06/08/2009 11:30:03
piece handle=

PRONTO!

Deste modo conseguimos definir regras de backup mais customizadas para cada banco de dados. � v�lido lembrar que, nos exemplos, realizei os testes de backup diretamente para disco, por�m, � poss�vel configurar os mesmos par�metros para FITA, de acordo com a sua configura��o MML no ambiente.

Abra�os,

Ignorando acentos no Oracle

leonardo.litz@gmail.com (Leonardo Litz) — Fri, 05 Feb 2010 10:00:00 +0100

�Hoje vamos falar um pouco sobre usabilidade utilizando o Oracle. � muito comum vermos em grande sites de e-commerce, buscas e relacionamentos, entre outros, que mesmo digitando uma palavra, sem sua acentua��o correta, ou at� mesmo com acento colocado errado, encontramos a informa��o desejada. Pois bem, veremos como isso � poss�vel utilizando um banco de dados Oracle.

Para a consulta funcionar, devemos alterar os par�metros nls_comp e nls_sort.

O par�metro nls_comp determina qual m�todo de compara��o ser� considerado na consulta. Ap�s a instala��o do banco de dados seu valor inicial � "binary".

Binary: todo SQL executado e baseado no m�todo bin�rio, exatamente da forma que est� escrita a informa��o.
Linguistic: todo SQL executado e baseado no M�todo ling��stico, considerando a busca e a ordena��o como a palavra e falada.

O Par�metro nls_sort define qual combina��o ling��stica ser� utilizada. Para instala��es em que o idioma escolhido � o Portugu�s (nls_language= portuguese), o valor para o padr�o ling��stico � o "Bin�rio" (nls_sort = binary).

Por exemplo, utilizando a combina��o bin�ria, temos as seguintes op��es:

O sufixo _ci indica que ser� utilizada a combina��o bin�ria com Case-Insensitive Sort.

O sufixo _ai indica que ser� utilizada a combina��o bin�ria com Accente Insensitive Sort. Pode haver outros valores para o par�metro como, por exemplo, xspanish_ia, mas isso j� � assunto para outro artigo.

Binary: segue exatamente da mesma forma que foi escrita.
Binary_ci: o algoritmo compara exatamente como a palavra foi escrita, desconsiderando as letras mai�sculas e min�sculas. (Case-Insensitive Sort).
Binary_ai: o algoritmo compara as palavras ignora a acentua��o e os mai�sculos e min�sculos. (Accent Insensitive Sort).

Por exemplo:

A letra "a" pode ser comparada com as letras "�,�,�,�,�,�"; a letra "�" pode ser comparada com as letras "e,�,�,�", dentre outras acentua��es.

Estes par�metros podem ser definidos para todo o banco de dados ou somente para uma se��o. O ideal � utilizar em locais apenas onde h� real necessidade, pois se utilizado para todo ambiente, pode degradar a performance do banco de dados.

Vamos praticar.

Em nosso cen�rio vamos considerar um cadastro de produto, que ser� utilizando em um E-Commerce.

Logo, se um cliente digitar o nome do produto sem a acentua��o necess�ria ou com a acentua��o errada, o sistema deve ser capaz de identificar e retornar o produto que ele procura.

Vamos criar um simples cadastro de produtos:


create table tb_produto(nome varchar2(40), valor number(16,4));
insert into tb_produto(nome,valor) values ('Fog�o 4 bocas',300);
insert into tb_produto(nome,valor) values ('Fogao 6 bocas',600);
insert into tb_produto(nome,valor) values ('Lava-lou�as',800);
insert into tb_produto(nome,valor) values ('Jogo de Faca',120);

Primeira situa��o:

Digamos que o cliente digitou o nome do produto com a acentua��o correta, mas toda a palavra em min�scula, e que estamos utilizando o m�todo bin�rio para consulta. Logo, ele n�o encontrar� o produto que procura!

SQL> select * from tb_produto where nome = 'lava-lou�as';

NOME                                                  VALOR
---------------------------------------- ------------------

Vamos mudar os nossos par�metros para n�o diferenciar mai�sculos e min�sculos.

SQL> alter session set nls_comp=linguistic;

Session 
altered

SQL> alter session set nls_sort=binary_ai;

Session
 altered

Veja que agora o Oracle encontra o produto solicitado.

SQL>  select * from tb_produto where nome = 'lava-lou�as';

NOME                                                  VALOR
---------------------------------------- ------------------
Lava-lou�as                                        800,0000

Segunda situa��o:

Vamos simular que o usu�rio digitou o nome do produto sem a acentua��o devida.

SQL> select * from tb_produto where nome = 'lava-lou�as';

NOME                                                  VALOR
---------------------------------------- ------------------

Agora vamos mudar o m�todo de compara��o para ling��stico, na se��o que estamos trabalhando.

SQL> alter session set nls_comp=linguistic;

Session altered

SQL> alter session set nls_sort=binary_ai;

Session altered

Veja que o Oracle interpretou a letra "c" sendo a mesma que "�". Ou seja, ignorou o acento.

SQL> select * from tb_produto where nome = 'lava-loucas';

NOME                                                  VALOR
---------------------------------------- ------------------
Lava-lou�as                                        800,0000

Veja que, mesmo se for�armos um acento indevido, poderemos saber o pre�o da lava-lou�a.

SQL> select * from tb_produto where nome = 'lava-louc�s';

NOME                                                  VALOR
---------------------------------------- ------------------
Lava-lou�as                                        800,0000

Assim chegamos ao final de mais um artigo, espero que tenham gostado!

Achei um ORA-600, o que fa�o?

dbarodrigo@gmail.com (Rodrigo Almeida) — Mon, 01 Feb 2010 11:15:00 +0100

O t�tulo deste artigo j� diz muita coisa, "Achei um ORA-600, o que fa�o?". Muitos gostariam de ter o bot�o EJECT na cadeira, outros de ser ninjas e jogar o p� para desaparecer e alguns gostariam de ser o novo David Blaine. Na verdade, esse n�mero "cabal�stico" de erro pode ser o in�cio de uma longa jornada.

O RDBMS (Relational Database Management System) Oracle possui dois c�digos de erros que assustam qualquer DBA, o bendito ORA-600 e ORA-7445. Neste momento vamos refletir sobre o ORA-600, o que ele realmente significa para n�s.

Quando o encontramos no alert.log ou diretamente pelo Oracle Server (via SQL*PLUS ou qualquer outra aplica��o), significa que temos um problema na aceita��o do comando no kernel do RDBMS ou temos uma inconsist�ncia em um determinado processo, que, geralmente, pode estar associado a um BUG. Mas nem sempre � um BUG, por isso que temos que ter muita calma nessa hora. O Metalink disponibiliza uma ferramenta de pesquisa para esse espec�fico erro, o chamado ORA-600 Lookup tool. Atrav�s dele, pode ser encontrada a solu��o para seu espec�fico erro, se existe um patch off -� uma corre��o para o determinado problema -, patch set, que � um conjunto de corre��es dos produtos, ou se h� um simples workarround "gambiarra" para realizar.

O ORA-600 pode ser um problema causado por diversos fatores, como:

Falta de recurso de hardware: a falta de recursos de mem�ria, problemas de disco ou problemas no funcionamento do hardware�podem auxiliar seu aparecimento.

Configura��o do Sistema Operacional: uma m� instala��o e falta de patchs no sistema operacional pode causar o ORA-600, e quando digo m� instala��o, gosto de me referir aquela instala��o, NEXT-NEXT-FINISH.

Falta de atualiza��o do banco de dados: podem perceber que a Oracle, quando lan�a um produto, possui diversos Patch sets, que � um conjunto de corre��es (Patch offs) que � detectado pelo suporte da Oracle em acompanhamento de seus clientes. A falta de atualiza��o s� aumenta a sua chance de ter um amigo ORA-600.

Utiliza��o de News Features: sempre que � lan�ada uma vers�o nova de banco de dados, com por exemplo, vers�o, 8.1.0, 9.1.0, 10.1.0 ou 11.1.0, (l�gico, em suas respectivas �pocas) e na sua aplica��o come�a a utilizar as features da vers�o (novos recursos de desenvolvimento ou banco de dados), **COM CERTEZA**, encontrar� um ORA-600 em algum momento de sua humilde vida. Isso � porque o Kernel do RDBMS ainda n�o est� "amadurecido" para executar "tal" tarefa, sobre "tal" hardware, com "tal" sistema operacional com "tal" linguagem de programa��o.

Como sempre digo, ter um ORA-600�na base de dados nem sempre � uma quest�o de desespero ou assinar a sebten�a de morte. Tudo bem que talvez voc� vire algumas noites na empresa, mas isso passa. O ORA-600 pode vir a qualquer momento, porque ele � resultante de diversos fatores como dito acima e **SIM**, para alguns tipos de ORA-600, podem ser resolvidos rapidamente.

Toda vez que se tem um ORA-600, � gerado um arquivo de trace no servidor, no diret�rio USER_DUMP_DEST ou BACKGROUND_DUMP_DEST(depende qual ser� o processo afetado). Nesse arquivo de trace, para quem � mais experiente, poder� encontrar as ra�zes dos problemas. Pode ser um "LAZARENTO" de uma instru��o de SELECT que faz join com uma INLINE VIEW, que tamb�m faz um hash join com uma Materialized view e tem uma view com dblink que for�a o aparecimento do ORA-600, ou como pode ser um simples INSERT em tabelas IOT e assim vai, s� com bastante analise iremos saber as causas. Mas onde quero chegar com isso?

Quando se tem o erro ORA-600 em m�os, devemos tentar entend�-lo, como mostra um exemplo de mensagem abaixo:

ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []

ORA-00600: internal error code, arguments: [12209], [498], [], [], [], [], [], []

Podemos ter uma id�ia de onde vem o poss�vel problema, a mensagem de erro � sempre composta por ORA-600 [argumento1] [argumento2] at� o [argumento8]. Se estudarem a arquitetura interna do Oracle, o kernel � composto por diversas travas que fazem o controle, acesso e utiliza��o dos dados.

Ningu�m sabe dizer com 100% de certeza se o kernel do Oracle � puramente escrito na linguagem C, mas dizem que possui algumas coisas em Java para os releases superiores ao 9i. Pois bem, isso n�o interessa at� o momento, eu quero apenas exemplificar como o kernel trabalha.

Analisando o trace gerado, podemos ter a id�ia de onde ele vem, como eu disse acima (por SELECT, INSERT, CREATE e etc), e sempre devemos prestar aten��o no primeiro argumento, pois � ele que dir� em qual momento ou trava ocorreu o problema.

No primeiro erro mencionado, nosso primeiro argumento foi o kcbz_check_objd_typ_3, que internamente para o Oracle a trava KCBZ quer dizer Kernel Cache Buffer, ent�o j� podemos ir mais profundamente e pensar que ocorreu um erro no tratamento da informa��o durante sua passagem pelo SGA.

No segundo erro, como n�o existe nenhuma trava mencionada no primeiro argumento, e n�o envolve travas do kernel, pode ser algum problema apenas como manipula��o dos dados ou quebra de integridade interna, e, por isso, d� uma esperan�a que pode ser um ORA-600 com resolu��o r�pida.

Ambos os erros podem estar associados a um BUG da vers�o ou apenas uma m� interpreta��o do banco de dados, isso, apenas olhando o erro e o trace n�o iremos conseguir garantir nada. � apenas um exemplo e modo de como podemos se comportar com um ORA-600 no banco de dados.

Lembrete

Sempre, mas sempre mesmo, que tiver um ORA-600 em sua base de dados, acione de imediato o suporte da Oracle para analisar profundamente os motivos do aparecimento do problema e realizar uma investiga��o sobre seu ambiente, como mencionado, os fatores podem ser diversos e tamb�m pode ser ou n�o um real BUG da sua vers�o.

Estou apenas dizendo uma experi�ncia que tenho no dia-a-dia e n�o me responsabilizo pelos seus atos. Espero que tenham gostado desse assunto e que possa entender melhor o motivo do nosso velho amigo ORA-600.

Abra�os,

Ferramentas RDA e SCM, qual a diferen�a?

dbarodrigo@gmail.com (Rodrigo Almeida) — Mon, 25 Jan 2010 10:00:00 +0100

Ol�!

Para quem trabalha em empresas que possuem diversas bases de dados e t�m contrato de suporte com a Oracle, como Metalink, Oracle Consulting�ou parceiras da empresa, j� conhece ou deve ter ouvido falar sobre as ferramentas de suporte �s equipes de DBA, o RDA (Remote Diagnostic Agent) e o SCM (Software Configuration Management).

Pois bem, muitos confundem e acham que essas ferramentas s�o a mesma coisa, ou que o SCM � uma vers�o do RDA melhorado, que realmente parece ter a mesma funcionalidade, mas existe um diferen�a entre eles.

O RDA � uma ferramenta de suporte da Oracle desenvolvido em Perl, que tem como principal finalidade captar diversas informa��es do ambiente do cliente para ajudar na solu��o de problemas quando se tem um TAR aberto no Metalink. Essas informa��es variam desde o sistema operacional, configura��es de rede, java at� informa��es do banco de dados e seus respectivos produtos, como ASM, Enterprise Manager, EBS, iAS�e etc.

Sua fun��o � auxiliar no momento da abertura do TAR ou durante o processo de investiga��o de seu problema junto � Oracle. Ao instalar e configurar o RDA, e posteriormente a sua execu��o, s�o coletados informa��es essenciais para os analistas, pois o RDA no final da execu��o gera um arquivo compactado contendo diversos relat�rios em extens�o HTML com todas as informa��es citadas acima.

O SCM j� trabalha de forma diferente, sua finalidade tamb�m � captar todas as informa��es sobre seu ambiente para ajudar na resolu��o de seus problemas, quase as mesmas que do RDA, por�m, seu grande diferencial � que ele trabalha com os chamados coletores, ou OCM (Oracle Configuration Manager), que podem ser executados em per�odos de tempo de acordo com a sua necessidade e ociosidade do sistema, ou seja, ap�s sua instala��o e configura��o correta, ele envia todas as informa��es coletadas para um reposit�rio on-line na Oracle, que pode ser acessado pelo novo site do Metalink, o My Oracle Support, com essas informa��es retidas na Oracle, ele automaticamente analisa e fornece dicas e alertas sobre seu banco de dados, quais patchs est�o faltando no banco, dicas para melhorar seguran�a, informa��es de ajuste para alguns par�metros e etc. Deste modo, fornece uma habilidade de pr�-atividade aos DBAs, mantendo sempre atualizado.

Ambas as ferramentas s�o multi-plataformas, ou seja, podem ser utilizadas tanto em ambientes Windows, Linux e Unix. Para cada caso existem scripts espec�ficos para cada sistema operacional.

O RDA sempre foi uma ferramenta muito boa n�o apenas para lhe auxiliar nas tarefas junto ao suporte da Oracle, mas tamb�m para consultores de banco de dados que trabalham em diversas empresas e que precisam conhecer o ambiente que ir� enfrentar, j� que seus relat�rios podem ser vistos de forma offline e completo, ajuda em muito para conhecer o sistema.

Eu apenas estou dando uma pequena pr�via sobre essas ferramentas, que considero como um recurso b�sico em qualquer equipe de administradores de banco de dados. Quem tem acesso ao Metalink, recomendo que veja como funciona essas ferramentas atrav�s de demonstra��es da pr�pria Oracle e conhe�a mais tecnicamente o que cada uma pode lhe oferecer. Existem tamb�m Web Seminars em portugu�s gratuitos no site para lhe auxiliar na aprendizagem.

D�vidas e sugest�es, visitem o meu blog.

Abra�os,

Crescendo profissionalmente no mundo Oracle

dbarodrigo@gmail.com (Rodrigo Almeida) — Mon, 11 Jan 2010 09:30:00 +0100

Ol�!

Gostaria de discutir um assunto que vem me chamando muito a aten��o nesses �ltimos tempos, a for�a que as comunidades Oracle podem oferecer aos profissionais iniciantes e at� mesmo aos mais experientes. E quando estamos falando de comunidades, estamos diretamente nos referindo aos grupos de usu�rios, sites e f�runs na internet. E o mais importante, eles podem lhe ajudar no seu crescimento profissional e t�cnico na �rea de tecnologia Oracle.

As comunidades Oracle, ultimamente, com o apoio da pr�pria Oracle, v�m crescendo e amadurecendo com a experi�ncia de seus pr�prios usu�rios. Esse crescimento podemos notar pelos eventos, conte�dos t�cnicos, blogs e o enriquecimento dos seus respectivos f�runs. Eu mesmo sou um f� de carteirinha de diversos sites Oracle brasileiros pelos servi�os e eventos que oferecem.

Mas como a comunidade pode ajudar no meu crescimento profissional?

A resposta � simples: nada melhor que voc� compartilhar a sua experi�ncia t�cnica e profissional com outros profissionais que realizam a mesma fun��o que voc�. Pela simples troca de experi�ncia em problemas de outras pessoas a partir de f�runs ou lista de discuss�es, voc� consegue estudar mais sobre o assunto, o outro profissional conhece novas t�cnicas, outros usu�rios que est�o participando do assunto conhecem mais sobre o problema e quando voc� vivenciar o problema discutido na empresa ou cliente que trabalha, j� ir� saber quais os passos e tarefas necess�rias para chegar a sua solu��o.

E o que dizer sobre recomenda��es de livros, eventos, white papers e at� mesmo ambiente de trabalho? Nada melhor do que voc� discutir isso com profissionais que est�o no mercado, que fazem o que voc� faz todos os dias. Simplesmente n�o d� para chegar em casa e tentar conversar com a sua esposa(o) sobre um erro ORA-600 que aconteceu contigo nesta manh�. No meu caso, minha esposa � administradora - se comento sobre erros ORA-600, ela pensa que � placa de carro, c�digo de guerra ou qualquer coisa de outro mundo. E, desse jeito, n�o temos muito assunto!

Por isso que as comunidades est�o se tornando mais fortes no Brasil conforme o crescimento da tecnologia Oracle acontece. F�runs e sites s�o as nossas casas virtuais, sempre recorremos � elas quando precisamos ou queremos saber algo sobre um determinado assunto. Ali�s, dentro de f�runs conhecemos usu�rios e ganhamos amigos, aumentando nossa network. E, talvez, conheceremos os amigos virtuais em eventos criados pela pr�pria Comunidade.

Outro ponto importante � que todo iniciante tem tr�s d�vidas b�sicas, tais como:

Como iniciar na carreira;
Quais os melhores livros para comprar;
Qual o melhor centro de treinamento;
E o b�sico de f�runs, ME AJUDE NO TRABALHO DE FACULDADE. (Opcional)

Algumas coisas podem ser respondidas pelo Google, mas, com certeza, nos diversos f�runs de Oracle que temos aqui no Brasil, sabendo usar o SEARCH/PROCURAR do f�rum, j� temos t�picos com t�tulos bem parecidos com os que est�o acima, com dicas e sugest�es de diversos profissionais, com diversos pontos de vista e recomenda��es do que deve ou n�o ser feito. Isso � centraliza��o, dissemina��o, orienta��o e agilidade que uma comunidade pode lhe oferecer.

Para os mais experientes, que j� sabem o poder da comunidade, al�m da troca de experi�ncia, conte�do t�cnico e network, algo que chama aten��o s�o as VAGAS DE EMPREGO. Sim, o mercado de DBA � muito restrito e nada mais normal que, nesse pequeno c�rculo de profissionais, vagas que se abrem em outras empresas, se compartilhadas por eles mesmos. Um exemplo disso � a chamada RECOMENDA��O. Muitas vezes voc� n�o conhece o profissional fisicamente, por�m, acompanha seus trabalhos, posts em blogs ou f�runs e sabe que a tal pessoa domina sobre a tecnologia. Ent�o, em vez de voc� deixar que o departamento de RH escolha um profissional para a vaga, o que pode ser um problema, voc� passa a indica��o ao gerente e/ou diretor de TI, conforme os requisitos da vaga. E, deste modo, pode ter certeza de que a contrata��o ser� muito mais valiosa e agregadora � empresa, pois geralmente RH n�o sabe mensurar um profissional para o tipo de problema ou requisito que a empresa est� necessitando.

Para concluir, � v�lido saber que comunidades Oracle, principalmente as brasileiras, est�o cheias de pessoas que colaboram e dedicam o seu tempo livre para ajudar e compartilhar sua experi�ncia com os mais novos, com a cria��o e a organiza��o de eventos, artigos t�cnicos, blogs, f�runs, lista de discuss�es por e-mail, chats e etc, elevando o n�vel de conhecimento, enriquecendo a internet e compartilhando a informa��o. Seguindo o velho ditado:

O importante � sempre compartilhar para multiplicar.

Para conhecerem mais sobre as nossas comunidades Oracle, preparei uma p�gina sobre comunidades, grupos de usu�rios, f�runs e sites em geral que podem lhe ajudar nessa caminhada.

Saiba mais sobre as Comunidades Oracle.

Abra�os,

Fun��es pipelined em Oracle

leonardo.litz@gmail.com (Leonardo Litz) — Fri, 31 Jul 2009 10:00:00 +0100

Por defini��o, uma fun��o de pipelined � aquela que retorna uma cole��o de dados, foi implementada pela Oracle a partir da vers�o 9i. Imagine ter que desenvolver uma query, com v�rias regras embutidas. Ter�amos que criar, codificar v�rias linhas de c�digo, talvez tenhamos que utilizar subquerys, minus, intersect, unions, decodes, cases, dentre outros recursos para que possamos obter o resultado esperado. Agora imagine a manuten��o disso. Dentre outras utilidades, uma fun��o de pipelined permite a simplifica��o do c�digo, tornando mais r�pido o desenvolvimento e �gil sua manuten��o.

Muitas vezes, durante o desenvolvimento, torna-se necess�rio criar uma seq��ncia de n�meros ou datas, que n�o est�o em tabelas, ou ent�o desejamos obter resultados de c�lculos, f�rmulas ou at� express�es condicionais. Para estes casos podemos utilizar fun��es de pipelined. Al�m de facilitar o desenvolvimento, � muito mais r�pida e de menor custo que uma query comum para retornar os dados.

� poss�vel facilitar o desenvolvimento com uma fun��o de pipelined. Veremos como.

Nosso cen�rio ser� um relat�rio de movimento de estoque de uma loja virtual. Um usu�rio deseja visualizar quantos itens de determinado produto foram movimentados a cada minuto. A estrutura da tabela de movimentos de estoque grava a data do movimento e a quantidade movimentada de um item. O resultado esperado deve estar no seguinte layout:

De	At�	Quant. Movimentada
5/7/2009 07:40:01	5/7/2009 07:41:00	0
5/7/2009 07:41:01	5/7/2009 07:42:00	0
5/7/2009 07:42:01	5/7/2009 07:43:00	3
5/7/2009 07:43:01	5/7/2009 07:44:00	3

Ent�o vamos l�:

1 - Crie a estrutura da tabela onde ser�o inseridos os movimentos ocorridos no estoque.

create table TB_MOVIMENTO
(
  ID_MOVIMENTO    NUMBER primary key,
  DT_MOVIMENTO    DATE,
  QTD_MOVIMENTADA NUMBER(4),
  COD_ITEM        VARCHAR2(6)
);

2 - Iremos incluir algumas movimenta��es de estoque, algo em torno de 10 mil registros, que ser�o gerados aleatoriamente. Para isso utilizarei a package dbms_random, proveniente da pr�pria instala��o do banco de dados.

declare
v_dt  dbms_sql.date_Table;    --Cria vetor do tipo data
v_qtd dbms_sql.Number_Table;  --Cria vetor do tipo num�rico
begin

      --Popular as datas geradas aleatoriamente
      dbms_random.seed(to_date('05/07/2009 23:59:59','dd/mm/rrrr HH24:MI:SS'));

      --Gera os registro de data de movimento em um dia.
      for dd in 1..10000 loop   

 v_dt(dd) := ((to_date('05/07/2009 23:59:59','dd/mm/rrrr hh24:mi:ss')+dbms_random.value)-1);                 

      end loop;   

      --Termina o processo
      dbms_random.terminate;

      --Popular as datas geradas aleatoriamente
      dbms_random.seed(99999);

      --Gera os registros de quantidade movimentada
      for dd in 1..10000 loop      
          v_qtd(dd) := dbms_random.value(1,100);                 
      end loop;       


      for dd in 1..v_dt.count loop

         --Insere as movimenta��es
         insert into tb_movimento
           (id_movimento, dt_movimento, qtd_movimentada, cod_item)
         values
           (dd, v_dt(dd), v_qtd(dd), 'CDROM');

      end loop;  

   commit;
end;

3 - Devemos criar a package que ir� conter a fun��o de pipelined, vamos cham�-la de pck_pipelined. Como uma fun��o de pipelined retorna sempre uma cole��o de dados, precisamos criar a estrutura de retorno, que pode ser um Record Type ou um Array. Utilizarei um Record Type. Vamos cham�-las de typ_periodo. Depois de criado, vamos criar uma tabela deste nosso novo Record.

Na declara��o da assinatura da fun��o de pipelined, devemos emitir o comando pipelined logo ap�s a determina��o do tipo de retorno, este comando � respons�vel por identificar a fun��o como pipelined. Para retorno dos dados, vamos declarar a vari�vel v_record do tipo do� typ_periodo, declarado no spec da package.

Tamb�m e poss�vel validar as informa��es da mesma forma que em uma procedure. Neste exemplo o par�metro p_dt_ini n�o poder� ser maior que p_dt_fim e o par�metro p_segundo n�o poder� ser menor que 60, caso seja, ser� emitido um erro na tela para o usu�rio. Dentro do comando while, emitimos o comando pipe row, este � utilizado para retornar a vari�vel com o conte�do que formar� o registro.

Como toda fun��o, ela precisa ter um return, que este � emitido no final da fun��o.

--Spec da package
create or replace package pck_pipelined
is

type typ_periodo is record (de date,
                            ate date,
                            qtd_movimento number);

type typ_tb_periodo is table of typ_periodo;      

function fnc_periodo(p_dt_ini  in date,
                     p_dt_fim  in date,
                     p_segundo in number,
                     p_item    in varchar2)
return typ_tb_periodo pipelined;                     

end pck_pipelined;

/

--Body da package
create or replace package body pck_pipelined
is
function fnc_periodo(p_dt_ini in date,
                     p_dt_fim in date,
                     p_segundo in number,
                     p_item    in varchar2)
return typ_tb_periodo pipelined
is
--Vari�vel do tipo typ_periodo, declarado no spec da package anteriormente
v_record          typ_periodo;
v_dt_base_ini     date;
v_dt_base_fim 	   date;
v_qtd_movimento   number;

begin

--Se a data inicial for maior que a data final, interrompe o processamento
if(p_dt_ini > p_dt_fim)then
 raise_application_error(-20001,'A data inicial n�o pode ser maior que a data final!');
end if;

--Se o per�odo for menor que 60 segundos interrompe o processamento
if(p_segundo < 60)then
 raise_application_error(-20002,'Os segundos n�o podem ser menores que 60');
end if;

v_dt_base_ini  := to_date(p_dt_ini,'dd/mm/rrrr hh24:mi:ss') + (1/24/60/60);
v_dt_base_fim  := to_date(p_dt_ini,'dd/mm/rrrr hh24:mi:ss') + ((1/24/60/60) * p_segundo);


  while trunc(v_dt_base_fim) < trunc(p_dt_fim+1) loop

              select nvl(sum(qtd_movimentada),0)
                into v_qtd_movimento
                from tb_movimento
               where dt_movimento between v_dt_base_ini and v_dt_base_fim
                 and cod_item = p_item;

               --Alimenta a vari�vel do tipo record
               v_record.qtd_movimento := v_qtd_movimento;
               v_record.de  := v_dt_base_ini;
               v_record.ate := v_dt_base_fim;

               --Retorna a vari�vel
        pipe row (v_record);

               v_dt_base_ini  := v_dt_base_fim + (1/24/60/60);
               v_dt_base_fim  := v_dt_base_fim + ((1/24/60/60) * p_segundo);


   end loop;    

   v_dt_base_fim  := v_dt_base_ini + ((1/24/60/60) * (p_segundo-2));

              select nvl(sum(qtd_movimentada),0)
                into v_qtd_movimento
                from tb_movimento
               where dt_movimento between v_dt_base_ini and v_dt_base_fim
                 and cod_item = p_item;


       --Alimenta a vari�vel do tipo record
               v_record.qtd_movimento := v_qtd_movimento;
               v_record.de  := v_dt_base_ini;
               v_record.ate := v_dt_base_fim;

        --Retorna a vari�vel
               pipe row (v_record);

  --Finaliza a fun��o emitindo o comando de retorno, comum em toda fun��o
  return;

end fnc_periodo;


end pck_pipelined;

4 - Vamos executar esta fun��o.

Uma fun��o de pipelined n�o pode ser executada como uma fun��o comum. Para execut�-la devemos fazer um select em sua estrutura, e transformar a fun��o em uma tabela virtual utilizando o comando table:

SQL> select *
    from (table(pck_pipelined.fnc_periodo(to_date('05/07/2009'),
                                          to_date('05/07/2009'),
                                          60,
                                          'CDROM')))
   ;

Logo o resultado ser�:

De - At�	Quant. Movimento
5/7/2009 00:00:01 - 5/7/2009 00:01:00	304
5/7/2009 00:01:01 - 5/7/2009 00:02:00	282
5/7/2009 00:02:01 - 5/7/2009 00:03:00	198
5/7/2009 00:03:01 - 5/7/2009 00:04:00	44
5/7/2009 00:04:01 - 5/7/2009 00:05:00	312
5/7/2009 00:05:01 - 5/7/2009 00:06:00	563
5/7/2009 00:06:01 - 5/7/2009 00:07:00	170
5/7/2009 00:07:01 - 5/7/2009 00:08:00	363
5/7/2009 00:08:01 - 5/7/2009 00:09:00	463
5/7/2009 00:09:01 - 5/7/2009 00:10:00	347
5/7/2009 00:10:01 - 5/7/2009 00:11:00	215
5/7/2009 00:11:01 - 5/7/2009 00:12:00	304
5/7/2009 00:12:01 - 5/7/2009 00:13:00	30

Conforme o layout esperado.

Tamb�m podemos relacionar a fun��o de pipelined com outras tabelas em um select.

No oracle 9i, n�o � suportada a sele��o de todas as tuplas utilizando o identificador select *, devendo ser declaradas as colunas manualmente, da seguinte forma:

SQL> select de, ate, qtd_movimento
  2   from (table(pck_pipelined.fnc_periodo(to_date('05/07/2009','dd/mm/rrrr'),
  3                                         to_date('05/07/2009','dd/mm/rrrr'),
  4                                         60,
  5                                         'CDROM')))
  6  ;

5 - Vamos simular o erro previsto em nossa fun��o.
Passaremos a data final maior que a data inicial para induzir o erro:

SQL> select de, ate, qtd_movimento
  2   from (table(pck_pipelined.fnc_periodo(to_date('05/07/2009','dd/mm/rrrr'),
  3                                         to_date('01/07/2009','dd/mm/rrrr'),
  4                                         60,
  5                                         'CDROM')))
  6  ;

select de, ate, qtd_movimento
 from (table(pck_pipelined.fnc_periodo(to_date('05/07/2009','dd/mm/rrrr'),
                                       to_date('01/07/2009','dd/mm/rrrr'),
                                       60,
                                       'CDROM')))

ORA-20001: A data inicial n�o pode ser maior que a data final!
ORA-06512: em "PROJETO.PCK_PIPELINED", line 17

6 - Tamb�m podemos ordernar a listagem:

SQL>     select de, ate, qtd_movimento
  2       from (table(pck_pipelined.fnc_periodo(to_date('05/07/2009','dd/mm/rrrr'),
  3                                             to_date('05/07/2009','dd/mm/rrrr'),
  4                                             60,
  5                                             'CDROM')))
  6    order by qtd_movimento desc
  7 ;

Como em toda fun��o que � utilizada em selects, a fun��o de pipelined tamb�m n�o permite utiliza��o de comandos DML. Com a utiliza��o das fun��es de pipelined podemos reduzir muito o tempo de desenvolvimento.

No pr�ximo artigo abordarei sobre a velocidade de processamento na utiliza��o de uma fun��o de pipelined. At� l�!

Desfragmentar faz bem

pichiliani@gmail.com (Mauro Pichiliani) — Mon, 20 Jul 2009 09:00:00 +0100

Ol�, pessoal. No artigo desta semana abordarei um assunto muito importante para quem trabalha com bancos de dados considerados grandes: a reindexa��o. Apresentarei quais s�o as caracter�sticas de bancos de dados que levam � reindexa��o, como detect�-la, o planejamento da sua execu��o e a medi��o dos resultados.

Em geral, a an�lise da fragmenta��o de �ndices � uma das etapas mais importantes. N�o me esque�o de verificar isso durante a an�lise inicial de um banco de dados, quando trabalho em alguma consultoria relacionada a problemas de desempenho. Em outras palavras, isso quer dizer que, infelizmente, encontro com mais freq��ncia do que gostaria diversos problemas relacionados � falta de desfragmenta��o dos �ndices das tabelas do banco de dados.

Muitos bancos de dados possuem um crescimento consider�vel ao longo do tempo devido a v�rios fatores, como o tipo de sistema utilizado, o volume de dados, as opera��es da empresa, integra��es gerais, falta de manuten��o e outros. Conforme o banco de dados vai sendo utilizado, a tend�ncia � que ele fique cada vez mais cheio se n�o houver uma preocupa��o em "esvazi�-lo", ou seja, uma manuten��o peri�dica.

Um dos efeitos colaterais da utiliza��o operacional dos bancos de dados para sistemas de ERP, CRM, Ponto de Venda e outros � a modifica��o da caracter�stica de ordena��o dos �ndices. Sim, conforme os dados v�o sendo inseridos, alterados ou exclu�dos das tabelas, h� tamb�m uma modifica��o nas p�ginas de �ndices, independente do tipo de �ndice utilizado. A grosso modo, � poss�vel imaginar que logo ap�s a cria��o de um �ndice (com fill factor=100%) todas as suas p�ginas est�o corretamente ordenadas e conectadas, como mostra o exemplo da Figura 1.

Figura 1. P�ginas de �ndices rec�m criadas

Na Figura 1 os ret�ngulos em azul representam as p�ginas do �ndice, independente do tipo. As setas pretas mostram como estas p�ginas est�o conectadas de forma ordenada e a seta vermelha indica o sentido que o SQL Server ir� utilizar quando for procurar dados neste �ndice. � claro que esta representa��o de p�ginas de �ndices � uma abstra��o, pois internamente o SQL Server utiliza �rvores bin�rias e outros recursos para percorrer as p�ginas de �ndices. Por�m para a explica��o de fragmenta��o este exemplo � �til.

Como dito anteriormente, conforme h� modifica��o, inser��o e dele��o de dados nas tabelas, o �ndice come�a a ser fragmentando logicamente, ou seja, a p�ginas de dados deste �ndice n�o mais v�o ser conectadas em seq��ncia, como mostrado na Figura 1.

Aqui vamos abrir um pequeno par�ntese. Existem diversas formas de fragmenta��o e provavelmente cada pessoa pensa algo diferente quando escuta essa palavra. Talvez o primeiro conceito que venha � mente de muitos quando escutam a palavra fragmenta��o � a fragmenta��o f�sica do disco r�gido (HD). Apesar desta fragmenta��o f�sica ser importante para a localiza��o de dados no disco r�gido, este assunto n�o ser� tratado neste artigo. Entretanto, recomenda-se utilizar alguma ferramenta especializada para desfragmentar o disco r�gido do servidor de acordo com a recomenda��o do pr�prio sistema operacional, desde que o banco de dados esteja devidamente parado e que esta desfragmenta��o seja realizada em um hor�rio de manuten��o e sob supervis�o.

Voltado para a desfragmenta��o l�gica de p�ginas de �ndice no SQL Server, ap�s a utiliza��o operacional durante um per�odo de tempo � comum que a estrutura de p�ginas de �ndice de uma tabela do SQL Server fique parecida com o desenho apresentado na figura 2.

Figura 2. P�ginas de �ndices ap�s uso natural da tabela

A figura 2 mostra que algumas p�ginas de �ndice n�o est�o mais completas, devido a page splits, e outras p�ginas foram removidas, devido � modifica��o dos dados. � poss�vel perceber tamb�m que as p�ginas n�o est�o mais conectas em sequ�ncia como na figura 1. Sem entrar em detalhes, a desfragmenta��o deste �ndice pode ser �til nesta situa��o, pois ela far� com que as p�ginas sejam reconstru�das alocando os dados novamente. Al�m disso, a desfragmenta��o criar� uma nova ordem de conex�o entre as p�ginas.

O cen�rio acima provavelmente ocorre em bancos de dados grandes, com tamanhos acima de 50 GB. Obviamente que esta � uma afirma��o gen�rica e cada banco de dados precisa ser analisado para indicar ou n�o a presen�a de fragmenta��o. Contudo, nos bancos de dados grandes geralmente encontramos o seguinte cen�rio: um pequeno conjunto de tabelas, entre 3 e 10, � respons�vel pela maior parte do banco de dados enquanto as demais tabelas ocupam pouco espa�o. � a famosa regra que diz que 20% do total s�o respons�vel por 80% do resto, por�m aplicada ao tamanho de algumas tabelas e ao banco de dados. Resultado: o pequeno conjunto de tabelas cont�m as prov�veis tabelas candidatas para a reindexa��o.

Isso me lembra um pouco da �poca dos sistemas desenvolvidos em Clipper, ou tecnologia similar, com bancos de dados no padr�o xBase. Apesar da nostalgia, lembro que naquela �poca a reindexa��o era uma necessidade operacional e que, infelizmente, era uma desculpa muito utilizada para justificar erros no sistema ou comportamentos bizarros. Felizmente as tecnologias de bancos de dados atuais evolu�ram ao ponto onde a reindexa��o n�o mais pode ser utilizada como desculpa para certas situa��es ou inconsist�ncias no sistema.

Antes de partir para a reindexa��o � preciso verificar se ela � realmente necess�ria. Aqui recomendo analisar primeiro o grupo de tabelas com um tamanho grande de dados antes de partir para a estrat�gia de reindexa��o. Para aqueles que n�o sabem como obter informa��es sobre o tamanho da tabela, recomendo a utiliza��o da system stored procedure sp_spaceused e tamb�m uma lida na documenta��o da tabela de sistema chamada sysindexes, pois assim � poss�vel identificar rapidamente quais s�o as tabelas que ocupam muito espa�o e que provavelmente possuem problemas de fragmenta��o l�gica.

Ap�s descobrir quais s�o as tabelas que ocupam muito espa�o em disco � preciso verificar a fragmenta��o dos seus �ndices. Recomendo utilizar o comando DBCC SHOWCONTIG para cada �ndice de cada tabela de modo a verificar a fragmenta��o l�gica. Esse comando � t�o importante que � comum encontrar nas provas oficiais de certifica��o da Microsoft algumas quest�es que cobrem o conhecimento do seu resultado. Sem entrar em detalhes espec�ficos, a Figura 3 apresenta o resultado da execu��o do comando DBCC SHOWCONTIG reportando a an�lise do �nico �ndice da tabela chamada Tabela1.

Figura 3. Relat�rio apresentado pelo comando DBCC SHOWCONTIG

O valor destacado pelo ret�ngulo vermelho da Figura 1 indica o qu�o fragmentado este �ndice est�. Quando mais pr�ximo de 0%, mais fragmentado ele estar�, ou seja, valores menores indicam que a desfragmenta��o pode ser ben�fica. Notem que a execu��o do comando DBCC SHOWCONTIG pode demorar de acordo com o tamanho da tabela e que devemos procurar utilizar este comando durante uma janela de manuten��o do banco de dados, assim como a desfragmenta��o. Obviamente que existem diversos outros valores a serem analisados, por�m, sem entrar em maiores detalhes, basta uma r�pida olhada no resultado do comando DBCC SHOWCONTIG e j� obtemos ind�cios sobre o a fragmenta��o do �ndice.

Aqui cabe indicar que os benef�cios de fragmenta��o s�o v�rios: desde a redu��o do espa�o ocupado pela tabela at� a melhora no desempenho das instru��es que utilizam o �ndice da tabela em quest�o. A raz�o destes benef�cios � simples: quando menos p�ginas s�o necess�rias para manipular os dados das tabelas, a tend�ncia � que a execu��o das instru��es seja mais r�pida.

Existem v�rias maneiras de se desfragmentar um �ndice. Por�m, antes de faz�-lo, � preciso tomar algumas cuidados. Em primeiro lugar deve-se sempre contar com um backup antes de realizar esta manuten��o, que deve ser feita durante uma janela de manuten��o devido aos impactos negativos no desempenho do banco de dados causados pelo processo de desfragmenta��o. Em segundo lugar � preciso monitorar e adequar o tamanho do Transacion Log, pois a desfragmenta��o de �ndices que ocupam muito espa�o requer uma grande movimenta��o de dados que, sem sombra de d�vida, utiliza muito o Transacion Log. Em terceiro lugar, mas n�o menos importante, � preciso desfragmentar um �ndice por vez e medir o tempo e o espa�o antes e depois da desfragmenta��o para comprovar se houve algum ganho ou n�o.

Seguidas estas recomenda��es podemos prosseguir no processo de desfragmenta��o. Como geralmente alguns �ndices s�o associados � chaves prim�rias ou estrangeiras, recomendo a utiliza��o do comando DBCC INDEXDEFRAG, pois assim pode-se desfragmentar o �ndice sem afetar os objetos associados a ele. Por�m esta � uma recomenda��o gen�rica que deve ser avaliada de acordo com as caracter�sticas de cada ambiente.

Por fim vale a pena identificar os ganhos ou perdas obtidos com a desfragmenta��o. Como � de praxe, recomenda-se montar um gr�fico ou algum tipo de visualiza��o de dados que auxilie a comprova��o e evidencie os resultados. Por exemplo: o gr�fico da Figura 4 mostra o ganho que obtive no tamanho de uma base de dados real ap�s a desfragmenta��o de alguns �ndices.

Figura 4. Gr�fico mostrando o espa�o ocupado pela Base 1 antes e depois da desfragmenta��o.

No gr�fico da figura 4 pode-se notar que o banco de dados ocupava aproximadamente 33,1 GB apenas com dados e �ndices antes da desfragmenta��o. Ap�s a an�lise das tabelas e da desfragmenta��o dos �ndices de 4 tabelas o tamanho do banco de dados foi reduzido para aproximadamente 29,3 GB, o que d� um ganho de aproximadamente 3,7 GB ou aproximadamente 11,2% de redu��o em rela��o ao tamanho inicial. Este resultado de tamanho em disco p�de ser medido imediatamente ap�s a desfragmenta��o, por�m outros efeitos ben�ficos foram constatados devido � redu��o da quantidade de p�ginas de �ndices.

Em resumo, vale a pena analisar o banco de dados em busca das tabelas que ocupam mais espa�o e procurar montar uma estrat�gia para organizar uma reindexa��o nos �ndices, preferencialmente de forma autom�tica e peri�dica. Quem sabe esta pode ser a pedra no sapato que tanto acaba influenciando no problema de desempenho que ningu�m sabe exatamente onde �.

Um grande abra�o e at� a pr�xima, pessoal.

Que tipo de DBA � voc�?

dbarodrigo@gmail.com (Rodrigo Almeida) — Tue, 14 Jul 2009 10:00:00 +0100

A carreira do profissional de banco de dados (DBA) � cercada de especializa��es, pelo motivo de trabalhar com diversas �reas do TI, como desenvolvimento, projetos, infra-estrutura e etc. � natural que o DBA, com o passar dos anos, tenha prefer�ncias ou "seja for�ado" a trabalhar com �reas espec�ficas, criando assim um perfil do administrador de banco de dados. Veja os diversos tipos de DBAs abaixo:

DBA Desenvolvedor

� o profissional que desde administrar o banco de dados tamb�m desenvolve a aplica��o, tem no perfil as seguintes caracter�sticas:

Profundos conhecimentos na linguagem de programa��o local;
Conhecimentos em instala��o e administra��o do banco de dados;
Sempre preocupado com a qualidade e manuten��o das querys;
Procura sempre o mais perform�tico, mesmo que a atividade n�o seja uma boa pr�tica;
Fortes conhecimentos em modelagem de dados, sabe aplicar a 3FN (brincadeira);
Trabalha sobre prazos e acostumado a "martelar" o banco de dados ou aplica��o para que seja entregue na data prevista.

Geralmente, o DBA desenvolvedor � lider de desenvolvimento ou atua como um guro na equipe, mandando orienta��es aos novos integrantes, organizando as atividades e analisando todos os requisitos de desenvolvimento.

DBA Infra-Estrutura

� o profissional que conhece toda a infra-estrutura necess�ria para a implementa��o do banco de dados, atua desde a concep��o do hardware at� a analise da infra-estrutura local do banco de dados, tem as seguintes caracter�sticas:

Profundos conhecimentos da arquitetura e administra��o Oracle;
Profundos conhecimentos em infra-estrutura, desde a configura��o do hardware, cabeamento, switch, sistema operacional e backup & recover;
Especialidade em performance ao n�vel de sistema operacional e inst�ncia Oracle;
Extremamente cuidadoso no momento de aplica��o de patches no banco de dados e sistema operacional;
Trabalha mais voltado a projetos e implementa��o de novos recursos de banco de dados ou aplica��o;
Respons�vel em adotar as boas pr�ticas para administra��o do banco de dados, mesmo que isso crie conflitos internamente na equipe.

O DBA Infra-Estrutura geralmente n�o d� tanta import�ncia para as aplica��es da empresa, costuma se preocupar apenas com o banco de dados e afeta diretamente a vida o SYSADMIN, pois tudo que o SYSADMIN fizer que tenha banco de dados no meio, ele ir� questionar.

DBA Projetos

� o perfil do profissional que j� foi um DBA Desenvolvedor e Infra-Estrutura, sabe como funciona cada �rea � aplica as boas pr�ticas na constru��o da aplica��o e na infra-estrutura para o banco de dados, suas principais caracter�sticas s�o:

Bons conhecimentos em desenvolvimento de aplica��es;
Bons conhecimentos sobre o produto e arquitetura Oracle;
Gerencia os prazos das atividades, aquisi��o de produtos extras, manuten��o na aplica��o, patches de banco de dados e requisitos b�sicos da infra-estrutura;
Costuma usar o Microsoft Project para se organizar e documenta todas as suas atividades;
Acostumado a opinar/sugerir/questionar o comportamento
Acostumado a delegar as atividades b�sicas de administra��o do banco de dados e cuidar apenas dos projetos que envolvem o banco de dados e a burocracia da empresa.

O DBA Projetos � conhecido com o "cara" do projeto da empresa, pois � ele que em diversas reuni�es com dezenas de �reas costuma a questionar e interrogar os participantes para coletar as informa��es no momento de criar o projeto do banco de dados.

Com sua experi�ncia, ele consegue detectar muitos problemas e possui pr�-atividade em suas atividades.

Agora, para descontrair um pouco, vamos falar sobre as outras vertentes da carreira de um DBA, aquelas vertentes que s�o comentadas pela "r�dio Pe�o" da empresa, como:

DBA Cafeteira

� o profissional que passa mais tempo tomando caf� e fumando que trabalhando efetivamente. Por�m, resolve os problemas da empresa rapidamente.

DBA Google

Esse � o profissional criado dentro do SIBEL ou qualquer outra ferramenta de gerenciamento de mudan�as, conhecido pelas filas de CHAMADOS! Passa a maior parte de sua vida atendendo chamados para produ��o ou desenvolvimento, tendo que aprender todos os tipos de coisas poss�veis que existem no mundo Oracle, por isso que falam que um DBA Google sem internet n�o trabalha!

Mas � muito bom para quem quer aprender banco de dados, aprende e tem no��o de tudo!

DBA Bombeiro

Essa vertente � a p�s-gradua��o do DBA Google, pois em algum momento da vida o DBA Google fica revoltado com a vida que tem e quer mudar de empresa, e a empresa em que ele ser� empregado � um consultoria com N clientes e ele dever� atender todos.

Deste modo, acaba surgindo o DBA Bombeiro, pois ele vai para os clientes apenas para apagar inc�ndios a todo momento, n�o consegue prosseguir em uma especializa��o. E para ajudar, � o perfil de DBA que costuma a receber um celular ou Page para ficar 24x7 para a empresa.

Tamb�m muito conhecido pelas suas olheiras, que v�m com o tempo!

DBA Ghost

Esse � o perfil de um profissional que escutou de algu�m que DBA ganha bem, que sendo DBA ele ir� prosperar em sua vida financeira e ter� tudo que o mundo pode vender para ele, assim sendo, algu�m muito conhecido consegue arrumar uma vaga na �rea de banco de dados e quando ele realmente consegue entrar, possui as caracter�sticas abaixo:

N�o sabe administrar o banco de dados;
Quando h� problemas, ele desaparece;
N�o atende o celular ap�s as 18 horas nunca;
Mata dezenas de parentes no ano para justificar suas faltas;
N�o gosta de estudar, ler livros, buscar conhecimentos e muito mesmo debater assuntos referentes a Oracle;
E o melhor, s� aparece para receber o sal�rio.

Acho que � isso, pessoal, deu para entender um pouco como funciona a carreira de um profissional de banco de dados Oracle, muitos �rea de especializa��es ou at� mesmo uma generaliza��o de tudo, com muita modera��o, n�o diga que sabe trabalhar com RAC, sendo que nunca viu como funciona RAC em sua frente.

Certifica��o � importante e recomendo a todos, por�m o Certificado Oracle, seja ele um OCA ou OCP, n�o vai dar garantias que seja o melhor profissional de todos os tempos, pois certifica��o n�o � garantia de qualidade no servi�o.

Abra�os.

Check-List para auditoria SOX em Oracle

dbarodrigo@gmail.com (Rodrigo Almeida) — Wed, 01 Jul 2009 10:30:00 +0100

Ol�!

Recentemente estive sobre os olhares da auditoria Sarbanes-Oxley (SOX) para os bancos de dados Oracle da empresa que trabalho e gostaria de compartilhar alguns check-lists necess�rios para os DBAs passarem sem muitos problemas dessa auditoria.

Sobre a Lei Sarbanes-Oxley (SOX)

A auditoria SOX, foi criada em 2002 pelo senador Paul Sarbanes e deputado Michael Oxley, nos EUA, tendo como objetivo controlar e investigar todos os investimentos estrangeiros de empresas que possuem capital aberto no mercado, afim de evitar grandes fraudes e governan�a inapropriada.

Como muitas empresas que possuem opera��es financeiras no exterior, a SOX promove a cria��o de processos de auditoria e seguran�a em todos os departamentos da empresa, a fim de torn�-la uma empresa confi�vel, transparente e principalmente segura.

Deste modo, a aten��o ao departamento de Tecnologia da Informa��o � uma parte muito importante durante uma auditoria SOX, pois os sistemas da empresa devem ser seguros e seguir diversos processos internos elaborados pelas suas gest�es para prevenir fraudes.

O banco de dados acaba sendo um alvo certo no processo de auditoria, porque simplesmente, armazena todos os dados vitais de uma empresa, e essa "caixa" de dados precisa ser segura e de acesso controlado, tornando uma dor de cabe�a aos DBAs e projetos da empresa, porque muitas restri��es s�o impostas.

Voc�s poder�o ver essas restri��es impostas no check-list abaixo, onde s�o pontos que os auditores pedem evid�ncias sobre o processo e/ou atividade realizada. Todo o check-list foi realizado para ambientes de bancos de dados Oracle.

Primeiramente, vamos iniciar o nosso check-list partindo da infra-estrutura, ou seja, o que � necess�rio para o ambiente de banco de dados estar de acordo com o SOX.

Infra-Estrutura

Backup & Recover em dia;
Documenta��o da Estrat�gia de Backup & Recover para cada banco de dados;
Evid�ncias de testes de recover vindas de Fita e/ou disco, o verdadeiro LOG da opera��o;
Padr�o de instala��o seguindo o OFA (Optimal Flexible Architecture);

Para bancos de dados em ambientes Windows:

Lista de usu�rios Locais do servidor;

Permiss�es dos usu�rios e pastas Oracle;

DUMPSEC dos servidores;

Relacionamento de confian�a entre os servidores;

Lista de servi�os do windows, para saber qual � necess�rio ou n�o;

Lista de protocolos utilizados pelo servidor;

Permiss�o dos arquivos listener.ora, sqlnet.ora e Execut�veis;

Permiss�o do Oratab;

Arquivo de Par�metro, quais e qual o motivo dos par�metros;

Informa��o sobre os processos do Windows Scheduler;

Informa��es sobre os processos Batch, n�o � permitido fixar a senha de usu�rios em hardcode;

Informa��es sobre as �ltimas atualiza��es do Windows, principalmente de Vulnerabilidade.

Para bancos de dados em ambientes Linux/Unix:

Utilizar o umask 022 no profile Oracle;

Fornecer os detalhes do profile default dos usu�rios e csh.login do sistema operacional;

Lista de servi�os que est�o executando, e desativar os desnecess�rios.

Lista dos usu�rios do DBA Group;

Permiss�o dos arquivos, diret�rios e FileSystem do Oracle User;

Permiss�o do OraTab;

Permiss�o de shell scripts, n�o � permitido fixar a senha de usu�rios em hardcode;

Permiss�o nos arquivos Listener.ora, sqlnet.ora e Execut�veis/Libs;

Arquivo de Par�metro, quais e qual o motivo dos par�metros;

Informa��es sobre os processos da Crontab e suas permiss�es.

Informa��es de permiss�o sobre os arquivos de dados, traces e log;

Agora, vamos para um check-list mais refinado, internamente no banco de dados, o que o DBA dever� prestar aten��o na auditoria, veja abaixo:

Banco de dados

Lista de usu�rios Gen�ricos, ou seja, Lista dos owners da aplica��o;
Lista de usu�rios Convencionais, os usu�rios finais;
Lista de Profiles e seus par�metros;
A fun��o VERIFY_PASS_FUNCTION deve ser programada para de acordo com a pol�tica de senha da empresa;
Permiss�es de visualiza��o no dicion�rio de dados Oracle, principalmente as views dba_source e dba_objects;
Lista de permiss�o dos Usu�rios por objeto, role e grants de sistema;
Lista de permiss�o dos usu�riso com WITH OPTION para concess�o de permiss�o;
Documenta��o do processo de Backup sobre os componentes l�gicos, como tabelas, procedures, packages, functions e triggers;
Documenta��o do processo de agendamento de Jobs ou a utiiza��o do DBMS_SCHEDULER, Quem usa, Como usa e quem utiliza;
O DBA n�o pode utilizar as contas SYS e SYSTEM, deve possuir uma conta pr�pria e nomeada para cada profissional;
Senha no Listener;
N�o utilizar autentica��o via SO para logar-se como SYS AS SYSDBA;
Utilizar arquivo de senha no banco de dados;
Utilizar o par�metro DBLINK_ENCRYPT_LOGIN = TRUE no banco de dados quando se trabalha com vers�es anteriores ao 9.2.0.1;
Recomenda��o de habilitar o AUDIT_TRAIL = DB ou SO, mas � apenas recomenda��o, depende de analise de ambiente;
Habilitar o par�metro AUDIT_SYS_OPERATIONS = TRUE para auditoria no usu�rio SYS;
Ocultar as autentica��es no banco de dados pelo sistema operacional, usando o par�metro OS_AUTHENT_PREFIX = ";
Ter habilitado o par�metro REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE para administra��o remota.

Dependendo da empresa que ir� auditar, alguns itens podem ser inclu�dos e outros nem solicitados, por�m, nunca se sabe o que eles v�o pedir, por isso, fica a recomenda��o e as devidas aten��es de seguran�a.

Outro detalhe importante sobre uma auditoria SOX, que os auditores pedem todos os documentos de processo e/ou atividade do banco de dados, portanto, mais e mais documentos s�o necess�rio para os nossos ambientes, como:

Documenta��o de Instala��o do banco de dados;
Documenta��o do controle de incidentes de banco de dados;
Documenta��o do controle de altera��o do banco de dados feitas atr�ves de aplica��o, ou seja, quando � necess�rio incluir, deletar ou modificar algum objeto da base;
Documenta��o dos servi�os que est�o sendo monitorados no banco de dados;
Documenta��o de procedimentos de manuten��o no banco de dados e etc;

Para a equipe de DBAs pode ser um imenso problema isso, porque documentar todo esses processos leva muito tempo e dificilmente um espec�fico profissional sabe tudo sobre um determinado ambiente. Por um lado, a documenta��o � extremamente importante para equipes com muitos DBAs, ou empresa que possuem alta rotatividade desses profissionais, pois o ambiente fica muito mais controlado, seguro e f�cil de se administrar. Eu sou totalmente favor�vel a qualquer tipo de documenta��o, tanto banco e aplica��o.

Uma recomenda��o importante quando for passar por auditoria SOX, s�o elas:

O DBA deve ter um backup, ou seja, outro profissional que fa�a as mesmas tarefas quando ele ficar doente ou sair da empresa;
Tenha ambientes separados para a aplica��o, exemplo: Ambiente de DESENVOLVIMENTO, HOMOLOGA��O e PRODU��O;
Tenha uma gest�o de incidentes ou projeto que controle todas as transa��es sobre os ambientes mencionados acima;
Todo o c�digo PL/SQL que passe a terceiros ou outras filiais deve usar o aplicativo WRAP para criptografia dos dados e posteriormente comparar os checksum;
Tenha �timas estrat�gias de Backup & Recover;
E um acesso restrito para querys em ambiente de produ��o.

BOM! Acho que � isso pessoal, esses s�o alguns ("grandes") check-lists para supotar uma auditoria da SOX, ou at� melhor, para conhecer tamb�m um pouco mais sobre como proteger o seu banco de dados, n�o precisa passar por uma auditoria para poder implementar alguns sugest�es que est�o acima ou at� mesmo, documentar os seus processos. S�o check-lists que � v�lido como um todo!

Para mais informa��es, o meu Blog est� a disposi��o.

Abra�os,

Desperdi�ando espa�o em disco

pichiliani@gmail.com (Mauro Pichiliani) — Thu, 25 Jun 2009 09:00:00 +0100

Ol�, pessoal. Hoje abordarei um assunto muito importante para quem trabalha com banco de dados de grandes tamanhos: o desperd�cio de espa�o em disco devido ao uso incorreto de tipos de dados.

Como consultor de banco de dados, uma das principais atividades com que me deparo durante o trabalho � analisar o modelo de dados dos sistemas que j� est�o em produ��o. Este trabalho requer um conhecimento b�sico do que o sistema faz e auxilia na identifica��o das diversas raz�es e motivos de problemas, principalmente os relacionados ao desempenho do banco de dados e consumo excessivo de recursos.

Nas �ltimas consultorias que prestei, n�o pude deixar de notar a presen�a de uma pr�tica n�o recomendada que, infelizmente, encontro com mais freq��ncia do que gostaria em diversos bancos de dados. Esta pr�tica, que explicarei em seguida, est� diretamente relacionada com a modelagem do banco de dados e com a cultura geral da falta de planejamento e modelagem adequada. Como conseq��ncia, diversos problemas aparecem, inclusive o desperd�cio de espa�o em disco e problemas de desempenho.

Explicarei uma situa��o de desperd�cio evidente a partir da modelagem do banco de dados. Em situa��es normais de temperatura e press�o, ap�s a elabora��o de requisitos e a especifica��o do que o sistema deve fazer, a equipe de desenvolvimento monta um diagrama entidade-relacionamento com as tabelas, colunas, tipos de dados, relacionamentos, etc. O problema come�a aqui: em muitas situa��es n�o se d� a devida aten��o aos tipos de dados de certas colunas. Mais especificamente, acaba-se usando tipos de dados superdimensionados para determinadas colunas, o que ocupa mais espa�o em disco do que o necess�rio. Mesmo com a taxa de custo/megabyte diminuindo a cada dia, isso n�o quer dizer que devemos esbanjar e evitar tomar certos cuidados durante a modelagem dos tipos de dados.

Um dos motivos para este super dimensionamento est� relacionado com a falta de previsibilidade do crescimento e volume de dados que ser�o armazenados. Nem sempre � f�cil identificar qual � o melhor tipo de dados para determinada coluna e, por causa disso, o modelo acaba pecando por excesso. Contudo, este pecado vai custar caro um dia devido ao crescimento.

Vou comentar um exemplo pr�tico. Em uma das consultorias que prestei, me deparei com um banco de dados cujo tamanho ocupava cerca de 50 GB, o que � um tamanho consider�vel de acordo com o hardware, a finalidade da aplica��o e do banco de dados neste contexto. Analisando melhor, me deparei com uma tabela que tinha aproximadamente 38 milh�es de linhas e que ocupava cerca de 30 GB apenas considerando os dados armazenados. Com certeza o tamanho e volume desta tabela estavam associados aos problemas de desempenho do banco de dados, motivo pelo qual fui contratado para dar a consultoria.

Analisando com calma, identifiquei que esta tabela continha mais de 40 colunas. Sem entrar em detalhes, pude verificar que das 40 colunas, 22 eram do tipo dados inteiro (INT). At� aqui sem problemas. Por�m, ao verificar o intervalo m�nimo e m�ximo para cada coluna (com o uso de instru��o SELECT MAX(), MIN() FROM TABELA), determinei que, das 22 colunas, 19 armazenavam apenas valores num�ricos compreendidos entre 0 e 50.000. Outro detalhe interessante � que n�o havia sequer um valor negativo para estas 19 colunas no meio das 38 milh�es de linhas. Este � um cen�rio t�pico onde o tipo de dados INT � utilizado como chave prim�ria junto com uma propriedade de auto-numera��o.

Se lembrarmos que o SQL Server possui o tipo de dados INT que ocupa 4 bytes, o tipo de dados SMALLINT ocupa 2 bytes e o tipo de dados TINYINT que ocupa 1 byte podemos ver claramente que o tipos de dados das 19 colunas foram super dimensionados.

Conversando com analistas, desenvolvedores e usu�rios ele confirmaram que estas colunas n�o armazenam valores grandes. Por exemplo: colunas com o n�mero de ag�ncia banc�ria, o n�mero da pra�a, o c�digo do usu�rio que digitou o documento, a filial da empresa, etc. Com a confirma��o de que todas estas colunas poderiam ter utilizado um tipo de dados que ocupa menos espa�o, isto �, o SMALLINT ou o TINYINT no lugar do INT, parti para calcular o quando se ganharia de espa�o na mudan�a de tipos.

Aqui vou considerar um c�lculo simples de custo de linha. Para informa��es e mais detalhes sobre o custo por linha, recomendo a leitura dos seguintes artigos publicados anteriormente aqui no iMasters: Verificando a aloca��o de dados - Parte 1 e Verificando a aloca��o de dados.

Vamos aos c�lculos:

Das 19 colunas com o tipo de dados INT (4 bytes), verifiquei que 8 delas poderiam ser trocadas pelo tipo TINYINT (1 BYTE) e as 11 poderiam ser trocadas pelo tipo SMALLINT (4 bytes). Notem que o intervalo de valores do TINYINT � de 0 a 255, o intervalo de valores do SMALLINT � de -32.768 a 32.767 e o intervalo de valores do INT � de -2.147.483.648 a 2.147.483.647.
Temos 19 colunas do tipo INT por linha. Como o tipo INT ocupa 4 bytes, a tabela ocupava 19x4 = 76 bytes por linha apenas com estas 19 colunas.
Multiplicando 76 bytes pela quantidade de linhas da tabela, 38 milh�es, temos: 76*38.000.000 = 28.880.000.00 bytes ou aproximadamente 2,7 GB.
Se utilizarmos o tipo de dados TINYINT em 8 colunas teremos: 8x1 = 8 bytes. Devemos somar tamb�m 11 colunas do tipo SMALLINT. Ou seja, teremos (8x1) + (11*2) = 8 + 22 = 30 bytes. Este � o custo da linha para as 19 colunas que ser�o modificadas.
Multiplicando 30 pela quantidade de linhas teremos 30*38.000.000 = 1.140.000.000 bytes ou aproximadamente 1 GB.

Se fiz�ssemos a troca de tipos, estar�amos economizando 1,7 GB, pois 2,7 - 1,0 = 1,7 GB. Notem que esta economia � de 63% do espa�o ocupado pelas colunas num�ricas e de 5,6% do tamanho total da tabela e, por conseq��ncia, do espa�o em disco. Isto apenas para o tamanho ocupado pelos dados, pois ter�amos um ganho adicional de espa�o se considerarmos que muitas destas 19 colunas fazem partes de �ndices. Para o leitor ter id�ia do que isso representa, faremos uma analogia.

Imagine se 5,6 % do espa�o do seu monitor estivesse com um ret�ngulo preto sem uso. Este espa�o estaria reservado para voc�, por�m ele nunca � utilizado porque o fabricante imaginou que um dia algu�m descobriria um jeito de utilizar este espa�o, coisa que nunca aconteceu na realidade. Se alguns designers j� reclamam de um ou outro dead pixel em um monitor com resolu��o de 1280x800 imaginem a falta que 51.000 pixels n�o faria....

A redu��o de espa�o proporciona outros efeitos colaterais ben�ficos. Al�m da redu��o dos �ndices, o banco de dados ocuparia menos mem�ria para armazenar as p�ginas de dados e �ndices desta tabela. Os joins ficariam mais r�pidos de serem executados devido ao tamanho reduzido das chaves prim�rias, o backup e a replica��o seriam executados mais r�pido, o processador gastaria menos ciclos de CPU para executar a instru��o, etc. Contudo, mensurar estes tipos de ganhos � mais complexo do que simplesmente indicar o ganho de espa�o em disco e, em muitas situa��es, a troca de tipos de dados pode se tornar muito complexa, especialmente com tipos que n�o armazenam n�meros.

Um fator decisivo para a minha escolha da mudan�a de tipos nesta consultoria foi facilidade de implementa��o: em termos pr�ticos n�o houve muitas dificuldades t�cnicas para trocar um tipo de dados INT para SMALLINT ou TINYINT. Em primeiro lugar, a convers�o dos programas, stored procedures e outros objetos program�veis � autom�tica, pois um valor SMALLINT ou TINYINT p�de ser armazenado em um INT sem problemas. Al�m disso, foi poss�vel utilizar o comando ALTER TABLE para trocar o tipo de dados sem problemas, com exce��o das chaves prim�rias. Em segundo lugar, valores num�ricos, em geral, s�o indexados e manipulados mais r�pido que outros tipos de dados, o que tornou esta manuten��o mais r�pida do que trocar um char(30) por um varchar(30), por exemplo. Em terceiro lugar, esta manuten��o apresentou resultados imediatos, que puderam ser medidos atrav�s de diversas maneiras no SQL Server.

Por�m isso n�o quer dizer que a tarefa vai ser sempre simples: h� sempre a obriga��o de testar o sistema ap�s a troca dos tipos de dados e contar com um backup pronto para ser restaurado em caso de problemas. Al�m disso, as implica��es desta troca de tipos podem afetar funcionalidades j� agendadas para desenvolvimento que contavam com um tipo de dado e, na hora da implementa��o, se depararam com outro tipo de dados.

Agora eu termino este artigo perguntando: voc�, leitor, j� sabe o quanto do seu banco de dados est� sendo "desperdi�ado" devido ao uso incorreto do tipo de dados de dados nas suas tabelas?

Um grande abra�o,