Apesar da replicação de storage ser mais simples de instalar e administrar, ao compararmos com a replicação de banco de dados temos um “overhead” enorme no consumo de banda de rede podendo chegar a quase 10 vezes mais volume de dados trafegado na rede. A cada operação de insert, update ou delete em um banco de dados, à nível de disco o SGBD grava inúmeras páginas de dados, tais como a página da linha / coluna da tabela alterada propriamente dita, mais páginas de índices, páginas de logs, etc, e assim um replicador de disco / storage terá que replicar para o servidor remoto todas estas páginas alteradas, ao longo que em um replicador de banco de dados como o OBJECTMMRS o único dado trafegado é o dado realmente alterado. É por isso que em projetos de replicação de disco / storage há a necessidade de grande banda de rede em contrapartida com projetos de replicação de banco de dados onde o consumo de banda de rede é mínimo.

Uma outra diferença muito importante é que no caso da replicação de disco / storage, a base de dados remota não pode ser usada, ela fica offline, não podendo ser usada nem para consultas.

Esta informação foi extraída do artigo escrito pelo experiente DBA Oracle Tom Kyte, podendo ser lida em http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:3586678100346900805

A resposta não é apenas um sim ou um não, é um depende.

As maiores restrições para o uso de um replicador assíncrono de dados são:

1. Sua base de dados precisa estar com pelo menos chaves primárias formalmente definidas, e o ideal é que também as chaves estrangeiras estejam formalmente definidas.
2. A forma de usar identificadores únicos precisa ser ajustada. Por exemplo se sua aplicação usa sequences (ou colunas tipo identifier, etc) para a atribuição automática de um número para um cliente, um pedido de vendas, etc, será necessário trabalhar no sentido de criar-se um script para o ajuste das sequências em cada servidor de banco de dados que for existir. . Numa situação onde tivessemos 3 servidores, por exemplo, num dos servidores a sequence numeraria na ordem 1, 4, 7, etc, no outro servidor seria 2, 5, 8, etc e no terceiro seria 3, 6, 9, etc.
3. Um outro cuidado refere-se ao uso de triggers pela aplicação. Se a aplicação não usa triggers ou a usa apenas para atribuição de IDs, etc, então não tem nenhum problema. Se a aplicação usa triggers então estas triggers precisam ser analisadas, principalmente triggers que façam totalizações, resumos, etc. Exemplificando: Se temos uma trigger num sistema contábil que automaticamente ajusta o saldo de uma conta a partir de um lançamento contábil, então temos que desabilitar esta trigger nos servidores deixando-a ativa apenas em um dos servidores para que não haja concorrência na atualização deste saldo gerando inconsistências. Ficando ativa em apenas um dos servidores ela calculará o saldo corretamente à medida que receba os lançamentos provenientes da replicação dos outros servidores, e depois replica o saldo atualizado para todos.
4. Um último cuidado, um pouco relacionado ao item anterior, é quanto à concorrência. Se sua aplicação por exemplo é de controle de estoque, então temos que controlar a aplicação para que um servidor admita transações de estoque apenas relativa à sua filial / site caso contrário teremos saldos de estoque inconsistentes. Se você tem então uma tabela ESTOQUE que contenha o código do produto e o código do local, então o servidor local pode atualizar ESTOQUE apenas para o código do local onde está, se atualizar o saldo de itens de outros servidores isso vai gerar erros nos saldos devido à falta de sincronismo instantâneo entre os servidores. (replicador assíncrono não tem two-phase-commit).

As restrições acima não são exclusivas do replicador ObjectMMRS, é muito importante entender que estas limitações são para QUALQUER replicador assíncrono, não existe meios de se livrar destas limitações sem trabalhar de forma síncrona.

A maioria dos grandes fabricantes de bancos de dados disponibilizou gratuitamente versões limitadas apenas na capacidade de armazenamento de seus gerenciadores de bancos de dados.

Embora funcione quase que 100% igual às versões comerciais, a maioria deles não disponibiliza os recursos mais avançados de banco como replicação.

Usando o replicador de base de dados da OBJECT Sistemas, você poderá utilizar estas bases de dados free e mesmo assim usar replicação multi-master / bi-direcional de dados com um custo bastante reduzido.

Entre em contato conosco que ajudamos a elaborar um projeto de menor custo/benefício para a sua aplicação descentralizada usando bancos de dados free (também chamados versões Express).

O replicador foi testado e homologado para funcionar com as seguintes bases Express:

• DB2 Express
• Oracle XE
• SQLServer  2005 Express

O ObjectMMRS trabalha também como se fosse uma ferramenta ETL (Extract, Transform and Load), a diferênça é que o “Extract” e o “Load” são feitos de forma contínua, tão rápido quanto a sua plataforma suporte (temos casos de ciclos de replicação, ou seja, ciclos de extract e load com intervalos de 5 segundos).

O “Transform” pode ser feito de 2 formas. Existe uma forma simples onde pode-se apenas mapear nomes de colunas e tabelas de origem com nomes de colunas e tabelas destino, e também existe a possibilidade de desenvolver uma classe java que implemente uma Interface pré-definida e com isso pode-se explorar toda a potencialidade da linguagem java para fazer qualquer transformação de dados necessária, inclusive fazendo acessos a bases de dados, sistema de arquivos, etc.

Portanto o ObjectMMRS não se limita a apenas replicar dados, ele também trabalha como um “integrador”, fazendo qualquer transformação necessária para a integração de sistemas heterogêneos em tempo real.