Treinamento Oracle GoldenGate 19c

01 - Instalação
Oradata Consultoria & Treinamentos
1

Instalação
Neste capítulo você vai aprender:
● Localização (oracle.com)
● Escolha da plataforma/versão correta
● Download
● Descompactação
● Variáveis de ambiente
● Instalação
2

Download
oracle.com > Downloads > Middleware > GoldenGate
3
1
2
3

Antes de qualquer coisa!
● Acerte o seu .bash_profile conforme abaixo.
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/19.0.0/dbhome_1
export ORACLE_SID=CDBPROD
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export OGG_HOME=$ORACLE_BASE/product/19.0.0/ogghome_1
export PATH=$PATH:$ORACLE_HOME/bin:$OGG_HOME/bin
4

Instalação
$ unzip 191002_fbo_ggs_Linux_x64_shiphome.zip
$ cd fbo_ggs_Linux_x64_shiphome/Disk1
$ ./runInstaller.sh
5

Instalação - modo silent (texto)
● Copie o arquivo fbo_ggs_Linux_x64_shiphome/Disk1/response/oggcore.rsp
para /home/oracle.
$ cp oggcore.rsp /home/oracle
● Edite o arquivo conforme abaixo:
10
PARÂMETRO VALOR PARÂMETRO VALOR
INSTALL_OPTION ORA19c DATABASE_LOCATION $ORACLE_HOME
SOFTWARE_LOCATION $OGG_HOME INVENTORY_LOCATION /u01/app/oraInventory
START_MANAGER TRUE UNIX_GROUP_NAME dba
MANAGER_PORT 7809

Instalação - modo silent (texto)
● Para executar a instalação em modo texto execute o comando:
$ ./runInstaller -silent -responseFile
/home/oracle/oggcore.rsp -showProgress
● Ao término da instalação tente acessar a interface de linha de comando
digitando ggsci. O resultado deve ser esse:
11

02 - Arquitetura
13

Conteúdo deste Capítulo
● Arquitetura do GoldenGate
● Topologias
● SCN / CSN (System Change Number)
● Processos do GoldenGate
14

System Change Number - SCN
● Número da modificação no sistema: Todo comando executado pelo banco
de dados que provoque alterações (qualquer coisa != SELECT).
● Peça chave no processo de replicação do Oracle GoldenGate
● Para capturar o seu SCN use:
select current_scn from (g)v$database;
select dbms_flashback.get_system_change_number from dual;
NOTA: Outros bancos de dados possuem o mesmo mecanismo, porém com
outro nome. Verifique na documentação do fabricante.
17

Processos / Componentes
● Manager: Não é o processo mais falado do GoldenGate, porém é o mais
importante (sem ele nada funciona). Veja suas principais atribuições:
○ Inicializar (ou reinicializar) demais processos do GoldenGate
○ Inicializar processos dinâmicos do GoldenGate
○ Gerenciar o número das portas dos outro processos
○ Gerenciamento dos Trail Files
○ Eventos, Erros, Threshold e Reports
● Este processo pode controlar diferentes tipos de processo do Oracle
GoldenGate permitindo um gerenciamento centralizado a partir de uma
estrutura simples e única.
18

● Collector: Processo de background executado no servidor target (destino)
quando há sincronismo online ativo.
● Este processo é necessário para garantir as seguintes funcionalidades:
○ Recebimento de conexões remotas (processo extract origem), e encaminha a requisição para
a porta configurada/disponível.
○ Recebe as transações vindas dos processos remotos (extract) e escreve nos trail files locais
● Sempre que uma conexão é feita ao servidor de destino o processo manager
inicia um “collector” e quando a conexão é encerrada o processo “collector”
também é finalizado.
19

Capture (extract):
● Processo utilizado no servidor de origem, para extrair as informações que
fazem parte do processo de replicação.
● As informações são coletadas dos logs de transação (redo e/ou archive log).
● As transações são retidas pelo processo extract até que recebam um commit
ou rollback, assim que é executado um commit os dados são escritos nos
trail files para serem enviados aos servidores de destino.
● Transações que recebem rollback são descartadas.
20

