蓝的成长记追逐DBA（2）：安装！安装！久违的记忆，引起我对

蓝的成长记追逐DBA（2）：安装！安装！久违的记忆，引起我对DBA的重新认知 ***************************************声明*************************************** 个人在oracle路上的成长记录，其中以蓝自喻，分享成长中的情感、眼界与技术的变化与成长。敏

蓝的成长记——追逐DBA（2）：安装！安装！久违的记忆，引起我对DBA的重新认知

***************************************声明***************************************

个人在oracle路上的成长记录，其中以蓝自喻，分享成长中的情感、眼界与技术的变化与成长。敏感信息均以英文形式代替，不会泄露任何企业机密，纯为技术分享。

创作灵感源于对自己的自省和记录。若能对刚刚起步的库友起到些许的帮助或共鸣，欣慰不已。

欢迎拍砖，如有关技术细节表述有错误之处，请您留言或邮件（hyldba@163.com）指明，不胜感激。

**********************************************************************************

谦逊的心，低调的生活，需要学习的地方还有太多、太多。

——深蓝

***************************************前言***************************************

这是一部个人记录的成长杂记，既然步入到oracle的这片蓝海，免不了一路的奔波与不断的考验。借由此杂记与库友们分享蓝的成长历程。

不知何时起对蓝有了一种说不出来的痴迷，痴迷其广博，痴迷其深邃，痴迷于近在咫尺却又遥不可及。

而又说不清从何时起，注视于oracle的红色耀眼，照亮出眼前的一道光，未知与迷惑在自己的脚下开始初露些许人生的充实与青春的回馈。

在追逐于DBA梦想的道路上步步前行。

***********************************************************************************

8月3日 威海

时光荏苒间，已经想不起正儿八经看着文档装数据库是什么时候了，感觉过了好久。尤其单实例的DB，即使做实验也习惯了直接导个镜像拿来就用。而回归到实际工作的时候，有些之前不再意的事情，就是摆在眼前的“饭票来源”。还记得之前看过一本书上说的，作为DBA，安装这档子事是很少碰见的，碰见的话也会交给什么第三方、什么经验人士去设计之类云云。。。当初我的看法也是如此，虽然是装过，但那都可以说的上是尘封的记忆了，但摆在眼前的情况是需要用最快的时间把这一切再想起来，这就是眼下的工作，刻不容缓。

纠结于报错，问题原因竟如此可笑。

问题出现在安装oracle软件的过程中，进度条到86%时报错了，如下图：

通过报错现象，我第一直觉的反应就是某个包没有打上。巧合的是就在昨天练习RAC时，出现了同样的问题，当时我也判断为包安装不全，但也没查到是哪个包没有装上。在单实例下也出现了这种情况。我开始感觉到似乎是我的思路跑偏了。

这才猛的想起，这个报错现象在今年年初的时候似乎在哪里看到过。突然想起来了，这很有可能是因为oracle与操作系统版本不匹配造成的。

因为这次使用的是CentOS5.6，为64位的操作系统，而之前习惯于用32位的数据库版本做实验。这才想到就在昨天RAC安装时记录的过程文档时查了一遍又一遍也没找到实质性的错误，没想到由单实例给了灵感，错误就是这么的简单。数据库与系统版本不匹配。于是经过些周折在OTN上download了一个64位的Linux版本数据库软件。而这次单实例报错，尝试点击continue，让其继续安装。之后又弹出几个类似报错，均点击continue让其继续。这次全当是实验一把在系统版本与数据库版本不匹配的情况下安装会出现什么情况（64位操作系统安装32位的oracle软件）。但让我没想到的是，接连的几个报错之后，点击继续后，软件竟然成功装上了，而且dbca建库、建监听完全正常。看来需要时间的考验了，兼容性可能会在不久之后由某个问题而暴漏。测试环境下测试着玩了。

下载完64位的oracle软件后，重新对其安装，果然不出所料，顺利的安装，完全没有报错。这次小不顺，问题就是出在细节上，这里引以为戒，切记，系统与数据库版本、位数要匹配。

让安装折腾了好一会儿，突然间想谈谈什么是DBA了，虽然眼下的安装只是DBA的一小小的要求之一（甚至可以说很不重要，但还是想说说）。

