如何设置SQL Server数据库服务器的身份验证模式

下文就为您介绍如何修改SQL Server身份验证模式，以及修改SQL Server 2000系统管理员Sa的登录密码的方法，希望对您能有所帮助。

下面以 *** 作系统Windows 2000上的SQL Server 2000为例，对误将SQL Server身份验证模式选择为“windows身份验证模式”的数据库进行修改， *** 作步骤为：

1． 打开企业管理器，依次展开服务器组，用右键单击软件使用的服务器。

2． 在d出的快捷菜单，执行“属性”命令，出现“SQL Server属性”对话框。如所示。单击“安全性”标签，在“安全性”选项框中，将“仅Windows”改为“SQL Server和Windows”身份验证。

3． 设置完成后，单击“确定”按钮，系统提示重新启动服务器。

4． 单击“是”按钮，完成对SQL Server身份验证模式的修改。

说明：在 Windows XP *** 作系统与Windows 2000 *** 作系统下修改SQL Server 2000身份验证模式相同，但在Windows 98 *** 作系统下，却不能通过以上方法对身份验证模式进行修改。因为在Windows 98 *** 作系统下，安装SQL Server 2000时，系统只支持“混合模式”身份验证模式。

如何修改SQL Server 2000系统管理员Sa的登录密码

分析：SQL Server 2000系统管理员Sa的登录密码，一般在安装SQL Server 2000时就已经设置。在数据库管理系统中，用检查口令等手段来检查用户身份，合法的用户才能进入数据库系统。千方百剂系列需要通过验证Sa登录密码才能创建、删除账套，这样Sa的登录密码在此就显得尤为重要。

*** 作步骤如下：

1． 打开企业管理器，依次展开服务器组，然后展开服务器。

2． 打开“安全性”文件夹，单击“登录”，然后用右键单击“Sa”，执行“属性”命令。

3． d出“SQL Server登录属性”对话框，如所示。在“SQL Server身份验证”密码栏，输入最新密码。

4． 单击“确定”按钮，d出“确认密码”对话框，再输一遍登录密码。

5． 单击“确定”按钮，完成对Sa登录密码的修改。

无法打开用户默认数据库，登录失败,这也是SQL Server使用者常见的问题之一。在使用企业管理器、查询分析器、各类工具和应用软件的时候，只要关系到连接SQL Server数据库的时候，都有可能会碰到此问题。

一、原因

登录帐户的默认数据库被删除。

二、解决方法：

(一)、使用管理员帐户修改此帐户的默认数据库

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

2. 展开"安全性",展开登录，右击相应的登录帐户，从d出的菜单中选择，属性

3、重新选择此登录帐户的默认数据库

(二)、若没有其他管理员登录帐户，无法在企业管理器里修改，使用isql命令行工具

isql /U"sa" /P"sa的密码" /d"master" /Q"exec sp_defaultdb N'sa', N'master'"

如果使用Windows验证方式，使用如下命令行，将默认数据库改成非丢失的数据库：

isql /E /d"master" /Q"exec sp_defaultdb N'BUILTIN\Administrators', N'master'"

在MySQL中创建一个Schema好像就跟创建一个Database是一样的效果，在SQL Server和Orcal数据库中好像又不一样. 目前我只能理解，在mysql中 schema<==>database。

数据库中User和Schema的关系

假如我们想了解数据库中的User和Schema究竟是什么关系，首先必须了解一下数据库中User和Schema到底是什么概念。

在SQL Server2000中，由于架构的原因，User和Schema总有一层隐含的关系，让我们很少意识到其实User和Schema是两种完全不同的概念，不过在SQL Server2005中这种架构被打破了，User和Schema也被分开了。

　

　首先我来做一个比喻，什么是Database，什么是Schema，什么是Table，什么是列，什么是行，什么是User？我们可以可以把

Database看作是一个大仓库，仓库分了很多很多的房间，Schema就是其中的房间，一个Schema代表一个房间，Table可以看作是每个

Schema中的床，Table（床）就被放入每个房间中，不能放置在房间之外，那岂不是晚上睡觉无家可归了J。，然后床上可以放置很多物品，就好比

Table上可以放置很多列和行一样，数据库中存储数据的基本单元是Table，现实中每个仓库放置物品的基本单位就是床，

User就是每个Schema的主人，（所以Schema包含的是Object，而不是User），其实User是对应与数据库的（即User是每个对应

数据库的主人），既然有 *** 作数据库（仓库）的权利，就肯定有 *** 作数据库中每个Schema（房间）的权利，就是说每个数据库映射的User有每个

