Sobre a Openflow Connector for Oracle¶

1. Licença Interna (fornecida pela Snowflake)¶

A Snowflake fornece a licença do Oracle XStream diretamente a você mediante uma taxa. Este modelo permite que você consuma a replicação do XStream sem um contrato direto com a Oracle. Para obter mais informações, consulte os Detalhes da licença interna e o Adendo do Openflow Connector para Oracle.

2. Licença independente (Traga sua própria licença - BYOL)¶

Você providencia a própria licença do Oracle que inclui direitos para o XStream (por exemplo, licença Oracle GoldenGate). Para obter mais informações, consulte os detalhes da licença independente (BYOL).

Faturamento¶

Os serviços do Oracle XStream são faturados mensalmente e deduzidos do seu saldo do Snowflake Capacity. A taxa tem dois componentes: licença e Suporte e Manutenção (S&M). A taxa de licença é calculada com base no número de núcleos de processador em seu banco de dados Oracle de origem, multiplicado pelo fator de núcleo de processador Oracle.

Compromisso (regra do «Dia 61»)¶

Os primeiros 60 dias são gratuitos para até 16 núcleos licenciados. No entanto, ativar o conector após a avaliação de 60 dias inicia uma vigência de faturamento de 36 meses incancelável («Vigência Inicial»).

• Conversão automática: o faturamento começa automaticamente no Dia 61. Para evitar cobranças, você deve cancelar a avaliação no painel Admin » Terms » Openflow for Oracle antes do Dia 60.

• Bloqueio: se o seu contrato com a Snowflake for encerrado durante a Vigência Inicial, todo o saldo restante referente à Vigência Inicial se tornará devido imediatamente.

Renovação após a vigência e penalidades¶

Após a Vigência Inicial, a taxa de licença passa a ser de US$ 0, mas a taxa de Suporte e Manutenção (S&M) é mantida.

• Consequência do cancelamento: você pode cancelar a renovação de S&M pelo painel em Admin » Terms » Openflow for Oracle. No entanto, se a cobertura de S&M for interrompida, os processadores do conector serão bloqueados. Para retomar as operações, você deve comprar uma NEW Licença Interna (redefinindo o compromisso de 36 meses pelo preço integral).

Requisitos¶

Você é responsável por relatar com precisão o número de núcleos de processador e o fator de núcleo correto na configuração do conector. Essas informações sempre deverão ser atualizadas se o hardware do banco de dados de origem mudar.

Restrições¶

Esta opção não está disponível para:

• Entidades do setor público (por exemplo, órgãos governamentais e instituições de ensino)

• Clientes que compram o Snowflake pelo GCP Marketplace

• Clientes que têm contratos com a Snowflake através de um revendedor terceirizado (por exemplo, CDW, Optiv)

Configuração¶

Para configurar a Licença Interna:

• Revise e aceite os termos do Adendo do Openflow Connector para Oracle apresentados na UI.

• Selecione o tipo Embedded License.

• Insira os detalhes da quantidade de núcleos de CPU do seu banco de dados Oracle de origem: total de núcleos (o número total de núcleos físicos no servidor de banco de dados de origem) e fator de núcleo (o fator de núcleo do processador Oracle, por exemplo, 0,5 para processadores Intel). Consulte a tabela de fatores de núcleo do processador Oracle para conferir o valor correto.

Requisitos¶

Você é o único responsável por garantir que o seu uso do conector esteja em conformidade com os termos previstos em seu contrato de licença existente com a Oracle. A Snowflake não valida nem faz auditoria de seus direitos com a Oracle.

Configuração¶

Para configurar a Licença Independente (BYOL):

• Revise e aceite os termos do Adendo do Openflow Connector para Oracle apresentados na UI.

• Selecione o tipo Independent License.

Ao configurar o conector, prossiga sem inserir nenhuma quantidade de núcleos ou informações relacionadas a faturamento.

Como as tabelas são replicadas¶

As tabelas são replicadas nos seguintes estágios:

1. Introspecção de esquema: o conector descobre as colunas na tabela de origem, incluindo os nomes e tipos de coluna, e as valida em relação às limitações do Snowflake e do conector. As falhas de validação fazem com que esse estágio falhe, e o ciclo se complete. Falhas na validação causam falha nesse estágio, e o ciclo é concluído. Após a conclusão bem-sucedida desse estágio, o conector cria uma tabela de destino vazia no Snowflake.

2. Carga de instantâneo: o conector copia todos os dados disponíveis na tabela de origem para a tabela de destino. Se esse estágio falhar, nenhum outro dado será replicado. Após a conclusão bem-sucedida, os dados da tabela de origem ficam disponíveis na tabela de destino.

3. Carga incremental: o conector rastreia as alterações na tabela de origem e aplica essas alterações à tabela de destino. Esse processo continua até que a tabela seja removida da replicação. Esse processo continua até que a tabela seja removida da replicação. Uma falha nesse estágio interromperá permanentemente a replicação da tabela de origem até que o problema seja resolvido.

Status da replicação da tabela¶

Falhas temporárias, como erros de conexão, não impedem a replicação das tabelas. Entretanto, falhas permanentes, como tipos de dados incompatíveis, impedem a replicação das tabelas.

