FAQ sur la planification de l'actualisation fréquente des données V2

Cette rubrique répertorie les questions fréquemment posées sur la planification de l'actualisation fréquente des données V2.

Existe-t-il des contrôles d'accès ou des autorisations pour empêcher les autres utilisateurs d'Oracle Fusion Data Intelligence de modifier les programmations fréquentes d'actualisation des données que j'ai créées ?

Vous pouvez utiliser l'historique d'audit pour afficher les modifications fréquentes de la programmation d'actualisation des données. Actuellement, il n'existe aucun contrôle d'accès ni aucune autorisation pour empêcher les autres utilisateurs de modifier vos programmations d'actualisation de données fréquentes.

Les tables delta sont-elles tronquées après chaque actualisation fréquente des données ou après la prochaine actualisation incrémentielle ?

Les tables delta sont tronquées après la prochaine actualisation incrémentielle.

Devons-nous utiliser des vues lambda ou des tables delta pour déplacer les données V2 d'actualisation fréquente les plus récentes d'Oracle Fusion Data Intelligence vers le lac de données d'entreprise en aval ?

Pour les intégrations en aval, il est recommandé de capturer les modifications de données. Reportez-vous à Capture Data Changes (Preview).

L'indicateur FDR est-il activé automatiquement pour les faits personnalisés, les dimensions personnalisées, les dimensions confirmées personnalisées ou les faits personnalisés ? Les tables lambda ou delta sont-elles créées manuellement ou automatiquement dans Oracle Fusion Data Intelligence ?

Lorsque vous exécutez des actualisations fréquentes des données, les tables lambda ou delta sont créées automatiquement.

L'actualisation fréquente des données V2 gère-t-elle les suppressions fermes effectuées dans Oracle Fusion Cloud Applications ?

Non Actuellement, l'actualisation fréquente des données V2 ne gère pas les suppressions physiques effectuées dans Oracle Fusion Cloud Applications.

Est-il possible de planifier l'actualisation des données toutes les deux semaines plusieurs fois par jour ?

Non Vous ne pouvez pas planifier l'actualisation des données toutes les deux semaines plusieurs fois par jour.

Continuerez-vous à prendre en charge les utilisateurs qui utilisent fréquemment l'actualisation des données V1 ?

Nous prenons actuellement en charge l'actualisation fréquente des données V1, mais nous recommandons aux utilisateurs de mettre à niveau et d'utiliser l'actualisation fréquente des données V2.

Des modifications de prix seront-elles apportées aux clients de la version 1 de l'actualisation fréquente des données qui migrent vers la version 2 de l'actualisation fréquente des données ?

Contactez votre chargé de compte Oracle pour discuter des implications spécifiques de l'actualisation fréquente des données V2. Ils peuvent fournir des informations détaillées et mises à jour sur les licences et les coûts adaptés aux besoins de votre organisation.

Est-il possible d'augmenter les limites d'actualisation fréquente des données V2 ? Par exemple, pouvons-nous demander plus de 20 tables pour une actualisation fréquente des données ?

Demandez au support technique Oracle d'augmenter vos limites. Notez que l'augmentation des limites peut avoir des conséquences sur les coûts.

Quelle colonne de la vue lambda correspond au champ Date la plus ancienne à rapport ?

Téléchargez la feuille de calcul d'objets de base de données V2 d'actualisation fréquente des données pour chaque pilier dans l'onglet FilterDateCols Tbls recommandés pour réviser les colonnes de date de filtre V2 d'actualisation fréquente des données afin de repérer le filtre utilisé.

Y a-t-il des inconvénients potentiels ou des impacts sur les performances pour augmenter le nombre de modules ou de tables FDR ?

Oui. Reportez-vous à Remarques concernant les performances pour l'actualisation fréquente des données.

Quelle est la différence entre les données stockées dans les tables de data warehouse après des actualisations incrémentielles et fréquentes des données ?

L'ancien mécanisme FDR V1 d'actualisation fréquente des données a mis à jour les mêmes tables de data warehouse de base que celles mises à jour par l'actualisation incrémentielle programmée. Le nouveau mécanisme d'actualisation fréquente des données FDR V2 ne met pas à jour les tables de data warehouse de base. Il utilise plutôt des tables Delta pour stocker les données qui ont été modifiées. Les vues lambda intègrent les données de base issues de l'actualisation incrémentielle des données et des modifications jusqu'au moment où l'actualisation fréquente des données a eu lieu. En outre, les tables Delta sont réinitialisées lors de chaque actualisation incrémentielle. L'actualisation fréquente des données V2 met à jour les données dans les tables d'entrepôt plus efficacement, ce qui permet des actualisations de données potentiellement plus fréquentes. Oracle recommande vivement de migrer de FDR V1 vers FDR V2 pour tirer parti de ses performances améliorées et de ses fonctionnalités étendues. Pour plus d'informations, reportez-vous à Planification des actualisations fréquentes des données avec un mécanisme de régénération repensée (aperçu).