Una forma de lidiar con esto sería crear una vista materializada de la tabla maestra en la base de datos local, luego crear la restricción de integridad que apunta al MV.
Eso funciona. Pero puede llevar a algunos problemas. Primero, si alguna vez necesita hacer una actualización completa de la vista materializada, deberá desactivar la restricción antes de hacerlo. De lo contrario, Oracle no podrá eliminar las filas en el MV antes de traer las nuevas filas.
En segundo lugar, puede experimentar algunos retrasos de tiempo. Por ejemplo, supongamos que agrega un registro a la tabla maestra en el sitio remoto. Luego, desea agregar un registro secundario a la tabla local. Pero el MV está configurado para actualizarse diariamente y eso aún no ha sucedido. Obtendrá una violación de clave externa, simplemente porque el MV no se ha actualizado.
Si realiza esta ruta, su enfoque más seguro es configurar el MV para que actualice rápidamente la confirmación de la tabla maestra. Eso significará mantener un DB Link abierto casi todo el tiempo. Y tendrá trabajo de administrador que hacer si alguna vez necesita hacer una actualización completa.
En general, generalmente hemos encontrado que un disparador es más fácil. En algunos casos, simplemente definimos el FK en nuestro modelo lógico, pero lo implementamos manualmente al configurar un trabajo diario que verificará las violaciones y alertará al personal. Por supuesto, somos muy cuidadosos, por lo que esas alertas son extremadamente raras.
Y tenga en cuenta que cualquier copia de seguridad/recuperación de cualquiera de las bases de datos podría romper esta 'restricción'. –