DBC Treinamento ODI 12c 2

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Treinamento interno ODI
www.dbccompany.com.br
Matriz Av. Andaraí, 531 Porto Alegre/RS Tel: (51) 3330-7777
Sudeste Rua Apeninos, 930 16º andar São Paulo/SP Tel: (11) 2893-2600
E-mail: contato@dbccompany.com.br
Agenda
O que é Oracle Golden Gate
Funcionamento Oracle Golden Gate
Estudo de caso Lojas Renner
Conhecendo ambiente HTC – Renner
Funcionamento das Stages (CRE e TOTVSCARD)
Parametrização e jornalização padrão de cargas
Funcionamento de Cargas por Lote
Troubleshooting.
O que é Oracle Golden Gate?
O Oracle Golden Gate é uma aplicação de elevado desempenho destinada à captura, transação, transformação e entrega de dados, em tempo real, e permite a replicação bidirecional dos dados baseada em registros. 
A aplicação garante que os sistemas críticos da sua organização estejam operacionais durante 24 horas, 7 dias por semana e que os dados associados sejam distribuídos por toda a empresa para otimizar o processo de decisão.
Funcionamento do Oracle Golden Gate
Funcionamento do Oracle Golden Gate
•	Uni-directional: Nesta configuração os dados são replicados em uma direção a partir da origem para o destino. 
•	Bi-Directional: Os dados são replicados em ambas as direções e fica sincronizado entre a base A e B. 
•	Peer to Peer : Semelhante ao Bi-directional mas envolve mais do que dois bancos de dados que permanecem sincronizados. 
•	Broadcast: Os dados de origem é enviado para vários destinos 
•	Consolidation: Aqui dados de várias fontes são entregues a um banco de dados de destino. 
•	Cascading: Dados de uma fonte é enviada para múltiplos destinos.
Funcionamento do Oracle Golden Gate
Além das formas de replicações acima, o GoldenGate também possibilita replicações/integrações entre origens e destinos com tecnologias heterogêneas, como por exemplo:
Funcionamento do Oracle Golden Gate
O Oracle Golden Gate pode ser configurado para os seguintes propósitos:
 
Extração estática de dados de um banco de dados e carrega-los em outro banco de dados.
Extração continua e replicação de comandos DML, ou seja, inserts, updates, deletes e demais comandos de manipulação do dados. Também a replicação de operações de DDL, ou seja, manipulações da estrutura dos objetos, como por exemplo: Alter Table, Drop Table, Create Index, entre outros e desta forma manter a origem e a base destino da replicação consistente.
Extração de dados de um banco de dados e replica-lo para um arquivo externo.
Funcionamento do Oracle Golden Gate
O Oracle Golden Gate é composto pelos seguintes componentes: 
Extract
Data Pump
Replicat
Trails or extract files
Checkpoints
Manager
Collector
Funcionamento do Oracle Golden Gate
Extract
O extract é o processo de extração (captura) do Oracle Golden Gate. Extract executa no sistema origem ou em downstream database, dependendo do banco de dados e requisitos de implementação.
Data Pump
O data pump é um extrator em grupo secundário no âmbito da fonte de configuração do Oracle GoldenGate . Se um data pump não é utilizado, Extract deve enviar as operações de dados capturados a uma trilha (Trail) remoto no ambiente de destino. Em uma configuração típica com um data pump, no entanto, o primário Extract em grupo escreve para uma trilha (Trail) no ambiente de origem. O data pump lê esta trilha e envia as operações de dados através da rede para uma trilha remota no ambiente de destino. O data pump acrescenta flexibilidade de armazenamento e também serve para isolar o processo do Extract primário de atividades de TCP / IP .
Funcionamento do Oracle Golden Gate
Replicat
O processo Replicat é executado no sistema de destino, lê a trilha (Trail) nesse sistema, e em seguida, reconstrói as operações DML ou DDL e as aplica para o banco de dados de destino. Replicat usa SQL dinâmico para compilar uma instrução SQL por vez, e depois executá-lo muitas vezes com diferentes variáveis (Bind).
Trails
Para suportar a extração contínua e replicação de alterações de banco de dados, o Oracle GoldenGate armazena registros das alterações capturadas temporariamente no disco em uma série de arquivos chamados de trilha (Trail). A trilha pode existir no sistema de origem, em um sistema intermediário, no sistema de destino, ou qualquer combinação destes sistemas, dependendo de como você configurar o Oracle GoldenGate. No sistema local é conhecido como uma trilha (Trail) de extract (ou trilha local). Em um sistema remoto, é conhecida como uma trilha remota.
Funcionamento do Oracle Golden Gate
Checkpoints
Checkpoints armazenam a posição atual de leitura e escrita do processo para o disco (HD) para fins de recuperação. Checkpoints garantem que as alterações de dados que estão marcados para a sincronização são capturados por Extract e aplicado ao alvo por Replicat, e eles impedem o processamento redundante. Eles fornecem tolerância a falhas, impedindo a perda de dados se o sistema, a rede , ou um processo Oracle GoldenGate precisar ser reiniciado. Para configurações de sincronização complexas, checkpoints permitem que vários processos Extract ou Replicat leiam a partir do mesmo conjunto de trilhas.
Funcionamento do Oracle Golden Gate
Collector
Collector é um processo que é executado em segundo plano no sistema de destino quando, online change synchronization estiver ativo. Collector faz o seguinte:
Após o envio de uma requisição de conexão a partir de um extract remoto para o Manager, ele escaneia e liga-se a uma porta disponível e, em seguida, envia o número da porta para o Manager para que ele a atribua para o processo Extract requerente.
Recebe as alterações extraídas do banco de dados que são enviados pelo Extract e grava-os em um arquivo de trilha. Collector Manager inicia automaticamente quando uma conexão de rede é necessária, para que os usuários Oracle GoldenGate não interajam com ele. Collector pode receber informações de apenas um processo Extract, desta forma ha um coletor para cada Extract que for usado. Collector termina quando o processo Extract associado termina.
Funcionamento do Oracle Golden Gate
Manager
Manager é o processo de Controle do Oracle GoldenGate. O Manager tem de estar em execução em cada sistema na configuração do Oracle GoldenGate antes do Extract ou Replicat possam ser iniciados, e o Manager deve permanecer em funcionamento enquanto esses processos estão sendo executados de modo que as funções de gestão de recursos são realizadas. O Manager executa as seguintes funções:
•	Iniciar processos Oracle GoldenGate
•	Iniciar processos dinâmicos
•	Manter números de porta para processos
•	Executar o gerenciamento de trilha
•	Criar eventos, relatórios de erro, e relatórios de Threshold.
Bancos de dados suportados pelo Oracle Golden Gate
						Banco de dados suportados
 O Oracle Golden Gate é suportado pela maioria dos bancos de dados de uso comum no Mercado como:
