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

蓝的成长记追逐DBA（3）：古董上操作，数据导入导出成了问题 ***************************************声明*************************************** 个人在oracle路上的成长记录，其中以蓝自喻，分享成长中的情感、眼界与技术的变化与成长。敏感信息均以英

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

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

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

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

欢迎拍砖，如有关技术细节表述有错误之处，请您留言或邮件（[e-mail]）指明，不胜感激。

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

生命的意义不是你现在拥有了什么，而是你选择追求什么，

有了目标追逐的时候，人生会变得充满意义。

——深蓝

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

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

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

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

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

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

2014年8月4日 威海

今天联系客户，来到数据中心A部，机房环境相当不错。只可惜当看到实际的机器后，有点失望，没有其它的想法，只是对其性能比较失望。09年的机器，5年过去了，按理说是有些年头，但也不算太久。之前了解的一台服务器工作20年无宕机依然坚挺。而眼前的这几台，只能说是IT界发展变化太快，不是不够用了，是跟不上大时代的步伐了。而这次服务器性能的下降可以很简单解释：在搭建初期由于试行阶段，这个系统每天的业务量很小，所以相当长的一段时间内都没暴漏出问题。而随着系统的大力摊开于这个威海各小分支部门后，隐患还是显现出来。据了解服务器近一年来小问题层出不穷，而现场的操作员最常用的方法是：重启服务器！所以想不出什么名次代替了，以用“古董”一词表达此刻的心情。接下来，我们看看这几台服务器的真面目：

（机1）：数据库服务器

Dell的PowerEdge2950/E53201.86GHz 四线程/3.99G内存/136G*2/Windows2003/Oracle10g

（机2）：应用服务器

Dell的PowerEdge2950/E53201.86GHz 八线程/7.99G内存/136G*2/ Windows2003

（机3）：ftp服务器

Dell的PowerEdge2950/E53201.86GHz 四线程/3.99G内存/136G*2/ Windows2003

（机4）：存储

Dell的MD3000/1T（300G*4）/RAID1

可笑的配置，相比较最高性能的服务器用给了应用服务器，数据库服务器流落和一台ftp服务器相同的配置。感觉有些奇怪的是在两台4G内存的机器上贴着没有撕掉的“Cluster”标识，这好似一套集群环境。再确认一下，眼前的这两台机器确实不是集群环境。跟负责日常管控的工程师了解之后得到了答案。这是被撤下来的方案，之前某个第三方服务商有人来过，撘过RAC，配置过存储。而后来不成功给撤掉了。虽得到了解答，但看见眼前存储上红色告警灯在不停的闪烁，还是有些闹不清之前发生了什么，真心无语了。

推测出了眼前的这套方案：之前的第三方服务人员可能是计划两台机器搭建RAC集群（机1+机3），使用一台性能稍高的作为应用服务器，存储使用阵列存储，而且处于安全考虑，他做了RAID1。但实际中由于集群搭建的失败，调整了方案，变成了单实例的数据库，数据文件存储在存储中，而应用服务器没有变动，这样便有一台服务器被闲置了，最后的选择是用其搭建了一台ftp服务器，用于文件的共享。按此思路下来，眼前的场景形成了。

不妨想一想，如果是我：Windows下的话，数据库集群就不搭了，将性能较好的那台服务器作为数据库服务器（机1），然后将余下的两台服务器搭建一个应用集群环境（机1+机3），最后当然还是使用存储，组建个RAID 0 1，来改善备份数据时的性能瓶颈。想归想，做归做，还要落地到客户当今的需求上。

了解了一下，改造平台的原因在于系统很不稳定，性能体现在访问人数变多时（达到50人时性能差体现的比较明显），便会出现应用响应延迟严重的现象。

各位领导到场后，讨论会议正式开始。经过一番讨论后，客户将稳定性、安全性作为了最重要的考虑，改造方案可由我方自行决定，对于操作员难度问题可暂不考虑。在这里，我可以预见在服务器宕机的这一个月来说对于客户是度过了怎样的煎熬，只要是稳定，其它一切都可以。

此次我方提出两个解决方案：

方案一：数据库服务器平台由Windows改造为Linux，应用服务器依旧保留Windows平台以降低驻地操作人员的使用难度；

方案二：数据库服务器平台、应用服务器平台均改为Linux平台，以实现稳定性，对于操作难度，会提供指导文档给具体操作 员。

在备份方案上，我方提出两种解决建议：

建议1：使用计划任务，完成本地自动备份；

建议2：进行远程备份容灾，组件最后一道防线，并由我方北京工程师实施备份。

经过确认后，改造采取方案二，在备份策略上结合两点建议，实现数据备份容灾的两条防线。远程的我方作为最后一道数据安保防线。就此，转战于机房。

连续使用类似的查看指令，推测出数据的增产量：每年约30G，指令参考如：“

selectcount(1) from t where t.ziduan>=to_date('20090101','yyyymmdd') andt.ziduan

在进一步决定备份方案时，看到红色警示灯的存储，真心不太敢用。

尝试逻辑备份部分数据，存储读写速度相当之慢，判断存储必然存在问题。看了一下数据的增产量、原有的数据量，建议客户抛弃掉存储阵列，使用本地服务器。可以至少维持两年的数据增长。由于机器配置较目前属于较低端，建议日后升级硬件系统。客户也予以采纳，此次先解决系统不稳定事宜，升级方案已经在考虑筹备之中。得到了“懿召”后，心里便有些底了。采用方案：数据库服务器（机2）、应用服务器（机1）、ftp组件一个本地备份服务器（机3）。

现在摆在眼前的问题就是：将存储中的数据文件备份出来，因为在这个存疑的存储上干活的话真心心里不踏实。而且也得到了验证：最初想直接由存储中将数据dump出来。11:30开始导出，14:30回去查看发现导出了了15G的数据量，查看发现需要导出80G的数据量。也就意味着全部数据导出的话可能要消耗15多个小时，这简直太可怕了。80G的数据并不算大，用这么久，时间太长了，于是想使用其它的方式。想把数据文件在系统层面都拷贝到本地服务器上，再通过类似指令，如：“alter database rename file 'Z:/one.dbf' to 'D:/one.dbf';”用以重定向数据文件，在通过逻辑备份导出文件。这正是做了一次冷备，需要在关库的情况下来完成。

在将数据文件拷贝到服务器的过程中，同样是一个令人煎熬的过程。从16:00开始做冷备。

不知多了多久，截下如下图片：

回想似乎是到19:00左右，终于完成了，没有预期的快，但至少比直接由存储导踏实很多了。现在可以开始做导出的工作了。

看看时间，开始逻辑备份，关闭显示器，离开返回酒店，让导出的任务在夜间完成吧。现在能做的，就是休息，愿今晚，一切！~安好~！。

***************************************未完待续***************************************

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

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