Oracle Announces Availability of Oracle Autonomous Transaction Processing(ATP)

在8月7日,Oracle宣布在云上正式上线自治事务处理数据库,这个名词ATP应对于早前发布的ADW(今年3月份Oracle宣布正式上线的自治数据仓库数据库)。 完整的发布会视频链接在这里

全自动

Atp1
Nothing to Learn, Nothing to Do. 这句宣传语在Larry的演讲中被重复了很多次。我们可以将自治数据库想象成自动驾驶,在没有自动驾驶之前,驾驶员要开一辆车从A地到B地,需要先考取驾照,还需要学习很多技巧,并且在开车的过程中仍然需要集中精力,否则容易出差错。但是有了自动驾驶(理想状态中的自动驾驶),我们不再需要驾驶员,乘客只需要告诉车辆我要从A地到B地,车辆就自动寻找最佳路线行驶了,在这个体验中,乘客完全不需要学些任何驾驶技巧,也不需要做任何驾驶的事情。这就是Nothing to Learn, Nothing to Do,那么在最新的Oracle自治数据库中,传统的DBA工作也不再需要了。安装、扩展、优化、安全、高可用、备份恢复等等,这些以往高深的技巧,现在统统不再需要学习,也不再需要DBA手工去做了。 恭喜大家,在传统DBA的职业道路上离失业又近了一步。

真.弹性

Atp2
Larry在整个演讲中,不知道说了多少次AWS,基本上就是盯着AWS打。只会为使用到的基础架构资源付费,没用到的不用付钱。如果把数据库从AWS上迁移到Oracle Cloud上的自治数据库里,承担的成本将减半,特意重点标注了“Guaranteed”,Larry拍着胸脯保证,账单数字一定会减半。

是骡子是马拉出来遛

Atp3
Atp4
Atp5
Larry接着连续用三页PPT叫板AWS,甚至在已经播放到下一环节以后,又请播放人员退回到上一页,持续嘲讽AWS。这就像60等级时候的魔兽世界,熟悉的“3破输出!”,Larry就是战士坦克,释放3个破甲,建立好仇恨,现在,DPS们可以输出了。 Oracle自治数据库,比AWS数据库快5-10倍。Larry,快5-10倍是什么意思?就是我用10秒钟干活的活儿,你AWS要干1分钟,在按照分钟计费的Cloud数据库中,这就意味着我比AWS要便宜5-10倍。 在纯的在线交易测试中,Oracle ATP比Aurora快12倍,在混合负载场景下,Oracle ATP比Aurora快100倍。在这一页上,Larry疯狂嘲讽了AWS,他说,AWS让别人用Aurora,用Redshift,但是他们自己却在用Oracle,在10年前,AWS就说要弃用Oracle数据库,但是到现在他们也没有做到。Larry还顺道一并嘲讽了SAP和Salesforce,他说这几个哥们儿都特别不想用Oracle数据库,但是怎么去也去不掉,因为这件事情真的很难很难,还因为Oracle数据库真的很优秀很优秀。 Oracle自治数据库可以在运行的同时实现安全补丁安装,可以让数据库获得99.995%的可用性,而AWS则做不到这一点,他们没办法在运行的时候为数据库打补丁。因此Oracle比Amazon稳定100倍。好吧,虽然我不知道这100倍的数字是怎么来的,但是Larry显得自信满满。

就是比AWS便宜

Atp6
整个演讲中间还有不少页,提及了Oracle自治数据库的优点,不过本来在这个世界上也确实没有比Oracle数据库单个解决方案更优秀的数据库产品了,因此Oracle数据库只是不断在超越自己,我们就不看了。我们总说,Oracle数据库除了贵没别的毛病,所以Larry在演讲快结尾的时候又再次提及了,这是我们写下来的承诺,能够满足客户业务负载的成本至少比Amazon便宜50%。

人干不过机器

Atp7
Larry在演讲的最后几分钟,举了NetSuite的案例。虽然PPT上的数字有些语焉不详,比如原来的8151个索引和下面的人类专家使用的4663个索引是什么关系?专家调优过的运行时间1172秒是运行了上面全部17542的SQL的总时长吗?但是,没关系,Oracle想说的是,Oracle ATP能够全自动地分析负载并创建更少更合适的索引,获得跟专家调优相近甚至更优的性能。 虽然为了公平起见,我们还是要提一下NetSuite是Oracle收购了的ERP厂商,但是毋庸置疑,人类传统DBA们面临了越来越多的挑战,就像前几天看到的新闻,DOTA2专业电子竞技高手被AI控制的机器完爆,打得找不到北。

免费品尝

Atp8
从Larry发表演讲的那一刻开始,就可以直接在Oracle Cloud网站申请免费测试Oracle ATP,但是在国内访问Oracle Cloud网站,特别是创建了免费账户以后登录进去的网站,遭遇了很强的阻碍。至少到目前为止,我还没有能成功地打开登录之后的第一个页面。欢迎期待我们测试以后的后续文章。

