MSSQL优化之 1.1 存储架构之文件和文件组

 

Sql server存储架构之一文件和文件组

本篇文章将由粗到细，讲解数据库的物理组成结构。有些东西可能是废话或是摘抄自BOL，等权威文章，但是作为一个知识体系结构，还是需要啰嗦一下。

 

数据库的文件和文件组

数据库是由一系列的文件组成，文件组是文件的管理单元，类似于命名空间，但很不幸的是微软没有在文件组这个管理单元上赋予更多的权力，比如权限管理。而数据库的权限管理是通过数据库的架构，账户，角色，证书等来控制的。文件组的最大的好处在于多磁盘环境，或者RAID环境下，可以轻松来组织管理文件。比如你可以将几个文件创建在几个不同的磁盘上，而且将几个文件分配到相同的文件组内，然后新建一个表，指定的存储是这个文件组。这样有什么好处呢？很明显的提高IO吞吐。因为磁盘多了，多磁盘可以并行取数据，至于磁盘的结构，大家可以参考李战老师写的一个关于磁盘的文章，地址我忘了，大家去可以去看看。（废话一下，最近公司磁盘坏了一块，咨询了一下dell的，他们说现在1w转的和1w5的价钱差不太多，大家可以考虑考虑）

 

关于文件大小

大家对文件大小也许会不屑一顾，但是这个是DBA人员非常看重的一个地方。文件大小的增长方式有按照比例自动增长和按照固定大小自动增长，因此有很多人在生产环境下对于创建数据库的时候这一选项都不在乎，实际上非常重要。如果开始指定的文件大小只有100M，那么当数据库达到100M的时候，数据库会向操作系统请求更多的空间，那么操作系统会怎办？？？大家都知道.NET里面的垃圾回收器整理堆区，重排堆区以提高程序访问托管堆的性能，那么在数据库也存在同样的问题。重新向操作系统申请的空间，应该说不大可能跟以前的数据库文件空间是连续的，所以导致文件之间的裂缝。关于裂缝，MSSQL有很多对付裂缝的方法，将在以后文章会陆续提到。还有就是如果文件已经很大，再次频繁增长的时候，因为闩锁会导致系统响应变慢，甚至响应超时。而更重要的一点是，TEMPDB文件的存放问题。TEMPDB，大家都知道是不会持久化数据的，但是读写时非常频繁的，而且他并不是不使用磁盘空间，全使用内存。大家熟悉的排序（配备 sort in tempdb 选项），临时表，假脱机表，连表的中间结果集，等都是存放在TEMPDB内的，保证磁盘的读写速度也是很重要的。（TEMPDB的性能2005比2000要好很多）所以一般的DBA都会将TEMPDB单独不与一般的数据文件存放在一个磁盘下（道理同上面提到的文件组管理）。TEMPDB的大小到底指定多少合适呢？？？没有一个绝对的数据，只有各种环境下的模拟测试。我看过顶尖DBA对TEMPDB大小的限制，一般是使用一个模拟的高峰期环境，查看TEMPDB所能达到的最大大小，然后乘以20%，来决定TEMPDB大小，当然这个是极端的做法，更多的不太可能这样做，一般一个指导性原则就是，如果你的表少，可以小点，如果你的临时表和排序，游标操作不多，可以少点，如果你不使用快照技术，可以少点。有关TEMPDB的更多优化细节，可以参看微软的知识库文章，TEMPDB最佳实践，http://www.microsoft.com/technet/prodtechnol/sql/2005/workingwithtempdb.mspx 我在这里就不详述多了。