Limitazioni

Se si intende utilizzare la funzionalità Evoluzione automatica schema, tenere presenti le limitazioni riportate di seguito.

• Replicat supporta lo schema automatico solo in modalità classica e coordinata (la modalità parallela non è supportata).

• Schema automatico non supportato per la replica bidirezionale.

• Lo schema automatico non è applicabile alla tabella utilizzata nella clausola MAPEXCEPTION. Gli utenti devono creare in modo esplicito la tabella delle eccezioni corrispondente prima di avviare la replica.

• Lo schema automatico non supporta il parametro COLMATCH.

• Lo schema automatico non propaga le colonne invisibili/nascoste di origine dall'origine alla destinazione.

• Lo schema automatico non rispetta il parametro DDLSUBST.

• Lo schema automatico non propaga tutti gli indici o i vincoli, presenti nella tabella di origine, nella tabella di destinazione corrispondente.

• Lo schema automatico non rispetta alcun set di caratteri a livello di colonna di origine e/o l'insieme. Il set di caratteri o la raccolta a livello di colonna corrispondente non è associato alle colonne target.

  • Lo schema automatico non associa alcun set di caratteri a livello di tabella alle tabelle di destinazione.

  • Lo schema automatico non associa alcun set di caratteri o ordinamento a livello di colonna alle colonne di destinazione.

    Quando si utilizza lo schema automatico, verificare i set di caratteri utilizzati nell'origine e i set di caratteri disponibili nei sistemi di destinazione. Non presumere che i set di caratteri di origine siano necessariamente disponibili nel sistema di destinazione. Ciò è particolarmente vero se i database non utilizzano tutti una qualche forma di Unicode. In questo momento, quando si utilizza lo schema automatico, viene fornita la migliore compatibilità con i set di caratteri del database di origine assicurandosi che qualsiasi database di destinazione utilizzi UTF-8 o UTF-16 per le relative colonne di caratteri. Ciò viene visualizzato in modo più specifico quando i database IBM Db2 sono l'origine. Per Db2 per z/OS e Db2 per i, i dati di origine sono spesso una qualche forma di EBCDIC e se la destinazione è un'altra famiglia di database, è improbabile che tali set di caratteri siano direttamente rappresentabili nella destinazione. Una preoccupazione simile può essere fatta anche per i set di caratteri ASCII, poiché non tutti i database li supportano universalmente tutti.

  IMPORTANTE: l'utilizzo di Unicode per il database di destinazione può richiedere un'espansione della lunghezza dei campi carattere per garantire che la dimensione corretta sia disponibile quando si esegue il mapping da un'origine diversa da Unicode stesso. Se il database di destinazione utilizza un numero maggiore di byte per rappresentare un carattere rispetto al numero di byte utilizzati dal database di origine, gli utenti devono utilizzare AUTOSCHEMAOPTIONS TYPEMAP per tutte le colonne e utilizzare un tipo di dati di destinazione più ampio e compatibile per evitare qualsiasi possibile troncamento dei dati.

• Lo schema automatico non supporta le colonne di origine di tipo AUTO-INCREMENT e non crea/altera le colonne di destinazione corrispondenti con le stesse proprietà di incremento automatico.

• Lo schema automatico potrebbe non creare correttamente la chiave primaria o univoca nella tabella di destinazione quando la tabella MySQL di origine contiene solo una chiave univoca e nessuna chiave primaria. Database MySQL che non fornisce le informazioni chiave corrette.

NOTA: questa non è una limitazione imposta dallo schema automatico, ma l'origine MySQL.

• Se il database di origine è Oracle Database 19c, lo schema automatico potrebbe non essere in grado di derivare correttamente la annullabilità delle colonne di destinazione.

NOTA: questo non è un limite di schema automatico, ma è l'Oracle Database di origine 19c che non fornisce le informazioni chiave corrette. Le colonne di tipo char e varchar2 dell'origine Oracle vengono sempre valutate utilizzando la semantica byte, anche se la DDL di origine utilizza la semantica char.

• Se per la tabella di origine Oracle non è stata definita alcuna chiave primaria, ma solo una chiave univoca contenente una qualsiasi delle colonne virtuali, colonne annullabili, tipi di dati definiti dall'utente, colonne varchar estese e lunghe oppure colonne di indice basate su funzioni, come colonne chiave valide, lo schema automatico non crea tali colonne come chiave primaria/unica nella tabella di destinazione.

