2016 Oracle 十大热门文章精选

Oracle 2016-12-31
223

当小编整理出年度最受欢迎的文章排行榜之后,不得不说,2016年是多灾多难的一年!尤其对于某些钟情于各类删除命令的哥们来讲!2017年,兄弟们可长点心吧!


今年我们在Oracle微信以坚持晨读的方式发布了上百篇技术文章,其中大部分是出于原创的技术文章,感谢各位专家及作者的支持!新的一年,我们会更加努力为各位分享有价值的文章和信息!感谢对我们微信的支持!


年度十大精华文章

1、高可用失灵:交换机导致Oracle集群故障致机场停运


这篇文章根据网络信息,记录了日本全日空航空公司(ANA)的国内航班系统3月22日由于发生ORA-29740错误,Oracle节点被踢出集群,若干数据库实例宕掉。导致乘客无法办理登机手续、订票系统也瘫痪的事故。本文主要信息来自网络,仅供参考,但是这个案例突出了数据高可用的迫切与重要


这类事件并不是头一次,今年2月24日,ANA国内航班系统就曾经发生故障,但30分种后修复,导致一部分航班晚点起飞。在2007年5月27日和2008年9月14日,也出现超过400架航班晚点或停航的故障。并且由于ANA的系统故障持续超过5个小时,在国内重要企业都应该算得上是重大事故,因此得到了广泛关注。


同时,ANA的航空系统是使用RAC集群,虽然是是久经考验的高可用架构,但

其单点数据存储和集中式架构在极端情况下仍然可能遭遇单点故障,所以构建可切换的灾备系统或者降级支持系统,对于核心企业业务架构来说是必不可少的。


在当前的企业级架构中,通过双活、灾备、读写分离等解决方案都可以作为数据库高可用的有益补充。


2、知己知彼-关于Oracle安全比特币勒索问题揭秘和防范


本文针对11月数据库遭遇的比特币攻击事件,进行了及时分析和故障排查处理方案的提供。

经分析,该类故障主要原因是某些用户下载了来源不明的数据库管理工具,导致数据库被感染。我们强烈推荐大家提高版权意识,购买正版软件,远离风险,从规范做起。


针对此类问题,云和恩墨专家及时作出响应,更新Bethune版本,提供比特币事件的有效监测和防范工具!


这类事件又让我们想起2015年的XcodeGhost入侵苹果iOS事件和202年中文版putty等SSH远程管理工具自动窃取用户名与口令的恶意攻击事件。这类事件一旦发生,带给企业的损失是不可估量的。


那么如何有效防范,加强数据安全保护措施呢?

老盖曾经在《数据安全警示录》一书中将数据的安全氛围5个维度,分别如下所示:


在这五大安全方向中,可能出现两种性质的安全问题,第一,由于内部管理不善而导致的数据安全问题;第二,由于外部恶意攻击入侵所带来的安全安问题。前者我们可以进行一定的控制和防范,但后者可能具有更多的突发性和偶然性。但我们要强调一点的是,无论是内部安全还是外部安全,对于数据的影响同样重要。因此,请大家参考数据库安全的16条军规保护好系统的心脑血管!


3、警示录:那个删除整个网站的小伙应该知道rm是危险的


本文针对四月份网上很火的一个帖子【有个哥们很忧桑:弄错一个命令,他把整个公司删没了...】,原文是一个小伙发了一个帖子,说他执行的一条命令出了问题,原本需要传入参数的rm -rf {foo}/{bar} ,因为Bug没有参数传入,Ansible自动推送所有操作在所有服务器,至少1535个客户托管的系统被全部删除。

估计这哥们当时的心情如下图所示:


这经历了大半年,也不知道缓过来了没有。其实小编并不关心这个哥们,重要的是,根据墨菲定律,有可能发生的事情就一定会发生,对于所有的运维者,一定要有强烈的安全意识,我们多次苦口婆心地强调“rm是危险的,rm是危险的,rm是危险的”,你咋就不听呢!


4、数据恢复:如何恢复Linux中意外删除的Oracle和MySQL数据库


这篇文章作者是这样开头的

没有删除过数据库的DBA职业生涯是不完整的,删除过数据库还能幸存的DBA一定是订阅了“Oracle”微信。

前一句话充分表现了作者是一名运维老司机,看看人家多淡定,删了库也这么有范,当然你不要学,估计你删了库之后别说DBA生涯,连人生都可能不完整了!后一句话,这是百分百的事实。别问我为什么,多读读我们的晨读文章,相信有一天你也能这么坦然地删库了!


