SQL2005 分五个版本，如下所列：
1.Enterprise(企业版)
2.Development(开发版)
3.Workgroup,(工作群版)
4.Standard,(标准版)
5.Express.(嗯，姑且就叫它简易版吧)
这几个版本，我们究竟应该使用哪一版呢？这是许多初学 SQL2005 的人最常问的问题。
简单的比较一下 Enterprise, Development 和 Express 等三个版本:以功能言，Enterprise 版和 Development 版的功能一模一样。两者的差别，除了授权不同外，最主要的差别是:
Enterprise 版的数据库引擎只能安装在 Win2003Server(或其他Server)。
如果你想安装在 WindowsXP Pro 系统上，你应该安装 SQL2005 Development 版(开发版)。
注:有人问，什么是「数据库引擎」。嗯，数据库引擎是SQL2005的核心，是最主要的数据库管理功能模块。没有它，就不是数据库管理系统了。
很多人下载 SQL2005 Express 版，因为它是免费的，可以直接从微软网站上下载。但是，它除了支持的内存比较少外，最主要的是它缺少相当于 SQL2000 下的「企业管理器」和「查询分析器」。
注: SQL2000 下的「企业管理器」和「查询分析器」在 SQL2005 已合为一，称为 Management Studio。
因此，如果你是初学者，如果你只是想要在家里学习学习，如果你的环境是 WindowsXP Pro，那么，你应该选择的是 SQL2005 Development(开发版)，而不是 SQL2005 Enterprise (企业版)或SQL2005 Express(简易版)。