一提到这，就免不了对未来走向重新梳理，摆正态度。而且对于当今DBA的需求，又勾起了我的话唠，想多说些什么，说给自己，也说给刚刚选择数据库这行的人吧。

听来众多5、6年前8i、9i的时代里，DBA一词在外界看来还是个比较神秘，比较高大上的职位。那时候对于DBA的了解与认知远没有当今被众多的人们所了解更谈不上是熟知，可以说那个时候的DBA是个待遇与地位相当不错的职位。当初的ocp、ocm认证也远比今天含金量更高更能体现价值。好在oracle也发现了这一点，提升了11gocp的认证难度，我想甲骨文也不想看到ocp证书烂大街的尴尬局面。但凡事都有两面性，当初对DBA的要求虽没有像当今这样要求更加庞杂的知识储配，但那时的压力在我看来可以说是更大的。这是为什么呢？随着oracle的不断发展、版本不断的革新和升级，使得操作化更加智能、功能性更加强大、目标工具的选择性也更加多元化。举个例子就能明显的体会到，在当时，对于一个DBA来说，编写SHELL脚本是必须具备的能力，即使搭建rac都需要自己来编写脚本。看看现在，无论是网络还是书籍材料，资源都太多了。甚至于有些DBA已经习惯于“拿来主义”，找到差不多的脚本，稍作修改，就成为自己的劳动成果了。这可能也更加说明当今含金量降低的原因。但历史总是拿来明鉴的，我们还是更多的是要立足于当今，更多的看向未来。毕竟时代和科技需要不断的发展、进化和提升，正才是人类IT发展的趋势。这样人类文明才能进步。想想看，倘若有一天DBA全都失业了，科技智能将会是达到了什么的样的高度，我们抽离出去，是不是应该有更多的喜悦才对呢。

扯的远了，再把话题扯回来吧。看看在当今云时代被炒得沸沸扬扬的时代里，DBA应该怎么定位。对于漫天飞来的云数据、大数据概念，很多时候都有些无可奈何。我最早了解到这个概念的时候应该是在07、08年的时候吧，那时候还在上学，当时觉得这门技术是个高大上、含金量超高，是个非常牛x的行业，所以最后还是决定走硬件的专业道路，对数据库的行业不敢奢望。之后了解一些才发现，媒体的嘘头炒作下，更多的跟随着国外有关“云概念”理论性的发展，这之后，国内才开始效仿甚至于愈演愈热的理论炒作、抄袭浪潮。转眼6、7年过去了，好像这个“大数据”终于有些起步的表现了。资源重新分配，虚拟化的快速发展同时也很大程度上推动了大数据的进步，Vmware公司成为2013年全球前十大软件公司，就可见一斑，再来看hadoop、nosql数据库被捧得极热。甲骨文当然也不甘人后，在收购SUN之后就可以遇见拉里的野心有多大，12C的问世，可以说的上是正式开始迈进大数据的第一步。众多诸强开始秣兵厉马，蓄势待发的要强占“云端”这块看似“轻飘飘”却“肥的流油”的“未来”。而对于DBA呢，在这个时代里，想引用梁敬斌的一句话：“这是最坏的时代，同时也是最好的时代”。面对各行、各业对于数据的重新认识和应用，数据库相关人员的角色或是更加明确或是更加模糊。

分开几方面来表述的话：

1、作为数据库开发，在未来市场需求将会爆发式增长，侧重于逻辑与业务，加班加点，作为开发人员应该是最习以为常的事了；

2、作为管理型DBA，抗压能力将是必备的能力，作为DBA应了那句话，“养兵千日用兵一时”，风平浪静下体现不出真正的价值，而往往是在重大灾难面前，这就是DBA需要挺身而出的时候，为企业扭转乾坤由死转生。这也是为什么，在很多公司里，老板把DBA当成超人的原因。在它们看来，DBA是个什么都会做的神，出了问题第一个想到就是DBA。而实际中，往往因素要比预见的更加复杂；

