我有一个带有极复杂且设计糟糕的架构的Oracle 11g数据库。这是一个具有许多依赖关系的遗留系统，它支持多个关键应用程序，遗憾的是，修改此数据库的模式是不可能的。
我正在开发一个Web应用程序（ASP.NET MVC 5），它充当此数据库中信息的只读状态仪表板。目前，我依靠专门构建的数据库视图来获取Web应用程序所需的信息。鉴于模式的复杂性，许多这些视图的表现非常差。当Web应用程序忙于许多用户时，数据库很难跟上，通常会导致超时错误。此外，当数据库因任何原因失败时，Web应用程序无法显示任何数据。用户仍然希望Web应用程序在数据库失败之前显示数据的快照。
数据的本质是非常动态的，不断地由几个外部系统和进程添加/更新/删除行，我无法知道底层数据何时发生变化，所以我必须重新开始 - 查看获取新数据的视图。
由于这种情况，我们正在考虑删除此数据库与Web应用程序之间的直接链接，而是在它们之间创建某种中间缓存/数据库/魔术层。这样，Web应用程序稍后将从此中介获取其数据，而不会对复杂数据库造成沉重负担。当复杂数据库失败时，Web应用程序仍然可以查询来自此中间层的数据的最后一个快照。
问题是，这个中间层应该是什么？因为我不知道底层数据何时以及如何变化，所以我无法维护数据的实时缓存。相反，我需要依赖此数据库中视图的快照。
这是我们目前的想法：
我们创建一个新的中间SQL Server / Oracle数据库。对于我们当前使用的每个数据库视图，作业每2分钟运行一次，查询它，然后将结果转储到我们的中间SQL Server / Oracle数据库中的表中。这将需要截断中间表，然后用新的视图结果数据重新填充它。与此同时，Web应用程序将查询这些中间表以获取数据。显而易见的问题是当Web应用程序在截断并重新填充新数据时尝试查询中间表时会发生什么？另一个问题是在从共享外键或相关数据的视图中获取数据时处理可能的并发问题。
通常，Web应用程序只会维护一个缓存，但这需要挂钩到数据库中的add / update / delete事件以维护缓存的状态。最重要的是，缓存不是数据库的完整快照。如果数据库失败，缓存将无法提供失败前数据的快照。
关于这个神奇的中间层应该是什么的任何其他建议？我们正在研究数据库端（SQL Server或Oracle）以及Web应用程序端的解决方案（ASP.NET MVC 5，IIS）上可用的解决方案。