如何使用SQL Server中的客户端配置工具

您当前所在位置：首页 → 数据库 → MSSQL → 如何使用SQL Server中的客户端配置工具

如何使用SQL Server中的客户端配置工具 时间：2015/6/28来源：绿色软件之家作者：网管联盟我要评论(0)

sql server 客户端配置工具用于配置客户端的工具(除基于DOS操作系统的客户端工具以外)，以便使它们可以成功地和SQL Server进行通信。这个程序应该在客户端工具装载之后运行。在大多数情况下，你并不需要运行这些程序，因为缺省的设置在大多数的网络配置下都能工作。但是，如果客户端软件不能和SQL Server进行通信，你可以使用这个工具来正确配置客户端软件，使之能够和SQL Server进行通信。

文章的内容分为四部分，第一部分描述了怎样启动客户端配置工具，其余三部分描述了配置工具的三个界面中提供的一些选项。

1. 怎样启动客户端配置工具

在大多数情况下，客户端配置工具和其他客户端工具一同被安装在你所使用的工作站上。如果你并没有安装这个工具但是现在又需要它，你就必须安装这个工具，接下来才能按照以下的步骤来启动这个程序。

1：如果你是在使用NT服务器或者工作站进行工作，应该使用具有管理员权限的帐号来登录。如果你是在使用Windows 95/98桌面操作系统，可以使用任何一个合法帐号来登录。

2：确定在启动配置工具之前没有其他程序在运行。如果有其他打开的程序，在继续下一步操作之前首先关闭它们。

3：单击"Start"按钮，单击"Programs"，再单击"Microsoft SQL Server"(包含该工具的程序组名)，单击"Client Configuration Utility"。

4：出现"SQL Server Client Configuration Utility"对话框。该对话框包括三个表单，这三个表单将三个主要的选项分离开了。

2. DB链接库配置

DB链接库表单的作用主要是用来确定是否客户端安装了最新版本的DB链接库。版本信息被显示在该界面的"Version Statistics"部分中。

你应该正在使用包含在SQL Server 6.5中的版本，如果曾经使用服务软件包或者其他的途径升级过这些文件，那么就应该正在使用更新的版本。

如果当前使用的客户端以前从未安装过任何版本的客户端工具，那么在这个客户端上应该只有由本次安装客户端工具确定的唯一的客户端工具版本。如果在这个工作站上存在旧版本的DB链接库文件，那么应该将这些文件删除，以免它们和新版本的文件有冲突。这种情况会在不同版本的文件安装在不同目录下的情况下发生。

如果你正在负责一个基于SQL Server的项目，或者你刚刚接触SQL Server，你都有可能要面临一些数据库性能的问题，这篇文章会为你提供一些有用的指导(其中大多数也可以用于其它的DBMS)。

在这里，我不打算介绍使用SQL Server的窍门，也不能提供一个包治百病的方案，我所做的是总结一些经验----关于如何形成一个好的设计。这些经验来自我过去几年中经受的教训，一直来，我看到许多同样的设计错误被一次又一次的重复。

你了解工具吗?

不要轻视这一点，这是我在这篇文章中讲述的最关键的一条。也许你也看到有很多的SQL Server程序员没有掌握全部的T-SQL命令和SQL Server提供的那些有用的工具。

"什么?我要浪费一个月的时间来学习那些我永远也不会用到的SQL命令???"，你也许会这样说。对的，你不需要这样做。但是你应该用一个周末浏览所有的T-SQL命令。在这里，你的任务是了解，将来，当你设计一个查询时，你会记起来："对了，这里有一个命令可以完全实现我需要的功能"，于是，到MSDN查看这个命令的确切语法。

不要使用光标

让我再重复一遍：不要使用光标。如果你想破坏整个系统的性能的话，它们倒是你最有效的首选办法。大多数的初学者都使用光标，而没有意识到它们对性能造成的影响。它们占用内存，还用它们那些不可思议的方式锁定表，另外，它们简直就像蜗牛。而最糟糕的是，它们可以使你的DBA所能做的一切性能优化等于没做。不知你是否知道每执行一次FetcH就等于执行一次SELECT命令?这意味着如果你的光标有10000条记录，它将执行10000次SELECT!如果你使用一组SELECT、UPDATE或者DELETE来完成相应的工作，那将有效率的多。

初学者一般认为使用光标是一种比较熟悉和舒适的编程方式，可很不幸，这会导致糟糕的性能。显然，SQL的总体目的是你要实现什么，而不是怎样实现。

我曾经用T-SQL重写了一个基于光标的存储过程，那个表只有100,000条记录，原来的存储过程用了40分钟才执行完毕，而新的存储过程只用了10秒钟。在这里，我想你应该可以看到一个不称职的程序员究竟在干了什么!!!

我们可以写一个小程序来取得和处理数据并且更新数据库，这样做有时会更有效。记住：对于循环，T-SQL无能为力。

我再重新提醒一下：使用光标没有好处。除了DBA的工作外，我从来没有看到过使用光标可以有效的完成任何工作。

规范化你的资料表