其实二者没有什么可比性，但是对于不包含聚集函数的GROUP BY操作来说，和DISTINCT操作是等价的。不过虽然二者的结果是一样的，但是二者的执行计划并不相同。
在Oracle9i中：
SQL> Select * FROM V$VERSION;
BANNER
—————————————————————-
oracle9i Enterprise Edition Release 9.2.0.4.0 – Production PL/SQL Release 9.2.0.4.0 – Production
CORE 9.2.0.3.0 Production
TNS for Linux: Version 9.2.0.4.0 – Production
NLSRTL Version 9.2.0.4.0 – Production
SQL> Create TABLE T AS Select ROWNUM ID, A.* FROM DBA_OBJECTS A;
表已创建。
SQL> Create INDEX IND_T_CreateD ON T (CreateD);
索引已创建。
SQL> Alter TABLE T MODIFY CreateD NOT NULL;
表已更改。
SQL> Alter SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
会话已更改。
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, 'T')
PL/SQL 过程已成功完成。
SQL> SET AUTOT ON EXP
SQL> Select COUNT(*) FROM (Select DISTINCT CreateD FROM T);
COUNT(*)
———-
4794
执行计划
———————————————————-
0 Select STATEMENT Optimizer=CHOOSE (Cost=65 Card=1)
1 0 SORT (AGGREGATE)
2 1 VIEW (Cost=65 Card=4794)
3 2 SORT (UNIQUE) (Cost=65 Card=4794 Bytes=38352)
4 3 INDEX (FAST FULL SCAN) OF 'IND_T_CreateD' (NON-UNIQUE) (Cost=4 Card=41802 Bytes=334416)
SQL> Select COUNT(*) FROM (Select CreateD FROM T GROUP BY CreateD);
COUNT(*)
———-
4794
执行计划
———————————————————-
0 Select STATEMENT Optimizer=CHOOSE (Cost=65 Card=1 Bytes=2)
1 0 SORT (AGGREGATE)
2 1 VIEW (Cost=65 Card=4794 Bytes=9588)
3 2 SORT (GROUP BY) (Cost=65 Card=4794 Bytes=38352)
4 3 INDEX (FAST FULL SCAN) OF 'IND_T_CreateD' (NON-UNIQUE) (Cost=4 Card=41802 Bytes=334416)
从执行计划上看，DISTINCT的操作是SORT (UNIQUE)，而GROUP BY是SORT (GROUP BY)。DISTINCT操作只需要找出所有不同的值就可以了。而GROUP BY操作还要为其他聚集函数进行准备工作。从这一点上将，GROUP BY操作做的工作应该比DISTINCT所做的工作要多一些。
除了这一点，基本上看不到DISTINCT和GROUP BY（没有聚集函数的情况）有什么区别，而且从执行效率上也看不到明显的差异。
不过从10g开始，二者的差异开始体现出来了。
SQL> CONN YANGTK/YANGTK@YTK已连接。
SQL> SET AUTOT OFF
SQL> SET TIMING OFF
SQL> Create TABLE T AS Select ROWNUM ID, A.* FROM DBA_OBJECTS A;
表已创建。
SQL> Create INDEX IND_T_CreateD ON T (CreateD);
索引已创建。
SQL> Alter TABLE T MODIFY CreateD NOT NULL;
表已更改。
SQL> Alter SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
会话已更改。
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, 'T')
PL/SQL 过程已成功完成。
SQL> SET AUTOT ON
SQL> SET TIMING ON
建立好测试环境后，看一看标准分页函数中，两个操作的差异：
SQL> Select *
2 FROM
3 (
4 Select ROWNUM RN, A.*
5 FROM
6 (
7 Select CreateD
8 FROM T
9 GROUP BY CreateD
10 ) A
11 Where ROWNUM < 20
12 )
13 Where RN >= 10;
RN CreateD
———- ——————-
10 2005-12-19 17:07:57
11 2005-12-19 17:07:58
12 2005-12-19 17:08:24
13 2005-12-19 17:08:25
14 2005-12-19 17:08:26
15 2005-12-19 17:08:27
16 2005-12-19 17:08:28
17 2005-12-19 17:08:29
18 2005-12-19 17:08:33
19 2005-12-19 17:08:35
已选择10行。
已用时间: 00: 00: 00.06
执行计划
———————————————————-
Plan hash value: 3639065582
——————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
——————————————————————————-
| 0 | Select STATEMENT | | 19 | 418 | 1 (0)|
|* 1 | VIEW | | 19 | 418 | 1 (0)|
|* 2 | COUNT STOPKEY | | | | |
| 3 | VIEW | | 969 | 8721 | 1 (0)|
|* 4 | SORT GROUP BY STOPKEY| | 969 | 7752 | 1 (0)|
| 5 | INDEX FULL SCAN | IND_T_CreateD | 969 | 7752 | 1 (0)|
——————————————————————————-
Predicate Information (identified by operation id):
—————————————————
1 – filter(“RN”>=10)
2 – filter(ROWNUM<20)
4 - filter(ROWNUM<20)
统计信息
----------------------------------------------------------
1 recursive calls
0 db block gets
67 consistent gets
0 physical reads
0 redo size
642 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed
SQL> Select *
2 FROM
3 (
4 Select ROWNUM RN, A.*
5 FROM
6 (
7 Select DISTINCT CreateD
8 FROM T
9 ) A
10 Where ROWNUM < 20
11 )
12 Where RN >= 10;
RN CreateD
———- ——————-
10 2005-12-19 17:07:57
11 2005-12-19 17:07:58
12 2005-12-19 17:08:24
13 2005-12-19 17:08:25
14 2005-12-19 17:08:26
15 2005-12-19 17:08:27
16 2005-12-19 17:08:28
17 2005-12-19 17:08:29
18 2005-12-19 17:08:33
19 2005-12-19 17:08:35
已选择10行。
已用时间: 00: 00: 00.03
执行计划
———————————————————-
Plan hash value: 1650124153
——————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
——————————————————————————-
| 0 | Select STATEMENT | | 19 | 418 | 14 (36)|
|* 1 | VIEW | | 19 | 418 | 14 (36)|
|* 2 | COUNT STOPKEY | | | | |
| 3 | VIEW | | 987 | 8883 | 14 (36)|
|* 4 | SORT GROUP BY STOPKEY| | 987 | 7896 | 14 (36)|
| 5 | INDEX FAST FULL SCAN| IND_T_CreateD | 50333 | 393K| 10 (10)|
——————————————————————————-
Predicate Information (identified by operation id):
—————————————————
1 – filter(“RN”>=10)
2 – filter(ROWNUM<20)
4 – filter(ROWNUM<20)
统计信息
———————————————————-
1 recursive calls
0 db block gets
73 consistent gets
0 physical reads
0 redo size
642 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed
出乎意料的是，GROUP BY操作的COST更低，而且逻辑读也小，这似乎与二者的工作量成反比。仔细观察执行计划发现，问题的根源来自于GROUP BY使用INDEX FULL SCAN，而DISTINCT使用了INDEX FAST FULL SCAN。也许有人会感到奇怪，索引的快速全扫描不是要比索引全扫描效率更高吗？对于读取所有数据的情况下，确实是索引快速全扫效率更高。但是由于这里采用了分页，只取前20条数据，而且Oracle的10g增加了GROUP BY STOPKEY这种新的执行路径，因此在这里GROUP BY操作的效率更高。
观察执行计划中的处理行数可以发现，索引全扫描由于是按照索引的顺序扫描，因此利用了STOPKEY，仅仅处理了969条记录就停了下来。而对于DISTINCT操作的快速索引全速而言，显然没有使用STOPKEY，读取了所有的50333条记录。这就是GROUP BY和DISTINCT的性能差异原因。

