在SQL Server tempdb满时检查数据文件
作为一名数据库DBA，肯定会听说过“tempdb数据库满了”。通常我们很容易确定造成这一问题的原因。但是更多的时候这一问题主要源于一组请求，涉及到新代码部署或逐渐增加的数据。
“Tempdb满了”意味着什么?
当SQL Server tempdb满了时，上层管理常常需要决策、一些开发人员可能会推卸责任，就连高级DBA也害怕碰到这种情况。
和我告诉管理员的一样，首先经验的做法就是：保持冷静。不要让还没有公布的情况给其他方面造成压力，那样可能酿成更大的错误。
既然情况已经出现了，那我们就来解决问题。Tempdb数据库由两部分组成：一是原始文件组里的数据文件，二是tempdb日志文件。这两者都可能出错，但错误信息会告诉你哪一部分满了。首先我们一起看看数据文件部分。在以后的文章部分中再讲解日志文件。
我们怎么压缩源文件?
首先我们要了解一下确定是什么占用大部分空间的方法，哪一个服务器有我们处理的ID号(SPID)、请求是从哪一台主机上发出的。以下查询将返回数据库里占空间的前1000个SPID。记住这些返回的值为页码数。为此，我算了一下存储值(单位为MB)。同样，我们还要注意计数器是随着SPID的使用时间而逐渐积累的：
SELECT top 1000
s.host_name, su.[session_id], d.name [DBName], su.[database_id],
su.[user_objects_alloc_page_count] [Usr_Pg_Alloc], su.[user_objects_dealloc_page_count] [Usr_Pg_DeAlloc],
su.[internal_objects_alloc_page_count] [Int_Pg_Alloc], su.[internal_objects_dealloc_page_count] [Int_Pg_DeAlloc],
(su.[user_objects_alloc_page_count]*1.0/128) [Usr_Alloc_MB], (su.[user_objects_dealloc_page_count]*1.0/128)
[Usr_DeAlloc_MB],
(su.[internal_objects_alloc_page_count]*1.0/128) [Int_Alloc_MB], (su.[inte
rnal_objects_dealloc_page_count]*1.0/128)
[Int_DeAlloc_MB]
from [sys].[dm_db_session_space_usage] su
inner join sys.databases d on su.database_id = d.database_id
inner join sys.dm_exec_sessions s on su.session_id = s.session_id
where (su.user_objects_alloc_page_count > 0 or
su.internal_objects_alloc_page_count > 0)
order by case when su.user_objects_alloc_page_count > su.internal_objects_
alloc_page_count then
相关文档：
在使用sqlserver2005创建作业时，创建不了，提示
无法将类型为“Microsoft.SqlServer.Management.Smo.SimpleObjectKey”的对象强制转换为类型“Microsoft.SqlServer.Management.Smo.Agent.JobObjectKey”。 (Microsoft.SqlServer.Smo)
于是就google，百度了一下，好多文章和贴子说需要� ......
由于最近要用到打包SQL Server 2005 Express Edition ，由于在安装过程中需要设置很多东西。带来很多的不便，于是在网上和MSDN找了好久终于找到办法了 ^_^
我用的是批处理来实现的，好了直接贴代码
CLS
@ECHO OFF
ECHO.
ECH ......
依据csdn高手写的自己练习一下方便以后查找
--Creator:Gongl
--Date:2009-1-8
--sql server 2000
--学习行转列，为了进一步了解动态sql拼接（单双三引号）
--几种类型
--Numeric(10,2) 指字段是数字型,长度为10 小数为两位
--varchar和nvarchar的区别
--1.从存储方式上，nvarchar是按字符存储的，而 varchar是按字� ......
