Coqueiro Digital e Seus Cocôs Cibernéticos

Eu estava navegando pelos Grupos do Google procurando algum fórum de discussão legal de Banco de Dados quando encontrei a pérola abaixo. Fiquei extremamente tentado a entrar no grupo que deve ter discussões de grande conteúdo e alto nível técnico. Principalmente se você for um profissional "Oraco" certificado. Na boa, ainda tentei achar uma justificativa para a escrita errada da palavra, tipo, pow, o cara esqueceu um "L"... Mas não deu. Porque mesmo com um "L", a coisa ficava "Oraclo"... Sei lá, vai ver é a versão Português (Brasil) do ORACLE! =P I was searching into the Google Groups some nice forum about DataBases when I had found this "pearl" above. I was extremely tempted to join it, which might have high level technical discussions and content. Even more if you're a "Oraco" Certified Professional. No jokes, I really tried to find some justification on the misspelling of the word, as if... the guy just forgot or...

É, sei que estou bastante em falta com meu blog. O problema foi que tive que praticamente formatar meu notebook e reinstalar tudo (na verdade ainda estou reinstalando). Em casa não sobra muito tempo à noite para postar (novamente reinstalando o Vista e seus 500 patches de atualização e estudando para tirar certificação OCP). Além de ter que dividir o tempo entre os afazeres domésticos! O homem também tem que participar =P Bem, pra não dizer que abandonei completamente meu singelo blog, vou postar sobre a única coisa que tenho visto ultimamente. Oracle Database. Recentemente tivemos uma situação na empresa que foi necessário "desfazer" a alteração do desenvolvedor. Um campo que ele havia passado para LONG, voltar a sua situação original: VARCHAR2 O problema é que não vai ser um simples ALTER TABLE que vai fazer com que tudo volte a Terra do Moranguinho. Por ser um tipo de campo usado para guardar objetos "largos", o banco não aceita que você simplesmente "diminu...

O monitoramento da coleta de estatísticas de um banco é tão importante quanto a coleta em si. Muitos "DBAs" se preocupam apenas em implementar a tarefa de coleta de estatísticas, mas não se preocupam em monitorar se a coleta está sendo feita corretamente. Um problema comum que impede a coleta das estatísticas é o erro ORA-20005: object statistics are locked. Normalmente isso acontece quando há uma interrupção brusca no processo de coleta, deixando a estatística de algum objeto "travada", como uma queda de energia, falha de hardware ou desligamento do servidor por algum outro motivo. Após ocorrer o problema ORA-20005, as estatísticas posteriores não serão mais concluídas, levando a uma queda de performance. Entretanto a solução para o problema não é nada de outro mundo. Normalmente eu utilizo o pacote DBMS_STAT.UNLOCK_SCHEMA_STATS ('nome_do_esquema') para "destravar" o objeto que ficou preso. Caso queira ir direto ao problema, ou seja, o objeto em...

Esse fim de semana tivemos uma queda de energia e o tempo foi maior do que os NoBreakes puderam suportar. Consequencia: nossos servidores foram desligados. Mas o melhor foi que semana passada desligamos a inicialização automática dos bancos para fazer um teste de performance e uso de memória. Ou seja, tive que conectar-me ao servidor no Sábado afim de colocar as principais bases no ar. Normalmente, no LINUX, os scripts de inicialização de banco ficam dentro do diretório /etc/rc.d/init.d . Lá você poderá encontrar arquivos como dbifx ou dbora, que geralmente contém os scripts de inicialização dos bancos que vocÊ deseja que sejam iniciados automáticamente quando o servidor é ligado. Os arquivos e locais podem variar dependendo da versão do Linux (ou S.O.), mas manteremos o escopo dentro desse padrão. Procure por arquivos com nome dbifx ou dbora dentro do diretório /etc/rc.d/init.d . Se não existir crie o seu. Existem várias formas de informar que instâncias você deseja que sejam inici...