Replicação de banco de dados e verificação de consistência

Suas opções são bastante limitadas por causa de seus requisitos para "verificar ... sincronizar constantemente" e "não pode fazer nenhuma alteração em A". Coisas como logs de exibição materializada, dbms_alert, fluxos e um banco de dados de espera estão todos fora de questão.

Se as tabelas em A estiverem constantemente tendo todas as suas linhas atualizadas, então (como disse Jack Douglas) uma visualização materializada seria a mais fácil de configurar. No caso mais provável de que a maioria dos registros não mude em A de momento a momento, você provavelmente desejará configurar um pacote (ou pacotes) em B que selecione de A para mesclar e excluir conforme necessário em B. Isso irá esteja atualizado apenas com a frequência em que é executado, mas, considerando seus requisitos, pode ser o melhor que você pode fazer.

Especificamente, seu pacote deve fazer o seguinte:

• Excluir de B as linhas que não existem em A.
• Mesclar A em B atualizando quando correspondido e inserindo quando não correspondido.

Se você quiser evitar atingir a tabela em A várias vezes, poderá inserir a tabela inteira em uma tabela temporária global em B e, em seguida, excluir/mesclar a partir daí.

Com relação a Minus: Minus pode informar todas as linhas de uma consulta de A que não estão em B. Unindo isso com B menos consulta de A, você pode obter todas as linhas que são diferentes, mas isso provavelmente levaria mais tempo para processar mesmo antes de adicionar a parte de inserção/atualização. Se A não obtiver atualizações ou exclusões, você poderá inserir os resultados do primeiro menos, mas insert into B...where not exists A...ainda seria mais rápido e simples.

Não há como saber que uma tabela em A foi alterada, exceto por votação. Você pode considerar as visualizações materializadas, atualizando periodicamente, que podem funcionar em um dblink - mas apenas uma atualização completa é possível, portanto, isso só pode ser prático se as tabelas forem pequenas.

Difícil, já que você não tem acesso além de um SELECT em db_A. Então, aqui está um pensamento, mas requer algumas suposições bastante rígidas que podem (ou não) ser atendidas:

Requisitos:

• Todas as tabelas sendo sincronizadas teriam:
  • Um timestamp (quanto mais resolução, melhor)
  • Um ID único e sequencial
• Todas as linhas da tabela, uma vez sincronizadas, não mudam.
  • Como alternativa, se ocorrer uma alteração E atualizar um carimbo de data/hora no registro, você poderá resolver isso dessa maneira.

Agora, em db_B:

CREATE TABLE table1...
CREATE TABLE table2...,
etc.

PROCEDURE SYNC_TABLE1 IS
    MAX_ACTIVITY_DATE DATE;
    MAX_SEQUENCE_NO NUMBER;

    BEGIN
        SELECT MAX(SEQUENCE_NO), MAX(ACTIVITY_DATE) 
          INTO MAX_SEQUENCE_NO, MAX_ACTIVITY_DATE
          FROM table1;
    EXCEPTION WHEN NO_DATA_FOUND THEN
        MAX_SEQUENCE_NO := 0;
        MAX_ACTIVITY_DATE = TO_DATE('01/01/1980', 'MM/DD/YYYY');
    END;

    -- Bring over recent entries from db_A.table1 to db_B.table1

    INSERT INTO table1
    SELECT *
      FROM table1@db_A
     WHERE
           -- if using timestamps as your criteria:
           activity_date > MAX_ACTIVITY_DATE
           -- if using sequence nos as your criteria:
           sequence_no > MAX_SEQUENCE_NO
    ;

    -- consider adding limiters to decrease the bandwidth necessary
    -- for large transactions. For example activity_date < MAX_ACTIVITY_DATE + 30
    -- would load a month's worth of transactions at a time. sequence_no <
    -- MAX_SEQUENCE_NO + 500 would load 500 transactions at a time.

    COMMIT;
EXCEPTION WHEN OTHERS THEN
    ROLLBACK;
    -- Consider logging the error!
    RAISE;
END;
(lather, rinse, repeat.)

Novamente, isso só funciona se você tiver um ID exclusivo sequencial OU uma data de atividade sempre atualizada em db_A (e essa data deve ter resolução suficiente para detectar uma transação inserida um milissegundo após a anterior, portanto, os carimbos de data e hora são os melhores.)

A maneira como sincronizo dados entre instâncias Oracle (e instâncias não Oracle, por exemplo, Oracle para mySql) é garantir que eu tenha uma coluna sync_date em todas as minhas tabelas sincronizáveis. Quando uma solicitação é feita para sincronizar dados, essa coluna sync_date é preenchida com a data da sincronização. Portanto, o processo de sincronização real é simples:

FOR r in ( SELECT * FROM table1
            WHERE sync_date IS NULL ) LOOP
    send_sync_data_somewhere;
    UPDATE table1
       SET sync_date = current_timestamp
     WHERE rowid=r.rowid;
END LOOP;

Normalmente, um limitador entra em vigor, mas essa é a ideia. Além disso, se os dados forem alterados em um registro, a coluna sync_date será NULL, ponto em que o processo de sincronização os recuperará novamente.

Observação: não importa a situação, você precisará de algum tipo de tratamento de desduplicação se puder oferecer suporte a alterações de dados depois que uma linha for sincronizada. Você pode tentar um MERGE ou um INSERT com um WHERE NOT EXISTS na cláusula SELECT juntamente com um UPDATE ... WHERE EXISTS.

Espero que isso ajude.