Capture (extract):
● Existem dois tipos de processos extract:
○ Initial load (carga inicial): Coleta um conjunto de dados estático do servidor de origem.
○ Change Synchronization (sincronização contínua): Coleta contínua de dados para
replicação entre servidores de origem e destino.
● Além de dois tipos de extract, também há a possibilidade de cada um deles
poder trabalhar de dois modos distintos:
○ Clássico: Default, completamente controlado pelo GGSCI, porém quando for necessário
fazer alguma análise de performance, é necessário se analisar pelo sistema operacional com
ferramentas como sar, mpstat, iostat, top, free entre outros. Além disso é preciso considerar
que cada um desses processos irá consumir algo entre 25MB à 55MB (por processo) a partir
da memória física do servidor.
21

Capture (extract):
○ Integrado: Iniciado no Oracle GoldenGate 11.2.0.2 e disponível a partir dos bancos de dados
Oracle 11.2.0.3. É um processo registrado dentro do banco de dados e trabalha junto com o
logminer.
22

Capture (extract):
● Repare que o processo quando integrado no modo integrado passa a
trabalhar integrado com o logminer e executando-se em quatro etapas:
○ Reader: Leitura das transações e quebra em pequenas sessões para outra leitura.
○ Preparer(n): Usado de maneira paralela (se necessário) para ler as informações e filtrar as
transações.
○ Build: Merge dos registros ordenando-os por SCN.
○ Capture:Coloca os registros nos trail files ordenados pelos LCR (logical change records).
● O processo integrado é um pouco mais complexo, porém é o tipo de
processo que a Oracle deseja adotar como padrão, porém ainda é possível
trabalhar das duas maneiras ainda.
23

● Data Pump: É um outro tipo de extrac, porém este tem a capacidade de
enviar dados através de rede. O que representa uma grande vantagem em
caso de indisponibilidade na comunicação entre os servidores:
● Em caso de perda de comunicação entre os servidores, o processo Data
Pump continua a coletar as informações e as retém nos trail files até que a
comunicação se restabeleça.
● Se você não estiver usando trail files local, o processo de extract apresentará
um erro, porém quando a comunicação for retomada para reiniciar o extract
sem perda de dados.
24

● Delivery Process: É o processo responsável por fazer a aplicação das
transações no servidor de destino, lendo as mesmas a partir dos trail files
garantindo a ordem cronológica (através do SCN).
● Até a versão 12.1.2.0 do Oracle GoldeGate existia apenas uma versão
(clássica) do processo de delivery (também conhecido como replicate),
porém agora há três tipos.
○ Classic
○ Coordinated
○ Integrated
● Cada uma dessas versões tem seus benefícios, porém a Oracle tende a
incentivar o uso do modo “integrated” que é válido para bancos de dados a
partir da versão 11.2.0.4. 25

Delivery Classic:
● Default, gerenciado através do sistema operacional, assim como o extract
clássico.
● Requer uma quantidade de memória para cada processo, entre 25MB ou
55MB por processo.
Delivery Coordinated:
● Similar ao clássico, porém trabalha com o conceito de master slave, para
melhorar a performance.
26

Integrated Process:
● Criado a partir da versão 12c.
● Permite a ingestão de grande volume de transações, sem dependência de
funções específicas.
● Divide as transações em grupos.
● Aplica transações de acordo com as regras de modelagem, primary key,
foreign key, unique key entre outros.
27

Integrated Delivery:
● Da mesma maneira que o processo extract integrado trabalha a partir de uma
API, o processo de integrado de delivery também, vide imagem abaixo:
28

Integrated Delivery:
● Reader: Processo que computa as transações vindas dos trail files,
baseadas em PK, FK, UK e DDL.
● Coordinator: Garante que todas as transações estão na ordem correta e às
envia para os processos de aplicação (apply(n)).
● Apply(n): Aplica às transações no banco de dados na ordem do SCN, porém
transações que não possuem dependências podem ser aplicadas fora da
ordem para otimizar a performance, o paralelismo é definido de maneira
automática de acordo com o volume de transações recebidas.
29

