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

原创作品。出自 “深蓝的blog” 博客。欢迎转载，转载时请务必注明出处，否则追究版权法律责任。

深蓝的blog：http://blog.csdn.net/huangyanlong/article/details/39718485

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

蓝的成长记——追逐DBA（6）： 做事与做人：小技术，大为人

**************************************************简单介绍********************************************************************

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

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

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

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

        做技术，学会仰望星空后。回到现实中依旧要脚踏实地，简单的事情未必会做的好。

                                                                                                                                    ——深蓝

        人们往往都喜欢把“天赋不足”当成“努力不足”的借口，水平不高的时候真的不能乱用“天赋”这个词。

                                                                                                                                    ——深蓝

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

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

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

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

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

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

        整理差旅间的点滴记录，小技术上的积累。非常多时候在积累的过程中并没感觉到技术上质的变化，但能让人感觉更踏实，也许这正是成长的感觉。做技术须要秉持着实实在在、仔细入微的严谨态度，有时区别就在于习惯和心态。

“懂”与“不懂”还真不能“装”，參数性能不会撒谎。理论与实践相辅相成才干让人对技术有更一步的理解。

2014年8月6日威海

（1）、现场业务应用。理解力超越文档十倍速

        继接上回顺利的导出、导入完毕了。平台级别的改造能够暂告段落了。短暂的结束，却发现要梳理的东西好多、好多。

        纸上谈兵终觉浅，实实在在的应用环境才是有助成长的最好平台。

对于业务层面的理解，真不是把文档熟读几遍就能理解的正确的。仅仅有当你与客户面对面交流时。你才会发现，真正的需求在哪里，应该注意的功能项是什么。仅仅有有用性强的业务功能才是体现价值，值得透析到技术层面。想方设法去做优化的努力方向。

认为就像是oracle“索引”一样，并不一定都须要建，要依据实际的业务需求。在oracle优化方面没有绝对性可言。一切都要从平衡性、有用性去出发。

（2）、websphere基本调优，四方面要记牢

1、连接池的连接数设置

2、java虚拟机的堆大小设置（即内存的分配）

3、应用现场的port号设置（这个须要依据实际客户要求进行更改）

4、启动servlet快速缓存

（3）、结合业务的导出表

         exp、imp导出导入工具，并不复杂，却须要业务知识的有力支撑。为何这么说呢，由于对于大表的确认上，要想办法将故障点系数尽可能减少。也意味着数据须要分割成模块化。如蓝的工作中接触的表，存在保存图片信息类的大表。因此这类表比較大，假设全然导出这张表，时间必定会非常长，同一时候显而易见的一个问题就是。时间越长，发生问题的可能性就越大。怎样将故障率减少呢？简单点想问题就好。把大表的数据分开来导出能够尽可能的减少故障率。于是採取一种以时间段而分开来完毕导出数据的方法是我们能够预见的设想。化整为零。将全表导出故障率降到最低。给出点提示，诸如这种写法：

--导出2010年1月1日之前的数据（2010.1.1之前）
>exp user/password@sid buffer=128000 feedback=10000 filesize=15G file_format=D:\信息大表20100101_%s.dmp TABLES=‘P表‘ query=\"where create_datetime<=to_date(‘20100101‘,‘yyyymmdd‘)\" log=D:\bak\信息大表20100101.log 

--导出2010年1月1日到2011年1月1日的数据（2010.1.1-2011.1.1）
>exp user/password@sid buffer=128000 feedback=10000 filesize=15G file_format=D:\信息大表2010010120110101_%s.dmp TABLES=‘P表‘ query=\"where create_datetime>=to_date(‘20100101‘,‘yyyymmdd‘) and create_datetime<=to_date(‘20110101‘,‘yymmdd‘)\" log=D:\bak\信息大表2010010120110101.log

--导出2011年1月1日到2012年1月1日的数据（2011.1.1-2012.1.1）
>exp user/password@sid buffer=128000 feedback=10000 filesize=15G file_format=D:\信息大表2011010120120101_%s.dmp TABLES=‘P表‘ query=\"where create_datetime>=to_date(‘20110101‘,‘yyyymmdd‘) and create_datetime<=to_date(‘20120101‘,‘yymmdd‘)\" log=D:\bak\信息大表2011010120120101.log

