对于dual总是有种熟悉而陌生的感觉，我们经常使用却对它知之甚少。今天由【DBA+社群】联合发起人杨建荣老师带你一起了解dual和它深藏的那些你不知道的玄机……
目录
为了存在而存在的dual
一个小案例中对dual的思考
Dual在数据库实例启动的不同阶段的变化
关于dual的改进：FAST DUAL
Dual中只保留一条数据记录的验证测试
关于dual破坏性测试和恢复
10g,11g,12c中都存在一个关于dual的小bug
一、为了存在而存在的dual
Dual在Oracle数据库中是一个特殊存在的对象，当然用黑格尔的哲学名言“存在即合理“来解释最恰当不过了。
我对dual的感觉就是为了存在而存在，一方面是为了保证语法的完整性，还有一种场景是为了序列的递增,如果再进一步，那应该是dual中会保留一条数据。
dual是一个虚表，也常称为dummy表。通过下面的查询结果可以很容易看出来dual是一个实体表，然后通过public的同义词，对所有的用户都可以提供访
问。
我对dual的关注源于一个小小的案例，也是在一次巡检中发现了一个小问题，然后死磕，发现了dual的一些小问题，最后也做了不少的测试。
二、 一个小案例中对dual的思考
Oracle对于sys用户的审计是默认的一个操作，所以不管你开启了什么审计策略，sys的登录操作都会记录下来，可能估计Oracle也没有料到有些应用会把这个影响放大，毕竟频繁登录sys听起来也是不现实的。但是放到大批量细粒度的自动化监控中，这个影响就会放大，可能在设计上有些功能还不够严谨，确切的说应该是存在一定的问题。
比如下面的这个场景，有一天我发现在审计目录下存在着大量细小的文件，生成时间也很紧凑，可见还是有一些操作很频繁的使用了sysdba登录数据库,而且生成了意料之外的大批量审计日志文件。
不要小瞧这些细小的文件，如果积累到一定程度，就会带来不小的影响。比如命令ls支持不了
或者inode溢出。
说完审计文件，我们打开看看里面的内容，里面是通过操作系统用户认证登录以后，做了一个简单的查询，通过语句可以看出来其实是在做一个判断，即数据库实例是否可用。
这个监控的逻辑就是如果实例可访问就返回 Oracle is alive，否则就报警。可能在大批量的服务器环境中还是需要这样的使用场景，在很短的时间间隔里去判断哪些数据库实例可能存在问题。
听起来还是可以接受的，如果审计日志文件太多，也可以考虑定期清理或者设置为noaudit的方式。
那么我们回到一个根本问题，这个监控语句有没有问题呢。
我们来做一个简单的实验。我把数据库用最少的参数启动到Nomount阶段，这个时候数据库实例其实还是不可用的，我们来看看这个监控语句是否可用。
首先就是最简单的参数文件，目前就配置了两个参数。
这个时候发现 这个简单的监控语句在nomount状态下也是可用的，这个时候还没有开始初始化数据字典，但是就是可以做一些计算。
所以通过这个细小的案例还是发现，其实监控的一些方式还是需要斟酌，如果需要做数据库是否可用的检查验证，使用了select 'Oracle is alive'的方式验证，那么可能数据库还没到open阶段，通过这个语句就已经“验证”数据库服务已经OK了，这种情况还是很容易造成误导。还是需要好好注意一下。
所以一个初步结论就是使用dual来做监控还是存在一定的隐患，很可能监控会给我们带来一些误导，因为数据库实例在nomount,mount,open阶段都可以成功输出结果。
一个小小的案例结束，我的分析才刚刚开始。
三、 Dual在数据库实例启动的不同阶段的变化
如果你观察仔细，就会发现dual在数据库启动的不同的阶段，里面的字段其实还会发生一些微妙的变化。在nomount和mount阶段含有多个“字段”，而不是一个。
如果感兴趣可以仔细分析一下上面的原委，如果从实用主义的角度，可能会感觉然并卵，好吧，我们再来看一个例子：FAST DUAL。
四、 关于dual的改进:FAST DUAL
如果追溯起来，FAST DUAL执行计划是Oracle10g中的新特性。对使用DUAL进行的计算，可以不用真正的访问表，从而快速的得到结果。
这个改变似乎并不起眼，但是实际上累计起来对于系统的影响还是很大的。
我们来简单测试一下两者的细微差别。
可以看到FAST DUAL的场景下consistents gets为0，然后再来看一下查询全表数据的情况，其实里面只有一条数据，但是还是会有额外的consistent gets。
明白了dual的一些基本使用，如果想更进一步了解dual，可以做一些小的测试。
五、 Dual中只保留一条数据记录的验证测试
我们再来看看dual的表结构，只有一个字段，里面也只有一条纪录。
那么我们可以不可以自己新建一个dual表呢，答案是当然可以。
不过这个使用下面的语句查看，会查不出结果。
SQL> select 4*5 from dual2;
no rows selected
这个时候肯定不行，主要原因就在于dual2中没有记录，而dual中始终保持一条记录。
这句话听起来很简单易懂，怎么实践呢。
在测试了10g,11g,12c中的dual的情况后，测试结果都是一致的。
我们给dual中插入一条记录。
这个时候查看dual表的数据，发现还是只有一条。
查看条数也只有1行。
那么还可以怎么玩呢。我们尝试删除。
SQL> delete from dual;
1 row deleted.
然后查看，刚刚插入的y这个时候又看到了。如果你继续delete还是会显示X
通过这个例子可以看出oracle对于dual的处理也是苦心积虑，需要dual里面始终保持一条记录。当然里面的值就是一个dummy值，没有其它实际的含义。
六、 关于dual破坏性测试和恢复
关于dual表的破坏性测试，既然是破坏性测试，首先严正声明，这个测试仅限于测试或者个人学习所用，可能有些sql看似极为简单，但是一旦运行就会导致业务系统崩溃。
比如说我们拿dual表开刀，因为这个表是一个dummy表，里面的内容没有特定的意义，就是为了存在而存在。但是一旦这个表出现问题，所有相关的基础操作都会受到影响，后果可不敢想象。
我们来简单模拟一下，在个人的机器上开始做下面的尝试，drop 表dual
--如果没有尝试重启数据库的情况下，完全可以采用如下的方式来解决，我们可以完全重建表dual,插入dummy的数据。
这个时候可以查看相关的sys下的失效对象，会发现大量的object都是INVALID状态，这个时候还是需要重新编译一下，使用utlrp.sql 或者手工编译即可。
如果不幸的是我们在出现问题的时候尝试重启数据库，就会发现数据库就起不来了。
alert日志中的相关内容如下：
日志中提到的trace 文件的内容如下：
如果确实知道问题的原因就轻车熟路的解决了，要不还需要费一番周折诊断，开启一些更为详尽的trace来排查。
这个错误和数据库参数replication_dependency_tracking有关,默认是TRUE,我们需要暂时绕过这个校验，先把库启动起来，然后重建表dual就可以了。在修复以后，重启数据库然后恢复replication_dependency_tracking的默认值TRUE
重启后需要创建dual表。然后把replication_dependency_tracking再置为默认值true，重新编译失效对象，这个问题的解决就告一段落了。
当然对于这个问题，MOS也有一篇文章去介绍如何修复，步骤也是大同小异。
How to Recreate Dual Table (Doc ID 1163714.1)
七、10g,11g,12c中都存在一个关于dual的小bug
对于这些细节如果多探索一些，就会发现一些奇怪而又意思的小问题，这个问题我在10g,11g,12c中都测试过，都可以复现，应该是一个未发布的bug。
不过过程也还是蛮有意思。
在12c中简单复现一下。
SQL> desc dual --这一步操作就是这么微妙，但是select * from dual就是有结果的。
当然解决方法也很简单，就是退出当前的session重新登录重启即可。
当然对于这个问题也可以开启更多的诊断事件去做分析。
可以看到一个看起来非常平淡的dual,其实还是有很多值得注意的地方。
最后说一句知乎中抄来的名言，平淡其实是很奢侈的，那意味着有许多爱你的人在为你付出，而在这里就是我们可爱的DBA们。
作者介绍：杨建荣
【DBA+社群】联合发起人
Oracle ACE-A,YEP成员,现就职于搜狐畅游，拥有6年以上的数据库开发和运维经验，曾任amdocs DBA,负责亚太电信运营商的数据业务支持，擅长电信数据业务,数据库迁移和性能调优。
拥有Oracle 10g OCP,OCM, MySQL OCP认证,对shell,java有一定的功底,曾在2015年数据库大会进行关于数据迁移和升级的主题分享，现在每天仍在孜孜不倦的进行技术分享，每天通过微信，技术博客共享，已连续坚持550多天。
