SQL Server 2000 页面大小和 NTFS 页面大小
在 Oracle 世界中，将数据库块大小构建为文件系统块大小的偶数倍是福音。 我认为这仍然是正确的，但我并不反对被告知为什么技术使这变得无关紧要。
但我听说一些 SQL Server DBA 将把 SS2000 安装的操作系统升级到 64 位，以便在 FS 中获得 64k 页。
SQL Server 2000 是否支持更改页面大小？
据我所知，它固定在 8k。 是这样吗？
如果固定在8k，做FS 64k有什么优势吗？
我从可靠的来源获得这些信息，但仍然是二手的。
编辑：感谢 SAMBO，我已阅读链接并找到了规范
“NTFS 分配单元大小”设置为 64Kb
我假设该术语 = 块大小...
因此 8k DB 块和 64k FS 块之间的冲突实际上是 MS 推荐的设置。
In the Oracle world, it's been gospel to build your database block size to be even multiples of the File system's block size. I assume this is still true but I'm not adverse to being told why technology has made this irrelevant.
But I've been told some SQL Server DBA's are going to upgrade the OS of a SS2000 installation to 64bit to get 64k pages in the FS.
Does SQL Server 2000 support changing the page size?
From what I've read it's fixed at 8k. Is that right?
If it is fixed at 8k, would there be any advantage to making the FS 64k?
I'm getting this information from a reliable source but none-the-less second hand.
EDIT: Thanks to SAMBO, I've read the links and found the specification for
"NTFS Allocation Unit Size" be set to 64Kb
I assume that term = Block Size...
So the conflict I have between 8k DB blocks and 64k FS blocks is in fact the recommended setup from MS.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
请务必阅读 Microsoft 的预部署 I/O 最佳实践
它建议对 NTFS 卷使用 64K 分配单元。
另外，阅读 SQL Server 2000 IO 基础知识
最后有查看这篇文章。
SQL Server 页面大小实际上是8K，这是不可配置的。 在操作系统上拥有更大分配单元的优点是，当 SQL Server 将页面提取到其缓存中时，也许您可以获得稍微更好的性能。
根据我的经验，我怀疑修改这些值是否会给您带来任何明显的性能改进，最好的情况是您会得到微小的改进。
最好把精力花在隔离 tempdb、确保使用 raid1/0 阵列、让事务日志位于与数据文件不同的阵列上以及优化查询等事情上。
Make sure you read the Microsoft's Predeployment I/O Best Practices
It recommends using 64K allocation units for NTFS volumes.
Also, read SQL Server 2000 IO basics
Finally have a look at this post.
SQL Servers page size is in fact 8K, this is non-configurable. The advantage of having larger allocation unit on the OS is that perhaps you can get slightly better performance when SQL Server is fetching pages in to its cache.
From my experience, I doubt mucking around with these values will give you any noticeable performance improvements best case you would get a minuscule improvement.
Better spend your efforts doing stuff like isolating tempdb, ensuring raid1/0 array are used, having your transaction log live on a different array to the data file and optimizing queries.
文件系统的整体性能可以产生显着的差异。
例如，我听说Windows Server 2003问世时，该平台上的SQL Server 2000性能得到了显着提高。
所以我并不感到惊讶。 我不认为多重因素有那么大的问题。
The overall performance of the file-system can make a noticeable difference.
For example, I heard when Windows Server 2003 came out that SQL Server 2000 performance on that platform was improved significantly.
So it doesn't surprise me. I don't think the multiple factor is that big of a deal.