A tarefa é trivial, mas não é algo que você faz todo dia. Então resolvi documentar aqui para facilitar a minha vida. Há várias formas diferentes de se rearranjar tablespaces. Com a popularização dos RAIDs, não é mais tão comum ficar dividindo tablespaces através de discos isolados, mas ainda assim, há bons motivos para você criar todos os objetos em apenas um tablespace:

• O backup on-line pode ser feito um tablespace por vez, diminuindo a quantidade de logs gerados durante o backup;
• Você pode transportar tablespaces entre bases (teste e produção por exemplo) sem ter que exportar e importar todos os dados;
• Você pode utilizar diferentes parâmetros de storage, particionamento, etc;
• Fica mais fácil monitorar o crescimento da base com várias aplicações se cada aplicação possuir suas próprias tablespaces;
• Separar índices de tabelas ainda é uma boa política, especialmente porquê os índices podem ser reconstruídos e as tabelas não;
• Objetos especiais como LOBs e dados estáticos são bons candidatos a terem seu próprio tablespace;

Assim sendo, é comum você pegar uma tabela que cresceu muito e alocar um tablespace só para ela e coisas do tipo. Particularmente, quando os desenvolvedores tem a liberdade de criar objetos no ambiente de testes (sim, isso é polêmico e fonte para outra conversa), é comum ter que ajustar os parâmetros de storage antes de colocar os objetos no ambiente de homologação ou produção. Seja qual for o motivo da movimentação, você terá que fazer a migração em 3 etapas:

• Migrar tabelas com o comando:

ALTER TABLE nome_da_tabela MOVE TABLESPACE nome_do_novo_tablespace
;

• Migrar índices com o comando:

ALTER INDEX nome_do_indice REBUILD TABLESPACE nome_do_novo_tablespace
;

• Migrar LOBs com o comando:

ALTER TABLE nome_da_tabela MOVE LOB(nome_da_coluna_lob)
    STORE AS (nome_do_novo_tablespace);

Note tabelas que contem LOBs, possuem um índice que aparece na tabela DBA_INDEXES com data_type do tipo LOB. Se você tentar reconstruir estes índices em outro tablespace você terá um erro do tipo: “ORA-02327: cannot create index on expression with datatype LOB”. Por isso é importante a etapa de migração dos LOBs.

Segue aqui um script para fazer isso rapidamente num para todos objetos de um determinado esquema:

SELECT 'ALTER TABLE nome_do_esquema.' || table_name || ' MOVE TABLESPACE nome_do_novo_tablespace;'
  FROM dba_tables
  WHERE
    owner = 'nome_do_esquema';
 
SELECT 'ALTER INDEX nome_do_esquema.' || index_name || ' REBUILD TABLESPACE nome_do_novo_tablespace;'
  FROM dba_indexes
  WHERE
    owner = 'nome_do_esquema' AND
    index_type != 'LOB';
 
SELECT
  'ALTER TABLE nome_do_esquema.' || table_name ||
  ' MOVE LOB( ' || COLUMN_NAME ||
  ' ) STORE AS (TABLESPACE nome_do_novo_tablespace);'
  FROM dba_tab_columns
  WHERE
    owner = 'nome_do_esquema' AND
    data_type LIKE '%LOB';

Veja, eu respeito o SGDB Oracle. Ele não apenas é um dos primeiros bancos de dados relacionais do mercado como também é robusto, confiável e possui uma miríade de recursos. Mas convenhamos, para um SGDB que está a tempos no mercado, algumas coisas são realmente incríveis. É claro que existem algumas explicações que dizem respeito a história de como o produto surgiu e muitas que tem mais haver com a estratégia de marketing da Oracle.

