11月15日上午接到boss电话，希望我当天就能赶到郑州，为用户解决TSM(Tivoli storage manager)性能与故障问题，此问题已经积压了2年多时间，项目也一直没有结项。说到这里给我的第一感觉就是这个问题会非常棘手，否则不会积压这么长时间都没人能够解决。同时我也初步了解到此系统采用的是VTL TS7650G虚拟带库，使用TSM备份工具将oracle11g RAC数据库备份到虚拟带库中，目前的备份时长是32小时，数据量为20TB，用户认为备份时间太长；另外从rman备份日志中发现了部分错误信息；所以用户急需我们我到现场处理此问题。
撂下电话我马上定了从沈阳到郑州的机票，又预定了5个房晚的希尔顿酒店无烟大床房。没来得及吃中午饭直接打车到桃仙机场，安检过后又直接到南航贵宾休息室吃午饭。时间刚刚好，吃过午饭就听到广播开始登机了。经常出差我就发现了一个现象，大部分坐飞机的人都喜欢把行李箱带上飞机，有的行李箱尺寸都明显超规格了，最后弄得其他人连背包都没地方放，怪不得人们早早就在登机口排长队。看到这种情况我就没啥客气的啦，直接走优先通道。经过2个多小时的飞行终于安全落地，一下飞机就感觉郑州比沈阳暖和多了。在等出租车的时候发现旁边一个小姑娘拿个本在记出租车号，在记完出租车号后再指定乘客去坐刚才记录了车号的出租车，她向乘客解释这样可以避免在出现事故或者纠纷后能够直接找到相关司机或者单位。
到达酒店后办理入住时我挑了一个15层最靠边的房间，我喜欢角落的房间因为比较安静。从楼上一眼望去，前面是曼哈顿广场，旁边是一个大公园，看起来环境还不错。第二天早上我来到行政酒廊吃早饭，刚一坐下就接到了集成商的电话，问我是否已到用户现场，我说一会就去。撂下电话我就心想，2年时间都干嘛去了，现在竟然开始着急了。不过我还是要说希尔顿酒店的早晚餐是我住过的五星级酒店当中最丰富的，还有很多种类的坚果，对于我们这些经常用脑的人来说，早晚饭我都会吃一点核桃，对身体有好处。
到达客户现场后，集成商召集项目经理和相关技术人员和我一起开了一个问题讨论会，会上我了解到客户的oracle RAC与tsm服务器都是使用的大型机LPAR，上面运行的zlinux，目前只有一个oracle客户端需要备份，系统架构不算复杂，但全都是采用的虚拟化技术。随后集成商的DBA马上抱怨说，RMAN备份脚本应该由我们原厂编写，还说以前的工程师给他们的备份脚本模板不会用。我心想这些不都是DBA的基本功和分内的工作吗，怎么会要求我们存储厂商来提供；但是我没有直接说出来，我只是和他们解释在以往的项目中我们只提供备份接口，不会针对每一种具体应用去为客户编写备份脚本，原因有二：
1.因为备份的客户端种类比较多，例如SAP、虚拟机、oracle、DB2、MSSQL；我们备份工程师不能精通所有的技术，更不能去编写具体的备份脚本，但是我们会提供接口，并指导客户如何使用这些接口；
2.每个客户的具体需求和备份策略都不尽相同，所以都是由客户技术人员根据实际需要去编写相应的脚本。
最后我又说这次来我的任务主要是解决两个问题：
1.分析目前TSM的备份性能是否还具有一定的调整空间；
2.分析备份过程中出现的错误，看是否能够给予解决。
根据以往的经验来看，性能问题与错误问题是相互依存的，通常系统负载过大，就可能会引起系统异常比如宕机；反过来系统异常也会引起性能问题，比如链路闪断就会影响系统的数据吞吐性能。会后客户分配给我一个IP地址，我登录到系统首先查看TSM server与VTL虚拟带库，没有发现配置问题与错误日志信息。由于客户采用的是LANFREE备份架构，备份数据将直接从oracle服务器备份到虚拟带库，中间并不需要TSM server来传输，所以tsm server不是关键。
在登录到oracle服务器后，我都习惯先检查操作系统层面状态，这是个好习惯，皮之不存毛将焉附，首先要保证操作系统层面是正常的，否则上面的应用肯定会有问题。在使用top命令后，我发现系统的CPU使用率一直都是100%；并且发现这个oracle服务器节点一共就2颗cpu。这2颗cpu就只能跑两个进程，因为大机的CPU架构与X86或者小型机的不同，每颗cpu上面只能运行一个进程，而没有什么多core的概念。同时从进程信息上看主要是oracle用户进程占满了CPU资源，不过IO负载和内存使用率并不高。用户没有专用的监控系统，所以无法确定这种CPU使用率100%的情况是短暂的还是持续的，所以我就将这个session窗口一直保留着，持续观察，同时并行的去看操作系统日志，在日志中发现了一些path告警信息，但目前还不确定这是不是问题的根本原因所在。
在持续观察系统性能的同时，我也并行的去分析rman备份输出日志，发现系统每次备份都会在不固定的一个小时之内报出相同的错误，但是rman备份channel都能够自动的进行failover，整个备份任务继续进行而没有中断，最后日志显示整个备份任务也是成功的。因此用户就怀疑备份过程中出现的问题可能会导致最终的备份存在问题。在检查tsm clinet备份客户端的时候，发现客户端使用了4个逻辑带库驱动器，TSM层面的配置也均正常。
经过一天的分析与观察，最终发现oracle服务器cpu使用率一直接近100%，基本全部被oracle客户端进程占用。但是这只是白天观察的结果，而TSM调用rman备份却在夜间进行，所以我又抽取了前几天晚间的awr报告，报告同样显示在夜间oracle服务器cpu使用率一直接近100%，主要是一些SQL将整个系统的CPU资源耗光了。
在第二天的阶段性通告会上，我主要针对性能问题向客户做了解答：整个系统只有2颗cpu，这两颗cpu只能同时运行两个进程，因为大机的cpu架构没有多核概念，同时cpu资源使用率一直保持100%，均由oracle用户进程占用，在rman备份期间也存在严重的资源抢占。TSM clinet、tsm server与VTL虚拟带库配置均没有问题，tsm server与VTL虚拟带库也不存在性能瓶颈。但是由于oracle服务器只有2颗cpu，即使为其分配4个虚拟驱动器，也只能用到其中的两个。所以就目前的系统环境来看，需要增加更多的cpu与优化oracle的sql来增加cpu可用资源供rman备份使用，进而可以提升整个系统的备份性能。同时我还说从最近的2次rman全备来看，每次用时都在18-20小时之间，相较之前所说的38小时性能提升很大。
用户表示目前系统硬件层面无法扩容，不能再增加cpu资源；oracle SQL语句开发商那边也难以进行优化。目前备份时长18-20小时也能接受，毕竟比以前的38小时缩短了一半。
但是客户需要解释为什么以前那次备份用了38个小时；我解释说，那次备份是在刚为系统变更LANFREE模式之后，系统从lanbase向lanfree转换需要一个趋于稳定的过程；或者当时系统非常繁忙，迟滞了整个备份进程。
另外针对目前发现的错误，暂时还不能确定具体原因，需要进一步分析；但是从日志上看这个错误是非致命性的，没有导致备份异常终止，而是自动进行了rman备份channel的failover，并且备份日志最终显示整个备份也是成功的。
会后我继续分析这个错误，根据以往经验来看，针对这种配置上没有问题，时而会出现的错误很难去找到根本原因。那么现在最好的办法就是双管齐下，借助外部资源协助分析此问题。通过客户服务号我提了一个问题服务请求，并将日志和系统配置信息都上传给了产品的二线技术支持。经过他们一天时间的分析之后给我的回复是这个错误很可能是软件兼容性问题，因为整个系统架构基本上都是采用的软件虚拟化技术实现的，其中包括v5000存储、vtl虚拟带库、大机上的虚拟分区都是虚拟化实现的。最后给出的建议是尝试升级不同的组件，tsm server或者tape driver。
当我把这个分析结果反馈给客户后，客户认为目前系统已经运行几年了，系统变更升级是个大动作，而且升级之后并不一定能够解决问题，所以不能接受软件升级建议。其实我也非常理解客户，这样的分析结果的确不容易接受。但是从配置各个层面的检查并没有发现明显的错误信息，而从以往的项目中也遇到过此类问题，尤其是这种数据量大耗时长的备份，整个备份过程中很可能会出现一些不确定的问题，但是这些问题都是非致命性的，就像这个case一样，rman能够自动failover。
看来这个问题很难直接找到root cause，更不能直接消除了。既然直走走不通，只能绕开转换问题的解决方向了。经过这几天与客户的接触与谈话中，使我意识到用户更关心的是备份是否是正常的，是否是可用的，而并不一定就是纠结必须去消除这个错误提示；那么我想是不是我只要证明整个备份是可用的就行了。在我把我的整个想法和客户沟通后，没想到客户马上同意了，看来我没判断错误客户的真是需求。
接下来我将编写3个脚本，用于全面扫描备份文件，以验证备份是否可用。
第1个脚本：
#!/bin/bash
. /home/oracle/.bash_profile
rman target / msglog /tmp/restoreprecheck.log <
run {
allocate channel t1 type 'sbt_tape' parms 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
allocate channel t2 type 'sbt_tape' parms 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
restore database preview;
release channel t1;
release channel t2;
}
EOF
exit
第2个脚本：
#!/bin/bash
. /home/oracle/.bash_profile
rman target / msglog /tmp/restorechenck.log <
run {
allocate channel t1 type 'sbt_tape' parms 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
allocate channel t2 type 'sbt_tape' parms 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
restore validate database;
release channel t1;
release channel t2;
}
EOF
exit
第3个脚本：
#!/bin/bash
. /home/oracle/.bash_profile
rman target / msglog /tmp/restorearcchenck.log <
run {
allocate channel t1 type 'sbt_tape' parms 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
allocate channel t2 type 'sbt_tape' parms 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
restore validate archivelog sequence between 33470 and 33503 thread 1;
restore validate archivelog sequence between 22764 and 22791 thread 2;
release channel t1;
release channel t2;
}
EOF
exit
使用nohup命令将3个脚本全部推到后台执行；先执行第一个脚本，待得到结果后，需要将得到的归档日志sequence号写入到第3个脚本中进行归档日志恢复验证。值得庆幸的是3个脚本都执行成功，输出日志中没有任何warning或者error信息，说明此备份是可以用于恢复的。当客户看过结果后也给予认可，同时我建议客户可以在他们的测试系统上进行异机恢复，这样更能确定备份是否可用，并且也可以在以后进行定期的异机恢复，在验证备份可用的同时还能够保留一份数据副本，进一步提升数据安全性。以前我们就遇到过一次oracle数据库数据损坏，更不幸的是备份磁带中的数据被用户维护人员误删除，导致备份不可用，最后是从测试数据库中把数据恢复回来的(当时他们就是做的定期恢复数据到测试数据库)，当然也丢失了最新的数据。
但是目前客户的存储空间不足(至少需要20TB空间才能进行oracle异机恢复)，将会在后期存储硬件扩容之后，再具体实施我的建议。目前的策略是每次完成数据库全备份之后，执行我写的3个脚本，以验证备份是否可用，并将其纳入到日常的运维制度当中。
总结：
1.通过这个案例让我深刻意识到去剖析客户的真实需求是多么重要；如果我一直按照去消除错误信息的想法去做，即耗时又费力，最后也不一定能够策底解决，因为错误原因太不明确了，不确定因素也很多，如果是容易的问题前面去过的几波人早就给解决了；如果尝试升级很有可能没有解决原有问题而产生新的问题，毕竟是生产系统，都是宜静不宜动。
2.在解决比较复杂的问题时，如果有外部资源可以使用，那就要充分利用，让他成为你的外脑，协助你快速准确的解决问题；在这个案例中我一开始就向产品团队提交了服务请求让他们协助分析。
3.尽可能的与客户充分沟通，在你了解客户以及客户真实需求的同时；也能够让客户了解你的想法和做法，这样更利于问题的处理。
最后一句话与大家共勉：你的琴棋书画搞得再好也没用，人家要的是身材和脸蛋。了解用户的真实需求能够让我们事半功倍。
分享至：
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