•	Oracle Database
•	TimesTen
•	MySQL
•	IBM DB2
•	Microsoft SQL Server
•	Teradata
•	Sybase
•	Enscribe
•	SQL/MX
Conhecendo ambiente HTC - Renner
captura
Trail files
lan
Trail files
pump
pump
entrega
Oracle Golden Gate
Staging
Origens
HTC
DW
SISTEMAS
EXADATA
O HTC originou-se da necessidade de definir uma solução que tratasse dos dados históricos da operação de produtos financeiros. O incentivo deu-se em razão do desenvolvimento da nova Plataforma de Produtos Financeiros (PPF) e o projeto de implantação da nova processadora Totvscard em substituição a CCR Legado
Frente 1 - Buscar as informações das Origens para carregar uma base consolidada (ODS)
Tombamento IQ
Gerenciador de Campanha
Motor Crédito
Neurotech
Staging
Extract/Transform/Load
Consolidado ODS
TOTVSCARD
Conductor
PDV Renner
E-Commerce Renner
PDV Camicado
E-Commerce Camicado
Clube de Vantagens
Tombamento IQ
Portal Realize 3.0
CRE
Light / Portal Realize 2.0
Portal Realize 3.0
Motor Crédito – Manutenção Cliente
Tombamento IQ
Behavior Score
Integração
Totvscard - FFinancing
Light
Meta e Coordenadores
Log Workflow Detalhe
Data Builder / Neural
Sistema
FFinancing
Sistema
PPerdas
Integração Totvscard - PPerdas
Em Execução
Em Planejamento
Não Iniciada
Tombamento IQ
Arquivos Risco
Near Real Time Loading (Oracle Golden Gate)
Frente 2 - Criação dos indicadores, projeto executado em paralelo e independente das origens
Extract/Transform/Load
Consolidado ODS
DW / DM
Light (Indicadores)
Captação
Ativação
Produtos (Indicador Produção)
Proposta e Análise
HTC Indicadores
Indicadores Produção
Indicadores Risco
Indicadores Cliente
Indicadores Análise
HTC Relatórios Dashboards
Produto, Subproduto
Loja, Regional, Coordenadores de PF
Dia, Mês, Ano, Ano Anterior
Colaborador
Cliente
Meta Forecast e Budget
Geográfica
* Indicadores que envolve a contabilidade não está previsto no projeto
MIS Cobrança
* Após a terceirização ter um documento de MIS de Cobrança para realização de estimativa.
 Funcionamento das Stages (CRE e TOTVSCARD)