• A Oracle possui uma enorme documentação. Toda ela está disponível on-line para qualquer um baixar. O mesmo acontece com os softwares (não as atualizações, claro). Uma das coisas que eu aprecio na documentação da Oracle, são as suas recomendações quanto as melhores práticas. Algumas delas são específicas em relação ao seu produto, mas muito do que está lá se aplica a qualquer banco de dados. Dito isso, me explique: qual o motivo de tantos produtos da Oracle não seguirem as suas próprias recomendações. Você não acredita? Quem conhece as restrições das aplicações feitas em FORMS sabe do que eu estou falando. Agora imagine um ERP inteiro sem uma FK (chave estrangeira). Isso mesmo… o famoso ERP da Oracle não tem nenhuma. Alguém me explica isso?
• Eu falei bem da documentação da Oracle, não? Pois é, os caras fazem um bom trabalho nela. Mas tem um problema. Algumas coisas misteriosamente não estão lá. É quase inacreditável que eles esqueçam de documentar coisas tão importantes na documentação. Realmente não faz nenhum sentido. Vou lhes dizer que não é pouca coisa.
• Mais um detalhe bizarro sobre a documentação da Oracle. Você já olhou o manual de instalação deles? Bom, eles tem uma lista de dependências que devem ser instaladas para que você não falhe miseravelmente no meio do caminho. No entanto há algumas coisas bizarras lá. Eu nunca entendi o que o gnome-libs, o xscreensaver e o control-center fazem na lista de dependências. São completamente inúteis. Você definitivamente não precisa delas no seu servidor, mesmo que você queira usar o instalador gráfico. Ainda assim, se você cair na besteira de ler a documentação que acompanha os CDs do Oracle, ou a documentação que vem junto com os binários que você baixa no site, você pode encontrar sérios problemas no caminho. Algumas dependências simplesmente não estão descritas nesta versão da documentação, como você poderia esperar. Não esqueça, sempre olhas os “Release Notes” na documentação on-line. Particularmente, se você for fazer uma instalação em Linx com 64 bits, você me agradecerá muito por esta dica. Isto acontece porquê o instalador do Oracle de 64 bits roda em 32 bits. Surpresa, as dependências de 32 bits não estão na documentação original.
• Sim, o famoso processo de instalação do banco de dados está longe de ser um processo simples. Eu realmente não conheci o Oracle nas suas versões mais antigas. Só conheço ele a partir da versão 8. Não tenho nada contra as zilhões de recomendações de acertos no SO antes da instalação. Na verdade, isso é até bem bacana. Uso muito destas recomendações com outros SGDBs. Mas o instalador gráfico deles é simplesmente horrível. Porquê? É muito simples… ele força você a instalar a interface gráfica no seu servidor. Para os usuários do Windows, tudo bem, mas no mundo Unix isto é uma heresia. Para complicar ainda mais… o instalador é feito em Java e pesa uma tonelada. Fazer um instalador em modo texto não seria tão complexo assim. Não é que seja impossível fazer a instalação em modo texto. Claro que é possível. Mas você tem de criar um arquivo enorme de configurações que pode ser um inferno de editar, conforme forem as suas necessidades. Eu mesmo já criei alguns scripts para me ajudar a criar os arquivos de isntalação em modo texto. Daí para criar um instalador em modo texto seria realmente um pulo. Convenhamos que esta não seria uma tarefa árdua para a Oracle.
• O SQL*Plus número um dos DBAs Oracle. É claro que surgiram coisas mais amigáveis como o SQL Developer, mas o SQL*Plus é a única ferramenta em modo texto que você tem para utilizar. Eu realmente gosto muito das interfaces gráficas. Mas na hora do aperto elas não me servem muito. Quando preciso rodar uma rotina pesada ela também não me ajuda muito. E principalmente, quando quero fazer algum script rápido que acesse o SGDB, o SQL*Plus é uma mão na roda. Mas há um detalhe muito bizarro nele. Ele não tem suporte a biblioteca mais manjada das ferramentas em linha de comando: a ReadLine. Sem ela ou outra substituta a altura, voltamos para a idade do bit lascado. Até as setas do seu teclado perdem a utilidade. É realmente lastimável a perda de produtividade que este detalhe nos proporciona no dia a dia. Para quem está acostumado com o Bash, isto é simplesmente irritante.
• O metalink é a porta de entrada para um universo a parte da Oracle. Patches de segurança, zilhões de documentos sobre erros bizarros, uma maravilha. Só tem um problema. Parece que a Oracle usou seus próprios produtos para criar o seu site. E vou lhes dizer uma coisa… eles parecem que nunca utilizaram o gmail na vida. Definitivamente nunca ouviram falar em AJAX. Para completar, ainda usam FLASH para montar um site lento, feito e com uma péssima usabilidade. Depois que você se acostuma com o jeito tosco do site, até dá para se virar bem, a não ser é claro, que você esteja com um pepino enorme na mão e a sua conexão com a Internet esteja lenta. Se for esse o seu caso, vou lhe dizer qual é a forma de rezolver seus problemas de forma mais rápida, interativa e eficiente: entre no servidor de IRC da freenodes na sala #oracle. Você vai descobrir que o “suporte livre” realmente funciona.
• O padrão SQL já vai completar 20 anos em 2009. Ele surgiu em sua primeira versão oficial em 1989. Ficou famoso pela versão de 1992, e depois contou com mais duas grandes versões sendo a última em 2003. É verdade que a moral da ISO anda meio baixa nos últimos tempos. Mesmo assim, não há motivos para a Oracle ser tão lenta na adoção dos padrões. O tipo de dado TIMESTAMP surgiu apenas na versão 9i. O tratamento com os nulos, o nvarchar, a ausência do tipo inteiro e outras coisas estranhas do Oracle lhe garantem não conformidades significativas com o padrão SQL.
• A Oracle tem uma tara por arquivos binários que nenhum ser usuário possa ler. A coisa não se limita aos dispositivos crús (Raw Devices), vai dos backups com RMAN, ao rastreamento de erros com trace. Enfim, o negócio é confiar na Oracle…

