TABLE | MAP

Válido Para

TABLE é válido para a Extração. Você só pode usar TABLE com Replicat com o parâmetro EVENTACTIONS. MAP é válido para Extract em determinadas situações e Replicat. Consulte MAP para Extract para obter detalhes.

Descrição

Os parâmetros TABLE e MAP controlam a seleção, o mapeamento e a manipulação dos objetos que serão afetados por um processo do Oracle GoldenGate. Esses parâmetros funcionam da seguinte forma:

TABLE e MAP são válidos para configurações de carga inicial e para processos on-line configurados para suportar a replicação de alterações transacionais.

Você pode processar os seguintes objetos com TABLE e MAP:

Para especificar uma sequência para captura pelo Extract, use o parâmetro SEQUENCE.

Observação: O Oracle GoldenGate suporta a replicação de valores de dados reais de views materializadas da Oracle.

Você pode usar uma ou mais instruções TABLE ou MAP em um arquivo de parâmetros, com ou sem curingas, para especificar todos os objetos que deseja processar.

Você pode excluir objetos de uma instrução TABLE ou MAP com caracteres curinga com os seguintes parâmetros:

Padrão

Nenhum

Sintaxe para TABLE

Para tabelas, você pode usar todas as opções do TABLE. Para objetos que não sejam de tabela, use TABLE somente para especificar um objeto para captura.

TABLE <source_table>[, TARGET <target_table>]
[, ATTRCHARSET (<charset>)]
[, CHARSET <character_set>]
[, COLCHARSET <character_set>]
[, COLMAP (<column_mapping>)]
[, {COLS | COLSEXCEPT} (<column_list>)]
[, {DEF | TARGETDEF} <template>]
[, EVENTACTIONS <action>]
[, EXITPARAM '<parameter>']
[, {FETCHCOLS | FETCHCOLSEXCEPT} (<column_list>)]
[, {FETCHMODCOLS | FETCHMODCOLSEXCEPT} (<column_list>)]
[, FETCHBEFOREFILTER]
[, FILTER (<filter_clause>)]
[, GETBEFORECOLS (<column_specification>)]
[, KEYCOLS (<columns>)]
[, SQLEXEC (<SQL_specification>)]
[, SQLPREDICATE 'WHERE <where_clause>']
[, TOKENS (<token_definition>)]
[, TRIMSPACES | NOTRIMSPACES]
[, TRIMVARSPACES | NOTRIMVARSPACES]
[, WHERE (<clause>)]
[, <container>.]<schema.table> PARTITIONOBJID <ptn_object_ID> [, <ptn_object_ID>]
;

Sintaxe para MAP

MAP <source_table>, TARGET <target_table>
[, MOD_COMPARE_COLS( <tgt_col> = <source> )]
[, COLMAP (<column_mapping>)]
[, COMPARECOLS (<column_specification>)]
[, COORDINATED]
[, {DEF | TARGETDEF} <template>]
[, EXCEPTIONSONLY]
[, EXITPARAM '<parameter>']
[, EVENTACTIONS (<action>)]
[, FILTER (<filter_clause>)]
[, HANDLECOLLISIONS | NOHANDLECOLLISIONS]
[, INSERTALLRECORDS]
[, INSERTAPPEND | NOINSERTAPPEND]
[, KEYCOLS (<columns>)]
[, MAPALLCOLUMNS | NOMAPALLCOLUMNS]
[, MAPEXCEPTION (<exceptions_mapping>)]
[, MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS]
[, REPERROR (<error>, <response>)]
[, RESOLVECONFLICT (<conflict_resolution_specification>)]
[, SQLEXEC (<SQL_specification>)]
[, THREAD (<thread_ID>)]
[, THREADRANGE (<thread_range>[, <column_list>])]
[, TRIMSPACES | NOTRIMSPACES]
[, TRIMVARSPACES | NOTRIMVARSPACES]
[, WHERE (<clause>)]
[, <container>.]<schema.table> PARTITIONOBJID <ptn_object_ID> [, <ptn_object_ID>]
;

Opções TABLE e MAP

A tabela a seguir resume as opções disponíveis para os parâmetros TABLE e MAP. Observe que nem todas as opções são válidas para ambos os parâmetros.

Sumário dos Componentes de Sintaxe TABLE e MAP da Tabela 11

Componente Descrição Válido Para
MAP MOD_COMPARE_COL( tgt_col = source [,...] ) Este é um parâmetro somente Replicat. Designa o valor de origem especificado à imagem anterior da coluna de destino como valor de chave, e o valor é usado para a cláusula WHERE. MAP
TABLE <source_table>[, TARGET <target>] Especifica o objeto de origem em uma instrução TABLE para Extract e um mapeamento opcional para um objeto de destino. Use no arquivo de parâmetros Extract. TABLE
MAP source_table, TARGET target_table Especifica o mapeamento do objeto de origem-destino para o processo Replicat. Usar no arquivo de parâmetros Replicat. MAP
ATTRCHARSET (charset) especifica as informações do conjunto de caracteres de origem no nível do atributo UDT. TABLE
COLCHARSET character_set Especifica qualquer conjunto de caracteres suportado. TABLE
COLMAP (column_mapping) Mapeia registros entre diferentes colunas de origem e destino. TABLE e MAP
{COLS \| COLSEXCEPT} (column_list) Seleciona ou exclui colunas para processamento. TABLE
COMPARECOLS (column_specification) Especifica colunas a serem usadas para detecção e resolução de conflitos. TABLE e MAP
COORDINATED Força uma transação a ser processada como uma transação de barreira. MAP
{DEF | TARGETDEF} template Especifica um modelo de definição de origem ou de definição de destino. TABLE e MAP
EXCEPTIONSONLY Especifica que a instrução MAP é uma instrução MAP de exceções. MAP
EVENTACTIONS (action) Aciona uma ação com base em um registro que satisfaz uma regra de filtro especificada. TABLE e MAP
EXITPARAM 'parameter' Passa um parâmetro na forma de uma string literal para uma saída de usuário. TABLE e MAP
FETCHBEFOREFILTER Direciona a ação FETCHCOLS ou FETCHCOLSEXCEPT a ser executada antes da execução de um filtro. TABLE
{FETCHCOLS | FETCHCOLSEXCEPT} (column_list) Permite a extração de valores de coluna do banco de dados de origem quando os valores não estão no registro da transação. TABLE
{FETCHMODCOLS | FETCHMODCOLSEXCEPT} (column_list) Força valores de coluna a serem extraídos do banco de dados quando as colunas estiverem presentes no log de transações. TABLE
FILTER (filter_clause) Seleciona registros com base em um valor numérico. O FILTER oferece mais flexibilidade que o WHERE. TABLE e MAP
GETBEFORECOLS (column_specification) Força antes de imagens de colunas a serem capturadas e gravadas na trilha. TABLE
HANDLECOLLISIONS \| NOHANDLECOLLISIONS Reconcilia os resultados das alterações feitas na tabela de destino por um processo de carregamento inicial com os aplicados por um grupo de sincronização de alterações. MAP
INSERTALLRECORDS Aplica todas as alterações de linha como inserções. MAP
INSERTAPPEND \| NOINSERTAPPEND Controla se o Replicat usa ou não uma dica do Oracle APPEND para instruções INSERT. MAP
KEYCOLS (columns) Designa colunas que identificam linhas de forma exclusiva. TABLE e MAP
MAPALLCOLUMNS | NOMAPALLCOLUMNS Controla se o Replicat obtém ou não colunas que não são de chave. NA
MAPEXCEPTION (exceptions_mapping) Especifica que a instrução MAP contém tratamento de exceções para tabelas com curingas. MAP
MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS Controla se o Replicat inclui ou não colunas invisíveis nas tabelas de destino da Oracle para mapeamento de coluna padrão. Para colunas invisíveis nas tabelas de destino da Oracle que usam mapeamento de coluna explícito, elas são sempre mapeadas, portanto, não exija essa opção. MAP
REPERROR (error, response) Controla como o Replicat responde a erros ao executar a instrução MAP. MAP
RESOLVECONFLICT (conflict_resolution_specification) Especifica regras para resolução de conflitos. MAP
SQLEXEC (SQL_specification) Executa consultas e procedures armazenados. TABLE e MAP
SQLPREDICATE 'WHERE where_clause' Permite que uma cláusula WHERE selecione linhas para uma carga inicial. TABLE
THREAD (thread_ID) Válido para Replicat no modo coordenado. Especifica que a instrução MAP será processada pelo thread de Replicat especificado. MAP
THREADRANGE (thread_range, column_list) Válido para Replicat no modo coordenado. Especifica que a instrução MAP será processada pelo intervalo especificado de threads de Replicat. MAP
TOKENS (token_definition) Define tokens de usuário. TABLE
TRIMSPACES \| NOTRIMSPACES Controla se os espaços finais são reduzidos ou não ao mapear colunas CHAR para VARCHAR. TABLE e MAP
TRIMVARSPACES \| NOTRIMVARSPACES Controla se os espaços finais são reduzidos ou não ao mapear VARCHAR para colunas CHAR ou VARCHAR. TABLE e MAP
WHERE (clause) Seleciona registros com base em operadores condicionais. TABLE e MAP
; (Semicolon) Finaliza a instrução TABLE ou MAP e é obrigatória. TABLE e MAP
PARTITIONOBJID Disponível para Extração Integrada. Esta opção é usada para especificar os IDs de objeto das partições a serem capturadas para tabelas particionadas. TABLE e MAP

MAP MOD_COMPARE_COL( tgt_col = fonte [,…] )

tgt_col deve ser o nome da coluna da tabela de destino e deve ser a coluna chave a ser efetivada corretamente. source pode ser a coluna da tabela de origem, o valor da constante (número ou string), a função de mapeamento da coluna ou os resultados de SQLEXEC. Por exemplo, source col1 é mapeado para target col 1. source col1 antes que o valor da imagem seja 1, que é um valor fictício porque é mascarado pelo DBA para segurança. O Replicat pode consultar o valor real antes do valor da imagem target col1 por SQLEXEC. Usando MOD_COMPARE_COLS(), o Replicat substitui o valor fictício source col1 pelo resultado SQLEXEC, para que a operação UPDATE ou DELETE funcione corretamente.

TABLE <source_table>[, TARGET <target>]

TABLE é válido em um arquivo de parâmetros do Extract.

Use TABLE para especificar um objeto de origem para o qual você deseja que o Extract capture dados. Especifique o nome de duas ou três partes totalmente qualificado do objeto, como <schema.table> ou <catalog.schema.table>. Você pode usar um curinga para especificar vários objetos com uma instrução TABLE. Para especificar nomes de objetos e curingas corretamente, consulte Usando Curingas em Nomes de Objetos de Banco de Dados e Usando Curingas em Argumentos de Comando na Documentação de Microsserviços do Oracle GoldenGate.

Use a opção TARGET somente quando o Extract precisar fazer referência a um arquivo de definições de destino (especificado com o parâmetro TARGETDEFS) para executar conversões ou quando a opção COLMAP for usada para mapear colunas. Caso contrário, ele poderá ser omitido de um parâmetro TABLE. O mapeamento de colunas com COLMAP e o trabalho de conversão geralmente são executados no sistema de destino para minimizar o impacto das atividades de replicação no sistema de origem, mas podem ser executados no sistema de origem, se necessário. Por exemplo, o mapeamento e a conversão de colunas podem ser executados no sistema de origem em uma configuração em que há várias origens e um destino. Neste cenário, pode ser mais fácil gerenciar um arquivo de definições de destino em vez de gerenciar um arquivo de definições para cada banco de dados de origem, especialmente se houver alterações frequentes no aplicativo que exigem a geração de novos arquivos de definições.

