创新谈-孙磊

创新性应用： 行业借鉴经验： 应用难点技巧：

 

 

 

从大学毕业到现在只有三年，我对数据库谈不上精通，但浓厚的兴趣一直让我对其不断学习和理解。我跳槽比较多，现在已是自己的的第三份工作了，这个显得不够塌实。这三份工作中，我一直都在跟数据库打交道。第一份工作就接触到当今流行的两个数据库，MSSQL和Oracle。记得调试PLSQL语句，优化Oracle存储过程常常在单位弄到很晚，不过一点都不会心烦意乱，反而会因为领会了一点什么会庆幸。当时公司里有一个数据库达人，他一直想去做DBA，领导似乎也支持他这么去做。有时候周末我去公司加班还看到他口啃干粮，在编存储过程之类的语句。我想，一个技术人员如果对某种技术感兴趣，他一定会花费很多时间去钻研，钻研的越深，越来劲，如此水平也不断提高，实现良性循环。在这之中，印象比较深的是在自定义报表这块，涉及很复杂的查询，因为是给银行开发，效率是很关键的环节之一；另外，调试报表的时候，跑出来的结果常常与筛选条件不符，然后检查SQL语句，自己感觉逻辑却都是对的，所以有时候还是蛮头疼的。特别是刚开始的时候，看到很长很长的存储过程，整个头都大了，于是整天就在Toad里面搞，后来慢慢熟悉点，也没开始那么吃力了，兴趣也开始慢慢滋长。后来公司做一个日本外包项目，前端要求用C#，后端用MSSQL。因为日方不断调整数据库的schema，我们在接到变更之后就须重新依照脚本将新数据库schema导入。但是有时候会出一些问题，如两个自定义函数和一个视图，函数2依赖于函数1并都被视图1调用，但MSSQL提供的导入并不够智能，记得是先导视图再导函数，所以这一块导入每次必须手动去修改。

另外，外键的彼此制约关系也会导致一些表不能导入或schema部分导入，这一块在MSSQL2K SP4中好像也没什么改进。DTS做的比较好，数据传输过程中保留了诸多选项，包括复制索引、主键、添加/替代数据、保留登录等，大抵可以满足需求，但是DTS也有性能上的不少问题，这在我进微软支持MSSQL产品之后经常遇到。我离开第一份工作，主要是觉得后期编程量越来越大，而我对编程是没有多少sense的。有幸进入微软工作，接触到很多精通技术内部实现的专家。对微软数据库产品，即Access和SQLServer。整个team只有十五六人，但是其中好几个是非常厉害的。在这次数据库工程师评选中，几乎没有看到他们的名字，我想可能是他们的项目经验比较少，因为我们主要是点对点来解决具体问题。我刚上来支持Access产品，然后支持SQLServer一些非疑难问题。也许大家都对Access嗤之以鼻，尤其是国内，几乎很少有公司会用Access来开发或使用，但在国外Access的使用是较为普遍的，很多个人或小型公司要么拿之为别人进行开发定制，要么实现该公司的一项什么功能或者应用。有些应用做的非常复杂，或者几易版本，已经非常成熟。我对Access的理解是，Access对小数据量的管理和实际应用还是很不错的，由于它集应用界面和数据后台为一体，对小数据量的查询性能也不赖，还是有一定的用户群。一些高级功能通过VBA进行开发，也能实现较为复杂的功能，如报表。当然，宏观上来说，Access没有日志（虽然可以控制事务），没有独立的文件读写进程，没有强化的数据（库）安全，但它的市场定位就是这样，对于需要这些功能的用户，可以选择SQLServer或非微软产品。Access几个比较优势劣势的地方，我也想列一下：

1 Word中有一个高级应用叫Mail Merge，可以从数据源如Access中逐行读取数据并很好的格式化。这点也是微软产品内部协作的一个体现。Mail Merge出来的结果可以存档，也可以自动打印成一定的页面，在实际应用中可以作为商品标签，呵呵。这样就不需要复杂的工控设备来完成了。

2 OfficeXP里提供一个封装Access产品的软件，由于Access开发的产品（MDB）需要在有安装Access软件的机器环境中才能运行，微软很聪明的做法是将这一依赖取消，出来了Access runtime版。通过Package Wizard这一工具，可以将Access文件、必要的DLL进行打包，做成安装包格式在任何一台Windows环境机器上都可以运行。我处理的很多case中都有这样的应用，如一个开发者为某小型公司定制这么一个系统（如电话查询系统），可以很好的满足应用，性能也比较好。