Schema（房间）的钥匙，换句话说，如果他是某个仓库的主人，那么这个仓库的使用权和仓库中的所有东西都是他的（包括房间），他有完全的 *** 作权，可以

扔掉不用的东西从每个房间，也可以放置一些有用的东西到某一个房间，呵呵，和现实也太相似了吧。我还可以给User分配具体的权限，也就是他到某一个房间

能做些什么，是只能看（Read-Only），还是可以像主人一样有所有的控制权（R/W），这个就要看这个User所对应的角色Role了，至于分配权

限的问题，我留在以后单独的blog中详述。比喻到这里，相信大家都清楚了吧。

在SQL Server2000中，假如我们在某一个数据库中创建了用户Bosco，按么此时后台也为我们默认地创建了默认Schema 【Bosco】。Schema的名字和User的名字相同，这也是我们分不清楚用户和Schema的原因。

　

　在SQL Server2005中，为了向后兼容，当你用sp_adduser 存储过程创建一个用户的时候，SQL

Server2005同时也创建了一个和用户名相同的Schema，然而这个存储过程是为了向后兼容才保留的，我们应该逐渐熟悉用新的DDL语言

Create User和Create Schema来 *** 作数据库。在SQL Server2005中，当我们用Create

User创建数据库用户时，我们可以为该用户指定一个已经存在的Schema作为默认Schema，如果我们不指定，则该用户所默认的Schema即为

dbo Schema，dbo

房间（Schema）好比一个大的公共房间，在当前登录用户没有默认Schema的前提下，如果你在大仓库中进行一些 *** 作，比如Create

Tabe，如果没有指定特定的房间（Schema），那么你的物品就只好放进公共的dbo房间（Schema）了。但是如果当前登录用户有默认的

Schema，那么所做的一切 *** 作都是在默认Schema上进行（比如当前登录用户为login1，该用户的默认Schema为login1，那么所做的

所有 *** 作都是在这个login1默认Schema上进行的。实验已经证明的确如此）。估计此时你会有一点晕，为什么呢？我刚才说dbo是一个

Schema，但是你可以在数据库中查看到，dbo同时也是一个user，晕了吧，呵呵。

在SQL Server2005中创建一个数据库的时候，会有一些Schema包括进去，被包括进去的Schema有：dbo，INFORMATION_SCHEMA, guest，sys等等（还有一些角色Schema，不提了，有晕了）。

　

　我在上文中已经提到了，在SQL Server2005中当用存储过程sp_adduser创建一个user时，同时SQL

Server2005也为我们创建了一个默认的和用户名相同的Schema，这个时候问题出来了，当我们create table

A时，如果没有特定的Schema做前缀，这个A表创建在了哪个Schema上，即进入了哪个房间？答案是：

1.如果当前 *** 作数据库的用户（可以用Select current_user查出来）有默认的Schema（在创建用户的时候指定了），那么表A被创建在了默认的Schema上。

　

　2.如果当前 *** 作数据库的用户没有默认的Schema（即在创建User的时候默认为空），但是有一个和用户名同名的Schema，那么表A照样被创建

在了dbo

Schema上，即使有一个和用户名同名的Schema存在，由于它不是该用户默认的Schema，所以创建表的时候是不会考虑的，当作一般的

Schema来处理，别看名字相同，可是没有任何关系哦。

3.如果在创建表A的时候指定了特定的Schema做前缀，则表A被创建在了指定的 Schema上（有权限吗？）

　

　现在问题又出来了，在当前 *** 作数据库的用户（用select

current_user可以查看到，再次强调）没有默认Schema的前提下，当我们用Create table A语句时，A表会去寻找dbo

Schema，并试图创建在dbo Schema上，但是如果创建A表的用户只有对dbo

Schema的只读权限，而没有写的权限呢？这个时候A表既不是建立不成功，这个就是我以后会提及到的Login,User,

Role和Schema四者之间的关系。在这里，为了避免混淆和提高 *** 作数据库的速度（在少量数据范围内，对我们肉眼来说几乎看不到差异），我们最好每次

在 *** 作数据库对象的时候都显式地指定特定的Schema最为前缀。

现在如果登录的用户为Sue，该用户有一个默认Schema也为Sue，那么如果现在有一条查询语句为Select * from mytable, 那么搜寻每个房间（Schema）的顺序是怎样的呢？顺序如下：

1. 首先搜寻sys.mytable （Sys Schema）

2. 然后搜寻Sue.mytable (Default Schema)

3. 最后搜寻 dbo.mytable (Dbo Schema)

执行的顺序大家既然清楚了，那么以后在查询数据库表中的数据时，最好指定特定的Schema前缀，这样子，数据库就不用去扫描Sys Schem

---