PGCasts
20 de Maio de 2011, 0:00 - sem comentários ainda
O Sr. Dickson Guedes resurgiu das cinzas em grande estilo e com um projeto muito bacana. O pgcasts é um screencast, ou seja, áudio e vídeo com uma demonstração de como fazer alguma coisa no PostgreSQL. Ver a tela dele fazendo enquanto vai comentando, é muito mais simples do que ler um artigo enorme num blog como o meu…. assuntos que eu levaria páginas para abordar ele mostra como fazer na prática com 20 a 30 minutos de screencast.
Muito bacana, eu recomendo. Até hoje (02/05/11) são 3 episódios e ele vem mantendo a média de um novo screencast por semana:
- Instalando PostgreSQL 9.0
- Trabalhando com datas no PostgreSQL
- Alterando colunas de tipos conflitantes
Divirtam-se.
PGBR2011
9 de Maio de 2011, 0:00 - sem comentários aindaPara quem não sabe, o PGBR2011 (nome novo para o PGCon Brasil) está à pleno vapor e em sua 4ª edição estamos novamente dando um bom salto de qualidade. Vejamos algumas novidades:
5 Palestrantes internacionais Confirmados
- Álvaro Herrera (Chile)
- Bruce Momjian (EUA)
- Dave Page (Inglaterra)
- Greg Smith (EUA)
- Koichi Suziki (Japão)
Todos eles são desenvolvedores do PostgreSQL e tem grandes contribuições para a comunidade.
O evento será realizado no conforto do Hotel Century Paulista, em São Paulo
Os detalhes do local já estão acertados. A decisão de fazer o evento num hotel deverá ajudar bastante quem vem de longe. Você poderá se hospedar no mesmo local do evento. Assim as pessoas gastam menos com deslocamento e perdem menos tempo. Para quem for se hospedar, confira os preços especiais para quem for participar do evento. Recomendo fazer a sua reserva o quanto antes para evitar surpresas na última hora.
Para quem mora em São Paulo, também será uma grande vantagem, o local fica a apenas algumas quadras da estação Brigadeiro do metrô. Se você preferir vir de carro até o local, há um estacionamento com preço fechado para participantes do evento.
Serão 3 salas simultâneas que juntas comportam 470 pessoas, uma sala de apoio, um salão de exposições e um local para o famoso coffee break à tarde. Estamos esperando um público de 400 pessoas nos 2 dias do evento, que cairão numa 5ª e 6ª feira, diferente das edições anteriores. Notem que na 4ª, haverá um feriado.
Participe
Você pode ajudar:
- Venha ao evento. Sua presença é o mais importante para nós. As inscrições deverão abrir em agosto. Como sempre, quem se inscrever com antecedência, vai poder aproveitar um preço especial.
- Mande uma proposta de palestra. A chamada de trabalhos será aberta em meados de junho ou julho, fique atento.
- Divulgue o evento:
- Se você tem um blog, um site, pode divulgar um banner do evento ou falar sobre ele.
- Se você utiliza o Twitter, fale sobre o evento e utilize a hash tag #PGBR2011.
- Se você participa de alguma lista de discussão por e-mail, informe as pessoas sobre o evento. Não esqueça das boas maneiras e coloque um [off-topic] no assunto.
- Se você estuda numa faculdade, estaremos fazendo alguns cartazes sobre o evento que você poderá afixar no mural.
- Se você trabalha numa empresa de TI ou utiliza muito o PostgreSQL no seu trabalho, considere a possibilidade da sua empresa patrocinar o evento.
- Se você gostaria de dar sugestões ou ajudar na organização do evento, entre na lista da comunidade.
O guro Oracle Thomas Kyte mostra os argumentos para usar o PostgreSQL
17 de Fevereiro de 2011, 0:00 - sem comentários aindaSim, é verdade! Estava lendo uma thread no blog do respeitável Thomas Kyte sobre comparações do Oracle com outros bancos de dados aqui. Claro, o Thomas não cita o PostgreSQL em momento algum, ele cita apenas o Informix, Ingres, Sybase, DB2 e o MS SQL Server.
Bom, vale a pena ler o artigo. Você verá que nos comentários o PostgreSQL começa a aparecer, e com boas avaliações. Mais interessante ainda é que o Thomas ignora ao máximo o PostgreSQL nos comentários. Claro, ele não é estúpido, não seria inteligente nem diplomático da parte dele. O máximo que ele chega a citar é que a Oracle tem o XE, que quem conhece sabe que é algo limitado e certamente foi lançado (a exemplo do que fez a MicroSoft e IBM) para retardar o avanço dos bancos de dados livres.
O post é de 2001 e os comentários perduram até 2010. De qualquer forma, fica claro, que os mesmos argumentos que ele utiliza para mostrar a superioridade do Oracle, serviriam para o PostgreSQL…. vale a pena ler.
Comparison between Oracle and Others
SQL para DBAs
25 de Janeiro de 2011, 0:00 - sem comentários aindaQuem me conhece, sabe que eu sempre implico com os vícios dos DBAs que iniciam a sua carreira no desenvolvimento. Mas os DBAs que começam como sysadmin também tem seus vícios. Um dos pontos fracos costuma ser a baixa familiaridade com o SQL.
Bom, vou mostrar aqui um alguns exemplos de SQLs que tive que desenvolver recentemente. Alguns foram feitos para ajudar a equipe de desenvolvimento, outros para resolverem problemas de performance e tem um que foi feito por solicitação dos sysadmins. Na verdade, eu deveria mesmo é organizar estes scripts de uma forma lógica, mas são coisas realmente simples para merecerem tanto coidado…
Então chega de blá, blá, blá e vamos a eles:
- Conversão de NOT IN em NOT EXISTS numa carga de dados. É muito comum você precisar carregar periodicamente uma tabela com os dados de uma outra. Isso ocorre muito na integração entre sistemas. Eu sei, eu sei, usar visões materializadas pode ser um processo bem mais inteligente. Infelizmente nem sempre estas decisões estão na nossa mão. Vejamos o caso:
INSERT INTO tabela2 SELECT * FROM tabela1 t1 WHERE campo_pk NOT IN(SELECT campo_pk FROM tabela_origem);
Você tem de carregar a tabela2, com os dados da tabela1 sem repetir os dados que já estejam lá. Utilizar o NOT IN é bem intuitivo, mas quando a tabela2 é grande, se torna um pesadelo, pois a subconsulta uma vez para cada registro na tabela1 e não consegue utilizar índices para isso. Um verdadeiro pesadelo. Então vamos a solução clássica:
INSERT INTO tabela2 SELECT * FROM tabela1 t1 WHERE NOT EXISTS (SELECT NULL FROM tabela2 t2 WHERE t2.campo_pk = t1.campo_pk );
- Pegar apenas o primeiro e o último nome de um campo com nome completo:
SELECT SUBSTR(nome,0,INSTR(TRIM(nome),' ')) primeiro_nome SUBSTR(nome,INSTR(TRIM(nome),' ',-1) + 1) ultimo_nome, FROM tabela_cadastro;
- Limpar caracteres inválidos de telefones. Sim, tem muita gente que gosta de armazenar telefones, CEP, RG, CPF com caracteres não numéricos. Não é o correto, mas muita gente faz. Então, para fazer uma limpeza, vamos utilizar um pouco de expressões regulares, que são pouco exploradas por muitos DBAs e até mesmo desenvolvedores:
SELECT SUBSTR(LTRIM(regexp_replace(telefone,'[^0-9]'),0),0,10) fone_tratado FROM tabela_cadastro;
- Selecionar apenas e-mails válidos. Eu sei, a validação deveria ser feita na carga dos dados, mas nem sempre acontece. Aqui, mais um caso clássico de uso de expressões regulares:
SELECT TRIM(email) email FROM tabela_cadastro WHERE REGEXP_LIKE (TRIM(email),'^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$','i');
- Agora uma forma de saber se o número de sessões num nó do Oracle RAC estão relativamente bem balanceadas. Aqui estou utilizando funções de janelas (que já abordamos aqui antes, mas com o Postgres), algo muito bacana, utilizado exaustivamente em consultas complexas com BI:
SELECT i.instance_name, l.sessions_current, ROUND(l.sessions_current * COUNT(l.inst_id) OVER () / SUM(l.sessions_current) OVER (),2) var FROM gv$license l, gv$instance i WHERE l.inst_id = i.inst_id;
Aqui, um valor entre digamos 0,9 e 1,1 para o campo VAR significa que o nó está relativamente bem balanceado. Esta consulta foi utilizada para uma ferramenta de monitoramento do Oracle RAC.
OBS: Os scripts aqui foram escritos e testados em Oracle 10g e 11g, sorry.
Rodando scrips de um usuário específico com segurança
21 de Janeiro de 2011, 0:00 - sem comentários aindaA história é recorrente: o desenvolvedor mandou para você um mega script (ou um pacote com dezenas deles) para rodar no banco de dados Oracle. Em 99% dos casos o desenvolvedor vai dizer que o script precisa ser executado com você conectado no banco de dados utilizando o usuário XYZ, que é o dono dos objetos que vão ser criados/alterados/apagados.
Aí o que o DBA faz? Pega a senha do usuário numa listinha “cuidadosamente” guardada e roda o script em questão. Então, pare e pense: qual é o problema nisso?
- Você tem que guardar a senha dos usuários da base. Isso vai lhe levar a uma das seguintes situações:
- Você vai colocar senhas fáceis (como o mesmo nome do usuário ou a mesma senha para todos usuários), o que representa uma brecha de segurança;
- Você vai anotar num papel, txt ou algo do tipo todas as senhas. E esse papel, txt, etc não vai estar guardado num cofre, pois você precisa disso com frequência. Nova falha de segurança.
- Você vai criar um banco de dados para guardar as senhas… e ter mais uma base para administrar, gênio.
- Você vai deixar o próprio desenvolvedor/fornecedor rodar o script para você. Tá louco? Jamais faça isso num ambiente de produção!!!
- Você vai ter que conceder permissões para este usuário além do necessário. Se precisa criar uma tabela, precisa conceder permissão de CREATE TABLE. Precisa criar uma sequência? CREATE VIEW. E por aí vai. Não é raro o DBA usar logo uma daquelas mega permissões como DBA, RESOURCE, etc. Afinal, perder tempo com segurança é coisa de DBA chato, certo?
Ok, você é um DBA esperto… muitos anos de praia, já sabe que existem outras alternativas:
- Rodar o script como DBA, mas antes abrir o script num editor e sair colocando o nome do esquema antes do nome do objeto. Isso dá certo, mas dá muito trabalho. Não é algo que se possa automatizar sem cometer alguns erros. Acredite, há casos em que isso pode levar horas e está sujeito a muitos erros.
- Você pode pegar a senha criptografada em DBA_USERS, alterar a senha do usuário, rodar o script e depois voltar a senha original. É também uma forma de bloquear o acesso deste usuário enquanto você está atualizando os objetos. Claro que idealmente um usuário dono de objetos não deveria nunca ser utilizado para acesso pela aplicação… mas não é o que os desenvolvedores tem a mania de fazer. Por mim esse usuário não deveria sequer ter permissão para se conectar na base. Eu realmente não acho esta uma solução elegante, e você precisa manter o usuário com um monte de privilégios desnecessários da mesma forma que antes. Já vi também pessoas colocando permissões de DBA enquanto rodam o script e depois que terminam removem a permissão. Não, não é uma boa idéia. Você também tem de anotar com cuidado a senha criptografada para alterar a senha de volta para a original qualquer caracter bizarro que você erre, já era. Por fim você tem conhecer o impacto de alterar a senha, mesmo que provisóriamente. Experimenta por exemplo trocar a senha do usuário APPS no EBS para ver o que acontece…
Então qual é o procedimento que 10 entre 10 DBAs experientes utilizam? Simples:
ALTER SESSION SET current_shema=foo;
Simples assim. O esquema padrão passa a ser foo. Todos os objetos criados, alterados e apagados serão neste esquema.
Mas calma, existem alguns problemas sim: alguns comandos não trabalham bem com outro CURRENT_SCHEMA. Um deles é a criação de DB Links. Não é possível criar um DB Link para outro esquema, você tem de estar realmente conectado com o usuário em questão para criar este DB Link. Claro que você não cria DB Links no ambiente de produção com frequência (pela sua sanidade mental, eu espero que não). DB Links públicos não tem esse problema, é claro. Outro problema é a criação de JOBs com o DBMS_JOB. Você pode utilizar o DBMS_IJOB, para contornar este problema ou pelo bem da humanidade migrar para o Scheduler.
Bom, de qualquer forma é sempre obrigação do DBA revisar os scripts, verificar os parâmetros de Storage, etc.
OBS: Este post é dedicado a um DBA velho de guerra que ainda guarda velhos hábitos dos tempos que era desenvolvedor e insiste em me trazer mais problemas do que soluções.
OBS2: No PostgreSQL existe uma não conformidade com o padrão SQL (você pode trabalhar no padrão se quiser, mas não vejo vantagem) que permite que os usuários e os esquemas não sejam diretamente relacionados. Então esta cultura ruim do Oracle não é tão comum entre os desenvolvedores/DBAs do PostgreSQL. Além disso o PostgreSQL tem o SEARCH_PATH que é mais refinado que o CURRENT_SCHEMA, e permite trocar facilmente o dono de qualquer objeto (que não seja um objeto de sistema, claro).