Utilisation de tables optimisées pour la recherche

L’optimisation de la recherche est généralement transparente pour les utilisateurs. Les requêtes fonctionnent de la même manière ; certaines sont simplement plus rapides. Cependant, il est important d’être conscient des effets possibles d’autres opérations de table sur le service d’optimisation de la recherche, ou l’inverse.

Modification de la table

Un chemin d’accès de recherche devient non valide si la valeur par défaut d’une colonne est modifiée.

Pour utiliser à nouveau l’optimisation de la recherche après qu’un chemin d’accès de recherche est devenu non valide, vous devez supprimer la propriété SEARCH OPTIMIZATION et ajouter à nouveau la propriété SEARCH OPTIMIZATION à la table.

Un chemin d’accès à la recherche reste valable si vous ajoutez, détruisez ou renommez une colonne :

  • Si vous avez activé l’optimisation de la recherche pour une toute une table sans spécifier de colonnes spécifiques, lorsque vous ajoutez une colonne à une table, la nouvelle colonne est automatiquement ajoutée au chemin d’accès à la recherche. Toutefois, si vous avez utilisé la clause ON lors de l’activation de l’optimisation de la recherche pour une colonne, les nouvelles colonnes ne sont pas ajoutées automatiquement.

  • Lorsque vous détruisez une colonne d’une table, la colonne détruite est automatiquement retirée du chemin d’accès à la recherche.

  • Le changement de nom d’une colonne ne nécessite aucune modification du chemin d’accès à la recherche.

Si vous détruisez une table, la propriété SEARCH OPTIMIZATION et les chemins d’accès à la recherche sont également détruits. Remarques importantes :

  • Le rétablissement de la table rétablit immédiatement l’optimisation de la recherche en tant que propriété de la table.

  • Lorsque vous détruisez une table, le chemin d’accès à la recherche a la même période de conservation des données que la table.

Si vous détruisez la propriété SEARCH OPTIMIZATION de la table, le chemin d’accès à la recherche est supprimé. Lorsque vous rajoutez la propriété SEARCH OPTIMIZATION à la table, le service de maintenance doit recréer le chemin d’accès de recherche. (Il est impossible de rétablir la propriété).

Clonage de la table, du schéma ou de la base de données

Si vous clonez une table, un schéma ou une base de données, la propriété SEARCH OPTIMIZATION et les chemins d’accès à la recherche de chaque table sont également clonés. (Le clonage d’une table, d’un schéma ou d’une base de données crée un clone à zéro copie de chaque table et ses chemins d’accès de recherche correspondants.)

Notez que si vous utilisez CREATE TABLE … LIKE pour créer une nouvelle table vide avec les mêmes colonnes que la table d’origine, la propriété SEARCH OPTIMIZATION n’est pas copiée dans la nouvelle table.

Travailler avec des tables dans une base de données secondaire (aide à la réplication d’une base de données)

Si la propriété SEARCH OPTIMIZATION est activée dans une table de la base de données principale, la propriété est répliquée dans la table correspondante de la base de données secondaire.

Les chemins d’accès de recherche dans la base de données secondaire ne sont pas répliqués, mais reconstruits automatiquement. Il est à noter que ce processus entraîne les mêmes types de coûts que ceux décrits dans Optimisation de la recherche - Estimation et gestion des coûts.

Partage de tables

Les fournisseurs de données peuvent utiliser Secure Data Sharing pour partager des tables pour lesquelles l’optimisation de la recherche est activée.

Lors de l’interrogation de tables partagées, les consommateurs de données peuvent bénéficier des améliorations de performances apportées par le service d’optimisation de la recherche.

Politiques de masquage et politiques d’accès aux lignes

Le service d’optimisation de la recherche est entièrement compatible avec les tables qui utilisent des politiques de masquage et des politiques d’accès aux lignes.

Toutefois, lorsque l’optimisation de la recherche est activée, un utilisateur qui ne peut pas voir une valeur en raison d’une politique de masquage ou d’une politique d’accès aux lignes peut être en mesure de déduire avec plus de certitude si cette valeur existe. Avec ou sans optimisation de la recherche, les différences de temps de latence des requêtes peuvent fournir des indications sur la présence ou l’absence de données limitées par une politique, ce qui peut constituer un problème de sécurité en fonction de la sensibilité des données. Cet effet peut être amplifié par l’optimisation de la recherche puisqu’elle peut rendre encore plus rapide une requête qui ne donne pas de résultats.

Par exemple, supposons qu’une politique d’accès aux lignes empêche un utilisateur d’accéder à des lignes avec country = 'US', mais que les données n’incluent pas de lignes avec country = 'US'. Supposons maintenant que l’optimisation de la recherche est activée pour la colonne country et que l’utilisateur exécute une requête avec WHERE country = 'US'. La requête renvoie des résultats vides comme prévu, mais la requête peut s’exécuter plus rapidement avec l’optimisation de la recherche que sans. Dans ce cas, l’utilisateur peut plus facilement déduire que les données ne contiennent pas de ligne où country = 'US' en fonction du temps nécessaire pour exécuter la requête.