创新谈-孙磊

创新性应用:

行业借鉴经验:

应用难点技巧:

 

 

 

 

 

 

 

 

 

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

另外,外键的彼此制约关系也会导致一些表不能导入或schema部分导入,这一块在MSSQL2K SP4中好像也没什么改进。DTS做的比较好,数据传输过程中保留了诸多选项,包括复制索引、主键、添加/替代数据、保留登录等,大抵可以满足需求,但是DTS也有性能上的不少问题,这在我进微软支持MSSQL产品之后经常遇到。我离开第一份工作,主要是觉得后期编程量越来越大,而我对编程是没有多少sense的。有幸进入微软工作,接触到很多精通技术内部实现的专家。对微软数据库产品,即AccessSQLServer。整个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来处理报表,SQLServerreporting service较为复杂,且有很多问题。当然水晶报表不错,不过价钱也不菲。

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

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

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 
  • 0
    点赞
  • 1
    评论
  • 0
    收藏
  • 打赏
    打赏
  • 扫一扫,分享海报

©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页

打赏作者

best_dba

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值