Você não concorda com as minhas observações? Diria que tem outros itens para acrescentar a lista? Coloque nos comentários então!

Coloquei hoje na área de downloads um arquivo contendo 3 diagramas que utilizei para explicar o funcionamento da parte de storage no Oracle RAC. Se alguém encontrar algum erro nos diagramas, por favor me avisem.

A Evans Data Corporation realizou uma pesquisa com 1400 usuário de bancos de dados em todo o mundo para saber o que eles acham dos principais SGDBs do mercado. A pesquisa virou matéria na InformationWeek que por sua vez foi comentada pelo Sr. Lewis Cunningham.

A pesquisa envolveu os seguintes bancos de dados:

• Informix Dynamic Server
• IBM DB2
• Microsoft SQL Server
• MySQL
• Oracle Database 10g or later
• PostgreSQL
• Sybase Adaptive Server

Os critérios de avaliação foram:

• Performance
• Funcionalidades de segurança
• Scalabilidade vertical
• Atomicidade
• Consistência
• Isolação de transações
• Durabilidade das transações
• Qualidade das ferramentas de modelagens
• Suporte ao XML
• Suporte a Multiplatforma
• Qualidade das ferramentas de gerenciamento inclusas no banco de dados
• Qualidade das ferramentas de gerenciamento avaliáveis por outros fornecedores
• Suporte a linguagens de programação

Antes de comentar sobre os resultados, é preciso dizer que a pesquisa é sobre a percepção dos usuários e não sobre testes de laboratório. portanto não reflete características reais dos softwares em questão e sim o que os seus usuários pensam deles.

Os resultados:

• A Oracle ficou em primeiro lugar em todos os critérios. Com o lançamento do 11g no ano passado eu imagino que toda a campanha de marketing esteja ainda viva na memória das pessoas, mas a posição não é de toda desmerecida. Particularmente, acredito que as ferramentas de monitoramento e gerenciamento da Oracle sejam realmente excelentes. Mas acredito que nos itens relativos a ACID (Atomicidade, Consistência, Isolação e Durabilidade) o DB2 rodando em mainframes ainda seja lider absoluto. O DB2 ficou em segundo lugar, mostrando que a Oracle realmente conseguiu cativar os corações do pessoal de TI. Também senti falta da Teradata como competidor, que é líder na área de Data Warehouse e teriam batido a Oracle e o DB2 nesta área. Pelos ítens da pesquisa, o foco foi avaliar os competidores que se destacam na area de OLTP.

