对于数据卫士，您可以在物理备用和逻辑备用之间进行选择。让我们先来看一下两者
有哪些不同！我将首先演示物理备用，随后转换至逻辑备用（数据库也由此命名）：
到目前为止，logst仍然是物理备用。被称为物理备用的原因是，prima和logst的数据文件在物理上是相同的。我甚至可以从一个还原至另一个：
现在，我从备用服务器uhesse2中将数据文件复制到主服务器uhesse1，有不同的方法可以做到这一点，但scp是一个：
当我尝试将数据文件在prima上再次上线时，看起来就像我想从备份中将其恢复：
在此处的两个站点中，数据文件和归档的日志文件在物理上都是相同的，只有控制文
件是不同的。 v$database（比如v$datafile）从控制文件获取其内容：
现在，我要将其转换至逻辑备用：
一处重要的改变是， DBID和名称现已不同于上面看到的主数据库。数据文件在物理上也不再是相同的：
我复制原始文件的原
因是，我知道从logst恢复将不起作用。为了证明我的观点：
没错，logst现在是一个自主数据库，它只是偶然地使用与prima（几乎）相同的DML。它在Oracle数据块方面已不再与prima相同。对于logst来说，来自于prima的rowids已不再有意义：
这就是我们通常记录在重做日志条目中的rowid，在我们进行“Redo Apply”（“恢复数据库”的另一种术语）时，该rowid足以在主数据库上以及一个物理备用上对该行进行检索。但这个rowid在logst上是不同的：
这就是为什么我们需要将附加信息（补充日志数据）放入主数据库的重做日志条
目中。这将帮助SQL
Apply机制对该行进行检索：
逻辑备用架构
补充日志数据应至少额外包括上图中的主键。在没有主键的情况下，修改行的每
一列将被写入重做日志。 这将影响主数据库的性能。逻辑备用的另一个严重缺点是，SQL Apply机制并不支持每个数据类型和每个在主数据库上的操作。然而，不支持的数据类
型数量随着版本的升级正在逐渐减少。
以上演示和草图出自我在2015年迪拜甲骨文大学专家峰会中做出的关于瞬态逻辑备用的展示，希望能够为您带来帮助:-)