O uso de TARGET em um parâmetro TABLE identifica os metadados dos dados extraídos com base na estrutura de destino, e não na da origem, para refletir a estrutura do registro que é refletida no arquivo de definições ou no mapa de colunas. Não use nomes de três partes se TARGET especificar tabelas em um banco de dados contêiner Oracle de destino. O Replicat só pode se conectar a um contêiner ou catálogo, portanto, presume-se que o contêiner ou a parte do catálogo do nome seja igual ao que o Replicat faz log-in (conforme especificado com USERIDALIAS, dependendo do banco de dados).

Se nenhuma outra opção de sintaxe TABLE for necessária para processar os dados de origem especificados, você poderá usar uma instrução TABLE simples, certificando-se de encerrá-la com um ponto e vírgula.

 TABLE sales.customers;

Veja a seguir o uso de um curinga para especificar várias tabelas:

 TABLE sales.*;

As instruções TABLE anteriores direcionam o processo Extract para capturar todos os dados de coluna suportados para os objetos especificados e gravá-los na trilha sem executar qualquer filtragem, conversão ou outra manipulação.

MAP <source_table>, TARGET <target_table>

MAP é válido em um arquivo de parâmetros de Replicat. Você também pode usar MAP em um arquivo de parâmetros Extract para alterar o nome das transações que o Oracle GoldenGate armazena para a tabela. Consulte

Use MAP para especificar um objeto de origem e TARGET para especificar o objeto de destino ao qual o Replicat aplica os dados de origem replicados. Juntos, as cláusulas MAP e TARGET compreendem um mapeamento.

A seguir, é mostrado o uso de um curinga para especificar várias tabelas. Observe que a cláusula TARGET não inclui o prefixo tab antes do caractere curinga. Essa especificação seria inválida porque o caractere curinga seria resolvido como sales.tabtab1, sales.tabtab2 e assim por diante.

 MAP sales.tab*, TARGET sales.*;

Se nenhum filtro, mapeamento ou outro trabalho for necessário para os objetos, você poderá usar instruções MAP simples como as seguintes, certificando-se de encerrar cada uma com um ponto e vírgula.

MAP sales.customers, TARGET sales.customers;
MAP fin.*, TARGET fin.*;

ATTRCHARSET <(charset)>

ATTRCHARSET é válido para TABLE.

Use a cláusula ATTRCHARSET para especificar as informações do conjunto de caracteres de origem no nível do atributo UDT. Ele substitui o conjunto de caracteres definido no arquivo de trilha ou especificado pelos parâmetros SOURCECHARSET, CHARSET ou COLCHARSET.

Os valores válidos são nomes de conjuntos de caracteres e nomes de atributos UDT válidos. Nomes de atributo curinga são suportados. Por exemplo:

TABLE SCHEMA.T*,
  ATTRCHARSET(WE8DEC, col*.attr1, col1.attr*.attr3);

COLCHARSET <character_set>

COLCHARSET é válido para TABLE.

Use a cláusula COLCHARSET para especificar qualquer conjunto de caracteres suportado. Consulte COLCHARSET para mais informações.

COLMAP <(column_mapping)>

O COLMAP é válido para TABLE e MAP.

Use COLMAP para:

COLMAP fornece instruções para selecionar, converter e mover dados da coluna de uma coluna de origem para uma coluna de destino. Observação: Para criar regras globais para mapeamento de colunas em todas as tabelas em instruções MAP subsequentes, use o parâmetro COLMATCH.

Obtendo Mais Informações sobre a Configuração do Mapeamento de Colunas

Para usar o COLMAP, as diretrizes de configuração relacionadas devem ser levadas em consideração, como se as estruturas de coluna de origem e de destino são idênticas ou diferentes e se os parâmetros de mapeamento de coluna global podem ser suficientes.

Sintaxe

COLMAP (
[USEDEFAULTS, ]
<target_column> = <source_expression> [BINARYINPUT]
[, ...]
)

USEDEFAULTS

Mapeia automaticamente colunas de origem e de destino que tenham o mesmo nome se não tiverem sido especificadas em um mapeamento de coluna explícito. Os tipos de dados são traduzidos automaticamente, conforme necessário, com base no arquivo de definições de dados local. USEDEFAULTS elimina a necessidade de um mapeamento de coluna explícito se essas colunas tiverem o mesmo nome e os dados não exigirem qualquer filtragem ou conversão.

Especifique USEDEFAULTS antes de mapeamentos de coluna explícitos na cláusula COLMAP.

<target_column = source_expression>

Define um mapeamento de coluna de origem-destino explícito.

<target_column>

Especifica o nome da coluna de destino. Para caracteres suportados em nomes de coluna, consulte Conjuntos de Caracteres Suportados.

<source_expression>

Pode ser qualquer uma das seguintes:

BINARYINPUT

Use BINARYINPUT quando a coluna de destino for definida como um tipo de dados binário, como RAW ou BLOB, mas a entrada de origem contiver zeros binários no meio dos dados. A entrada de origem é tratada como entrada binária e a substituição de valores de dados é suprimida.

Exemplo 1

MAP ggs.tran, TARGET ggs.tran2, COLMAP (loc2 = loc, type2 = type);

Exemplo 2

TABLE ggs.tran, COLMAP (SECTION = @STRCAT('\u00a7', SECTION ));

{COLS | COLSEXCEPT} (<column_list>)

As opções COLS e COLSEXCEPT são válidas para TABLE.

Use COLS e COLSEXCEPT para controlar as colunas para as quais os dados são capturados.

Para usar o COLS, é necessário o seguinte:

Sem uma chave primária, uma chave exclusiva ou uma cláusula KEYCOLS na instrução TABLE, o Oracle GoldenGate usa todas as colunas da tabela, tornando COLS desnecessário.

Observação: Não use esta opção para tabelas que são processadas no modo de passagem por um grupo Extract de data-pump.

Sintaxe

{COLS | COLSEXCEPT} (<column> [, ...])

<column>

O nome de uma coluna. Para especificar várias <columns>, crie uma lista delimitada por vírgulas, por exemplo:

COLS (name, city, state, phone)

Observação: Se o banco de dados registrar apenas valores de colunas que foram alteradas em uma operação de atualização, uma coluna especificada para captura com COLS poderá não estar disponível. Para disponibilizar essas colunas, use a opção FETCHCOLS na instrução TABLE ou ative o registro em log complementar para a coluna.

Exemplo

O COLS <clause> neste exemplo captura somente <columns> 1 e 3, enquanto o COLSEXCEPT <clause> captura todos os <columns>, exceto <columns> 1 e 3.

TABLE hq.acct, COLS (col1, col3);
TABLE hq.sales, COLSEXCEPT (col1, col3);

COMPARECOLS (<column_specification>)

COMPARECOLS é válido para MAP.

Use COMPARECOLS para especificar as colunas que o Replicat usa para detectar e resolver conflitos de atualização ou exclusão quando configurado com a opção RESOLVECONFLICT de MAP em uma configuração multimestre. Conflito é uma incompatibilidade entre a imagem anterior de um registro na trilha e os dados apropriados na tabela de destino.

Para usar COMPARECOLS, a imagem anterior deve estar disponível no registro de trilha por meio do parâmetro GETBEFORECOLS na instrução Extract TABLE. As colunas especificadas devem existir no banco de dados de destino e também fazer parte da configuração do Replicat (satisfaça a especificação TARGET com ou sem uma cláusula COLMAP).

Somente tipos de dados escalares são suportados pelo COMPARECOLS como colunas de comparação. Um tipo de dados escalar pode ser usado em uma cláusula WHERE, tem um único valor atômico e nenhum componente interno. Os tipos de dados escalares suportados pelo Oracle GoldenGate incluem o seguinte, mas não LOBs.

Alguns exemplos de tipos de dados não escalares são dados espaciais, tipos de dados definidos pelo usuário, objetos grandes (LOB), XML, tipos de dados de referência e RAW. Uma linha que está sendo considerada para CDR pode incluir dados não escalares, desde que o conflito não esteja nos próprios dados não escalares.

Para especificar rotinas de resolução de conflitos, use a opção RESOLVECONFLICT de MAP. As opções COMPARECOLS e RESOLVECONFLICT podem estar em qualquer ordem na instrução MAP.

Obter mais informações sobre como configurar o recurso CDR

Consulte Detecção e Resolução Automática de Conflitos ou Detecção e Resolução Manuais de Conflitos para obter mais informações sobre como configurar a detecção e a resolução de conflitos.

Sintaxe

COMPARECOLS(
{ON UPDATE | ON DELETE}
{ALL | KEY | KEYINCLUDING (<col>[,...]) | ALLEXCLUDING (<col>[,...]) }
[,...]
)
{ON UPDATE ON DELETE}

Especifica se a imagem anterior das colunas especificadas deve ser comparada para atualizações ou exclusões. Você pode usar somente ON UPDATE, somente ON DELETE ou ambos. Se estiver usando ambos, especifique-os dentro da mesma cláusula COMPARECOLS. Consulte o exemplo de como utilizar ambas as versões.

{ALL | KEY | KEYINCLUDING (<col>[,...]) | ALLEXCLUDING (<col>[,...])}

Especifica as colunas para as quais uma imagem anterior é capturada.

ALL

Compara o uso de todas as colunas na tabela de destino. Um erro será gerado se qualquer imagem correspondente antes não estiver disponível na trilha. O uso de ALL impõe a carga de processamento mais alta para Replicat, mas permite que comparações de detecção de conflito sejam executadas usando todas as colunas para obter a precisão máxima.

KEY

compara somente as colunas de chave primária. Esta é a opção mais rápida, mas não permite a detecção de conflito mais precisa, porque as chaves podem corresponder, mas as colunas não-chave podem ser diferentes.

KEYINCLUDING

Compara as colunas de chave primária e a coluna ou colunas especificadas. Este é um compromisso razoável entre velocidade e precisão de detecção.

ALLEXCLUDING

Compara todas as colunas, exceto as especificadas. Para tabelas com várias colunas, ALLEXCLUDING pode ser mais eficiente que KEYINCLUDING. Não exclua colunas-chave.

Exemplo 1

No exemplo a seguir, as colunas de chave mais as colunas name, address e salary são comparadas em caso de conflitos.

MAP src, TARGET tgt
COMPARECOLS (
ON UPDATE KEYINCLUDING (name, address, salary),
ON DELETE KEYINCLUDING (name, address, salary));

Exemplo 2

No exemplo a seguir, a coluna comment é ignorada e todas as outras colunas são comparadas para conflitos.

MAP src, TARGET tgt
COMPARECOLS (ON UPDATE ALLEXCLUDING (comment))

COORDENADO

COORDINATED é válido para MAP. Esta opção é válida quando o Replicat está no modo coordenado.

Use a opção COORDINATED para forçar transações feitas em objetos no mesmo demonstrativo MAP a serem processadas como transações de barreira. Ela faz com que todos os threads entre todas as instruções MAP sejam sincronizados com o mesmo local de trilha. A posição sincronizada é o início da transação que contém um registro que satisfaz a um MAP que contém a palavra-chave COORDINATED. A transação é então aplicada atomicamente por um único thread, que é o thread com o thread mais baixo ID entre os threads em execução no momento ou um thread dedicado com o ID de 0 se USEDEDICATEDCOORDINATIONTHREAD for especificado no arquivo de parâmetros.

As cláusulas THREAD e THREADRANGE especificadas em conjunto com COORDINATED são ignoradas porque o registro não será aplicado pelo(s) thread(s) designado(s). A palavra-chave COORDINATED resulta na suspensão temporária do paralelismo para que as tabelas de destino fiquem em um estado consistente antes da aplicação da transação coordenada à força. Após este ponto, a execução paralela começa novamente.

