SQL Server: Tipos de Dados, Objetos e Operações Suportados

Saiba mais sobre informações de suporte para o Oracle GoldenGate no SQL Server Database.

Com o Oracle GoldenGate for SQL Server, é possível capturar e fornecer dados transacionais e de carga inicial para as versões suportadas do banco de dados do SQL Server.

O Oracle GoldenGate for SQL Server suporta o mapeamento, a filtragem e a transformação de dados de origem, a menos que seja observado o contrário neste documento, bem como a replicação de dados derivados de outros bancos de dados de origem suportados pelo Oracle GoldenGate, em bancos de dados do SQL Server.

Requisitos da Instância

O nome do servidor do SQL Server (@@SERVERNAME) não deve ser NULL.
(Extração) Para que o Oracle GoldenGate capture dados transacionais, o Agente do SQL Server deve estar em execução na instância do SQL Server de origem e o job de Captura de Dados de Alteração do SQL Server deve estar em execução no banco de dados. Se a Replicação Transacional do SQL Server também estiver ativada para o banco de dados, o Agente do Leitor de Log do SQL Server deverá estar em execução.
Se seus dados para as colunas TEXT, NTEXT, IMAGE, ou VARCHAR(MAX), NVARCHAR(MAX) e VARBINARY(MAX) excederem o tamanho padrão do SQL Server definido para a opção max text repl size, estenda o tamanho. Use sp_configure para exibir ou ajustar o valor atual de max text repl size. Observação: Para o Amazon RDS for SQL Server, para ajustar as definições da instância, você precisa usar Grupos de Parâmetros em vez de sp_configure.

É recomendável instalar o Service Pack ou a Atualização Cummulativa mais recente para sua instância do SQL Server para garantir a funcionalidade adequada. Para o SQL Server 2012, 2014, 2016 e 2017, a Microsoft identificou e corrigiu vários problemas importantes que afetam diretamente o recurso Captura de Dados de Alteração do SQL Server. Essa situação afeta a capacidade do Oracle GoldenGate de capturar dados corretamente. Os problemas conhecidos atuais que exigem patches da Microsoft incluem KB3030352, KB3166120 e KB 4073684.

Requisitos do Banco de Dados

Observe os seguintes requisitos e limitações para oferecer suporte ao Oracle GoldenGate:

Somente bancos de dados do usuário são suportados para captura e entrega.
Certifique-se de que Auto Create Statistics e Auto Update Statistics estejam ativados para o banco de dados.
O banco de dados deve ser definido para o nível de compatibilidade da versão da instância do SQL Server.
O Oracle GoldenGate suporta bancos de dados SQL Server configurados com TDE (Transparent Data Encryption).
(Extrair) O banco de dados de origem pode ser definido para qualquer modelo de recuperação que suporte o recurso de captura de dados de alteração no Microsoft SQL Server.
Se o banco de dados de origem tiver sido criado restaurando um backup de outra instância, você deverá sincronizar o SID do proprietário do banco de dados com o SID na nova instância. Como alternativa, você pode usar sp_changedbowner para definir o banco de dados restaurado como um log-in atual.
A captura de bancos de dados do SQL Server (SQL Server 2017 CU15 e versões mais recentes) ativada com OLTP na Memória (otimização na memória) é suportada, com as versões 21.15 e 23.5 do Oracle GoldenGate em diante. No entanto, somente a captura de tabelas em disco é suportada, e não das tabelas otimizadas para memória.
(AlwaysOn) O Extract suporta a captura do banco de dados principal ou de um modo de commit síncrono somente para leitura. O modo assíncrono-commit não é suportado para captura.
Consideração de desempenho do Replicat: A partir do SQL Server 2016, a Microsoft alterou a definição padrão para a opção de banco de dados TARGET_RECOVERY_TIME de 0 para 60 segundos. Foi demonstrado em testes internos que isso pode reduzir o throughput do Replicat. Se você sentir degradação do throughput do Replicat, considere ajustar a definição TARGET_RECOVERY_TIME como 0.

Limitações:

