求SQL数据库安装步骤教程

在使用 SQL Server 的过程中，用户遇到的最多的问题莫过于连接失败了。一般而言

，有以下两种连接 SQL Server 的方式，一是利用 SQL Server 自带的客户端工具，如企业管

理器、查询分析器、事务探查器等；二是利用用户自己开发的客户端程序，如ASP 脚本、VB程

序等，客户端程序中又是利用 ODBC 或者 OLE DB 等连接 SQL Server。下面，我们将就这两

一、客户端工具连接失败

在使用 SQL Server 自带的客户端工具（以企业管理器为例）连接 SQL Server时，

1、SQL Server 不存在或访问被拒绝

ConnectionOpen (Connect())

2、用户'sa'登录失败。原因：未与信任 SQL Server 连接相关联。

3、超时已过期。

下面我们依次介绍如何来解决这三个最常见的连接错误。

第一个错误"SQL Server 不存在或访问被拒绝"通常是最复杂的，错误发生的原因比

较多，需要检查的方面也比较多。一般说来，有以下几种可能性：

1、SQL Server名称或IP地址拼写有误；

2、服务器端网络配置有误；

3、客户端网络配置有误。

要解决这个问题，我们一般要遵循以下的步骤来一步步找出导致错误的原因。

首先，检查网络物理连接：

ping ＜服务器IP地址＞

或者

ping ＜服务器名称＞

如果 ping ＜服务器IP地址＞ 失败，说明物理连接有问题，这时候要检查硬件设备

，如网卡、HUB、路由器等。还有一种可能是由于客户端和服务器之间安装有防火墙软件造成

的，比如 ISA Server。防火墙软件可能会屏蔽对 ping、telnet 等的响应，因此在检查连接

问题的时候，我们要先把防火墙软件暂时关闭，或者打开所有被封闭的端口。

如果ping ＜服务器IP地址＞ 成功而 ping ＜服务器名称＞ 失败，则说明名字解析

有问题，这时候要检查 DNS 服务是否正常。有时候客户端和服务器不在同一个局域网里面，

这时候很可能无法直接使用服务器名称来标识该服务器，这时候我们可以使用HOSTS文件来进

1、使用记事本打开HOSTS文件（一般情况下位于C:WINNTsystem32driversetc）

2、添加一条IP地址与服务器名称的对应记录，如：

1721681024 myserver

也可以在 SQL Server 的客户端网络实用工具里面进行配置，后面会有详细说明。

其次，使用 telnet 命令检查SQL Server服务器工作状态：

telnet ＜服务器IP地址＞ 1433

如果命令执行成功，可以看到屏幕一闪之后光标在左上角不停闪动，这说明 SQL

Server 服务器工作正常，并且正在监听1433端口的 TCP/IP 连接；如果命令返回"无法打开

连接"的错误信息，则说明服务器端没有启动 SQL Server 服务，也可能服务器端没启用

TCP/IP 协议，或者服务器端没有在 SQL Server 默认的端口1433上监听。

接着，我们要到服务器上检查服务器端的网络配置，检查是否启用了命名管道，是否

启用了 TCP/IP 协议等等。我们可以利用 SQL Server 自带的服务器网络使用工具来进行检查

点击：程序 -＞ Microsoft SQL Server -＞ 服务器网络使用工具，打开该工具后看

到的画面如下图所示：

从这里我们可以看到服务器启用了哪些协议。一般而言，我们启用命名管道以及

点中 TCP/IP 协议，选择"属性"，我们可以来检查 SQK Server 服务默认端口的设置

，如下图所示：

一般而言，我们使用 SQL Server 默认的1433端口。如果选中"隐藏服务器"，则意味

着客户端无法通过枚举服务器来看到这台服务器，起到了保护的作用，但不影响连接。

检查完了服务器端的网络配置，接下来我们要到客户端检查客户端的网络配置。我们

同样可以利用 SQL Server 自带的客户端网络使用工具来进行检查，所不同的是这次是在客户

点击：程序 -＞ Microsoft SQL Server -＞ 客户端网络使用工具， 打开该工具后

看到的画面如下图所示：

从这里我们可以看到客户端启用了哪些协议。一般而言，我们同样需要启用命名管道

点击 TCP/IP 协议，选择"属性"，可以检查客户端默认连接端口的设置，如下图所示

。

该端口必须与服务器一致。

单击"别名"选项卡，还可以为服务器配置别名。服务器的别名是用来连接的名称，连

接参数中的服务器是真正的服务器名称，两者可以相同或不同。如下图中，我们可以使用