• Se l'origine è un database PostgreSQL e la tabella di origine include colonne LOB come parte della chiave, gli utenti devono specificare DBOPTIONS MAXLOBKEYLEN <value> nel file dei parametri Extract. In caso contrario, per impostazione predefinita (senza AUTOSCHEMAOPTIONS TYPEMAP), lo schema automatico creerà le colonne corrispondenti con lunghezza zero sulla destinazione.

• Per il tipo Array di origine PostgreSQL, lo schema automatico crea il tipo CLOB o il relativo equivalente per la colonna di destinazione corrispondente. È necessario specificare AUTOSCHEMAOPTIONS TYPEMAP per selezionare il tipo di destinazione appropriato, in base al nome della colonna Array di origine PostgreSQL.

• Per le colonne CLOB di origine Oracle con set di caratteri di database a più byte, per impostazione predefinita viene scelto NCLOB o un tipo di destinazione equivalente per la colonna di destinazione. Per eseguire l'override, utilizzare TYPEMAP.

• Per Db2 per z/OS, la replica dei dati UTF-16 richiede un database EBCDIC o Unicode. Altre codifiche a doppio byte non sono esplicitamente supportate.

• Per i database IBM Db2 (in precedenza Db2 per LUW) che replicano i dati UTF-16, è necessario un database Unicode. Altre codifiche a doppio byte non sono esplicitamente supportate.

• Per le colonne di tipo ENUM di origine, lo schema automatico applica char come tipo di destinazione in MySQL. Utilizzare invece TYPEMAP, se necessario, per utilizzare VARCHAR.

• È necessario specificare AUTOSCHEMAOPTIONS TYPEMAP in base al nome della colonna di origine e non al nome del tipo di dati di origine per le colonne numeriche/decimali di origine con precisione inferiore a 8.

• È necessario specificare AUTOSCHEMAOPTIONS TYPEMAP in base al nome della colonna di origine e non in base al nome del tipo di dati di origine per le colonne di origine di tipo:
  • Colonne di tipo Char/Varchar con lunghezza > 4000.
  • TEMPO(p)
  • TEMPO(p) SENZA TEMPO ZONA
  • TEMPO(p) CON ZONA TEMPO
  • TIMESTAMP(p)
  • TIMESTAMP(p) SENZA TEMPO ZONA
  • TIMESTAMP(p) CON ZONA DI TEMPO
  • Tutte le varianti INTERVAL
  • Colonne di tipo vettore SQL Server di origine

• Lo schema automatico non supporta l'utilizzo della clausola COLMAP con nomi di colonna contenenti virgolette doppie. Il nome della colonna di destinazione utilizzato in un mapping di colonne specifico nella clausola COLMAP, mappato a un nome di colonna di origine, non può essere uguale a qualsiasi altro nome di colonna nella tabella di origine.

• Alcuni dei messaggi di errore dello schema automatico possono essere visualizzati in ASCII quando la versione locale del sistema in cui è in esecuzione GoldenGate è un set di caratteri a più byte, ad esempio cinese o giapponese (ad esempio, zh_CN.UTF-8).

• Nella destinazione di SQL Server, per qualsiasi tipo datetime/timestamp di origine senza secondi frazionari, è necessario specificare AUTOSCHEMAOPTIONS TYPEMAP per il tipo di origine (o il nome colonna) corrispondente con datetime2(0) come tipo di destinazione di sostituzione specificato.

• Nella destinazione Db2 z/OS, lo schema automatico non supporta l'eliminazione di più colonne utilizzando un singolo ALTER TABLE DDL. È possibile rieseguire il DDL non riuscito riportato nell'errore OGG (dal file di report Replicat) e riavviare Replicat.

• Nella destinazione SQLServer, lo schema automatico non rileva/esegue correttamente la modifica della colonna da VARCHAR(n) a TEXT o VARCHAR(max).

