SQL Server 体系结构

SQL Server 实例

SQL Server 实例是指安装的一个 SQL Server 数据库引擎/服务。在同一台计算机上可以安装 SQL Server 的多个实例。从安全性、实例管理的数据以及其它方面来说，每个实例是完全彼此独立的。在逻辑层面，位于同一计算机上的两个不同实例和位于两台不同计算机上的实例相差无几。当然，它们会共享服务器的物力资源（如 CPU、内存、磁盘空间）。

可以将计算机上安装的实例之一设置为默认实例，而其它实例则必须为命名实例。在安装期间可以决定是将一个实例安装为默认实例，还是命名实例：安装好以后就不能对此进行修改了。如果一个客户端应用程序要连接到默认实例，只需指明实例所在计算机的名称或 IP 地址。要连接到一个命名实例，客户端要指明计算机的名称或 IP 地址，接着再写一个反斜杠字符（“\”），后面指明实例名称（在安装期间提供的）。例如，假设在名为 Server1 的计算机上安装了两个 SQL Server 实例，其中一个安装为默认实例，而另一个则安装为命名实例 Inst1。要连接到默认实例，就只要指定服务器名称 Server1；而要连接到命名实例，则要将其指定为 Server1\Inst1。

在同一台计算机上安装多个 SQL Server 的实例，可能会有各种原因，这里只列举几个。

一个例子是像我们普通的开发者，有时候要测试不同版本之间的区别，就可以很方便的在同一个笔记本上安装多个版本的 SQL Server 实例。

另一个例子是数据库供应商可能拥有非常强大的数据中心，能够容纳多个 SQL Server 的安装实例，而不必维护多台性能较低的计算机，在每台这样的机器上安装不同的实例。

数据库

可以将数据库认为是各种对象的容器，这些对象可以是表（table）、视图（view）、存储过程（stored procedure）等等。每个 SQL Server 实例可以包含多个数据库，如图 1-1 所示。

当安装 SQLServer 时，安装程序会创建几个系统数据库，用于保存系统数据和服务与内部目的。安装好之后，就可以创建自己的用户数据库，以保存应用程序数据。

安装程序创建的系统数据库包括 master、Resource、model、tempdb 以及 msdb。它们各自的作用分别描述如下：

• master    master 数据库保存 SQL Server 实例范围内的元数据信息、服务器配置、示例中所有数据库的信息，以及初始化信息。
• Resource    Resource 数据库是 SQL Server 2005 中增加的，用于保存所有系统对象。当查询数据库中的元数据信息时，这种信息表面上使位于数据库中，但实际上是保存在 Resource 数据库中。
• model    model 数据库是新数据库的模板。每个新创建的数据库最初都是 model 的一个副本（copy）。所以，如果想在所有新创建的数据库中都包含特定的对象（比如数据类型），或者是在所有新创建的数据库中都以特定的方式来配置某些数据库属性，就可以先把这些对象或配置属性放在 model 数据库中。注意：对 model 数据库做出的修改不会影响现有的数据库，只影响此后新创建的数据库。
• tempdb    tempdb 数据库是 SQL Server 保存临时数据的地方，这些临时数据包括工作表（work table）、排序空间（sort space）、行版本控制（row versioning）信息等等。SQL Server 允许用户自己创建临时表，这些临时表的物理保存位置就是 tempdb。注意，每次重启 SQL Server 实例时，会删除这个数据库的内容，并将其重新创建为 model 的一个副本。因此，当需要为测试目的而创建一些对象，而且在测试完成后不想将这些对象继续保存在数据库中时，通常可以在 tempdb 中创建它们。即使忘记清除这些对象，在重新启动后也会自动清除它们。
• msdb    msdb 是称为 SQL Server Agent 的一种服务保存其数据的地方。SQL Server Agent 负责自动化处理，包括记录有关作业（job）、计划（schedule）和警报等实体的信息。SQL Server Agent 也是负责复制（replication）的服务。msdb 还用于保存一些有关其它 SQL Server 功能的信息，例如 Database mail 和 Service Broker。

在 SQL Server 实例中可以创建需要的任意数量的用户数据库。用户数据库内可以保存应用程序需要的各种对象和数据。

