TRANLOGOPTIONS

Válido Para

Extrair

Descrição

Use o parâmetro TRANLOGOPTIONS para controlar a maneira como o Extract interage com o log de transações ou com a API que transmite dados da transação, dependendo do banco de dados ou do modo de captura. Você pode usar várias instruções TRANLOGOPTIONS no mesmo arquivo de parâmetro ou pode especificar várias opções dentro da mesma instrução TRANLOGOPTIONS, se permitido para essas opções.

Use uma determinada opção TRANLOGOPTIONS somente para o banco de dados ou bancos de dados para os quais ela se destina.

Padrão

Nenhum

Sintaxe

TRANLOGOPTIONS {[ALLOW_BINLOG_ROW_METADATA_MINIMAL]
[ALLOWTABLECOMPRESSION][ALTLOGDEST <path> | REMOTE]
[ALWAYSONREADONLYROUTING]
[ASMUSERALIAS <alias> [DOMAIN <domain>]]
[ASYNCTRANSPROCESSING <buffer_size>]
[BUFSIZE <size>]
[CHECKPOINTRETENTIONTIME <days>][DB2APIRETRY <retry_count>]
[DB2ZV11COMPATIBILITYMODE]
[DICTIONARY_CACHE_SIZE <value>]
[DLFAILOVER_TIMEOUT <seconds>]
[DISABLESOFTEOFDELAY]
[EXCLUDEFILTERTABLE <table>]
[EXCLUDETAG {<tag> | + | NULL}]
[EXCLUDETRANS <transaction>]
[EXCLUDEUSER <user>]
[EXCLUDEUSERID <Oracle_uid>][FAILOVERTARGETDESTID <n>][FETCHPARTIALJSON]
[FETCHPARTIALLOB][FETCHPARTIALXML]
[FORCEFETCHLOB]
[GETCTASDML | NOGETCTASDML][HANDLEDLFAILOVER [STANDBY_WARNING | STANDBY_ABEND]]
[IFILOCKSECONDS]
[IGNOREDATACAPTURECHANGES | NOIGNOREDATACAPTURECHANGES]
[INCLUDEAUX (<AUX_specification>)]
[INCLUDEREGIONID | INCLUDEREGIONIDWITHOFFSET]
[INTEGRATEDPARAMS]
[INCLUDETAG <tag>]
[ENABLE_PROCEDURAL_REPLICATION Y]
[ENABLE_AUTO_CAPTURE | DISABLE_AUTO_CAPTURE]
[LOB_CHUNK_SIZE <size>]
[MAXAUTOCMTTRANSSIZE (<range>, <default>)]
[LOGREADTIMEOUT <value>]
[MININGUSERIDALIAS <alias> [DOMAIN <domain>]][MIXEDENDIAN [ON|OFF]]
[MANAGECDCCLEANUP | NOMANAGECDCCLEANUP ]
[MANAGESECONDARYTRUNCATIONPOINT | NOMANAGESECONDARYTRUNCATIONPOINT ]
[PERFORMANCEPROFILE HIGH|MEDIUM|LOW_RES|LOW_WORKLOAD][QUERYTIMEOUT <seconds>]
[QUERYRETRYCOUNT <seconds>]
[READQUEUESIZE <size>]
[READTIMEOUT <milliseconds>]
[REDO_TRANSPORT_LAG_THRESHOLD <seconds>]
[REDO_TRANSPORT_LAG_TIMEOUT <value>]
[REMOTESCHEMA <value>]
[REQUIRELONGDATACAPTURECHANGES | NOREQUIRELONGDATACAPTURECHANGES]
[SOURCE_OS_TIMEZONE <timezone>]
[SKIPUNKNOWNEVENT]  [STREAMINGOPTIONS (publication_names=<pub_name1>, <pub_name2>, <pub_name3>)
[SUPPRESSNOOOPUPDATES]
[TRACKSCHEMACHANGES | NOTRACKSCHEMACHANGES]
[TRANCOUNT <integer>]
[TSLOOKUPBEGINLRI | TSLOOKUPENDLRI]
[VALIDATEINLINESFLOB]
[USE_ROOT_CONTAINER_TIMEZONE]
[USENATIVEOBJSUPPORT | NOUSENATIVEOBJSUPPORT]
[VERSIONCHECK DYNAMIC | IMMEDIATE][WARNCREATEASSELECT]
}

[ALLOW_BINLOG_ROW_METADATA_MINIMAL]

Válido para MySQL

Use o ALLOW_BINLOG_ROW_METADATA_MINIMAL no arquivo de parâmetros de extração para continuar usando a variável BINLOG_ROW_METADATA do MySQL Server definida como MINIMAL.

A variável BINLOG_ROW_METADATA do MySQL Server não suporta recursos como replicação TRACKSCHEMACHANGES e DDL. Para usar esses recursos, defina BINLOG_ROW_METADATA como Full dentro do arquivo de configuração do servidor MySQL. Se esses recursos não forem necessários, continue usando MINIMAL com o parâmetro ALLOW_BINLOG_ROW_METADATA_MINIMAL.

ALWAYSONREADONLYROUTING

Válido para o SQLServer

O parâmetro ALWAYSONREADONLYROUTING permite que o Extract do Servidor SQL roteie seu processamento somente para leitura para um secundário de intenção de leitura disponível quando conectado a um listener de grupo de disponibilidade Sempre Ativo.

ALTLOGDEST <path | REMOTE>

Válido para MySQL.

Especifica a localização do arquivo de índice de log MySQL. O Extract procura os arquivos de log neste local, em vez do local padrão do banco de dados. O ALTLOGDEST pode ser usado quando a configuração do banco de dados não inclui o nome completo do caminho para os logs ou quando há várias instalações do MySQL na máquina. O Extract lê o arquivo de índice de log para localizar o arquivo de log de binários que ele precisa ler. Quando ALTLOGDEST é usado, o Extract pressupõe que os logs e o índice estejam no mesmo local.

Forneça o nome do caminho completo para o diretório.

No Windows, coloque o caminho entre aspas duplas se o caminho contiver espaços, como no exemplo a seguir.

TRANLOGOPTIONS ALTLOGDEST "C:\Program Files\MySQL\MySQL Server
5.7\log\binlog.index"

No sistema Linux:

TRANLOGOPTIONS ALTLOGDEST "/mnt/rdbms/mysql/data/logs/binlog.index"

Ao capturar em um banco de dados MySQL remoto, use a opção REMOTE em vez do caminho do arquivo de índice. Além disso, se ALTLOGDEST não for especificado, o sistema assumirá que a opção é REMOTE.

Na captura remota, especifique o seguinte no arquivo de parâmetros Extract.

TRANLOGOPTIONS ALTLOGDEST REMOTE

Para obter mais informações sobre como usar a opção REMOTE, consulte Configurar Propriedades de Log.

ASYNCTRANSPROCESSING <buffer_size>

Válido para Extração no modo de captura integrada para Oracle.

Controla se a captura integrada é executada no modo de processamento assíncrono ou síncrono e controla o tamanho do buffer quando o Extract está no modo assíncrono. O mínimo é 1 e o máximo é 1024; o padrão é 300. "

ASYNCTRANSPROCESSING <buffer_size>

No modo de processamento assíncrono <transaction>, há dois threads de controle:

• Um thread agrupa registros de alteração lógica (LCR) em transações, faz filtragem no nível do objeto e faz processamento de rollback parcial,

• O outro thread formata transações submetidas a commit, executa qualquer transformação especificada pelo usuário e grava no arquivo de trilha.

O buffer de transação é o buffer entre esses dois threads e é usado para transferir o trabalho de um thread para o outro. O tamanho do buffer de transação padrão é 300 transações submetidas a commit, mas será ajustado para baixo pelo gerenciador de memória do Oracle GoldenGate se sua memória de cache estiver próxima de ser esgotada.

NOASYNCTRANSPROCESSING

Desativa o processamento assíncrono e faz com que o Extract opere no modo síncrono. Neste modo, um thread executa todo o trabalho de captura.

BUFSIZE <size>

Válido para Db2 LUW e Db2 z/OS. Válido para Db2 para i do Oracle GoldenGate 19c e superior. Válido para o banco de dados Oracle AI do Oracle GoldenGate 21c e superior.

Controla o tamanho máximo, em bytes, dos buffers alocados para conter os dados lidos do log de transações.

Valores altos aumentam a velocidade de captura, mas fazem com que o Extract consuma mais memória. Valores baixos reduzem o uso de memória, mas aumentam a E/S porque o Extract deve armazenar dados que excedam o tamanho do cache em disco.

Para o Oracle AI Database, o tamanho do registro de operação DDL é limitado pelo tamanho do buffer de captura de registro interno do Oracle GoldenGate. O tamanho DDL pode estar até o limite de tamanho do Oracle RDBMS. Embora o banco de dados Oracle 21c permita criar DDL maior que 10 MB, o tamanho máximo do buffer de captura de registro interno é limitado a 10 MB.

O buffer <size> do <default> é determinado pela origem dos dados de redo. Estes são os intervalos válidos e os tamanhos <default>, em bytes:

Db2 LUW:

• Mínimo: 8,192

• Máximo: 10,000,000

• Padrão: 204,800

• Os valores anteriores devem estar em múltiplos do tamanho da página 4096. O processo Extract será truncado para um múltiplo se um determinado valor não atender a esse requisito.

Db2 z/OS e Db2 para i:

• Mínimo: 36KB (36864)

• Máximo: 32MB (33554432)

• Padrão: 2MB (2097152)

• Os valores anteriores devem estar em múltiplos do tamanho da página 4096. O processo Extract será truncado em um múltiplo se um determinado valor não atender a esse requisito.

• Cada Extract usa um 32bytes fixo de ECSA no sistema z/OS Db2 ao qual o Extract se conecta. Isso não se aplica a Db2 para i.

CHECKPOINTRETENTIONTIME <days>

Válido para Extração no modo integrado somente para Oracle.

Controla o número de dias que o Extract retém pontos de verificação antes de serem expurgados. É possível especificar dias parciais usando valores decimais. Por exemplo, 8,25 especifica 8 dias e 6 horas. Quando o ponto de verificação de um Extract no modo da captura integrada é expurgado, as informações de dicionário LogMiner do arquivo redo log arquivado que corresponde ao ponto de verificação são expurgadas, e o valor first_scn do processo da captura é redefinido para o valor SCN correspondente ao primeiro alteração no próximo arquivo redo log arquivado. O padrão é sete dias e o mínimo é 0,00001.

DB2APIRETRY <number> de novas tentativas

Se o Extract receber um erro da API db2ReadLog(), de leitura de log do Db2, em seguida, para determinados erros, a chamada da API será repetida. Use o DB2APIRETRY para alterar o número de novas tentativas. O número padrão de novas tentativas é definido como 3. O código SQL para o qual a API é repetida é SQLCODE -30108.

DB2ZV11COMPATIBILITYMODE

Válido para Extract em Db2 z/OS.

Ao usar o Oracle GoldenGate para extrair do Db2 z/OS versão 11 em alguns modos de compatibilidade, o processo Extract pode não determinar programaticamente a versão real do banco de dados e ocorrer um erro OGG-00551 ou OGG-00804. Use esta opção no arquivo de parâmetros Extract para definir manualmente a versão necessária do banco de dados.

DICTIONARY_CACHE_SIZE <value>

Use esta opção para ajustar o tamanho do cache do dicionário do Extract. O valor padrão é 5.000. Se PERFORMANCEPROFILE for definido como HIGH, o valor padrão será 10000.

DLFAILOVER_TIMEOUT <seconds>

Válido para Extração no modo integrado para Oracle.

Fornece um timeout configurável em segundos para permitir a transição pós-atribuição de reintegração do banco de dados stand-by. Ele é usado em conjunto com HANDLEDLFAILOVER para permitir que a Extração Integrada seja iniciada imediatamente após uma transição de função. No final do período de timeout, se o banco de dados stand-by ainda não estiver disponível, o processo Extract será encerrado.

O padrão é 300. Você também pode usar centissegundos ou milissegundos.

DISABLESOFTEOFDELAY

Válido para Extração somente no modo integrado para Oracle e Db2 LUW.

Use DISABLESOFTEOFDELAY no arquivo de parâmetros Extract para definir que o tempo de espera entre em vigor quando o status de EOF for reportado sem registros a serem retornados.

ENABLE_AUTO_CAPTURE

DISABLE_AUTO_CAPTURE

Defina essa opção para ativar o modo auto_capture, que entregaria LCRs de tabelas ativadas para captura automática. Essa opção pode ser definida quando a versão binária Oracle do banco de dados de origem for 21c ou mais recente.

EXCLUDETAG {<tag> | + | NULL}]

