quinta-feira, 10 de setembro de 2009

DE DBA PARA DBA

Olá, como vão vocês?

Eu estava pensando esses dias em como é comum encontrarmos profissionais falando sempre , mau ou bem, do seu banco de dados, ou seja do DBA por conseqüência (risos..), mas uma coisa muito interessante me chamou atenção.

Trabalhei com pessoas incríveis nesse trajeto profissional até então, e sempre aprendo muito com todos, mesmo com aqueles cujas metodologias e conhecimento não eram lá tão excepcionais, pode parecer um pouco de “desdém” de minha parte, mas todos nós profissionais de T.I temos que saber separar as coisas e entender muito bem o porque de fulano ser um ótimo técnico e ciclano ser apenas um técnico comum.

Vejam, ao falarmos de Banco de Dados como um todo, pensamos de cara em um ambiente sem falhas, exemplar, com rotinas bem organizadas, estratégias de Backup impecáveis, sysadmins extremamente complacentes e flexíveis a entender as necessidades dos Dba’s, e como supra-sumo de tudo uma equipe de desenvolvedores muito, mais muito integrada com a área de Banco de Dados e de Analise de Sistemas ( Calma não estou delirando , nem estou sendo acometido de um mau súbito.(risos)). Porém na verdade muito disso nunca ocorre, estamos via de regra muito preocupados em questionar, em bater de frente, em impor nossas ideologias e metodologias, é um comportamento natural das pessoas pró-ativas, mas porque não pensar antes de fazer isso em tentar compreender o seu ambiente.

É visível que na maioria das vezes todos nós encontraremos ambientes diferentes em diversos aspectos, principalmente se formos profissionais de consultoria, cada dia em um cliente, cada minuto atendendo um problema de um ambiente altamente desconhecido, até ai tudo normal, nada de extraordinário. Então porque não nos preocupamos em primeiro ver o que ocorre no local de atuação? Não seria mais óbvio? A resposta é SIM, seria.

Hoje em dia contamos com tantos métodos de analise de informações que ficamos até meio sem saber qual é o melhor para nos auxiliar, ora temos bancos em OLTP , ora em DSS, ora é para um DW que estamos olhando, enfim diversos ambientes com suas particularidades.

Eu por diversas vezes no ímpeto de querer mostrar serviço assim que sai do meu curso de Oracle 8i Administração I, achei que mudaria o mundo, principalmente quando chegamos no capitulo que tratava de divisão da utilização dos BLOCOS de banco de dados através das STORAGE CLAUSULES que podemos definir nas tabelas na hora de sua criação, e foi ai onde rolou minha decepção, por curiosidade olhei as tabelas de onde trabalhava na época e vi apenas as seguintes clausulas : NOPARALLEL e NOLOGGING.

Eis que me ocorreu o seguinte : o que fazer então? Bem ai vai um conselho, só mexa nisso se for de sua alçada e se relamente lhe for consultado ok? Peraí que isso, não mesmo, coletem essa informação sim, levem ao conhecimento de sua equipe de desenvolvimento e de gerencia se for o caso, porque enquanto o sistema funcionar numa boa seu pescoço está salvo, mais ao primeiro sinal de contenção, lentidão e travamento é o seu “pescoço” que entrará na reta.

Quantos de vocês já debateram com seus DA’s ou Developers sobre, PCTFREE, PCTUSED, PCTINCREASE, MINTRANS, MAXTRANS, etc , nunca vi ninguém ter esse tipo de papo, ninguém se preocupa com isso, ainda mais depois de tantas técnicas de armazenamentos desenvolvidas nos últimos anos, eu vão desde gerenciamento de tabelas até gerenciamento de discos ( ASM ), isso deixou um pouco de ser uma preocupação para alguns. Mas e quanto aos que ainda usam versões que dependem disso? Versões que ainda contam com o bom e velho RBO. Opa eu disse bom e velho RBO? È pessoal porque não?

Se você possui um banco de dados com uma escrita SQL bem feita, com índices de fragmentação bem controlados, com a volumetria equalizada, objetos bem construídos, sem exageros em índices , sem sujeiras em seu dicionário como tabelas “XXX”, “TEMP”, etc e tal o otimizados a base de REGRA é bem funcional, visto que não se trabalha com coleta de estatísticas em bancos desse nível, portanto devemos manter o mais enxuto, coeso e preciso possível, pois a arma infalível do ANALYZE TABLE ou da DBMS_STATS aqui são mero artifícios de festa a fantasia, sem utilidade alguma, podendo até comprometer a performance do seu ERP se aplicados.

Sem querer ser chato, devemos sempre dar atenção a pequenos detalhes como , arquitetura do nosso Server, distribuição de discos, modo como estão distribuídas as cargas, procurar seguir ao máximo as padronizações sem se preocupar se foi bobagem ou não aquilo que alguém escreveu, se um dia alguém perdeu tempo para se dedicar a escrever aquilo é porque faz sentido , tem lógica e raciocínio, é como por exemplo quem usa ASM , se a pessoa quiser ser meticulosa e chata ela pode muito bem se dar ao trabalho de ler o livro de ASM e descobrir que se ele reservar os cilindros do disco mais ao centro , sua leitura será muito mais rápida do que se ela usar os cilindros que correspondem a parte periférica do disco rígido. Daí podem dizer assim: “VOCÊ TA DE BRINCADEIRA QUE TENHO QUE FICAR SEPARANDO CILINDRO DE HD ?”. E eu digo, olha de brincadeira eu não estou não, mais te garanto que visivelmente você percebera as leituras mais rápidas, principalmente se as principais tabelas do sistema ficarem na tablespace que você criou exatamente naquele espaço mais próximo ao centro do HD, que viagem não é?

Falo com freqüência para alguns amigos meus, não manjo muito, ainda preciso aprender muita coisa, mais se você tiver armas como TKPROF, STATSPACK, AWR, ASH, ADDM nas mãos , você vai longe, todas elas não vão te dizer o que fazer em alguns casos, mais te darão um norte de por onde começar, nas versões mais novas o ADDM tem até uma parte de “recomendations”, mais cada caso é um caso, e aquilo que é bom pra X pode não ser para Y, devemos sempre nos lembrar de que trabalhar com EXATAS não quer dizer que você tenha sempre que pensar que uma reta é constituída de 2 pontos, isso metaforicamente falando, o que eu quero dizer é que você deve levar em consideração toda e qualquer informação , por mais descabida que pareça, pode ser que haja alguma verdade nela e que lhe sirva de alguma maneira.

Bem, falei demais não é? Agora eu gostaria de falar um pouco de BACKUP, é de uma notoriedade impar que RMAN é sem dúvida venerado pelo mundo todo, isso é facilmente comprovado pela quantidade de artigos, sites, papers etc e tal sobre o assunto, o mais importante é definir uma boa estratégia seja ela de que maneira for, e seja lá qual aplicativo vai usar pra isso, BACKUP é algo que deve ser feito sempre e que principalmente ele deve ser passível de RESTAURAÇÃO, porque um backup que não restaura é como uma prova feita a lápis, você não pode reclamar se não der certo.

Bom pessoal, tenho muitas coisas que ainda preciso comentar, mais por agora fico por aqui nesse pequeno “Overview” sobre os meus pontos de vista com relação a algumas coisas.

Espero que apreciem, logo mais darei continuidade a esse assunto e trazendo mais de minhas experiências.

Abraço á todos!!!