看似简单的dual,其实深藏玄机

杨建荣 2016-01-13 09:48:34

对于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多天。
     



小编精心为大家挑选了近日最受欢迎的几篇热文:


回复001,看杨志洪《【职场心路】一个老DBA的自白》;

回复002,看丁俊的《【重磅干货】看了此文,Oracle SQL优化文章不必再看!》;

回复003,看胡怡文《PG,一道横跨oltp到olap的梦想之桥》;

回复004,看陈科《memcached&redis等分布式缓存的实现原理》

回复005,看宋日杰《Oracle后台专家解决library cache锁争用的终极武器》

回复006,看郑晓辉《存储和数据库不得不说的故事》

回复007,看袁伟翔《揭秘Oracle数据库truncate原理》;

回复008,看杨建荣《立等可取:工具定制让Oracle优化变得更简单快捷》;

回复009,看丁启良《LINUX类主机JAVA应用程序占用CPU、内存过高分析手段》

回复010,看徐桂林《以应用为中心的企业混合云管理》


关于DBA+社群

DBA+社群是中国最大的涵盖各种架构师、数据库、中间件的微信社群!线上分享2次/周、线下沙龙1次/月,顶级峰会6次/年,直接受众10000+,间接影响50万+ITer。DBA+社群致力于搭建一个学习交流、专业人脉、跨界合作的公益平台,更多精彩请持续关注dbaplus微信订阅号!

扫码关注

DBAplus社群

超越DBA圈子,连接的不仅仅是DBA

活动预告