Para solucionar problemas de replicação ou verificar se uma tabela foi removida com êxito do fluxo de replicação, consulte o armazenamento de estado de tabela:

1. Na tela do tempo de execução do Openflow, clique com o botão direito do mouse em um grupo de processadores e escolha Controller Services. Uma tabela que lista os serviços do controlador é exibida.

2. Localize a linha chamada Table State Store, clique no botão More à direita da linha e escolha View State.

Uma lista de tabelas e os respectivos estados atuais é exibida. Digite na caixa de pesquisa para filtrar a lista por nome da tabela. Os estados possíveis são:

• NEW: a tabela está agendada para replicação, mas a replicação não foi iniciada.

• SNAPSHOT_REPLICATION: o conector está copiando os dados existentes. Esse status é exibido até que todos os registros sejam armazenados na tabela de destino.

• INCREMENTAL_REPLICATION: o conector está replicando as alterações ativamente. Esse status é exibido após o término da replicação do instantâneo e continua a ser exibido indefinidamente até que uma tabela seja removida da replicação ou a replicação falhe.

• FAILED: a replicação foi interrompida permanentemente devido a um erro.

Replication state for table <database_name>.<schema_name>.<table_name> changed from <old_state> to <new_state>

Se uma falha permanente impedir a replicação da tabela, remova a tabela da replicação. Depois de resolver o problema que causou a falha, você poderá adicionar a tabela de volta à replicação. Para obter mais informações, consulte Reiniciar a replicação da tabela.

Retenção de dados¶

Colunas de metadados da tabela de destino¶

Cada tabela de destino inclui as seguintes colunas de metadados que rastreiam informações de replicação:

Linhas excluídas logicamente¶

Quando uma linha é excluída da tabela de origem, o conector não a remove fisicamente da tabela de destino. Em vez disso, a linha é marcada como excluída definindo a coluna de metadados _SNOWFLAKE_DELETED como true.

Essa abordagem permite:

• Reter dados históricos para fins de auditoria ou conformidade.

• Consultar registros excluídos quando necessário.

• Decidir quando e como remover dados permanentemente com base em suas necessidades.

Para consultar apenas linhas ativas (não excluídas), filtre pela coluna _SNOWFLAKE_DELETED:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = FALSE;

Para consultar linhas excluídas:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = TRUE;

Colunas descartadas¶

Quando uma coluna é descartada da tabela de origem, o conector não descarta a coluna correspondente da tabela de destino. Em vez disso, a coluna é renomeada anexando o sufixo __SNOWFLAKE_DELETED para preservar os valores históricos.

Por exemplo, se uma coluna chamada EMAIL for descartada da tabela de origem, ela será renomeada para EMAIL__SNOWFLAKE_DELETED na tabela de destino. As linhas que existiam antes do descarte da coluna mantêm os valores originais, enquanto as linhas adicionadas após o descarte terão NULL nessa coluna.

Você ainda pode consultar os valores históricos da coluna renomeada:

SELECT EMAIL__SNOWFLAKE_DELETED FROM my_table;

Colunas renomeadas¶

Devido às limitações nos mecanismos de captura de dados de alteração (Change Data Capture, CDC), o conector não consegue distinguir entre uma coluna renomeada e uma coluna descartada seguida da adição de uma nova coluna. Como resultado, quando você renomeia uma coluna na tabela de origem, o conector trata isso como duas operações separadas: descartar a coluna original e adicionar uma nova coluna com o novo nome.

Por exemplo, se você renomear uma coluna de A para B na tabela de origem, a tabela de destino conterá:

• A__SNOWFLAKE_DELETED: contém valores de antes da renomeação. As linhas adicionadas após a renomeação têm NULL nesta coluna.

• B: contém valores de depois da renomeação. As linhas que existiam antes da renomeação têm NULL nesta coluna.

SELECT
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

SELECT
    CASE
        WHEN B IS NOT NULL THEN B
        ELSE A__SNOWFLAKE_DELETED
    END AS A_RENAMED_TO_B
FROM my_table;

CREATE VIEW my_table_unified AS
SELECT
    *,
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

Tabelas de diário¶

Durante a replicação incremental, as alterações do banco de dados de origem são gravadas primeiro em tabelas de diário antes de serem mescladas às tabelas de destino. O conector não remove automaticamente os dados das tabelas de diário, pois esses dados podem ser úteis para fins de auditoria, depuração ou reprocessamento.

As tabelas de diário são criadas no mesmo esquema que as respectivas tabelas de destino e seguem esta convenção de nomenclatura:

<TABLE_NAME>_JOURNAL_<timestamp>_<number>

Onde:

• <TABLE_NAME> é o nome da tabela de destino.

• <timestamp> é o carimbo de data/hora de criação no formato de época Unix (segundos desde 1º de janeiro de 1970), garantindo a exclusividade.

• <number> começa em 1 e incrementa sempre que o esquema da tabela de destino é alterado, seja devido a alterações no esquema da tabela de origem ou a modificações nos filtros de coluna.

Por exemplo, se a tabela de destino for SALES.ORDERS, a tabela de diário poderá ter o nome SALES.ORDERS_JOURNAL_1705320000_1.