使用 SET NOCOUNT ON
默认情况下，存储过程将返回过程中每个语句影响的行数。如果不需要在应用程序中使用该信息（大多数应用程序并不需要），请在存储过程中使用 SET NOCOUNT ON 语句以终止该行为。根据存储过程中包含的影响行的语句的数量，这将删除客户端和服务器之间的一个或多个往返过程。尽管这不是大问题，但它可以为高流量应用程序的性能产生负面影响。
create procedure test_MyStoredProc @param1 int
as
set nocount on
曾因工作的原因，在别人的督促之下，试了SQL 7同ORACLE联接，在SQL7中直接访问ORACLE的数据库方法，下面将该方法简单说一下。
当时用的是LINKED SERVER直接联接对方数据库。
一、先在SQL服务器装上ORACLE的客户端，并设置好
二、然后打开ENTERPRISE MANGER，与昨天相同的方法进到添加LINKED SERVER窗口
三、在LINKED SERVER框输入要使用的服务器名，服务器名允许按命名规则任意命名，但不能与已有的REMOTE SERVER或LINKED SERVER重名。
四、在SERVER区选中“OTHER DATA SOURCE”
五、Provider name选择“Microsoft OLE DB Provider for Oracle”
六、在Product name处输入“Oracle”
七、在Data source处输入在Oracle客户端程序中设置的服务器名
八、在Provider处输入“MSDAORA” 注：用ORACLE就是这个，不能改
九、在Server opentions区选择“RPC”和“RPC OUT”
十、再切换到安全（Security），根据实际设置。
（我都是选择“THEY WILL BE MAPPED TO”，然后输入帐号和口令）
十一、单击确定完成设置
我按这个步骤设置成功，但因时间和条件的问题，一直没再继续试其它的设置，如果各位那位有这样的条件的话，请再试一下其它的选项，看有什么不同，试完希望能将步骤和结果给我发一份。
另需说明的是，这种的联接的稳定性还是可以的，在设好以后的一年中，只因为对方服务器出问题重设了一次，还有一次是ORACLE的客户端被管理员不小心删了个文件，又重设了一次，然后一直没出问题，并且速度也还可以，一个过程，在ORACLE客户端执行需要0.1秒钟，通过LINKED SERVER执行需要0.2秒钟左右。
明天给大家写一下上面同样的设置用SQL7的系统过程设置的方法。
以上在UNIX ORACLE7和NT4 SP5 SQL7上测试成功。
有时候程序处理的数据量比较小时，四平八稳，一切安然无恙，但数据量一大，原先潜伏的问题就暴露无遗了。
原访问数据库的代码为：
1SqlConnection conn = new SqlConnection(strConn);
2conn.Open();
3SqlTransaction trans = conn.BeginTransaction();
4try
5{
6 CEngine.ExecuteNonQuery(trans,CommandType.Text,sql);
7 trans.Commit();
8}
9catch(SqlException ex)
10{
11 trans.Rollback();
12 ErrorCode = ex.Number;
13 Info = "数据操作失败：" ex.Message;
14}
15finally
16{
17 trans.Dispose();
18 conn.Close();
19}
20
21
22
运行时，一旦出现数据量过大或者处理时间较长，则系统会提示出错。错误提示为“SqlTransaction已经用完；它再也不能使用。”
开始时，我怀疑是跟内存有关。因为系统需要做好事务回滚的准备，每执行一条插入或修改的SQL，都要有一定的开销，数据量一大，恐怕就吃不消了。不过我查了一下SQL SERVER的资料，未见提到内存的问题。
后来想到，数据库连接SqlTransaction有个时间问题。默认是15秒。数据量大的时候，这个时间很可能就不够了。于是改为：
1SqlConnection conn = new SqlConnection(strConn);
2conn.Open();
3SqlTransaction trans = conn.BeginTransaction();
4try
5{
6 SqlCommand cmd = new SqlCommand();
7 cmd.CommandType = CommandType.Text;
8 //连接时限改为300秒
9 cmd.CommandTimeout = 300;
10 cmd.CommandText = sql;
11 cmd.Connection = conn;
12 cmd.Transaction = trans;
13 cmd.ExecuteNonQuery();
14 trans.Commit();
15}
16catch(SqlException ex)
17{
18 trans.Rollback();
19 ErrorCode = ex.Number;
20 Info = "数据操作失败：" ex.Message;
21}
22finally
23{
24 trans.Dispose();
25 conn.Close();
26}
修改后在测试，问题解决：）
最近有个朋友问我，他说他在SQLSERVER删除几百万到几千万数据是显的很慢，帮他分析了一下，提了一些以下意见，或许对很多人有用，再者也好长没写过BLOG了，一起探讨一下
如果你的硬盘空间小，并且不想设置数据库的日志为最小(因为希望其他正常的日志希望仍然记录)，而且对速度要求比较高，并清除所有的数据建议你用turncate table1,因为truncate 是DDL操作，不产生rollback，不写日志速度快一些，然后如果有自增的话，恢复到1开始，而delete会产生rollback，如果删除大数据量的表速度会很慢，同时会占用很多的rollback segments，同时还要记录下G级别的日志 ；当然如果有条件删除比如where time<'2006-3-10' 怎么办，能不能不记录日志用delete，回答是不行的，SQL Server 引擎在设计上就会对 Delete 操作进行日志记录。至今没有办法强制制定某一些语句不记录到日志中，如果在执行 Delete Table1 where Time < '2006-3-10' 由于涉及的记录比较多,所以日志记录也相应很大(3-4G),如果可行,我建议用以下方式：
选出您所需要保留的记录到新的表。如果您使用 Full Recovery Mode
根据SELECT INTO的记录数,日志可能会比较大
Select * into Table2 From Table1 Where Time > = '2006-03-10'
然后直接Truncate Table1。无论何种恢复模式都不会进行日志记录
Truncate table Table1
最后对Table2进行改名为Table1
EC sp_rename 'Table2', 'Table1'
出处：BLOG:domino的专栏
当您怀疑计算机硬件是影响SQL Server运行性能的主要原因时，可以通过SQL Server Performance Monitor监视相应硬件的负载，以证实您的猜测并找出系统瓶颈。下文将介绍一些常用的分析对象及其参数。
Memory: Page Faults / sec
如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。
Process: Working Set
SQL Server的该参数应该非常接近分配给SQL Server的内存值。在SQL Server设定中，如果将"set working set size"置为0, 则Windows NT会决定SQL Server的工作集的大小。如果将"set working set size"置为1，则强制工作集大小为SQLServer的分配内存大小。一般情况下，最好不要改变"set working set size"的缺省值。
Process:%Processor Time
如果该参数值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
Processor:%Privileged Time
如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。
Processor:%User Time
表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
Physical Disk:Avg.Disk Queue Length
该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。
注意:一个Raid Disk实际有多个磁盘。
SQLServer:Cache Hit Ratio
该值越高越好。如果持续低于80%，应考虑增加内存。
注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。