3、作为优化方向，正是在行业里谁都讲不清屡不清的一种情结。在我看来，判别一个DBA的标准正是要看优化的能力。一个不能做优化的DBA就称不上是DBA。同时还有一个比较尴尬的局面，就是智能化、自动化的优化软件大力开发，对于数据库的优化可能会在一段时间之后，由软件所取代，Oracle的EM这是这种趋势（注释：图形化占用资源大，往往老的应用系统都不允许使用图形化界面，这也在一定程度上限定了EM的普及），人们只需要学会使用工具软件就好，而底层产生的原因或许即使你不知道也没关系。但这只是设想，都期望可以这样，但同时同不愿看到这一幕。换个角度去看，如果真到了那一天，如果我们可以找到其它的增长点或新的技术领域，就可以消除所有DBA的担忧，毕竟还要混口饭吃。

4、数据库设计，这是个要求最高的水平，是要建立在之前几个水平的情况下发展而来的。但同时这要深刻的理解业务需求、数据库原理、模型的建立、设计出所需要的索引、对象。这是以后技术水平发展的根基。

这些要是引开说还有太多了，在此对于初学者我推荐一本书，可以读读看：梁敬斌的《收获，不止oracle》，这是我当时购买的第一本有关oracle的书籍，从中，无论是知识还是思维方式，收益匪浅。

话题再转吧，谈谈我对于当今DBA技能的认识，我喜欢用两个词来形容：

1、DNS：Database+Network+Storage；（注意这里的DNS可不是域名解析系统噢，亲！）

2、SPSM：SQL+PL/SQL+System+Middleware；（同样，这里SPSM不是物理中的概念）

不言自明了，当今对于DBA的技能要求越来越多源化，如果你想成为一个管理型DBA就需要掌握数据库的原理、知识其中涵盖有备份、恢复、调优、RAC、DG、GG等等诸多方面。而且对于网络和存储知识也需要掌握一些，这在前期实施搭建、后期排除故障都是很有助益的。

另外，我刚刚进到行业内时间不长，以我的视角看来，对于DBA而言，熟练掌握SQL是基本，这个在工作中不断的使用的话，便会加强记忆，或者有意的背些指令我觉得也是很需要的。再就是PL/SQL的编写，很多人认为作为DBA无需掌握脚本的编写能力，我对此并不赞同，虽然目前个人能力很有限，对于脚本编写很吃力，毕竟并不是写代码出身，对于很多逻辑的理解或是调用什么的还觉得很吃力。但我坚持认为这项能力将对一个DBA来说有着莫大的助益，当掌握了PL/SQL以后对存储过程、包、函数理解和使用会完全不同，再者在调优的工作中，SQL调优会占据相当大的比重，有甚者有些调优项目针对的就只有SQL语句。还有管理数据库时，对某些功能的监控也是我们工作中需要做的，这里就要用到写SHELL能力了，如果所在的公司想要最大化的削减成本来达到监控的效果，由DBA来编写一些监控脚本是很寻常的事。即使使用一些监控软件，如果你懂PL/SQL，你也会发现理解程度是不一样的。所以，我说这么多，就是想强调，拥有PL/SQL的能力，会为职业生涯和稳定度带来不小的助力。有这么一个观点：“在很多方面，要求DBA会修改脚本来完成自己的目的就行”，这个确实是被认可的。然而这种观点一定程度上误导了很多人，以为作为DBA只需会修改脚本就OK了，这往往是一个误区，见到过很多DBA最初都是自己写些简单的脚本，基础扎实后才在业务层面修改脚本为己所有，最后达到游刃有余的地步。而那些从最初就只秉持着修改就好观点的人，到最后很少有能修改脚本为己所用的，这里分享出来，供大家参考吧。

再来说说系统吧，当今数据库主流的运行平台都是在Linux或Unix下的，所以说想要玩好DB对于系统的操作就需要不断练习，熟练是会给解决DB问题带来很多的便利。我这里接触过几个操作系统，其中就有如Solaris、红帽Linux、CentOS、Suse、Ubuntu还有小机的AIX、HPUNIX等等，最初接触的时候感觉很费力，时间久了，常用的命令就是那些而且不同的unix和linux系统之间都有着很多相近的地方，虽说目前对于指令的掌握很多还需要查查手册才能确定，但对其理解看来，操作系统就如同我们平时玩游戏的windows平台一样，要慢慢的学着熟悉它、掌握它、精通它。而且不只是对于系统，协调在应用层面的中间件也是需要掌握的技能之一，关于中间件本人知知甚少，还在慢慢学习中，此处就不过多发表个人意见了。

欢迎访问：深蓝的Blog：http://blog.csdn.net/huangyanlong

*****************************************************************************************