本文主要是针对一起误删MySQL数据库的案例,对整个目录中的数据文件做了操作系统级别的删除,然而幸运的是这个数据库没有崩溃,仍然处于 open 状态的时候,文章 列出了详细的回复过程,最终经过专家的努力,保证了数据的零丢失


这么厉害的老司机,就知道你想多了解他,一般人我不会跟他说专家的博客地址是:http://www.dbform.com 的!


5、理论实践:循序渐进理解AWR细致入微分析性能报告


前面尽是各类惨不忍睹的事故,真是闹心!看到这篇就 放心了,还是有人在安静地做着重要的事情呢。

AWR是Oracle数据库中一个非常重要的诊断工具,通过度量而展现问题,每一个DBA都应当深入理解这其中的知识,这 篇文章重点对 AWR 报告中的 DB Time、DBCPU、IO 等数据进行了说明,可帮助读者更加清楚的理解这些数据代表的含义,与数据库的性能表现有何关系。同时通过两个简短的例子,实践如何分析 AWR 报告。


AWR的重要性相信大家都是不否认的,但文尽于此,更多的分析AWR报告的技巧还需要DBA日积月累!2017,愿你在通往专家的路上走得更远!


6、出乎预料:开发人员是如何使用数据库的?


文章根据JetBrains公司的一份调查报告,分别从开发人员分布,开发语言选择,数据库类型选择,开发的核心关注点,数据库的功能等各方面进行了数据分析对比,最终得出了以下结论:

  1. 与关系数据库和SQL相关的工作不但没有减少,而且随着全球开发者社区的发展自然扩大;

  2. 开发人员不断编写SQL代码,浏览数据,运行查询,并且持续关注性能。很多业务逻辑仍然驻留在数据库中:存储过程和触发器继续被大量使用;

  3. 数据库软件并未停滞不前:令人印象深刻的PostgreSQL取得快速发展,成为竞争的主要参与者;NoSQL数据库肯定占据自己的位置,但并没有对关系型数据库产生重要影响;这让我们相信SQL仍将是处理数据的坚实可靠的工具;

  4. 在走向云的过程中,亚马逊目前是厂商之中的绝对领导者,尽管如此,云的未来仍有很长的路要走;参与大数据开发人员的数量甚至比我们期望看到更高。似乎越来越多的人停止谈论大数据,并开始行动 - 这是很好的;


嗯,作为运维者,还是要多了解了解开发的!


7、性能优化:调整 I/O 相关的等待


对Oracle数据库进行调整优化,基本上最终都可以归结到I/O调整上,因此,了解如何来优化Oracle数据库的I/O对于一个DBA来说就显得至关重要。这篇文章首先介绍了如何根据数据库的各类统计信息来评估性能,之后针对跟I/O相关的各类等待事件,详细分析了原因,并针对不同的等待事件给出了相应的调整措施。

这篇文章非常长,摘自老盖的博客。建议每个搞运维的弟兄都看5遍以上!(放心,善良的小编从来不坑人的呀)


另外,鉴于大家对性能优化的文章的关注度比较高,在2017年,我们也将会更合理的安排内容,分享有价值的内容给各位!也请参与文末的投票,告诉我你想看的话题哟~


8、风云再起:美国财富500强Oracle高居利润率IT公司第1位


虽然这些年江湖上去O减O的流言纷纷,但我们的老大哥Oracle公司却不会轻易低头的,根据美国财富500强企业排行榜,Oracle公司以利润率26%高居第六位,在500强企业中,甲骨文公司的排名是第77位。在这个『利润率排名』榜上,IT公司里Oracle位居第一,还在苹果之上。


相信Oracle这几年的压力是蛮大的,很多人可能都认为,Oracle能够在云时代的大潮下保持稳健仍然疏为不易。事实上,随着Oracle12.2云上的发布,以及官方文档中体现出来的Oracle在12.2做的一些创新性的改进,通过这些我们都看到,Oracle从没有被打败,面对大趋势,Oracle开启了全面向云迈进的旅程,在12.1发布后的四年,潜心致力于转向云的改进。今天,在12.2中,我们将会通过各种新功能看到Oracle12.2版本细腻中霸气侧漏,无论在大方向上还是细节的改进,都给用户带来强烈的震撼!关于Oracle的新特性,请查看Oracle12.2新特性掌上手册系列


第一卷 Availability

第二卷 In-Memory的增强

第三卷 Core Improvements

第四卷 Sharding

第五卷 RAC and Grid

第六卷 ADG的性能与诊断