3 Access出来的报告简单明了，据说国内一些银行即通过Access来处理报表，SQLServer的reporting service较为复杂，且有很多问题。当然水晶报表不错，不过价钱也不菲。

当然Access也有不少实际问题，一下仅举几例：

1 微软虽然宣称Access最多可以支持255个客户端（LDF最多可以容纳255行 每行对应一个用户端），可是我们处理很多用户实例过程中，在共享用户达到20～30之后常常出现一些问题，如数据库无法继续正常提供访问，需要修复，等等。关于这种错误在深层次上有不少原因，在此不能详述。总之其并发度是一个问题。

2 VBA执行效率不高大家都有体会，在针对大数据量时，如果使用ResultSet来进行一些匹配，在机器内存较为紧张情况下，会发生一些内存换进换出、溢出等情况。而且我和同事也做过试验，在数据量达到几百万时候，Access查询的性能大打折扣，2G的数据库容量限制随即而来。

3 Access报表中对图形的支持较Excel差，对于同样的一个圆或三角，Excel出来的非常好看而Access出来锯齿状效果很明显。这是由于Access传递分割图形而Excel通过打印机调用API绘图函数机理不同而导致。

4 Access的JetSQL在多表union时也有一些问题，不同的顺序出来的结果还不一致。据说下一版本的Access将不使用Jet作为引擎，届时可以观察一下效果。

 

当然，话说回来遇到问题最多的还是SQLServer，可以去查微软的KB文章，关于SQLServer的文档比Access多多了。对于目前流行的几个数据库，我的感觉是功能和设计思想相差不大，日志传送在SQLServer中有，在Oracle中有，在DB2中也有。关于高可用性的实现，SQLServer依赖与MSCS的Failover Cluster和Oracle的Application Cluster实现机制都有类似，在SQLServer2005中Database Mirror其实是换汤不换药，但这其中的改进还是应该看到的。但是即使是Database Mirror，工作服务器和预备服务器之间的数据也不是任一时刻同步，网上曾看到讨论实时同步的帖子，讨论今天的硬件和软件实现之道，跟帖者很多并且争的面红耳赤，主要观点还是目前还不能够实现两服务器间数据的时刻同步，IBM还是哪家公司的实现据说可以，但费用高昂。

 

在微软的一年多，工作甚是辛苦，加班到晚间十点亦是家常便饭。我们通常遇到的问题集中在复制、DTS、数据库服务不能启动或数据库错误等。我也感觉复制这块实现并不好，第一对复制的对象有要求（如对表要求主键等），第二还会对一些表加额外的列，这个就比较严重了，客户常常不能接受。微软对于其旗下一些产品应用该技术都不提供支持，如多SMS服务器间进行数据库的复制行为。据说中国铁路当时请Sybase来做的网络发布－分发－订阅这一功能，我们还曾看到网上一些针对与此的技术讨论，说100个点往一个点汇总，这样听起来令人毛骨悚然，Sybase真能这样也太强大了，问题是对于冲突的数据怎么解决真的是个难题，至少SQLServer没有解决好。

 

网上关于数据库间复制也是提问的焦点，小到文本文件导出数据至Access，大到DB2导出数据至SQLServer，或者Oracle通过透明网关导入SQLServer数据。就我碰到的DTS问题，以性能为主居多。DTS性能确实也不高，跟驱动层有一定关系。用户常常从午夜一点开始导一批数据（如160G），至清晨不能结束，甚至两天下来不能结束。很难想象让用户接受将此DTS作为作业定期隔三差五运行。BCP和TextCopy性能要好一些，但是不能一蹴而就，而且应用也有限。

 

讨论SQLServer的网站感觉也比较少，国内csdn和itpub上算人气比较热的，但提出的很多问题比较初级，如“我的企业版SQLServer无法安装在WinXP 怎么回事啊 急急急”，“ 请问左连接和右连接到底有什么不同”，“我的日志太大了 怎么截断”，高级一些的问题如“链接服务器上作游标访问失败”，“成功Debug的DTS作业无法定期运行”等，关于SQLServer高级功能和性能调优的问题很少，对SQLServer内部实现的讨论则寥寥无几。不过对于无法进阶SQLServer的用户来言，他们是站在应用的角度来看问题，我当时微软的几个同事因为对代码都比较清楚，对于一些问题的看待则是由里而外的，异常深刻。我也非常敬佩他们，不过他们水平也不是一天能够形成的，而且成天地去看错误内存镜像文件是很枯燥而且恐怖的事情。

 

对于数据库的应用，相信每一个用心的技术人员都会进行整理，我也常常将一些经验，心得整理在专用文档中，因为有些东西事后还是会遗忘，留在纸上（文档中）则可以温故知新。关于这个，有人比喻说如果你对这些知识不做整理，你只能盖平房；如果你经常做梳理和理解，可以盖成高楼，有一些道理。

 