myserver来代替真正的服务器名称sql2kcn-02，并且使用网络库 Named Pipes。别名的设置与

使用HOSTS文件有相似之处。

通过以上几个方面的检查，错误 1 发生的原因基本上可以被排除。下面我们再详细

当用户尝试在查询分析器里面使用sa来连接SQL Server，或者在企业管理器里面使用

sa来新建一个SQL Server注册时，经常会遇到如图 2 所示的错误信息。该错误产生的原因是

由于SQL Server使用了"仅 Windows"的身份验证方式，因此用户无法使用SQL Server的登录帐

户（如 sa ）进行连接。解决方法如下所示：

1、 在服务器端使用企业管理器，并且选择"使用 Windows 身份验证"连接上 SQL

2、 展开"SQL Server组"，鼠标右键点击SQL Server服务器的名称，选择"属性"，再

3、 在"身份验证"下，选择"SQL Server和 Windows "。

4、 重新启动SQL Server服务。

在以上解决方法中，如果在第 1 步中使用"使用 Windows 身份验证"连接 SQL

Server 失败，那么我们将遇到一个两难的境地：首先，服务器只允许了 Windows 的身份验

证；其次，即使使用了 Windows 身份验证仍然无法连接上服务器。这种情形被形象地称之为

"自己把自己锁在了门外"，因为无论用何种方式，用户均无法使用进行连接。实际上，我们可

以通过修改一个注册表键值来将身份验证方式改为 SQL Server 和 Windows 混合验证，步骤

1、点击"开始"-"运行"，输入regedit，回车进入注册表编辑器；

2、依次展开注册表项，浏览到以下注册表键：

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSSQLServerMSSQLServer]

3、在屏幕右方找到名称"LoginMode"，双击编辑双字节值；

4、将原值从1改为2，点击"确定"；

5、关闭注册表编辑器；

6、重新启动SQL Server服务。

此时，用户可以成功地使用sa在企业管理器中新建SQL Server注册，但是仍然无法使

用Windows身份验证模式来连接SQL Server。这是因为在 SQL Server 中有两个缺省的登录帐

户：BUILTINAdministrators 以及 ＜机器名＞Administrator 被删除。要恢复这两个帐户

1、打开企业管理器，展开服务器组，然后展开服务器；

2、展开"安全性"，右击"登录"，然后单击"新建登录"；

3、在"名称"框中，输入 BUILTINAdministrators；

4、在"服务器角色"选项卡中，选择"System Administrators" ；

5、点击"确定"退出；

6、使用同样方法添加 ＜机器名＞Administrator 登录。

以下注册表键

HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSSQLServerMSSQLServerLoginMode

的值决定了SQL Server将采取何种身份验证模式。该值为1，表示使用Windows 身份

验证模式；该值为2，表示使用混合模式（Windows 身份验证和 SQL Server 身份验证）。

看完如何解决前两个错误的方法之后，让我们来看一下如图 3 所示的第三个错误。

如果遇到第三个错误，一般而言表示客户端已经找到了这台服务器，并且可以进行连

接，不过是由于连接的时间大于允许的时间而导致出错。这种情况一般会发生在当用户在

Internet上运行企业管理器来注册另外一台同样在Internet上的服务器，并且是慢速连接时，

有可能会导致以上的超时错误。有些情况下，由于局域网的网络问题，也会导致这样的错误。

要解决这样的错误，可以修改客户端的连接超时设置。默认情况下，通过企业管理器

注册另外一台SQL Server的超时设置是 4 秒，而查询分析器是 15 秒（这也是为什么在企业

1、在企业管理器中，选择菜单上的"工具"，再选择"选项"；

2、在d出的"SQL Server企业管理器属性"窗口中，点击"高级"选项卡；

3、在"连接设置"下的"登录超时（秒）"右边的框中输入一个比较大的数字，如 20

查询分析器中也可以在同样位置进行设置。

二、应用程序连接失败

以上的三种错误信息都是发生在 SQL Server 自带的客户端工具中，在应用程序中我

Microsoft OLE DB Provider for SQL Server (0x80004005)

[DBNETLIB][ConnectionOpen (Connect())]Specified SQL server not found

Microsoft OLE DB Provider for SQL Server (0x80004005)

用户 'sa' 登录失败。原因: 未与信任 SQL Server 连接相关联。

Microsoft OLE DB Provider for ODBC Drivers 错误 '80004005'

[Microsoft][ODBC SQL Server Driver]超时已过期

首先，让我们来详细看以下的示意图来了解一下使用 ODBC 和使用 OLE DB 连接

