Présentation de l’actualisation des tables dynamiques¶

Types d’actualisation de table dynamique¶

Le processus d’actualisation d’une table dynamique se déroule de deux manières :

1. Actualisation incrémentielle : ce processus automatisé analyse la requête de la table dynamique et calcule les changements survenus depuis la dernière actualisation. Il fusionne ensuite ces modifications dans la table. Voir Requêtes prises en charge dans le cadre de l’actualisation incrémentielle pour plus de détails sur les requêtes prises en charge.

2. Actualisation complète : Lorsque le processus automatisé ne peut pas effectuer une actualisation incrémentielle, il effectue une actualisation complète. Cela implique l’exécution de la requête pour la table dynamique et le remplacement complet des résultats matérialisés précédents.

Les constructions utilisées dans la requête déterminent si une actualisation incrémentielle peut être utilisée. Après avoir créé une table dynamique, vous pouvez surveiller la table pour déterminer si des actualisations incrémentielles ou complètes sont utilisées pour mettre à jour cette table.

Comprendre la latence cible¶

L’actualisation de table dynamique est déclenchée en fonction du degré d’obsolescence des données, ce que l’on appelle communément latence ou latence cible.

La latence cible est spécifiée de deux manières :

1. Mesure de niveau d’actualisation : spécifie le délai maximum pendant lequel le contenu de la table dynamique doit être décalé par rapport aux mises à jour des tables de base.

   Spécifiée à l’aide du paramètre TARGET_LAG = { num { seconds | ... | days } lors de la modification ou de la définition initiale d’une table dynamique.

2. DOWNSTREAM : spécifie que la table dynamique doit être actualisée à la demande lorsque d’autres tables dynamiques qui en dépendent doivent être actualisées. Les mises à jour sont déduites des objets de la base de données en amont. Les tables dynamiques en aval ne sont mises à jour qu’à la demande des consommateurs en amont.

Prenons l’exemple suivant, dans lequel la table dynamique 2 (DT2) est définie sur la base de la table dynamique 1 (DT1). DT2 doit lire dans DT1 pour matérialiser son contenu. En outre, un rapport consomme des données DT2 par le biais d’une requête.

Les résultats suivants sont possibles, en fonction de la manière dont chaque table dynamique spécifie sa latence :

Requêtes prises en charge dans le cadre de l’actualisation incrémentielle¶

La table suivante décrit les expressions, les mots-clés et les clauses qui prennent actuellement en charge l’actualisation incrémentielle. Pour une liste des requêtes qui ne prennent pas en charge l’actualisation incrémentielle, voir Limitations de la prise en charge de l’actualisation incrémentielle.

Fonctions non déterministes prises en charge dans le cadre d’une actualisation complète¶

Les fonctions non déterministes suivantes sont prises en charge dans les tables dynamiques. Notez que ces fonctions ne sont prises en charge que pour les actualisations complètes. Pour une liste des éléments non pris en charge pour l’actualisation incrémentielle, voir Limitations de la prise en charge de l’actualisation incrémentielle.

• Fonctions définies par l’utilisateur VOLATILE

• Fonctions séquentielles (par exemple SEQ1, SEQ2)

• Les fonctions contextuelles suivantes :

  • CURRENT_ROLE

  • CURRENT_WAREHOUSE

  • CURRENT_ACCOUNT

  • CURRENT_REGION

• Les fonctions de date et d’heure suivantes (ainsi que leurs alias respectifs) :

  • CURRENT_DATE

  • CURRENT_TIME

  • CURRENT_TIMESTAMP

Comment les données sont-elles actualisées lorsque des tables dynamiques dépendent d’autres tables dynamiques ?¶

Lorsqu’une latence de table dynamique est spécifiée en tant que mesure de temps, le processus d’actualisation automatisé détermine le calendrier des actualisations, sur la base des temps de latence cibles des tables dynamiques. Le processus choisit un calendrier qui respecte au mieux les temps de latence cibles des tables.

Afin de préserver la cohérence des données dans les cas où une table dynamique dépend d’une autre, le processus actualise toutes les tables dynamiques d’un compte à des moments compatibles. Le délai des actualisations moins fréquentes coïncide avec celui des actualisations plus fréquentes.

Par exemple, supposons qu’une table dynamique A ait un temps de latence cible de 2 minutes et qu’elle interroge une table dynamique B dont le temps de latence cible est d’une minute. Le processus peut déterminer que A doit être actualisée toutes les 96 secondes et B toutes les 48 secondes. En conséquence, le processus peut se dérouler selon le calendrier suivant :

Cela signifie qu’à tout moment, lorsque vous interrogez un ensemble de tables dynamiques qui dépendent les unes des autres, vous interrogez le même « instantané » des données de ces tables.

Notez que la latence cible d’une table dynamique ne peut être plus courte que la latence cible des tables dynamiques dont elle dépend. Par exemple, supposons ceci :

• Une table dynamique A interroge les tables dynamiques B et C.

• La table dynamique B a une latence cible de cinq minutes.

• La table dynamique C a une latence cible d’une minute.

Cela signifie que le temps de latence cible pour A ne doit pas être inférieur à cinq minutes (c’est-à-dire qu’il ne doit pas être inférieur au plus long des temps de latence pour B et C).

Si vous définissez la latence pour A à cinq minutes, le processus établit un calendrier d’actualisation avec ces objectifs :

• Actualisez C suffisamment souvent pour que sa latence soit inférieure à une minute.

• Actualisez A et B en même temps et suffisamment souvent pour que leur latence soit inférieure à cinq minutes.

• Assurez-vous que l’actualisation de A et B coïncide avec l’actualisation de C pour garantir l’isolation des instantanés.

Remarque : si les actualisations prennent trop de temps, le programmateur peut ignorer des actualisations pour essayer de rester à jour. Toutefois, l’isolation des instantanés est préservée.