实现SQL Server数据库的优化，首先要有一个好的数据库设计方案。在实际工作中，许多SQL Server方案往往是由于数据库设计得不好导致性能很差。实现良好的数据库设计必须考虑这些问题:
1. 逻辑数据库规范化问题
一般来说，逻辑数据库设计会满足规范化的前3级标准：
第1规范：没有重复的组或多值的列;
第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分;
第3规范: 一个非关键字段不能依赖于另一个非关键字段。
遵守这些规则的数据库设计会产生较少的列和更多的表，因而也就减少了数据冗余，也减少了用于存储数据的页。
2. 生成物理数据库
要想正确选择基本物理实现策略，必须了解和利用好数据库访问格式和硬件资源的操作特点，特别是内存和磁盘子系统I/O。以下是一些常用技巧：
与每个表列相关的数据类型应该反映数据所需的最小存储空间，特别是对于被索引的列更是如此。比如能使用smallint类型就不要用integer类型，这样索引字段可以被更快地读取，而且可以在一个数据页上放置更多的数据行，因而也就减少了I/O操作。
把一个表放在某个物理设备上，再通过SQL Server的段把它的不分簇索引放在一个不同的物理设备上，这样能提高性能。尤其是系统采用了多个智能型磁盘控制器和数据分离技术的情况下，这样做的好处更加明显。
用SQL Server段把一个频繁使用的大表分割开，并放在多个单独的智能型磁盘控制器的数据库设备上，这样也可以提高性能。因为有多个磁头在查找，所以数据分离也能提高性能。
用SQL Server段把文本或图像列的数据存放在一个单独的物理设备上可以提高性能。一个专用的智能型的控制器能进一步提高性能。
应用系统设计
在应用系统的设计中，要着重考虑以下几点：
1．合理使用索引
索引是数据库中重要的数据结构，它的根本目的就是提高查询效率。索引的使用要恰到好处，其使用原则如下：
在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引；在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引；在条件表达式中经常用到的不同值较多的列上建立索引，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。 如果待排序的列有多个，可以在这些列上建立复合索引。
2. 避免或简化排序
应当尽量简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序这个步骤。为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。
3．消除对大型表行数据的顺序存取
在嵌套查询中，表的顺序存取对查询效率可能产生致命的影响。我们有时可以使用并集来避免顺序存取。尽管也许在所有的检查列上都有索引，但某些形式的where子句会强迫优化器使用顺序存取，这一点也应注意。
4. 避免相关子查询
如果一个列同时在主查询和where子句中出现，很可能当主查询中的列值改变之后，子查询必须重新查询一次。而且查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。
5．避免困难的正规表达式
Mathes和Like关键字支持通配符匹配，但这种匹配特别耗时。例如：Select * FROM customer Where zipcode LIKE “98_ _ _”，即使在zipcode字段上已建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为：Select * FROM customer Where zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。
6．使用临时表加速查询
把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。但要注意，临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。
操作系统相关优化
操作系统性能的好坏直接影响数据库的使用性能，如果操作系统存在问题，如CPU过载、过度内存交换、磁盘I/O瓶颈等，在这种情况下，单纯进行数据库内部性能调整是不会改善系统性能的。我们可以通过Windows NT的系统监视器(System Monitor)来监控各种设备，发现性能瓶颈。
CPU 一种常见的性能问题就是缺乏处理能力。系统的处理能力是由系统的CPU数量、类型和速度决定的。如果系统没有足够的CPU处理能力，它就不能足够快地处理事务以满足需要。我们可以使用System Monitor确定CPU的使用率，如果以75%或更高的速率长时间运行，就可能碰到了CPU瓶颈问题，这时应该升级CPU。但是升级前必须监视系统的其他特性，如果是因为SQL语句效率非常低，优化语句就有助于解决较低的CPU利用率。而当确定需要更强的处理能力，可以添加CPU或者用更快的CPU 替换。
内存 SQL Server可使用的内存量是SQL Server性能最关键因素之一。而内存同I/O子系统的关系也是一个非常重要的因素。例如，在I/O操作频繁的系统中，SQL Server用来缓存数据的可用内存越多，必须执行的物理I/O也就越少。这是因为数据将从数据缓存中读取而不是从磁盘读取。同样，内存量的不足会引起明显的磁盘读写瓶颈，因为系统缓存能力不足会引起更多的物理磁盘I/O。
可以利用System Monitor检查SQL Server的Buffer Cache Hit Ratio计数器，如果命中率经常低于90%，就应该添加更多的内存。
I/O子系统 由I/O子系统发生的瓶颈问题是数据库系统可能遇到的最常见的同硬件有关的问题。配置很差的I/O子系统引起性能问题的严重程度仅次于编写很差的SQL语句。I/O子系统问题是这样产生的，一个磁盘驱动器能够执行的I/O操作是有限的，一般一个普通的磁盘驱动器每秒只能处理85次I/O操作，如果磁盘驱动器超载，到这些磁盘驱动器的I/O操作就要排队，SQL的I/O延迟将很长。这可能会使锁持续的时间更长，或者使线程在等待资源的过程中保持空闲状态，其结果就是整个系统的性能受到影响。
解决I/O子系统有关的问题也许是最容易的，多数情况下，增加磁盘驱动器就可以解决这个性能问题。
当然，影响性能的因素很多，而应用又各不相同，找出一个通用的优化方案是很困难的，只能是在系统开发和维护的过程中针对运行的具体情况，不断加以调整。