CRE
TOTVS
CARD
ODS
EXADATA X5
STAGE
GoldenGate 12c
GoldenGate 12c
ODI 12c
DW
ODI 12c
Microstrategy
DW08 (OLTP)
DW11 (OLAP)
Comportamento dos dados nos fluxo dos Dados - Integrações
Stage
Carga full efetuda pelo GoldenGate e após a replicação online dos dados. As tabelas terão a mesma estrutura da tabela na origem e mais 3 campos.
	DT_GG_REP: Data que o GG replicou o dado
	USER_OPER: Usuário que fez a alteração na origem
	TP_GG_OPER: Operação que o dado sofreu na origem (Insert, Update, Delete)
Comportamento dos dados nos fluxo dos Dados - Integrações
ODS
Comportamento SCD nas cargas ODI, ou seja, as cargas terão versionamento de registros com os campos:
	FL_REG_ATIVO: Status do registro. Ativo(S) ou Inativo(N)
	DT_INICIO_VIGENCIA: Data que iniciou a vigência do registro
	DT_FIM_VIGENCIA: Data que o registro deixou de ser ativo
	ID_CARGA: Sessão do ODI
DW
Comportamento normal de dados. Se a informação alterou o dado é atualizado no DW.
Parametrização e jornalização padrão de cargas
As cargas ODI do projeto HTC, tem como padrão a jornalização por data, ou seja, para controlar o que foi atualizado na origem, buscamos por um determinado período de data, previamente parametrizado em uma tabela de banco de dados.
Para as cargas HTC , é utilizada a tabela PARAM_INTG no schema ODI_AUX dentro banco de dados DW08.
Parametrização e jornalização padrão de cargas
Os parâmetros mais utilizados pelas cargas são:
DATA_INI_ETL – Deve gravar um valor TIMESTAMP indicando a próxima data de inicio da carga.
DATA_FIM_ETL – Deve gravar um valor TIMESTAMP indicando a última inicialização da carga anterior.
DIAS_RETROATIVOS – Indica o número de dias de margem de segurança a carga vai busca retroativamente.
Parametrização e jornalização padrão de cargas
Detalhamento de um fluxo ODI simples utilizando parametrização.
Parametrização e jornalização padrão de cargas
viDT_INI_ETL
Modulo será o nome do projeto ODI Nome do Fluxo será buscado dinamicamente utilizando a API do ODI.
Parametrização e jornalização padrão de cargas
prATUALIZA_DT_FIM
Esta procedure define a data (current_timestamp) que está sendo iniciada a carga. É executada sempre após o refresh da data inicial.
Parametrização e jornalização padrão de cargas
viDT_FIM_ETL
Busca a data/hora setada na procedure anterior
Parametrização e jornalização padrão de cargas
viDIAS_RETROATIVOS
Busca o número de dias retroativos de margem de segurança
Parametrização e jornalização padrão de cargas
Execução do Mapping
Utiliza os parâmetros instânciados anteriormente para filtrar a data que o Golden Gate replicou o dado na STAGE
Parametrização e jornalização padrão de cargas
prATUALIZA_DATA_INI
Atualiza o parâmetro da data inicial da próxima carga, sempre subtraindo os dias retroativos gravado na variável anteriormente.
Execução de cargas por Lote
Cargas que carregam grandes volumes de dados, podem ser “quebradas” por lotes, normalmente por Loja ou Período.
Execução de cargas por Lote
viLIMITE_LOTE
Busca o parâmetro que indica qual o número máximo registros pode ser carregado em um único lote.
Execução de cargas por Lote
viQTD_LOAD_%
Busca na tabela de destino, a quantidade de registros que deve ser carregado para o período.
Execução de cargas por Lote
Avaliação da quantiade de registros
Execução de cargas por Lote
Divisão por Loja
1 - Cria uma tabela temporária com as lojas disponiveis
2 – A cada “loop” exclui a loja da tamporária até não exisitr mais registros
3 – Exclui a tabela temporária
Troubleshooting
Erros comuns:
Problema: Parâmetro não registrado na tabela ODI_AUX.PARAM_INTG
Correção: Cadastrar o parâmetro corretamente na tabela.
Problema: Cargas que estouram a tablespace UNDO ou que retornam erro "snapshot too old".
Correção: Volume de carga está muito alto, deve ser avaliado a execução por lote.
Problema: Em procedures ou filtros, as tabelas referenciadas podem estar sem a função "getSchema" do ODI
Correção: Colocar a função “getSchema” apontando para o owner correto.
Troubleshooting
Pontos de atenção
Existem cargas que possuem cenários de mappings e procedures, e estes devem ser enviados no PL para subida.
As tabelas temporarias não devem ser dropadas. Verificar IKM e LKM e marcar false na option de “delete temporary objects”.
Marcar no modelo físico para gerar nomes de objetos randomicos, evitando assim, uma carga dropar objetos de outra.
Setar o alias do dataset/tabela no uIKM SCD customizado, devido ao filtro != ‘DELETE’ utilizado pelo mesmo.
Fim
FIM 
Leonardo Moura 19/11/2014