Operazioni supportate con evoluzione automatica schema

Automatic Schema Evolution è supportato sulle destinazioni Oracle, MySQL, PostgreSQL, SQL Server, Db2 LUW, DB2400, Teradata e Oracle TimesTen.

Automatic Schema Evolution è supportato su origini Oracle, MySQL, PostgreSQL, SQL Server, Db2 LUW, Db2 zOS, DB2400, Sybase, Teradata, Oracle TimesTen e Snowflake.

Sono supportate le operazioni riportate di seguito.

La risposta Evoluzione automatica schema predefinita può essere sostituita utilizzando AUTOSCHEMAOPTIONS. Sono supportate le seguenti opzioni:
- TYPEMAP: utilizzare questa opzione in modo da eseguire l'override del mapping del tipo di dati predefinito
- IGNORE_DATA_TRUNCATION: se il mapping del tipo di dati predefinito prevede un possibile troncamento dei dati, Replicat viene interrotto con l'errore appropriato per impostazione predefinita. Per ignorare questi errori di troncamento dei dati e consentire a Replicat di continuare senza interrompere, è possibile specificare AUTOSCHEMAOPTIONS IGNORE_DATA_TRUNCATION nel file dei parametri Replicat.
- IGNORE_MODIFY_KEY_COLUMN: per impostazione predefinita, Automatic Schema Evolution non consente di modificare la colonna o le colonne della chiave primaria e Replicat viene interrotto in tali casi con un errore appropriato. È possibile specificare AUTOSCHEMAOPTIONS IGNORE_MODIFY_KEY_COLUMN per saltare eventuali modifiche alle colonne della chiave.
- ALLOW_MODIFY_KEY_COLUMN: per impostazione predefinita, Automatic Schema Evolution non consente di modificare la colonna o le colonne di chiave primaria e Replicat viene interrotto in tali casi. È possibile specificare AUTOSCHEMAOPTIONS ALLOW_MODIFY_KEY_COLUMN per consentire qualsiasi modifica alle colonne chiave.
- MODIFY_COLUMN_NULLABILITY_ONLY: è possibile specificare AUTOSCHEMAOPTIONS MODIFY_COLUMN_NULLABILITY_ONLY se sono interessati solo alla modifica alla annullabilità della colonna e non alla modifica del tipo.

Automatic Schema Evolution supporta le operazioni riportate di seguito in base alle modifiche dello schema rilevate dai record di metadati nei file trail per mantenere sincronizzato lo schema delle tabelle di origine e di destinazione.

Creazione della tabella mancante nel database di destinazione
Modifica della tabella di destinazione mediante l'esecuzione delle colonne ADD/MODIFY/DROP

In base ai metadati di ogni colonna di origine, per impostazione predefinita viene scelto il tipo di dati di tipo "corrispondenza più adatta" per la colonna di destinazione corrispondente.

NOTA: esaminare i mapping dei tipi di dati predefiniti applicabili per lo scenario di replica del database di origine specifico al database di destinazione da Mapping tipo di dati prima di implementare l'evoluzione automatica dello schema.

I tipi di dati di destinazione potrebbero non essere esattamente uguali al tipo di dati di origine in tutti i casi. Ove possibile, la scelta del tipo di dati di destinazione viene effettuata in modo che il tipo di destinazione sia sempre compatibile e sufficientemente grande (con le stesse dimensioni della colonna di origine o più ampia) da poter contenere i dati della colonna di origine corrispondente. In alcuni casi in cui non è disponibile alcun tipo appropriato per il tipo di dati della colonna di origine corrispondente nel database di destinazione (ad esempio, i tipi disponibili nel database di destinazione possono causare il troncamento dei dati), viene restituito un errore all'utente con un suggerimento appropriato.

Creazione della tabella mancante

AutoSchema supporta i seguenti casi d'uso:

Creare la tabella mancante nella destinazione durante l'applicazione dei dati trail generati da CDC Extract.
Creare la tabella mancante nella destinazione durante l'applicazione dei dati trail generati dall'estrazione del caricamento iniziale.
Durante l'applicazione del trail generato solo dall'estrazione initialLoad, è possibile scegliere di eliminare la tabella di destinazione esistente e crearne un'altra specificando OPTYPE RECREATE come parte dei criteri di inclusione DDL AUTOSCHEMA.
Se tutte le colonne della chiave di origine corrispondenti dai metadati trail non sono annullabili, Automatic Schema crea la tabella di destinazione con una clausola PRIMARY KEY con tutte le colonne corrispondenti.
Se una qualsiasi delle colonne chiave di origine corrispondenti, dai metadati trail, è annullabile, lo schema automatico crea la tabella di destinazione con una clausola UNIQUE KEY con tutte le colonne corrispondenti.

Modifica della tabella esistente

Se nell'origine vengono aggiunte/eliminate/modificate colonne, le DDL ALTER TABLE corrispondenti vengono generate ed eseguite nelle tabelle di destinazione mappate corrispondenti. Lo schema automatico supporta le modifiche correlate solo al tipo (inclusi nome del tipo di dati, lunghezza, precisione, scala come applicabile) e al vincolo di nullità. Tuttavia, non rispetta alcuna modifica ad altri attributi di colonna. Se sulle colonne di origine vengono rilevate modifiche allo schema correlate al tipo o alla annullabilità, queste vengono propagate sulle colonne di destinazione.

Una o più modifiche allo schema nella tabella di origine possono generare una o più DDL ALTER TABLE nelle tabelle di destinazione mappate, come supportato nel database di destinazione specifico. Il numero di DDL nella destinazione dipende dalla sintassi supportata in un database di destinazione specifico, ad esempio nei casi riportati di seguito.

Pochi database non consentono l'aggiunta, la rimozione o la modifica di più colonne in un singolo ALTER TABLE DDL.
Pochi database non consentono la modifica sia del tipo che della nullabilità delle colonne in una singola istruzione ALTER TABLE DDL.

In questi casi, il numero richiesto di istruzioni ALTER TABLE DDL viene eseguito sulla tabella di destinazione, in base ai requisiti del database di destinazione.

È possibile che lo schema automatico influisca sul database di destinazione che richiede ulteriori azioni. Ad esempio, se un ALTER TABLE MODIFY COLUMN può causare il troncamento di alcuni dati, database diversi potrebbero gestirlo in modi diversi. Un database potrebbe rilevare alcuni dati esistenti che potrebbero essere troncati dall'operazione e causare l'arresto di Replicat, che in genere si verifica tra Oracle e MySQL, quando MySQL è in esecuzione con la modalità rigorosa abilitata. Tuttavia, se MySQL è configurato in modalità non rigorosa, la trazione potrebbe verificarsi senza alcuna avvertenza.

Per IBM i, a seconda della configurazione del sistema, il Replicat può apparire sospeso. Per alcune azioni su Db2 (in precedenza Db2 LUW) e Db2 z/OS, alcune azioni potrebbero richiedere una riorganizzazione della tabella. Su Db2 z/OS, una colonna di rilascio non verrà riconosciuta fino a quando non viene eseguita una riorganizzazione e per Db2 la tabella potrebbe finire in uno stato di riorganizzazione in sospeso e smettere di consentire ulteriori operazioni su di essa.

NOTA: se necessario, è possibile aggiungere in modo selettivo OPTYPE ADDCOLUMN, OPTYPE DROPCOLUMN e OPTYPE MODIFYCOLUMN ai criteri di inclusione/esclusione DDL AUTOSCHEMA.