返回表达式，此表达式已被格式化为日期或时间。

FormatDateTime(Date[, NamedFormat])

» Read more: FormatDateTime 函数

返回两个日期之间的时间间隔。

DateDiff(interval, date1, date2 [,firstdayofweek[, firstweekofyear]])

» Read more: DateDiff 函数

返回已添加指定时间间隔的日期。
DateAdd(interval, number, date)
参数
interval
必选项。字符串表达式，表示要添加的时间间隔。有关数值，请参阅“设置”部分。
number
必选项。数值表达式，表示要添加的时间间隔的个数。数值表达式可以是正数（得到未来的日期）或负数（得到过去的日期）。
date
必选项。Variant 或要添加 interval 的表示日期的文字。
设置
interval 参数可以有以下值：
设置 描述
yyyy 年
q 季度
m 月
y 一年的日数
d 日
w 一周的日数
ww 周
h 小时
n 分钟
s 秒
说明
可用 DateAdd 函数从日期中添加或减去指定时间间隔。例如可以使用 DateAdd 从当天算起 30 天以后的日期或从现在算起 45 分钟以后的时间。要向 date 添加以“日”为单位的时间间隔，可以使用“一年的日数”（“y”）、“日”（“d”）或“一周的日数”（“w”）。
DateAdd 函数不会返回无效日期。如下示例将 95 年 1 月 31 日加上一个月：
NewDate = DateAdd(“m”, 1, “31-Jan-95″)
在这个示例中，DateAdd 返回 95 年 2 月 28 日，而不是 95 年 2 月 31 日。如果 date 为 96 年 1 月 31 日，则返回 96 年 2 月 29 日，这是因为 1996 是闰年。
如果计算的日期是在公元 100 年之前，则会产生错误。
如果 number 不是 Long 型值，则在计算前四舍五入为最接近的整数。