为什么不规范化数据库?大概有两个借口：出于性能的考虑和纯粹因为懒惰。至于第二点，你迟早得为此付出代价。而关于性能的问题，你不需要优化根本就不慢的东西。我经常看到一些程序员"反规范化"数据库，他们的理由是"原来的设计太慢了"，可结果却常常是他们让系统更慢了。DBMS被设计用来处理规范数据库的，因此，记住：按照规范化的要求设计数据库。

不要使用SELECT *

这点不太容易做到，我太了解了，因为我自己就经常这样干。可是，如果在SELECT中指定你所需要的列，那将会带来以下的好处：

1 减少内存耗费和网络的带宽

2 你可以得到更安全的设计

3 给查询优化器机会从索引读取所有需要的列

了解你将要对数据进行的操作

为你的数据库创建一个健壮的索引，那可是功德一件。可要做到这一点简直就是一门艺术。每当你为一个表添加一个索引，SELECT会更快了，可INSERT和DELETE却大大的变慢了，因为创建了维护索引需要许多额外的工作。显然，这里问题的关键是：你要对这张表进行什么样的操作。这个问题不太好把握，特别是涉及DELETE和UPDATE时，因为这些语句经常在WHERE部分包含SELECT命令。

不要给"性别"列创建索引

首先，我们必须了解索引是如何加速对表的访问的。你可以将索引理解为基于一定的标准上对表进行划分的一种方式。如果你给类似于"性别"这样的列创建了一个索引，你仅仅是将表划分为两部分：男和女。你在处理一个有1,000,000条记录的表，这样的划分有什么意义?记住：维护索引是比较费时的。当你设计索引时，请遵循这样的规则：根据列可能包含不同内容的数目从多到少排列，比如：姓名+省份+性别。

使用事务

请使用事务，特别是当查询比较耗时。如果系统出现问题，这样做会救你一命的。一般有些经验的程序员都有体会-----你经常会碰到一些不可预料的情况会导致存储过程崩溃。

小心死锁

按照一定的次序来访问你的表。如果你先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果你(不经意的)某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。如果锁定顺序没有被预先详细的设计好，死锁是不太容易被发现的。

不要打开大的资料集

在技术论坛中，一个经常被提出的问题是：我怎样才能迅速的将100000条记录添加到ComboBox中?这是不对的，你不能也不需要这样做。很简单，你的用户要浏览100000条记录才能找到需要的记录，他一定会诅咒你的。在这里，你需要的是一个更好的UI，你需要为你的用户显示不超过100或200条记录。

不要使用服务器端光标

与服务器端光标比起来，客户端光标可以减少服务器和网络的系统开销，并且还减少锁定时间。

使用参数查询

有时，我在技术论坛看到类似这样的问题："SELECT * FROM a WHERE a.id='A'B，因为单引号查询发生异常，我该怎么办?"，而普遍的回答是：用两个单引号代替单引号。这是错误的。这样治标不治本，因为你还会在其它一些字符上遇到这样的问题，更何况这样会导致严重的bug，除此以外，这样做还会使SQL Server的缓冲系统无法发挥应有的作用。使用参数查询，釜底抽薪，这些问题统统不存在了。

在程序编码时使用大数据量的数据库

程序员在开发中使用的测试数据库一般数据量都不大，可经常的是最终用户的数据量都很大。我们通常的做法是不对的，原因很简单：现在硬盘不是很贵，可为什么性能问题却要等到已经无可挽回的时候才被注意呢?

不要使用INSERT导入大批的数据

请不要这样做，除非那是必须的。使用UTS或者BCP，这样你可以一举而兼得灵活性和速度。

注意超时问题

查询数据库时，一般数据库的缺省都比较小，比如15秒或者30秒。而有些查询运行时间要比这长，特别是当数据库的数据量不断变大时。

不要忽略同时修改同一记录的问题

有时候，两个用户会同时修改同一记录，这样，后一个修改者修改了前一个修改者的操作，某些更新就会丢失。处理这种情况不是很难：创建一个timestamp字段，在写入前检查它，如果允许，就合并修改，如果存在冲突，提示用户。

在细节表中插入纪录时，不要在主表执行SELECT MAX(ID)

这是一个普遍的错误，当两个用户在同一时间插入数据时，这会导致错误。你可以使用SCOPE_IDENTITY，IDENT_CURRENT和@@IDENTITY。如果可能，不要使用@@IDENTITY，因为在有触发器的情况下，它会引起一些问题(详见这里的讨论)。

避免将列设为NULLable

如果可能的话，你应该避免将列设为NULLable。系统会为NULLable列的每一行分配一个额外的字节，查询时会带来更多的系统开销。另外，将列设为NULLable使编码变得复杂，因为每一次访问这些列时都必须先进行检查。

我并不是说NULLS是麻烦的根源，尽管有些人这样认为。我认为如果你的业务规则中允许"空数据"，那么，将列设为NULLable有时会发挥很好的作用，但是，如果在

关键词标签：SQL Server

相关阅读

文章评论

查看所有0条评论>>