• O MySQL foi o terceiro SGDB mais bem avaliado no geral. Apesar disso ter ficado longe no ranking no que diz respeito a ACID, escalabilidade e funcionalidades de segurança. O que puxou sua nota para cima foi a sua avaliação em suporte multiplataforma (2º lugar), performance (3º lugar), qualidade de ferramentas fornecidas por 3ºs (3º lugar) e suporte a linguagens de programação. Acho que a avaliação reflete bem o status do MySQL, sua popularidade e suas características de bicicleta de velódromo: é leve e rápido, mas não tem freios, câmbio, etc. O lançamento do falcon é a promessa de mudar isso. Particularmente eu gostaria que o MySQL continuasse exatamente do jeito que ele é, pois se torna uma ótima opção em sites web dinâmicos, que não se preocupam muito com transações.

• O MS SQL Server foi mal em suporte multiplataforma (ok, isso é óbvio) e performance. Se destacou na parte das ferramentas de modelagem, gerenciamento e suporte a XML.

• O PostgreSQL não foi muito bem… foi mal avaliado nas ferramentas de gerenciamento, modelagem, suporte a XML. No entanto foi bem avaliado em ACID e em funcionalidades de segurança. Estas avaliações positivas são importantes, pois demonstram a percepção dos usuários de que o PostgreSQL é confiável. Uma zebra ocorreu na parte de suporte a plataformas, pois o PostgreSQL deveria ser melhor avaliado aqui. Veja por exemplo que ele roda em FreeBSD uma plataforma para poucos.

O PostgreSQL foi o que teve a segunda pior avaliação Mas estamos em 2008 e apesar do nome da pesquisa, ela foi conduzida em dezembro de 2007. Com o lançamento do PostgreSQL 8.3 algumas coisas mudam na avaliação: a performance melhorou muito e o suporte a XML também. Isto já seria motivo para o PostgreSQL subir vários pontos e encostar no Oracle e no DB2.

O que temos que perceber é que o PostgreSQL vem se desenvolvendo sobre terreno firme. Com a parte de ACID bem resolvida, é possível crescer sem ter que abrir mão da segurança. A performance do PostgreSQL vem crescendo numa taxa que o coloca entre os líderes desta categoria. Algumas funcionalidades que precisam ser melhoradas como a parte de particionamento de tabelas já estão sendo trabalhadas para a versão 8.4. Assim, o que os usuários ainda sentem falta (veja o histórico das listas do PostgreSQL e você verá que isto é recorrente) são de ferramentas de monitoramento, gerenciamento e modelagem. Ainda há muito o que se trabalhar nesta área. Mas acredito que isto seja uma questão que se resolverá. O PostgreSQL tem evoluído muito na quantidade de funções e tabelas de sistemas capazes de fornecer informações úteis para o DBA. O pgsnmpd deverá abrir as portas para o gerenciamento corporativo. O que falta são ferramentas mais amigáveis. Isto não será problema. Já vemos coisas muito promissoras neste sentido. O PostgreSQL está sedimentado sobre uma base sólida, a parte do acabamento virá naturalmente.

O PostgreSQL 8.3 foi lançado. Demorou mais que o dobro do que se esperava. Sim… a expectativa inicial eram de 6 meses até o lançamento. Mas não há motivo nenhum para se ficar triste. 2007 foi um ano excepcional para o PostgreSQL.

Vamos começar simplificando as coisas, agora é correto chamar o PostgreSQL de Postgres. Segundo a documentação oficial:

Many people continue to refer to PostgreSQL as “Postgres” (now rarely in all capital letters) because of tradition or because it is easier to pronounce. This usage is widely accepted as a nickname or alias.

Particularmente eu me acostumei a falar e escrever “PostgreSQL”. Dá mais trabalho e é mais enrolado. Mas além disso, “Postgres” parece ter mais força, causa menos confusão (com pessoas que acabam usando “Postgre” ou “Postgree”). Comercialmente também parece soar melhor, :-).

Bom, antes de falar sobre a versão 8.3, eu gostaria de mostrar alguns detalhes interessantes sobre como o Postgres passou por 2007. A comunidade cresceu, não apenas em número, mas em qualidade. Após a explosão populacional causada pela versão do Postgres nativa para o Windows, houve um crescimento numérico em usuários do Postgres, mas a sua comunidade caiu notavelmente em termos de nível técnico. 2007 pareceu recuperar o fôlego. Veja alguns detalhes interessantes:

