周末两天参加了IT168的架构师大会。虽然基本上是以互联网应用的基础架构为主，但是我还是从各位嘉宾的演讲和回答问题的环节中，获益良多。至少开扩了不少眼界。之前我参加过不少原厂商组织的技术大会，和那些活动比起来，我更喜欢这样由工作在一线的技术人员经验分享为主的会议。大家讨论的是实实在在在实际工作中碰到的问题，针对性也很强。演讲者的很多经验，其实也可以推而广之到别的环境和其他的行业应用。
不过因为时间的限制，很多演讲关于细节的东西没有涉及太深入，不能不说是一个遗憾。
Posts Tagged ‘架构’
参加IT168架构师大会
August 31st, 2009Review我对一个Oracle数据库系统的改造
July 16th, 2009一年前,我接管了一套Oracle数据库系统.这套系统主要是为制造业工厂生产线服务的应用系统.当时的系统的状况是,我来之前整套系统都是由老外负责Build.但是服务器的硬件在国内由集成商搭建,后期因为缺少技术人员没人管,基本处于放羊阶段.最多有硬件坏了,安排集成商更换一下.数据库是Oracle10G.在使用过程中经常down机.基本每周必有一down.很多时候系统down了,生产线的工人就只能停下来,Call老外,让老外重起,或者手工切换一下节点.后来领导可能觉得实在麻烦,拍着我的肩说,你管一下吧.于是我上了.
虽然我已经有年头没摸Oracle了,但是我想我作为一个Oracle Dba的思路还是有的.毕竟在N年前,我是Oracle 8I的OCP:)
Review一下我的工作记录,从当初到现在,我大致做了这么几件事:
1.收集能收集到所有的系统信息，包括OS/DB的版本，内核参数，硬件微码版本。
升级Os的版本从AIX53-02到AIX53-07.
升级系统微码到一个比较新的Level,这个操作fix了一个内置网卡在大流量下会假死的一个问题.
调整内核参数,使其符合Oracle数据库的环境.
2.分析所有的系统日志文件,包括对前面几次Down机生成的Core文件.解决了Hacmp的dms问题.
3.调整存储。以前的状况是一个DS4300上面,就划出一个几百G的Share VG.所有的数据库相关文件,包括Tablespaces,Controlfile,RedoLog,Archive file都在这个Vg里面。
我在一年的时间里面,分2步进行调整：
Step1: 去年的时候重新划分3个VG,分别存放Datafiles,Redo log,Archive log.将老的数据迁移到新的Vg里面,我创建的每个PV为64gb.旧的空间回收.基本消灭Io Wait。
Step2：今年上半年刚做完的,将回收的空间做成了ASM,将基于文件系统的Oracle迁移到Asm的架构里面.（这里参考了Ningoo的文章)
完成上面的操作,再也没有发现临时表空间会突然被一个SESSION排序占满的情况.
4.我只对Oracle的参数做了微调，毕竟经过前面的分析，因为不合理的参数导致的Oracle down的情况几乎没有。
5.分析Oracle AS的错误日志，发现其中有某些线程导致Memory Out的错误，提交给老外Fix。俺也不是万能的:)
6.增加Monitor脚本。对文件系统和表空间的监控结果按照Email的方式,定时发到我的邮箱。定时移出Archive log file.
7.给系统增加Netbackup的解决方案，制定备份策略。现在Rman+Tape library能够满足需求了。
8.根据Auditor的要求，打开了审计功能。清理掉大多数的默认用户。要求开发者将数据库用户密码存储管理用密文存储。
9.安装Quest Vas+Sudo。将OS用户集成到公司统一的Ldap环境里面。基本杜绝误操作的概率。就算出现误操作，也能揪出人来，再前面挡着:)
10.安装AWR.
11.定时schedule合理的Downtime.在我的理解里面planned的downtime不是down机，也不会影响你的SLA的水平。所以，我现在基本3个月来一次。最终用户也能接受。
现在这个系统已经很长一段时间>8个月没有非正常停机了，Workload的各项指标也比较正常。
回顾以上操作，也许有人会问每看见你去优化SQL呢?呵呵，我首先不是Application的owner，另外我这边通过Awr生成的一些sql的报告来看，基本上没有太离谱的sql。当然，老外写的sql确实还不错。更重要的是，我觉得好的一个系统规划，能够消灭70%以上的性能问题。
分布式的数据库集群和海量数据存储的一点思考
April 3rd, 2009题目很大，如果以为这是篇技术文章，那可就错了:)
过年的时候，回来和几个老朋友见面。大家好像都碰到面临着海量数据存储和数据处理能力overflow的压力。
一个哥们,一直做移动行业的ETL，N久没见。给我的第一个电话，就是讨论详单海量数据能否由过去的集中处理，能否考虑在ETL中使用分布式的集群。
另外一个老朋友，工作在一个亚洲数得着的一个大规模订单处理和流转系统环境里面从事应用架构方面的工作，现在也在考虑数据库层面架构的重构。过年就那么几天，和他喝了一次咖啡，吃了一次日本菜。每次主要讨论的都是系统架构的技术细节(:
至于我，以前从事过移动和烟草的一些项目，也对RAC和DPF,oltp/olap都有一些自己的体验,所以对架构这块也有一些兴趣。虽然目前的公司在我眼里是一个老牌保守的那种正统商业公司，但是随着公司内部”Open Source policy”的发布和Amazon saas这样服务在国外的流行，公司内部的论坛上对saas和cloud的讨论也越来越集中。而且已经有超过60个节点的cluster被用来做CAD计算。
对于db2来说，一直以来我在思考的就是两个问题，在大规模的分布式环境里面如何分离读写IO和DPF如何满足OLTP的要求。前一个问题，几年前和IBM讨论的时候，记得他们的技术人员提到用SQL复制/Q复制来做。对于这点，我是有疑虑的。经过几个项目的体会，这两种都基本上是表层面的，而且SQL复制性能相当一般。Q复制，性能还行，但是对于通道的维护那还是比较麻烦的，也不适合。最近，了解到一些新的解决方案可以帮助我找到答案。另一个问题，虽然听过沈刚的presentation,有一些启发但是这个还得结合应用来考虑。
就国内来说，阿里的Jacky.zhang目前主持的Amoeba+db的分布式架构和mysql的廉价集群项目，无疑是值得期待的。希望他的blog能继续给我们带来更detail的技术细节和更新的技术思路。
Jacky.Zhang,俺看好你哟:)