O Oracle GoldenGate não suporta captura ou entrega de bancos de dados do sistema.
O Oracle GoldenGate não suporta captura de bancos de dados contidos.
Os nomes de banco de dados de origem não podem exceder 121 caracteres. Esta limitação é devido aos procedimentos armazenados do SQL Server que são usados para ativar o registro em log complementar.
Se você estiver configurando a funcionalidade de pulsação do Oracle GoldenGate, o nome do banco de dados do SQL Server não deverá exceder 107 caracteres.
(AlwaysOn) Não há suporte para a captura de bancos de dados configurados no modo assíncrono de commit de um grupo de Disponibilidade AlwaysOn.

Requisitos da Tabela

As tabelas a serem incluídas para captura e entrega devem incluir apenas os tipos de dados listados em Tipos de Dados do SQL Server Suportados.

O Oracle GoldenGate suporta a captura de DML transacional de tabelas de usuário e a entrega a tabelas de usuário e views graváveis.
Operações DDL não são suportadas.
O Oracle GoldenGate suporta o máximo permitido de nomes de tabelas e comprimentos de coluna para tabelas rastreadas pela Captura de Dados de Alteração do SQL Server.
A soma de todos os tamanhos de coluna de uma tabela a ser capturada não deve exceder o tamanho que o SQL Server permite ativar a Captura de Dados de Alteração para a tabela. Se a soma de todos os tamanhos de coluna exceder o permitido pelo procedimento sys.sp.cdc_enable_table do SQL Server, ADD TRANDATA não poderá ser ativado para essa tabela. O tamanho máximo permitido do registro diminui à medida que mais colunas estão presentes, portanto, há um relacionamento inverso entre o tamanho máximo do registro e o número de colunas na tabela.

Tipos de Dados do SQL Server Suportados

Os seguintes tipos de dados são suportados para captura e entrega, a menos que especificamente indicados nas limitações a seguir:

Tipos de Dados Binários
- (binary, varbinary, varbinary (max))
- (varbinary (max)com FILESTREAM)
Tipos de dados de caractere
- (char, nchar, nvarchar, nvarchar (max), varchar, varchar (max))
Tipos de Dados de Data e Hora
- (date, datetime2, datetime, datetimeoffset, smalldatetime, time)
Tipos de Dados Numéricos
- (bigint, bit, decimal, float, int, money, numeric, real, smallint, smallmoney, tinyint)
LOBs
- (image, ntext, text)
Outros Tipos de Dados
- (timestamp, uniqueidentifier, hierarchyid, geography, geometry, sql_variant (Delivery only), XML)
O Oracle GoldenGate for SQL Server pode replicar dados de coluna que contêm definições SPARSE.

Limitações:

O Oracle GoldenGate não suporta filtragem, mapeamento de colunas ou manipulação de objetos grandes com mais de 4 KB. A funcionalidade completa do Oracle GoldenGate pode ser usada para objetos de até 4 KB.
O Oracle GoldenGate trata os dados XML como um objeto grande (LOB), assim como o SQL Server quando o XML não se encaixa em uma linha. Os aprimoramentos de XML estendido do SQL Server (como validação lax, DATETIME, funcionalidade de união) não são suportados.
Uma coluna TIMESTAMP atribuída pelo sistema ou uma coluna calculada não materializada não pode fazer parte de uma chave. Uma tabela que contém uma coluna TIMESTAMP deve ter uma chave, que pode ser uma chave primária ou uma restrição exclusiva, ou uma chave substituta especificada com uma cláusula KEYCOLS nas instruções TABLE ou MAP. Para obter mais informações, consulte Atribuindo Identificadores de Linha.
O Oracle GoldenGate suporta tipos de dados de caracteres multibyte e dados de vários bytes armazenados em colunas de caracteres. Os dados multibyte são suportados apenas em uma configuração semelhante ao SQL Server. Transformação, filtragem e outros tipos de manipulação não são suportados para dados de caracteres multibyte.
Se a captura de dados para as colunas TEXT, NTEXT, IMAGE, VARCHAR (MAX), NVARCHAR(MAX) e VARBINARY (MAX) exceder o tamanho padrão do SQL Server definido para a opção max text repl size, estenda o tamanho. Use sp_configure para exibir o valor atual de max text repl size e ajustar a opção conforme necessário. Observação: O Amazon RDS para SQL Server não permite que max text repl size seja maior que 64 MB. {: .infoboxnote}
As colunas dos tipos de dados IMAGE, NTEXT e TEXT são registradas como um valor NULL para operações de exclusão e antes da atualização da imagem. As colunas VARBINARY(MAX), VARCHAR(MAX) e NVARCHAR(MAX) são registradas como um valor NULL para as operações de atualização de imagem anteriores, a menos que a coluna tenha sido atualizada.