Válido para o Extract. (Somente Oracle)

O EXCLUDETAG é usado para excluir alterações que foram marcadas anteriormente pelo Replicat usando a opção DBOPTIONS SET TAG ou dentro da sessão do Oracle AI Database usando o procedimento DBMS_XSTREAM_ADM.SET_TAG.

Use EXCLUDETAG tag> para direcionar o processo Extract para ignorar os registros individuais marcados com a tag redo especificada.

Use EXCLUDETAG NULL para excluir todas as operações que não estão marcadas com tag. É o oposto de EXCLUDETAG +.

Use EXCLUDETAG + para direcionar o processo Extract para ignorar os registros individuais marcados com qualquer tag de redo.

Exemplo

Veja a seguir exemplos de como usar especificadores de tag com EXCLUDETAG.

Para excluir todas as alterações marcadas:

TRANLOGOPTIONS EXCLUDETAG +

Para excluir alterações marcadas específicas:

TRANLOGOPTIONS EXCLUDETAG 00
TRANLOGOPTIONS EXCLUDETAG 0952

Diretrizes ao usar os Parâmetros EXCLUDETAG e INCLUDETAG

Ao usar os parâmetros EXCLUDETAG e INCLUDETAG com os comandos TRANLOGOPTIONS e DDLOPTIONS, considere o seguinte:

• Se o TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG for especificado e o DDLOPTIONS EXCLUDETAG/INCLUDETAG não for especificado, os parâmetros TRANLOGOPIIONS EXCLUDETAG/INCLUDETAG serão aplicados às operações DML e DDL.

• Se as opções TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG forem especificadas e DDLOPTIONS EXCLUDETAG/INCLUDETAG também forem especificadas, a TRANLOGOPIIONS EXCLUDETAG/INCLUDETAG se aplicará às operações DML e a DDLOPTIONS EXCLUDETAG/INCLUDETAG se aplicará às operações DDL.

• Se o TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG não for especificado e o DDLOPTIONS EXCLUDETAG/INCLUDETAG for especificado, o DDLOPTIONS EXCLUDETAG/INCLUDETAG se aplicará às operações DDL e não haverá filtragem de tags para operações DML.

• Se TRANLOGOPTIONS EXCLUDETAG/INCLUDETAG não for especificado e DDLOPTIONS EXCLUDETAG/INCLUDETAG também não for especificado, a opção padrão DDLOPTIONS EXCLUDETAG + será aplicável, o que exclui todas as operações DDL marcadas com tag.

• Para DDLOPTIONS ao especificar EXCLUDETAG e INCLUDETAG, o EXCLUDETAG deverá vir primeiro.

EXCLUDETRANS <transaction>

Válido para Extração Integrada para Oracle.

Especifica o nome da transação do usuário do banco de dados Replicat ou de qualquer outro usuário para que essas transações não sejam capturadas pelo Extract. Use para processamento bidirecional para evitar o loop de dados entre os bancos de dados.

Para obter mais informações sobre a sincronização bidirecional, consulte Configurando a Replicação Bidirecional na Documentação do Oracle GoldenGate Microservices.

EXCLUDEUSER <user>

Válido para Db2 LUW, Db2 para z/OS, Db2 para i, Oracle e Sybase.

Especifica o nome do usuário do banco de dados de Replicat ou de qualquer outro usuário a ser usado como filtro. Normalmente, essa opção é usada para identificar transações Replicat em uma configuração de processamento bidirecional ou em cascata, com a finalidade de excluí-las ou capturá-las. No entanto, ele pode ser usado para identificar transações por qualquer outro usuário, como as de um aplicativo de negócios específico.

Você pode usar EXCLUDEUSER e EXCLUDEUSERID no mesmo arquivo de parâmetros. Não use curingas em nenhum dos parâmetros.

O nome de usuário deve ser válido. O Oracle GoldenGate consulta o banco de dados para obter o usuário associado ID e mapeia o identificador numérico de volta para o nome do usuário. Por esse motivo, se o usuário especificado for eliminado e recriado enquanto a resolução do nome for definida como o padrão de DYNAMICRESOLUTION, EXCLUDEUSER permanecerá válido. Se a mesma transação for executada quando a resolução do nome for definida como NODYNAMICRESOLUTION, EXCLUDEUSER se tornará inválido e o Extract deverá ser interrompido e, em seguida, iniciado para que EXCLUDEUSER entre em vigor, consulte DYNAMICRESOLUTION \| NODYNAMICRESOLUTION.

• Diretrizes Db2 z/OS: Em Db2 para z/OS, o usuário é sempre a autorização principal ID da transação, que normalmente é a do usuário RACF original que fez logon, mas também pode ser uma autorização diferente ID se for alterada por um processador de transação ou pela saída Db2.

• Diretrizes da Oracle: Para um Oracle AI Database, várias instruções EXCLUDEUSER podem ser usadas. Todos os usuários especificados são considerados iguais aos usuários do Replicat.

