Régler les transactions de réplication

Le processus Replicat utilise des instructions SQL régulières, de sorte que ses performances dépendent des performances de la base de données cible et du type d'instruction SQL appliquée (insertions, mises à jour ou suppressions). Toutefois, vous pouvez prendre certaines mesures pour optimiser l'efficacité du processus Replicat.

Régler les performances de coordination par rapport aux transactions barrière

Dans une configuration Replicat coordonnée, les transactions de barrière telles que les mises à jour de la clé primaire entraînent une augmentation du nombre de validations dans la base de données et interrompent l'avantage de la fonctionnalité GROUPTRANSOPS du processus Replicat. Lorsque la charge globale globale du processus Replicat coordonné est soumise à un nombre élevé de transactions barrière, l'utilisation d'un nombre élevé de threads peut réellement dégrader les performances du processus Replicat.

Pour maintenir des performances élevées lorsque de nombreuses transactions barrière sont attendues, vous pouvez effectuer les opérations suivantes :

• Réduisez le nombre de threads actifs dans le groupe. Cela réduit le nombre total de validations effectuées par le processus Replicat.

• Déplacez les tables qui représentent la majorité des transactions barrière et toutes les tables avec lesquelles elles ont des dépendances vers un groupe Replicat coordonné distinct avec un petit nombre de threads. Conservez les tables présentant un nombre minimal de transactions barrière dans le groupe Replicat d'origine avec le nombre de threads le plus élevé, afin que les performances parallèles soient maintenues sans interruption par les transactions barrière.

• (Oracle RAC) Dans une nouvelle configuration Replicat, vous pouvez augmenter l'attribut PCTFREE de la table de points de reprise Replicat. Toutefois, cela doit être fait avant que le processus Replicat ne soit démarré pour la première fois. La valeur recommandée de PCTFREE est 90.

Empêcher les balayages complets de table en l'absence de clés

Si une table cible ne comporte pas de clé primaire, de clé unique ou d'index unique, le processus Replicat utilise toutes les colonnes pour créer sa clause WHERE. Il s'agit essentiellement d'un balayage complet de table (full table scan).

Pour rendre la sélection de ligne plus efficace, utilisez une clause KEYCOLS dans les instructions TABLE et MAP afin d'identifier des colonnes comme uniques. Le processus Replicat utilisera les colonnes indiquées comme clé. L'exemple suivant présente une clause KEYCOLS dans une instruction TABLE :

TABLE hr.emp, KEYCOLS (FIRST_NAME, LAST_NAME, DOB, ID_NO);

Pour connaître les instructions d'utilisation et la syntaxe, reportez-vous aux paramètres TABLE et MAP dans Référence des paramètres et des fonctions pour Oracle GoldenGate.

Fractionnement de transactions volumineuses

Si la base de données cible ne peut pas gérer les transactions volumineuses à partir de la base de données source, vous pouvez les fractionner en une série de transactions plus petites à l'aide du paramètre de réplication MAXTRANSOPS. Pour plus d'informations, reportez-vous à Référence des paramètres et des fonctions pour Oracle GoldenGate.

Remarque : MAXTRANSOPS n'est pas valide pour une réplication intégrée sur un système Oracle AI Database.

Ajustement des curseurs ouverts

Le processus Replicat gère les curseurs pour les instructions SQL mises en cache et pour les opérations SQLEXEC. Sans suffisamment de curseurs, le processus Replicat doit vieillir davantage d'instructions. Par défaut, le processus Replicat gère autant de curseurs que le paramètre MAXSQLSTATEMENTS autorise. Vous pouvez constater que la valeur de ce paramètre doit être augmentée. Si tel est le cas, vous devrez peut-être également ajuster le nombre maximal de curseurs ouverts autorisés par la base de données. Pour plus d'informations, reportez-vous à Référence des paramètres et des fonctions pour Oracle GoldenGate.

Amélioration de la vitesse de mise à jour

Une fragmentation excessive des blocs entraîne l'application des instructions SQL par le processus Replicat à une vitesse supérieure à la normale. Réorganisez les tables fortement fragmentées, puis arrêtez et démarrez Replicat pour enregistrer le nouvel ID d'objet.

Définir un délai d'expiration de transaction de réplication

Utilisez le paramètre TRANSACTIONTIMEOUT pour empêcher une transaction cible de réplication non validée de contenir des verrous sur la base de données cible et d'utiliser ses ressources inutilement. Vous pouvez modifier la valeur de ce paramètre afin que le processus Replicat puisse s'adapter aux délais d'attente d'application existants et à d'autres exigences de base de données sur la cible.

TRANSACTIONTIMEOUT limite la durée pendant laquelle le processus de réplication peut bloquer l'ouverture d'une transaction cible si elle n'a pas reçu l'enregistrement de fin de transaction pour la dernière transaction source de cette transaction. Par défaut, le processus Replicat regroupe plusieurs transactions source dans une transaction cible pour améliorer les performances, mais il ne valide pas une transaction source partielle et attend indéfiniment pour ce dernier enregistrement. Le paramètre de réplication GROUPTRANSOPS contrôle la taille minimale d'une transaction cible groupée.

Les événements suivants peuvent durer suffisamment longtemps pour déclencher TRANSACTIONTIMEOUT :

• Les problèmes réseau empêchent la transmission des données de trace au système cible.

• Espace disque insuffisant sur n'importe quel système, ce qui empêche l'écriture des données de trace.

• L'extraction est abandonnée ou se termine au milieu de l'écriture d'enregistrements pour une transaction.

• Il y a une panne du système source, telle qu'une panne de courant ou une panne du système.

Pour plus d'informations, reportez-vous à TRANSACTIONTIMEOUT dans Référence des paramètres et des fonctions pour Oracle GoldenGate.