Para obter mais informações, revise o conteúdo Tipos de Dados de Objetos Grandes no seguinte documento da Microsoft:

https://docs.microsoft.com/en-us/sql/relational-databases/system-tables/cdc-capture-instance-ct-transact-sql?view=sql-server-ver15
O Oracle GoldenGate suporta dados UDT e UDA de até 2 GB de tamanho. Todos os UDTs, exceto SQL_Variant, são suportados.
Common Language Runtime (CLR), incluindo tipos de dados CLR integrados do SQL Server (como geometria, geografia e ID de hierarquia), são suportados. Os tipos de dados CLR são suportados apenas em uma configuração do SQL Server semelhante. Transformação, filtragem e outros tipos de manipulação não são suportados para dados CLR.
Há suporte para colunas VARBINARY (MAX) com o atributo FILESTREAM de até 4 GB. O Extract usa funções de arquivo padrão Win32 para ler o arquivo FILESTREAM.
O alcance e a precisão dos números de ponto flutuante dependem da máquina host. Em geral, a precisão é precisa para 16 dígitos significativos, mas você deve revisar a documentação do banco de dados para determinar as aproximações esperadas. O Oracle GoldenGate arredonda ou trunca valores que excedem a precisão suportada.
O Oracle GoldenGate suporta dados de timestamp de 0001/01/03:00:00:00 a 9999/12/31:23:59:59. Se um timestamp for convertido de GMT para hora local, esses limites também se aplicarão ao timestamp resultante. Dependendo do fuso horário, a conversão pode adicionar ou subtrair horas, o que pode fazer com que o timestamp exceda o limite inferior ou superior suportado.

Limitações nas Colunas Calculadas:

Colunas calculadas, persistidas ou não persistidas, não são suportadas pela Captura de Dados de Alteração da Microsoft. Portanto, nenhum dado é gravado na trilha para colunas que contêm colunas calculadas. Para replicar dados para colunas calculadas não persistidas, use a opção FETCHCOLS ou FETCHMODCOLS do parâmetro TABLE para extrair os dados da coluna da tabela.

Lembre-se de que pode haver discrepâncias causadas por diferenças nos valores de dados entre a hora em que a coluna foi alterada no banco de dados e a hora em que o processo Extract extrai os dados do registro de transação que está sendo processado.
Quando uma coluna com tipo de dados não suportado sql_variant é usada nas opções FETCHCOLS ou FETCHMODCOLS, o processo Extract é encerrado com o seguinte erro:
```
ERROR   OGG-25230 Unsupported datatype '*column-name* (sql_variant)' used with 'FETCHCOLS/FETCHCOLSEXCEPT' in table '*table-name>*.
```
O Replicat não aplicará DML a nenhuma coluna calculada, mesmo se os dados dessa coluna estiverem na trilha, porque o banco de dados não permite DML nesse tipo de coluna. Os dados de uma coluna calculada persistida de origem ou de uma coluna não persistida extraída podem ser aplicados a uma coluna de destino que não seja uma coluna calculada.
Em um carregamento inicial, todos os dados são selecionados diretamente das tabelas de origem, não do log de transações. Portanto, em uma carga inicial, os valores de dados de todas as colunas, incluindo colunas calculadas não persistidas, são gravados na trilha ou enviados para o destino, dependendo do método usado. No entanto, como ao aplicar dados de alteração, o Replicat não aplica dados de carga inicial a colunas calculadas, porque o banco de dados não permite DML nesse tipo de coluna.
O Oracle GoldenGate não permite que uma coluna calculada não persistida seja usada em uma cláusula KEYCOLS em uma instrução TABLE ou MAP.
Se uma chave exclusiva incluir uma coluna calculada não persistida e o Oracle GoldenGate precisar usar a chave, a coluna calculada não persistida será ignorada. Isso poderá afetar a integridade dos dados se as colunas restantes não imporem a exclusividade.
Se um índice exclusivo for definido em qualquer coluna calculada não persistida, ele não será usado.
Se uma chave ou índice exclusivo contiver uma coluna calculada não persistida e for o único identificador exclusivo em uma tabela, o Oracle GoldenGate deverá usar todas as colunas como um identificador para localizar linhas de destino. Como uma coluna calculada não persistida não pode ser usada neste identificador, o Replicat pode aplicar operações que contenham esse identificador às linhas de destino erradas.