Trail Files:
● Arquivos binários usados para guardar as transações das aplicações dentro
do GoldenGate.
● Suporta extração e replicação contínua retendo as informações de maneira
temporária.
● Podem existir tanto na origem quanto no destino.
● Precisão nos dados e tolerância à falhas.
● Separados por processos, para prover isolabilidade entre os processos.
30

03 - Replicação Básica
32

Conteúdo deste Capítulo
● Profiler
● Arquivos de parâmetros
● Trail Files
● Obey Files
● Carga Inicial
● Replicação Contínua
33

Profiler
Antes de iniciar um processo de replicação pelo Oracle GoldenGate é preciso
verificar se há algum tipo de informação que não pode ser replicada ou necessita
de alguma atenção especial.
Para fazer essa verificação, existem três opções que são dois scripts para usar
em banco de dados até a versão 10g e uma query simples que pode-se executar
a partir da versão 11.2.0.4.
Estes scripts vão executar uma verificação dentro do banco de dados a fim de
encontrar essas possíveis inconsistências e podem ser executados tanto focados
em apenas um schema ou para o banco de dados inteiro, veja alguns exemplos.
34

Profiler
● Para analisar apenas um schema específico:
$ sqlplus / as sysdba
@full-schemaCheckOracle_06292015.sql
● Para analisar o banco de dados inteiro:
full-DB_CheckOracle_07082015.sql
Nota: Para baixar estes scripts bem como coletar maiores informações sobre
os mesmos, pesquise no MOS pelas notas 1298562.1 e 1296168.1 35

Profiler
● Ao executar os scripts o output deve ser algo similar a imagem abaixo:
36

Profiler
● A partir da versão 11.2.0.4, a vida ficou mais fácil, pois agora o Oracle já tem
uma tabela pronta com as informações que precisamos, logo os scripts não
são mais necessários:
select owner, object_name, support_mode
from dba_goldengate_support_mode;
● Fique atento a coluna support_mode pois os registros que apresentarem o
valor NONE não poderão ser replicados.
37

Pré-Requisitos
● Bancos de dados em modo ARCHIVELOG.
STARTUP MOUNT
ALTER DATABASE ARCHIVELOG
● Bancos de dados dados em modo FORCE LOGGING.
ALTER DATABASE FORCE LOGGING
● Bancos de dados com SUPPLEMENTAL LOG DATA PK.
ALTER DATABASE ENABLE SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS
● SPFILE com ENABLE_GOLDEGATE_REPLICATION=TRUE.
ALTER SYSTEM SET ENABLE_GOLDEN_GATE_REPLICATION=TRUE
38

Preparação
● Criação do usuário responsável pelo GoldenGate
CREATE USER C##GGUSER IDENTIFIED BY GGUSER DEFAULT TABLESPACE GGTBS
● Permissões exclusivas para o usuário go GoldenGate
GRANT CREATE SESSION, CONNECT, RESOURCE TO C##GG_USER CONTAINER=ALL;
GRANT ALTER ANY TABLE, ALTER SYSTEM TO C##GG_USER CONTAINER=ALL;
GRANT SELECT ANY DICTIONARY TO C##GG_USER CONTAINER=ALL;
GRANT DBA TO C##GG_USER CONTAINER=ALL;
GRANT SET CONTAINER TO C##GG_USER;
39

Preparação
● Permissões exclusivas para o usuário go GoldenGate
exec DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE(
'C##GG_USER',container=>'ALL');
/
'C##GG_USER','capture',container=>'ALL');
/
'C##GG_USER','apply',container=> 'ALL');
/
40

[SCHEMA] TRANDATA
Fazem as mesmas funções com escopos distintos
● SCHEMATRANDATA: para um schema específico
● TRANDATA: Todo o banco de dados (inclusive se não for Oracle).
● Habilita supplemental logging para novas tabelas (CREATE TABLE).
● Atualiza os supplemental logging para tabelas alteradas (ALTER TABLE).
● Atualiza os supplemental logging para tabelas renomeadas.
● Atualiza os supplemental logging para tabelas em que as PKs e UKs são
criadas e/ou eliminadas.
41

