Questions tagged «tempdb»

TempDB是MS SQL Server的一部分。它是一个系统数据库,用作临时表,内部对象和行版本的存储区。

3
由于varchar(max),将溢出溢出排序到tempdb
在具有32GB的服务器上,我们正在运行SQL Server 2014 SP2,最大内存为25GB,我们有两个表,在这里您可以找到两个表的简化结构: CREATE TABLE [dbo].[Settings]( [id] [int] IDENTITY(1,1) NOT NULL, [resourceId] [int] NULL, [typeID] [int] NULL, [remark] [varchar](max) NULL, CONSTRAINT [PK_Settings] PRIMARY KEY CLUSTERED ([id] ASC) ) ON [PRIMARY] GO CREATE TABLE [dbo].[Resources]( [id] [int] IDENTITY(1,1) NOT NULL, [resourceUID] [int] NULL, CONSTRAINT [PK_Resources] PRIMARY KEY CLUSTERED ([id] ASC) …

1
哈希/排序溢出到tempdb中的频率是多少?
我们的企业应用程序使用SQL Server进行数据存储,并且主要是OLTP系统。但是,我们应用程序的重要组成部分会产生大量的OLAP工作负载。 我们对tempdb的写入延迟约为100毫秒。这种趋势发展随着时间的推移,和ALLOW_SNAPSHOT_ISOLATION关断。我们正在对有关此问题的问题进行故障排除,到目前为止,我们发现的唯一有趣的事情是,有大量散列和排序溢出到tempdb。我们推测这是来自我们的OLAP工作负载。 题 涉及什么频率的泄漏?任何?每秒多少溢出?我们的初步数据表明,每秒大约有2次哈希溢出,每分钟大约25次分类溢出。 这种溢出的频率是否可能成为我们高tempdb写延迟的主要原因? 其他资讯 根据内核数的建议,我们正在为tempdb使用多个文件。tempdb文件位于RAID 1 + 0 SAN(具有高性能SSD)上,但与主DB数据和日志文件位于同一设备上。tempdb文件的大小足够大,以至于它们很少增长。我们没有使用跟踪标志1117或1118。另一个变量是,此设置被许多不同的数据库共享,这些数据库都承受着中到高负载。 我们的100 ms写延迟远远大于我们在MSDN,SQL Skills和其他站点上找到的tempdb写延迟可接受的范围。但是,其他数据库的写入延迟很好(小于10ms)。基于其他统计数据,看来我们在大量使用tempdb,尤其是对于内部对象。因此,我们正在深入研究以找出为什么我们的应用程序如此大量地使用内部对象。 我们的平台上确实存在实际性能问题,这些问题以不同的方式体现出来。我们一直在监视性能计数器,查看DM视图,并分析我们的应用程序行为,以尝试挖掘系统的资源使用特征。我们现在专注于溢出,因为我们已经了解到溢出具有严重的负面影响,因为它们是在磁盘上而不是在内存中执行的。而且我们似乎有大量的泄漏事件,但是我想就人们认为“高泄漏”的问题征求一些意见。

4
TempDB上的DDL争用
我有一个SQL Server 2005 Standard x64,在过去的几个月中,TempDB DDL争用一直遇到问题。服务器将在等待资源2:1:103(等待类型为PAGELATCH_EX)上发生争用。 当服务器处于正常负载时,该问题似乎偶尔发生。我一直在监视“销毁临时表”的速率,在我们在2:1:103遇到PAGELATCH_EX问题时,它的速率可能会跳到5,000+。根据我的阅读,该计数器在大多数情况下应该为0,但在大多数情况下,我们的计数器似乎保持在300-1100之间。仅当系统上用户很少时,计数器才会变为0。 我如何缩小在tempdb上导致DDL争用的原因,而不必在干草堆中寻找针头?

2
TempDB不会收缩。没有公开交易
我在SQL 2008上有一个TempDB,它已经变得很大(> 40gb),我想缩小它。我已经通过Management Studio使用了dbcc收缩数据库,dbcc收缩文件和收缩命令。 我收到以下错误: 页面1:4573184无法移动,因为它是工作表页面。 我已经能够通过运行DBCC FREEPROCCACHE并重新运行其中一个收缩例程来回收一些空间,使我摆脱危险,但是显然这不是理想的选择,可能只会给我带来一点时间。 我已经运行过DBCC OpenTran,那里没有东西挂。 我在Internet上阅读的所有内容都归结为回收SQL Server ...肯定有更好的方法...有人吗? 谢谢, 汤姆

3
TempDB中损坏的分区如何导致DBCC CHECKDB报告没有问题?
我们的SQL Server之一最近报告了以下错误: DATE/TIME: 2/25/2013 9:15:14 PM DESCRIPTION: No catalog entry found for partition ID 9079262474267394048 in database 2. The metadata is inconsistent. Run DBCC CHECKDB to check for a metadata corruption. 不到15分钟后,我连接到服务器并运行: SELECT name FROM sys.databases WHERE database_id = 2; 哪个返回'tempdb'。然后我跑了: DBCC CHECKDB ('tempdb') WITH NO_INFOMSGS, TABLERESULTS; 其中未返回任何结果,表明受影响的数据库没有问题。 数据库中的损坏如何导致上面的错误消息而又DBCC CHECKDB未报告问题?我假设页面校验和计算失败,导致该页面被标记为怀疑无法引用该页面的任何对象,但是我一定是错误的。 …

1
SELECT INTO是否在运行时之前在TempDB中保留#Object名称?
汇集了一个快速处理程序以帮助调试,我遇到了编译器中似乎是错误的错误。 create proc spFoo @param bit as begin if @param = 0 begin select * into #bar from [master].dbo.spt_values -- where number between ... end else begin select top 10 * into #bar from [master].dbo.spt_values order by newid(); end; end; 尝试执行上述操作会返回以下错误 消息2714,级别16,状态1,过程spFoo,第19 行在数据库中已经有一个名为“ #bar”的对象。 在人类可读的意义上,该proc似乎很好:select into因为它们被包装在if-else块中,所以仅将执行一条语句。但是,非常好,SQL Server无法确认这些语句在逻辑上相互排斥。也许更令人困惑的是,将drop table #fooif放置在if-else块内时(如果假定它将告诉编译器取消分配对象名),错误仍然存​​在,如下所示。 create …

1
每秒非常高的交易
我们的生产服务器平均每秒运行4,000个事务。在过去几天中,平均数量已跃升至每秒175,000个事务。那不是打字错误,是每秒175K。 在查看交易的DMV时,我们无法将其直接链接到用户会话,但是我们看到了: SELECT NAME, COUNT(*) FROM sys.dm_tran_active_transactions GROUP BY NAME ORDER BY 2 DESC - +------------------------------+-------+ | Name | Count | +------------------------------+-------+ | WorkFileGroup_fake_worktable | 627 | | LobStorageProviderSession | 217 | | workfile | 171 | +------------------------------+-------+ 谁能阐明这些类型的交易?还是我在这里追鬼?

3
当使用sp_MSForEachDB遍历数据库时,IF语句不跳过TempDB
[SQL Server 2012 SP2 EE] 为什么以下脚本给我一个与tempdb有关的错误? exec sp_MSForEachDB ' IF ( (select database_id from sys.databases where name = ''?'') > 4) BEGIN ALTER AUTHORIZATION ON DATABASE::? TO [sa]; ALTER DATABASE [?] SET RECOVERY SIMPLE; END' 这是我得到的错误: Msg 5058, Level 16, State 1, Line 5 Option 'RECOVERY' cannot be set in …

2
tempdb位置损坏,无法恢复
犯了一个错误,并为tempdb输入了一个alter database命令。 现在该实例将无法启动。我无法使用-m在单用户模式下启动,因为它指出找不到tempdb。我尝试使用: net start msqsqlserver /f /t3608 但是,我实际上根本无法使用sqlcmd或连接到实例ssms。

2
将TempDB拆分为多个文件,这些文件等于CPU的数量
《SQL Server tempdb最佳实践提高性能》一文建议,我应该将tempdb文件分割成与内核数相等的数量。因此,对于4个内核,您将获得4个文件。 通过拥有更多的文件,可以增加SQL Server一次可以推送到磁盘的物理I / O操作的数量。SQL Server可以将其下推到磁盘级别的I / O越多,数据库将运行得越快。使用标准数据库,SQL Server可以将所需的大量数据缓存到内存中。由于tempdb具有高写入特性,因此需要先将数据写入磁盘,然后才能将其缓存回内存。 尽管从理论上讲听起来不错,但总体上来说它真的那么好吗?它仅适用于IO非常高的特定系统吗?
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.