第七卷 Big Data and Data Warehousing

第八卷 PDB的快速创建和移除


听说12.2就快要正式发布了,想必大家都跟我一样期待呢!


9、常与无常:SQL语句中常量的处理及性能差异解析


这篇文章源于一个很奇怪的现象,两个SQL语句的功能相同,执行结果相同,连执行计划也完全相同,但是两者的执行时间相差了将近一倍?


经杨长老分析,导致这个问题的原因是很多程序员在SQL时经常会遇到的常量处理问题。

当CBO发现表达式中存在常量或常量表达式时,优化器会在SQL执行之前将表达式的值计算出来,避免在表达式中进行多次计算。但是优化器无法将等号一边的常量移动到等号的另一边。这里所说的等号是泛指,还包括不等号、大于号和小于号等

但专家思考问题的角度就是不一样的,针对这个问题,后文详细描述了如何处理常量才可以使SQL语句运行得更快。杨老师通过详细的测试,给出了许多有价值的方案。

恩,这篇文章也值得多读读。


10、防不胜防:一个空格在数据库里可能引发的N重血案


对,就是这个词,防不胜防!

在Oracle DBA的职业生涯中,无数看似简单的一个疏忽就能够导致致命的故障和数据损失,一个空格看似很小,可是如果在脚本运行环境中,就绝对不容轻视。文中由于SQL语句中相差了一个空格,结果出现了如下的结果:


第二次就出现了这样的结果:


这个结果是不是很2 ?


这个语句和上面第二个语句只是相差了一个空格,结果是完全不同的。对于第二个语句而言,注释并没有对语句产生任何的影响;而对于第三个语句,实际上 Oracle 并没有把这个语句作为包含注释的语句看待,实际上 sqlplus 运行的是/,也就是将缓存中的语句再运行一次,而完全忽略了/之后的内容。


这是一个平时不容易遇到的问题哟,多看看吧!

防不胜防:一个空格在数据库里可能引发的N重血案


以上是当之无愧的排名前十的文章!另外还有以下几篇也收到广大朋友们的欢迎,来看看是不是你的菜呢?


盘点完了年度文章,接下来我们来找找幕后的英雄们!


年度最佳作者

崔华,网名 dbsnake

Oracle ACE Director,ACOUG 核心专家

相关文章:


黄玮(Fuyuncat)

资深Oracle DBA,个人网www.HelloDBA.com,致力于数据库底层技术的研究,其作品获得广大同行的高度评价.

相关文章:


何剑敏 

Oracle ACS华南区售后团队,首席技术工程师。多年从事第一线的数据库运维工作,有丰富项目经验、维护经验和调优经验,专注于数据库的整体运维。

相关文章:


张大朋(Lunar)Oracle 资深技术专家

Lunar 拥有超过十年的 ORACLE SUPPORT 从业经验,曾经服务于ORACLE ACS部门,现就职于 ORACLE Sales Consultant 部门,负责的产品主要是 Exadata,Golden Gate,Database 等。

相关文章:


韩锋

精通包括Oracle、MySQL、informix等多种关系型数据库,有丰富的数据库架构设计开发经验。就职于宜信。

相关文章:


陈焕生

Oracle Real-World Performance Group 成员,senior performance engineer,专注于 OLTP、OLAP 系统 在 Exadata 平台和 In-Memory 特性上的最佳实践。个人博客 http://dbsid.com 。

相关文章:


许春植(Luocs)

(阿里巴巴高级数据库管理员,7年以上数据库运维管理经验,擅长MySQL、Oracle及MongoDB数据库,目前主要研究并建设MongoDB一套完整的运维体系

相关文章:


更多精彩文章请关注Oracle微信进行浏览学习!


最后我们来做个小投票吧!告诉我你想看什么样的文章!

以上都没有你想看的?就喜欢你这么有个性的,请留言告诉我你想看什么!




如何加入"云和恩墨大讲堂"微信群

搜索 盖国强(Eygle) :eyygle,或者扫描下面二维码,备注:云和恩墨大讲堂,即可入群。每周与千人共享免费技术分享,与讲师在线讨论。


近期文章

性能优化之查询转换 - 子查询类

基于Oracle公有云的备份与恢复

苦海岸边,GR的基础知识

Oracle 12c Global Data Services

MySQL Group Replication 学习笔记

利用硬链接和truncate降低drop table对线上影响

以12c Identity类型示范自我探索式学习方法

从执行计划洞察ORACLE优化器的“小聪明”

Oracle安全比特币勒索问题揭秘和防范

文章转载自Oracle,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论