[SCHEMA] TRANDATA
● O uso destes comandos é feito através do GGSCI.
$ ggsci
● Uma vez dentro do GGSCI é preciso conectar-se com o usuário responsável
pelo OGG dentro da instância.
GGSCI> dblogin userid ggate password ggate
● Após estar conectado, execute o comando:
GGSCI> add schematrandata HR
42

Arquivos de Parâmetros
● Uma replicação unidirecional basicamente possui esta arquitetura:
43

Arquivos de Parâmetros
● O processo de replicação dentro do OGG é basicamente orientado por
arquivos de configurações e processos no SO e/ou banco de dados.
● De maneira geral, em uma replicação unidirecional, basicamente você tem
três arquivos de configuração, que estão diretamente relacionados com seus
respectivos processos:
44
Processo Arquivo Função Local Obrigatório
Manager mgr.prm Gerenciar OGG Origem e Destino Sim
Extract Extrair os dados Origem e/ou Destino Sim
Replicat Aplicar as transações Destino Sim
Data Pump Represar os dados Origem e/ou Destino Não

Arquivos de Parâmetros - Extract
● Entre no GGSCI, conecte-se à instância e adicione o processo extract ao
OGG.
$ ggsci
GGSCI> dblogin userid c##gg_user, password GG_USER
GGSCI> add extract ext1, integrated tranlog, begin now
● Adicione a tabela de checkpoint (opcional, mas recomendado).
GGSCI> add checkpointtable orcl.c##gg_user.gg_checkpoint
● Registre o extract no banco de dados.
GGSCI> register extract EXT_INVOICES database container(orcl)
45

● Use [SCHEMA] TRANDATA para o schema e/ou banco de dados desejado.
GGSCI> add schematrandata orcl.APP_TEST
● Adicione o trail file para o extract que você está criando.
GGSCI> add exttrail ./dirdat/ex, extract EXT_INVOICES
● Agora com o comando “edit params” crie o seu arquivo do processo extract
(vide próximo slide).
GGSCI> edit params EXT_INVOICES
46

-- Tipo do arquivo e nome do arquivo
EXTRACT EXT_INVOICES
-- Credenciais de logon
USERID OGG_USER PASSWORD OGG_USER
-- Local de e nome do trail file
EXTTRAIL ./dirdat/ex
-- Opções de ajustes adicionais
TRANLOGOPTIONS EXCLUDEUSER OGG_USER
TRANLOGOPTIONS DBLOGREADER
…
-- Tabela(s) da replicação
TABLE APP_TEST.INVOICES; 47

● Após criar o arquivo de parâmetrização do processo extract, inicie-o dentro
do GGSCI com o comando start extract [nome do processo].
GGSCI> start extract EXT_INVOICES
GGSCI> info all
● Após a execução deste de comando o output deve ser algo similar à imagem
abaixo.
48

Arquivos de Parâmetros - Extract (Data Pump)
● Este processo tem a função de enviar as transações para os trail files do
servidor de destino de sua replicação.
● Neste arquivo você vai informar os dados do servidor de destino, porta do
processo manager (destino).
● Local e nome do trail file (destino).
● Tabelas que serão replicadas.
49

● Adicione o processo data pump à configuração do OGG. Repare que ele vai
capturar as informações do seu trail file local.
GGSCI>add extract EXT_PUMP, exttrailsource ./dirdat/lt
● Registre o Data Pump na instância de banco de dados.
GGSCI>register extract EXT_PUMP, database container(orcl)
● Informe onde as informações devem ser entregues no destino e qual a
origem dessas informações (processo extract data pump origem).
GGSCI>add rmttrail ./dirdat/pu, extract EXP_PUMP
50

● Crie o arquivo de configuração do processo extract data pump.
GGSCI>edit params EXT_PUMP
extract EXT_PUMP
userid OGG_user, password OGG_USER
rmthost labgg-destino, mgrport 7809
rmttrail ./dirdat/pu
table ORCL.APP_TEST.*;
● Uma vez que as configurações estão prontas, o próximo passo é iniciar o
processo com o comando start extrat [nome do processo].
GGSCI>start extract EXT_PUMP
GGSCI>info all
51