SQL Server 有什么不同之处。

从上图中，我们可以看出在实际使用中，应用程序创建和使用各种 ADO 对象，ADO

对象框架调用享用的 OLE DB 提供者。为了访问 SQL Server 数据库，OLE DB 提供了两种不

同的方法：用于 SQL Server 的 OLE DB 提供者以及用于 ODBC 的 OLE DB 提供者。这两种不

同的方法对应于两种不同的连接字符串，标准的连接字符串写法如下所示：

1、使用用于 SQL Server 的 OLE DB 提供者：

使用 SQL Server 身份验证：

oConnOpen "Provider=sqloledb;" & _

"Data Source=myServerName;" & _

"Initial Catalog=myDatabaseName;" & _

"User Id=myUsername;" & _

"Password=myPassword"

使用 Windows 身份验证（信任连接）：

oConnOpen "Provider=sqloledb;" & _

"Data Source=myServerName;" & _

"Initial Catalog=myDatabaseName;" & _

"Integrated Security=SSPI"

2、使用用于 ODBC 的 OLE DB 提供者（不使用 ODBC 数据源）：

使用 SQL Server 身份验证：

oConnOpen "Driver={SQL Server};" & _

"Server=MyServerName;" & _

"Database=myDatabaseName;" & _

"Uid=myUsername;" & _

"Pwd=myPassword"

使用 Windows 身份验证（信任连接）：

oConnOpen "Driver={SQL Server};" & _

"Server=MyServerName;" & _

"Database=myDatabaseName;" & _

"Trusted_Connection=yes"

3、使用用于 ODBC 的 OLE DB 提供者（使用 ODBC 数据源）：

oConnOpen "DSN=mySystemDSN;" & _

"Uid=myUsername;" & _

"Pwd=myPassword"

如果遇到连接失败的情况，我们只要按照一中所示的方法，结合程序中的连接字符串

进行检查，基本都能得到解决。另外，还有以下几个要注意的地方：

1、配置 ODBC 数据源时，点击"客户端"配置选项可以让我们指定连接使用的网络库

、端口号等属性，如下图所示：

2、如果遇到连接超时的错误，我们可以在程序中修改 Connection 对象的超时设置

＜%

Set Conn = ServerCreateObject("ADODBConnection")

DSNtest="DRIVER={SQL Server};SERVER=ServerName;UID=USER;PWD=pass

Conn Properties("Connect Timeout") = 15 '以秒为单位

Connopen DSNtest

%＞

3、如果遇到查询超时的错误，我们可以在程序中修改 Recordset 对象的超时设置

Dim cn As New ADODBConnection

Dim rs As ADODBRecordset

cmd1 = txtQueryText

Set rs = New ADODBRecordset

rsProperties("Command Time Out") = 300

'同样以秒为单位，如果设置为 0 表示无限制

rsOpen cmd1, cn

rsMoveFirst

三、小结

本文针对大部分用户在使用 SQL Server 过程中常见的连接失败的错误，重点讨论了

在使用 SQL Server 客户端工具以及用户开发的应用程序两种情况下，如何诊断并解决连接失

败的错误。看过本文以后，相信每一个读者都会对 SQL Server 的连接工作原理、身份验证方

式以及应用程序开发等有一个较为全面而深入的连接。本文中所有的测试或者示例均在

Windows 2000 Advanced Server + SQL Server 2000 企业版上通过

1停止SQL Server的服务,备份SQL Server安装目录下的\data子目录

下故障数据库的两个文件,一个数据文件hbposv6_branch_datamdf,

一个hbposv6_branch_logldf(也有可能非此命名),同时查看磁盘

空间是否有足够的空间；

2启动SQL Server服务(如已停止),创建一个新的数据库，命名为

原来数据库的名字。

3停止SQL Server

4把老数据库的MDF文件(hbposv6_branch_datamdf)替换

新数据库的相应的MDF文件，

并把LDF文件(hbposv6_branch_logldg)删除。

5重新启动SQL Server服务，然后运行如下命令：

Use Master

go

sp_configure 'allow updates', 1

reconfigure with override

go

begin tran

update sysdatabases set status = 32768 where name = 'hbposv6_branch'

--Verify one row is updated before committing

commit tran

go

6停止SQL然后重新启动SQL Server服务，然后运行如下命令

(更换日志文件路径地址)：

use master

go

DBCC TRACEON(3604)

DBCC REBUILD_LOG

('hbposv6_branch',

'c:\Program Files\Microsoft SQL Server\MSSQL\Data\hbposv6_branch_logldf')