Exemplo

Os filtros de exemplo do Oracle a seguir para dois usuários (um por nome e um pelo usuário ID). As transações geradas por esses usuários serão tratadas usando tags de filtro, e um novo tamanho de buffer de transação será especificado.

TRANLOGOPTIONS EXCLUDEUSER ggsrep, EXCLUDEUSERID 90, BUFSIZE 100000

Para usar EXCLUDEUSER com multitenant, especifique o PDB.USERNAME. O exemplo a seguir exclui qualquer operação DML feita por PDBXYZ.SCOTT:

TRANLOGOPTIONS EXCLUDEUSER PDBXYZ.SCOTT

EXCLUDEUSERID <Database_uid>

Válido para Extração para Oracle.

Especifica o usuário do banco de dados ID (uid) do usuário do banco de dados de Replicat ou de qualquer outro usuário a ser usado como filtro. Este parâmetro não é válido para Extrações multitenant. Use tags e EXCLUDETAG.

O uso é o mesmo do EXCLUDEUSER.

<Oracle_uid> é um inteiro não negativo com um valor máximo de 2147483638. Há várias views do sistema que podem ser consultadas para obter o usuário ID. A mais simples é a exibição ALL_USERS. O Oracle GoldenGate não valida o usuário ID. Se o usuário associado ao usuário especificado ID for eliminado e recriado, um novo usuário ID será designado; portanto, EXCLUDEUSERID se tornará inválido para esse usuário.

FAILOVERTARGETDESTID <n>

Válido para Extração para Oracle.

Ao usar os processos de Extract do Oracle GoldenGate em uma configuração do Oracle Data Guard, o processo de Extract GoldenGate deve permanecer atrás do redo que foi aplicado ao banco de dados stand-by do Oracle Data Guard. O parâmetro FAILOVERTARGETDESTID é usado para identificar o parâmetro de inicialização LOG_ARCHIVE_DEST_n que aponta para o stand-by, ou seja, o destino de failover no qual o Extract deve permanecer para trás. Esse parâmetro é usado em combinação com HANDLEDLFAILOVER para controlar se o Extract acelerará sua gravação de dados de trilha com base no andamento da aplicação do banco de dados stand-by do Oracle Data Guard. Observe que o FAILOVERTARGETDESTID não será necessário se a configuração do Data Guard tiver o FSFO (Failover de Inicialização Rápida) ativado. O valor mínimo é 0, o máximo é 32 e o padrão é 0.

Exemplo

Para determinar o valor apropriado para o parâmetro Extract TRANLOGOPTIONS FAILOVERTARGETDESTID, conecte-se ao banco de dados do qual o Extract está extraindo dados e execute o comando a seguir.

SQL> show parameters log_archive_dest
        NAME TYPE VALUE
        -----------------------------------------------------------------------------
         log_archive_dest_1 string location=USE_DB_RECOVERY_FILE_DEST,
         valid_for=(ALL_LOGFILES, ALL_ROLES)

         log_archive_dest_2 string service="ggs2d",
         ASYNC NOAFFIRM delay=0 optional compression =disable max_failure=0
         max_connections=1 reopen=300 db_unique_name="GGS2D" net_timeout=30,
         valid_for=(online_logfile,all_roles)

O parâmetro de Extract TRANLOGOPTIONS FAILOVERTARGETDESTID será definido como 2 porque esse é o banco de dados Stand-by que o Oracle GoldenGate deve ficar para trás. A primeira entrada (log_archive_dest_1) é para os logs de arquivamento locais desse banco de dados e a segunda é para o banco de dados stand-by.

Ela seria definida como 2 porque esse é o banco de dados Stand-by que o Oracle GoldenGate deve ficar para trás. A primeira entrada (log_archive_dest_1) é para os logs de arquivamento locais desse banco de dados e a segunda é para o banco de dados stand-by.

FETCHPARTIALJSON

Válido para Extração para MySQL

Use essa opção no arquivo de parâmetros Extract para extrair dados diretamente da tabela, se houver atualizações parciais nas colunas de tipo de dados JSON de uma tabela. Observação: O processamento de atualizações de dados da coluna JSON depende do valor da variável do servidor MySQL, binlog_row_value_options, cujo valor precisa ser definido como PARTIAL_JSON, e o arquivo de parâmetros Extract inclui o parâmetro FETCHPARTIALJSON.

FETCHPARTIALLOB

Válido para Extração no modo de captura integrada para Oracle.

Use essa opção ao replicar para um destino heterogêneo ou em outras condições em que a imagem LOB completa seja necessária. Isso faz com que o Extract extraia o objeto LOB completo, em vez de usar o objeto de alteração parcial do registro de redo. Por padrão, o servidor de logmining do banco de dados envia o Extract um LOB inteiro ou parcial, dependendo se todo ou parte do LOB de origem foi atualizado. Para garantir o snapshot correto do LOB, o recurso Oracle Flashback deve ser ativado para a tabela e o Extract deve ser configurado para usá-lo. O parâmetro Extract FETCHOPTIONS controla a extração e deve ser definido como USESNAPSHOT (o padrão na ausência de NOUSESNAPSHOT). Sem um snapshot de Flashback, o Extract extrai o LOB da tabela, que pode ser uma imagem diferente do momento em que o registro de redo foi gerado.

FETCHPARTIALXML

Válido para Extração no modo de captura integrada Oracle.

Use essa opção ao replicar para um destino heterogêneo ou em outras condições em que a imagem LOB completa seja necessária. Isso faz com que o Extract extraia o documento XML completo, em vez de usar a imagem de alteração parcial do registro de redo. Por padrão, o servidor de logmining do banco de dados envia ao Extract um documento XML inteiro ou parcial, dependendo se todo ou parte do XML de origem foi atualizado. Para garantir o snapshot correto do XML, o recurso Oracle Flashback deve ser ativado para a tabela e o Extract deve ser configurado para usá-lo. O parâmetro do Extract FETCHOPTIONS controla a extração e deve ser definido como USESNAPSHOT (o padrão na ausência de NOUSESNAPSHOT). Sem um snapshot de Flashback, o Extract extrai o documento XML da tabela, que pode ser uma imagem diferente do ponto no tempo em que o registro de redo foi gerado.

EXCLUDEFILTERTABLE <table>

Válido para Extract em MySQL, PostgreSQL e SQL Server.

Use esta opção para identificar uma transação de origem para filtragem. Se uma transação de origem incluir qualquer operação para o EXCLUDEFILTERTABLE especificado, essa transação será identificada como uma transação replicada. A filtragem de transações é baseada em tags.

Quando um Replicat usa uma tabela de checkpoint, ele grava um registro de recuperação na tabela de checkpoint no final de cada transação que ele aplica. Considerando que todas as transações aplicadas pelo Replicat contêm uma atualização sobre a tabela de checkpoint, o Extract ignora toda a transação aplicada pelo Replicat, o que impede o loop de dados. Para o Servidor PostgreSQL e SQL, certifique-se de que o TRANDATA tenha sido adicionado à tabela de checkpoint.

Se estiver usando um Replicat paralelo em uma replicação bidirecional, várias tabelas de filtro serão suportadas usando a opção TRANLOGOPTIONS EXCLUDEFILTERTABLE. Várias tabelas de filtro permitem que o TRANLOGOPTIONS EXCLUDEFILTERTABLE seja especificado várias vezes com diferentes nomes de tabela ou curingas.

Você pode incluir uma ou várias entradas TRANLOGOPTIONS EXCLUDEFILTERTABLE no arquivo de parâmetros do Extract. No exemplo a seguir, várias entradas TRANLOGOPTIONS EXCLUDEFILTERTABLE são incluídas no arquivo de parâmetros Extract com nomes de objeto explícitos e curingas.

TRANLOGOPTIONS EXCLUDEFILTERTABLE ggs.chkpt2
TRANLOGOPTIONS EXCLUDEFILTERTABLE ggs.chkpt_RABC_*

Para obter informações sobre como criar uma tabela de checkpoint, consulte Adicionar uma Extração Principal. Para especificar nomes de objetos e curingas corretamente, consulte Using Wildcards in Command Arguments na Documentação de Microsserviços do Oracle GoldenGate.

FORCEFETCHLOB

Válido para Extração para Oracle.

Substitui o comportamento padrão de capturar dados do LOB do redo log. Faz com que os LOBs sejam extraídos do banco de dados por padrão.

Cuidado: Se um valor for excluído antes que a extração ocorra, o Extract gravará um valor nulo na trilha. Se um valor for atualizado antes de uma extração, o Extract gravará o valor atualizado. Para evitar essas imprecisões, tente manter a latência do Extract baixa. A documentação do Oracle GoldenGate fornece diretrizes para o ajuste do desempenho do processo. Além disso, consulte Interações entre Buscas de uma Tabela e DDL para obter instruções sobre como definir opções de busca.

