domingo, 4 de maio de 2014

Oracle Goldengate - Parte 4


Jovens

Agora sim. Vamos configurar o EXTRACT e o DATA PUMP.

Prometo, sem enrolação hoje.

Se quiser lembrar onde estamos. Veja aqui [1] e aqui [2] e aqui também [3].

Sem delongas, vamos ao que interessa.

Os procedimentos abaixo devem ser feitos no SOURCE e no TARGET.

1) Criação dos subdiretórios do GoldenGate - Ir até o GG_HOME.

   
cd $GG_HOME
    ./ggsci

    GGSCI (mario) 1> create subdirs

    Creating subdirectories under current directory /oracle/oradata/QSP/gg11

    Parameter files                /oracle/oradata/QSP/gg11/dirprm: already exists
    Report files                   /oracle/oradata/QSP/gg11/dirrpt: created
    Checkpoint files               /oracle/oradata/QSP/gg11/dirchk: created
    Process status files           /oracle/oradata/QSP/gg11/dirpcs: created
    SQL script files               /oracle/oradata/QSP/gg11/dirsql: created
    Database definitions files     /oracle/oradata/QSP/gg11/dirdef: created
    Extract data files             /oracle/oradata/QSP/gg11/dirdat: created
    Temporary files                /oracle/oradata/QSP/gg11/dirtmp: created
    Stdout files                   /oracle/oradata/QSP/gg11/dirout: created

2) Configuração da porta de comunicação do MANAGER.
Lembre-se que o MANAGER deve estar no ar antes de começarmos os procesoss de EXTRACT/REPLICAT.
       
        -- SOmente mostrando o status do MANAGER no momento
        GGSCI (mario) 1> info all
        Program     Status      Group       Lag at Chkpt  Time Since Chkpt
        MANAGER     STOPPED

        -- Vamos editar o arquivo de parâmetros do MANAGER
        GGSCI (mario) 1> edit params mgr
       
        Incluir a linha abaixo:   
        PORT 7090
       
        Importante: Aqui pode ser a porta que quiserem. Eu escolhi essa, mas podem colocar qualquer porta. Salve a alteração.
       
        -- Vamos iniciar o MANAGEr
        GGSCI (mario) 1> start manager
        Manager started.

        GGSCI (mario) 1> info all
        Program     Status      Group       Lag at Chkpt  Time Since Chkpt
        MANAGER     RUNNING

        Importante: Não esqueça de fazer isso no TARGET. Eu espero...
       
3) Configuração do checkpointtable e trandata
       
        -- Lembra que criamos o user lá no artigo 2? Pois é, vamos usar aqui.
        GGSCI (mario) 1> dblogin userid gguser; password COLOQUE_UMA_SENHA_DECENTE_POR_FAVOR
        Successfully logged into database.

        -- Imagine que o processo de REPLICAT está replicando os dados para o TARGET, e então ocorre algo inesperado. Imaginamos que o REPLICAT vai para o status ABENDED devido a algum tipo de erro de falta de registro, por exemplo.
       
        O GoldenGate se oriente de quais operações foram replicadas de duas formas. Sempre é gravado um arquivo de controle e verificação em /dirchk . Este arquivo deve existir e se ele for removido o GoldenGate perde o controle de seus processos.
       
        Podemos também criar uma tabela de ponto de verificação (CHECKPOINT TABLE). Criar essa tabela é opcional e pode ser especificado globalmente (através do arquivo GLOBALS que não iremos utilizar nesses artigos) ou para cada processo de replicação.
       
        Quando o processo de REPLICAT é iniciado e se a tabela existe, ele não lê o arquivo de verificação e sim a tabela de ponto de verificação encontrando o ponto de recuperação e começando a reaplicar todas as transações que ocorreram logo após a parada.    
           
       
GGSCI (mario) 1> ADD CHECKPOINTTABLE gguser.checkpoint
        Successfully created checkpoint table gguser.checkpoint.

       
-- Agora vamos executar o trandata para os owner's que vamos replicar. O ADD TRANDATA permiti ao GoldenGate adquirir as informações de transação que ele precisa para replicação a partir dos registros de transações.                                             
       
        GGSCI (mario) 1> add trandata SAPSR3.*

Pessoal, tudo ok até aqui não é? Como eu escrevi antes, essa é uma maneira de ser feito. Você pode preferir não usar a CHECKPOINT TABLE. Ou criar um arquivo GLOBALS para especificar uma tabela global, enfim. Veja o que melhor te atende.
       