--在这里，请输入你的数据库的路径

go

7停止SQL然后重新启动SQL Server服务，然后运行：

use master

go

update sysdatabases set status = 8 where name = 'hbposv6_branch'

go

sp_configure 'allow updates', 0

reconfigure with override

go

8运行dbcc checkdb(db_name) 检查数据库的完整性

9修复数库

--请在查询分析器中执行下列语句执行前断开其它

所有数据库连接，最好是断开网线

--如果不是该数据库名，请将数据库

--hbposv6_branch

--改为要修复的数据库

USE master

Go

--单用户模式

EXEC sp_dboption 'hbposv6_branch', 'single user', 'TRUE'

go

--数据库检查

DBCC CHECKDB ('hbposv6_branch')

Go

--如果返回结果出现了红色的提示文字，说明数据库中存在错误，需要修复

--数据库修复

DBCC CHECKDB ('hbposv6_branch','repair_rebuild')

Go

--再次数据库检查，如果返回结果中没有了红色的提示文字，

说明修复成功；

DBCC CHECKDB ('hbposv6_branch')

Go

--否则意味着还需要更高级别的修复；尝试将上面修复语句的

'repair_rebuild'换为'repair_allow_data_loss'再试，

之后再次检查数据库。

--如果还有错误未修复，请把这些信息以文字的方式发给我们

--退出前请一定要执行以下语句返回到多用户模式

EXEC sp_dboption 'hbposv6_branch', 'single user','FALSE'

go

注：都要把 dbname 替换成真实的数据库名字。

备份数据文件,然后按下面的步骤处理:

1新建一个同名的数据库(数据文件与原来的要一致)

2再停掉sql server(注意不要分离数据库)

3用原数据库的数据文件覆盖掉这个新建的数据库

4再重启sql server

5此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)

6完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用

数据库的脚本创建一个新的数据库,并将数据导进去就行了

USE MASTER

GO

SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE

GO

UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'

Go

sp_dboption '置疑的数据库名', 'single user', 'true'

Go

DBCC CHECKDB('置疑的数据库名')

Go

update sysdatabases set status =28 where name='置疑的数据库名'

Go

sp_configure 'allow updates', 0 reconfigure with override

Go

sp_dboption '置疑的数据库名', 'single user', 'false

假设数据库为TEST：

按以下步骤执行

A．设置数据库允许直接 *** 作系统表。此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。

use master

go

sp_configure 'allow updates',1

go

reconfigure with override

go

B．设置test为紧急修复模式

update sysdatabases set status=-32768 where dbid=DB_ID('test')

此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

C．下面执行真正的恢复 *** 作，重建数据库日志文件

dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_logldf')

执行过程中，如果遇到下列提示信息：

服务器: 消息 5030，级别 16，状态 1，行 1

未能排它地锁定数据库以执行该 *** 作。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。

正确执行完成的提示应该类似于：

警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

D．验证数据库一致性（可省略）

dbcc checkdb('test')

一般执行结果如下：

CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

E．设置数据库为正常状态

sp_dboption 'test','dbo use only','false'

如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

F．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接 *** 作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成

sp_configure 'allow updates',0

go

reconfigure with override

go

上面的语句 *** 作步骤有点问题：

应该如下：

A．我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。

B．停掉数据库服务器。

C．将刚才生成的数据库的日志文件test_logldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_datamdf。

D．启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何 *** 作。

E．设置数据库允许直接 *** 作系统表。此 *** 作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。

use master

go

sp_configure 'allow updates',1

go

reconfigure with override

go

F．设置test为紧急修复模式

update sysdatabases set status=-32768 where dbid=DB_ID('test')

此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表

G．下面执行真正的恢复 *** 作，重建数据库日志文件

dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_logldf')

执行过程中，如果遇到下列提示信息：

服务器: 消息 5030，级别 16，状态 1，行 1

未能排它地锁定数据库以执行该 *** 作。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。

正确执行完成的提示应该类似于：

警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

H．验证数据库一致性（可省略）

dbcc checkdb('test')

一般执行结果如下：

CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

I．设置数据库为正常状态

sp_dboption 'test','dbo use only','false'

如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

J．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接 *** 作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成

sp_configure 'allow updates',0

go

reconfigure with override

go

以上就是关于求SQL数据库安装步骤教程全部的内容，包括:求SQL数据库安装步骤教程、怎样修复已经损坏的SQL数据库、sql2000使用DBCC checkdb 检查出来的错误怎么解决等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！