GETCTASDML | NOGETCTASDML

Ativa a funcionalidade Criar Tabela Como Seleção (CTAS). Quando GETCTASDML está ativado, os DMLs CTAS são enviados do LogMiner e replicados no destino. Esta opção é ativada por padrão. A execução do CTAS DDL é suprimida no destino.

HANDLEDLFAILOVER [ STANDBY_WARNING <value> | STANDBY_ABEND <value>]

Válido para Extração para Oracle

STANDBY_WARNING e STANDBY_ABEND válidos para o Oracle Database 21c e versões posteriores.

Controla se o Extract acelerará sua gravação de dados de trilha com base no andamento da aplicação do banco de dados stand-by Failover de Inicialização Rápida. Ele tem como objetivo manter o Extract em um ponto seguro atrás de qualquer failover de perda de dados.

Ao usar isso para perda de dados em uma configuração do Data Guard sem FSFO (Fast Start Failover), você deve definir o parâmetro Extract FAILOVERTARGETDESTID para identificar o destino do log de arquivamento ID no qual o stand-by pode ser conectado.

Descobriu-se que a extração está em um estado parado quando o Extract consulta o banco de dados stand-by, aplica informações de SCN (SELECT applied_scn FROM v$archive_dest where dest_id=n) e esse SCN é menor que o SCN de LCR de processamento de Extração. Nesse caso, o Extract não processará o LCR e aguardará até que o applied_scn se torne maior ou igual ao processamento do Extract LCR SCN.

STANDBY_WARNING <value>

O período antes de uma mensagem de aviso ser gravada no arquivo de relatório Extract, se o processo Extract estiver parado. O padrão são 60 segundos.

STANDBY_ABEND <value>

O tempo antes da conclusão do Extract, se o Extract estiver parado. O default é 30 minutos.

Se STANDBY_WARNING e STANDBY_ABEND forem especificados, STANDBY_ABEND sempre deverá ser maior que STANDBY_WARNING.

IFILOCKSECONDS <seconds>

Válido para Db2 z/OS

Define o intervalo em <seconds>, para o qual o Extract contém os bloqueios implícitos mantidos no banco de dados pelas chamadas para IFCID

1. Os bloqueios podem afetar a capacidade de executar determinadas operações do banco de dados, como REORGS. O valor padrão é 20 segundos, com valores mínimos e máximos como 1 segundo e 300 segundos, respectivamente. Observação: Se o parâmetro IFILOCKSECONDS for definido por um período mais longo, outras operações do banco de dados, como REORGS, poderão ser impactadas por causa do bloqueio interno causado pelas chamadas IFI de Extração. Portanto, se ocorrer alguma contenção de bloqueio em relação a um Extract, defina o timeout de bloqueio da operação para uma duração maior que o valor do parâmetro IFILOCKSECONDS ou faça shutdown do Extract.

IGNOREDATACAPTURECHANGES

NOIGNOREDATACAPTURECHANGES

Válido para Db2 LUW

Controla se a Extração captura ou não tabelas para as quais DATA CAPTURE CHANGES não está definido. IGNOREDATACAPTURECHANGES ignora tabelas para as quais o DATA CAPTURE CHANGES não está definido. Utilize-o se as tabelas tiverem sido especificadas com um curinga para garantir que o processamento continue para tabelas que não tenham conjunto de captura de alterações. Um aviso é emitido para o log de erros das tabelas que foram ignoradas. O padrão é NOIGNOREDATACAPTURECHANGES.

INCLUDEREGIONID

INCLUDEREGIONIDWITHOFFSET

Válido para Extração para Oracle.

Essas opções suportam o tipo de dados TIMESTAMP WITH TIME ZONE do sistema Oracle especificado como TZR (que representa a região do fuso horário, como US/Pacific). Por padrão, o Extract será encerrado em TIMESTAMP WITH TIME ZONE se ele incluir uma região de fuso horário. Essas opções permitem tratar esse timestamp com base no tipo de banco de dados de destino.

Quando o Extract detecta que o tipo de dados de origem é TIMESTAMP e há um token de mapeamento ID de região, o Replicat aplica o timestamp da seguinte forma:

• Um TIMESTAMP WITH TIME ZONE com TZR será aplicado se a versão do Oracle de destino for compatível com ele.

• Um timestamp com um deslocamento UTC é aplicado a um banco de dados heterogêneo ou a uma versão anterior do Oracle que não suporta TIMESTAMP WITH TIME ZONE com TZR.

INCLUDEREGIONID

Válido para Extração Integrada para Oracle.

O INCLUDEREGIONID está obsoleto para o Oracle GoldenGate 19c (19.1.0). A partir do Oracle GoldenGate 19c (19.1.0), o TIMESTAMP WITH TIME ZONE com dados da região ID é incluído por padrão, incluindo a carga inicial.

Use ao replicar de uma origem Oracle para um destino Oracle da mesma versão ou posterior. Quando INCLUDEREGIONID é especificado, o Extract adiciona um índice de coluna e o valor TMZ de dois bytes como um token de mapeamento de fuso horário e o envia para a trilha no formato UTC de YYYY-MM-DD HH:MI.SS.FFFFFF +00:00.

INCLUDEREGIONIDWITHOFFSET

Válido para Extração Integrada para Oracle.

Utilize esta opção para converter a região ID em valor de deslocamento de hora e minutos (+06:00 como exemplo). Se a opção não for especificada, o timestamp será sempre gravado no arquivo de trilha em UTC e o fuso horário será sempre +00:00.

Se você precisar preservar o valor do fuso horário em horas e minutos, em vez de UTC, essa opção poderá ser usada.

Nos seguintes casos, a opção é forçada a ativar para preservar o TIMEZONE <value> em hora e minutos <offset>:

• Formato de arquivo de trilha antigo porque o Replicat não suporta a região ID.

• Os formatos XML, TEXT e SQL não suportam a região ID.

INCLUDETAG {<tag>| +}

Válido para o Extract. (Somente Oracle)

Use INCLUDETAG <tag> para incluir operações DDL marcadas específicas nos arquivos de trilha. O valor da tag pode ter até 2000 dígitos hexadecimais (0-9 A-F).

Para evitar conflitos, não use INCLUDETAG em conjunto com EXCLUDETAG.

Exemplo: tranlogoptions includetag 00

LOB_CHUNK_SIZE

Válido para SQL Server, PostgreSQL.

Se você tiver tamanhos de dados LOB enormes, poderá ajustar o LOB_CHUNK_SIZE do padrão de 4000 bytes para um valor maior de até 65535 bytes, para que o tamanho da extração seja aumentado, reduzindo os percursos necessários para extrair o LOB inteiro

Exemplo: TRANLOGOPTIONS LOB_CHUNK_SIZE 8000

(PostgreSQL) Especifica o tamanho do chunk para os dados LOB (CLOB/BLOB) que serão usados para enviar em COM. A unidade está em bytes. Os valores mínimo e máximo de lob_chunk_size estão entre 4000 e 65535 bytes.

LOGREADTIMEOUT

Válido para Extract para o PostgreSQL versão 12 e posterior.

Ativa ou desativa a opção wal_sender_timeout para o processo do remetente de WAL.

A opção value pode ser somente um valor inteiro, com 60000 milissegundos como o valor padrão. O valor máximo é 2147483647 milissegundos e o valor mínimo é 0 milissegundos.

INTEGRATEDPARAMS (<parametervalue> [, ...])

Válido para Extração no modo de captura integrada para o Oracle Standard ou Enterprise Edition 12c ou posterior.

Passa parâmetros e valores para o servidor de logmining do Oracle AI Database quando o Extract está no modo de captura integrada. A entrada deve estar na forma de <parameter value>, como em:

TRANLOGOPTIONS INTEGRATEDPARAMS (downsream_real_time_mine Y)

As especificações de parâmetro válidas e seus valores são os seguintes:

max_sga_size

Especifica a quantidade de memória SGA usada pelo servidor de logmining do banco de dados. Pode ser um inteiro positivo em megabytes. O padrão será 1 GB se streams_pool_size for maior que 1 GB; caso contrário, será 75% de streams_pool_size.

parallelism

Especifica o número de processos que suportam o servidor de logmining do banco de dados. Pode ser um inteiro positivo. O padrão é 2.

downstream_real_time_mine

Especifica se a captura integrada extrai ou não um banco de dados de mineração downstream no modo em tempo real. Um valor de Y especifica a captura em tempo real e requer que redo logs stand-by sejam configurados no banco de dados de mineração downstream. Um valor de N especifica a captura de logs arquivados enviados ao banco de dados de mineração downstream. O padrão é N.

enable_procedural_replication

Ativa a replicação de procedimentos na captura. A replicação de procedimentos é desativada por padrão. Um valor Y permite a replicação procedural. Depois que essa opção for ativada para um Extract, ela permanecerá ativada. O valor do parâmetro não pode ser alternado.