Tipos e Recursos de Dados do SQL Server Não Suportados

O tipo de dado SQL_Variant não é suportado para captura.
As tabelas que contêm tipos de dados não suportados podem fazer com que o processo Extract seja encerrado. Como solução alternativa, você deve remover TRANDATA dessas tabelas e removê-las da instrução TABLE do Extract ou usar o parâmetro TABLEEXCLUDE do Extract para a tabela.

Objetos e Operações Suportados para SQL Server

Os seguintes objetos e operações são suportados:

O Replicat Paralelo é suportado com o Oracle GoldenGate para SQL Server.
O Oracle GoldenGate oferece suporte à captura de DML transacional de tabelas do usuário e à entrega de tabelas do usuário e views graváveis.
As colunas TEXT, NTEXT, IMAGE, VARBINARY, VARBINARY (MAX) VARCHAR (MAX) e NVARCHAR (MAX) são suportadas em seu tamanho total para operações registradas pela Captura de Dados de Chang do SQL Server. Por exemplo, as colunas dos tipos de dados IMAGE, NTEXT e TEXT são registradas como um valor NULL para operações de exclusão. Para obter mais informações, revise o conteúdo Tipos de Dados de Objetos Grandes no seguinte documento da Microsoft:

https://docs.microsoft.com/en-us/sql/relational-databases/system-tables/cdc-capture-instance-ct-transact-sql?view=sql-server-ver15
O Oracle GoldenGate suporta os tamanhos máximos de linhas permitidos para tabelas ativadas para a Captura de Dados de Alteração do SQL Server.
O Oracle GoldenGate suporta a captura de tabelas ativadas com a compactação PAGE e ROW. Para tabelas particionadas que usam compactação, todas as partições devem ser ativadas com o mesmo tipo de compactação.
O Oracle GoldenGate suporta captura para tabelas particionadas se a tabela tiver o mesmo layout físico em todas as partições.
A soma de todos os tamanhos de coluna de uma tabela a ser capturada não deve exceder o tamanho que o SQL Server permite ativar a Captura de Dados de Alteração para a tabela. Se a soma de todos os tamanhos de coluna exceder o permitido pelo procedimento do SQL Server sys.sp.cdc_enable_table, ADD TRANDATA não poderá ser adicionado para essa tabela. O tamanho máximo permitido do registro diminui à medida que mais colunas estão presentes, portanto, há um relacionamento inverso entre o tamanho máximo do registro e o número de colunas na tabela.

Objetos e Operações Não Suportados para SQL Server

Os seguintes objetos e operações não são suportados:

