我是一名开发人员,需要一些 DBA 建议。
我们开始遇到 MSSQL2005 数据库的性能问题。事件的可见影响主要是服务器上的 CPU 占用率过高,但运营报告称它还消耗了 SAN 的资源(并非总是如此)。问题的主要来源肯定是某些应用程序,但我想知道我们是否应该对一些主表进行分区以减轻 I/O 压力。
一个文件的基础大小约为 60GB。
主表(订单)有 210 万行,每行 215 个冒号(但没有一个是巨大的)。
我们有一个整数作为 PK,因此定义分区函数应该没问题。
分区能给我们带来好处吗?分区索引能给我们带来好处吗?
以下是有关数据库和表的更多事实
database_name database_size unallocated space
My_base 57173.06 MB 79.74 MB
reserved data index_size unused
29 444 808 KB 26 577 320 KB 2 845 232 KB 22 256 KB
name rows reserved data index_size unused
Order 2 097 626 4 403 832 KB 2 756 064 KB 1 646 080 KB 1688 KB
谢谢你的建议
唐
答案1
啊 - 为什么?15 年前,100 万行数据已经算小了。而今天,1 亿行数据已经算小了。
如果您遇到 CPU 占用过大的问题,我会开始查找问题所在 - 这看起来更像是索引问题和/或不良字段设计,而不是其他任何问题。
现在,SAN 占用 - 对于任何 SQL Server 来说,这都是完全正常的。SAN 人员通常对数据库服务器的 IO 负荷大这一事实一无所知。数据库通常需要针对其优化并可充分利用的特定 SAN 设置。它不是“占用”它,而是尝试尽可能好地利用所有资源。
您的数据库很小 - 说真的。我在这里真的看不到任何问题。订单表的内存只有 4GB,有趣的是 - 这个大小应该从内存中回答。
分区对于大量删除很有用(每年删除一张表,删除一年的订单是表截断,而不是删除),但对于您的规模来说这不是问题(我有一个包含大约 15 亿个条目的价格表,而且这个数据量很小)。它不会大大加速查询 - 要么查询只能选择一个分区(不,整数 PK 没有帮助,除非您按 PK 范围选择作为过滤器) - 要么它不能。但即使它可以,索引也几乎一样快。
什么类型的查询不好?执行计划怎么样?也许你会:
内存太小(8GB或更多?)
索引布局不理想/不匹配,导致查询基本上变成表扫描?在这种情况下,我会从那方面开始修复。
您加载了超出需要的数据吗?
如果没有查询执行计划,就无法回答这个问题。
顺便说一句,一个文件 60GB 是严重疏忽。任何大型数据库都应该具有与并行操作数量相同的文件数量(即 SQL Server 可用的服务器核心数量);)我敢肯定您的 I/O 组织得很糟糕 - 未对齐的分区、错误的格式,减慢了您的速度(可能非常慢 - 错误的磁盘设置可能会使您的性能降低高达 40%)。
要缓解 I/O 压力:
确保数据库服务器已正确安装(我很少看到 - 管理员似乎喜欢忽略这里的文档)
首先,确保你拥有适当的资源。磁盘子系统上的 IOPS 预算有多高?你测量过吗?
确保数据库设置正确(再次强调,大多数管理员在这种情况下都喜欢装糊涂)
确保您有一个良好的表结构和良好的主键(几乎这是您唯一正确的东西)。
然后 - 进入分析器,找出应用程序并确保这些查询得到优化。