MANAGESECONDARYTRUNCATIONPOINT

NOMANAGESECONDARYTRUNCATIONPOINT

Válido para PostgreSQL.

MANAGESECONDARYTRUNCATIONPOINT é a definição padrão e controla o restart_lsn do slot de replicação para o Extract específico.

NOMANAGESECONDARYTRUNCATIONPOINT não move o slot de replicação do Extract e geralmente é usado apenas para fins de desenvolvimento e teste em que um Extract precisa ser reposicionado para um LSN anterior do LSN de recuperação do Extract. Se usado, o log de gravação antecipada PostgreSQL continuará a aumentar e a consumir espaço em disco.

MAXAUTOCMTTRANSSIZE (<range>, <default>)

Válido apenas para DB2 para i

Fornece o intervalo do tamanho máximo da transação com commit automático.

Db2 para registros com commit automático i (o lançamento tem CCID igual a 0) não tem um registro de commit no lançamento e, portanto, o Oracle GoldenGate deve criar uma transação implícita para incluir esses registros na trilha. O padrão permite que um único registro seja incluído em uma única transação, o que mantém a precisão do Tempo de E/S indicado para cada registro porque o tempo de E/S é baseado na confirmação da transação.

Esse parâmetro define o número máximo de registros que serão incluídos em uma transação criada implicitamente, mas o número poderá ser menor se qualquer outro tipo de entrada for visto no lançamento antes do máximo ser atingido. Esta resposta evita problemas com sobreposição de pontos de verificação em registros que pertencem a registros explicitamente confirmados.

A definição do valor para esse parâmetro como 1 (o defulat) fornecerá um tempo de E/S preciso para cada registro na trilha para registros que são confirmados automaticamente (têm um CCID de 0 no lançamento), à despesa potencial de throughput para o Extract. O valor desse parâmetro também afeta o tamanho potencial máximo de uma transação em cache para esses registros na memória. A definição para um valor menor faz com que a memória da transação seja menor se o Extract for capaz de armazenar o número máximo de entradas por transação implícita. Por definição, só pode haver uma dessas transações implícitas na memória a qualquer momento, uma vez que qualquer outro registro de transação causará um commit imediato na trilha de qualquer registro em uma transação implícita já na memória.

O intervalo padrão está entre 1 e 10000 e o valor padrão é 1.

MININGUSER {/ | <useridalias> [<algorithm> ENCRYPTKEY {<key_name> | DEFAULT}] [SYSDBA]]

Válido para o Oracle GoldenGate Extract for Oracle.

Especifica as credenciais de log-in do Extract para fazer log-in em um banco de dados Oracle mining downstream para interagir com o servidor de log-mining. Pode ser usado em vez da opção MININGUSERIDALIAS se um armazenamento de credenciais do Oracle GoldenGate não estiver sendo usado.

Este usuário deve:

• Ter os privilégios concedidos na atribuição OGG_CAPTURE e OGG_APPLY para o Oracle GoldenGate 26ai e versões posteriores. Para o Oracle Database 21c, os privilégios concedidos no dbms_goldengate_auth.grant_admin_privilege devem ser aplicados.

• Ser o usuário que emite os comandos MININGDBLOGIN, MININGDBLOGIN USERIDALIAS e REGISTER EXTRACT ou UNREGISTER EXTRACT para o grupo Extract associado a esse MININGDBLOGIN USERIDALIAS.

• Não ser alterado.

/

Direciona o Oracle GoldenGate a usar um login no sistema operacional para a Oracle, não um login de usuário no banco de dados. Só use esse argumento se o banco de dados permitir autenticação no nível do sistema operacional. Ignorar a autenticação no nível do banco de dados elimina a necessidade de atualizar os arquivos de parâmetro do Oracle GoldenGate se as senhas do aplicativo forem alteradas com frequência.

Para usar essa opção, o nome de usuário correspondente deve existir no banco, em relação ao valor do parâmetro Oracle OS_AUTHENT_PREFIX de inicialização. O valor definido com OS_AUTHENT_PREFIX é concatenado com o início do nome da conta do sistema operacional de um usuário e depois comparado com o nome do banco de dados. Esses dois nomes devem coincidir.

Quando OS_AUTHENT_PREFIX é definido como ' ' (uma string nula), o nome do usuário deve ser criado com IDENTIFIED EXTERNALLY. Por exemplo, se o nome de usuário OS for ogg, você usará o seguinte para criar o usuário do banco de dados:

CREATE USER ogg IDENTIFIED EXTERNALLY;

Quando OS_AUTHENT_PREFIX for definido como OPS$ ou outra string, o nome <user> deverá ser criado no formato de:

<OS_AUTHENT_PREFIX_value><OS_user_name>

Por exemplo, se o nome OS <user> for ogg, você usará o seguinte para criar o banco de dados <user>:

CREATE USER ops$ogg IDENTIFIED BY oggpassword;

<user>

Especifica o nome do usuário do banco de Dados de Mineração ou uma string SQL*Net.

<password>

A senha do usuário. Use quando a autenticação do banco de dados for necessária para especificar a senha do usuário de banco de dados. Se a senha foi criptografada por meio do comando ENCRYPT PASSWORD, forneça a senha criptografada; caso contrário, use a senha em texto sem formatação. Se a senha distinguir maiúsculas de minúsculas, digite-a dessa maneira. Se o usuário ID ou a senha forem alterados, a alteração deverá ser feita nos arquivos de parâmetros do Oracle GoldenGate, incluindo a recriptografia da senha, se necessário.

<algorithm>

Especifica a criptografia <algorithm> que foi usada para criptografar a <password> com ENCRYPT PASSWORD. Pode ser um dos seguintes:

AES128
AES192
AES256

ENCRYPTKEY {<key_name> | DEFAULT}

Especifica a chave de criptografia que foi especificada com ENCRYPT PASSWORD.

• ENCRYPTKEY <key_name> especifica o nome lógico de uma chave de criptografia criada pelo usuário no arquivo da pesquisa ENCKEYS. Use se o ENCRYPT PASSWORD foi usado com a opção KEYNAME <key_name>.

• ENCRYPTKEY DEFAULT direciona o Oracle GoldenGate para usar uma chave aleatória. Use se ENCRYPT PASSWORD foi usado com a opção KEYNAME DEFAULT.

SYSDBA

Especifica que o usuário faz log-in como sysdba.

MININGUSERIDALIAS <alias>

Válido para Extração para Oracle.

Especifica o alias para as credenciais de log-in que o Extract usa para fazer log-in em um banco de dados Oracle mining downstream para interagir com o servidor de log-mining. Pode ser usado em vez de MININGUSER se um armazenamento de credenciais do Oracle GoldenGate estiver sendo usado.

Este alias deve ser:

• Associado a uma credencial de log-in de usuário do banco de dados que é armazenada no armazenamento de credenciais local do Oracle GoldenGate. Esse usuário deve ter os privilégios concedidos em dbms_goldengate_auth.grant_admin_privilege para o Oracle Database 21c e inferior e a atribuição OGG_CAPTURE e OGG_APPLY para o Oracle AI Database 26ai e superior.

• O usuário que emite os comandos MININGDBLOGIN, MININGDBLOGINALIAS e REGISTER EXTRACT ou UNREGISTER EXTRACT para o grupo Extract associado a esse MININGUSERIDALIAS.

Este alias e usuário não devem ser alterados enquanto o Extract estiver no modo de captura integrada.

MIXEDENDIAN [ON

OFF]

Válido para Db2 LUW com o Extract principal do Oracle GoldenGate

O Oracle GoldenGate Extract for Db2 LUW suporta captura interendian em que o banco de dados e o Oracle GoldenGate estão em execução em diferentes servidores de ordem de byte. A detecção de ordem de byte é automática para o banco de dados LUW versão 10.5 e superior Db2. Se você precisar desativar a detecção automática no Db2 LUW 10.5, poderá substituí-lo especificando esse parâmetro. Para a versão 10.1, o parâmetro deve ser usado no arquivo de parâmetros de Extract para a captura de cross-endian. Por padrão, o valor é definido como OFF para a versão 10.1.

Sintaxe:

TRANLOGOPTIONS MIXEDENDIAN [ON|OFF]

ON: Se essa opção estiver definida, o processo Extract assumirá que o banco de dados e o Oracle GoldenGate estão em execução em servidores com uma ordem de byte diferente e a conversão de reversão de byte necessária será executada.

OFF: Se essa opção estiver definida, o Extract assumirá que o banco de dados e o Oracle GoldenGate estão em execução em servidores com a mesma ordem de byte e nenhuma conversão de reversão de ordem de byte será executada.

MANAGECDCCLEANUP

NOMANAGECDCCLENUP

Válido para o Servidor SQL.