可以在数据库级上定义一个成为 collation（排序规则）的属性，由它确定数据库中字符数据使用的排序规则信息（包括支持的语言、区分大小写和排序规则等）。如果在创建数据库时不为其指定 collation 属性，将使用实例默认的排序规则设置。

为了对数据库运行 T-SQL 代码，客户端应用程序需连接到 SQL Server 实例，要位于相关数据库的上下文（context）中，或者能够使用相关数据库。

在安全性方面，为了能够连接到 SQL Server 实例，必须让 DBA（数据库管理员）为用户创建一个登录账号。登录账号可以关联到 Windows 凭据（credentials），在这种情况下，它会调用 Windows 凭据进行身份验证。使用 Windows 验证的登录，当连接到 SQL Server 时就无需提供登录用户名和密码信息，因为当登录到 Windows 时已经提供了这些信息。登录账号可以关联到 Windows 凭据（credentials），需要时，它会调用 Windows 凭据进行身份验证。当使用 SQL Server 验证登录来连接 SQL Server 时，就必须提供登录的用户名和密码。

DBA 要将你的登录账号映射到有权访问的任何数据库中的数据库用户（database user）。数据库用户是将被授权访问数据库对象的实体。

到目前为止，已经主要介绍了数据库的逻辑层面。图 1-2 演示了数据库的物理布局图。

数据库在物理上由数据文件和事务日志文件组成。当创建数据库时，能够定义每个文件的各种属性，包括文件名、保存位置，以及文件自动扩展的增量（autogrowth 属性）。每个数据库必须至少有一个数据文件和一个日志文件（SQL Server 的默认情况）。数据文件用于保存数据库对象数据，日志文件则保存 SQL Server 为了维护事务而需要的信息。

虽然 SQL Server 可以同时写多个数据文件，但某一时刻只能顺序方式写一个日志文件。因此与数据文件不同，使用多个日志文件并不能提升系统的性能。如果原来的日志文件所在的磁盘空间耗尽了，就可能要增加新的日志文件。

多个数据文件在逻辑上按照文件组（FileGroup）的形式进行分组管理。创建数据库对象（例如表或索引）时，就会将其保存在目标文件组中。对象数据可能会保存在属于目标文件组的多个文件中。通过文件组可以控制数据库对象的物理存储位置。数据库必须至少要有一个主文件组（PRIMARY），而用户定义的文件组则是可选的。PRIMARY 文件组包含主数据文件（扩展名为 .MDF），以及数据库的系统目录（catalog）。可以选择性地为 PRIMARY 增加多个辅助数据文件（secondary data file），扩展名为 .NDF。用户定义的文件组只能包含辅助数据文件。可以指定将哪个文件组作为默认文件组。当对象创建语句没有明确指定目标文件组时，就将它创建在默认文件组中。

架构（Schema）和对象

前面曾经说过数据库是一种对象的容器，这样说只是为了简单而已。如图 1-3 所示，一个数据库可以包含多个架构，而每个架构又包含多个对象。可以将架构看做是各种对象的容器，这些对象可以是表（table）、视图（view）、存储过程（stored procedure）等。

可以在架构级别上控制对象的访问权限。例如，可以为一个用户授予某个架构上的 SELECT 权限，让这个用户能够查询该架构中的所有对象的数据。所以，对于决定在架构中如何组织对象，安全性是应该考虑的因素之一。

此外，架构也是一个命名空间，用作对象名称的前缀。例如，假设在架构 Sales 中有一个 Orders 表，架构限定（schema-qualified）的对象名称是 Sales.Orders，也称为两部分对象名称（two-part name）。如果在引用对象时省略架构名称，SQL Server 将采用一定的办法来分析出架构名称是什么，例如，检查对象是否在用户的默认架构中，如果不在，再继续检查对象是否在 dbo 架构中。当在代码中引用对象时，推荐总是使用这种由两部分构成的对象名称。有时，如果不显式指定架构，那么在解析对象名称时，就会要付出一些没有意义的额外代价。既然这样的额外代价是没有意义的，为什么还要为它付出？而且，在不同的架构中可能存在名称相同的多个对象，如果这时还不显式指定架构，那么最终得到的对象可能并不是你原本想要的。