我一直觉得这三千字很难写，因为文章标题是创新谈，那么在创新谈之前，首先要熟练应用各项功能，但数据库二次开发功能比较弱吧，无论是SQLServer还是Oracle抑或是DB2，都有很多bug，在一项应用可以服务当前需求情况下，我们或提高一项查询的性能，或进行物理硬件的Enhance，或依据分析器脚本来巩固/优化数据库性能，谈不上创新；如果一项应用不能满足当前需求，对于一个企业的做法是更换数据库系统，我想对于主要的需求当前几个数据库基本上都cover住了。当然，创新是有的，就是针对一个点，一个细节，不过很遗憾，大多都忘记了。过去做几百个case，有一些技巧性的动作，但都依照特定的程序环境，时过境迁回忆不起来了。还有对于常见的应用，我也不想拷贝出来，比如通过一条SQL语句对一个数据库里所有表进行清空、添加列、列出所有的列名，比如数据库崩溃后如何依照上次的备份进行时点的还原，比如行列转化、比如删除数据怎样最快效果最好，比如数据库日常维护策略，比如大位图文件的存取等等，这些网上都有很多讨论，也都有正确地答案，也就不放在这里充字数。

 

离开微软来我现在的公司微创，是想多接触一些人的因素，不愿整天跟机器打交道。事实也是如此，微创这里就是做项目，包括SQL、AD、Exchange、ISA、SMS等。我记得前一阶段，客户那里有一个需求，他们想搭建SQLServer来实现每日500G数据的流量，我听了吓了一跳，这样的日数据流量，完全是要靠经验来做的，衡量这个项目成功最重要的指标就是性能。而我是没有系统处理过大数据经验的。当然还有更夸张的，从报纸上看的，美国要架设一个什么天文观测站，整个站点都几百个射电望远镜构成，每秒处理的数据量是多少我也记不清了，反而是TB单位，真是恐怖。目前针对大数据处理，都说DB2性能最好，我想DB2即便能进行这样的处理，也必须依托极其凶悍的硬件了。

 

现在整天在外面跑，我感觉很多公司对数据库应用都不充分，ERP系统动辄使用Oracle，其实只是赚个噱头而已，那些基本功能在Access中也能实现，当然数据安全性还是很重要的，所以用SQLServer还是不错的选择。可是即便是这样，很多公司也会用不好。备份的方式还是采用每日全备，有家规模挺大的公司就是因为数据库损坏，所有的数据退回到前一个工作日，内部员工不得不重复一回当天的工作内容，可见管理水平并不高。

 

再谈谈性能，SQLServer搭建在Windows系统之上，稳定性不够是其一，性能也有损失。想运行在Unix/Linux系统上的Oracle就自然领先了。微软宣称其Windows Server 2003产品是其有史以来发布的最为稳定的一款服务器平台，但与此同时她建议用户一个月能够重启一次服务器，以便回收部分资源，可见Windows还是有其根深蒂固的缺点。Unix和Linux虽然配置麻烦，但一旦上阵，坚如钢铁，牢不可破。这也是SQLServer不为大用户青睐的原因之一。SQLServer 2005比之前版本更为“霸道”，对内存的占用很凶猛，有多少吃多少，不过也可以迅速释放。可见，为了提高性能，2005还是下了很多功夫。网上常常有人抱怨自己的SQLServer很慢，问他内存原来只有512M或者1G，还是在台式机上，所以得出结论说SQLServer性能不高，真是无话可说。即使是Oracle、DB2，在处理海量数据上，也并不是绝对优势，微软在发布2005之初给一些大公司做的迁移，之后OLAP的效率大大提高，超过之前应用的Oracle。我所在的上海地区，就举上海移动为例，每月余进行数据汇总，报表等的处理也要花费相当的时间，那个时候打1861总是提示数据处理中。总结一下，我说的比较罗嗦，我觉得目前的几个主流产品，虽然实现机理大抵相似，但性能差距是必然存在的，每个产品都有它的优势和劣势，DB2不是绝对的好，SQLServer也不是绝对的不好，配以好的硬件环境，好的技术管理，每个产品的优势都可以最大化。

 

就写到这里，如能忍痛看完，不甚欣慰。写这些出来，就是交流一下，平时bbs上一直交流具体的技术，这里就不再详述技术，只说一些心路历程之类的，呵呵。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

文章请同时提交信箱：bestdba@ciw.com.cn  mulibox@yahoo.com.cn