O processo Replicat por padrão coordena transações em que a chave primária é atualizada, transações que executam DDL e determinadas ações EVENTACTIONS. COORDINATED prevê coordenação explícita.

Consulte Sobre a Replicação Coordenada para obter mais informações.

Sintaxe

COORDINATED

Exemplo

Veja a seguir um exemplo do uso da opção COORDINATED. Neste exemplo, as regras de negócios exigem que as tabelas de destino estejam em um estado consistente antes que o Replicat execute transações que incluam operações SQLEXEC nos objetos especificados na instrução MAP. Nesse caso, o paralelismo deve ser convertido temporariamente para o processamento de SQL serial.

Considerando a instrução MAP a seguir, se outro thread inserir em t2 um registro com o valor 100 para col_val antes de a inserção em t1 ser executada pelo thread 1, o SQLEXEC excluirá a linha. Se outros threads ainda estiverem processando o registro com o valor 100, o SQLEXEC falhará. Os resultados dessa instrução MAP não são, portanto, previsíveis.

MAP u1.t1, TARGET u2.t1 SQLEXEC (ID test2, QUERY ' delete from u2.t2 where col_val =100 ', NOPARAMS)), THREAD(1);

Por outro lado, quando COORDINATED é usado, todos os threads são sincronizados em um ponto comum, incluindo aquele que processa o registro col_val=100, removendo assim a ambiguidade dos resultados.

MAP u1.t1, TARGET u2.t1 SQLEXEC (ID test2, QUERY ' delete from u2.t2 where col_val =100 ', NOPARAMS)), THREAD(1), COORDINATED;

{DEF| TARGETDEF}<template>

As opções DEF e TARGETDEF são válidas para TABLE e MAP.

Use DEF e TARGETDEF para especificar o nome de um modelo de definições que foi criado pelo utilitário DEFGEN.

Um modelo é baseado nas definições de uma tabela específica. Ele permite que novas tabelas que têm as mesmas definições da tabela original sejam adicionadas à configuração do Oracle GoldenGate sem executar DEFGEN para elas e sem precisar interromper e iniciar o processo do Oracle GoldenGate. As definições no modelo são usadas para pesquisas de definições.

Sintaxe

{DEF | TARGETDEF} <template>

<template>

O nome de um dos seguintes modelos de definições gerados pelo utilitário DEFGEN:

As definições contidas no modelo devem ser idênticas às definições da tabela ou tabelas especificadas na mesma instrução TABLE ou MAP.

A distinção entre maiúsculas e minúsculas do nome do modelo é observada quando o nome é especificado da mesma forma que é armazenado no banco de dados. Certifique-se de que o nome do modelo seja especificado da mesma forma na cláusula DEF ou TARGETDEF nesta instrução TABLE ou MAP e no arquivo de parâmetros DEFGEN que criou o modelo.

Exemplo 1

Este exemplo mostra um nome de modelo sem distinção entre maiúsculas e minúsculas.

MAP acct.cust*, TARGET acct.cust*, DEF custdef;

Exemplo 2

Este exemplo mostra um nome de modelo com distinção entre maiúsculas e minúsculas quando o banco de dados requer aspas para impor a distinção entre maiúsculas e minúsculas.

  TABLE acct.cust*, DEF "CustDef";

Exemplo 3

Este exemplo mostra um caso em que DEF e TARGETDEF são usados.

  MAP acct.cust*, TARGET acc.cust*, DEF custdef, TARGETDEF tcustdef;

SOMENTE EXCEÇÕES

EXCEPTIONSONLY é válido para MAP.

Use EXCEPTIONSONLY em uma instrução MAP de exceções destinada ao tratamento de erros. A instrução MAP de exceções deve seguir a instrução MAP para a qual os erros são antecipados. A instrução MAP de exceções só será executada se ocorrer um erro para o último registro processado na instrução MAP regular anterior.

Para usar EXCEPTIONSONLY, use uma instrução REPERROR com a opção EXCEPTION na instrução MAP regular ou na raiz do arquivo de parâmetros. Consulte REPERROR para mais informações. Observação: Se você estiver usando o recurso CDR (Conflict Detection and Resolution) do Oracle GoldenGate, não será necessário um REPERROR com EXCEPTION. O CDR envia automaticamente todas as operações que causam erros para a instrução MAP de exceções.

A instrução MAP de exceções deve especificar a mesma tabela de origem que a instrução MAP regular, mas a tabela de destino na instrução MAP de exceções deve ser uma tabela de exceções.

Observação: Consulte "MAPEXCEPTION (exceptions_mapping)" para suportar nomes de objetos com caracteres curinga.

Sintaxe

EXCEPTIONSONLY

EVENTACTIONS (<action>)

O EVENTACTIONS é válido para TABLE e MAP. Algumas opções se aplicam apenas a um ou outro parâmetro e são anotadas como tal nas descrições.

Use EVENTACTIONS para fazer com que o processo execute uma ação definida com base em um registro na trilha, conhecido como registro de evento, que se qualifica para uma regra de filtro específica. Você pode usar esse sistema, conhecido como sistema de marcador de eventos (ou infraestrutura de marcador de eventos) para personalizar o processamento com base em eventos de banco de dados. Por exemplo, você pode suspender um processo para executar uma transformação ou reportar estatísticas. O recurso de marcador de evento é suportado para a replicação de alterações de dados, mas não para cargas iniciais.

Para acionar ações que não exigem que os dados sejam aplicados às tabelas de destino, você pode usar o parâmetro Replicat TABLE com opções de filtragem que suportam EVENTACTIONS. Consulte "TABLE para Replicat" para obter mais informações.

Você pode precisar combinar duas ou mais ações para atingir seus objetivos. Quando várias ações são combinadas, a instrução EVENTACTIONS inteira é analisada primeiro e, em seguida, as opções especificadas são executadas em ordem de precedência. A lista a seguir mostra a ordem de precedência. As ações listadas antes de Process the record ocorrerem antes do registro ser gravado na trilha ou aplicado ao destino (dependendo do processo). As ações listadas após Process the record são executadas após o processamento do registro.

Para evitar que o próprio registro de evento seja processado da maneira normal, use a opção IGNORE ou DISCARD. Como IGNORE e DISCARD são avaliados antes do próprio registro, eles impedem o processamento do registro. Sem essas opções, o EVENTACTIONS para Extract grava o registro na trilha e o EVENTACTIONS para Replicat aplica essa operação ao banco de dados de destino.

Você deve levar em conta a possibilidade de que uma transação possa conter dois ou mais registros que acionam uma ação de evento. Nesse caso, pode haver várias execuções de determinadas especificações do EVENTACTIONS. Por exemplo, encontrar dois registros de qualificação que acionem duas ações ROLLOVER sucessivas fará com que o Extract percorra a trilha duas vezes, deixando um dos dois arquivos vazio dos dados da transação.

Você também deve levar em conta que, quando o parâmetro GETUPDATEBEFORES estiver em vigor, dois registros serão gerados para operações UPDATE: um registro que contenha a imagem anterior e um registro que contenha a imagem posterior. Uma ação de evento é acionada para cada um desses registros quando a operação se qualifica como um registro de evento. Você pode usar o token BEFOREAFTERINDICATOR da função de conversão de coluna GGHEADER como um filtro em uma cláusula FILTER para qualificar os registros de modo que a ação do evento seja acionada apenas uma vez, no registro anterior ou posterior, mas não em ambos.

Os filtros de exemplo a seguir no indicador BEFORE. O EVENTACTION emite o comando shell ECHO para gerar a string 'Triggered on BEFORE' para o log de eventos quando um registro BEFORE é encontrado.

TABLE qasource.test, &
FILTER(@STRFIND('BEFORE', @GETENV('GGHEADER' , 'BEFOREAFTERINDICATOR')) > 0), &
EVENTACTIONS ( shell ('echo --== Triggered on BEFORE ==-- '), LOG);

O seguinte mostra o resultado do evento <action>:

013-03-06 17:59:31  INFO    OGG-05301  Shell command output: '--== Triggered
on AFTER ==--'

O exemplo a seguir faz a mesma coisa, mas para o indicador AFTER.

 TABLE qasource.test, &
 FILTER(@STRFIND('AFTER', @GETENV('GGHEADER' , 'BEFOREAFTERINDICATOR')) > 0), &
 EVENTACTIONS ( shell ('echo --== Triggered on AFTER ==-- '), LOG);

Sintaxe