Agora, vamos criar o EXTRACT e DATA PUMP no SOURCE. Somente no SOURCE.       
       
4) Ainda conectado com o dblogin
    GGSCI (mario) 1> dblogin userid gguser; password COLOQUE_UMA_SENHA_DECENTE_POR_FAVOR
    Successfully logged into database.

5) Configuração do EXTRACT
   
    -- Você se lembra que fizemos um expdp/impdp com o flashback_scn? Pois bem, vamos usar o SCN para adicionar o extract a partir dele.
    GGSCI (mario) 1> ADD EXTRACT extqsp6, TRANLOG, SCN 5600816832
   
    Importante: Se você fez um export com a base fechada, aqui você pode usar um "BEGIN NOW" ao invés do SCN. Ficaria assim:
    GGSCI (mario) 1> ADD EXTRACT extqsp6, TRANLOG, BEGIN NOW
       
    -- Vamos também indicar o nosso arquivo de trail para o EXTRACT. Criaremos arquivos de 512M.
    GGSCI (mario) 1> ADD EXTTRAIL ./dirdat/sc, EXTRACT extqsp6, megabytes 512
   
    -- Agora vamos editar o arquivo de parâmetros so EXTRACT    
       
        Incluir as linhas abaixo no arquivo. Podem tirar os comentários se quiser.
       
        GGSCI (mario) 1> edit params extqsp6
           
        -- Nome do extract
        EXTRACT extqsp6
        -- Usuário e senha para as conexões
        USERID gguser, PASSWORD COLOQUE_UMA_SENHA_DECENTE_POR_FAVOR
        -- Trail File
        EXTTRAIL ./dirdat/sc
        -- Indica ao GG que uma operação de TRUNCATE deve ser replicada. Por padrão, o GG não replica truncates.
        GETTRUNCATES
        -- Usamos o DDL para ativar o suporte a DDL, filtrar as operações DDL e configurar uma ação de processamento com base em um DDL. O INCLUDE identifica o início de uma cláusula que contém critérios de filtragem que identificam o escopo DDL que este parâmetro afetará. O MAPPED mapeia o escopo da filtragem.
        DDL INCLUDE MAPPED OBJNAME SAPSR3.*
        -- Tabelas que devem ser extraídas
        TABLE SAPSR3.*;
       
        Salve o arquivo. Esse já está pronto.
       
6) Configuração do Data Pump
       
        -- Vamos fazer o add do pump
        GGSCI (mario) 1> ADD EXTRACT pumpqsp6, EXTTRAILSOURCE ./dirdat/sc, SCN 5637686564
   
        Importante: Se você quiser fazer o pump a partir de um ponto no tempo, pode também. Ficaria assim:
        GGSCI (mario) 1> add extract pumpqsp6, tranlog, begin 2014-04-15 02:00
       
        -- O ADD RMTTRAIL cria uma trilha para o processamento on-line no servidor remoto além de associar um trail a um EXTRACT.
        GGSCI (mario) 1> ADD RMTTRAIL ./dirdat/st, EXTRACT pumpqsp6, megabytes 512
               
        -- Editamos agora o parameter file
        edit params pumpqsp6
       
        -- Nome do pump
        EXTRACT pumpqsp6
       
        -- Usuário e senha para as conexões
        USERID gguser, PASSWORD COLOQUE_UMA_SENHA_DECENTE_POR_FAVOR
       
        -- Especificar o RMTHOST antes da entrada de RMTTRAIL para identificar o servidor remoto e a porta
        RMTHOST 10.193.125.59, MGRPORT 7090
       
        -- Local do trail
        RMTTRAIL ./dirdat/st
       
        -- Indica ao GG que uma operação de TRUNCATE deve ser replicada. Por padrão, o GG não replica truncates.
        GETTRUNCATES
       
        -- Tabelas que devem ser extraídas
        TABLE SAPSR3.*;
       
7) É isso ai. Agora vamos iniciar os dois
    GGSCI (mario) 1> start extract extqsp6
    GGSCI (mario) 1> start extract pumpqsp6
       