● Após executar todas as configurações, criar o arquivo de configuração e
iniciar os processo, com o comando info all, veja se o mesmo foi iniciado
corretamente com o comando “info all”
GGSCI>info all
● Após a execução do comando “info all” o resultado deve ser similar à imagem
abaixo.
52

Carga Inicial
● Antes de a replicação “contínua” dos dados iniciar, é preciso que haja um
processo de carga inicial (cópia fria). Com o OGG você pode fazer esse
processo de três maneiras quando a replicação for Oracle x Oracle.
○ Oracle Data Pump (expdp & impdp)
○ Carga direta com SQL*Loader
○ Carga a partir de arquivos com SQL*Loader.
● O procedimento mais comum é via Data Pump utilizando o parâmetro
FLASHBACK_SCN para que tenhamos um “ponto de corte limpo”.
53

Carga Inicial - Procedimento
● Antes de iniciar o processo de exportar a(s) tabela(s) que deseja replicar,
capture o SCN atual de sua instância.
select current_scn from (g)v$database;
select dbms_flashback.get_system_change_number from dual;
● Uma vez que você já tem o número do SCN, você pode gerar um dump da(a)
tabela(s) que deseja replicar através do OGG.
expdp user/pass direcotory=dump_dir dumpfile=tables.dmp
tables=APP_TEST.INVOICES flashback_scn=1234 logfile=exp_tables.log
● Após a exportação da(s) tabelas(s), mova o arquivo para o seu servidor de
destino e faça a importação das informações, pois o próximo passo será
ativar a replicação contínua.
54

Arquivos de Parâmetros - Replicat
● Lê as informações armazenadas nos trail files e às aplica no banco de dados
de destino em ordem cronológica.
● Procedimento de criação é similar aos outros processos.
GGSCI> add checkpointtable dest.c##gg_user.gg_checkpoint
GGSCI> add replicat EXT_REP, exttrail ./dirdat/pu, checkpointtable
dest.ogg_user.gg_checkpoint
GGSCI> edit params EXT_REP
replicat EXT_REP
userid ogg_user@pdb_trgt, password ogg_user
assumetargetdefs
HANDLECOLLISIONS
map ORCL.APP_TEST.*, target TRGT.NEW_SCHEMA.*; 55

Arquivos de Parâmetros - Replicat
● Depois de ter registrado o processo replicat EXT_REP dentro do OGG e
adicionado o mesmo dentro da instância de banco de dados,o próximo passo
é iniciar o processo de replicação (replicat EXT_REP).
GGSCI> start replicat EXT_REP
GGSCI> info all
56

Trail Files
● Arquivos utilizados pelo OGG para armazenar as transações que sofreram
commit e fazem parte do processo de replicação.
● São armazenados localmente no servidor de origem (local).
● Utilizados pelo processo extract data pump para criar trail files no servidor de
destino.
● Quando no servidor de destino, são lidos pelo processo replicat para capturar
as informações das transações e atualizar as informações dentro do banco
de dados de destino.
57

Trail Files - Tamanho e Retenção
● Tamanho default 50MB.
● Para ambientes produtivos é muito pequeno.
● Recomenda-se que o tamanho seja o mesmo tamanho dos archives.
○ Caso a replicação seja de toda a instância.
○ Se for apenas alguns schemas ou objetos, pode-se diminuir o tamanho.
● Período de retenção o mesmo período que se retém os archive logs.
58

Obey Files
● São arquivos similares a scripts sql, porém estes são executados dentro do
GGSCI, com o intuito de facilitar suas atividades no dia a dia.
$ vi login.oby
dblogin userid c##gg_user, password GG_USER
versions
info all
GGSCI> obey login.oby
59

Treinamento Oracle GoldenGate 19c

Mais conteúdo relacionado

Mais procurados

Último

Treinamento Oracle GoldenGate 19c