Limites et objets et opérations non pris en charge

GoldenGate Replicat comporte les mêmes limitations que celles qui existent dans Google Cloud Spanner. Le développeur d'applications doit être conscient de ces limites et doit concevoir sa charge d'application en conséquence.

Voici les opérations qui ne sont pas prises en charge par la réplication Oracle GoldenGate pour Google Spanner, dans la version actuelle :

• La réplication parallèle n'est pas prise en charge dans la version de prévisualisation.

• La réplication LDD n'est pas prise en charge avec la réplication pour Google Cloud Spanner.

• SQLEXEC n'est pas pris en charge.

• L'évolution automatique des schémas n'est pas prise en charge.

• La détection et la résolution des conflits ne sont pas prises en charge avec Replicat pour Google Cloud Spanner.

• Le processus Replicat Oracle GoldenGate ne prend pas en charge PKUPDATE pour les tables qui ont appliqué une contrainte d'intégrité référentielle (pour ON DELETE CASCADE et ON DELETE NO ACTION).

• La réplication pour Google Spanner ne prend pas en charge SUSPEND EVENT ACTION car la base de données Google Cloud Spanner supprime automatiquement toute transaction de lecture/écriture inactive pendant plus de 10 secondes et ne prend pas en charge toute configuration permettant d'augmenter le délai d'inactivité de 10 secondes. Si vous utilisez SUSPEND comme action d'événement, la transaction restera ouverte pendant plus de 10 secondes et sera annulée automatiquement sur RESUME.

  Dans ce cas, vous pouvez utiliser la règle REPERROR RETRY sur l'erreur ABORTED (code d'erreur 10) pour réessayer la transaction lorsque la réplication rencontre une transaction abandonnée. Cela s'applique également aux règles LMD REPERROR RETRY où une nouvelle tentative LMD après plus de 10 secondes entraînera l'annulation automatique de la transaction en cours par Spanner.

• Si le processus Replicat pour Spanner trouve une table qui a imposé une clé étrangère, il s'interrompt avec l'erreur suivante.

  Google Spanner does not natively support PKUpdate.
  The PKUpdate operation is implemented in GoldenGate as DELETE followed by INSERT OR IGNORE
  operation.
  
  If the table contains enforced foreign key, PKUpdate (delete followed by insert) might
  unintentionally delete the records from the child table.
  
  In this case, you can take any of the following actions to continue:
  
        1. If you do not intend to perform PKUpdate on table, use ALLOW_ENFORCED_FK in the Replicat parameter file.
  
        2. Modify the enforced foreign keys to informational foreign keys
  
        3. If the table is not required, exclude the target table from Replicat mapping to continue.

• Voici les détails concernant les limites de la prise en charge des signaux d'activité :

  • Google Spanner prend uniquement en charge la réplication Oracle GoldenGate et non l'extraction. Par conséquent, le paramètre TARGETONLY / NOTARGETONLY n'est explicitement pas pris en charge sur Google Spanner, comme dans les bases de données TimesTen et Teradata.

  • Oracle GoldenGate ne prend en charge que la distribution sur Google Spanner. Par conséquent, aucun mécanisme n'est requis pour remplir ou mettre à jour les tables de signal d'activité à l'aide des programmateurs d'événements ou de travaux.

  • La commande ADD HEARTBEATTABLE avec les options FREQUENCY, PURGE_FREQUENCY ou RETENTION_TIME n'est pas prise en charge dans Google Spanner. Lorsque l'une de ces options est spécifiée avec la commande ADD HEARTBEATTABLE, un message d'information s'affiche indiquant que l'option est ignorée.

  • Les travaux et fréquences de signal d'activité ne sont pas pris en charge dans Google Spanner, de sorte que la commande ALTER HEARTBEATTABLE n'est pas prise en charge sur Google Spanner. Si elle est utilisée, la commande est ignorée en mode silencieux.

  • Spanner ne dispose d'aucun planificateur d'événements ou de tâches interne. Il est donc impossible de purger automatiquement les tables d'historique des signaux d'activité. Vous devez tronquer explicitement les objets de signal d'activité correspondants.

• Si une transaction entraîne plus de 80 000 mutations, Spanner renvoie une erreur et le processus Replicat abandonne avec cette erreur.

  De la même manière, la taille de transaction de Spanner est de 100 MiB et si les données écrites par la transaction dépassent 100 MiB (y compris les index et les flux de modification), la transaction échoue et le processus Replicat s'interrompt avec des erreurs.

  Pour gérer les limites de transaction de 80000/100 Mo de Spanner, vous devez utiliser le paramètre de réplication MAXTRANSOPS pour fractionner les transactions source volumineuses en lots cible plus petits, avant d'atteindre les limites de validation de Spanner.

• Spanner applique qu'une transaction en lecture-écriture voit une version de schéma unique et cohérente du début à la fin. Lorsqu'une instruction LDD (toute table/index de la base de données) est validée, la version de schéma de la base de données avance. Les transactions qui ont démarré sous la version précédente sont abandonnées avec une erreur, indiquant la modification du schéma. L'abandon est de conception et est traité de la même manière que les autres abandons tentables en raison de conflits ou d'erreurs transitoires. Pour effectuer une récupération suite à cette erreur, attendez la fin de l'opération LDD en cours, puis redémarrez le processus Replicat.