--导出2012年1月1日到2013年1月1日的数据（2012.1.1-2013.1.1）
>exp user/password@sid buffer=128000 feedback=10000 filesize=15G file_format=D:\信息大表2012010120130101_%s.dmp TABLES=‘P表‘ query=\"where create_datetime>=to_date(‘20120101‘,‘yyyymmdd‘) and create_datetime<=to_date(‘20130101‘,‘yymmdd‘)\" log=D:\bak\信息大表2012010120130101.log

--导出2013年1月1日到2014年1月1日的数据（2013.1.1-2014.1.1）
>exp user/password@sid buffer=128000 feedback=10000 filesize=15G file_format=D:\信息大表2013010120140101_%s.dmp TABLES=‘P表‘ query=\"where create_datetime>=to_date(‘20130101‘,‘yyyymmdd‘) and create_datetime<=to_date(‘20140101‘,‘yymmdd‘)\" log=D:\bak\信息大表2013010120140101.log

--导出2014年1月1日之后的数据（2014.1.1之后）
>exp user/password@sid buffer=128000 feedback=10000 filesize=15G file_format=D:\信息大表20140101_%s.dmp TABLES=‘P表‘ query=\"where create_datetime>=to_date(‘20140101‘,‘yyyymmdd‘)\" log=D:\bak\信息大表20140101.log

        至此，不知道聪明的你看懂没有，以上的思路就是将大的表按时间拆分成不同的部分。来减少导出时的故障率。

当然这个还须要依据实际情况作出灵活调整。

（4）、系统级别分析工具——top

top工具，系统级别的监控工具。非常easy。并且非常有用。

下面用图例方式简单说明：

1. top

如图例中简单列举了几点说明，例如以下：

        这当中想着重说一下我对“load average”的理解，这是系统平均负载的參考值。在专业的UNIX文档中你会发现把这个值得来由做了深入的分析。让人会感觉其相当复杂，但在实际应用中，我觉得没这个必要。与其把这个用数学公式演算而来的性能值弄得明确。倒不如知道其作用而有意义的多。这3个数据分别代表“现在”、“5分钟前”、“10分钟前”，平均有多少个进程由于CPU来不及处理而进入等待状态的一种定量分析。官方參考标准为“<1”时表示系统大部分都是空暇状态；“1-2”之间表示系统正在性能同意范围之内，较为理想的执行着；“2-3”表示系统处于轻度负载状态了；“>10”时说明系统严重负载，有可能性能已经不堪重负了。但这里要特别说明。在非常多技术书籍中会存在实际系统过载标准不同的情况，这都是正常的。所以这个标准都是要结合不同的系统相对而言的。而在业内有一个不言的标准，就是会觉得这个“平均负载值”不应该大于系统处理器数目的2倍。这里大家要引起注意。

而在实际工作中，你会发现有时候系统过载并不一定是系统出了问题，很多其它是出在应用程序上。因此，在下定结论之前须要分析系统上应用的执行状况。

原本这是属于系统管理员的工作。但现在的DBA经常要在系统管理员介入之前提前做出预判。

由于非常多小企业不存在系统管理员一职，有的即使存在，与其说是系统管理员不如说是界面操作员。根本不会考虑到这些东西，所以对于当今的DBA而言，知识面的纵深性要求也越来越高了。

2. Tasks、Cpu（s）

3. Mem、Swap

4.命令交互区、进程列表区

（5）、cpu核心、线程数

查看CPU：# cat /proc/cpuinfo

说明：一般来讲。多核的CPU，或者支持超线程的CPU，或者物理上有多个CPU，就会显示出相应条数数目的信息。

比如双核的CPU就会显示2条CPU信息。双核超线程的CPU就会显示出4条CPU信息（尽管条数多了。可是基本信息都一样）。例如以下为双核1颗CPU显示出一条CPU信息，是i系列双核cpu，应该是四线程cpu，intel的i系列cpu双核cpu能够有多线程（即四线程）。

图例：

更精炼的显示查询方式：

# cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq –c

图例：

由下面信息可知逻辑有1个cpu，i系列，双核。频率为2.6GHz。

修正：

修正结束

 

（6）、内存

# cat /proc/meminfo

2014年8月7日威海

（1）、报告

        在实际的工作中，经常会验证着“二八”现象。用20%的时间来处理问题。用80%的时间来整理文档。