EVENTACTIONS (
[STOP | SUSPEND | ABORT | FORCESTOP]
[IGNORE [RECORD | TRANSACTION [INCLUDEVENT]]
[DISCARD]
[LOG [INFO | WARNING]]
[REPORT]
[ROLLOVER]
[SHELL '<command>' | SHELL ('<command>', VAR <variable> = {<column_name> | <expression>}
  [, ...]) ]
[TRACE[2] <file> [TRANSACTION] [DDL[INCLUDE] | DDLONLY] [PURGE | APPEND]]
[CHECKPOINT [BEFORE | AFTER | BOTH]]
[, ...]
)

STOP

Válido em TABLE para Extract e em MAP para Replicat.

Traz o processo para uma interrupção normal quando o registro de evento especificado é encontrado. O processo aguarda que outras operações dentro da transação de evento sejam concluídas antes da interrupção. Se a transação for uma transação agrupada ou em batch do Replicat, o grupo atual de transações será aplicado antes de o processo ser interrompido normalmente. O processo é reiniciado no próximo registro após o registro do evento, desde que esse registro também signifique o fim de uma transação.

O processo registra uma mensagem se não puder ser interrompido imediatamente porque uma transação ainda está aberta. No entanto, se o registro de evento for encontrado em uma transação aberta de longa execução, não haverá mensagem de aviso que avise o estado não confirmado da transação. Portanto, o processo pode permanecer em execução por um longo tempo, apesar do evento STOP.

STOP pode ser combinado com outras opções do EVENTACTIONS, exceto ABORT e FORCESTOP.

SUSPEND

Válido em TABLE para Extract e em MAP para Replicat.

Pausa o processo para que ele retenha o contexto ativo da execução atual e ainda possa responder aos comandos SEND que são emitidos no Admin Client. Quando um processo é suspenso, o comando INFO o mostra como RUNNING e o campo RBA mostra a última posição do checkpoint.

Para retomar o processamento, execute o comando SEND com a opção RESUME.

Para utilizar a opção CHECKPOINT BEFORE em conjunto com SUSPEND, o registro de evento deve ser o início de uma transação para que o SUSPEND ocorra. Dessa forma, se o processo for eliminado enquanto estiver no estado suspenso, o registro de evento com a ação SUSPEND será o primeiro registro a ser reprocessado na reinicialização. Se CHECKPOINT BERORE e SUSPEND forem especificados, mas o registro de evento não for o início de uma transação, o processo será interrompido antes que SUSPEND possa ocorrer.

Para usar a opção CHECKPOINT AFTER em conjunto com SUSPEND, o comando RESUME deve ser emitido antes que o checkpoint possa ocorrer, e o registro de evento deve ser um registro COMMIT. Se o processo for encerrado enquanto estiver em um estado SUSPEND, o processo reprocessará a transação da última posição com checkpoint após a reinicialização.

SUSPEND não pode ser combinado com ABORT, mas pode ser combinado com todas as outras opções.

ABORT

Válido em TABLE para Extract e em MAP para Replicat.

Força o processo a sair imediatamente quando o registro de evento especificado for encontrado, independentemente de haver ou não transações em aberto. O registro do evento não foi processado. Um erro fatal é gravado no log e o registro de evento será gravado no arquivo de descarte se DISCARD também for especificado. O processo será recuperado na inicialização.

ABORT só pode ser combinado com CHECKPOINT BEFORE, DISCARD, SHELL e REPORT.

FORCESTOP

Válido em TABLE para Extract e em MAP para Replicat.

Força o processo a ser interrompido normalmente quando o registro de evento especificado for encontrado, mas somente se o registro de evento for a última operação na transação ou o único registro na transação. O registro é escrito normalmente.

Se o registro de evento for encontrado em uma transação aberta de longa execução, o processo gravará uma mensagem de aviso no log e sairá imediatamente, como em ABORT. Nesse caso, a recuperação pode ser necessária na inicialização. Se a ação FORCESTOP for acionada no meio de uma transação de longa execução, o processo será encerrado sem uma mensagem de aviso.

FORCESTOP pode ser combinado com outras opções do EVENTACTIONS, exceto ABORT, STOP, CHECKPOINT AFTER e CHECKPOINT BOTH. Se usado com ROLLOVER, o rollover só ocorrerá se o processo for interrompido normalmente.

IGNORE [RECORD TRANSACTION [INCLUDEVENT]]

Válido em TABLE para Extract e em MAP para Replicat.

Ignora algumas ou todas as transações, dependendo da ação selecionada.

IGNORE pode ser combinado com todas as outras opções EVENTACTIONS, exceto ABORT e DISCARD.

Uma ação IGNORE é processada depois que todas as operações de qualificação, filtragem, mapeamento e saída do usuário são processadas. O registro ou a transação é ignorado na fase de saída final e impede que o registro ou a transação seja gravado no destino de saída (a trilha no caso do Extract ou do banco de dados no caso do Replicat). Portanto, em determinadas expressões, por exemplo, aquelas que incluem operações SQLEXEC, o SQLEXEC será executado antes do processamento do IGNORE. Isso significa que, embora o registro não seja gravado na trilha ou no banco de dados de destino, ocorrerão todos os efeitos do processamento do registro por meio de qualificação, filtragem, mapeamento e saída do usuário.

Esta ação não é válida para registros DDL. Como as operações DDL são autônomas, ignorar um registro equivale a ignorar toda a transação.

DISCARD

Válido em TABLE para Extract e em MAP para Replicat.

Faz com que o processo:

O processo retoma o processamento com o próximo registro na trilha.

DISCARD pode ser combinado com todas as outras opções do EVENTACTIONS, exceto IGNORE.

LOG [INFO WARNING]

Válido em TABLE para Extract e em MAP para Replicat.

Faz com que o processo registre o evento quando o registro de evento especificado for encontrado. A mensagem é gravada no arquivo de relatório, no log de erros do Oracle GoldenGate e no log de eventos do sistema.

Use as seguintes opções para especificar a severidade da mensagem:

LOG pode ser combinado com todas as outras opções EVENTACTIONS, exceto ABORT. Se estiver usando ABORT, LOG não será necessário porque ABORT registra um erro fatal antes da saída do processo.

REPORT

Válido em TABLE para Extract e em MAP para Replicat.

Faz com que o processo gere um arquivo de relatório quando o registro de evento especificado é encontrado. É o mesmo que usar o comando SEND com a opção REPORT no GGSCI.

A mensagem REPORT ocorre após o processamento do registro de evento (a menos que DISCARD, IGNORE ou ABORT sejam usados), de modo que os dados do relatório incluirão o registro de evento.

REPORT pode ser combinado com todas as outras opções EVENTACTIONS.

ROLLOVER

Válido em TABLE para Extract.

Faz com que o Extract percorra a trilha para um novo arquivo quando o registro de evento especificado é encontrado. A ação ROLLOVER ocorre antes de o Extract gravar o registro de evento no arquivo de trilha, o que faz com que o registro seja o primeiro no novo arquivo, a menos que DISCARD, IGNORE ou ABORT também sejam usados.

ROLLOVER pode ser combinado com todas as outras opções do EVENTACTIONS, exceto ABORT. ROLLOVER não pode ser combinado com ABORT porque ROLLOVER não faz com que o processo grave um checkpoint, e ROLLOVER acontece antes de ABORT.

Sem um checkpoint ROLLOVER, o ABORT faz com que o Extract vá para seu checkpoint anterior após a reinicialização, que estaria no arquivo de trilha anterior. Com efeito, isso cancela o rollover.

SHELL '<command>'

Válido em TABLE para Extract e em MAP para Replicat.

Faz com que o processo execute o comando shell especificado quando o registro de evento é encontrado. SHELL '<command'> executa um comando de shell básico. A string de comando é obtida em seu valor literal e enviada para o sistema dessa forma. O comando faz distinção entre maiúsculas e minúsculas. Coloque a string de comando entre aspas simples, por exemplo:

 EVENTACTIONS (SHELL 'echo hello world! > output.txt')

Se o comando shell for bem-sucedido, o processo gravará uma mensagem informativa no arquivo de relatório e no log de eventos. O êxito se baseia no status de saída do comando de acordo com a linguagem de shell do UNIX. Nesse idioma, zero indica sucesso.

Se a chamada do sistema não for bem-sucedida, o processo será encerrado com um erro fatal. Na linguagem shell UNIX, diferente de zero é igual a falha. Observe que a mensagem de erro se refere apenas à execução do próprio comando SHELL, e não ao status de saída de qualquer comando subordinado. Por exemplo, SHELL pode executar um script com sucesso, mas os comandos desse script podem falhar.

SHELL pode ser combinado com todas as outras opções EVENTACTIONS.

SHELL ('<command>', VAR <variable> = {<column_name> | <expression>} [, ...])

Válido em TABLE para Extract e em MAP para Replicat.

Faz com que o processo execute o comando shell especificado quando o registro de evento é encontrado e suporta a passagem de parâmetro. O comando e os parâmetros diferenciam maiúsculas de minúsculas.

Quando SHELL é usado com argumentos, toda a <command> e as strings de argumentos devem estar entre parênteses, por exemplo:

 EVENTACTIONS (SHELL
 ('Current timestamp: $1  SQLEXEC result is $2 ',VAR $1 = @GETENV('JULIANTIMESTAMP'),
 VAR $2 = mytest.description));

A entrada é a seguinte:

<command>

É o comando, que é passado literalmente para o sistema.

VAR

É uma palavra-chave obrigatória que inicia a entrada do parâmetro.

<variable>

É o nome definido pelo usuário da variável de espaço reservado na qual o valor da variável de tempo de execução será substituído. Variáveis extras que não são usadas no comando são ignoradas. Observe que qualquer literal no comando SHELL que corresponda a um nome de variável VAR é substituído pelo valor VAR substituído. Isso pode ter consequências indesejadas. Teste seu código antes de colocá-lo em produção.

<column_name>

Pode ser a imagem anterior ou posterior (atual) de um valor de coluna.

<expression>

pode ser o seguinte, dependendo se os dados da coluna ou DDL estão sendo tratados.

<TRACE[2]file> [TRANSACTION] [DDL[INCLUDE] | DDLONLY] [PURGE | APPEND]

Válido em TABLE para Extract e em MAP para Replicat.

Faz com que as informações de rastreamento do processo sejam gravadas em um arquivo de rastreamento quando o registro de evento especificado é encontrado. TRACE fornece informações de processamento passo a passo. TRACE2 identifica os segmentos de código nos quais o processo está gastando mais tempo.

Por padrão (sem opções), o rastreamento padrão DML sem diretrizes de limites de transação é ativado até que o processo seja encerrado.

TRACE pode ser combinado com todas as outras opções do EVENTACTIONS, exceto ABORT.

Para desativar o rastreamento para o arquivo de rastreamento especificado, emita o comando de processo GGSCI SEND com a opção TRACE OFF <file_name>.

CHECKPOINT [BEFORE AFTER BOTH]

Válido em TABLE para Extract e em MAP para Replicat.

Faz com que o processo grave um checkpoint quando o registro de evento especificado é encontrado. As ações de ponto de verificação fornecem um contexto em torno do processamento definido nas instruções TABLE ou MAP. Esse contexto tem um ponto inicial e um ponto final, fornecendo assim pontos de sincronização para mapear as funções que são executadas com SQLEXEC e saídas do usuário.

BEFORE

BEFORE para um processo Extract grava um checkpoint antes de o Extract gravar o registro de evento na trilha. BEFORE para um processo Replicat grava um checkpoint antes de o Replicat aplicar a operação SQL que está contida no registro ao destino.

BEFORE exige que o registro de evento seja o primeiro registro em uma transação. Se não for o primeiro registro, o processo será encerrado. Use BEFORE para garantir que todas as transações anteriores àquela que começa com o registro de evento sejam confirmadas.

Ao usar EVENTACTIONS para um registro DDL, observe que, como cada registro DDL é autônomo, o registro DDL é garantido para ser o início de uma transação; portanto, a ação do evento CHECKPOINT BEFORE está implícita para um registro DDL.

CHECKPOINT BEFORE pode ser combinado com todas as opções EVENTACTIONS.

AFTER

AFTER para Extract grava um checkpoint depois que o Extract grava o registro de evento na trilha. AFTER para Replicat grava um checkpoint depois que o Replicat aplica a operação SQL que está contida no registro ao destino.

AFTER indica a solicitação de checkpoint como uma recomendação, o que significa que o processo só emitirá um checkpoint na próxima oportunidade prática. Por exemplo, no caso em que o registro de evento é uma transação de vários registros, o ponto de verificação ocorrerá no próximo limite da transação, de acordo com o modelo de integridade de dados do Oracle GoldenGate.

Ao usar EVENTACTIONS para um registro DDL, observe que, como cada registro DDL é autônomo, o registro DDL é garantido como o fim (limite) de uma transação; portanto, a ação do evento CHECKPOINT AFTER está implícita em um registro DDL.

CHECKPOINT AFTER pode ser combinado com todas as opções EVENTACTIONS, exceto ABORT.

BOTH

O BOTH combina BEFORE e AFTER. O processo Extract ou Replicat grava um checkpoint antes e depois de processar o registro de evento.

CHECKPOINT BOTH pode ser combinado com todas as opções EVENTACTIONS, exceto ABORT.

CHECKPOINT pode ser reduzido para CP.

Exemplo 1

O exemplo a seguir mostra como você pode configurar um processo para ignorar determinados registros. Quando o Extract processa qualquer registro de trilha que tenha name = abc, ele ignora o registro.

TABLE fin.cust, &
WHERE (name = 'abc'), &
EVENTACTIONS (ignore);

Exemplo 2

Com base nas regras de compatibilidade e precedência das opções EVENTACTIONS, DISCARD tem precedência maior que ABORT, portanto, neste exemplo, o registro de evento é gravado no arquivo de descarte antes do término do processo.

MAP fin.cust, TARGET fin.cust2, &
WHERE (name = 'abc'), &
EVENTACTIONS (DISCARD, ABORT);

Exemplo 3

O exemplo a seguir executa uma ação SHELL. Ele obtém o resultado de uma consulta SQLEXEC e o emparelha com o timestamp atual.

TABLE src.tab &
SQLEXEC (id mytest, query 'select description from lookup &
where pop = :mycol2', params (mycol2 = col2) ), &
EVENTACTIONS (SHELL ('Current timestamp: $1  SQLEXEC result is $2 ', &
VAR $1 = @GETENV('JULIANTIMESTAMP'), VAR $2 = mytest.description));

O shell <command> resultante deste exemplo pode ser semelhante ao seguinte:

'Current timestamp: 212156002704718000  SQLEXEC result is test passed'

Exemplo 4

O exemplo a seguir mostra como resultados inválidos podem ocorrer se um nome de espaço reservado entrar em conflito com o texto literal na string de comando. Neste exemplo, um placeholder chamado $1 está associado a um valor de coluna, e o comando SHELL ecoa uma string literal que inclui $1.

MAP src.tab1, TARGET targ.tab1 &
EVENTACTIONS (SHELL ('echo Extra charge for $1 is $1', VAR $1 = COL1));

Este é o resultado não intencional, supondo que o valor <column> seja gift wrap:

'Extra charge for gift wrap is gift wrap'

A alteração do placeholder <variable> para $col resulta na saída correta:

MAP src.tab1, TARGET targ.tab1 &
EVENTACTIONS (SHELL ('echo Extra charge for $col is $1', VAR $col = COL1));
'Extra charge for gift wrap is $1'

O seguinte mostra um potencial semelhante para resultados não intencionais:

MAP src.tab1, TARGET targ.tab1 &
EVENTACTIONS (SHELL ('Timestamp: $1  Price is $13 > out.txt ', &
VAR $1 = @GETENV('JULIANTIMESTAMP')));

A saída redirecionada <file> pode conter uma <string> como esta (observe que o segundo timestamp contém um valor anexado de 3):

'Timestamp: 212156002704718000 Price is 2121560027047180003'

O resultado pretendido é:

'Timestamp: 212156002704718000 Price is $13'

Exemplo 5

Esses exemplos mostram diferentes maneiras de configurar o rastreamento.

MAP tab1, TARGET tab1 EVENTACTIONS (TRACE ./dirrpt/trace
1.txt);
MAP tab2, TARGET tab2 EVENTACTIONS (TRACE ./dirrpt/trace2.txt TRANSACTION);

Exemplo 6

Veja a seguir como o EVENTACTIONS com SUSPEND pode ser usado.

EXITPARAM '<parameter>'

O EXITPARAM é válido para TABLE e MAP.

Use EXITPARAM para especificar um parâmetro para a função EXIT_PARAMS de uma rotina de saída de usuário sempre que um registro da instrução TABLE ou MAP for encontrado.

Sintaxe

EXITPARAM '<parameter string>'

<'parameter string'>

Um parâmetro que é uma string literal. Coloque o parâmetro entre aspas simples. Você pode especificar até 100 caracteres para a string de parâmetro.

FETCHBEFOREFILTER

FETCHBEFOREFILTER é válido para TABLE.

Use FETCHBEFOREFILTER para extrair colunas que são especificadas com FETCHCOLS ou FETCHCOLSEXCEPT antes de uma operação FILTER ser executada. A extração antes do filtro garante que os valores necessários para o filtro estejam disponíveis. Sem FETCHBEFOREFILTER, as extrações especificadas com FETCHCOLS ou FETCHCOLSEXCEPT não são executadas até que os filtros sejam executados. Especifique FETCHBEFOREFILTER antes de FILTER no arquivo de parâmetros.

Não use esta opção para tabelas que estão sendo processadas no modo de passagem por um grupo Extract de data-pump.

Sintaxe

FETCHBEFOREFILTER

Exemplo

TABLE hr.salary, FETCHCOLS (<sal_level>),
FETCHBEFOREFILTER,
FILTER (sal_level >= 8)
;

{FETCHCOLS | FETCHCOLSEXCEPT} (<column_list>)

As opções FETCHCOLS e FETCHCOLSEXCEPT são válidas para TABLE. Essas opções são válidas apenas para o processo Extract principal.

Use FETCHCOLS e FETCHCOLSEXCEPT para extrair valores de coluna do banco de dados quando os valores não estiverem presentes no registro de log de transação. Use essa opção se o banco de dados registrar apenas os valores das colunas que foram alteradas em uma operação de atualização, mas você precisar garantir que outros valores de coluna necessários para as operações FILTER estejam disponíveis.

FETCHCOLS e FETCHCOLSEXCEPT são válidos para todos os bancos de dados suportados pelo Oracle GoldenGate.

Para um Oracle AI Database, o Oracle GoldenGate extrai os valores do tablespace de undo por meio do mecanismo Flashback Query da Oracle. A consulta fornece uma imagem com consistência de leitura das colunas a partir de um horário específico ou SCN. Para obter mais informações sobre como o Oracle GoldenGate usa a Consulta de Flashback.

Em vez de usar FETCHCOLS ou FETCHCOLSEXCEPT, pode ser mais eficiente ativar o registro em log complementar para as colunas desejadas.

Para controlar a extração e ativar uma resposta quando não for possível localizar uma coluna especificada para extração, use o parâmetro FETCHOPTIONS. Para incluir resultados de extração em exibições estatísticas geradas pelo comando STATS EXTRACT, use o parâmetro STATOPTIONS.

Se valores para colunas especificadas com FETCHCOLS ou FETCHCOLSEXCEPT estiverem presentes no log de transações, nenhuma extração de banco de dados será executada. Isso reduz a sobrecarga do banco de dados.

Sintaxe

{FETCHCOLS | FETCHCOLSEXCEPT} (<column> [, ...])

<column>

Pode ser um dos seguintes:

Exemplo

A cláusula FETCHCOLS neste exemplo extrai somente as colunas 1 e 3, enquanto a cláusula FETCHCOLSEXCEPT extrai todas as colunas, exceto as colunas 1 e 3.

TABLE hq.acct, FETCHCOLS (col1, col3);
TABLE hq.sales, FETCHCOLSEXCEPT (col1, col3);

{FETCHMODCOLS | FETCHMODCOLSEXCEPT} (<column_list>)

As opções FETCHMODCOLS e FETCHMODCOLSEXCEPT são válidas para TABLE. Essas opções são válidas apenas para o processo Extract principal.

Use FETCHMODCOLS e FETCHMODCOLSEXCEPT para forçar valores de coluna a serem extraídos do banco de dados, mesmo que as colunas estejam presentes no log de transações. Dependendo do tipo de banco de dados, um registro de log pode conter todas as colunas de uma tabela ou apenas as colunas que foram alteradas na operação de transação fornecida.

FETCHMODCOLS e FETCHMODCOLSEXCEPT são válidos para todos os bancos de dados suportados pelo Oracle GoldenGate.

Observe as seguintes diretrizes de uso:

Sintaxe

{FETCHMODCOLS | FETCHMODCOLSEXCEPT} (<column> [, ...])

(<column> [, ...])

Pode ser um dos seguintes:

Exemplo

A cláusula FETCHMODCOLS neste exemplo extrai somente as colunas 1 e 3, enquanto a cláusula FETCHMODCOLSEXCEPT extrai todas as colunas, exceto as colunas 1 e 3.

TABLE hq.acct, FETCHMODCOLS (col1, col3);
TABLE hq.sales, FETCHMODCOLSEXCEPT (col1, col3);

FILTER (<filter_clause>)

O FILTER é válido para TABLE e MAP.

Use FILTER para selecionar ou excluir registros com base em um valor numérico. Uma expressão de filtro pode usar operadores condicionais, funções de conversão de coluna do Oracle GoldenGate ou ambos. Observação: Para filtrar com base em uma string, use uma das funções de string do Oracle GoldenGate. Consulte "Funções de Mapeamento de Tabela e Coluna" para obter mais informações sobre essas funções. Você também pode usar a opção WHERE. Consulte "WHERE (cláusula)".

Separe todos os componentes FILTER com vírgulas. Uma cláusula FILTER pode incluir o seguinte:

Coloque as literais entre aspas simples. Especifique nomes de colunas com distinção entre maiúsculas e minúsculas à medida que são armazenados no banco de dados e coloque-os entre aspas duplas se o banco de dados exigir aspas para impor distinção entre maiúsculas e minúsculas (como o Oracle).

O Oracle GoldenGate suporta FILTER para colunas que têm um conjunto de caracteres de vários bytes.

Sintaxe

FILTER (
[, ON INSERT | ON UPDATE| ON DELETE]
[, IGNORE INSERT | IGNORE UPDATE | IGNORE DELETE]
, <filter_clause>
[, RAISEERROR <error_number>]
)

<filter_clause>

Seleciona registros com base em uma <expression>, como:

FILTER ((PRODUCT_PRICE*PRODUCT_AMOUNT) > 10000))

Você pode usar as funções de conversão de coluna do Oracle GoldenGate em um filtro <clause>, como em:

FILTER (@COMPUTE (PRODUCT_PRICE*PRODUCT_AMOUNT)>10000)

Coloque as literais entre aspas simples. Especifique nomes de colunas com distinção entre maiúsculas e minúsculas à medida que são armazenados no banco de dados e coloque-os entre aspas duplas se o banco de dados exigir aspas para impor distinção entre maiúsculas e minúsculas (como o Oracle).

O Oracle GoldenGate não suporta FILTER para colunas que tenham um conjunto de caracteres de vários bytes ou um conjunto de caracteres incompatível com o conjunto de caracteres do sistema operacional local.

O tamanho máximo da cláusula de filtro é 5.000 bytes.

ON INSERT ON UPDATE ON DELETE

Restringe a filtragem de registros às operações especificadas. Separe as operações com vírgulas, por exemplo:

FILTER (ON UPDATE, ON DELETE,
@COMPUTE (PRODUCT_PRICE*PRODUCT_AMOUNT)>10000)

O exemplo anterior executa o filtro para as operações UPDATE e DELETE, mas não as operações INSERT.

IGNORE INSERT IGNORE UPDATE IGNORE DELETE

Não aplica o filtro para as operações especificadas. Separe as operações com vírgulas, por exemplo:

FILTER (IGNORE INSERT, @COMPUTE (PRODUCT_PRICE*PRODUCT_AMOUNT)>10000)

O exemplo anterior executa o filtro nas operações UPDATE e DELETE, mas ignora as operações INSERT.

RAISEERROR <error>

Emite um número de erro definido pelo usuário se o filtro falhar. Pode ser usada como entrada para o parâmetro REPERROR para chamar o tratamento de erros. Certifique-se de que o valor de <error> esteja fora do intervalo de números de erro usado pelo banco de dados ou pelo Oracle GoldenGate. Por exemplo: RAISEERROR 21000,

GETBEFORECOLS (<column_specification>)

GETBEFORECOLS é válido para TABLE.

Use GETBEFORECOLS para especificar colunas para as quais você deseja que a imagem seja capturada e gravada na trilha em uma operação de atualização ou exclusão. Use GETBEFORECOLS ao usar o recurso CDR (Conflict Detection and Resolution) do Oracle GoldenGate em uma configuração bidirecional ou multimestre. Também use-o ao usar funções de conversão ou outros recursos de processamento que exigem a imagem anterior de um registro.

Para atualizações, a imagem anterior das colunas especificadas é incluída na trilha, independentemente de qualquer coluna ser modificada ou não. Além das colunas especificadas na cláusula GETBEFORECOLS, um Oracle AI Database também registrará a imagem anterior de outras colunas modificadas. Para outros bancos de dados suportados, você pode usar o parâmetro GETUPDATEBEFORES para forçar a inclusão dos valores antes de outras colunas que são modificadas.

Observação: GETUPDATEBEFORES substituirá GETBEFORECOLS se ambos forem usados no mesmo arquivo de parâmetros.

Para usar esse parâmetro, o log complementar deve ser ativado para qualquer banco de dados que não faça log antes dos valores por padrão.

GETBEFORECOLS substitui COMPRESSUPDATES e COMPRESSDELETES se usado no mesmo arquivo de parâmetros.

Esse parâmetro é válido para todos OS bancos de dados, exceto para Db2 z/OS. Para Db2 z/OS em todas as plataformas suportadas pelo Oracle GoldenGate, use o parâmetro GETUPDATEBEFORES em vez de GETBEFORECOLS.

Sintaxe

GETBEFORECOLS(
{ON UPDATE | ON DELETE}
{ALL | KEY | KEYINCLUDING (<col>[,...])  | KEYANDMOD | | ALLEXCLUDING (<col>[,...]) }
[,...]
)
{ON UPDATE ON DELETE}

Especifica se a imagem anterior das colunas especificadas deve ser capturada para atualizações ou exclusões. Você pode usar somente ON UPDATE, somente ON DELETE ou ambos. Se estiver usando ambos, especifique-os dentro da mesma cláusula GETBEFORECOLS. Consulte o exemplo de como usar ambas as reconciliações.

{ALL | KEY | KEYINCLUDING (<col>[,...]) | KEYANDMOD | ALLEXCLUDING (<col>[,...])}

Especifica as colunas para as quais uma imagem anterior é capturada.

ALL

Captura uma imagem anterior de todas as colunas de tipo de dados suportadas na tabela de destino, incluindo a chave primária; todas as colunas não suportadas são ignoradas e registradas no arquivo de parâmetros Extract ou Replicat como uma mensagem de informação. Isso impõe a maior carga de processamento para Extract, mas permite que comparações de detecção de conflito sejam realizadas usando todas as colunas para máxima precisão.

KEY

Capturar antes da imagem somente para a chave primária. Esta é a opção mais rápida, mas não permite a detecção de conflito mais precisa, porque as chaves podem corresponder, mas as colunas não-chave podem ser diferentes. KEY é o padrão.

KEYINCLUDING

Captura antes da imagem da chave primária e também da(s) coluna(s) especificada(s). Este é um compromisso razoável entre velocidade e precisão de detecção.

KEYANDMOD

Use essa opção como uma extensão da opção de chave para Extract e Replicat. Para atualizar DMLs na origem, o Extract registra a chave e as colunas modificadas. O processo Replicat no destino usará as colunas KEY e MODIFIED durante a detecção de conflito em uma cláusula WHERE. Com o Oracle AI Databases, a coluna modificada é sempre usada para detecção de conflitos por padrão e esse parâmetro a torna explícita.

ALLEXCLUDING

Captura antes da imagem de todas as colunas, exceto as colunas especificadas. Para tabelas com várias colunas, ALLEXCLUDING pode ser mais eficiente que KEYINCLUDING. Não exclua colunas-chave.

Exemplo

No exemplo a seguir, as imagens anteriores da(s) coluna(s) principal(is) mais name, address e salary são sempre gravadas no arquivo de trilha nas operações de atualização e exclusão.

TABLE src,
GETBEFORECOLS (
ON UPDATE KEYINCLUDING (name, address,  salary),
ON DELETE KEYINCLUDING (name, address, salary));

HANDLECOLLISIONS | NOHANDLECOLLISIONS

As opções HANDLECOLLISIONS e NOHANDLECOLLISIONS são válidas para MAP.

Use HANDLECOLLISIONS e NOHANDLECOLLISIONS para controlar se o Oracle GoldenGate reconcilia ou não os resultados de uma carga inicial com alterações transacionais replicadas feitas nas mesmas tabelas. Quando o Oracle GoldenGate aplica alterações replicadas após a conclusão da carga, o HANDLECOLLISIONS faz com que o Replicat substitua registros duplicados nas tabelas de destino e forneça tratamento alternativo de erros para registros ausentes.

HANDLECOLLISIONS e NOHANDLECOLLISIONS podem ser usados globalmente para todas as instruções MAP no arquivo de parâmetros ou como uma chave ON/OFF para grupos de tabelas especificadas com instruções MAP, e eles podem ser usados em uma instrução MAP. Quando usados em uma instrução MAP, eles substituem as especificações globais.

Consulte "HANDLECOLLISIONS | NOHANDLECOLLISIONS" para obter sintaxe e uso.

INSERIR REGISTROS

INSERTALLRECORDS é válido para MAP.

Use o parâmetro INSERTALLRECORDS para converter todas as operações mapeadas em operações INSERT no destino. O INSERTALLRECORDS pode ser usado no nível raiz do arquivo de parâmetros, em uma instrução MAP e em uma cláusula MAPEXCEPTION de uma instrução MAP.

Consulte "INSERTALLRECORDS" para obter sintaxe e uso.

INSERIR ANEXO | NOINSERTAPPEND

INSERTAPPEND é válido para MAP.

Use os parâmetros INSERTAPPEND e NOINSERTAPPEND para controlar se o Replicat usa ou não uma dica APPEND quando aplica operações INSERT às tabelas de destino Oracle. Esses parâmetros são válidos apenas para bancos de dados Oracle.

Consulte "INSERTAPPEND | NOINSERTAPPEND" para obter sintaxe e uso.

KEYCOLS (<columns>)

O KEYCOLS é válido para TABLE e MAP.

Use KEYCOLS para definir uma ou mais colunas da tabela de destino como exclusivas. O uso principal de KEYCOLS é definir uma chave primária substituta quando uma chave primária ou um índice exclusivo apropriado não estiver disponível para a tabela. Você também pode usar KEYCOLS para especificar colunas adicionais a serem usadas no identificador de linha que o Replicat usa. Sem a disponibilidade de uma chave ou de uma cláusula KEYCOLS, o Replicat usa todas as colunas da tabela para criar sua cláusula WHERE, executando essencialmente uma verificação completa da tabela.

As colunas de uma chave renderizada por KEYCOLS devem identificar exclusivamente uma linha e devem corresponder às colunas usadas como chave na tabela de origem. A tabela de origem deve conter pelo menos tantas colunas de chave ou índice quanto a chave KEYCOLS especificada para a tabela de destino. Caso contrário, no caso de uma atualização na chave de origem ou nas colunas de índice, o Replicat não terá as imagens anteriores para as colunas KEYCOL de destino extra.

Ao definir uma chave substituta com KEYCOLS, observe as seguintes diretrizes:

Ao usar KEYCOLS, certifique-se de que as colunas especificadas estejam configuradas para log, de modo que estejam disponíveis para Replicat nos registros de trilha. Para um banco de dados Oracle AI, você pode ativar o registro em log usando a opção COLS do comando ADD TRANDATA.

Nas tabelas de destino, crie um índice exclusivo nas colunas de chave definidas pelo KEYCOLS. Um índice melhora a velocidade com que o Oracle GoldenGate localiza as linhas de destino que precisa processar.

Não use KEYCOLS para tabelas que estão sendo processadas no modo de passagem por um grupo Extract de data-pump.

Diretrizes adicionais para KEYCOLS ao usar o Replicat Paralelo ou o Replicat Integrado:

Sintaxe

KEYCOLS (<column> [, ... ])

<column>

Define uma coluna a ser usada como uma chave primária substituta. Se existir uma chave primária ou exclusiva, essas colunas deverão ser incluídas na especificação KEYCOLS. Para especificar várias colunas, crie uma lista delimitada por vírgulas como em:

KEYCOLS (id, name)

Os seguintes tipos de coluna não são suportados em KEYCOLS:

Exemplo

KEYCOLS

MAPEXCEPTION (<exceptions_mapping>)

MAPEXCEPTIONS é válido para MAP.

Use MAPEXCEPTION como parte de uma instrução MAP de exceções destinada ao tratamento de erros. MAPEXCEPTION mapeia operações com falha que são sinalizadas como exceções pelo parâmetro REPERROR para uma tabela de exceções. O Replicat grava os valores dessas operações com outras informações na tabela de exceções.

Você pode usar MAPEXCEPTION na mesma instrução MAP que inclui o mapeamento da tabela de destino de origem e outras opções padrão MAP. Os nomes das tabelas de origem e de destino podem incluir curingas.

Ao usar MAPEXCEPTION, use uma instrução REPERROR com a opção EXCEPTION dentro da mesma instrução MAP ou na raiz do arquivo de parâmetros de Replicat. Consulte "EXCEPTIONSONLY" e "REPERROR".

Sintaxe

MAPEXCEPTION (TARGET <exceptions_table>, INSERTALLRECORDS [, <exception_MAP_options>])

TARGET <exceptions_table>

O nome totalmente qualificado da tabela de exceções. As regras padrão do Oracle GoldenGate para nomes de objeto se aplicam ao nome da tabela de exceções.

<exception_MAP_options>

Quaisquer opções válidas do parâmetro MAP que você deseja aplicar ao tratamento de exceções.

INSERTALLRECORDS

Aplica todas as exceções à tabela de exceções como operações INSERT. Esse parâmetro é necessário ao usar MAPEXCEPTION.

Exemplo

Este é um exemplo de como usar o MAPEXCEPTION para mapeamento de exceções. As cláusulas MAP e TARGET contêm nomes de tabela de origem e destino curinga. As exceções que ocorrerem ao processar qualquer tabela com um nome que comece com TRX serão capturadas na tabela fin.trxexceptions usando o mapeamento especificado.

MAP src.trx*, TARGET trg.*,
MAPEXCEPTION (TARGET fin.trxexceptions,
INSERTALLRECORDS,
COLMAP (USEDEFAULTS,
ACCT_NO = ACCT_NO,
OPTYPE = @GETENV ('LASTERR', 'OPTYPE'),
DBERR = @GETENV ('LASTERR', 'DBERRNUM'),
DBERRMSG = @GETENV ('LASTERR', 'DBERRMSG')
)
);

MAPACOLUNAS | NOMAPALLCOLUMNS

As opções MAPALLCOLUMNS e NOMAPALLCOLUMNS são válidas para MAP.

Use MAPALLCOLUMNS para obter colunas não mapeadas (não chave). Quando essa opção é especificada, o processo Extract ou Replicat verifica se todas as colunas de origem estão diretamente mapeadas para o destino sem a função de mapeamento de coluna. Se alguma coluna de origem não estiver mapeada, o processo Extract e/ou Replicat será encerrado.

Consulte "MAPALLCOLUMNS| NOMAPALLCOLUMNS".

MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS

As opções MAPINVISIBLECOLUMNS e NOMAPINVISIBLECOLUMNS são válidas para MAP.

Use MAPINVISIBLECOLUMNS e NOMAPINVISIBLECOLUMNS para controlar se o Replicat incluirá ou não colunas invisíveis nas tabelas de destino da Oracle para mapeamento de coluna padrão. Para colunas invisíveis nas tabelas de destino da Oracle que usam mapeamento de coluna explícito, elas são sempre mapeadas, portanto, não exija essa opção.

MAPINVISIBLECOLUMNS e NOMAPINVISIBLECOLUMNS podem ser usados de duas maneiras diferentes. Quando especificado em um nível global, um parâmetro permanece em vigor para todas as instruções MAP subsequentes, até que o outro parâmetro seja especificado. Quando usados em uma instrução MAP, eles substituem as especificações globais

Consulte "MAPINVISIBLECOLUMNS | NOMAPINVISIBLECOLUMNS" para obter sintaxe e uso.

REPERROR (<error>,<response>)

REPERROR é válido para MAP.

Use REPERROR para especificar um erro e uma resposta que, juntos, controlam como o Replicat responde ao erro ao executar a instrução MAP. Você pode usar REPERROR no nível MAP para substituir e complementar as regras globais de tratamento de erros definidas com o parâmetro REPERROR no nível raiz do arquivo de parâmetros. Várias instruções REPERROR podem ser aplicadas à mesma instrução MAP para permitir o gerenciamento automático e abrangente de erros e o processamento de replicação sem interrupção.

Para obter sintaxe e descrições, consulte "REPERROR".

RESOLVECONFLICT (<conflict_resolution_specification>)

RESOLVECONFLICT é válido para MAP.

Use RESOLVECONFLICT em uma configuração bidirecional ou multimestre para especificar como o Replicat trata os conflitos nas operações feitas nas tabelas na instrução MAP.

Várias resoluções podem ser especificadas para o mesmo tipo de conflito e são executadas na ordem listada em RESOLVECONFLICT. Várias resoluções estão limitadas apenas a conflitos INSERTROWEXISTS e UPDATEROWEXISTS.

O RESOLVECONFLICT pode ser usado várias vezes em uma instrução MAP para especificar diferentes resoluções para diferentes tipos de conflito.

A seguir estão os tipos de dados e as plataformas suportados pelo RESOLVECONFLICT.

Sintaxe

RESOLVECONFLICT (
{INSERTROWEXISTS | UPDATEROWEXISTS | UPDATEROWMISSING |
   DELETEROWEXISTS | DELETEROWMISSING}
( {DEFAULT | <resolution_name>},
  {USEMAX (<resolution_column>) | USEMAXEQ (<resolution_column>) | USEMIN (<resolution_column>) | USEMINEQ (<resolution_column>) | USEDELTA |
     DISCARD | OVERWRITE | IGNORE}
 )
[, COLS (<column>[,...])]
)
INSERTROWEXISTS UPDATEROWEXISTS UPDATEROWMISSING
DELETEROWEXISTS DELETEROWMISSING  

O tipo de conflito que esta resolução trata.

INSERTROWEXISTS

Uma linha inserida viola uma restrição de exclusividade no destino.

UPDATEROWEXISTS

Existe uma linha atualizada no destino, mas uma ou mais colunas têm uma imagem anterior na trilha diferente do valor atual no banco de dados.

UPDATEROWMISSING

Não existe uma linha atualizada no destino.

DELETEROWEXISTS

Existe uma linha excluída no destino, mas uma ou mais colunas têm uma imagem anterior na trilha diferente do valor atual no banco de dados.

DELETEROWMISSING

Não existe uma linha excluída no destino.

DEFAULT | <resolution_name>

DEFAULT

O grupo de colunas padrão. A resolução associada ao grupo de colunas DEFAULT é usada para todas as colunas que não estão em um grupo de colunas explicitamente nomeado. Defina um grupo de colunas DEFAULT.

<resolution_name>

Um nome para um grupo de colunas específico vinculado a um tipo de resolução específico. Forneça um nome que identifique o tipo de resolução. Os valores válidos são caracteres alfanuméricos. Evite espaços e caracteres especiais, mas sublinhados são permitidos, por exemplo:

delta_res_method

Use uma resolução nomeada ou DEFAULT, mas não ambas.

USEMAX (<resolution_column>) | USEMAXEQ (<resolution_column>) | USEMIN (<resolution_column>) | USEMINEQ (<resolution_column>) | USEDELTA |    
DISCARD OVERWRITE IGNORE

A lógica do manipulador de conflitos usada para resolver o conflito. Os cálculos válidos são:

USEMAX

Se o valor de <resolution_column> no registro de trilha for maior que o valor da coluna no banco de dados, a ação apropriada será executada.

USEMAXEQ

Se o valor de <resolution_column> no registro de trilha for maior ou igual ao valor da coluna no banco de dados, a ação apropriada será executada.

USEMIN

Se o valor de <resolution_column> no registro de trilha for menor que o valor do <column> no banco de dados, o <action> apropriado será executado:

USEMINEQ

Se o valor de <resolution_column> no registro de trilha for menor ou igual ao valor do <column> no banco de dados, o <action> apropriado será executado:

<resolution_column>

O nome de uma coluna NOT NULL que serve como coluna de resolução. Esta coluna deve fazer parte do grupo de colunas associado a esta resolução. O valor da coluna de resolução comparado ao valor atual no banco de dados de destino determina como uma resolução deve ser aplicada. A imagem posterior da coluna de resolução é usada para a comparação, se disponível; caso contrário, o valor da imagem anterior é usado. Use uma coluna que possa ser comparada por meio do SQL simples:

Para usar uma resolução de timestamp mais recente, use uma coluna de timestamp como <resolution_column> e defina a coluna de timestamp como a hora atual quando uma linha for inserida ou atualizada. Se possível, defina a coluna de resolução com o tipo de dados SYSTIMESTAMP, que suporta segundos fracionais. Quando comparações são realizadas com granularidade de subsegundo, há pouca necessidade de manipuladores de conflito desempate que resolvam casos em que o valor da coluna de resolução é idêntico na trilha e no destino. Se você garantir que o valor da coluna de timestamp só possa aumentar ou diminuir (dependendo da resolução), USEMAX e USEMIN não levarão a divergência de dados.

Observação:

Não use uma coluna de chave primária como a coluna de resolução em uma instrução USEMAX para o conflito UPDATEROWEXISTS. Caso contrário, o Replicat terá um erro semelhante ao seguinte:

  2013-04-04 10:18:38 ERROR OGG-01922 Missing RESOLUTION COLUMN NAME while mapping to target table "FIN"."ACCT".

USEDELTA

(Somente conflito UPDATEROWEXISTS) Adicione a diferença entre os valores antes e depois no registro de trilha para o valor atual da coluna no banco de dados de destino. Se qualquer um dos valores for NULL, um erro será gerado. Baseie USEDELTA em colunas que contenham tipos de dados NUMERIC. USEDELTA é útil em uma configuração com vários nós quando uma linha está sendo atualizada simultaneamente em vários nós. Propaga somente a diferença nos valores da coluna para os outros nós, de modo que todos os nós se tornem sincronizados.

DISCARD

(Válido para todos os tipos de conflito) Mantenha o valor atual no banco de dados de destino e grave os dados no registro de trilha no arquivo de descarte.

Use DISCARD com cuidado, pois isso pode levar a divergência de dados.

OVERWRITE

(Válido para todos os tipos de conflito, exceto DELETEROWMISSING) Aplique o registro de trilha da seguinte forma:

Use OVERWRITE com cuidado, pois isso pode levar a divergência de dados.

IGNORE

(Válido para todos os tipos de conflito) Mantenha o valor atual no banco de dados de destino e ignore o registro de trilha: Não se aplique à tabela de destino nem a um arquivo de descarte.

COLS (<column>[, ...])

Um grupo de colunas não padrão. Esta é uma lista de colunas no banco de dados de destino (após o mapeamento) que são vinculadas a um tipo de resolução específico e operadas por ele. Se nenhum grupo de colunas for especificado para um conflito, todas as colunas serão afetadas pela resolução especificada para o conflito fornecido.

Como alternativa, você pode especificar um grupo de colunas DEFAULT, que inclui todas as colunas que não estão listadas em outro grupo de colunas. Consulte a opção DEFAULT.

Você pode especificar vários grupos de colunas, cada um com uma resolução diferente. Por exemplo, você poderia usar OVERWRITE para col2 e col3, e poderia usar USEDELTA para col4. Nenhuma coluna em qualquer grupo pode estar em qualquer outro grupo. Os conflitos para colunas em diferentes grupos de colunas são resolvidos separadamente de acordo com a resolução especificada e na ordem listada.

Os grupos de colunas funcionam da seguinte forma:

Exemplos

Exemplo 1

Este exemplo demonstra todos os tipos de conflito com USEMAX, OVERWRITE, DISCARD.

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS (ON UPDATE ALL, ON DELETE ALL),
    RESOLVECONFLICT (UPDATEROWEXISTS, (DEFAULT, USEMAX (last_mod_time)),
    RESOLVECONFLICT (INSERTROWEXISTS, (DEFAULT, USEMAX (last_mod_time)),
    RESOLVECONFLICT (DELETEROWEXISTS, (DEFAULT, OVERWRITE)),
    RESOLVECONFLICT (UPDATEROWMISSING, (DEFAULT, OVERWRITE)),
    RESOLVECONFLICT (DELETEROWMISSING, (DEFAULT, DISCARD)),
    );

Exemplo 2

Este exemplo demonstra a UPDATEROWEXISTS com USEDELTA e USEMAX.

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS
    (ON UPDATE KEYINCLUDING (address, phone, salary, last_mod_time),
    ON DELETE KEYINCLUDING (address, phone, salary, last_mod_time)),
    RESOLVECONFLICT (
    UPDATEROWEXISTS,
    (delta_res_method, USEDELTA, COLS (salary)),
    (DEFAULT, USEMAX (last_mod_time)));

Exemplo 3

Este exemplo demonstra a UPDATEROWEXISTS com USEDELTA, USEMAX e IGNORE.

MAP fin.src, TARGET fin.tgt,
    COMPARECOLS
    (ON UPDATE ALLEXCLUDING (comment)),
    RESOLVECONFLICT (
    UPDATEROWEXISTS,
    (delta_res_method, USEDELTA, COLS (salary, balance)),
    (max_res_method, USEMAX (last_mod_time), COLS (address, last_mod_time)),
    (DEFAULT, IGNORE));

SQLEXEC (<SQL_specification>)

O SQLEXEC é válido para TABLE e MAP.

Use SQLEXEC para executar um procedimento armazenado SQL ou consulta de dentro de uma instrução MAP durante o processamento do Oracle GoldenGate. O SQLEXEC permite que o Oracle GoldenGate se comunique diretamente com o banco de dados para executar qualquer trabalho suportado pelo banco de dados. Esse trabalho pode fazer parte do processo de sincronização, como recuperar valores para conversão de coluna, ou pode ser independente de extrair ou replicar dados, como executar um procedimento armazenado que executa uma ação no banco de dados.

Consulte "SQLEXEC" para obter sintaxe e uso.

SQLPREDICATE 'WHERE <where_clause>'

SQLPREDICATE é válido para bancos de dados Oracle, Db2 LUW, Db2 em z/OS, Db2 para i, PostgreSQL, MySQL, SQL Server e Sybase. Não use SQLPREDICATE para um grupo de Extract configurado para sincronizar alterações transacionais. Ele só é apropriado para um Extract de carga inicial porque ele reativa uma instrução SELECT que seleciona registros diretamente das tabelas.

SQLPREDICATE é usado com TABLE.

Use SQLPREDICATE para incluir uma cláusula SQL WHERE convencional na instrução SELECT que o Extract usa ao selecionar dados de uma tabela em preparação para uma carga inicial. SQLPREDICATE força os registros retornados pela seleção a serem ordenados pelos valores de chave.

SQLPREDICATE é um método de seleção mais rápido para cargas iniciais do que as opções WHERE ou FILTER. Ela afeta a instrução SQL diretamente e não exige que o processo Extract extraia todos os registros antes de filtrá-los.

Para tabelas Oracle, o SQLPREDICATE reduz a quantidade de dados armazenados no segmento de undo, o que pode reduzir a incidência de erros muito antigos do snapshot. Isso é útil ao carregar tabelas muito grandes.

Usando uma cláusula SQLPREDICATE, você pode particionar as linhas de uma tabela grande entre dois ou mais processos de Extract paralelos. Essa configuração também permite que você aproveite o processamento de carga de entrega paralela.

SQLPREDICATE também permite que você selecione dados com base em um timestamp ou em outros critérios para filtrar as linhas que são extraídas e carregadas na tabela de destino. SQLPREDICATE pode ser usado para cláusulas ORDER BY ou qualquer outro tipo de cláusula de seleção.

Certifique-se de que a cláusula WHERE contenha colunas que façam parte de uma chave ou índice. Caso contrário, o Extract executará uma verificação completa da tabela, o que reduz a eficiência da instrução SELECT.

Sintaxe

TABLE <source_table>, SQLPREDICATE 'WHERE <where_clause>';

WHERE

Esta é uma palavra-chave obrigatória.

<where_clause>

Uma cláusula SQL WHERE válida que seleciona registros das tabelas de origem.

Exemplo

TABLE hr.emp, SQLPREDICATE 'WHERE state = 'CO' and city = 'DENVER''

THREAD (<thread_ID>)

THREAD é válido para MAP. Esta opção é válida quando o Replicat está no modo coordenado.

Use THREAD para especificar que todos os objetos na mesma instrução MAP devem ser processados pelo thread de Replicat especificado. O thread especificado trata filtragem, manipulação, entrega ao destino, tratamento de erros e outros trabalhos configurados para esses objetos. Caracteres curinga podem ser usados na cláusula TARGET quando THREAD é usado.

Todas as tabelas que têm dependências referenciais entre si devem ser mapeadas no mesmo thread. Por exemplo, se as tabelas scott.cust e scott.ord tiverem uma relação de chave estrangeira, o seguinte será um possível mapeamento:

MAP scott.cust, TARGET scott.cust, THREAD (5);
MAP scott.ord, TARGET scott.ord, THREAD (5);

O thread com o thread mais baixo ID sempre processa transações de barreira se a opção THREAD ou THREADRANGE for omitida. Além disso, e o trabalho que não é explicitamente atribuído a um thread é processado por meio desse thread. Por exemplo, se houver threads com IDs de 1 a 10, as transações de barreira e não atribuídas serão executadas pelo thread 1.

Para processar uma instrução MAP entre vários threads, consulte THREADRANGE (thread_range, column_list). THREAD e THREADRANGE são opções mutuamente exclusivas. Não os use juntos na mesma instrução MAP.

Sintaxe

THREAD (<thread_ID>)

<thread_ID>

Um identificador numérico para o thread que processará esta instrução MAP. Os valores válidos são 1 até o valor que foi especificado com a opção MAXTHREADS do comando ADD REPLICAT que criou esse grupo. Você pode usar o comando INFO REPLICAT para verificar o número máximo de threads permitidos para um grupo de Replicat. Ao especificar IDs thread, o seguinte deve ser verdadeiro:

Se MAXTHREADS não tiver sido usado, o número máximo padrão de threads será 25.

Exemplos

Os exemplos a seguir mostram algumas maneiras de usar a opção THREAD.

Exemplo 1

Neste exemplo, o thread 1 processa a tabela cust.

MAP scott.cust, TARGET scott.cust, THREAD (1);

Exemplo 2

Neste exemplo, o thread 1 processa todas as tabelas no esquema scott.

MAP scott.*, TARGET scott.*, THREAD (1);

Exemplo 3

Neste exemplo, a tabela orders é particionada entre duas instruções MAP por meio do uso de FILTER (filter_clause) e da função @RANGE. Para mais informações sobre @RANGE, consulte "@RANGE".

MAP scott.orders, TARGET scott.orders, FILTER (@RANGE (1, 2, OID)), THREAD (1);
MAP scott.orders, TARGET scott.orders, FILTER (@RANGE (2, 2, OID)), THREAD (2);

THREADRANGE (<thread_range>,<column_list>)

THREADRANGE é válido para MAP. Esta opção é válida quando o Replicat está no modo coordenado.

Use THREADRANGE para especificar que a carga de trabalho da tabela de destino deve ser particionada uniformemente entre uma faixa de threads de Replicat, com base no valor de uma ou mais colunas especificadas. Por exemplo, se o particionamento se basear no valor de uma coluna chamada ID e o valor THREADRANGE for 1-3, o thread 1 processará linhas com valores ID de 1 a 10, o thread 2 processará linhas com valores ID de 11 a 20 e o thread 3 processará linhas com valores ID de 21 a 30. O particionamento pode não ser tão absolutamente igual ao mostrado no exemplo anterior, dependendo do cálculo inicial da carga de trabalho, mas é coordenado para que a mesma linha seja sempre processada pelo mesmo thread. Cada thread especificado lida com filtragem, manipulação, tratamento de erros, entrega ao destino e outros trabalhos para seu intervalo de linhas.

O particionamento de uma tabela em uma faixa de threads pode melhorar o desempenho da aplicação para tabelas muito grandes ou tabelas que frequentemente incorrem em transações de longa execução ou volume pesado, mas também podem ser usadas em outros casos. É possível processar mais de uma tabela por meio do mesmo intervalo de threads.

Uma cláusula TARGET com caracteres curinga poderá ser usada quando THREADRANGE for usado se a lista de colunas opcional for omitida. Ao usar uma lista de colunas, use instruções MAP explícitas separadas para cada tabela que esteja usando o mesmo intervalo de threads.

Para processar uma instrução MAP com um thread específico, consulte THREAD (thread_ID). THREAD e THREADRANGE são opções mutuamente exclusivas. Não os use juntos na mesma instrução MAP.

Não especifique tabelas que tenham dependências referenciais entre si em um intervalo de threads. Use a opção THREAD e processe todas essas tabelas com o mesmo thread.

Não use THREADRANGE para particionar sequências. Se a coordenação for necessária, por exemplo, quando uma sequência fizer parte de uma operação SQLEXEC, particione o trabalho da sequência para um thread com a opção THREAD.

O thread com o thread mais baixo ID sempre processa transações de barreira se a opção THREAD ou THREADRANGE for omitida. Além disso, e o trabalho que não é explicitamente atribuído a um thread é processado por meio desse thread. Por exemplo, se houver threads com IDs de 1 a 10, as transações de barreira e não atribuídas serão executadas pelo thread 1. Observação: As colunas especificadas em uma lista de colunas devem existir no arquivo de trilha. Você pode controlar isso usando KEYCOLS no Extract para incluir essa coluna, ou usando FETCHCOLS no Extract para a coluna ou garantindo que a coluna faça parte do grupo de logs complementares e, em seguida, usando LOGALLSUPCOLS.

Sintaxe

THREADRANGE (<lowID>-<highID>, [<column>[, <column>][, ...]])

<lowID>

O identificador de thread mais baixo deste intervalo. Os valores válidos são de 1 a 500.

<highID>

O identificador de thread mais alto deste intervalo, que deve ser um número maior que <lowID>. Os valores válidos são <lowID>+1 a 500. O número de threads no intervalo não pode exceder o valor especificado com a opção MAXTHREADS do comando ADD REPLICAT. Se MAXTHREADS não tiver sido usado, o número máximo padrão de threads será 25.

[<column>[, <column>][, ...]]

Opcional. Especifica uma ou mais colunas exclusivas nas quais basear o particionamento de linha. Para especificar várias colunas, use uma lista delimitada por vírgulas, como col1, col2, col3. Quando esta opção é omitida, o particionamento entre os threads é baseado por padrão nas seguintes colunas, na ordem de preferência mostrada:

Exemplo

O exemplo a seguir divide as tabelas orders e order_lines entre os mesmos dois threads, com base no valor da coluna OID.

MAP scott.orders, TARGET scott.orders, THREADRANGE (1-2, OID);
MAP scott.order_lines, TARGET scott.order_lines, THREADRANGE (1-2, OID);

TOKENS (<token_definition>)

TOKENS é válido para TABLE.

Use TOKENS para definir um token de usuário e associá-lo aos dados. Os tokens permitem extrair e armazenar dados na área de token do usuário de um cabeçalho de registro de trilha. Os dados de token podem ser recuperados e usados de várias maneiras para personalizar a maneira como o Oracle GoldenGate fornece dados. Por exemplo, você pode usar dados de token em mapas de colunas, procedimentos armazenados chamados pelo SQLEXEC ou macros.

Para usar os dados de token definidos nas tabelas de destino, use a função de conversão de coluna @TOKEN na cláusula COLMAP de uma instrução MAP de Replicat. A função @TOKEN mapeia o nome de um token para uma coluna de destino.

Não use esta opção para tabelas que estão sendo processadas no modo de passagem por um grupo Extract de data-pump.

O conjunto de caracteres dos dados do token não é convertido. O token deve estar no conjunto de caracteres do banco de dados de origem para Extract e no conjunto de caracteres do banco de dados de destino para Replicat.

Sintaxe

TOKENS (<token_name> = <token_data> [, ...])

<token_name>

Um nome de sua escolha para o token. Pode ter qualquer número de caracteres válidos e não faz distinção entre maiúsculas e minúsculas. Nomes de vários bytes não são suportados.

<token_data>

Qualquer string de caracteres válida de até 2000 bytes. Os dados podem ser um literal entre aspas simples (ou aspas duplas se NOUSEANSISQLQUOTES estiver em uso) ou o resultado de uma função de conversão de coluna do Oracle GoldenGate.

Exemplo

O seguinte cria tokens denominados TK-OSUSER, TK-GROUP e TK-HOST e os mapeia para dados de token obtidos com a função @GETENV.

TABLE ora.oratest, TOKENS (
TK-OSUSER = @GETENV ('GGENVIRONMENT' , 'OSUSERNAME'),
TK-GROUP = @GETENV ('GGENVIRONMENT' , 'GROUPNAME')
TK-HOST =  @GETENV ('GGENVIRONMENT' , 'HOSTNAME'));

GUARNIÇÕES | NOTRIMSPACES

As opções TRIMSPACES e NOTRIMSPACES são válidas para TABLE e MAP.

Use TRIMSPACES e NOTRIMSPACES no nível raiz de um arquivo de parâmetros ou em uma instrução TABLE ou MAP para controlar se os espaços à direita em uma coluna CHAR de origem são truncados quando aplicados a uma coluna CHAR ou VARCHAR de destino. O padrão é TRIMSPACES.

Consulte "TRIMSPACES | NOTRIMSPACES" para obter sintaxe e uso.

TRIMVARSPACES | NOTRIMVARSPACES

As opções TRIMVARSPACES e NOTRIMVARSPACES são válidas para TABLE e MAP.

Use TRIMVARSPACES e NOTRIMVARSPACES no nível raiz de um arquivo de parâmetros ou em uma instrução TABLE ou MAP para controlar se os espaços à direita em uma coluna VARCHAR de origem são truncados quando aplicados a uma coluna CHAR ou VARCHAR de destino. O padrão é NOTRIMVARSPACES.

Consulte "TRIMVARSPACES | NOTRIMVARSPACES" para obter sintaxe e uso.

WHERE (<clause>)

O WHERE é válido para TABLE e MAP.

Use WHERE para selecionar registros com base em uma instrução condicional. WHERE não oferece suporte ao seguinte:

Coloque as literais entre aspas simples. Especifique nomes de colunas com distinção entre maiúsculas e minúsculas à medida que são armazenados no banco de dados e coloque-os entre aspas duplas se o banco de dados exigir aspas para impor distinção entre maiúsculas e minúsculas (como o Oracle).

Obtendo mais informações sobre filtragem de registros

Sintaxe

WHERE (<clause>)

<clause>

Seleciona registros com base em uma condição, como:

WHERE (branch = 'NY')

A Tabela 2-12 mostra os operadores WHERE permitidos.

Tabela 12 Operadores WHERE Permissíveis

Operador Exemplo
Nomes de colunas PRODUCT_AMT "Product_Amt"
Valores numéricos -123, 5500.123
Strings literais entre aspas simples 'AUTO', 'Ca'
Testes de coluna @NULL, @PRESENT, @ABSENT (a coluna é nula, presente ou ausente no registro). These tests are built into Oracle GoldenGate.
Comparison operators =, <>, >, <,>=, <= < td>
Conjunctive operators `AND`, `OR`
Grouping parentheses Use open and close parentheses for logical grouping of multiple elements.

Example

The following WHERE example returns all records when the AMOUNT column is over 10,000 and does not cause a record to be discarded when AMOUNT is absent.

WHERE (amount = @PRESENT AND amount > 10000)

PARTITIONOBJID

Valid for Integrated Extract.

PARTITIONOBJID is used to specify the object IDs of the partitions to be captured for partitioned tables, and applies to Integrated Extract. For an IO table (with or without overflow area), index segment object ID should be used for partition level filtering. In this case, PARTITIONOBJID in the MAP or TABLE statement specifies the index segment object IDs of the partitions to be extracted.

Syntax

MAP/TABLE [container.]schema.table PARTITIONOBJID ptn_object_ID [, ptn_object_ID]

As seguintes restrições são aplicadas:

Syntax for IO table TABLE statement:

TABLE [container.]schema.table PARTITIONOBJID index_segment_object_ID [, index_segment_object_ID]

Syntax for IO table MAP statement:

MAP [container.]schema.table PARTITIONOBJID index_segment_object_ID [, index_segment_object_ID]