明年19c

Atp9
Larry简短地预报了Oracle数据库的路线图,在2019年一月份,将会发布Oracle 19c,还停留在11g时代的兄弟们,是不是应该感到惭愧了?

What’s the bug status code meaning in MOS

MOS中查看Bug database,会看到每个bug都有自己的status,那么这其中常见的status有哪些,又都分别是什么含义呢?

我们可以通过MOS中的Advanced Search功能查找特定状态的Bug,比如有哪些是已经确认为Bug移交到研发部门但是还没有补丁写出来的?

比较常见的status有以下这些。而这些状态也基本上表明了一个bug从接收到解决的流程。

10 – Description Phase
Development is requesting more information. 研发部门需要更多信息。

16 – Support bug screening
Bug is being reviewed by our Bug Diagnostics group. Bug诊断小组正在评估。

11 – Code Bug (Response/Resolution)
Bug is being worked by Development. 已经确认为Bug,研发部门正在尝试修正。

30 – Additional Information Requested
Bug is being worked by Support and/or more information was requested by Development. 技术支持已经参与工作,不过研发部门正在要求更多信息。这意味着补丁已经写完,正在让技术测试去测试是否有效。研发部门从现有的bug描述和上传的log截图等信息中还无法确定问题,要求bug的提交者提供其他更加详细的信息。

37 – To Filer for Review/Merge Required
Bug has been fixed but the patch will be merged into the next patchset. Bug已经修正但是补丁在下一个补丁集中一起发布。

80 – Development to Q/A
Bug is being regression tested for future release. Bug被移交到质量控制部门做回归测试。

81 – Q/A to Dev/Patch or Workaround Avble
Patch released via Metalink. 补丁发布到Metalink上。

90 – Closed, Verified by Filer
Bug has been fixed and is closed. Bug已经修正并且关闭。

91 – Closed, Could Not Reproduce
Bug is closed as not reproducible. Bug被关闭因为无法重现。

92 – Closed, Not a Bug
Bug is closed as not a bug (not reproducible or setup issue). Bug被关闭因为这不是个bug,可能是因为无法重现也可能仅仅是因为客户的安装问题。

93 – Closed, Not Verified by Filer
Bug has been fixed and is closed. Bug已经修正并且关闭。

95 – Closed, Vendor OS Problem
Bug is closed as an OS problem. Bug被关闭因为这是操作系统问题。

96 – Closed, Duplicate Bug
Bug is closed as a duplicate bug. Bug被关闭因为已经有重复的bug已经被报告了。

其中10, 16表示技术支持部门(也就是Oracle的OSS)提交了一个bug,但是研发部门还没有确认和接受它是一个真正的bug。
11表示bug已经移交到研发部门,研发人员正在尝试修正,还在工作过程中,目前为止还未修正。
80, 81, 90 , 93表示bug已被修正,补丁可以下载或者请求下载了。

DB time VS. DB CPU

如何行之有效地展示系统负载在做系统调优的时候是必不可少的技巧。通常我们会使用Oracle提供的Time Model,比如我们需要作出类似于下面这样的趋势图来展示系统负载的高低。

这样的趋势图可以直接使用Oracle10g以后的OEM得到,也可以将SQL结果传入Excel中作出趋势图,这里并不是想说如何作出这样的图来,而是想说在我们选取的性能指标中,DB time是什么意思?DB CPU是什么意思?

实际上,官方文档已经给出了解释(我很希望我早就注意到):V$SESS_TIME_MODEL

其中的事件模型树状图很值得参考。

总的来说(如果有任何错误,欢迎指正):
1. 数据库消耗的总时间包括background elapsed time + DB time,基本上在一个正常的系统中DB time要远远大于background elapsed time(指数据库后台进程消耗的时间,比如PMON进程本身)。
2. DB time包含DB CPU + sql execute elapsed time + parse time elapsed + 其它的那些elapsed time,基本上一个正常的系统中,前三项占据了99%以上的DB time,而其中sql execute elapsed time又应该会在95%以上,但是值得注意的是DB CPU和sql execute elapsed time是有交集的,因此你会看到在一份AWR报告中有出现DB CPU + sql execute elapsed time超过100% DB time的情况。
3. DB time是流逝的时间量(elapsed time),以微妙(microseconds)为单位,也就是百万分之一秒。在v$sys_time_model中的STAT_NAME是”DB time”。
4. DB CPU是CPU运转的时间,不包含数据库进程在等待CPU的时间,同样以微秒(microseconds)为单位。在v$sys_time_model中的STAT_NAME是”DB CPU”。
5. 我们在ASH报告中经常看到的’CPU + Wait for CPU’指的是DB time,而CPU就是DB CPU。

另外,下面的这三篇文章也同样值得阅读:
Average active sessions: the magic metric? (PDF by John Beresniewicz)
Time Matters – DB Time (from Doug’s Oracle Blog)
Time Matters – DB CPU (from Doug’s Oracle Blog)