Prepara tabelle per elaborazione

In questa sezione viene descritto come preparare le tabelle per l'elaborazione. La preparazione della tabella richiede i seguenti task.

Garantisci univocità righe per tabelle

Oracle GoldenGate richiede una forma di identificativo di riga univoco nelle tabelle di origine e di destinazione per individuare le righe di destinazione corrette per gli aggiornamenti e le eliminazioni replicati.

A meno che non venga utilizzata una clausola KEYCOLS nell'istruzione TABLE o MAP, Oracle GoldenGate seleziona un identificativo di riga da utilizzare nel seguente ordine di priorità:

  1. Chiave primaria

  2. Prima chiave univoca in modo alfanumerico che non contiene un indicatore orario o una colonna calcolata non materializzata.

  3. Se non esiste alcun tipo di chiave precedente (anche se nella tabella potrebbero essere definiti altri tipi di chiavi), Oracle GoldenGate costruisce una pseudo chiave di tutte le colonne che il database consente di essere utilizzato in una chiave univoca, esclusi quelli non supportati da Oracle GoldenGate in una chiave o quelli esclusi dalla configurazione di Oracle GoldenGate.

Nota: se sono presenti altre chiavi non utilizzabili in una tabella o se non sono presenti chiavi nella tabella, Oracle GoldenGate registra un messaggio appropriato nel file di report. La creazione di una chiave da tutte le colonne impedisce le prestazioni di Oracle GoldenGate nel sistema di origine. Nella destinazione, questa chiave fa sì che Replicat utilizzi una clausola WHERE più grande e meno efficiente.

  1. Se una tabella non dispone di una chiave appropriata o se si preferisce che non vengano utilizzate le chiavi esistenti, è possibile definire una chiave sostitutiva se la tabella contiene colonne che contengono sempre valori univoci. Per definire questa chiave sostitutiva, includere una clausola KEYCOLS nel parametro Extract TABLE e nel parametro Replicat MAP. La chiave specificata sostituirà qualsiasi chiave primaria o univoca esistente trovata da Oracle GoldenGate. Vedere TABLE | MAP in Reference for Oracle GoldenGate.

Tabelle con una chiave primaria derivata da un indice univoco

In assenza di una chiave primaria in una tabella, MySQL promuoverà un indice univoco alla chiave primaria se la colonna indicizzata è NOT NULL. Se sono presenti più indici non nulli, il primo creato diventa la chiave primaria. Per evitare errori di Replicat, creare questi indici nello stesso ordine nelle tabelle di origine e di destinazione.

Si supponga, ad esempio, che le tabelle di origine e di destinazione denominate ggvam.emp dispongano di colonne denominate prime, medie e ultime e che tutte siano definite come NOT NULL. Se si creano indici univoci nell'ordine seguente, Oracle GoldenGate interromperà la destinazione perché le definizioni delle tabelle non corrispondono.

Origine:

CREATE UNIQUE INDEX UQL ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ2 on ggvam.emp(middle);
CREATE UNIQUE INDEX UQ3 on ggvam.emp(last);

Destinazione:

CREATE UNIQUE INDEX UQ1 ON ggvam.emp(last);
CREATE UNIQUE INDEX UQ2 ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ3 ON ggvam.emp(middle);

Il risultato di questa sequenza è che MySQL promuove l'indice nella colonna "first" di origine alla chiave primaria e promuove l'indice nella colonna "last" di destinazione alla chiave primaria. Oracle GoldenGate selezionerà le chiavi primarie come identificativi quando crea il relativo record di metadati e i metadati non corrisponderanno. Per evitare questo errore, decidere quale colonna si desidera promuovere nella chiave primaria e creare l'indice in primo luogo nell'origine e nella destinazione.

Specificare la chiave personale da utilizzare per Oracle GoldenGate

Se una tabella non dispone di uno dei tipi precedenti di identificativi di riga o se si preferisce non utilizzare tali identificativi, è possibile definire una chiave sostitutiva se la tabella contiene colonne che contengono sempre valori univoci. Per definire questa chiave sostitutiva, includere una clausola KEYCOLS nel parametro Extract TABLE e nel parametro Replicat MAP. La chiave specificata sostituirà qualsiasi chiave primaria o univoca esistente trovata da Oracle GoldenGate.

Limita modifiche righe nelle tabelle che non dispongono di una chiave

Se una tabella di destinazione non dispone di una chiave primaria o di una chiave univoca, possono esistere righe duplicate. In questo caso, Oracle GoldenGate potrebbe aggiornare o eliminare troppe righe di destinazione, causando l'interruzione della sincronizzazione dei dati di origine e destinazione senza messaggi di errore per avvisare l'utente. Per limitare il numero di righe aggiornate, utilizzare il parametro DBOPTIONS con l'opzione LIMITROWS nel file dei parametri Replicat. LIMITROWS può aumentare le prestazioni di Oracle GoldenGate nel sistema di destinazione perché viene elaborata una sola riga.

Considerazioni sui trigger e sui vincoli in cascata

Trigger

Disabilitare i trigger nelle tabelle di destinazione o modificarli per ignorare le modifiche apportate dall'utente del database Oracle GoldenGate. Oracle GoldenGate replica DML risultante da un trigger. Se lo stesso trigger viene attivato nella tabella di destinazione, diventa ridondante a causa della versione replicata e il database restituisce un errore.

Considerazioni sui vincoli in cascata

Gli aggiornamenti e le eliminazioni a catena acquisiti da Oracle GoldenGate non vengono registrati nel log binario, pertanto non vengono acquisiti. Questo è valido sia per MySQL che per MariaDB. Ad esempio, quando si esegue l'istruzione delete nella tabella padre con una relazione padre-figlio tra le tabelle, l'eliminazione a catena (se presente) viene eseguita per la tabella figlio, ma non viene eseguito il login al log binario. Solo il record di eliminazione o aggiornamento per la tabella padre viene registrato nel log binario e acquisito da Oracle GoldenGate.

Per informazioni dettagliate, vedere https://mariadb.com/kb/en/replication-and-foreign-keys/ e https://dev.mysql.com/doc/refman/8.0/en/innodb-and-mysql-replication.html.

Per gestire correttamente la replica delle operazioni a catena, si consiglia di disabilitare le eliminazioni e gli aggiornamenti a catena nell'origine e nel codice dell'applicazione per eliminare o aggiornare in modo esplicito i record figlio prima di modificare il record padre. In alternativa, è necessario assicurarsi che la tabella padre di destinazione abbia gli stessi vincoli a catena configurati come tabella padre di origine, ma ciò potrebbe portare a una condizione non sincronizzata tra l'origine e la destinazione, soprattutto nei casi di replica bidirezionale.