MANAGECDCCLEANUP é a definição padrão e recomendada que instrui o processo Extract a validar a existência do job de Limpeza do CDC do Oracle GoldenGate ou a tarefa Expurgar Dados de Alteração, dependendo da arquitetura e da versão do Oracle GoldenGate.

Para todas as versões da Arquitetura Clássica do Oracle GoldenGate e para versões de Microsserviços anteriores ao Oracle GoldenGate 21.4, use o programa ogg_cdc_cleanup_setup.bat/sh para instalar o job de Limpeza de CDC do Oracle GoldenGate e tabelas associadas e procedimentos armazenados.

Para instalações do Oracle GoldenGate Microservices 21.4 e posteriores, crie uma tarefa Expurgar Dados de Alteração na página Tarefas da seção Configuração do Serviço de Administração do WebUI. A tarefa Expurgar Dados de Alteração cria os procedimentos armazenados necessários e as tabelas associadas e trata a função de expurgação dentro do Oracle GoldenGate e não por meio do job do Agente do Servidor SQL.

A opção NOMANAGECDCCLEANUP instrui o Extract a não verificar a existência do job de Limpeza do CDC do Oracle GoldenGate ou da tarefa Limpar Dados de Alteração. Esta não é uma opção recomendada para ambientes de produção, mas pode ser usada para testar um Extract sem precisar criar o job ou a tarefa de Limpeza do CDC do Oracle GoldenGate.

PERFORMANCEPROFILE HIGH

MEDIUM

LOW_RES

LOW_WORKLOAD

Válido para Extração no modo de Captura Integrada.

Para ajustar a Captura Integrada.

Pode ser definido como HIGH, MEDIUM (padrão) ou LOW_RES. Ele ajuda a obter melhor desempenho agrupando os parâmetros que afetam o desempenho. Depois que o perfil do desempenho é configurado, essa opção configura automaticamente os parâmetros relevantes para atingir a taxa de transferência e latência necessárias.

• A opção HIGH permite que uma alta carga de trabalho com um throughput contínuo seja processado com mais eficiência em termos de replicação de ponta a ponta. A opção HIGH aumenta o tamanho do buffer do arquivo de trilha para 4 MB e diminui os valores da opção de fim de arquivo e descarga para 0,1 segundo.

• A opção MEDIUM define o tamanho do buffer do arquivo de trilha como 1 MB, e os valores para atraso e descarga de fim de arquivo como 1 segundo.

• A opção LOW_RES é aplicável quando os recursos estão baixos e foram adicionados para implantação com restrição de memória ou recurso.

• A opção LOW_WORKLOAD é usada com ambientes do Oracle GoldenGate for Oracle AI Database com uma baixa carga de trabalho, mas a latência deve estar em subsegundos.

Quando a opção HIGH está ativada para carga de trabalho de baixa a média intensidade, ela aumenta a latência de Extract integrada para vários segundos. Isso ocorre porque a opção HIGH aumenta o tamanho do buffer de leitura do Extract para 8 MB. No entanto, a regra para descarregar o buffer de leitura de extração é quando o buffer está cheio ou quando não há registros de entrada por uma duração de 0,2 segundos. Portanto, qualquer carga de trabalho contínua com taxa de ingestão de Extract inferior a 8 MB resultará em latência de Extract integrada para exceder 1 segundo. Certifique-se de que, se as taxas de ingestão do Extract (ou taxas de geração de redo se 100% do redo estiver sendo capturado) forem inferiores ao valor especificado, como ~15 MB/s para obter uma latência de extração de ~0,5 segundo, não use a opção HIGH. Se a latência de subsegundo for necessária, recomenda-se reduzir o tamanho do buffer adequadamente. Por exemplo, defina o tamanho do buffer para um terço da taxa de geração de redo em MB/seg para obter uma latência máxima de extração de ~0,3 segundo.

QUERYTIMEOUT <seconds>

Válido para o Servidor SQL.

Especifica por quanto tempo as consultas ao Servidor SQL aguardarão os resultados antes de reportar uma mensagem de erro de timeout. Esta opção usa um valor inteiro para representar o número de segundos. O valor padrão de timeout de consulta é 300 segundos (5 minutos). O valor mínimo é 0 segundos (tempo limite infinito). O máximo é 2147483645 segundos.

O exemplo a seguir instrui o Servidor SQL a aguardar 60 segundos pelos resultados antes do timeout.

TRANLOGOPTIONS QUERYTIMEOUT 60

QUERYRETRYCOUNT <seconds>

Válido para Extract para o Servidor SQL e MySQL.

Especifica quantas vezes as chamadas de repetição para o procedimento armazenado CDC usado pelo Extract, em caso de timeout do conjunto de resultados.

É possível especificar QUERYRETRYCOUNT para repetir várias vezes. Se todas as tentativas de repetição falharem, o Extract será encerrado com a mensagem de erro de timeout de conexão normal.

Para o Servidor SQL, o padrão é uma tentativa de repetição, após a qual a definição mínima (0) do processo abends.The é infinita, o máximo é 1000 e o padrão é 1.

Para MySQL, a definição mínima e padrão é 50 e a máxima é 1000. Não há valor infinito. Qualquer tentativa de definir o QUERYRETRYCOUNT como menor que o mínimo será ignorada sem erro ou aviso.

O exemplo a seguir faz com que o Extract tente a chamada de procedimento armazenado CDC 4 vezes:

TRANLOGOPTIONS QUERYRETRYCOUNT 4

O exemplo a seguir faz com que o Extract tente a chamada de procedimento armazenado CDC 100 vezes:

TRANLOGOPTIONS QUERYRETRYCOUNT 100

READQUEUESIZE <size>

Válido para MySQL.

Especifica o tamanho da fila interna, em bytes, para dados da transação. Pode ser aumentado para melhorar o desempenho. Os valores válidos são números inteiros de 3 a 1500. O default é 256 bytes; comece com o default e avalie o desempenho antes de ajustar para cima.

REDO_TRANSPORT_LAG_THRESHOLD <seconds>

Válido para Extração Integrada no Modo de Mineração Downstream.

Monitora a latência de rede entre um banco de dados de origem e o de destino quando os redo logs são enviados. Se a latência exceder o limite especificado, um aviso será exibido no arquivo de relatório e uma mensagem de informação subsequente será exibida quando o atraso cair para o nível normal.

O valor de limite padrão é 30 segundos. O valor limite mínimo que pode ser especificado é 15 segundos.

Para obter mais informações, consulte Extração de Downstream

REDO_TRANSPORT_LAG_TIMEOUT <value>

Válido para Extração Integrada no Modo de Mineração Downstream.

O valor fornecido como entrada nesta opção de parâmetro é o período durante o qual o Extract aguardará o redo de cada thread. Se todos os threads tiverem aguardado o timeout (em segundos) e não tiverem recebido nenhum redo, o processo Extract será encerrado novamente.

REQUIRELONGDATACAPTURECHANGES

NOREQUIRELONGDATACAPTURECHANGES

Válido para Db2 LUW.

Controla a resposta do Extract quando DATA CAPTURE é definido como NONE ou como CHANGES sem INCLUDE LONGVAR COLUMNS e o arquivo de parâmetros inclui qualquer um dos seguintes parâmetros de Oracle GoldenGate que exigem a presença de imagens antes para alguns ou todos os valores de coluna: GETBEFOREUPATES, NOCOMPRESSUPDATES e NOCOMPRESSDELETES. Ambas as definições DATA CAPTURE impedem o log de valores anteriores para colunas LONGVAR. Se essas colunas não estiverem disponíveis para o processo Extract, isso poderá afetar a integridade dos dados de destino.

REQUIRELONGDATACAPTURECHANGES

A extração termina com um erro.

NOREQUIRELONGDATACAPTURECHANGES

A extração emite um aviso, mas continua processando o registro de dados.

REMOTESCHEMA <value>

Válido para a Extração z/OS Db2.

Ao usar várias versões do Oracle GoldenGate for Db2 z/OS Extract, crie várias versões dos componentes do Extract GoldenGate dentro de Db2 z/OS em diferentes nomes de esquema. O parâmetro REMOTESCHEMA é usado para instruir o Extract sobre qual esquema usar.

Consulte Instalar Componentes de Extração no Db2 z/OS na Documentação do Oracle GoldenGate Microservices para obter detalhes.

SOURCE_OS_TIMEZONE <timezone>

Válido para Extração no modo de captura integrada para Oracle.

Especifica o fuso horário do sistema do banco de dados de origem. O fuso horário do sistema de um banco de dados geralmente é fornecido pelo fuso horário padrão de seu sistema operacional e também pode ser substituído definindo a variável de ambiente TZ quando o banco de dados é iniciado. Você deverá especificar essa opção somente se o banco de dados de origem e o processo de Extração utilizarem fusos horários do sistema diferentes. Por exemplo, em uma implantação de captura downstream em que o banco de dados de origem e o processo Extract são executados em diferentes servidores em fusos horários diferentes.