当中这80%的内容里包括了前期的排查错误、排错过程的实际操作、解决这个问题后的总结、兴许方案的建议等等一系列。当你想在DBA这行里生存下去。你就会意识到“文档意识”的重要性。

（2）、汇报

        所见所感间，发现领导和下属有时如同一对恋人，有时熟络亲近。有时平淡处之。但不管如何，都要做到——保持联络！

有时候这个领导可能不是你的直属，有时候客户、同事、其他部门的同事可能一时间都成了你的领导。须要的是多沟通，多协调。当某些技术细节或方案变动被提出时，没有不论什么人会希望最后得知这个消息。

也就是说，当你正主导于某项技术性变动时，做事可能非常easy。但协调时须要花费的功夫和技巧。这个事须要用心去体会了。

（3）、兴许

        兴许的方案改进。传统性的中国思维，攻克了现状问题。其他问题先暂告段落。但隐患仍然是确确实实的存在在那。实际工作中经常发现，作为一个技术人员。不仅是仅仅面对领导的指派任务，这期间还要协调诸如销售等一系列的分工人员。在业界不成文的规则就是每当调优之时，诸如销售等业务层面的同事同一时候也会跟进，调优做的太完美，兴许平台执行没有问题。兴许维护合同就不好签销售指标就会下降。处理的不好，这就是技术人员的失职，客户会要你负责、领导也会要你负责。一个技术人员有时就像这样。会认为比較尴尬。究竟是商业策略至上还是技术水平至上呢？这仅仅能详细情况详细分析了，相信不管是哪行哪业都存在这样的现象，当中滋味看来仅仅有当事者方能体味的到了，这里纯当我戏谈了，O(∩_∩)O~

 

        做人、做事对得起良心，工作有时候须要多些责任，负责的事情就应该负责究竟。

做技术对得起自己付出的辛劳与汗水。对于年轻人的担当在业界有时候是个非常模糊的概念。

都已经忘却了以前的那种“小赢靠智，大胜靠德”的主流价值观。

 

说明：

下面是个人杂记，无关于技术。

2014年威海

遇到喜欢你的人，你会发现她总是有时间；

遇到不喜欢你的人，你会发现她总是没有时间。

行于路上。遇见时，留存下记忆中最美的美好；

离别时，不带走不论什么感伤。或许。不期而遇的某一天就是一个新的未来。

不经意发现。原来已从过往中走出；

面朝大海时，平静，释然。

埋藏了爱情，已不再泛起往事的波澜。

                                                                                                                                   ——深蓝

        人这一辈子。除了挣钱以外。总要找到一件能够称之为梦想的事情吧，不停的追逐，这样人活着才干认为有意义。

时代在发展。社会在进步，人与人之间的情感我认为是最值得珍惜的东西。

但往往可能都是单方面的情愿，正所谓。“人才易找。知己难求”的孤寂。

或许我的想法比較单纯、幼稚。不想在人的一生中让金钱地位成为左右自己成长、经历的瓶颈。想想当初决定从家出来看看世界的冲动，想必就是追求着在外人看来比較“理想主义”的生活态度。

或许我是无知吧，但我仍然确信的是人生中追求的正是那份超越物质的成就感，并不断的为之奋斗着。好在是要能找到一个能够用尽一生去为之奋斗的事情。即使老了，回头张望时，不会留有遗憾，会发现一路走来时，收获的是阅历，收获的是人生的超然，收获的是普通却不平庸的人生轨迹。

        时光转轮慢慢的却从未停歇的前进着，看着身边的人，有的走了。有的来了，隐约间暗含的各中滋味，时常让人想放空自己，来来去去，过往不停息的人群，这一刻才意识到光阴、生命就在这一幕一幕中流逝、改变。期盼着。也害怕着，期盼未来会更美好，却也害怕着有些说不出的滋味会再次涌入心头。

        人。非常多时候是自负与无知的，有时候莫名的低落也找不到合理的慰藉，却在一次一次莫名的哭泣中学会忘记、学会成长。

        对于財富的渴望，在人群中差点儿是一个共通的情节，而对照于“技术”，非常多时候会混沌掉“金钱”和“技术”之间那微妙的关系。

