Múltiplos EXTTRAILs (DIRDAT) no mesmo Extract.
Muitas vezes, ao configurar o extract, assumimos, de forma equivocada, que ele pode ter apenas um único EXTTRAIL (dirdat). Eu mesmo já tive essa impressão, pois muitos exemplos na documentação e em artigos seguem essa abordagem. Com isso, por hábito, acabamos incluindo vários owners dentro do mesmo extract, utilizando um único trail.
E foi assim até o dia em que me deparei com uma base que gerava, sabe-se lá quantos dirdat por minuto. O problema é que, por causa disso, os outros owners, que tinham poucas transações, começaram a apresentar um grande volume de lag nos seus replicats. No entanto, o lag não era causado pela quantidade de transações, e sim pelo grande volume de dirdat que o replicat precisava percorrer. Cada um desses dirdat continha poucas transações dos owners que geravam menos atividade, mas, devido ao alto volume geral, o processamento ficava atrasado.
A questão é: como resolver isso? Como separar os dirdat de forma que cada owner tenha suas operações registradas separadamente?
Primeiro, vou mostrar como o "padrão" é implementado e, em seguida, demonstrarei como realizar essa separação,
Criando o arquivo de parâmetro e_prod.prm
GGSCI (777bca39a994) 2> dblogin USERIDALIAS ORIGEM19C
Successfully logged into database CDB$ROOT.
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 5> edit param e_prod
EXTRACT E_PROD
USERIDALIAS ORIGEM19C
EXTTRAIL ./dirdat/aa
TABLE SRC19EEPDB1.OWNER1.*;
TABLE SRC19EEPDB1.OWNER2.*;
TABLE SRC19EEPDB1.OWNER3.*;
Vamos registrar e adicionar o Extract:
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 10> REGISTER EXTRACT E_PROD DATABASE CONTAINER (SRC19EEPDB1) ;
2025-02-18 19:36:19 INFO OGG-02003 Extract E_PROD successfully registered with database at SCN 21184522.
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 11> ADD EXTRACT E_PROD, INTEGRATED TRANLOG, BEGIN NOW
EXTRACT (Integrated) added.
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 12> ADD EXTTRAIL ./dirdat/aa, EXTRACT E_PROD
EXTTRAIL added.
Obtendo informações do Extract:
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 13> info e_prod
EXTRACT E_PROD Initialized 2025-02-18 19:36 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:01:44 ago)
Log Read Checkpoint Oracle Integrated Redo Logs
2025-02-18 19:36:52
SCN 0.0 (0)
Iniciando Extract:
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 14> start e_prod
Sending START request to MANAGER ...
EXTRACT E_PROD starting
GGSCI (777bca39a994) 3> info e_prod, detail
EXTRACT E_PROD Last Started 2025-02-18 19:45 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:09 ago)
Process ID 78817
Log Read Checkpoint Oracle Integrated Redo Logs
2025-02-18 19:46:14
SCN 0.21225987 (21225987)
Target Extract Trails:
Trail Name Seqno RBA Max MB Trail Type
./dirdat/aa 0 409753 500 EXTTRAIL
Vamos popular as tabelas dos respectivos owners e acompanhar a gravação:
SQL> BEGIN
FOR i IN 1001..2000 LOOP
INSERT INTO OWNER1.TABELA_EXEMPLO (ID, NOME, DATA_CRIACAO)
VALUES (i, 'Registro ' || i, SYSDATE - DBMS_RANDOM.VALUE(1, 365));
INSERT INTO OWNER2.TABELA_EXEMPLO (ID, NOME, DATA_CRIACAO)
VALUES (i, 'Registro ' || i, SYSDATE - DBMS_RANDOM.VALUE(1, 365));
2
INSERT INTO OWNER3.TABELA_EXEMPLO (ID, NOME, DATA_CRIACAO)
VALUES (i, 'Registro ' || i, SYSDATE - DBMS_RANDOM.VALUE(1, 365));
-- Faz o commit a cada 100 registros para evitar consumo excessivo de UNDO
IF MOD(i, 100) = 0 THEN
3 COMMIT;
END IF;
END LOOP;
COMMIT;
END;
/ 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
PL/SQL procedure successfully completed.
Podemos ver que todos os registros foram para um único dirdat, o “aa”.
[oracle@777bca39a994 dirdat]$ ls -lrt
total 808
-rw-r----- 1 oracle oinstall 824151 Feb 18 19:50 aa000000000
Nesse momento, o Extract está operando dessa forma:
Como podemos ver acima, o extract está escrevendo a captura dos 3 owners em um único arquivo ./dirdat/aa. A seguir, vamos ver como separar para que cada owner escreva em um dirdat separado.
Agora vamos adicionar o Extract de maneira que cada owner “escreva“ no seu próprio dirdat.
GGSCI (777bca39a994) 2> edit param e_prod
EXTRACT E_PROD
USERIDALIAS ORIGEM19C
EXTTRAIL ./dirdat/aa
TABLE SRC19EEPDB1.OWNER1.*;
EXTTRAIL ./dirdat/ab
TABLE SRC19EEPDB1.OWNER2.*;
EXTTRAIL ./dirdat/ac
TABLE SRC19EEPDB1.OWNER3.*;
Agora vamos adicionar o Extract
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 4> REGISTER EXTRACT E_PROD DATABASE CONTAINER (SRC19EEPDB1) ;
2025-02-18 20:09:24 INFO OGG-02003 Extract E_PROD successfully registered with database at SCN 21234029.
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 5> ADD EXTRACT E_PROD, INTEGRATED TRANLOG, BEGIN NOW
EXTRACT (Integrated) added.
Agora, assim como separamos os exttrail no arquivo de parâmetros, devemos adicionar os 3 ao extract também.
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 6> ADD EXTTRAIL ./dirdat/aa, EXTRACT E_PROD
EXTTRAIL added.
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 7> ADD EXTTRAIL ./dirdat/ab, EXTRACT E_PROD
EXTTRAIL added.
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 8> ADD EXTTRAIL ./dirdat/ac, EXTRACT E_PROD
Pronto, agora vamos iniciar o Extract.
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 9> start e_prod
Sending START request to MANAGER ...
EXTRACT E_PROD starting
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 10> info e_prod
EXTRACT E_PROD Last Started 2025-02-18 20:12 Status RUNNING
Checkpoint Lag 00:03:22 (updated 00:00:01 ago)
Process ID 78851
Log Read Checkpoint Oracle Integrated Redo Logs
2025-02-18 20:09:34
SCN 0.0 (0)
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 11> info e_prod, detail
EXTRACT E_PROD Last Started 2025-02-18 20:12 Status RUNNING
Checkpoint Lag 00:03:22 (updated 00:00:06 ago)
Process ID 78851
Log Read Checkpoint Oracle Integrated Redo Logs
2025-02-18 20:09:34
SCN 0.0 (0)
Target Extract Trails:
Trail Name Seqno RBA Max MB Trail Type
./dirdat/aa 0 1289 500 EXTTRAIL
./dirdat/ab 0 1289 500 EXTTRAIL
./dirdat/ac 0 1289 500 EXTTRAIL
Pronto, agora vamos popular as tabelas de origem novamente para vermos como serão gerados os dirdats:
SQL> BEGIN
FOR i IN 2001..3000 LOOP
INSERT INTO OWNER1.TABELA_EXEMPLO (ID, NOME, DATA_CRIACAO)
VALUES (i, 'Registro ' || i, SYSDATE - DBMS_RANDOM.VALUE(1, 365));
INSERT INTO OWNER2.TABELA_EXEMPLO (ID, NOME, DATA_CRI 2 ACAO)
VALUES (i, 'Registro ' || i, SYSDATE - DBMS_RANDOM.VALUE(1, 365));
INSERT INTO OWNER3.TABELA_EXEMPLO (ID, NOME, DATA_CRIACAO)
VALUES (i, 'Registro ' || i, SYSDATE - DBMS_RANDOM.VALUE(1, 365));
-- Faz o commit a cada 100 registros para evitar consumo excessivo de UNDO
3 IF MOD(i, 100) = 0 THEN
COMMIT;
END IF;
END LOOP;
COMMIT;
END;
/ 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
PL/SQL procedure successfully
Verificando os dirdats gerados:
GGSCI (777bca39a994 as C##OGG@SRC19EE/CDB$ROOT) 12> exit
[oracle@777bca39a994 dirdat]$ ls -lrt
total 420
-rw-r----- 1 oracle oinstall 140230 Feb 18 20:21 ac000000000
-rw-r----- 1 oracle oinstall 140230 Feb 18 20:21 ab000000000
-rw-r----- 1 oracle oinstall 140230 Feb 18 20:21 aa000000000
Pronto, agora nosso Extract está operando dessa forma:
Na imagem acima, agora podemos ver que o OWNER1 está “escrevendo” no ./dirdat/aa o OWNER2 no ./dirdat/ab e o OWNER3 no ./dirdat/ac
É isso, pessoal, espero que este artigo tenha contribuído de alguma forma para o seu projeto atual de OGG ou nos próximos 🙂.