É possível especificar o valor dessa opção em um nome de região de fuso horário ou em um formulário de deslocamento UTC e você deve usar o mesmo formulário usado pelo banco de dados de origem. Por exemplo, se o banco de dados de origem usar um form de nome de região como America/New_York, você deverá especificar America/New_York, US/Eastern ou EST5EDT. Como alternativa, se o banco de dados de origem usar um form de deslocamento UTC como -05:00, você deverá usar a sintaxe (GMT)[+|-]hh[:mm]. Por exemplo, GMT-05:00 ou -5.

SKIPUNKNOWNEVENT

Válido para MySQL.

Você pode usar esse parâmetro no arquivo de parâmetros Extract para ativar a ignorar qualquer evento não tratado ou desconhecido no log de binários MySQL. Se esse parâmetro for especificado, o Extract do Oracle GoldenGate para MySQL continuará o processamento sem nenhum erro ao localizar um evento que não seja tratado pelo processo Extract atual.

STREAMINGOPTIONS

Válido para PostgreSQL.

Use esse parâmetro para fornecer os parâmetros necessários durante a inicialização da replicação. Consulte também Registrar Extract para PostgreSQL na Documentação de Microsserviços do Oracle GoldenGate.

Por exemplo:

TRANLOGOPTIONS STREAMINGOPTIONS (publication_names="my*123,my_publication2, my_publication";)

SUPPRESSNOOOPUPDATES

Válido para Extração no Oracle AI Database.

Você pode controlar se as atualizações sem operação são filtradas ou não na Extração Integrada. O padrão não é uma supressão.

TRACKSCHEMACHANGES

NOTRACKSCHEMACHANGES

Válido para Db2 z/OS e MySQL

Para o Oracle GoldenGate for Db2 z/OS, esse parâmetro permite que o Extract capture instruções DDL de nível de tabela e retenha um histórico das alterações a serem usadas para processar DML quando os registros de log se referem a uma versão de tabela anterior à versão atual da tabela. Isso normalmente seria antes de imagens de atualizações, mas poderia ser depois de imagens, inserções ou exclusões se o Extract estiver em execução em uma situação de atraso do backlog do log. Quando o Extract encontrar as operações DDL apropriadas, ele anotará o número da versão do DDL e atualizará a tabela de histórico DDL com as novas informações. O processo Extract criará um novo registro de TDR relacionado à alteração na trilha também. Quando o Extract encontrar versões anteriores da tabela no log, ele fará referência ao histórico DDL para poder interpretar corretamente o DDL da versão mais antiga da tabela. A alteração DDL não está sendo replicada na verdade, e a sincronização de quaisquer alterações na tabela de origem ainda precisa ser executada manualmente pelo usuário no banco de dados de destino.

Quando você informar esse comando, ele permitirá que as alterações no nível da tabela DDL sejam rastreadas pelo Extract e os metadados da trilha sejam atualizados, conforme apropriado. Para usar TRACKSCHEMACHANGES corretamente, os metadados da tabela devem estar em um estado consistente conhecido, o que significa que todas as tabelas que precisam de rastreamento de versão devem ser criadas e nunca alteradas ou reorganizadas antes de usar TRACKSCHEMACHANGES para que nenhuma versão anterior da tabela apareça no log de transações para operações de atualização ou exclusão. O script ddl_update.sh foi fornecido para ajudar na criação de um conjunto inicial de registros de histórico DDL para o banco de dados.

Para usar o processamento DDL, o banco de dados precisa ser configurado com uma tabela de histórico que capturará as alterações DDL das várias versões de todas as tabelas no sistema de banco de dados. Além disso, as tabelas do sistema precisam ser ativadas para alterações de captura de dados. Para criar e manter a tabela de histórico, são fornecidos os seguintes scripts de shell do UNIX:

• ddl_create.sh : Este script é usado para criar a tabela de histórico DDL. Também permite alterações na captura de dados para as seguintes tabelas do sistema:

  • SYSIBM.SYSTABLES

  • SYSIBM.SYSCOLUMNS

  • SYSIBM.SYSINDEXES

  • SYSIBM.SYSKEYCOLUSE

  Exemplo:

  ./ddl_create.sh -f crt_ddl_hist.sql -s OGGSCHEMA

  Neste exemplo, o arquivo resultante, crt_ddl_hist.sql, deve ser processado por outro programa.

  ./ddl_create.sh -d DB2DSXY -u gguser -p ggpw -s OGGSCHEMA

  Isso chamará um Db2 local para estabelecer uma conexão remota com um banco de dados mainframe a fim de criar imediatamente a tabela de histórico DDL.

• ddl_remove.sh: Este script é usado para remover a tabela de histórico DDL. No entanto, as tabelas do sistema não são alteradas.

• ddl_update.sh: Este script deve ser executado para estabelecer um ponto inicial inicial para o rastreamento de versão DDL usando TRACKSCHEMACHANGES. Ele deve ser executado após a criação da tabela de histórico DDL e não deve ser necessário executá-la novamente, a menos que a extração deva ser reposicionada de forma que as versões da tabela possam ser perdidas no log de transações. A reexecução de ddl_update.sh só adicionará informações para tabelas que ainda não estão presentes no histórico DDL.

• execsql.sh: Este script não deve ser executado diretamente, mas deve estar disponível para que os outros scripts sejam originados. Ele fornece recursos comuns para analisar a linha de comando e executar o SQL ou gravá-lo em um arquivo.

Esses scripts podem ser usados para criar as tabelas diretamente usando uma conexão Db2 ou podem ser usados para criar arquivos SQL que podem ser executados em um programa de processamento SQL de sua escolha. Os arquivos foram verificados como compatíveis com o controle remoto Db2 e SPUFI.

Veja a seguir uma descrição das opções aceitas por esses scripts:

• -h mostra essa ajuda de uso.

• -d dsn especifica o DSN Db2 ao qual estabelecer conexão.

• -u userid especifica o Usuário ID com o qual se conectará ao banco de dados.

• -p password especifica a senha com a qual se conectar ao banco de dados.

• -s ggschema especifica o nome do esquema no qual a tabela de histórico DDL deve ser armazenada. Esse esquema deve ser igual ao GGSCHEMA em GLOBALS.

• -t ddltable especifica o nome da tabela da tabela de histórico DDL. GGS_DDL_HIST é o padrão.

• -f outfile especifica o nome de um arquivo no qual gravar as instruções SQL em vez de executá-las. Se -d, -u, -p deverão ser todos especificados se forem usados ou -f. No momento, -t não deve ser usado. -f deverá ser usado se apenas o comando db2cli estiver disponível no host remoto, pois db2cli não pode executar as instruções SQL que são geradas.

Para o Oracle GoldenGate for MySQL, há suporte para a replicação DDL com captura e entrega. Quando a replicação DDL está ativada, o Extract detecta as operações DDL na tabela de banco de dados de origem, processa a instrução DDL, atualiza os metadados da tabela e grava a instrução DDL e os metadados no arquivo de trilha. O Replicat aplica essas operações DDL no banco de dados de destino MySQL e também seleciona a nova versão dos metadados da trilha e processa as operações DML subsequentes. Todo esse processo é contínuo e não há tempo de inatividade envolvido, mas isso só é possível para o cenário de curtir, como (MySQL a MySQL).

O parâmetro TRACKSCHEMACHANGES permite capturar as alterações de metadados da tabela após a operação DDL nas tabelas de origem para que a captura possa processar operações DML subsequentes sem qualquer tempo de inatividade. Quando a opção TRACKSCHEMACHANGES está ativada, a captura grava um novo registro TDR na trilha que contém os novos metadados em cada operação DDL seguida pelos dados correspondentes. O Capture não processa e grava a instrução DDL no arquivo de trilha, portanto, as alterações em DDL não são realmente replicadas no banco de dados de destino. É necessário executar manualmente no banco de dados de destino a sincronização de quaisquer alterações do DDL correspondentes à origem. O benefício de usar esse recurso é que, ao contrário da replicação DDL, TRACKSCHEMACHANGES pode ser usado em cenários de replicação entre bancos de dados, por exemplo, MySQL a Db2 z/OS.

Estas são as considerações ao usar o comando TRANLOGOPTIONS TRACKSCHEMACHANGES:

• Por padrão, o parâmetro TRACKSCHEMACHANGES é ativado do Oracle GoldenGate 23.7 em diante. Portanto, os metadados modificados também são capturados por padrão.

• DDL e TRACKSCHEMCHANGES não estão em conflito. Se o DDL estiver ativado, o DDL será capturado e processado.

• Para capturar as alterações de esquema, o usuário precisa ativar explicitamente TRACKSCHEMACHANGES no arquivo de parâmetros Extract.