• O planet postgresql cresceu em número de participantes e número de artigos;
• No Brasil também surgiram alguns blogs novos sobre PostgreSQL como o PG Viável e o Meu Blog de PostgreSQL;
• O número de companhias contribuindo diretamente com código aumentou, como a Sun e a Skype;
• O número de projetos no Pg Foundry também aumentou muito (hoje conta com mais de 260 projetos). Eles estão mais ativos também, com varias novas versões de projetos sendo lançadas toda semana.
• O número de eventos em que o Postgres esteve presente ou de eventos dedicados exclusivamente ao Postgres também explodiu.
• Foi criado o Postgres OnLine Journal;

Tudo muito bonito… mas chegou a hora do “Show me the code”! Sim, sim, vamos ao que realmente interessa. Vou começar mostrando um teste de performance criado quando o PostgreSQL ainda estava na sua fase Beta.

Antes de dizer qualquer coisa, você precisa entender que o teste foi feito numa condição muito específica:

• Uso do pgbench que realiza uma carga semelhante ao TPC-B, que é uma carga transacional que visa simular um ambiente OLTP;
• As tabelas forma ajustada para um fator de escala de 100, o que equivale a um volume de 10 milhões de linhas;
• 100 conexões ativas simultâneas;
• 10 milhões de transações;

Isto demonstra um cenário bastante específico. Se você esperar um ganho de performance em pequenas aplicações, você certamente não encontrará ganhos de performance tão significativos. Mas o cenário utilizado é muito importante, pois é semelhante a um ambiente corporativo, onde temos aplicações com um grande volume de dados sendo alterado por muitos usuários simultaneamente. Este é um cenário bastante difícil de lidar. Bancos de dados menores certamente sofrerão amargamente neste cenário.

Quando a versão 8.0 foi lançada, uma série de novas funcionalidades importantes marcaram a transição da série 7.x para a série 8.x . Além das novas funcionalidades que tornam a vida do desenvolvedor mais fácil (ou funcionalidades que melhoram a usabilidade) notou-se um aumento significativo nas opções de segurança (PITR, Stand By, etc) e de desempenho (Tablespaces, Particionamento, AutoVacuum, etc). Com a versão 8.3, estas novas funcionalidades atingiram um bom grau de maturidade. Ao comparar a versão 7.4 com a versão 8.3, você verá um salto enorme atingido em apenas 4 anos. Veja a matriz de comparação de funcionalidades para ter uma idéia do que foi realizado.

Ao olhar a última versão do Oracle 11g, percebe-se um aprimoramento notável nas ferramentas de gerenciamento do SGBD. As ferramentas de gerenciamento do Oracle 11g são realmente invejáveis. No entanto, quando pensamos em desempenho, não vemos um aprimoramento significativo. O mesmo aconteceu na transição da versão 9i para o 10g.

Por outro lado, o Postgres tem dado saltos enormes em termos de desempenho e ainda possui ferramentas pouco sofisticadas. A questão é que o desempenho do Postgres deve ultrapassar o do Oracle rapidamente. Uma pergunta que muitos devem estar se fazendo é se ele já não passou com o lançamento do 8.3! De toda forma, isto deverá ser o suficiente para atrair novos investimentos em torno do Postgres, fazendo com que mais empresas ofereçam ferramentas de gerenciamento para o Posrgres. O time principal do Postgres não desenvolve nenhuma ferramenta de gerenciamento além do psql. O resto fica a cargo de outros projetos de software livre ou de empresas que oferecem ferramentas proprietárias.

O Postgres tem simplificado o trabalho para muita gente. Migrar para ele está cada vez mais fácil. Além de incorporar funcionalidades e sintaxes semelhantes as do Oracle, o mesmo tem acontecido com o MySQL, com a introdução do tipo de dados ENUM, por exemplo. Chegou a hora de começar a comparar o Postgres e o MySQL mais de perto. No entanto engana-se quem pensa que o Postgres adota padrões exóticos de vários SGDBs se tornando uma colcha de retalhos. O Postgres concentra a maior parte dos seus esforços em trazer funcionalidades de acordo com o padrão SQL. Isto significa que o Postgres é uma excelente opção para aqueles que estão preocupados com a portabilidade também.

Bom… se você não testou o Postgres 8.3, vá correndo testar. Se já testou, você já pode ir vendo o que está por vir na versão 8.4…