8) E listar e ver se está tudo no ar
   
    GGSCI (mario) 1> status manager
    Manager is running (IP port mario.7090).
   
    GGSCI (mario) 1> info all
    Program     Status      Group       Lag           Time Since Chkpt
    MANAGER     RUNNING
    EXTRACT     RUNNING     extqsp6     00:00:00      00:00:09
    EXTRACT     RUNNING     pumpqsp6    00:00:00      00:00:09
   
    Importante: Para uma informação um pouco mais detalhada:
    info extract extqsp6, detail
    info extract pumpqsp6, detail
   
   
    Além de ver o log:
    cd $GG_HOME
    tail -f ggserr.log
   
    ou
   
    GGSCI (mario) 1> VIEW GGSEVT


Agora, vamos criar o REPLICAT no TARGET. Somente no TARGET.       

1) Login, como já feito antes.   
    GGSCI (mario) 1> dblogin userid gguser; password gguserquero

2)     Vamos fazer o add do replicat
    GGSCI (mario) 1> add replicat repqsp6, exttrail ./dirdat/st, CHECKPOINTTABLE GGUSER.checkpoint
   
    Importante: Aqui, se você sabe o momento que deve iniciar o replicat, melhor definir uma data e hora.
    GGSCI (mario) 1> add replicat  repqsp6, ExtTrail ./dirdat/rb, Begin 2014-05-04 03:50:00
   
    -- Editamos agora o parameter file
    edit params repqsp6
   
    -- Nome do replicat
    REPLICAT repqsp6
   
    -- Quando os objetos de origem e destino especificados na instrução MAP têm estrutura exatamente igual. Quando as tabelas de origem e de destino têm estruturas diferentes, devemos criar um arquivo de definições de dados para o objeto de origem e especificar as definições do arquivo com o parâmetro SOURCEDEFS.
    ASSUMETARGETDEFS
   
    -- Muito cuidado aqui jovem. Use as HANDLECOLLISIONS para controlar registros duplicados. Essas duplicidades chamadas de colisões, ocorrem durante uma carga inicial, por exemplo. Quando os dados de tabelas de origem estão sendo carregados e o Oracle GoldenGate está extraindo as alterações transacionais que estão sendo feitas nas tabelas. Quando o GG replicar as alterações após a carga inicial, o HANDLECOLLISIONS fornece ao Replicat uma lógica de tratamento de erros para essas colisões.
    HANDLECOLLISIONS
   
    -- Usuário e senha para as conexões
    USERID gguser, PASSWORD gguserquero
   
    -- Indica ao GG que uma operação de TRUNCATE deve ser replicada. Por padrão, o GG não replica truncates.
    GETTRUNCATES
   
    -- Mapeamento das tabelas de origem e destino
    MAP SAPSR3.*, TARGET SAPSR3.*;
   
    -- Suporte a ddl
    DDL INCLUDE ALL

    -- Aqui vamos ignorar todos os erros, sem tentar novas tentativas de replicação (RETRYOP). Existem várias formas de tratamento desses erros, aqui somente para exemplo, vamos nesse mais genérico. Você pode usar várias instâncias do DDLERROR no mesmo arquivo de parâmetros para lidar com todos os erros que estão previstos.
    DDLERROR DEFAULT IGNORE RETRYOP

3) Agora jovem, basta iniciar...
    start replicat repqsp6, aftercsn 5600816832
   
4) E verificar.
    GGSCI (mario) 1> info all
    Program     Status      Group       Lag           Time Since Chkpt
    MANAGER     RUNNING
    REPLICAT    RUNNING     repqsp6     00:00:00      00:00:19

    -- Um pouco mais detalhado
    stats REPLICAT repqsp6, total, hourly, reportrate min   
    stats REPLICAT repqsp6, total, hourly, table ., reportrate min

   
Ahhhhhhhhhhhhhhhhhhhh meu amigo, estou sentindo a replicação acontecendo.

Se chegamos até aqui é porque conseguimos!!!! Agora é só partir para os testes. Crie tabelas, insira dados, delete, atualize e

Se deu algum erro, repasse os passos. Lembre-se, esse é um cenário específico para as necessidades de um cliente. Pode ser que você precise fazer algum acerto.

Procure nos manuais da Oracle outras opções, veja outros blogs, corra atrás. É muito legal.

Abraço
Mario
   


Nenhum comentário:

Postar um comentário

Isso te ajudou? Comente...

Postagem em destaque

[ORACLE] Embedding ONNX model for Vector Search tests with Oracle Database 23ai

Hello, everyone. How's it going? Today, I'm going to show you how to load an ONNX model into the Oracle 23ai database for your vecto...