As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Utilizar um banco de dados Oracle como origem do AWS DMS
É possível migrar dados de um ou vários bancos de dados Oracle com o AWS DMS. Com um banco de dados Oracle como origem, é possível migrar dados para qualquer um dos destinos compatíveis com o AWS DMS.
O AWS DMS é compatível com as seguintes edições de bancos de dados Oracle:
-
Oracle Enterprise Edition
-
Oracle Standard Edition
-
Oracle Express Edition
-
Oracle Personal Edition
Para obter informações sobre as versões de bancos de dados Oracle que são compatíveis com o AWS DMS, consulte Fontes para AWS DMS.
É possível utilizar Secure Sockets Layer (SSL) para criptografar conexões entre o endpoint do Oracle e a instância de replicação. Para obter mais informações sobre a utilização de SSL com um endpoint do Oracle, consulte Suporte de SSL para um endpoint do Oracle.
O AWS DMS é compatível com a utilização da criptografia transparente de dados (TDE) do Oracle para criptografar dados em repouso no banco de dados de origem. Para obter mais informações sobre como utilizar a TDE do Oracle com um endpoint do Oracle de origem, consulte Métodos de criptografia com suporte para uso do Oracle como origem do AWS DMS.
O AWS é compatível com a utilização do TLS versão 1.2 e posterior com os endpoints do Oracle (e todos os outros tipos de endpoints) e recomenda a utilização do TLS versão 1.3 ou posterior.
Siga estas etapas para configurar um banco de dados Oracle como um endpoint de origem do AWS DMS:
-
Crie um usuário do Oracle com as permissões adequadas para o AWS DMS acessar o banco de dados de origem Oracle.
-
Crie um endpoint de origem do Oracle que esteja em conformidade com a configuração de banco de dados Oracle escolhida. Para criar uma tarefa de somente carga máxima, nenhuma outra configuração é necessária.
-
Para criar uma tarefa que trata a captura de dados de alteração (uma tarefa somente de CDC ou de carga máxima e CDC), escolha LogMiner do Oracle ou o Binary Reader do AWS DMS para capturar as alterações nos dados. A escolha do LogMiner ou do Binary Reader determina algumas das permissões e opções de configuração posteriores. Para obter uma comparação entre o LogMiner e Binary Reader, consulte a seguinte seção.
nota
Para obter mais informações sobre tarefas de carga máxima, tarefas somente CDC e tarefas de carga máxima e CDC, consulte Criar uma tarefa
Para obter mais detalhes sobre como trabalhar com bancos de dados Oracle de origem e o AWS DMS, consulte as seguintes seções.
Tópicos
- Utilizar o LogMiner do Oracle ou o Binary Reader do AWS DMS para CDC
- Fluxos de trabalho para configurar um banco de dados de origem Oracle gerenciado pela AWS no AWS DMSConfigurar um banco de dados de origem Oracle
- Trabalhar com um banco de dados Oracle autogerenciado como origem do AWS DMS
- Como trabalhar com um banco de dados Oracle gerenciado pela AWS como origem do AWS DMS
- Limitações da utilização do Oracle como origem do AWS DMS
- Suporte de SSL para um endpoint do Oracle
- Métodos de criptografia com suporte para uso do Oracle como origem do AWS DMS
- Métodos de compactação com suporte para uso do Oracle como origem do AWS DMS
- Replicar tabelas aninhadas utilizando Oracle como origem do AWS DMS
- Armazenar REDO no Oracle ASM ao utilizar o Oracle como origem do AWS DMS
- Configurações de endpoint ao utilizar o Oracle como origem do AWS DMS
- Tipos de dados de origem do Oracle
Utilizar o LogMiner do Oracle ou o Binary Reader do AWS DMS para CDC
No AWS DMS, há dois métodos para ler os redo logs ao executar a captura de dados de alteração (CDC) para o Oracle como origem: LogMiner do Oracle e Binary Reader do AWS DMS. O LogMiner é uma API Oracle para ler os logs redo online e arquivos de logs redo arquivados. O Binary Reader é um método do AWS DMS que lê e analisa os arquivos de redo logs brutos diretamente. Esses métodos têm os recursos a seguir.
Atributo | LogMiner | Binary Reader |
---|---|---|
Fácil de configurar | Sim | Não |
Menor impacto na E/S e na CPU do sistema de origem | Não | Sim |
Melhor performance da CDC | Não | Sim |
Compatível com clusters de tabelas do Oracle | Sim | Não |
Compatível com todos os tipos de Oracle Hybrid Columnar Compression (HCC) | Sim |
Parcialmente O Binary Reader não é compatível com QUERY LOW para tarefas com CDC. Todos os outros tipos de HCC são totalmente compatíveis. |
Compatível com a coluna LOB no Oracle 12c somente | Não (a compatibilidade com o LOB não está disponível com o LogMiner no Oracle 12c.) | Sim |
Compatível com instruções UPDATE que afetam somente colunas LOB |
Não | Sim |
Compatível com a criptografia de dados transparente (TDE) do Oracle |
Parcialmente Ao utilizar o LogMiner do Oracle, o AWS DMS não é compatível com a criptografia TDE em nível de coluna para o Amazon RDS para Oracle. |
Parcialmente O Binary Reader é compatível com TDE somente em bancos de dados Oracle autogerenciados. |
Compatível com todos os métodos de compactação do Oracle | Sim | Não |
Compatível com transações XA | Não | Sim |
RAC |
Sim Não recomendado por motivos de desempenho e por algumas limitações internas do DMS. |
Sim Altamente recomendado |
nota
Por padrão, o AWS DMS utiliza o LogMiner do Oracle para (CDC).
O AWS DMS é compatível com os métodos de criptografia de dados transparente (TDE) ao trabalhar com um banco de dados de origem Oracle. Se as credenciais da TDE especificadas estiverem incorretas, a tarefa de migração do AWS DMS não falhará, o que pode afetar a replicação contínua de tabelas criptografadas. Para obter mais informações sobre como especificar as credenciais da TDE, consulte Métodos de criptografia com suporte para uso do Oracle como origem do AWS DMS.
As vantagens principais da utilização do LogMiner com o AWS DMS incluem:
-
O LogMiner é compatível com a maioria das opções do Oracle, como por exemplo, as opções de criptografia e de compactação. O Binary Reader não é compatível com todas as opções do Oracle, especialmente a compactação e a maioria das opções de criptografia.
-
O LogMiner oferece uma configuração mais simples, especialmente quando comparada com a configuração de acesso direto do Binary Reader ou quando os redo logs forem gerenciados utilizando o Oracle Automatic Storage Management (ASM).
-
O LogMiner é compatível com clusters de tabela para uso com o AWS DMS. O Binary Reader não oferece.
As principais vantagens da utilização do Binary Reader com o AWS DMS incluem:
-
Para migrações com um alto volume de alterações, o LogMiner pode afetar a E/S ou a CPU do computador que hospeda o banco de dados Oracle de origem. O Binary Reader tem menos chance de causar impacto na E/S ou na CPU porque os logs são minerados diretamente, em vez da execução de várias consultas ao banco de dados.
-
Para migrações com um alto volume de alterações, o desempenho da captura de dados de alteração (CDC) é, em geral, muito melhor utilizando o Binary Reader do que o LogMiner do Oracle.
-
O Binary Reader é compatível com a CDC para LOBs no Oracle versão 12c. O LogMiner não é compatível.
Como regra geral, utilize o LogMiner do Oracle para migrar um banco de dados Oracle, a menos que você se encontre em uma das seguintes situações:
-
Você precisa executar várias tarefas de migração no banco de dados Oracle de origem.
-
O volume de alterações ou o volume de redo logs no banco de dados Oracle de origem é alto ou você tem alterações e também está utilizando o Oracle ASM.
nota
Se você alterar entre a utilização do LogMiner do Oracle e do Binary Reader do AWS DMS, reinicie a tarefa de CDC.
Configuração da CDC em um banco de dados Oracle de origem
Para que um endpoint de origem Oracle se conecte ao banco de dados para uma tarefa de captura de dados de alteração (CDC), talvez seja necessário especificar atributos de conexão adicionais. Isso pode ser verdade tanto para uma tarefa de carga máxima e CDC quanto para uma tarefa somente de CDC. Os atributos de conexão adicionais especificados dependem do método utilizado para acessar os redo logs: LogMiner do Oracle ou do Binary Reader do AWS DMS.
Você especifica atributos de conexão adicionais ao criar o endpoint de origem. Se você tiver várias configurações de atributos de conexão, separe-as umas das outras por ponto e vírgula e sem espaços em branco adicionais (por exemplo, oneSetting;thenAnother
).
O AWS DMS utiliza o LogMiner por padrão. Não é necessário especificar atributos de conexão adicionais para utilizá-lo.
Para utilizar o Binary Reader para acessar os redo logs, inclua os seguintes atributos de conexão adicionais.
useLogMinerReader=N;useBfile=Y;
Utilize o seguinte formato para os atributos de conexão adicionais para acessar um servidor que utiliza o ASM com o Binary Reader.
useLogMinerReader=N;useBfile=Y;asm_user=
asm_username
;asm_server=RAC_server_ip_address
:port_number
/+ASM;
Defina o parâmetro de solicitação Password
do endpoint de origem para a senha do usuário do Oracle e a senha do ASM, separadas por uma vírgula da seguinte forma.
oracle_user_password
,asm_user_password
Quando a origem Oracle utiliza o ASM, é possível trabalhar com opções de alto desempenho no Binary Reader para o processamento de transações em escala. Essas opções incluem atributos de conexão adicionais para especificar o número de threads paralelos (parallelASMReadThreads
) e o número de buffers de leitura antecipada (readAheadBlocks
). A configuração conjunta desses atributos pode melhorar significativamente o desempenho da tarefa de CDC. As configurações a seguir fornecem bons resultados para a maioria das configurações do ASM.
useLogMinerReader=N;useBfile=Y;asm_user=asm_username;asm_server=RAC_server_ip_address:port_number/+ASM; parallelASMReadThreads=6;readAheadBlocks=150000;
Para obter mais informações sobre os valores compatíveis com atributos de conexão adicionais, consulte Configurações de endpoint ao utilizar o Oracle como origem do AWS DMS.
Além disso, o desempenho de uma tarefa de CDC com uma origem Oracle que utiliza o ASM depende das outras configurações escolhidas. Essas configurações incluem os atributos de conexão adicionais do AWS DMS e as configurações do SQL para configurar a origem Oracle. Para obter mais informações sobre atributos de conexão adicionais para uma origem Oracle que utiliza o ASM, consulte Configurações de endpoint ao utilizar o Oracle como origem do AWS DMS
Você também precisa escolher um ponto de partida apropriado da CDC. Normalmente, ao fazer isso, você deseja identificar o ponto de processamento da transação que captura a primeira transação aberta a partir da qual a CDC é iniciada. Caso contrário, a tarefa de CDC pode perder transações abertas anteriores. Para um banco de dados de origem Oracle, é possível escolher um ponto inicial nativo da CDC com base no número da alteração do sistema (SCN) do Oracle para identificar essa primeira transação aberta. Para ter mais informações, consulte Executar a replicação a partir de um ponto de início de CDC.
Para obter mais informações sobre como configurar a CDC para um banco de dados Oracle autogerenciado como origem, consulte Privilégios necessários da conta ao utilizar o LogMiner do Oracle para acessar os redo logs, Privilégios necessários de conta ao utilizar o Binary Reader do AWS DMS para acessar os redo logs e Privilégios adicionais de conta necessários ao utilizar o Binary Reader com o Oracle ASM.
Para obter mais informações sobre como configurar a CDC para um banco de dados Oracle gerenciado pela AWS como origem, consulte Configurar uma tarefa de CDC para utilizar o Binary Reader com uma origem do RDS para Oracle do AWS DMS e Utilizar um Amazon RDS Oracle Standby (réplica de leitura) como origem com o Binary Reader para CDC no AWS DMS.
Fluxos de trabalho para configurar um banco de dados de origem Oracle gerenciado pela AWS no AWS DMS
Configurar um banco de dados de origem Oracle
Para configurar uma instância de banco de dados de origem autogerenciado, utilize as seguintes etapas, dependendo de como você executa a CDC.
Utilize as seguintes etapas do fluxo de trabalho para configurar uma instância de banco de dados de origem Oracle gerenciado pela AWS.
Para esta etapa do fluxo de trabalho | Se você executar a CDC utilizando o LogMiner, faça isso | Se você executar a CDC utilizando o Binary Reader, faça isso |
---|---|---|
Conceda privilégios à conta Oracle. | Para ter mais informações, consulte Privilégios de conta de usuário necessários em uma origem do Oracle gerenciado pela AWS do AWS DMS. | Para ter mais informações, consulte Privilégios de conta de usuário necessários em uma origem do Oracle gerenciado pela AWS do AWS DMS. |
Prepare o banco de dados de origem para replicação utilizando a CDC. | Para ter mais informações, consulte Configurar uma origem Oracle gerenciado pela AWS do AWS DMS. | Para ter mais informações, consulte Configurar uma origem Oracle gerenciado pela AWS do AWS DMS. |
Conceda privilégios adicionais ao usuário do Oracle necessários para a CDC. | Nenhum privilégio adicional de conta é necessário. | Para ter mais informações, consulte Configurar uma tarefa de CDC para utilizar o Binary Reader com uma origem do RDS para Oracle do AWS DMS. |
Se ainda não fez isso, configure a tarefa para utilizar o LogMiner ou o Binary Reader para a CDC. | Para ter mais informações, consulte Utilizar o LogMiner do Oracle ou o Binary Reader do AWS DMS para CDC. | Para ter mais informações, consulte Utilizar o LogMiner do Oracle ou o Binary Reader do AWS DMS para CDC. |
Configure o Oracle Standby como origem para a CDC. | O AWS DMS não é compatível com o Oracle Standby como origem. | Para ter mais informações, consulte Utilizar um Amazon RDS Oracle Standby (réplica de leitura) como origem com o Binary Reader para CDC no AWS DMS. |
Trabalhar com um banco de dados Oracle autogerenciado como origem do AWS DMS
Um banco de dados autogerenciado é um banco de dados que você configura e controla, em uma instância de banco de dados on-premises ou em um banco de dados no Amazon EC2. Veja a seguir as informações sobre os privilégios e as configurações necessários ao utilizar um banco de dados Oracle autogerenciado com o AWS DMS.
Privilégios de conta de usuário necessários para utilizar uma origem do Oracle autogerenciado do AWS DMS
Para utilizar um banco de dados Oracle como origem no AWS DMS, conceda os seguintes privilégios ao usuário do Oracle especificado nas configurações de conexão do endpoint do Oracle.
nota
Ao conceder privilégios, utilize o nome real dos objetos, não o sinônimo de cada objeto. Por exemplo, utilize V_$OBJECT
incluindo o sublinhado, não V$OBJECT
sem o sublinhado.
GRANT CREATE SESSION TO
db_user
; GRANT SELECT ANY TRANSACTION TOdb_user
; GRANT SELECT ON V_$ARCHIVED_LOG TOdb_user
; GRANT SELECT ON V_$LOG TOdb_user
; GRANT SELECT ON V_$LOGFILE TOdb_user
; GRANT SELECT ON V_$LOGMNR_LOGS TOdb_user
; GRANT SELECT ON V_$LOGMNR_CONTENTS TOdb_user
; GRANT SELECT ON V_$DATABASE TOdb_user
; GRANT SELECT ON V_$THREAD TOdb_user
; GRANT SELECT ON V_$PARAMETER TOdb_user
; GRANT SELECT ON V_$NLS_PARAMETERS TOdb_user
; GRANT SELECT ON V_$TIMEZONE_NAMES TOdb_user
; GRANT SELECT ON V_$TRANSACTION TOdb_user
; GRANT SELECT ON V_$CONTAINERS TOdb_user
; GRANT SELECT ON ALL_INDEXES TOdb_user
; GRANT SELECT ON ALL_OBJECTS TOdb_user
; GRANT SELECT ON ALL_TABLES TOdb_user
; GRANT SELECT ON ALL_USERS TOdb_user
; GRANT SELECT ON ALL_CATALOG TOdb_user
; GRANT SELECT ON ALL_CONSTRAINTS TOdb_user
; GRANT SELECT ON ALL_CONS_COLUMNS TOdb_user
; GRANT SELECT ON ALL_TAB_COLS TOdb_user
; GRANT SELECT ON ALL_IND_COLUMNS TOdb_user
; GRANT SELECT ON ALL_ENCRYPTED_COLUMNS TOdb_user
; GRANT SELECT ON ALL_LOG_GROUPS TOdb_user
; GRANT SELECT ON ALL_TAB_PARTITIONS TOdb_user
; GRANT SELECT ON SYS.DBA_REGISTRY TOdb_user
; GRANT SELECT ON SYS.OBJ$ TOdb_user
; GRANT SELECT ON DBA_TABLESPACES TOdb_user
; GRANT SELECT ON DBA_OBJECTS TOdb_user
; -– Required if the Oracle version is earlier than 11.2.0.3. GRANT SELECT ON SYS.ENC$ TOdb_user
; -– Required if transparent data encryption (TDE) is enabled. For more information on using Oracle TDE with AWS DMS, see Métodos de criptografia com suporte para uso do Oracle como origem do AWS DMS. GRANT SELECT ON GV_$TRANSACTION TOdb_user
; -– Required if the source database is Oracle RAC in AWS DMS versions 3.4.6 and higher. GRANT SELECT ON V_$DATAGUARD_STATS TOdb_user
; -- Required if the source database is Oracle Data Guard and Oracle Standby is used in the latest release of DMS version 3.4.6, version 3.4.7, and higher. GRANT SELECT ON V$DATABASE_INCARNATION TOdb_user
;
Conceda o privilégio adicional a seguir para cada tabela replicada ao utilizar uma lista de tabelas específica.
GRANT SELECT on
any-replicated-table
todb_user
;
Conceda o seguinte privilégio adicional para validar colunas LOB com o recurso de validação.
GRANT EXECUTE ON SYS.DBMS_CRYPTO TO
db_user
;
Conceda o privilégio adicional a seguir se você utilizar o Binary Reader em vez do LogMiner.
GRANT SELECT ON SYS.DBA_DIRECTORIES TO
db_user
;
Conceda o seguinte privilégio adicional para expor visualizações.
GRANT SELECT on ALL_VIEWS to
dms_user
;
Para expor visualizações, adicione também o atributo de conexão adicional do exposeViews=true
ao endpoint de origem.
Conceda o seguinte privilégio adicional ao utilizar replicações com tecnologia sem servidor.
GRANT SELECT on dba_segments to
db_user
;
Para obter informações sobre as replicações com tecnologia sem servidor, consulte Trabalhando com AWS DMS Serverless.
Conceda os seguintes privilégios adicionais ao utilizar avaliações de pré-migração específicas do Oracle.
GRANT SELECT on gv_$parameter to
dms_user
; GRANT SELECT on v_$instance todms_user
; GRANT SELECT on v_$version todms_user
; GRANT SELECT on gv_$ASM_DISKGROUP todms_user
; GRANT SELECT on gv_$database todms_user
; GRANT SELECT on dba_db_links todms_user
; GRANT SELECT on gv_$log_History todms_user
; GRANT SELECT on gv_$log todms_user
; GRANT SELECT ON DBA_TYPES TOdb_user
; GRANT SELECT ON DBA_USERS to dms_user; GRANT SELECT ON DBA_DIRECTORIES to dms_user;
Para obter informações sobre avaliações de pré-migração específicas do Oracle, consulte. Avaliações do Oracle
Pré-requisitos para tratar transações abertas do Oracle Standby
Ao utilizar as versões 3.4.6 e superiores do AWS DMS, execute as etapas a seguir para tratar transações abertas do Oracle Standby.
-
Crie um link de banco de dados nomeado
AWSDMS_DBLINK
no banco de dados primário. O
utilizará o link de banco de dados para conectar-se ao banco de dados primário. Observe que o link de banco de dados é executado na instância em espera para consultar as transações abertas em execução no banco de dados primário. Veja o exemplo a seguir.DMS_USER
CREATE PUBLIC DATABASE LINK AWSDMS_DBLINK CONNECT TO
DMS_USER
IDENTIFIED BYDMS_USER_PASSWORD
USING '(DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_HOST_NAME_OR_IP
)(PORT=PORT
)) (CONNECT_DATA=(SERVICE_NAME=SID
)) )'; -
Verifique se a conexão ao link de banco de dados que utiliza o
está estabelecida conforme mostrado no exemplo a seguir.DMS_USER
select 1 from dual@AWSDMS_DBLINK
Preparar um banco de dados de origem Oracle autogerenciado para a CDC utilizando o AWS DMS
Prepare seu banco de dados Oracle autogerenciado como origem para executar uma tarefa de CDC fazendo o seguinte:
Verificar se o AWS DMS é compatível com a versão do banco de dados de origem
Execute uma consulta, como a seguinte, para verificar se a versão atual do banco de dados Oracle é compatível com o AWS DMS.
SELECT name, value, description FROM v$parameter WHERE name = 'compatible';
Aqui, name
, value
e description
são colunas em algum local no banco de dados que estão sendo consultadas com base no valor de name
. Se essa consulta for executada sem erros, o AWS DMS será compatível com a versão atual do banco de dados e você poderá continuar com a migração. Se a consulta resultar em erro, o AWS DMS não será compatível com essa versão do banco de dados. Para continuar com a migração, primeiro converta o banco de dados Oracle em uma versão compatível com o AWS DMS.
Verificar se o modo ARCHIVELOG está ativado
É possível executar o Oracle em dois modos diferentes: o modo ARCHIVELOG
e o modo NOARCHIVELOG
. Para executar uma tarefa de CDC, execute o banco de dados no modo ARCHIVELOG
. Para saber se o banco de dados está no modo ARCHIVELOG
, execute a consulta a seguir.
SQL> SELECT log_mode FROM v$database;
Se for retornado o modo NOARCHIVELOG
, defina o banco de dados como ARCHIVELOG
de acordo com as instruções do Oracle.
Configuração de registro em log suplementar
Para capturar as alterações em andamento, o AWS DMS requer que você ative o registro em log suplementar mínimo no banco de dados Oracle de origem. Além disso, você precisa ativar o registro em log suplementar em cada tabela replicada no banco de dados.
Por padrão, o AWS DMS adiciona o registro em log suplementar PRIMARY KEY
em todas as tabelas replicadas. Para permitir que o AWS DMS adicione registros em log suplementares de PRIMARY KEY
, conceda o seguinte privilégio a cada tabela replicada.
ALTER on
any-replicated-table
;
É possível desativar o registro em log suplementar de PRIMARY KEY
adicionado pelo AWS DMS utilizando o atributo de conexão adicional addSupplementalLogging
. Para ter mais informações, consulte Configurações de endpoint ao utilizar o Oracle como origem do AWS DMS.
Ative o registro em log suplementar se a tarefa de replicação atualizar uma tabela utilizando uma cláusula WHERE
que não faz referência a uma coluna de chave primária.
Como configurar o registro em log suplementar manualmente
-
Execute a consulta a seguir para verificar se o registro em log suplementar está ativado para o banco de dados.
SELECT supplemental_log_data_min FROM v$database;
Se o resultado retornado for
YES
ouIMPLICIT
, o registro em log suplementar estará ativado para o banco de dados.Se necessário, ative o registro em log suplementar para o banco de dados executando o comando a seguir.
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
-
Verifique se o registro em log suplementar necessário está adicionado a cada tabela replicada.
Considere o seguinte:
-
Se o registro em log suplementar
ALL COLUMNS
estiver adicionado à tabela, não será necessário adicionar mais registros em log. -
Se houver uma chave primária, adicione o registro em log suplementar à chave primária. É possível fazer isso utilizando o formato para adicionar registro em log suplementar à chave primária ou adicionando o registro em log suplementar às colunas de chave primária no banco de dados.
ALTER TABLE Tablename ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
-
Se não houver uma chave primária e a tabela possuir um único índice exclusivo, adicione todas as colunas do índice exclusivo ao log suplementar.
ALTER TABLE
TableName
ADD SUPPLEMENTAL LOG GROUPLogGroupName
(UniqueIndexColumn1
[,UniqueIndexColumn2
] ...) ALWAYS;Usar
SUPPLEMENTAL LOG DATA (UNIQUE INDEX) COLUMNS
não faz com que as colunas do índice exclusivo sejam adicionadas ao log. -
Se não existir nenhuma chave primária e a tabela tiver vários índices exclusivos, o AWS DMS selecionará o primeiro índice exclusivo em uma lista ordenada de forma alfabética em ordem crescente. Você precisa adicionar registro em log suplementar nas colunas do índice selecionado, como no item anterior.
Usar
SUPPLEMENTAL LOG DATA (UNIQUE INDEX) COLUMNS
não faz com que as colunas do índice exclusivo sejam adicionadas ao log. -
Se não houver uma chave primária e não houver um índice exclusivo, adicione o registro em log suplementar em todas as colunas.
ALTER TABLE
TableName
ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;Em alguns casos, a chave primária da tabela de destino ou índice exclusivo são diferentes da chave primária da tabela de origem ou índice exclusivo. Nesses casos, adicione o registro em log suplementar manualmente nas colunas da tabela de origem que compõem a chave primária da tabela ou o índice exclusivo de destino.
Além disso, se você alterar a chave primária da tabela de destino, adicione o registro complementar às colunas do índice exclusivo de destino, em vez das colunas do índice exclusivo ou da chave primária de origem.
-
Se um filtro ou uma transformação for definida para uma tabela, talvez seja necessário habilitar o registro em log adicional.
Considere o seguinte:
-
Se o registro em log suplementar
ALL COLUMNS
estiver adicionado à tabela, não será necessário adicionar mais registros em log. -
Se a tabela tiver um índice exclusivo ou uma chave primária, adicione registro em log suplementar a cada coluna envolvida em um filtro ou transformação. No entanto, faça isso somente se essas colunas forem diferentes da chave primária ou das colunas do índice exclusivo.
-
Se uma transformação incluir apenas uma coluna, não adicione essa coluna a um grupo de registro em log suplementar. Por exemplo, para uma transformação
A+B
, adicione registro em log suplementar em ambas as colunasA
eB
. No entanto, para uma transformaçãosubstring(A,10)
, não adicione registro em log suplementar à colunaA
. -
Para configurar o registro em log suplementar em colunas de índice exclusivo ou de chave primária e outras colunas específicas filtradas ou transformadas, é possível adicionar o registro em log suplementar
USER_LOG_GROUP
. Adicione esse registro em log suplementar às colunas de chave primária ou ao índice exclusivo e às outras colunas específicas filtradas ou transformadas.Por exemplo, para replicar uma tabela nomeada
TEST.LOGGING
com chave primáriaID
e um filtro pela colunaNAME
, é possível executar um comando semelhante ao seguinte para criar o registro em log suplementar do grupo de logs.ALTER TABLE TEST.LOGGING ADD SUPPLEMENTAL LOG GROUP TEST_LOG_GROUP (ID, NAME) ALWAYS;
Privilégios necessários da conta ao utilizar o LogMiner do Oracle para acessar os redo logs
Para acessar os redo logs utilizando o LogMiner do Oracle, conceda os seguintes privilégios ao usuário do Oracle especificado nas configurações de conexão de endpoint do Oracle:
GRANT EXECUTE on DBMS_LOGMNR to db_user; GRANT SELECT on V_$LOGMNR_LOGS to db_user; GRANT SELECT on V_$LOGMNR_CONTENTS to db_user; GRANT LOGMINING to db_user; -– Required only if the Oracle version is 12c or higher.
Privilégios necessários de conta ao utilizar o Binary Reader do AWS DMS para acessar os redo logs
Para acessar os redo logs utilizando o Binary Reader do AWS DMS, conceda os seguintes privilégios ao usuário do Oracle especificado nas configurações de conexão do endpoint do Oracle:
GRANT SELECT on v_$transportable_platform to db_user; -– Grant this privilege if the redo logs are stored in Oracle Automatic Storage Management (ASM) and AWS DMS accesses them from ASM. GRANT CREATE ANY DIRECTORY to db_user; -– Grant this privilege to allow AWS DMS to use Oracle BFILE read file access in certain cases. This access is required when the replication instance doesn't have file-level access to the redo logs and the redo logs are on non-ASM storage. GRANT EXECUTE on DBMS_FILE_TRANSFER to db_user; -– Grant this privilege to copy the redo log files to a temporary folder using the CopyToTempFolder method. GRANT EXECUTE on DBMS_FILE_GROUP to db_user;
O Binary Reader funciona com recursos de arquivo Oracle que incluem diretórios do Oracle. Cada objeto no diretório do Oracle inclui o nome da pasta que contém os arquivos de logs redo a serem processados. Esses diretórios do Oracle não são representados no nível do sistema de arquivos. Eles são diretórios lógicos criados no nível do banco de dados Oracle. É possível exibi-los na visualização ALL_DIRECTORIES
do Oracle.
Se você quiser que o AWS DMS crie esses diretórios do Oracle, conceda o privilégio CREATE
ANY DIRECTORY
especificado anteriormente. O AWS DMS cria os nomes de diretório com o prefixo DMS_
. Se você não conceder o privilégio CREATE ANY DIRECTORY
, crie os diretórios correspondentes manualmente. Em alguns casos, ao criar os diretórios do Oracle manualmente, o usuário do Oracle especificado no endpoint de origem Oracle não é o usuário que criou esses diretórios. Nesses casos, também conceda o privilégio READ
on DIRECTORY
.
Se o endpoint do Oracle de origem estiver no Active Dataguard Standby (ADG), consulte a postagem Como utilizar o Binary Reader com o ADG
nota
A AWS DMS CDC não é compatível com o Active Dataguard Standby que não está configurado para utilizar o serviço de transporte automático de refazer.
Em alguns casos, é possível utilizar o Oracle Managed Files (OMF) para armazenar os logs. Ou endpoint de origem está no ADG e, portanto, o privilégio CREATE ANY DIRECTORY não pode ser concedido. Nesses casos, crie manualmente os diretórios com todos os locais de log possíveis antes de iniciar a tarefa de replicação do AWS DMS. Se o AWS DMS não encontrar um diretório pré-criado que é esperado, a tarefa será interrompida. Além disso, o AWS DMS não exclui as entradas que criou na visualização ALL_DIRECTORIES
, portanto, exclua-as manualmente.
Privilégios adicionais de conta necessários ao utilizar o Binary Reader com o Oracle ASM
Para acessar os redo logs no Automatic Storage Management (ASM) utilizando o Binary Reader, conceda os seguintes privilégios ao usuário do Oracle especificado nas configurações de conexão de endpoint do Oracle:
SELECT ON v_$transportable_platform SYSASM -– To access the ASM account with Oracle 11g Release 2 (version 11.2.0.2) and higher, grant the Oracle endpoint user the SYSASM privilege. For older supported Oracle versions, it's typically sufficient to grant the Oracle endpoint user the SYSDBA privilege.
É possível validar o acesso à conta do ASM abrindo um prompt de comando e invocando uma das instruções a seguir, dependendo da versão do Oracle, conforme especificado anteriormente.
Se o privilégio SYSDBA
for necessário, use o seguinte.
sqlplus
asmuser
/asmpassword
@+asmserver
as sysdba
Se o privilégio SYSASM
for necessário, use o seguinte.
sqlplus
asmuser
/asmpassword
@+asmserver
as sysasm
Utilizar um Oracle Standby autogerenciado como origem com o Binary Reader para CDC no AWS DMS
Para configurar uma instância do Oracle Standby como origem ao utilizar o Binary Reader para CDC, comece com os seguintes pré-requisitos:
-
Atualmente, o AWS DMS é compatível somente com o Oracle Active Data Guard Standby.
-
Verifique se a configuração do Oracle Data Guard utiliza:
-
Serviços de transporte de refazer para transferências automatizadas de dados de refazer.
-
Aplique serviços para aplicar automaticamente refazer banco de dados em espera.
-
Para confirmar se esses requisitos foram atendidos, execute a consulta a seguir.
SQL> select open_mode, database_role from v$database;
Na saída dessa consulta, confirme se o banco de dados em espera está aberto no modo SOMENTE LEITURA e se refazer está sendo aplicado automaticamente. Por exemplo:
OPEN_MODE DATABASE_ROLE -------------------- ---------------- READ ONLY WITH APPLY PHYSICAL STANDBY
Como configurar uma instância do Oracle Standby como origem ao utilizar o Binary Reader para CDC
-
Conceda privilégios adicionais necessários para acessar arquivos de log em espera.
GRANT SELECT ON v_$standby_log TO
db_user
; -
Crie um endpoint de origem para o Oracle Standby utilizando o AWS Management Console ou a AWS CLI. Ao criar o endpoint, especifique os seguintes atributos de conexão adicionais.
useLogminerReader=N;useBfile=Y;
nota
No AWS DMS, é possível utilizar atributos de conexão adicionais para especificar se deseja migrar dos logs de arquivamento em vez dos redo logs. Para ter mais informações, consulte Configurações de endpoint ao utilizar o Oracle como origem do AWS DMS.
-
Configure o destino do log arquivado.
O Binary Reader do DMS da origem do Oracle sem ASM utiliza diretórios do Oracle para acessar os redo logs arquivados. Se o banco de dados estiver configurado para utilizar Fast Recovery Area (FRA) como destino do log de arquivamento, a localização dos arquivos de refazer de arquivamento não é constante. Cada dia em que redo logs arquivados são gerados resulta em um novo diretório criado no FRA, utilizando o formato de nome de diretório AAAA_MM_DD. Por exemplo:
DB_RECOVERY_FILE_DEST
/SID
/archivelog/YYYY_MM_DD
Quando o DMS precisa acessar arquivos de refazer arquivados no diretório FRA recém-criado, e o banco de dados primário de leitura e gravação está sendo utilizado como origem, o DMS cria um novo diretório Oracle ou substitui um existente, da seguinte forma.
CREATE OR REPLACE DIRECTORY
dmsrep_taskid
AS ‘DB_RECOVERY_FILE_DEST
/SID
/archivelog/YYYY_MM_DD
’;Quando o banco de dados em espera está sendo utilizado como origem, o DMS não pode criar ou substituir o diretório Oracle porque o banco de dados está no modo somente leitura. Porém, é possível optar por executar uma dessas etapas adicionais:
-
Modificar
log_archive_dest_id_1
para utilizar um caminho real em vez do FRA em uma configuração que o Oracle não crie subdiretórios diariamente:ALTER SYSTEM SET log_archive_dest_1=’LOCATION=
full directory path
’Criar um objeto no diretório Oracle para ser utilizado pelo DMS:
CREATE OR REPLACE DIRECTORY dms_archived_logs AS ‘
full directory path
’; -
Criar um destino adicional de log de arquivamento e um objeto no diretório Oracle apontando para esse destino. Por exemplo:
ALTER SYSTEM SET log_archive_dest_3=’LOCATION=
full directory path
’; CREATE DIRECTORY dms_archived_log AS ‘full directory path
’;Adicionar um atributo de conexão adicional ao endpoint da origem da tarefa:
archivedLogDestId=3
-
Pré-crie manualmente objetos no diretório Oracle para serem utilizados pelo DMS.
CREATE DIRECTORY
dms_archived_log_20210301
AS ‘DB_RECOVERY_FILE_DEST/SID/archivelog/2021_03_01
’; CREATE DIRECTORYdms_archived_log_20210302
AS ‘DB_RECOVERY_FILE_DEST>/SID>/archivelog/2021_03_02
’; ... -
Criar uma tarefa do programador do Oracle que seja executada diariamente e criar o diretório necessário.
-
Utilizar um banco de dados gerenciado pelo usuário no Oracle Cloud Infrastructure (OCI) como origem da CDC no AWS DMS
Um banco de dados gerenciado pelo usuário é um banco de dados que você configura e controla, como um banco de dados Oracle criado em uma máquina virtual (VM), bare metal ou servidor Exadata. Ou bancos de dados que você configura e controla que são executados em uma infraestrutura dedicada, como o Oracle Cloud Infrastructure (OCI). As informações a seguir descrevem os privilégios e as configurações necessárias ao utilizar um banco de dados Oracle gerenciado pelo usuário no OCI como origem para a captura de dados de alteração (CDC) no AWS DMS.
Para configurar um banco de dados Oracle gerenciado pelo usuário hospedado pelo OCI como origem para a captura de dados de alteração
-
Conceda os privilégios da conta de usuário necessários para utilizar um banco de dados de origem do Oracle gerenciado pelo usuário no OCI. Para obter mais informações, consulte Privilégios de conta para um endpoint de origem do Oracle autogerenciado.
-
Conceda os privilégios da conta necessários ao utilizar o Binary Reader para acessar os redo logs. Para obter mais informações, consulte Privilégios da conta necessários ao utilizar o Binary Reader.
-
Adicione os privilégios da conta necessários ao utilizar o Binary Reader com o Oracle Automatic Storage Management (ASM). Para obter mais informações, consulte Privilégios adicionais da conta necessários ao utilizar o Binary Reader com o Oracle ASM.
-
Configure o registro em log suplementar. Para obter mais informações, consulte Configuração do registro em log suplementar.
-
Configure a criptografia de TDE. Para obter mais informações, consulte Métodos de criptografia ao utilizar um banco de dados Oracle como um endpoint de origem.
As limitações a seguir se aplicam ao replicar dados de um banco de dados de origem do Oracle no Oracle Cloud Infrastructure (OCI).
Limitações
-
O DMS não é compatível com a utilização do LogMiner do Oracle para acessar os redo logs.
-
O DMS não é compatível com o banco de dados autônomo.
Como trabalhar com um banco de dados Oracle gerenciado pela AWS como origem do AWS DMS
Um banco de dados gerenciado pela AWS é um banco de dados que está em um serviço da Amazon, como o Amazon RDS, o Amazon Aurora, ou o Amazon S3. Veja a seguir os privilégios e as configurações necessários para configuração ao utilizar um banco de dados Oracle gerenciado pela AWS com o AWS DMS.
Privilégios de conta de usuário necessários em uma origem do Oracle gerenciado pela AWS do AWS DMS
Conceda os seguintes privilégios à conta de usuário do Oracle especificada na definição do endpoint de origem do Oracle.
Importante
Para todos os valores de parâmetros, como
e db_user
, o Oracle pressupõe que o valor está todo em letras maiúsculas, a menos que você especifique o valor com um identificador que diferencia letras maiúsculas de minúsculas. Por exemplo, suponha que você crie um valor de any-replicated-table
sem utilizar aspas, como em db_user
CREATE USER
ou myuser
CREATE USER
MYUSER
. Nesse caso, o Oracle identifica e armazena o valor como todo em maiúsculas (MYUSER
). Se você utilizar aspas, como em CREATE USER "MyUser"
ouCREATE USER 'MyUser'
, o Oracle identificará e armazenará o valor com distinção entre maiúsculas e minúsculas que você especificar (MyUser
).
GRANT CREATE SESSION to
db_user
; GRANT SELECT ANY TRANSACTION todb_user
; GRANT SELECT on DBA_TABLESPACES todb_user
; GRANT SELECT ONany-replicated-table
todb_user
; GRANT EXECUTE on rdsadmin.rdsadmin_util todb_user
; -- For Oracle 12c or higher: GRANT LOGMINING to db_user; – Required only if the Oracle version is 12c or higher.
Além disso, conceda as permissões SELECT
e EXECUTE
em objetos SYS
utilizando o procedimento do Amazon RDS rdsadmin.rdsadmin_util.grant_sys_object
conforme mostrado. Para obter mais informações, consulte Conceder privilégios SELECT ou EXECUTE a objetos SYS.
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_VIEWS', '
db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_PARTITIONS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_INDEXES', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_OBJECTS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TABLES', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_USERS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CATALOG', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONSTRAINTS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_CONS_COLUMNS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_COLS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_IND_COLUMNS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_LOG_GROUPS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOG', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGFILE', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$THREAD', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$NLS_PARAMETERS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TIMEZONE_NAMES', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$TRANSACTION', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$CONTAINERS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_REGISTRY', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('OBJ$', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_ENCRYPTED_COLUMNS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_LOGS', 'db_user
', 'SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_CONTENTS','db_user
','SELECT'); exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_LOGMNR', 'db_user
', 'EXECUTE'); -- (as of Oracle versions 12.1 and higher) exec rdsadmin.rdsadmin_util.grant_sys_object('REGISTRY$SQLPATCH', 'db_user
', 'SELECT'); -- (for Amazon RDS Active Dataguard Standby (ADG)) exec rdsadmin.rdsadmin_util.grant_sys_object('V_$STANDBY_LOG', 'db_user
', 'SELECT'); -- (for transparent data encryption (TDE)) exec rdsadmin.rdsadmin_util.grant_sys_object('ENC$', 'db_user
', 'SELECT'); -- (for validation with LOB columns) exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_CRYPTO', 'db_user
', 'EXECUTE'); -- (for binary reader) exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_DIRECTORIES','db_user
','SELECT'); -- Required when the source database is Oracle Data guard, and Oracle Standby is used in the latest release of DMS version 3.4.6, version 3.4.7, and higher. exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATAGUARD_STATS', 'db_user
', 'SELECT');
Para obter mais informações sobre como utilizar o Amazon RDS Active Dataguard Standby (ADG) com o AWS DMS, consulte Utilizar um Amazon RDS Oracle Standby (réplica de leitura) como origem com o Binary Reader para CDC no AWS DMS.
Para obter mais informações sobre como utilizar o Oracle TDE com o AWS DMS, consulte Métodos de criptografia com suporte para uso do Oracle como origem do AWS DMS.
Pré-requisitos para tratar transações abertas do Oracle Standby
Ao utilizar as versões 3.4.6 e superiores do AWS DMS, execute as etapas a seguir para tratar transações abertas do Oracle Standby.
-
Crie um link de banco de dados nomeado
AWSDMS_DBLINK
no banco de dados primário. O
utilizará o link de banco de dados para conectar-se ao banco de dados primário. Observe que o link de banco de dados é executado na instância em espera para consultar as transações abertas em execução no banco de dados primário. Veja o exemplo a seguir.DMS_USER
CREATE PUBLIC DATABASE LINK AWSDMS_DBLINK CONNECT TO
DMS_USER
IDENTIFIED BYDMS_USER_PASSWORD
USING '(DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=PRIMARY_HOST_NAME_OR_IP
)(PORT=PORT
)) (CONNECT_DATA=(SERVICE_NAME=SID
)) )'; -
Verifique se a conexão ao link de banco de dados que utiliza o
está estabelecida conforme mostrado no exemplo a seguir.DMS_USER
select 1 from dual@AWSDMS_DBLINK
Configurar uma origem Oracle gerenciado pela AWS do AWS DMS
Antes de utilizar um banco de dados Oracle gerenciado pela AWS como origem do AWS DMS, execute as seguintes tarefas para o banco de dados Oracle:
-
Ative backups automáticos. Para obter mais informações sobre como ativar backups automáticos, consulte Ativar backups automáticos no Guia do usuário do Amazon RDS.
-
Configure o registro em log suplementar.
-
Configure o arquivamento. O arquivamento dos redo logs da instância de banco de dados Amazon RDS para Oracle permite que o AWS DMS recupere as informações do log utilizando o LogMiner do Oracle ou o Binary Reader.
Como configurar o arquivamento
-
Execute o comando
rdsadmin.rdsadmin_util.set_configuration
para configurar o arquivamento.Por exemplo, para reter os redo logs arquivados por 24 horas, execute o comando a seguir.
exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24); commit;
nota
A confirmação é necessária para que uma alteração entre em vigor.
-
Verifique se o armazenamento tem espaço suficiente para os redo logs arquivados durante o período de retenção especificado. Por exemplo, se o período de retenção for de 24 horas, calcule o tamanho total dos redo logs arquivados acumulados em uma hora típica de processamento de transações e multiplique esse total por 24. Compare esse total calculado de 24 horas com o espaço de armazenamento disponível e decida se você tem espaço de armazenamento suficiente para tratar o processamento de transações de um total 24 horas.
Como configurar o registro em log suplementar
-
Execute o comando a seguir para ativar o registro em log suplementar no nível de banco de dados.
exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD');
-
O exemplo a seguir ativa o registro em log suplementar de chave primária.
exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD','PRIMARY KEY');
-
(Opcional) Ative o registro em log suplementar em nível de chave no nível da tabela.
O banco de dados de origem incorre em pequenos custos quando o registro em log suplementar em nível de chave está ativado. Portanto, se estiver migrando apenas um subconjunto das tabelas, ative o registro em log suplementar de nível de chave no nível da tabela. Para ativar o registro em log suplementar de nível de chave no nível da tabela, execute o seguinte comando.
alter table table_name add supplemental log data (PRIMARY KEY) columns;
Configurar uma tarefa de CDC para utilizar o Binary Reader com uma origem do RDS para Oracle do AWS DMS
É possível configurar o AWS DMS para acessar os redo logs de origem da instância Amazon RDS para Oracle utilizando o Binary Reader para a CDC.
nota
Para utilizar o LogMiner do Oracle, os privilégios mínimos de conta de usuário necessários são suficientes. Para ter mais informações, consulte Privilégios de conta de usuário necessários em uma origem do Oracle gerenciado pela AWS do AWS DMS.
Para utilizar o Binary Reader do AWS DMS, especifique configurações adicionais e atributos de conexão adicionais para o endpoint de origem Oracle, dependendo da versão do AWS DMS.
A compatibilidade com o Binary Reader está disponível nas seguintes versões do Amazon RDS para Oracle:
-
Oracle 11.2, versões 11.2.0.4V11 e superior
-
Oracle 12.1, versões 12.1.0.2.V7 e superior
-
Oracle 12.2, todas as versões
-
Oracle 18.0, todas as versões
-
Oracle 19.0, todas as versões
Como configurar a CDC utilizando o Binary Reader
-
Faça login no banco de dados de origem do Amazon RDS para Oracle como o usuário mestre e execute os seguintes procedimentos armazenados para criar os diretórios em nível de servidor.
exec rdsadmin.rdsadmin_master_util.create_archivelog_dir; exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;
-
Conceda os seguintes privilégios à conta de usuário do Oracle utilizada para acessar o endpoint de origem do Oracle:
GRANT READ ON DIRECTORY ONLINELOG_DIR TO
db_user
; GRANT READ ON DIRECTORY ARCHIVELOG_DIR TOdb_user
; -
Defina os atributos de conexão adicionais a seguir no endpoint de origem Amazon RDS Oracle.
-
Para as versões 11.2 e 12.1 do RDS Oracle, defina o seguinte.
useLogminerReader=N;useBfile=Y;accessAlternateDirectly=false;useAlternateFolderForOnline=true; oraclePathPrefix=/rdsdbdata/db/{$DATABASE_NAME}_A/;usePathPrefix=/rdsdbdata/log/;replacePathPrefix=true;
-
Para as versões 12.2, 18.0 e 19.0 do RDS Oracle, defina o seguinte.
useLogminerReader=N;useBfile=Y;
-
nota
Verifique se não há nenhum espaço em branco após o separador de ponto e vírgula (;) em várias configurações de atributo, por exemplo, oneSetting;thenAnother
.
Para obter mais informações para configurar uma tarefa de CDC, consulte Configuração da CDC em um banco de dados Oracle de origem.
Utilizar um Amazon RDS Oracle Standby (réplica de leitura) como origem com o Binary Reader para CDC no AWS DMS
Verifique os seguintes pré-requisitos para utilizar o Amazon RDS para Oracle Standby como origem ao utilizar o Binary Reader para CDC no AWS DMS:
-
Utilize o usuário mestre do Oracle para configurar o Binary Reader.
-
Verifique se o AWS DMS atualmente é compatível com a utilização somente do Oracle Active Data Guard Standby.
Depois de fazer isso, utilize o procedimento a seguir para utilizar o RDS para Oracle Standby como origem ao utilizar o Binary Reader para CDC.
Como configurar um RDS para Oracle Standby como origem ao utilizar o Binary Reader para CDC
-
Faça login na instância primária do RDS para Oracle como usuário mestre.
-
Execute os seguintes procedimentos armazenados conforme documentado no Guia do usuário do Amazon RDS para criar os diretórios no nível do servidor.
exec rdsadmin.rdsadmin_master_util.create_archivelog_dir; exec rdsadmin.rdsadmin_master_util.create_onlinelog_dir;
-
Identifique os diretórios criados na etapa 2.
SELECT directory_name, directory_path FROM all_directories WHERE directory_name LIKE ( 'ARCHIVELOG_DIR_%' ) OR directory_name LIKE ( 'ONLINELOG_DIR_%' )
Por exemplo, o código anterior exibe uma lista de diretórios como a seguinte.
-
Conceda o privilégio
Read
nos diretórios anteriores à conta de usuário Oracle utilizada para acessar o Oracle Standby.GRANT READ ON DIRECTORY ARCHIVELOG_DIR_A TO
db_user
; GRANT READ ON DIRECTORY ARCHIVELOG_DIR_B TOdb_user
; GRANT READ ON DIRECTORY ONLINELOG_DIR_A TOdb_user
; GRANT READ ON DIRECTORY ONLINELOG_DIR_B TOdb_user
; -
Execute uma troca de log de arquivamento na instância primária. Isso garante que as alterações de
ALL_DIRECTORIES
também sejam transferidas para o Oracle Standby. -
Execute uma consulta
ALL_DIRECTORIES
no Oracle Standby para confirmar se as alterações foram aplicadas. -
Crie um endpoint de origem para o Oracle Standby utilizando o console de gerenciamento do AWS DMS ou a AWS Command Line Interface (AWS CLI). Ao criar o endpoint, especifique os seguintes atributos de conexão adicionais.
useLogminerReader=N;useBfile=Y;archivedLogDestId=1;additionalArchivedLogDestId=2
-
Depois de criar o endpoint, utilize Testar conexão de endpoint na página Criar endpoint do console ou o comando
test-connection
da AWS CLI para verificar se a conectividade foi estabelecida.
Limitações da utilização do Oracle como origem do AWS DMS
As seguintes limitações se aplicam quando um banco de dados Oracle é utilizado como origem do AWS DMS:
-
O AWS DMS é compatível com os tipos de dados Oracle Extended no AWS DMS versão 3.5.0 e superior.
-
O AWS DMS não é compatível com nomes de objetos longos (mais de 30 bytes).
-
O AWS DMS não é compatível com índices baseados em perfis.
-
Se você gerenciar o registro em log suplementar e realizar transformações em qualquer uma das colunas, verifique se o registro em log suplementar está ativado para todos os campos e colunas. Para obter mais informações sobre como configurar o registro em log suplementar, consulte os seguintes tópicos.
-
Para um banco de dados Oracle autogerenciado como origem, consulte Configuração de registro em log suplementar.
-
Para um banco de dados Oracle autogerenciado pela AWS como origem, consulte Configurar uma origem Oracle gerenciado pela AWS do AWS DMS.
-
-
O AWS DMS não é compatível com bancos de dados raiz de contêiner de vários locatários (CDB$ROOT). Ele é compatível com um PDB utilizando o Binary Reader.
-
O AWS DMS não é compatível com restrições adiadas.
-
Na versão 3.5.1 e superior do AWS DMS, os LOBs seguros são compatíveis somente por meio da realização de uma pesquisa de LOB.
-
O AWS DMS é compatível com a sintaxe
rename table table-name to new-table-name
para todas as versões 11 e superiores do Oracle. Essa sintaxe não é compatível para nenhum banco de dados de origem Oracle versão 10. -
O AWS DMS não replica os resultados da instrução DDL
ALTER TABLE ADD
. Em vez de replicarcolumn
data_type
DEFAULTdefault_value
para o destino, ele define a nova coluna comodefault_value
NULL
. -
Ao utilizar o AWS DMS versão 3.4.7 ou superior, para replicar as alterações resultantes das operações de partição ou subpartição, faça o seguinte antes de iniciar uma tarefa do DMS.
-
Crie manualmente a estrutura da tabela particionada (DDL);
-
Verifique se a DDL é a mesma na origem e no destino do Oracle;
-
Defina o atributo de conexão adicional
enableHomogenousPartitionOps=true
.
Para obter mais informações sobre
enableHomogenousPartitionOps
, consulte Configurações de endpoint ao utilizar o Oracle como origem do AWS DMS. Além disso, observe que em tarefas FULL+CDC, o DMS não replica as alterações de dados capturadas como parte das alterações em cache. Nesse caso de uso, recrie a estrutura da tabela no destino do Oracle e recarregue as tabelas em questão.Antes do AWS DMS versão 3.4.7:
O DMS não replica alterações de dados resultantes de operações de partição ou subpartição (
ADD
,DROP
,EXCHANGE
eTRUNCATE
). Essas atualizações podem causar os seguintes erros durante a replicação:-
Para operações
ADD
, atualizações e exclusões nos dados adicionados podem gerar um aviso de “0 linhas afetadas”. -
Para operações
DROP
eTRUNCATE
, novas inserções podem gerar erros de “duplicatas”. -
Operações
EXCHANGE
podem gerar um aviso de “0 linhas afetadas” e erros de “duplicatas”.
Para replicar alterações resultantes de operações de partição ou subpartição, recarregue as tabelas em questão. Depois de adicionar uma nova partição vazia, as operações na partição adicionada são replicadas para o destino como normais.
-
-
As versões anteriores à 3.4 do AWS DMS não são compatíveis com todas as alterações de dados no destino que resultam da execução da instrução
CREATE TABLE AS
na origem. No entanto, a nova tabela é criada no destino. -
O AWS DMS não captura as alterações feitas pelo pacote Oracle
DBMS_REDEFINITION
, por exemplo, os metadados da tabela e o campoOBJECT_ID
. -
O AWS DMS mapeia colunas de BLOB e CLOB vazias para
NULL
no destino. -
Ao capturar alterações com o Oracle 11 LogMiner, uma atualização em uma coluna de CLOB com um tamanho de string maior que 1.982 é perdida e o destino não é atualizado.
-
Durante a captura de dados de alteração (CDC), o AWS DMS não é compatível com atualizações em lote para colunas numéricas definidas como chave primária.
-
O AWS DMS não é compatível com determinados comandos
UPDATE
. O exemplo a seguir é um comandoUPDATE
não compatível.UPDATE TEST_TABLE SET KEY=KEY+1;
Aqui,
TEST_TABLE
é o nome da tabela eKEY
é uma coluna numérica definida como chave primária. -
O AWS DMS não é compatível com o modo LOB completo para carregar colunas LONG e LONG RAW. Em vez disso, é possível utilizar o modo LOB limitado para migrar esses tipos de dados para um destino do Oracle. No modo LOB limitado, o AWS DMS trunca todos os dados de 64 KB definidos como colunas LONG ou LONG RAW com mais de 64 KB.
-
O AWS DMS não é compatível com o modo LOB completo para carregar colunas XMLTYPE. Em vez disso, é possível utilizar o modo LOB limitado para migrar colunas XMLTYPE para um destino do Oracle. No modo LOB limitado, o DMS trunca todos os dados maiores que a variável “Tamanho máximo de LOB” definida pelo usuário. O valor máximo recomendado para “Tamanho máximo de LOB” é 100 MB.
-
O AWS DMS não replica tabelas cujos nomes contêm apóstrofes.
-
O AWS DMS é compatível com a CDC em visões materializadas. Mas o DMS não é compatível com a CDC de nenhuma outra visualização.
-
O AWS DMS não é compatível com tabelas organizadas por índice com um segmento excedente.
-
OAWS DMS não é compatível com a operação
Drop Partition
para tabelas particionadas por referência comenableHomogenousPartitionOps
definido comotrue
. -
Ao utilizar o LogMiner do Oracle para acessar os redo logs, o AWS DMS tem as seguintes limitações:
-
Somente para o Oracle 12, o AWS DMS não replica nenhuma alteração para colunas de LOB.
-
Para todas as versões do Oracle, o AWS DMS não replica o resultado das operações
UPDATE
em colunas de LOB eXMLTYPE
. -
O AWS DMS não é compatível com transações XA na replicação ao utilizar o LogMiner do Oracle.
-
O LogMiner do Oracle não é compatível com conexões com um banco de dados conectável (PDB). Para conectar-se a um PDB, acesse os redo logs utilizando o Binary Reader.
-
As operações SHRINK SPACE não são compatíveis.
-
-
Ao utilizar o Binary Reader, o AWS DMS tem as seguintes limitações:
-
Ele não é compatível com clusters de tabela.
-
Ele é compatível somente com operações
SHRINK SPACE
em nível da tabela. Esse nível inclui a tabela completa, as partições e as subpartições. -
Ele não é compatível com alterações em tabelas organizadas por índice com compactação de chaves.
-
Ele não é compatível com a implementação de redo logs on-line em dispositivos brutos.
-
O Binary Reader é compatível com a TDE somente para bancos de dados Oracle autogerenciados, uma vez que o RDS para Oracle não é compatível com a recuperação de senha de carteira para chaves de criptografia da TDE.
-
-
O AWS DMS não é compatível com conexões com uma origem do Amazon RDS para Oracle utilizando um proxy do Oracle Automatic Storage Management (ASM).
-
O AWS DMS não é compatível com colunas virtuais.
-
O AWS DMS não é compatível com o tipo de dados
ROWID
ou visões materializadas com base em uma coluna ROWID.O AWS DMS é compatível parcialmente com visões materializadas do Oracle. Para cargas máximas, o DMS pode fazer uma cópia da carga máxima de uma visão materializada do Oracle. O DMS copia a visão materializada como uma tabela base para o sistema de destino e ignora todas as colunas ROWID na visão materializada. Para a replicação contínua (CDC), o DMS tenta replicar as alterações nos dados da visão materializada, mas os resultados podem não ser ideais. Especificamente, se a visão materializada estiver completamente atualizada, o DMS replica exclusões individuais de todas as linhas, seguidas por inserções individuais em todas as linhas. Esse é um exercício que consome muitos recursos e pode ter um desempenho inadequado em visões materializadas com um grande número de linhas. Para a replicação contínua em que as visões materializadas fazem uma atualização rápida, o DMS tenta processar e replicar as alterações de dados de atualização rápida. Em ambos os casos, o DMS ignora qualquer coluna ROWID na visão materializada.
-
O AWS DMS não carrega nem captura tabelas temporárias globais.
-
Para destinos do S3 que utilizam a replicação, ative o registro em log suplementar em cada coluna para que as atualizações da linha de origem possam capturar cada valor da coluna. Veja a seguir um exemplo:
alter table yourtablename add supplemental log data (all) columns;
. -
Uma atualização de uma linha com uma chave exclusiva composta que contém
null
não pode ser replicada no destino. -
O AWS DMS não é compatível com a utilização de várias chaves de criptografia TDE do Oracle no mesmo endpoint de origem. Cada endpoint pode ter somente um atributo para o nome da chave de criptografia da TDE "
securityDbEncryptionName
" e uma senha da TDE para essa chave. -
Ao replicar do Amazon RDS para Oracle, a TDE é compatível somente com espaço de tabela criptografado e utilizando o LogMiner do Oracle.
-
O AWS DMS não é compatível com várias operações de renomeação de tabelas em rápida sucessão.
-
Ao utilizar o Oracle 19.0 como origem, o AWS DMS não é compatível com os seguintes recursos:
-
Redirecionamento de DML do Data-guard
-
Tabelas particionadas híbridas
-
Contas Oracle somente de esquemas
-
-
O AWS DMS não é compatível com a migração de tabelas ou visualizações do tipo
BIN$
ouDR$
. -
A partir do Oracle 18.x, o AWS DMS não é compatível com a captura de dados de alteração (CDC) do Oracle Express Edition (Oracle Database XE).
-
Ao migrar dados de uma coluna CHAR, o DMS trunca todos os espaços à direita.
-
O AWS DMS não é compatível com a replicação em contêineres de aplicações.
-
O AWS DMS não é compatível com a execução do Oracle Flashback Database e dos pontos de restauração, pois essas operações afetam a consistência dos arquivos de redo log do Oracle.
-
O procedimento de carga direta
INSERT
com a opção de execução paralela não é compatível nos seguintes casos:-
Tabelas não compactadas com mais de 255 colunas
-
O tamanho da linha excede 8K
-
Tabelas do Exadata HCC
-
Banco de dados em execução na plataforma Big Endian
-
-
Uma tabela de origem sem chave primária ou exclusiva exige que o registro em log suplementar ALL COLUMN esteja ativado. Ele cria mais atividades no redo log e pode aumentar a latência da CDC do DMS.
-
O AWS DMS não migra dados de colunas invisíveis no banco de dados de origem. Para incluir essas colunas no escopo da migração, utilize a instrução
ALTER TABLE
para tornar essas colunas visíveis.
Suporte de SSL para um endpoint do Oracle
Os endpoints do AWS DMS Oracle são compatíveis com o SSL V3 para os modos SSL none
e verify-ca
. Para utilizar SSL com um endpoint do Oracle, carregue o Oracle Wallet para o endpoint, em vez de nos arquivos de certificado .pem.
Tópicos
Utilizar um certificado existente para SSL no Oracle
Para utilizar uma instalação cliente existente do Oracle e criar o arquivo Oracle Wallet a partir de um arquivo de certificado CA, siga as seguintes etapas.
Como utilizar uma instalação cliente existente do Oracle para SSL no Oracle com o AWS DMS
-
Defina a variável do sistema
ORACLE_HOME
como local do seu diretóriodbhome_1
, executando o comando a seguir.prompt>export ORACLE_HOME=/home/user/app/user/product/12.1.0/dbhome_1
-
Anexe
$ORACLE_HOME/lib
ao sistema variávelLD_LIBRARY_PATH
.prompt>export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib
-
Crie um diretório para o Oracle Wallet em
$ORACLE_HOME/ssl_wallet
.prompt>mkdir $ORACLE_HOME/ssl_wallet
-
Coloque o arquivo
.pem
de certificado da CA no diretóriossl_wallet
. Se você utilizar o Amazon RDS, poderá baixar o arquivo raiz do certificado a CArds-ca-2015-root.pem
hospedado pelo Amazon RDS. Para obter mais informações sobre como baixar esse arquivo, consulte Utilizar o SSL/TLS para criptografar uma conexão com uma instância de banco de dados no Guia do usuário do Amazon RDS. -
Execute os seguintes comandos para criar o Oracle Wallet.
prompt>orapki wallet create -wallet $ORACLE_HOME/ssl_wallet -auto_login_only prompt>orapki wallet add -wallet $ORACLE_HOME/ssl_wallet -trusted_cert -cert $ORACLE_HOME/ssl_wallet/ca-cert.pem -auto_login_only
Ao concluir as etapas anteriores, é possível importar o arquivo wallet com a chamada de API ImportCertificate
, especificando o parâmetro certificate-wallet. Utilize o certificado wallet importado ao selecionar verify-ca
como modo SSL ao criar ou modificar o seu endpoint do Oracle.
nota
As carteiras Oracle são arquivos binários. AWS O DMS aceita esses arquivos no estado em que se encontram.
Utilizar um certificado autoassinado para SSL no Oracle
Para utilizar um certificado autoassinado para SSL no Oracle, siga as etapas a seguir, pressupondo uma senha de carteira Oracle de oracle123
.
Como utilizar um certificado autoassinado para SSL no Oracle com o AWS DMS
-
Crie um diretório que será utilizado para trabalhar com o certificado autoassinado.
mkdir -p /u01/app/oracle/self_signed_cert
-
Altere para o diretório que você criou na etapa anterior.
cd /u01/app/oracle/self_signed_cert
-
Crie uma chave raiz.
openssl genrsa -out self-rootCA.key 2048
-
Autoassine um certificado raiz utilizando a chave criada na etapa anterior.
openssl req -x509 -new -nodes -key self-rootCA.key -sha256 -days 3650 -out self-rootCA.pem
Utilize os parâmetros de entrada, como os seguintes:
-
Country Name (2 letter code) [XX]
, por exemplo:AU
-
State or Province Name (full name) []
, por exemplo:NSW
-
Locality Name (e.g., city) [Default City]
, por exemplo:Sydney
-
Organization Name (e.g., company) [Default Company Ltd]
, por exemplo:AmazonWebService
-
Organizational Unit Name (e.g., section) []
, por exemplo:DBeng
-
Common Name (e.g., your name or your server's hostname) []
, por exemplo:aws
-
Email Address []
, por exemplo: abcd.efgh@amazonwebservice.com
-
-
Crie um diretório do Oracle Wallet para o banco de dados Oracle.
mkdir -p /u01/app/oracle/wallet
-
Crie um novo Oracle Wallet.
orapki wallet create -wallet "/u01/app/oracle/wallet" -pwd oracle123 -auto_login_local
-
Adicione o certificado raiz ao Oracle Wallet.
orapki wallet add -wallet "/u01/app/oracle/wallet" -pwd oracle123 -trusted_cert -cert /u01/app/oracle/self_signed_cert/self-rootCA.pem
-
Liste os conteúdos do Oracle Wallet. A lista deve incluir o certificado raiz.
orapki wallet display -wallet /u01/app/oracle/wallet -pwd oracle123
Por exemplo, isso pode ser exibido de forma semelhante à seguinte.
Requested Certificates: User Certificates: Trusted Certificates: Subject: CN=aws,OU=DBeng,O= AmazonWebService,L=Sydney,ST=NSW,C=AU
-
Gere o Certificate Signing Request (CSR - Solicitação de assinatura de certificado) utilizando o utilitário ORAPKI.
orapki wallet add -wallet "/u01/app/oracle/wallet" -pwd oracle123 -dn "CN=aws" -keysize 2048 -sign_alg sha256
-
Execute o seguinte comando .
openssl pkcs12 -in /u01/app/oracle/wallet/ewallet.p12 -nodes -out /u01/app/oracle/wallet/nonoracle_wallet.pem
Isso produz uma saída semelhante à seguinte.
Enter Import Password: MAC verified OK Warning unsupported bag type: secretBag
-
Coloque "dms" como o nome comum.
openssl req -new -key /u01/app/oracle/wallet/nonoracle_wallet.pem -out certdms.csr
Utilize os parâmetros de entrada, como os seguintes:
-
Country Name (2 letter code) [XX]
, por exemplo:AU
-
State or Province Name (full name) []
, por exemplo:NSW
-
Locality Name (e.g., city) [Default City]
, por exemplo:Sydney
-
Organization Name (e.g., company) [Default Company Ltd]
, por exemplo:AmazonWebService
-
Organizational Unit Name (e.g., section) []
, por exemplo:aws
-
Common Name (e.g., your name or your server's hostname) []
, por exemplo:aws
-
Email Address []
, por exemplo: abcd.efgh@amazonwebservice.com
Verifique se isso não é o mesmo que a etapa 4. É possível fazer isso, por exemplo, alterando o nome da unidade organizacional para um nome diferente, conforme mostrado.
Insira os atributos adicionais a seguir para serem enviados com a solicitação de certificado.
-
A challenge password []
, por exemplo:oracle123
-
An optional company name []
, por exemplo:aws
-
-
Obtenha a assinatura do certificado.
openssl req -noout -text -in certdms.csr | grep -i signature
A chave de assinatura desta postagem é
sha256WithRSAEncryption
. -
Utilize o seguinte comando para gerar o arquivo de certificado (
.crt
):openssl x509 -req -in certdms.csr -CA self-rootCA.pem -CAkey self-rootCA.key -CAcreateserial -out certdms.crt -days 365 -sha256
Isso exibe uma saída semelhante à seguinte.
Signature ok subject=/C=AU/ST=NSW/L=Sydney/O=awsweb/OU=DBeng/CN=aws Getting CA Private Key
-
Adicione o certificado à carteira.
orapki wallet add -wallet /u01/app/oracle/wallet -pwd oracle123 -user_cert -cert certdms.crt
-
Visualize a carteira. Deve haver duas entradas. Consulte o seguinte código:
orapki wallet display -wallet /u01/app/oracle/wallet -pwd oracle123
-
Configure o arquivo
sqlnet.ora
($ORACLE_HOME/network/admin/sqlnet.ora
).WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /u01/app/oracle/wallet/) ) ) SQLNET.AUTHENTICATION_SERVICES = (NONE) SSL_VERSION = 1.0 SSL_CLIENT_AUTHENTICATION = FALSE SSL_CIPHER_SUITES = (SSL_RSA_WITH_AES_256_CBC_SHA)
-
Interrompa o receptor do Oracle.
lsnrctl stop
-
Adicione entradas para SSL no arquivo
listener.ora
($ORACLE_HOME/network/admin/listener.ora
).SSL_CLIENT_AUTHENTICATION = FALSE WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /u01/app/oracle/wallet/) ) ) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME =
SID
) (ORACLE_HOME =ORACLE_HOME
) (SID_NAME =SID
) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCPS)(HOST = localhost.localdomain)(PORT = 1522)) (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) ) ) -
Configure o arquivo
tnsnames.ora
($ORACLE_HOME/network/admin/tnsnames.ora
).<SID>= (DESCRIPTION= (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <SID>) ) ) <SID>_ssl= (DESCRIPTION= (ADDRESS_LIST = (ADDRESS=(PROTOCOL = TCPS)(HOST = localhost.localdomain)(PORT = 1522)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <SID>) ) )
-
Reinicie o receptor do Oracle.
lsnrctl start
-
Mostre o status do receptor do Oracle.
lsnrctl status
-
Teste a conexão SSL ao banco de dados no host local, utilizando sqlplus e a a entrada SSL tnsnames.
sqlplus -L
ORACLE_USER
@SID
_ssl -
Verifique se você se conectou com êxito utilizando SSL.
SELECT SYS_CONTEXT('USERENV', 'network_protocol') FROM DUAL; SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') -------------------------------------------------------------------------------- tcps
-
Altere o diretório para o diretório com o certificado autoassinado.
cd /u01/app/oracle/self_signed_cert
-
Crie um novo Oracle Wallet de cliente para uso pelo AWS DMS.
orapki wallet create -wallet ./ -auto_login_only
-
Adicione o certificado raiz autoassinado ao Oracle Wallet.
orapki wallet add -wallet ./ -trusted_cert -cert self-rootCA.pem -auto_login_only
-
Liste o conteúdo do Oracle Wallet para uso pelo AWS DMS. A lista deve incluir o certificado raiz autoassinado.
orapki wallet display -wallet ./
Isso produz uma saída semelhante à seguinte.
Trusted Certificates: Subject: CN=aws,OU=DBeng,O=AmazonWebService,L=Sydney,ST=NSW,C=AU
-
Carregue o Oracle Wallet recém-criado no AWS DMS.
Métodos de criptografia com suporte para uso do Oracle como origem do AWS DMS
Na tabela a seguir, é possível encontrar os métodos de criptografia de dados transparente (TDE) ao qual o AWS DMS é compatível com o trabalhar com um banco de dados de origem Oracle.
Método de acesso de logs redo | Espaço de tabela de TDE | Coluna de TDE |
---|---|---|
LogMiner do Oracle | Sim | Sim |
Binary Reader | Sim | Sim |
O AWS DMS é compatível com a TDE do Oracle ao utilizar o Binary Reader no nível de coluna e no nível de espaço para tabela. Para utilizar a criptografia da TDE com o AWS DMS, primeiro identifique o local da carteira do Oracle em que a chave de criptografia e a senha da TDE estão armazenadas. Identifique a chave de criptografia e a senha corretas da TDE para o endpoint de origem do Oracle.
Para identificar e especificar a chave de criptografia e a senha para a criptografia da TDE
-
Execute a consulta a seguir para encontrar a carteira de criptografia do Oracle no host do banco de dados Oracle.
SQL> SELECT WRL_PARAMETER FROM V$ENCRYPTION_WALLET; WRL_PARAMETER -------------------------------------------------------------------------------- /u01/oracle/product/12.2.0/dbhome_1/data/wallet/
Aqui,
/u01/oracle/product/12.2.0/dbhome_1/data/wallet/
é a localização da carteira. -
Obtenha o ID da chave mestra utilizando uma das seguintes opções de criptografia, dependendo de qual delas retorna esse valor.
-
Para a criptografia em nível de tabela ou de coluna, execute as consultas a seguir.
SQL> SELECT OBJECT_ID FROM ALL_OBJECTS WHERE OWNER='DMS_USER' AND OBJECT_NAME='TEST_TDE_COLUMN' AND OBJECT_TYPE='TABLE'; OBJECT_ID --------------- 81046 SQL> SELECT MKEYID FROM SYS.ENC$ WHERE OBJ#=81046; MKEYID ------------ AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Aqui,
AWGDC9glSk8Xv+3bVveiVSg
é o ID da chave mestra (MKEYID
). Se você obtiver um valor paraMKEYID
, poderá continuar com a Etapa 3. Caso contrário, continue na Etapa 2.2.nota
Os caracteres à direita da string
'A'
(AAA...
) não fazem parte do valor. -
Para a criptografia em nível de espaço para tabela, execute as consultas a seguir.
SQL> SELECT TABLESPACE_NAME, ENCRYPTED FROM dba_tablespaces; TABLESPACE_NAME ENC ------------------------------ --- SYSTEM NO SYSAUX NO UNDOTBS1 NO TEMP NO USERS NO TEST_ENCRYT YES SQL> SELECT name,utl_raw.cast_to_varchar2( utl_encode.base64_encode('01'||substr(mkeyid,1,4))) || utl_raw.cast_to_varchar2( utl_encode.base64_encode(substr(mkeyid,5,length(mkeyid)))) masterkeyid_base64 FROM (SELECT t.name, RAWTOHEX(x.mkid) mkeyid FROM v$tablespace t, x$kcbtek x WHERE t.ts#=x.ts#) WHERE name = 'TEST_ENCRYT'; NAME MASTERKEYID_BASE64 ------------------------------ ---------------------------------- TEST_ENCRYT AWGDC9glSk8Xv+3bVveiVSg=
Aqui,
AWGDC9glSk8Xv+3bVveiVSg
é o ID da chave mestra (TEST_ENCRYT
). Se as etapas 2.1 e 2.2 retornarem um valor, elas serão sempre idênticas.O caractere à direita de
'='
não faz parte do valor.
-
-
Na linha de comando, liste as entradas da carteira de criptografia no host do banco de dados Oracle de origem.
$ mkstore -wrl /u01/oracle/product/12.2.0/dbhome_1/data/wallet/ -list Oracle Secret Store entries: ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ORACLE.SECURITY.DB.ENCRYPTION.AY1mRA8OXU9Qvzo3idU4OH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA ORACLE.SECURITY.DB.ENCRYPTION.MASTERKEY ORACLE.SECURITY.ID.ENCRYPTION. ORACLE.SECURITY.KB.ENCRYPTION. ORACLE.SECURITY.KM.ENCRYPTION.AY1mRA8OXU9Qvzo3idU4OH4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Encontre a entrada que contém o ID da chave mestra que você encontrou na etapa 2 (
AWGDC9glSk8Xv+3bVveiVSg
). Essa entrada é o nome da chave de criptografia da TDE. -
Visualize os detalhes da entrada que você localizou na etapa anterior.
$ mkstore -wrl /u01/oracle/product/12.2.0/dbhome_1/data/wallet/ -viewEntry ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Oracle Secret Store Tool : Version 12.2.0.1.0 Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved. Enter wallet password: ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA = AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==
Digite a senha da carteira para ver o resultado.
Aqui, o valor à direita de
'='
é a senha da TDE. -
Especifique o nome da chave de criptografia da TDE para o endpoint de origem do Oracle definindo o atributo de conexão adicional
securityDbEncryptionName
.securityDbEncryptionName=ORACLE.SECURITY.DB.ENCRYPTION.AWGDC9glSk8Xv+3bVveiVSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
-
Forneça a senha da TDE associada para essa chave no console como parte do valor da Senha da origem do Oracle. Utilize a ordem a seguir para formatar os valores de senha separados por vírgula, finalizados pelo valor da senha da TDE.
Oracle_db_password
,ASM_Password
,AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==Especifique os valores de senha nessa ordem, independentemente da configuração do banco de dados Oracle. Por exemplo, se estiver utilizando a TDE, mas o banco de dados Oracle não estiver utilizando o ASM, especifique os valores de senha relevantes na ordem separada por vírgulas a seguir.
Oracle_db_password
,,AEMAASAASGYs0phWHfNt9J5mEMkkegGFiD4LLfQszDojgDzbfoYDEACv0x3pJC+UGD/PdtE2jLIcBQcAeHgJChQGLA==
Se as credenciais da TDE especificadas estiverem incorretas, a tarefa de migração do AWS DMS não falhará. No entanto, a tarefa também não lê nem aplica alterações contínuas de replicação ao banco de dados de destino. Depois de iniciar a tarefa, monitore as Estatísticas da tabela na página de tarefas de migração no console para garantir que as alterações sejam replicadas.
Se um DBA alterar os valores das credenciais da TDE para o banco de dados Oracle enquanto a tarefa estiver em execução, a tarefa falhará. A mensagem de erro contém o novo nome da chave de criptografia da TDE. Para especificar novos valores e reiniciar a tarefa, utilize o procedimento anterior.
Importante
Não é possível manipular uma carteira da TDE criada em um local do Oracle Automatic Storage Management (ASM) porque comandos em nível do sistema operacional, como cp
, mv
, orapki
e mkstore
, corrompem os arquivos da carteira armazenados em um local do ASM. Essa restrição é específica de arquivos de carteira da TDE armazenados somente em um local do ASM, mas não para arquivos de carteira da TDE armazenados em um diretório local do sistema operacional.
Para manipular uma carteira da TDE armazenada no ASM com comandos em nível do sistema operacional, crie um keystore local e mescle o keystore do ASM no keystore local da seguinte forma:
-
Crie um keystore local.
ADMINISTER KEY MANAGEMENT create keystore
file system wallet location
identified bywallet password
; -
Mescle o keystore do ASM com o keystore local.
ADMINISTER KEY MANAGEMENT merge keystore
ASM wallet location
identified bywallet password
into existing keystorefile system wallet location
identified bywallet password
with backup;
Para listar as entradas da carteira de criptografia e a senha da TDE, execute as etapas 3 e 4 no keystore local.
Métodos de compactação com suporte para uso do Oracle como origem do AWS DMS
Na tabela a seguir, é possível encontrar quais métodos de compactação têm suporte no AWS DMS ao trabalhar com um banco de dados de origem Oracle. Como mostra a tabela, a compatibilidade com a compactação depende tanto da versão do banco de dados Oracle quanto da configuração do DMS para utilizar o LogMiner do Oracle para acessar os logs redo.
Version (Versão) | Basic | OLTP |
HCC (do Oracle 11g R2 ou mais recente) |
Outros |
---|---|---|---|---|
Oracle 10 | Não | N/D | N/D | Não |
Oracle 11 ou mais recente, LogMiner do Oracle | Sim | Sim | Sim | Sim, qualquer método de compactação compatível com o LogMiner do Oracle. |
Oracle 11 ou mais recente: Binary Reader | Sim | Sim | Sim, para obter mais informações, consulte a observação a seguir. | Sim |
nota
Quando o endpoint de origem Oracle é configurado para utilizar o Binary Reader, o nível Query Low do método de compactação HCC tem suporte somente para tarefas de carga máxima.
Replicar tabelas aninhadas utilizando Oracle como origem do AWS DMS
O AWS DMS é compatível com a replicação de tabelas Oracle com colunas que são tabelas aninhadas ou tipos definidos. Para ativar essa funcionalidade, adicione a seguinte configuração do atributo de conexão adicional ao endpoint de origem Oracle.
allowSelectNestedTables=true;
O AWS DMS cria as tabelas de destino com base em tabelas aninhadas Oracle como tabelas pai e filho regulares no destino sem uma restrição exclusiva. Para acessar os dados corretos no destino, junte as tabelas pai e filho. Para fazer isso, primeiro crie manualmente um índice não exclusivo na coluna NESTED_TABLE_ID
na tabela filho de destino. É possível utilizar a coluna NESTED_TABLE_ID
na cláusula de junção ON
juntamente com a coluna pai que corresponde ao nome da tabela filho. Além disso, a criação de um índice desse tipo melhora o desempenho quando os dados da tabela filho de destino são atualizados ou excluídos pelo AWS DMS. Para ver um exemplo, consulte Exemplo de junção para tabelas pai e filho no destino.
É recomendável configurar a tarefa para ser interrompida após a conclusão de uma carga máxima. Crie esses índices não exclusivos para todas as tabelas filho replicadas no destino e retome a tarefa.
Se uma tabela aninhada capturada for adicionada a uma tabela pai existente (capturada ou não capturada), o AWS DMS a manipulará corretamente. No entanto, o índice não exclusivo para a tabela de destino correspondente não é criado. Nesse caso, se a tabela filho de destino se tornar extremamente grande, o desempenho pode ser afetado. Nesse caso, é recomendável interromper a tarefa, criar o índice e retomar a tarefa.
Depois que as tabelas aninhadas forem replicadas para o destino, solicite que o administrador de banco de dados execute uma junção nas tabelas pai e filho correspondentes para nivelar os dados.
Pré-requisitos para replicação de tabelas aninhadas Oracle como origem
Replique tabelas pai para todas as tabelas aninhadas replicadas. Inclua as tabelas pai (as tabelas com a coluna da tabela aninhada) e as tabelas filho (ou seja, aninhadas) nos mapeamentos de tabelas do AWS DMS.
Tipos de tabela aninhada Oracle com suporte como origem
O AWS DMS é compatível com os seguintes tipos de tabela aninhada Oracle como origem:
-
Tipo de dados
-
Objeto definido pelo usuário
Limitações de suporte do AWS DMS para tabelas aninhadas Oracle como origem
O AWS DMS tem as seguintes limitações no suporte a tabelas aninhadas Oracle como origem:
-
O AWS DMS é compatível somente com um nível de aninhamento de tabela.
-
O mapeamento de tabelas do AWS DMS não verifica se a tabela pai e filho ou tabelas são selecionadas para replicação. Ou seja, é possível selecionar uma tabela pai sem uma tabela filho ou uma tabela filho sem pai.
Como o AWS DMS replica tabelas aninhadas Oracle como origem
O AWS DMS replica tabelas pai e aninhadas para o destino da seguinte forma:
-
O AWS DMS cria a tabela pai idêntica à origem. Ele define a coluna aninhada no pai como
RAW(16)
e inclui uma referência às tabelas aninhadas do pai em sua colunaNESTED_TABLE_ID
. -
O AWS DMS cria a tabela filho idêntica à origem aninhada, mas com uma coluna adicional chamada
NESTED_TABLE_ID
. Essa coluna tem o mesmo tipo e valor que a coluna aninhada pai correspondente e tem o mesmo significado.
Exemplo de junção para tabelas pai e filho no destino
Para nivelar a tabela pai, execute uma junção entre as tabelas pai e filho, conforme mostrado no exemplo a seguir:
-
Crie a tabela de
Type
.CREATE OR REPLACE TYPE NESTED_TEST_T AS TABLE OF VARCHAR(50);
-
Crie a tabela pai com uma coluna do tipo
NESTED_TEST_T
, conforme definido anteriormente.CREATE TABLE NESTED_PARENT_TEST (ID NUMBER(10,0) PRIMARY KEY, NAME NESTED_TEST_T) NESTED TABLE NAME STORE AS NAME_KEY;
-
Nivele a tabela
NESTED_PARENT_TEST
utilizando uma junção com a tabela filhoNAME_KEY
em queCHILD.NESTED_TABLE_ID
corresponde aPARENT.NAME
.SELECT … FROM NESTED_PARENT_TEST PARENT, NAME_KEY CHILD WHERE CHILD.NESTED_ TABLE_ID = PARENT.NAME;
Armazenar REDO no Oracle ASM ao utilizar o Oracle como origem do AWS DMS
Para origens Oracle com alta geração de REDO, o armazenamento de REDO no Oracle ASM pode beneficiar o desempenho, especialmente em uma configuração RAC, pois é possível configurar o DMS para distribuir leituras de REDO do ASM em todos os nós do ASM.
Para utilizar essa configuração, utilize o atributo de conexão asmServer
. Por exemplo, a seguinte string de conexão distribui leituras de REDO do DMS em três nós do ASM:
asmServer=(DESCRIPTION=(CONNECT_TIMEOUT=8)(ENABLE=BROKEN)(LOAD_BALANCE=ON)(FAILOVER=ON) (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=asm_node1_ip_address)(PORT=asm_node1_port_number)) (ADDRESS=(PROTOCOL=tcp)(HOST=asm_node2_ip_address)(PORT=asm_node2_port_number)) (ADDRESS=(PROTOCOL=tcp)(HOST=asm_node3_ip_address)(PORT=asm_node3_port_number))) (CONNECT_DATA=(SERVICE_NAME=+ASM)))
Ao utilizar o NFS para armazenar o REDO do Oracle, é importante garantir que os patches de cliente DNFS (Direct NFS) aplicáveis sejam aplicados, especificamente qualquer patch que resolva o erro 25224242 do Oracle. Para obter informações adicionais, analise a seguinte publicação do Oracle sobre os patches relacionados ao cliente Direct NFS, Patches recomendados para o cliente Direct NFS
Além disso, para melhorar o desempenho de leitura do NFS, é recomendável aumentar o valor de rsize
e wsize
em fstab
para o volume NFS, conforme mostrado no exemplo a seguir.
NAS_name_here
:/ora_DATA1_archive /u09/oradata/DATA1 nfs rw,bg,hard,nointr,tcp,nfsvers=3,_netdev, timeo=600,rsize=262144,wsize=262144
Além disso, ajuste o valor de tcp-max-xfer-size
da seguinte forma:
vserver nfs modify -vserver
vserver
-tcp-max-xfer-size 262144
Configurações de endpoint ao utilizar o Oracle como origem do AWS DMS
É possível utilizar as configurações de endpoint para configurar o banco de dados de origem Oracle de forma semelhante à utilização de atributos de conexão adicionais. Você especifica as configurações ao criar o endpoint de origem utilizando o console do AWS DMS ou o comando create-endpoint
na AWS CLI, com a sintaxe --oracle-settings '{"
do JSON.EndpointSetting"
:
"value"
, ...
}'
A tabela a seguir mostra as configurações de endpoint que podem ser utilizadas com o Oracle como origem.
Nome | Descrição |
---|---|
AccessAlternateDirectly |
Defina esse atributo como falso para utilizar o Binary Reader para a captura de dados de alteração para um Amazon RDS para Oracle como origem. Isso informa a instância do DMS para não acessar logs de redo por meio de qualquer substituição de prefixo de caminho especificado utilizando o acesso direto a arquivos. Para ter mais informações, consulte Configurar uma tarefa de CDC para utilizar o Binary Reader com uma origem do RDS para Oracle do AWS DMS. Valor padrão: verdadeiro Valores válidos: verdadeiro/falso Exemplo: |
|
Defina esse atributo com Apesar de o AWS DMS ser compatível com a utilização da opção Valores válidos: Ids de destino de arquivamento Exemplo: |
|
Defina este atributo para configurar a criação de logs complementares no nível da tabela para o banco de dados Oracle. Esse atributo habilita uma das seguintes opções em todas as tabelas selecionadas para uma tarefa de migração, dependendo dos respectivos metadados:
Valor padrão: falso Valores válidos: verdadeiro/falso Exemplo: notaSe você utilizar essa opção, ainda precisará ativar a criação de registro em log suplementar no nível do banco de dados, conforme discutido anteriormente. |
|
Defina esse atributo como true para permitir a replicação de tabelas Oracle com colunas que são tabelas aninhadas ou tipos definidos. Para ter mais informações, consulte Replicar tabelas aninhadas utilizando Oracle como origem do AWS DMS. Valor padrão: falso Valores válidos: verdadeiro/falso Exemplo: |
|
Especifica o ID do destino para os logs redo de restauração arquivados. Esse valor deve ser o mesmo que um número na coluna dest_id da visualização v$archived_log. Se você trabalhar com um destino de redo log adicional, é recomendável utilizar o atributo Valor padrão: 1 Valores válidos: número Exemplo: |
|
Quando esse campo é definido como Y, o AWS DMS só acessa os logs redo arquivados. Se os logs redo arquivados estiverem armazenados somente no Oracle ASM, será necessário conceder privilégios de ASM à conta de usuário do AWS DMS. Valor padrão: N Valores válidos: Y/N Exemplo: |
|
Utilize esse atributo de conexão adicional (ECA) ao capturar alterações na origem com o BinaryReader. Essa configuração permite que o DMS armazene 50 leituras em nível do ASM por thread de leitura único ao controlar o número de threads utilizando o atributo Valor padrão: falso Valores válidos: verdadeiro/falso Exemplo de ECA: |
|
Defina esse atributo como Valor padrão: falso Valores válidos: verdadeiro/falso Exemplo: |
|
Defina esse atributo como Observe que esse recurso e aprimoramento foram introduzidos no AWS DMS versão 3.4.7. Valor padrão: falso Valores válidos: verdadeiro/falso Exemplo: |
|
Defina esse atributo para habilitar a replicação homogênea de tablespace e criar tabelas ou índices existentes no mesmo tablespace no destino. Valor padrão: falso Valores válidos: verdadeiro/falso Exemplo: |
|
Defina esse atributo como um caractere de escape. Esse caractere de escape permite que um único caractere curinga se comporte como um caractere normal em expressões de mapeamento de tabela. Para ter mais informações, consulte Curingas no mapeamento de tabela. Valor padrão: nulo Valores válidos: qualquer caractere que não seja um caractere curinga Exemplo: notaÉ possível utilizar |
|
É possível extrair dados uma vez de uma visualização, mas não é possível utilizá-los para replicação contínua. Ao extrair dados de uma visualização, a visualização aparece como uma tabela no esquema de destino. Valor padrão: falso Valores válidos: verdadeiro/falso Exemplo: |
|
Especifica os IDs de mais um destino para um ou mais logs redo arquivados. Esses IDs são os valores da coluna dest_id na visualização v$archived_log. Utilize essa configuração com o atributo de conexão adicional ArchivedLogDestId em uma configuração primária para única ou primária para várias em espera. Essa configuração é útil em uma transição quando você utiliza um banco de dados Oracle Data Guard como origem. Nesse caso, o AWS DMS precisa de informações sobre o destino de onde obter logs redo de arquivo para ler as alterações. O AWS DMS precisa disso porque, após a transição, o primário anterior é uma instância em espera. Valores válidos: Ids de destino de arquivamento Exemplo: |
|
Quando definido como Se a tarefa for definida como modo LOB limitado e essa opção estiver definida como Valor padrão: falso Valores válidos: booleano Exemplo: |
|
Utilize esse atributo de conexão adicional (ECA) para permitir que o DMS ignore transações de um usuário especificado ao replicar dados do Oracle ao utilizar o LogMiner. É possível passar valores de nome de usuário separados por vírgula, mas eles devem estar em letras MAIÚSCULAS. Exemplo de ECA: |
|
Especifica a escala de números. É possível selecionar um aumento da escala verticalmente para 38 ou selecionar -1 para FLOAT ou -2 para VARCHAR. Por padrão, o tipo de dados NUMBER é convertido para um valor com precisão 38 e escala 10. Valor padrão: 10 Valores válidos: de -2 a 38 (–2 para VARCHAR, -1 para FLOAT) Exemplo: notaSelecione uma combinação de escala de precisão, -1 (FLOAT) ou -2 (VARCHAR). O DMS é compatível com qualquer combinação de escala de precisão compatível com o Oracle. Se a precisão for 39 ou superior, selecione -2 (VARCHAR). A configuração NumberDataTypeScale para o banco de dados Oracle é utilizada somente para o tipo de dados NUMBER (sem a definição explícita de precisão e escala). |
|
Fornece o período em minutos para verificar se há transações abertas apenas para tarefas da CDC. notaQuando você define Valor padrão: 0 Valores válidos: um número inteiro de 0 a 240 Exemplo: |
OraclePathPrefix |
Defina esse atributo de string como o valor exigido para usar o Binary Reader para capturar dados de alteração para um Amazon RDS for Oracle como origem. Esse valor especifica a raiz padrão do Oracle utilizada para acessar os logs redo. Para ter mais informações, consulte Configurar uma tarefa de CDC para utilizar o Binary Reader com uma origem do RDS para Oracle do AWS DMS. Valor padrão: nenhum Valor válido: /rdsdbdata/db/ORCL_A/ Exemplo: |
ParallelASMReadThreads |
Defina esse atributo para alterar o número de threads que o DMS configura para executar uma captura de dados de alteração (CDC) utilizando o Oracle Automatic Storage Management (ASM). É possível especificar um valor inteiro entre 2 (o padrão) e 8 (o máximo). Use esse atributo junto com o atributo Valor padrão: 2 Valores válidos: um número inteiro de 2 a 8 Exemplo: |
ReadAheadBlocks |
Defina esse atributo para alterar o número de blocos de leitura antecipada que o DMS configura para executar a CDC utilizando o Oracle Automatic Storage Management (ASM) o armazenamento não ASM NAS. É possível especificar um valor inteiro entre 1000 (o padrão) e 200.000 (o máximo). Use esse atributo junto com o atributo Valor padrão: 1000 Valores válidos: um número inteiro de 1.000 a 200.000 Exemplo: |
|
Quando definido como Valor padrão: falso Valores válidos: booleano Exemplo: |
ReplacePathPrefix |
Defina esse atributo como true para usar o Binary Reader para capturar dados de alteração em um Amazon RDS for Oracle como a origem. Essa configuração informa a instância do DMS para substituir raiz padrão do Oracle pela configuração UsePathPrefix especificada para acessar os logs redo. Para ter mais informações, consulte Configurar uma tarefa de CDC para utilizar o Binary Reader com uma origem do RDS para Oracle do AWS DMS.Valor padrão: falso Valores válidos: verdadeiro/falso Exemplo: |
|
Especifica o número de segundos que o sistema espera antes de enviar novamente uma consulta. Valor padrão: 5 Valores válidos: número a partir de 1 Exemplo: |
|
Especifica o nome de uma chave utilizada para a criptografia de dados transparente (TDE) das colunas e do espaço para tabela no banco de dados de origem Oracle. Para obter mais informações sobre como definir esse atributo e sua senha associada no endpoint de origem Oracle, consulte Métodos de criptografia com suporte para uso do Oracle como origem do AWS DMS. Valor padrão: "" Valores válidos: string Exemplo: |
|
Para origens Oracle versão 12.1 ou anterior migrando para destinos PostgreSQL, utilize esse atributo para converter SDO_GEOMETRY para o formato GEOJSON. Por padrão, o AWS DMS chama o perfil personalizado Valor padrão: SDO2GEOJSON Valores válidos: string Exemplo: |
|
Utilize esse atributo para especificar um tempo em minutos para o atraso na sincronização de espera. Se a origem for um banco de dados em espera do Active Data Guard, utilize esse atributo para especificar o atraso de tempo entre os bancos de dados primário e em espera. No AWS DMS, é possível criar uma tarefa de CDC do Oracle que utiliza uma instância em espera do Active Data Guard como a origem para replicar as alterações em andamento. Isso elimina a necessidade de se conectar a um banco de dados ativo que pode estar em produção. Valor padrão: 0 Valores válidos: número Exemplo: Observação: ao utilizar o DMS 3.4.6, 3.4.7 e superior, a utilização dessa configuração de conexão é opcional. Na versão mais recente do DMS 3.4.6 e na versão 3.4.7, |
UseAlternateFolderForOnline |
Defina esse atributo como true para usar o Binary Reader para capturar dados de alteração em um Amazon RDS for Oracle como a origem. Isso informa a instância do DMS para utilizar qualquer substituição do prefixo especificado para acessar todos os logs redo online, Para ter mais informações, consulte Configurar uma tarefa de CDC para utilizar o Binary Reader com uma origem do RDS para Oracle do AWS DMS. Valor padrão: falso Valores válidos: verdadeiro/falso Exemplo: |
UseBfile |
Defina esse atributo como Y para capturar dados de alterações utilizando o utilitário Binary Reader. Defina Observação: ao definir esse valor como um atributo de conexão adicional (ECA), os valores válidos são "S" e "N". Ao definir esse valor como uma configuração de endpoint, os valores válidos são Valor padrão: N Valores válidos: S/N (ao definir esse valor como ECA); verdadeiro/falso (ao definir esse valor como uma configuração de endpoint). Exemplo: |
|
Defina esse atributo como Y para capturar alterações nos dados utilizando o utilitário LogMiner (padrão). Defina essa opção como N para que o AWS DMS acesse os logs redo como arquivos binários. Ao definir essa opção como N, adicione também a configuração useBfile=Y. Para obter mais informações sobre essa configuração e sobre a utilização do Oracle Automatic Storage Management (ASM), consulte Utilizar o LogMiner do Oracle ou o Binary Reader do AWS DMS para CDC. Observação: ao definir esse valor como um atributo de conexão adicional (ECA), os valores válidos são "S" e "N". Ao definir esse valor como uma configuração de endpoint, os valores válidos são Valor padrão: Y Valores válidos: S/N (ao definir esse valor como ECA); verdadeiro/falso (ao definir esse valor como uma configuração de endpoint). Exemplo: |
UsePathPrefix |
Defina esse atributo de string como o valor exigido para usar o Binary Reader para capturar dados de alteração para um Amazon RDS for Oracle como origem. Esse valor especifica o prefixo do caminho utilizado para substituir a raiz padrão do Oracle para acessar os redo logs. Para ter mais informações, consulte Configurar uma tarefa de CDC para utilizar o Binary Reader com uma origem do RDS para Oracle do AWS DMS. Valor padrão: nenhum Valor válido: /rdsdbdata/log/ Exemplo: |
Tipos de dados de origem do Oracle
O endpoint Oracle para o AWS DMS é compatível com a maioria dos tipos de dados do Oracle. A tabela a seguir mostra os tipos de dados de origem Oracle compatíveis com o AWS DMS e o mapeamento padrão relativo aos tipos de dados do AWS DMS.
nota
Com exceção dos tipos de dados LONG e LONG RAW, ao replicar de uma origem Oracle para um destino Oracle (uma replicação homogênea), todos os tipos de dados de origem e de destino serão idênticos. Mas o tipo de dados LONG será mapeado para CLOB e o tipo de dados LONG RAW será mapeado para BLOB.
Para obter informações sobre como visualizar o tipo de dados mapeado no destino, consulte a seção relativa ao endpoint de destino que você está usando.
Para obter mais informações sobre os tipos de dados do AWS DMS, consulte Tipos de dados do AWS Database Migration Service.
Tipo de dados do Oracle |
Tipo de dados do AWS DMS |
---|---|
BINARY_FLOAT |
REAL4 |
BINARY_DOUBLE |
REAL8 |
BINARY |
BYTES |
FLOAT (P) |
Se a precisão é menor ou igual a 24, utilize REAL4. Se a precisão for maior que 24, utilize REAL8. |
NUMBER (P,S) |
Quando a escala for maior que 0, utilize NUMERIC. Quando a escala for 0:
Quando a escala for menor que 0, utilize REAL8. |
DATA |
DATETIME |
INTERVAL YEAR TO MONTH |
STRING (com indicação de intervalo de tempo em anos e meses) |
INTERVAL DAY TO SECOND |
STRING (com indicação de intervalo de tempo em dias e segundos) |
TIMESTAMP |
DATETIME |
TIMESTAMP WITH TIME ZONE |
STRING (com indicação de time stamp com fuso horário) |
TIMESTAMP WITH LOCAL TIME ZONE |
STRING (com indicação de time stamp com fuso horário local) |
CHAR |
STRING |
VARCHAR2 |
|
NCHAR |
WSTRING |
NVARCHAR2 |
|
RAW |
BYTES |
REAL |
REAL8 |
BLOB |
BLOB Para utilizar esse tipo de dados com o AWS DMS, ative a utilização de tipos de dados BLOB em uma tarefa específica. O AWS DMS é compatível com os tipos de dados BLOB somente em tabelas que possuem uma chave primária. |
CLOB |
CLOB Para usar esse tipo de dados no AWS DMS, é necessário habilitar o uso de tipos de dados CLOB em uma tarefa específica. Durante uma captura de dados de alteração (CDC), o AWS DMS oferece suporte aos tipos de dados CLOB somente em tabelas que possuem uma chave primária. |
NCLOB |
NCLOB Para usar esse tipo de dados no AWS DMS, é necessário habilitar o uso de tipos de dados NCLOB em uma tarefa específica. Durante uma captura de dados de alteração (CDC), o AWS DMS oferece suporte aos tipos de dados NCLOB somente em tabelas que incluem uma chave primária. |
LONG |
CLOB O tipo de dados LONG não é compatível no modo de aplicação otimizado para lotes (modo TurboStream CDC). Para utilizar esse tipo de dados com oAWS DMS, ative a utilização de LOBs em uma tarefa específica. Durante uma CDC ou carga máxima, o AWS DMS é compatível com os tipos de dados LOB somente em tabelas que possuem uma chave primária. Além disso, o AWS DMS não é compatível com o modo LOB completo para carregar colunas LONG. Em vez disso, é possível utilizar o modo LOB limitado para migrar colunas LONG para um destino Oracle. No modo LOB limitado, o AWS DMS trunca todos os dados de 64 KB definidos como colunas LONG com mais de 64 KB. Para obter mais informações sobre a compatibilidade com LOB no AWS DMS, consulte Configurando LOB suporte para bancos de dados de origem em uma AWS DMS tarefa. |
LONG RAW |
BLOB O tipo de dados LONG RAW não é compatível no modo de aplicação otimizado para lotes (modo TurboStream CDC). Para utilizar esse tipo de dados com oAWS DMS, ative a utilização de LOBs em uma tarefa específica. Durante uma CDC ou carga máxima, o AWS DMS é compatível com os tipos de dados LOB somente em tabelas que possuem uma chave primária. Além disso, AWS DMS não é compatível com o modo LOB completo para carregar colunas LONG RAW. Em vez disso, é possível utilizar o modo LOB limitado para migrar colunas LONG RAW para um destino Oracle. No modo LOB limitado, o AWS DMS trunca todos os dados de 64 KB definidos como colunas LONG RAW com mais de 64 KB. Para obter mais informações sobre a compatibilidade com LOB no AWS DMS, consulte Configurando LOB suporte para bancos de dados de origem em uma AWS DMS tarefa. |
XMLTYPE |
CLOB |
SDO_GEOMETRY |
BLOB (quando é uma migração de Oracle para Oracle) CLOB (quando é uma migração de Oracle para PostgreSQL) |
As tabelas do Oracle utilizado como origem com colunas dos tipos de dados a seguir não são compatíveis e não podem ser replicadas. A replicação de colunas com esses tipos de dados resultará em colunas nulas.
-
BFILE
-
ROWID
-
REF
-
UROWID
-
Tipos de dados definidos pelo usuário
-
ANYDATA
-
VARRAY
nota
Colunas virtuais não são compatíveis.
Migrar tipos de dados espaciais do Oracle
Dados espaciais identificam as informações de geometria de um objeto ou local no espaço. Em um banco de dados Oracle, a descrição geométrica de um objeto geográfico é armazenada em um objeto do tipo SDO_GEOMETRY. Dentro desse objeto, a descrição geométrica é armazenada em uma única linha em uma única coluna de uma tabela definida pelo usuário.
O AWS DMS é compatível com a migração do tipo SDO_GEOMETRY do Oracle de uma origem Oracle para um destino Oracle ou PostgreSQL.
Ao migrar tipos de dados espaciais do Oracle utilizando o AWS DMS, considere o seguinte:
-
Ao migrar para um destino Oracle, transfira manualmente as entradas USER_SDO_GEOM_METADATA que incluem informações de tipo.
-
Ao migrar de um endpoint de origem Oracle para um endpoint de destino PostgreSQL, o AWS DMS cria colunas de destino. Essas colunas têm geometria padrão e informações de tipo geográfico com uma dimensão 2D e um identificador de referência espacial (SRID) igual a zero (0). Um exemplo é
GEOMETRY, 2, 0
. -
Para origens Oracle versão 12.1 ou anterior migrando para destinos PostgreSQL, converta os objetos
SDO_GEOMETRY
para o formatoGEOJSON
utilizando o perfilSDO2GEOJSON
ou o atributo de conexão adicionalspatialSdo2GeoJsonFunctionName
. Para ter mais informações, consulte Configurações de endpoint ao utilizar o Oracle como origem do AWS DMS. -
O AWS DMS é compatível com migrações de colunas espaciais do Oracle somente para o modo LOB completo. O AWS DMS não é compatível com os modos LOB limitado ou LOB em linha. Para obter mais informações sobre o modo LOB, consulte Configurando LOB suporte para bancos de dados de origem em uma AWS DMS tarefa.
Como o AWS DMS só é compatível com o modo LOB completo para migrar colunas espaciais do Oracle, a tabela das colunas precisa de uma chave primária e de uma chave exclusiva. Se a tabela não tiver uma chave primária e uma chave exclusiva, a tabela será ignorada na migração.