• Quando o binlog_row_metadata não é FULL no MariaDB e no MySQL, o TRACKSCHEMCHANGES é desativado com a seguinte mensagem de advertência mostrada no arquivo de relatório Extract:

  "Schema change tracking has been disabled because the MySQL system variable binlog_row_metadata is set to MINIMAL.
  The metadata recorded in the MySQL binlog is insufficient for schema change tracking and may result in data discrepancies.
  It is recommended to set it to FULL."

• A opção de parâmetro TRANLOGOPTIONS NOTRACKSCHEMACHANGES permite desativar o rastreamento de esquema. No entanto, é recomendável não desativar o rastreamento de esquema. Se você desativar o rastreamento de esquema, uma mensagem de aviso será emitida no relatório Extract da seguinte forma:

  Schema change tracking has been disabled because TRANLOGOPTIONS NOTRACKSCHEMACHANGES is specified in the Extract parameter file.
  It is recommended to enable the schema change tracking. To enable the schema tracking, set the MySQL system variable binlog_row_metadata to FULL
  and remove the parameter TRANLOGOPTIONS NOTRACKSCHEMACHANGES from the extract parameter file.

• Embora TRACKSCHMEACHANGES esteja ativado por padrão, quando DDL e TRACKSCHMEACHANGES não estão ativados no arquivo de parâmetros Extract e o CREATE TABLE AS SELECT é encontrado pelo Extract, a operação DDL CREATE TABLE é ignorada do processamento e as operações DML (INSERT) associadas são capturadas pelo Extract.

  Ao processar as DMLs de uma tabela desse tipo, o Replicat de destino deve terminar conforme a tabela DDL não é replicada para o destino.

  A tabela no destino precisa ser criada manualmente nesses casos, emitindo apenas a operação CREATE TABLE e não a operação CREATE TABLE AS SELECT.

• Se nem TRACKSCHEMACHANGES nem DDL estiverem ativados no arquivo de parâmetros Extract e uma operação DDL for emitida em uma tabela específica que faça parte da lista Extract, o Extract será encerrado de forma anormal.

• Se nem TRACKSCHEMACHANGES nem DDL estiverem ativados no arquivo de parâmetros do Extract e uma operação DDL for emitida em uma tabela específica que não faça parte da lista de captura, o Extract não será encerrado de forma anormal

TRANCOUNT

Válido para o Servidor SQL.

Permite o ajuste do número de transações processadas por chamada pelo Extract para extrair dados das tabelas intermediárias de captura de dados de alteração do Servidor SQL. Com base na carga de trabalho da transação, ajustar esse valor pode melhorar o throughput da taxa de captura. O valor mínimo é 1, o máximo é 100 e o padrão é 10.

Exemplo:

TRANLOGOPTIONS TRANCOUNT 20

Este exemplo instrui o Extract a extrair 20 transações por vez das tabelas ativadas para captura de dados de alteração.

[TSLOOKUPBEGINLRI

TSLOOKUPENDLRI]

Válido para Db2 LUW v 10.1 e posterior.

Quando você especifica um intervalo de LRI usando esses parâmetros, o Extract procura o timestamp especificado no comando ADD ou ALTER EXTRACT dentro desse intervalo. Isso ajuda o Extract a otimizar o processo de pesquisa de um timestamp específico no log de transações do banco de dados. O parâmetro TSLOOKUPBEGINLRI é obrigatório, enquanto TSLOOKUPENDLRI é opcional. A especificação de apenas TSLOOKUPENDLRI sem TSLOOKUPBEGINLRI é inválida e faz com que o Extract seja encerrado de forma anormal. Por exemplo:

TRANLOGOPTIONS TSLOOKUPBEGINLRI 75200.666197, TSLOOKUPENDLRI  75207.666216
TRANLOGOPTIONS TSLOOKUPBEGINLRI 75200.666197

Se o timestamp fornecido estiver entre os intervalos de LRI fornecidos ou o timestamp fornecido estiver após o timestamp de LRI TSLOOKUPBEGINLRI, o Extract começará com um registro com timestamp igual ou menor que o timestamp fornecido.

Se o timestamp fornecido for anterior ao timestamp do LRI TSLOOKUPBEGINLRI, o Extract será iniciado no LRI TSLOOKUPBEGINLRI especificado. Se o timestamp fornecido for posterior ao timestamp TSLOOKUPENDLRI, o Extract será encerrado de forma anormal.

USENATIVEOBJSUPPORT

NOUSENATIVEOBJSUPPORT

Válido para Extração no modo de captura integrada para Oracle.

O Integrated Capture adiciona captura baseada em redo para tipos de dados UDT (User Defined Type) e ANYDATA. Ele é ativado por padrão e só pode ser ativado se a versão do banco de dados de origem for 12.1.0.1 ou posterior e a compatibilidade do banco de dados de origem for 12.0.0.0.0 ou posterior. É necessário usar o processo Replicat do Oracle GoldenGate release 12.1.2.1.0. Para usar o Suporte Nativo, todas as suas instâncias do Oracle AI Database e do Oracle GoldenGate devem ser da versão 12.1.0.1 ou posterior para serem compatíveis.

Se a captura baseada em redo estiver ativada, mas um UDT contiver um atributo não suportado, o Integrated Capture tentará capturar o UDT usando a extração. Para obter as limitações de suporte para captura, consulte XML Data Types. Se você criar tabelas de objetos usando uma instrução CREATE TABLE AS SELECT (CTAS), a Captura Integrada deverá ser configurada para capturar DML da operação CTAS para suportar totalmente as tabelas de objetos. Para CTAS, consulte Como o Oracle GoldenGate Trata Nomes de Objetos Derivados na Documentação de Microsserviços do Oracle GoldenGate

O padrão é USENATIVEOBJSUPPORT, se suportado.

Ative o parâmetro TRANLOGOPTIONS NOUSENATIVEOBJSUPPORT no arquivo de parâmetros do Oracle Extract para capturar os dados UDT como dados XML no arquivo de trilha. Esses dados podem ser aplicados a qualquer coluna de destino que aceite dados XML como CLOB/TEXT/CHAR/VARCHAR etc.

USE_ROOT_CONTAINER_TIMEZONE

Válido somente para Extract integrado pela Oracle.

Este parâmetro é para um ambiente CDB. Cada PDB em um CDB pode usar outro fuso horário do banco de dados. Se o fuso horário do banco de dados estiver disponível, o Extract tentará obter o fuso horário de um PDB do Dicionário Integrado. A extração de fuso horário requer um patch no banco de dados de mineração. Se o patch não estiver disponível, o Extract enviará uma consulta ao PDB para obter o fuso horário. Se o patch do banco de dados ou uma conexão com o PDB não estiver disponível e esse parâmetro for especificado, o Extract assumirá que o fuso horário do banco de dados PDB é igual ao fuso horário do banco de dados contêiner raiz.

VERSIONCHECK DYNAMIC

IMMEDIATE

Isso é válido para o Servidor SQL.

Use essa opção quando quiser que o Extract valide versões de objetos CDC de procedimentos armazenados comuns, como OracleCDCExtract e OracleGGCreateProcs, na inicialização.

DYNAMIC (padrão) identifica as versões do objeto CDC da tabela especificada no arquivo de parâmetros uma vez por tabela enquanto os registros são processados.

O IMMEDIATE identifica problemas de versão do objeto CDC antecipadamente, em vez de enquanto os registros são processados. Os bancos de dados com um grande número de tabelas configuradas para captura exigem validação de inicialização mais longa.

WARNCREATEASSELECT

Isso é válido para Extract para MySQL.

A operação DDL CREATE TABLE AS SELECT não é suportada e o Oracle GoldenGate Extract para MySQL é encerrado quando encontra este DDL. Um erro semelhante ao seguinte ocorre quando o Extract é encerrado pela primeira vez:

DDL statement "CREATE TABLE AS SELECT" is detected for table <table-name> at binary log
number <binlog number> and offset <binlog offset>. The DDL operation "CREATE TABLE AS SELECT"
is not supported. Execute all 'CREATE TABLE AS SELECT' DDL operations manually to the target
database and start Extract by adding Extract parameter TRANLOGOPTIONS WARNCREATEASSELECT. Once
Extract gets past the 'CREATE TABLE AS SELECT' operation, restart Extract after disabling the
parameter TRANLOGOPTIONS WARNCREATEASSELECT.

Quando você usa a definição TRANLOGOPTIONS WARNCREATEASSELECT no arquivo Extract <parameter>, o Extract continua depois de emitir a seguinte mensagem de advertência no arquivo de relatório Extract:

DDL statement 'CREATE TABLE AS SELECT' is detected for table <table-name> at binary
log number <binlog number> and offset <binlog offset>. The DDL operation 'CREATE TABLE AS SELECT' is not supported.
The DDL and the associated DMLs are ignored.