设定:
- Windows Server 2008 R2
- SQL Server 2008 R2 SP1
- 240GB RAM
- TempDB是8x16GB数据文件,没有自动增长(总共128GB)
- 物理/独立服务器
该服务器用于ETL处理。我们刚刚在此服务器上安装了更多RAM,总共有240GB RAM。SQL Server服务是唯一可运行的东西。
内存在BIOS,OpenManage和Windows中显示正常。
如果我将SQL Server配置为使用最小/最大70 / 100GB内存,则没有问题。但是,一旦将其增加到120 / 150GB,则在运行我们的ETL进程之一时会出现以下错误:
无法为数据库“ tempdb”中的对象“ <临时系统对象:422234507706368>”分配空间,因为“ PRIMARY”文件组已满。通过删除不需要的文件,在文件组中删除对象,向文件组添加其他文件或为文件组中的现有文件设置自动增长来创建磁盘空间。(消息1105,状态2,过程未知,第1行)
在更改内存配置之前,我们从未遇到过此问题。重新配置回原始的70 / 100GB后,我们不会收到此错误。
我尝试过的事情:
- 将TempDB数据文件设置为自动增长。这只会导致文件自动增长,直到达到磁盘容量,然后失败。
- 添加更多的TempDB数据文件。与显示的错误相同。
- 将TempDB的大小增加到8x32GB(总共256GB)
我对可能导致此问题的原因不知所措。
2
您的内存在NUMA个节点之间是否平衡?你的处理器怎么样?SQL Server日志是否显示启动期间正在使用多少个CPU?
—
亚伦·伯特兰
您在ETL流程中使用什么?SSIS或类似的工具?如果它是SQL Server之外的工具,您是否在与SQL Server实例相同的服务器上运行它?
—
Mike Fal 2013年
@Mike很好,如果ETL进程无法捕获足够的内存来执行其任务,因为SQL Server使用过多,则可能必须将工作推送到tempdb。
—
亚伦·伯特兰
这是监视tempdb使用情况的一个很好的开始:msdn.microsoft.com/zh-cn/library/ms176029(v=SQL.105).aspx。这应该使您对正在发生的事情有所了解。
—
Thomas Stringer
在TempDB实际扩展时,您是否对实际运行的内容进行了任何分析?一个简单的sp_who2 / sp_whoisactive?在我看来,您有一些长期运行的事务可以更好地管理,但很难分辨。就个人而言,我不会继续关注内存更改,而是先查看代码,看看它是否运行正常。
—
Mike Fal 2013年