是为了財富增长技术水平，还是以追寻技术为乐趣。而財富都仅仅是技术的附属品而已呢？我时常会问自己一个问题。我为什么选择把oracle或者说是数据库作为我今生为之奋斗和努力的目标呢？我有时会认为这个能够为自己挣得足够的金钱、地位。却经常想着这一天能够快些到来，也不免会做非常多的白日大梦。记得有人说过，判别一个人成熟与否的标准，要看看这个人还会不会做些白日大梦。我想我就是经常在自己的梦境中。勾勒出一个又一个梦境出来。

一个不成熟的人。在外界的干扰下，时常会被影响。也许这也是一项不可抗拒的因素。

想要走出梦境。成为一个人，学着大气，学着胸怀广阔。须要具备什么素养吗？还是有什么更好的捷径呢？时常迷惑在人生的十字路口上，左右徘徊，总是企盼着一个指明一切的人出现。而往往时间是不会给你时间去等待这么个人出现的。而又经常在左顾右盼中平淡的度过了一个又一个夜，一天又一天的消耗着。时不时的告诫自己。时不时的拷问着自己。就在这这一切似乎没有得出明白答案的时候，似乎都在发生着些许的变化。

        就在全部人的对于財富注视的目光中。自己却忘记了，属于自己的那份快乐源泉哪里去了？工作、学习不是生活的附属品，会占领人一生中大部分的时间。

而人的精力是有限的，也就是说在有限的时间里我们要尽可能的完毕我们感兴趣的、能给我们带来发自心底里最快乐的那种元素。这就是梦想，就是目标。就是我们永远都不应放弃的执着。

        之前在思考的是我怎样要用接下来一年的时间，去弥补过去两年中浪费的时光呢？怎样把积累变的更加高速起来呢？时间有时候是敌人，有时候又是最好的朋友。每当我们被不同种类的人所歧视、藐视、谩骂的时候。事实上也不必沮丧，不必慌张，低下头，去为吹响号角前积攒很多其它些能量吧，时间会证明一切。

        如今突然明确，接下来的一年不是弥补。而是去开拓属于自己的这一年光景。很多其它的是来源于对知识的渴求中获得成长，来源于对技术收获的快乐，附带着少许的財富，毕竟还是要活着。好在能够得到喘息。或许未来就是这样。想好。没用，当放下了，才会懂得，一切都有着意义。

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

原创作品。出自 “深蓝的blog” 博客。欢迎转载，转载时请务必注明出处。否则追究版权法律责任。

深蓝的blog：http://blog.csdn.net/huangyanlong/article/details/39718485

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

 

 

*******************************************蓝的成长记系列_20150820*************************************

原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处（http://blog.csdn.net/huangyanlong）。

蓝的成长记——追逐DBA（1）：奔波于路上，挺进山东

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

蓝的成长记——追逐DBA（3）：古董上操作，数据导入导出成了问题

蓝的成长记——追逐DBA（4）：追忆少年情愁，再探oracle安装（Linux下10g、11g）

蓝的成长记——追逐DBA（5）：不谈技术谈业务。恼人的应用系统

蓝的成长记——追逐DBA（6）：做事与做人：小技术，大为人

蓝的成长记——追逐DBA（7）：基础命令。地基之石

蓝的成长记——追逐DBA（8）：重拾SP报告，回顾oracle的STATSPACK实验

蓝的成长记——追逐DBA（9）：国庆渐去，追逐DBA。新规划。新启程

蓝的成长记——追逐DBA（10）：飞刀防身，熟络而非专长：摆弄中间件Websphere

蓝的成长记——追逐DBA（11）：回家后的安逸。晕晕乎乎醒了过来

蓝的成长记——追逐DBA（12）：七天七收获的SQL

蓝的成长记——追逐DBA（13）：协调硬件厂商，六个故事：所见所感的“server、存储、交换机......”

蓝的成长记——追逐DBA（14）：难忘的“云”端，起步的hadoop部署

蓝的成长记——追逐DBA（15）：以为FTP非常“简单”。谁成想一波三折

蓝的成长记——追逐DBA（16）：DBA也喝酒，被捭阖了

蓝的成长记——追逐DBA（17）：是分享，还是消费，在后IOE时代学会成长

蓝的成长记——追逐DBA（18）：小机上WAS集群故障，由一次更换IP引起

蓝的成长记——追逐DBA（19）：路上的插曲：触碰“框架”与“软件系统”

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