Cette fonctionnalité reste applicable sur les systèmes ASA r2, même si ASA r2 utilise une architecture SAN simplifiée (SAZ et unités de stockage au lieu de volumes).

Les bases de données sont vulnérables à la corruption lors des basculements de stockage car elles conservent d'importants caches internes. Si un événement catastrophique nécessite de forcer un basculement ONTAP , indépendamment de l'état de la configuration globale, il en résulte que des modifications précédemment reconnues peuvent être effectivement abandonnées. Le contenu de la baie de stockage remonte dans le temps, et l'état du cache de la base de données ne reflète plus l'état des données sur le disque. Cette incohérence entraîne une corruption des données.

La mise en cache peut avoir lieu au niveau de l'application ou du serveur. Par exemple, une configuration Oracle Real Application Cluster (RAC) avec des serveurs actifs à la fois sur un site principal et un site distant met en cache les données dans l'Oracle SGA. Une opération de basculement forcé entraînant une perte de données exposerait la base de données à un risque de corruption, car les blocs stockés dans la SGA pourraient ne pas correspondre aux blocs sur le disque.

Une utilisation moins évidente de la mise en cache se situe au niveau du système de fichiers du système d'exploitation. Un système de fichiers en cluster basé sur des LUN situés sur le site principal pourrait être monté sur des serveurs du site distant, et les données pourraient à nouveau être mises en cache. Une défaillance de la NVRAM ou une prise de contrôle forcée dans ces situations pourrait entraîner une corruption du système de fichiers.

ONTAP protège les bases de données et les systèmes d'exploitation contre ce scénario grâce à NVFAIL et à ses paramètres associés, qui signalent à l'hôte d'invalider les données mises en cache et de remonter les systèmes de fichiers affectés après le basculement. Ce mécanisme s'applique aux LUN et aux espaces de noms ASA r2 de la même manière qu'à AFF/ FAS.