***********************************************声明***********************************************************************
原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处，否则追究版权法律责任。
深蓝的blog：http://blog.csdn.net/huangyanlong/article/details/39718485
****************************************************************************************************************************
蓝的成长记——追逐DBA（6）： 做事与做人：小技术，大为人
**************************************************简介********************************************************************
个人在oracle路上的成长记录，其中以蓝自喻，分享成长中的情感、眼界与技术的变化与成长。敏感信息均以英文形式代替，不会泄露任何企业机密，纯为技术分享。
创作灵感源于对自己的自省和记录。若能对刚刚起步的库友起到些许的帮助或共鸣，欣慰不已。
欢迎拍砖，如有关技术细节表述有错误之处，请您留言或邮件（hyldba@163.com）指明，不胜感激。
***************************************************************************************************************************
做技术，学会仰望星空后，回到现实中依然要脚踏实地，简单的事情未必会做的好。
——深蓝
人们往往都喜欢把“天赋不足”当成“努力不足”的借口，水平不高的时候真的不能乱用“天赋”这个词。
——深蓝
**************************************************前言********************************************************************
这是一部个人记录的成长杂记，既然步入到oracle的这片蓝海，免不了一路的奔波与不断的考验。借由此杂记与库友们分享蓝的成长历程。
不知何时起对蓝有了一种说不出来的痴迷，痴迷其广博，痴迷其深邃，痴迷于近在咫尺却又遥不可及。
而又说不清从何时起，注视于oracle的红色耀眼，照亮出眼前的一道光，未知与迷惑在自己的脚下开始初露些许人生的充实与青春的回馈。
在追逐于DBA梦想的道路上步步前行。
***************************************************************************************************************************
整理差旅间的点滴记录，小技术上的积累，很多时候在积累的过程中并没感觉到技术上质的变化，但能让人感觉更踏实，或许这正是成长的感觉。做技术需要秉持着实实在在、细致入微的严谨态度，有时差别就在于习惯和心态。“懂”与“不懂”还真不能“装”，参数性能不会撒谎，理论与实践相辅相成才能让人对技术有更一步的理解。
继接上回顺利的导出、导入完成了，平台级别的改造可以暂告段落了。短暂的结束，却发现要梳理的东西好多、好多。
纸上谈兵终觉浅，实实在在的应用环境才是有助成长的最好平台。对于业务层面的理解，真不是把文档熟读几遍就能理解的正确的。只有当你与客户面对面交流时，你才会发现，真正的需求在哪里，应该注意的功能项是什么。只有实用性强的业务功能才是体现价值，值得透析到技术层面，想方设法去做优化的努力方向。觉得就像是oracle“索引”一样，并不一定都需要建，要根据实际的业务需求，在oracle优化方面没有绝对性可言。一切都要从平衡性、实用性去出发。
1、连接池的连接数设置
2、java虚拟机的堆大小设置（即内存的分配）
3、应用现场的端口号设置（这个需要根据实际客户要求进行更改）
4、启动servlet高速缓存
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
至此，不知道聪明的你看懂没有，以上的思路就是将大的表按时间拆分成不同的部分，来降低导出时的故障率。当然这个还需要根据实际情况作出灵活调整。
top工具，系统级别的监控工具。很简单，而且很实用。
以下用图例方式简单说明：
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.命令交互区、进程列表区
查看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。
# cat /proc/meminfo
在实际的工作中，常常会验证着“二八”现象，用20%的时间来处理问题，用80%的时间来整理文档。其中这80%的内容里包含了前期的排查错误、排错过程的实际操作、解决问题后的总结、后续方案的建议等等一系列。当你想在DBA这行里生存下去，你就会意识到“文档意识”的重要性。
所见所感间，发现领导和下属有时如同一对恋人，有时熟络亲近，有时平淡处之，但无论怎样，都要做到——保持联络！有时候这个领导可能不是你的直属，有时候客户、同事、其它部门的同事可能一时间都成了你的领导。需要的是多沟通，多协调。当某些技术细节或方案变动被提出时，没有任何人会希望最后得知这个消息。也就是说，当你正主导于某项技术性变动时，做事可能很简单，但协调时需要花费的功夫和技巧，这个事需要用心去体会了。
后续的方案改进。传统性的中国思维，解决了现状问题，其它问题先暂告段落，但隐患仍然是确确实实的存在在那。实际工作中常常发现，作为一个技术人员，不仅是只面对领导的指派任务，这期间还要协调诸如销售等一系列的分工人员。在业界不成文的规则就是每当调优之时，诸如销售等业务层面的同事同时也会跟进，调优做的太完美，后续平台运行没有问题，后续维护合同就不好签销售指标就会下降。处理的不好，这就是技术人员的失职，客户会要你负责、领导也会要你负责。一个技术人员有时就像这样，会觉得比较尴尬。到底是商业策略至上还是技术水平至上呢？这只能具体情况具体分析了，相信无论是哪行哪业都存在这种现象，其中滋味看来只有当事者方能体味的到了，这里纯当我戏谈了，O(∩_∩)O~
做人、做事对得起良心，工作有时候需要多些责任，负责的事情就应该负责到底。做技术对得起自己付出的辛劳与汗水。对于年轻人的担当在业界有时候是个很模糊的概念。都已经忘却了曾经的那种“小赢靠智，大胜靠德”的主流价值观。
说明：
以下是个人杂记，无关于技术。
遇到喜欢你的人，你会发现她总是有时间；
遇到不喜欢你的人，你会发现她总是没有时间。
行于路上，遇见时，留存下记忆中最美的美好；
离别时，不带走任何感伤，也许，不期而遇的某一天就是一个新的未来。
不经意发现，原来已从过往中走出；
面朝大海时，平静，释然；
埋藏了爱情，已不再泛起往事的波澜。
——深蓝
人这一辈子，除了挣钱以外，总要找到一件可以称之为梦想的事情吧，不停的追逐，这样人活着才能觉得有意义。时代在发展，社会在进步，人与人之间的情感我觉得是最值得珍惜的东西。但往往可能都是单方面的情愿，正所谓，“人才易找，知己难求”的孤寂。也许我的想法比较单纯、幼稚，不想在人的一生中让金钱地位成为左右自己成长、经历的瓶颈。想想当初决定从家出来看看世界的冲动，想必就是追求着在外人看来比较“理想主义”的生活态度。也许我是无知吧，但我仍然确信的是人生中追求的正是那份超越物质的成就感，并不断的为之奋斗着。好在是要能找到一个可以用尽一生去为之奋斗的事情。即使老了，回头张望时，不会留有遗憾，会发现一路走来时，收获的是阅历，收获的是人生的超然，收获的是普通却不平凡的人生轨迹。
时光转轮慢慢的却从未停歇的前进着，看着身边的人，有的走了，有的来了，隐约间暗含的各中滋味，时常让人想放空自己，来来去去，过往不停息的人群，这一刻才意识到光阴、生命就在这一幕一幕中流逝、改变。期盼着，也害怕着，期盼未来会更美好，却也害怕着有些说不出的滋味会再次涌入心头。
人，很多时候是自负与无知的，有时候莫名的低落也找不到合理的慰藉，却在一次一次莫名的哭泣中学会忘记、学会成长。
对于财富的渴望，在人群中几乎是一个共通的情节，而对比于“技术”，很多时候会混沌掉“金钱”和“技术”之间那微妙的关系。是为了财富增长技术水平，还是以追寻技术为乐趣，而财富都只是技术的附属品而已呢？我时常会问自己一个问题，我为什么选择把oracle或者说是数据库作为我今生为之奋斗和努力的目标呢？我有时会觉得这个可以为自己挣得足够的金钱、地位，却常常想着这一天可以快些到来，也不免会做很多的白日大梦。记得有人说过，判别一个人成熟与否的标准，要看看这个人还会不会做些白日大梦。我想我就是常常在自己的梦境中，勾勒出一个又一个梦境出来。一个不成熟的人，在外界的干扰下，时常会被影响，或许这也是一项不可抗拒的因素。想要走出梦境，成为一个人，学着大气，学着胸怀广阔，需要具备什么素质吗？还是有什么更好的捷径呢？时常迷惑在人生的十字路口上，左右徘徊，总是企盼着一个指明一切的人出现，而往往时间是不会给你时间去等待这么个人出现的。而又常常在左顾右盼中平淡的度过了一个又一个夜，一天又一天的消耗着。时不时的告诫自己，时不时的拷问着自己。就在这这一切似乎没有得出明确答案的时候，似乎都在发生着些许的变化。
就在所有人的对于财富注视的目光中，自己却忘记了，属于自己的那份快乐源泉哪里去了？工作、学习不是生活的附属品，会占据人一生中大部分的时间。而人的精力是有限的，也就是说在有限的时间里我们要尽可能的完成我们感兴趣的、能给我们带来发自心底里最快乐的那种元素。这就是梦想，就是目标，就是我们永远都不应放弃的执着。
之前在思考的是我如何要用接下来一年的时间，去弥补过去两年中浪费的时光呢？如何把积累变的更加快速起来呢？时间有时候是敌人，有时候又是最好的朋友。每当我们被不同种类的人所鄙视、轻视、谩骂的时候，其实也不必沮丧，不必慌张，低下头，去为吹响号角前积攒更多些能量吧，时间会证明一切。
现在突然明白，接下来的一年不是弥补，而是去开拓属于自己的这一年光景。更多的是来源于对知识的渴求中获得成长，来源于对技术收获的快乐，附带着少许的财富，毕竟还是要活着。好在可以得到喘息，也许未来就是这样，想好，没用，当放下了，才会懂得，一切都有着意义。
***********************************************声明***********************************************************************
原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处，否则追究版权法律责任。
深蓝的blog：http://blog.csdn.net/huangyanlong/article/details/39718485
****************************************************************************************************************************
系列链接：
蓝的成长记——追逐DBA（2）：安装！安装！久违的记忆，引起我对DBA的重新认知
蓝的成长记——追逐DBA（3）：古董上操作，数据导入导出成了问题
蓝的成长记——追逐DBA（4）：追忆少年情愁，再探oracle安装（Linux下10g、11g）
蓝的成长记——追逐DBA（5）：不谈技术谈业务，恼人的应用系统
蓝的成长记——追逐DBA（6）： 做事与做人：小技术，大为人
原文地址：http://blog.csdn.net/huangyanlong/article/details/39718485