自动增加字段需要重写。在access中经常使用的自动编号字段，导入到mssql后，他并不是自增型的int，需要手工设置，把导入后的自动编号字段的标识的“否”改为“是”，“种子”和“递增量”都为“1”，才能成为自动编号
所有的默认值都丢失了。主要是数字类型和日期类型
所有now()，time()，date()要改成getdate()
所有datediff(’d’, time1, time2)要改成datediff(day, time1, time2)
所有datediff(’ww’, time1, time2)要改成datediff(week, time1, time2)
所有datediff(’d’, time1, time2)要改成datediff(day, time1, time2)
在mssql server中，有许多保留字，在access中是没有的，当你把数据导入到mssql的时候，问题就出来了。mssql在导入的时候，会自动给这些字段（包括数据库中的表名）加上“[字段名]”，因此，你必须修改你的脚本，把相应的字段名字（或者表名字）加上中括号，或改变字段名字为不是mssql的保留字
在用access关于时间的使用，大家喜欢使用“select * from aaaa while time=”&now()”这样的sql语句，然而，在mssql中没有“now()”这个函数，而是使用“getdate()”，所以，所有的sql语句中的“now()”必须换成“getdate()”。
日期函数不相同，在对ACCESS数据库处理中，可用date()、time()等函数，但对
SQL SERVER数据库处理中，只能用datediff,dateadd等函数，而不能用date()、time()等函数。
转化时，跟日期有关的字段，SQL SERVER默认为smalldatetime型，我们最好将它变为datetime型，因为datetime型的范围比smalldatetime型大。有时用smalldatetime型时，转化失败，而用datetime型时，转化成功
isnull(rowname)要改成rowname = null
CursorType要改成1,也就是打开数据库时要给出第一个数字参数为1，否则记录可能
显示不完整
备注类型要通过cast(column as varchar)来使用
true/false类型不能使用，要变为1/0
对此两种数据库进行操作的sql语句不全相同，例如：在对ACCESS数据库进行删除纪录时用：”delete * from user where id=10″,而对SQL SERVER数据库进行删除是用：”delete user where id=10″.
在对ACCESS数据库处理中,sql语句中直接可以用一些VB的函数，像cstr()函数，而对SQL SERVER数据库处理中，却不能用
在access的sql语句中的时间使用变量查询的时候，大家一般使用”select * from aaaa while time=#”&变量名&”#”，在mssql中是不行的，他的语法是“select * from aaaa while time=’”&变量名&”’””。（意思是让你把日期时间变量当成字符串来使用，呵呵~~~）
原来ASP里的“Delete * FROM ……”要改为“Delete FROM ……”
有可能rs.update失败，修改成update 表名 set 字段=‘值’ 这样通过（遇到的情况，提示为：
Microsoft OLE DB Provider for SQL Server 错误 ’80040e38’
乐观并发检查失败。已在此游标之外修改了该行。
/Admin_ClassOrder.asp，行 164 ）
access里面除法可以使用”\”或者”/”，MSSQL里面只能使用”/”
1.mdb中的ID到了Access会变成普通的int，要重新设置为“标识”。
2.SQL语句中的now()要改成getdate()。
3.SQL语句中Like后面字符串的通配符'*'要改成'%'。
4、access表内数据类型”是/否”，到了sql server的表内就是 bit (not null)
5、access查询通过cdate构造日期，sql server内是convert(datetime,…)
6. 在sql server 里,就我使用的经验来看： '2004-5-29' =
convert(datetime,'2004-5-29')
7.数据库导入以后，自动增加字段需要重写，所有的数字类型需要增加长度，最好用
decimal。
8.所有的默认值都丢失了。主要是数字类型和日期类型。
9.所有now()，time()，date()要改成getdate()。
10.所有datediff('d', time1, time2)要改成datediff(day, time1, time2)
11.有可能一些true/false类型不能使用，要变为1/0。
12.备注类型要通过cast(column as varchar)来使用。
13.CursorType要改成1,也就是打开数据库时要给出第一个数字参数为1，否则记录可能
显示不完整。
14.isnull(rowname)要改成rowname = null
15.ACCESS的数据库中的自动编号类型在转化时，sql server并没有将它设为自动编号型，我们需在SQL创建语句中加上identity，表示自动编号！
16.转化时，跟日期有关的字段，SQL SERVER默认为smalldatetime型，我们最好将它变为datetime型，因为datetime型的范围比smalldatetime型大。我遇见这种情况，用smalldatetime型时，转化失败，而用datetime型时，转化成功。
17.对此两种数据库进行操作的sql语句不全相同，例如：在对ACCESS数据库进行删除纪录时用：”delete * from user where id=10″,而对SQL SERVER数据库进行删除是用：”delete user where id=10″.
18.日期函数不相同，在对ACCESS数据库处理中，可用date()、time()等函数，但对
SQL SERVER数据库处理中，只能用datediff,dateadd等函数，而不能用date()、time()等函数。
19.在对ACCESS数据库处理中,sql语句中直接可以用一些VB的函数，像cstr()函数，而对SQL SERVER数据库处理中，却不能用。
20:最好在有可能和系统关键字的地方使用“［”和“］”将他包围起来，以避免在移植过程中出现的运行错误问题

