SQL Server之体系结构

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 所示。

图 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 演示了数据库的物理布局图。

图 1-2 数据布局

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

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

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

文件扩展名 .mdf、.ldf 和 .ndf

数据库文件扩展名 .mdf 和 .ldf 的含义很明确。扩展名 .mdf 表明 Master Data File（主要数据文件，不要与 master 数据库混淆），ldf 表明 Log Data File（日志数据文件）。当讨论辅助数据文件的扩展名时，一种有趣的说法是，.ndf 表明 Not Master Data File（非主要数据文件），某位开发人员提出了这种开玩笑式的说法，业界也就这么接受了。

架构（Schema）和对象

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

图 1-3 数据库、架构和数据库对象

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

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