• AUTOSCHEMAOPTIONS TYPEMAP non funziona per le specifiche del tipo di destinazione:
  • NUMERO (p,s)
  • NUMERICO(p,s)
  • DECIMAL(p,s)
  • TIMESTAMP(p) con fuso orario
  • TIME(p) con fuso orario: la soluzione alternativa consiste nell'utilizzare TIME(p) come specifica del nome del tipo di destinazione anziché TIME(p) senza fuso orario perché entrambi sono semanticamente equivalenti.
  • TIMESTAMP(p) senza fuso orario Come soluzione alternativa, è possibile utilizzare TIMESTAMP(p) come specifica del nome del tipo di destinazione anziché TIMESTAMP(p) senza fuso orario perché entrambi sono semanticamente equivalenti.
  • Varbinary(max)
  • Varchar(max): la soluzione alternativa consiste nell'utilizzare CLOB come specifica del nome del tipo di destinazione anziché varchar(max)
  • Nvarchar(max): la soluzione alternativa consiste nell'utilizzare NCLOB come specifica del nome del tipo di destinazione anziché nvarchar(max)

• Nella destinazione SQLServer, specificare la dimensione Vector nella specifica del tipo è obbligatorio. L'indicazione del tipo di base (ad esempio float16 o float32) è facoltativa.

• Per le colonne di origine SQLServer di tipo DATETIME, Autoschema non può distinguere tra DATETIME e DATETIME2(3). Pertanto, durante l'utilizzo della clausola TYPEMAP esplicita, è necessario configurare una colonna di origine basata sul nome TYPEMAP anziché una mappa tipi basata sul nome del tipo di origine.

• Per le colonne NCHAR di destinazione DB2AS400, lo schema automatico non rileva correttamente le modifiche del tipo di colonna richieste.

• Se un database Oracle GoldenGate Delivery su PostgreSQL (o compatibile con PostgreSQL) è configurato per utilizzare il driver ODBC nativo PostgreSQL, lo schema automatico non rileva correttamente i casi di colonna Modifica tabella alterata.

• Per IBM Db2 for i, è possibile che un job possa apparire "hang" e non fare progressi. Ad esempio, è più probabile che ciò si verifichi nella replica per quando viene utilizzato lo schema automatico se l'operazione richiesta può causare un problema di troncamento dei dati. A seconda della configurazione del sistema IBM i, è possibile impostare il job di replica in uno stato MGW (Message Wait) in cui il sistema è in attesa che un utente fornisca l'azione che il job deve eseguire per risolvere il problema specifico. Attualmente non c'è modo per GoldenGate di affrontare questo direttamente, e si deve gestire sul lato IBM i.

• Per i tipi di colonna Snowflake di origine TIMESTAMP_NTZ(p) o TIMESTAMP_LTZ(p) o TIMESTAMP_TZ(p), lo schema automatico li mappa alle colonne indicatore orario corrispondenti, ma con una precisione data/ora pari a 0. Per evitare il troncamento dei dati dei secondi frazionari, è necessario utilizzare AUTOSCHEMAOPTIONS TYPEMAP per selezionare il tipo richiesto nella destinazione.

• Lo schema automatico non differenzia i tipi di colonna JSON e JSONB dell'origine PostgreSQL. È necessario utilizzare AUTOSCHEMAOPTIONS TYPEMAP in base al nome della colonna di origine anziché al tipo di colonna per i tipi JSONB di origine PostgreSQL.

• Lo schema automatico non fa distinzione tra i tipi numerici di origine PostgreSQL (numerici senza precisione e scala) e i tipi numerici di origine PostgreSQL (1000, 100). È necessario utilizzare AUTOSCHEMAOPTIONS TYPEMAP in base al nome della colonna di origine anziché al tipo di colonna per le colonne di tipo numerico di origine PostgreSQL (1000.100).

• Per i tipi di colonna di origine Snowflake ARRAY, GEOGRAPHY e GEOMETRY, lo schema automatico esegue il mapping al tipo JSON (se supportato) o al tipo CLOB sulla destinazione. Per selezionare un tipo diverso nella destinazione, gli utenti devono utilizzare AUTOSCHEMAOPTIONS TYPEMAP.

• Il messaggio o i messaggi informativi contenenti le specifiche basate sul nome della colonna di origine, parte di AUTOSCHEMAOPTIONS TYPEMAP, non vengono visualizzati correttamente.