在windows控制面版–>管理工具–>服务–>MSSQLSERVER–>属性–>改为你的新的操作系统密码！
或
在windows控制面版–>管理工具–>服务–>MSSQLSERVER–>属性–>改为本地登陆！

系统用户administrator 密码改变后，注销重新登录，发现SQL Server没有随机启动。手动从服务管理器中启动，提示“由于登录失败而无法启动服务”。
原因:
安装SQL Server时是使用默认登录用户来作为启动SQL Server服务的账号（对于自己使用的单机，通常就是administrator），当该用户更改了用户名（如把administrator改成admin）或更改了其口令时，再次启动服务器，就出现“同于登录失败而无法启动服务”的错误了。
解决方法如下：
1、将administrator的密码改回原来的密码；
2、从数据库服务管理器中启动SQLServer；
3、从“计算机管理”中修改administrator的密码；
4、打开数据库企业管理器，在左边数据库服务器列表中找到要修改的服务器，点击右键菜单【属性】,在出现的属性对话框中选择“安全性”表项；
5、在“启动服务帐户”处的“本帐户”选项中修改密码为administrator的新密码，点击“确定”，系统提示“是否现在停止并重新启动服务器？”，点击“是”。数据库服务器会自动停止并重新启动。
建议与总结：
1、如果在“启动服务帐户”处的选项不是“本帐户”，而是“系统帐户”，则修改用户密码不会导致数据库启动失败；
2、数据库服务器必须是运行状态，才可修改其属性，否则连接不上；所以才必须改回原密码，将数据库启动后再修改；
3、必须先修改administrator的密码，再修改数据库的安全性属性，反之则修改不成。