Considere um relacionamento pai-filho entre duas tabelas, em que uma chave primária na tabela pai é referenciada por uma chave estrangeira na tabela filho com a cláusula ON UPDATE SET DEFAULT. A atualização de PK diferida na tabela pai resulta em pares DELETE e INSERT. Não é possível identificar com segurança as operações DELETE e INSERT correspondentes na tabela pai. Quando essa atualização diferida é executada na tabela pai, o Oracle GoldenGate Extract não pode capturar de maneira confiável todos os eventos.
Para bancos de dados de origem, operações não suportadas pela Captura de Dados de Alteração do SQL Server, como instruções TRUNCATE. Consulte a Documentação do Microsoft SQL Server para obter uma lista completa das operações limitadas ao ativar a Captura de Dados de Alteração do SQL Server.
O Oracle GoldenGate for SQL Server não suporta a captura ou a entrega de alterações DDL para o SQL Server, e etapas extras são necessárias para que os processos do Oracle GoldenGate na origem e no destino manipulem quaisquer alterações DDL no nível da tabela, incluindo operações de recriação do índice da tabela. Consulte Requisitos para Alterações de DDL no Nível da Tabela.
As views não são suportadas.
Operações do utilitário TextCopy e das instruções WRITETEXT e UPDATETEXT. Esses recursos executam operações que não são registradas pelo banco de dados ou são registradas apenas parcialmente, portanto, não podem ser suportadas pelo processo Extract.
Tabelas particionadas que têm mais de um layout físico entre partições.
Alternâncias de partição em uma tabela de origem. A Captura de Dados de Alteração do SQL Server trata as chaves de partição como operações DDL e os dados movidos de uma partição para outra não são registrados nas tabelas CDC; portanto, você deve seguir os procedimentos em Requisitos para Alterações DDL no Nível da Tabela para implementar manualmente uma chave de partição quando a tabela estiver ativada para log complementar.
Devido a uma limitação com a Captura de Dados de Alteração do SQL Server, os agrupamentos no nível da coluna que são diferentes do agrupamento do banco de dados podem fazer com que dados incorretos sejam gravados nas tabelas CDC para dados de caracteres e o Extract os capturará conforme são gravados nas tabelas CDC. É recomendável usar o tipo de dados NVARCHAR, NCHAR ou NTEXT para colunas que contenham dados não ASCII ou usar a mesma compactação para colunas de tabela que o banco de dados. Para obter mais informações, consulte Sobre a Captura de Dados de Alteração (SQL Server).
Devido a uma limitação com a Captura de Dados de Alteração do SQL Server, o NOOPUPDATES não é capturado pelo agente de Captura de Dados de Alteração do SQL Server, portanto, não há registros para o Extract capturar para operações de atualização sem operação.
As tabelas temporais não são suportadas para ativar a Captura de Dados de Alteração; portanto, não podem ser configuradas para a Extração para implementações de origem.

Requisitos para Alterações DDL no Nível da Tabela

O Oracle GoldenGate for SQL Server não suporta a captura ou a entrega de alterações DDL. No entanto, a partir do Oracle GoldenGate 21c, as alterações feitas nas tabelas ativadas com TRANDATA não farão com que o Extract seja encerrado. O Extract continuará processando dados de alteração para a tabela como ela existia quando o TRANDATA estava ativado.

As operações consideradas como alterações DDL no nível da tabela incluem, entre outros: ALTER TABLE, TRUNCATE TABLE, reconstruções de índice e seletores de partição.

Para evitar inconsistências de dados devido a alterações de DDL no nível da tabela, as etapas a seguir são necessárias.

Origem: Pausar ou Interromper dados do aplicativo para a tabela ou tabelas a serem modificadas.
Fonte: Certifique-se de que não haja transações abertas na tabela a ser modificada.
Fonte: Assegure-se de que o trabalho Captura CDC do SQL Server processe todas as transações restantes para a tabela que será modificada.
Origem: Certifique-se de que a Extração processe todas as transações da tabela que deve ser modificada, antes de fazer qualquer alteração de DDL.
Destino: Certifique-se de que o Replicat processe todas as transações da tabela que devem ser modificadas, antes de fazer qualquer alteração de DDL.
Opcionalmente, a implementação de uma tabela Marcador de Eventos pode ser usada para determinar quando todas as transações restantes foram processadas para a tabela a ser modificada e para controlar a coordenação de quando interromper corretamente o processo Extract e Replicat.
Origem: Interrompe o processo de Extração.
Destino: Interrompe o processo Replicat.
Origem: Desative o registro em log complementar da tabela a ser modificada executando DELETE TRANDATA.
Origem: Faça alterações de DDL na tabela de origem.
Destino: Faça alterações de DDL na tabela de destino.
Fonte: Reative o registro em log complementar executando ADD TRANDATA na(s) tabela(s) após a execução das modificações.
Fonte: Iniciar o Extract.
Destino: Iniciar o processo Replicat.
Fonte: Retomar dados do aplicativo para a tabela ou tabelas que foram modificadas.

Esquemas do Sistema para SQL Server

Os seguintes esquemas de sistema não são suportados para Replicação:

sys
cdc
INFORMATION_SCHEMA

O esquema guest não é suportado usando mapeamentos de curinga, mas é suportado quando listado explicitamente, como TABLE guest.employees.