您的位置:首页 > 数据库

关于SQLServer2005的学习笔记(一)——前言

2009-12-18 10:41 295 查看
关于SQLServer2005
的学习笔记(一)——前言



关于
SQL Server
,个人一直认为它是比较简单却又很神秘的数据库;简单之处在于他完全通过图形化界面便可实现所有大型数据库的安装、维护、备份、优化等等;神秘呢在于它所有的一切都隐藏在了图形化界面之下,让人琢磨不透,当需要更深层次的去了解他的时候,却无能为力。

我开始使用
SQL Server

2002
年起,做了一年多基于
SQL Server
数据库的程序开发,然后
04

05
年又做了两年基于
SQL Server
的数据仓库,因为数据量太大和性能原因所以需要不断进行性能优化和调整。



印象最深刻的是
05
年在某移动公司实施基于
SQL Server2000
的数据仓库项目。那台数据仓库机器的硬件配置也不高,
4G
内存,好像是
4

CPU
,跑的是
Windows Server2003
;当时每天的数据量为
1.2GB
,整个数据仓库包括一年的历史数据,总计达到了将近
800GB
,业务数据源主要来自于一个
oracle
数据库,当然还有大量的话务文件,话务信息总是以二进制文本存在,并通过解析工具不断的解析到数据库中。

对于
SQLServer2000
来说,难点主要如下:

1、

单表超过
1000
万记录,查询更新删除性能急转直下

很不幸的是,话单信息每天都要超过
3000
万了,即使经过处理后的话单也将近
1000
万;

2、

SQL Server
的锁机制问题,
SQLServer2000
采用的是已提交读的悲观并发控制,在读和写之间非常容易造成死锁。

3、

业务逻辑处理复杂度太高,导致性能问题

一条话务可能会出现几十条话单(最高记录为
50
条左右,大概是
IVR
流程设置的问题),最终的话单会被一个长达七八百行的存储过程解析为
3
条话单,而这个过程基本是连续的;这三条话单再经过
ETL
处理转变成可统计的话务指标。

4、

OLAP
也存在严重的性能问题,当时的一个
MOLAP
就将近
100GB


5、

系统稳定性不够,总是莫名其妙的出现作业当掉的情况

针对以上情况,我做了不断的尝试和优化,例如优化表结构设计,把表做成当前表和历史表,历史表再切分成分月表;优化业务逻辑存储过程;增加检验和处理死锁;并针对稳定性问题向微软上海进行咨询和处理,最后下载了一堆的补丁和工具进行反复实践。

说实在的,用
SQLServer2000

BI/DW
项目,最大的好处是完全通过联机帮助就可以上手,而最大的问题就是稳定性和性能问题,使用
SQL Server
的这段的经验确实让人很痛苦,因为你无从解决。



再后来,转向了
Oracle
一段时间,同样我对
Oracle
的整体架构、性能优化和开发稍微了解一些,但无奈的是自己对
linux
的了解实在匮乏,所以很难专进去。个人认为自个对
Oracle
的体系架构认识的要比
SQLServer
更深刻一些。



最近一段时间同步阅读了一下《
SQLServe2005
技术内幕存储引擎》、《
SQLServe2005
技术内幕程序设计》、《
SQLServe2005
技术内幕
T-SQL
查询》,对
SQLServer2005
有了一些新的认识,总得感觉
2005

2000
有了质的飞跃,微软也在与
Oracle

IBM
的不断竞争中成长,而数据库在竞争中不断趋同。



读书第一遍只是为粗略的看一下,不敢去发表什么个人观点;读第二遍的时候把自己熟悉的部分会做下实践和印证;如果还是无法理解,再去读第三遍;这是我对读书的态度。



我会在这段时间陆陆续续把自己对以上三本书的学习心得不断记录下来,并在
SQLServer

Oracle
之间进行比较,在
SQLServer2000

SQLServer2005
之间进行比较。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: