《MS SQL Server 2000管理员手册》系列——4. 设计Microsoft SQL Server 系统

4. 设计Microsoft SQL Server 系统

系统需求

系统组件和选项

数据库排列

应用程序

本章总结

在正式安装 SQL Sever 操作系统之前，必须事先计划如何架设属于您的 SQL Server 系统，以避免后续操作的麻烦，甚至还得重新安装。本书如提到 SQL Server 系统，代表这台计算机是在跑 SQL Server 主程序的计算机，若是只提到系统一词，则代表是使用者装有 SQL Sever 数据库的计算机。

这一章我们会学到 Microsoft Window 2000 和 SQL Server 的不同版本，几种可存取 SQL Server 的前端应用程序，以及 SQL Server 和前端应用程序的结合对系统延展性与执行效能的影响。

系统需求

在决定整个系统的需求之前，首先得考虑系统的目的。看看要用几台计算机，以及如何用才能达到架设这个系统的目的。这一章我们先看看一般人架设的目的。到第5章和第6章再来讨论如何配合目的来设计、安装硬设备。

在这一章我们也会讨论到系统的功能，以及如何设定这些功能。在设定服务项目之前，我们首先要了解将要架设的系统会跑哪些类型的应用程序。

系统应用程序

少了应用程序，SQL Server 数据库也没啥存在的必要。应用程序可使 SQL Server使用方便。有些应用程序一看便知是个数据库，有些则不然。不论何种应用程序，都得在最短的时间内解决使用者的需求。否则使用者只好去买更好的软件啰！

应用程序的类型可以功能性区分。一般可分为三大类型：在线交易处理 (OLTP) 系统、决策支持系统 (DSS)和批处理系统。这三种类型有不同的系统需求，也可能用到截然不同类型的应用软件。

在线交易处理

当一堆使用者同时在在线存取资料，就被分类为在线交易处理。还有一点很重要的特质，就是这些使用者同时等候系统响应。在线交易处理系统有几种模式，如：

• 在线购物这种模式当然是因应电子商务蓬勃发展。应用的范围譬如说当您在网络上购物填数据买东西时总得等待数据传送，这就是一种在线交易的模式。当然存取数据的时间越短就能让您快快完成交易行为。

• 商店购物当店员刷过您的信用卡那一剎那，您的数据就透过层层系统进入数据库中交易了。

• 商业系统每家公司都会透过自己的一套应用程序进入数据库。这可以是薪资系统、购物系统等各式各样的系统。这些应用程序可以是内部网络的应用程序，或是用 C++、Microsoft Visual Basic 等各种语言写的程序。总之不管什么应用程序，数据的来源都是来自数据库。

所有的在线交易系统有一个共通点，那就是─等，正确的说法应该是用者都需要等待系统的响应。所以好的系统是设计合理的响应时间。(就是不要让人家等太久啦！)

决策支持系统

决策支持系统，顾名思义就是可以支持您做企业上决策的系统。使用者可以丢出问题，再参考运算后出来的结果。下列几种问题就是决策支持系统可以回答的问题：

• 找出公司每个地区谁最会卖，什么产品卖最多？

• 找出产品的季节性。

• 如果减价大甩卖会怎样？

• 平均每个地区的业务拿了多少佣金？

决策支持系统和在线交易处理系统的不同处，在于前者可以有耐心地等待一个结果，因为系统也许得花上一点时间来分析这些复杂的问题。这并不是说使用者就不在乎这次得等多久，而是总产值 (与其浪费一堆人的时间) 和回复时间 (不如浪费一个人的时间) 是可以互相协调的。

批处理系统

批处理系统离线处理无后端使用者的组件，以下是这类系统典型的运作形式：

• 每日数据重整有的决策支持系统需要每晚重新整理数据，批处理系统则将这个步骤自动化。

• 数据转换这项作业和前述作业有些类似，不过这里会进行数据转换。

• 数据清除清除如重复的账户使用者。

• 离线布告可由客户每晚的布告组成。

批处理系统通常不会有使用者在一旁等待作业的完成，但这类型的系统还是要在一定的时间范围内完成作业，如晚上的数据重整就不能到早上使用者都上线了还没完成。

设备需求

介绍完这三种不同类型的应用程序，您可以知道在设计一个数据库服务器之前，了解系统要跑什么类型的应用程序是很重要的了。在下几节您会学到每种类型的系统均有自己的设备需求和特质。所以设备需求和特质决定了是否采用分布式处理系统。

要求服务范围

服务范围是设计一个系统最重要的一环。服务项目通常清楚的列入服务范围同意书 (SLA)内。SLA 是服务提供者和顾客之间的同意书，是否真的需要很正式的一份 SLA 通常取决于客人。

举例来说，如果您和外面的公司签定数据库服务，提供这项服务的公司大多会给您一份 SLA，这可以视为一份有法律效力的同意书。但如果是由公司内部某部门提供数据库的服务，可能就没这么正式。不管是哪一种 SLA，都会列出应该包含的服务范围，有时也会一并列出毁约的处罚。

当服务范围确认，就可以设计适合的系统提供服务了。以下我们将讨论影响设计的层面：

执行效能规定

SLA 内重要的一点就是详述系统设备的最低要求。一份典型的 SLA 会附上表格，并列出一个应用程序可支持的数种交易形式，完成交易所需要的基本服务，及选择性的附上完成 90﹪─ 95﹪ 交易时所需的时间。如 SLA 可能列出一项服务内容：「加入新客户名单」，如要完成这项服务的90﹪需两秒钟，完成全部则需三秒钟。

提供服务的公司或单位必须彻底作到服务的范围以免违约，DBA 更要确认服务的执行。您必须定期检视系统状况及功能制定计划，当系统有问题发生，必须视程度强化其系统功能。

运作能力范围

除了包含设备需求，SLA 也可考虑加入系统的运作能力范围。系统运作能力范围可分为几个种类，如硬盘空间能力范围、使用者能力范围及网络连结能力范围等。您必须确保您的系统有足够的能力执行需求。

经常检视您的系统，如果发现系统达到能力范围的临界点，要立即处理。在第六章中，我们会就细节讨论如何适时强化系统资源。

系统最佳执行时间

除了规划系统的执行效能和运作能力范围，SLA 通常也会规范系统的最佳执行时间。所谓系统最佳执行时间就是我们规定使用者可使用系统的时间。SLA 可能规定一天24小时都是系统最佳执行时间，或规定特定的几个小时为最佳执行时间。要维护这项服务，DBA 必须计划性的作固定备份和回复的动作。

系统组件和选项

现在您有了应用程序类型和制定服务范围的概念，我们可以开始看看如何决定安装合适的软件。这里有四种版本的 Windows 2000 和三种版本的 SQL Server 2000 供您挑选。这一节会教您各版本的不同性与适用性。

Windows 2000 的四个版本

Windows 2000 的四个版本就功能性的多寡依序是 Windows 数据中心、Windows 2000 高阶服务器版、Windows 2000 服务器版，最后是 Windows 2000 专业版。以下会介绍每种版本的功能性，方便您找到适合您系统的版本，而不是胡乱的买个最贵的版本交差。

Windows 2000 专业版

Windows 2000 专业版适用于一般的桌上型计算机。通常，用到 Windows 2000 专业版的计算机，会用到的大约只是 SQL Server 2000 客户端组件。当然，如果您想在自己的计算机上跑 SQL Server 2000 的话，可以加装 SQL Server 2000 个人版。不过个人版仅允许您在自己的计算机上存取数据，不允许透过其它的系统存取。

________________________________________

相关信息

一个丛集离误和系统同样需要有回复及立即重新开机的功能。MSCS 不提供容错功能-仅提供快速回复。

________________________________________

SQL Server 复写

SQL Server 复制选项可将 SQL Server 数据库内的数据复写一份到另一个数据库系统。复制的方法有三种-快照式复写、交易式复写及合并式复写。三种型式的复制均采订阅模式，就是订阅者可以接收由发行者发出的复制版本这样的模式。

快照式复写

快照式复写是以定时快照的方式将档案复制供其它系统使用。快照的动作需要使用者设定使用后才会执行工作，以避免影响系统的运作。快照式复写的缺点是复制出来的版本，最新的资料仅止于上一次复制出来的版本，至于这个所谓最新版本可能已是几个钟头前的版本了。

交易式复写

这种类型的复写方式在前端的处理和之前的快照式是相同的。不同处在于当交易类型的复制法启动之后，发行者就不断的读取交易记录文件并将读取的数据传给订阅者。订阅者这边就会保持一份较新的复制，当然在传送的过程中是会有迟滞的。

合并式复写

合并式复写和其它两种类型复写不同的地方在于，合并式复写会同时在发行者与订阅者端更新。SQL Server 利用触发程序和时间戳记(timestamp)整合不同的复写系统。合并式复写在需要以多重执行绪方式进行复写程序时很适用，当然系统要承受的负担会比其它两种复写类型来得重。

可更新分布式检视表

SQL Server 2000 推出的可更新分布式检视表可让系统间共享逻辑数据库，加强了系统的延展性。逻辑数据库可以分布到很多台计算机，使数据库更具功能性。第十八章会就可更新分布式检表作更详细的讨论。

数据库排列

设计数据库另一个重点就是数据排列。这里的设计包括输出后呈现给使用者的排列格式，如交易记录文件、数据文件等的排列。事先设计好您所想要的排列方式是很重要的，因为排列方式一旦决定之后更改起来就很费事了。第五章和第六章中我们会讨论排列的细节。

交易记录文件

交易记录文件对系统稳定与否很重要。交易记录文件记录着一个系统所有数据的更动，当系统发生问题时也要靠交易记录文件回复系统数据，因此必须将记录文件放在适合的地方。最好使用数组输出入装置保护交易记录文件，当硬盘出了问题也不致损坏此记录文件。

此外，这个档案应放置于执行效能较高的装置上，因为交易必须先存盘记录后才能进行下一笔交易，若装置的系统执行效能低，则会影响整个系统的执行效能。其它要注意的是记录文件需有容错性，这一部份的细节我们会在下一章讨论。

当放置交易记录文件的空间存满，便会停止交易，所以要配置一个足够的空间来存放交易记录文件。交易文件可藉备份把空间释放出来，但由于备份也可能会影响系统执行效能，有些DBA会先较大的空间存放记录文件，约每个小时或每天备份一次。就空间上来说，最好设计能有足够的空间存放八个小时的交易量且无须间中备份。以后您会发现其实这种是一种简化的交易记录文件。

数据文件

数据文件和交易记录文件有不同的呈列方式。呈列的方式取决于使用者进入档案的方式。档案应分散存放在不同的硬盘上，分散各硬盘的负担。我们会在下一章详细的讨论这部分。

您要准备足够的空间来应付数据的成长。当数据成长，索引也跟着成长。所以必须定期的执行空间容量规划测试，确保还有足够的空间存放数据。

在学会了规划数据文件、计算空间、评估执行效能和以数组式装置配置子系统硬盘，下一个要考虑的就是是否允许容错。当输入输出装置子系统确认后，就可将数据文件平均分配在各控制器和硬盘上。

应用程序

在这一节您会学到如何设计一个应用程序，并考虑其执行效能、延展性及成长性。

层次架构

一个应用程序的基本架构可以有很多种类型，各类型间的不同在于这个应用软件包含了多少层次的系统架构。很多数据库应用软件的营销重点就放在该软件是采几层次的系统架构。

层次架构比较

每一个数据库应用程序皆可分为三层不同的服务范围，分别是：

• 数据库服务：这是数据库系统的后端部分，储存数据库的地方。

• 应用程序服务：这是数据库的应用程序或运算逻辑。

• 显示服务：这是属于使用者的接口，这个服务必须负责把运算结果以使用者可以理解的形式呈现。

这些应用程序可分为一层式架构、两层及三层式架构。这些架构的分隔在于该应用程序如何将上述三项服务分组。请先参照图4-1的架构示意图，之后会再仔细介绍这三种架构。

图4-1应用软件架构示意图

一层式架构即是三种服务组件都在安装在同一系统上执行。以这种架构为主的应用软件不处理系统平台外的需求。如 Microsoft Access database 就是一例。

现在已经很少有数据库应用程序仅单采用一层式架构，尤其是 Windows 2000 支持的软件。在 SQL Server 更是找不出支持此架构的数据库应用软件。有一种架构是您在一台计算机上同时安装 Enterprise Manager 和数据库，看来似乎是采这种模式，但其实这并不算是一层式架构，因为在这里应用软件其实是运用 SQL Server 网络上的组件来执行运作的。

两层式架构

两层式架构是将显示服务和数据库分别放在不同的系统上。而显示服务(使用者接口)已内含运用程序逻辑。SQL Server Enterprise Manger 就是采这种架构。在这里的使用者接口和程序逻辑均放置在 Enterprise Manager 内，但数据部分则是放在另一个装有 SQL Server 数据库的系统上。

两层式架构是很常见的一种架构。很多这种架构的应用程序是以支持 Winodws API 的语言(如 Microsoft Visual C++ 或 Visual Basic)写成的。在这种架构，使用者必须和 SQL Server 数据库联机。但是这种连结有时是没有效率的，因为很可能联机的应用程序都在闲置状态，却又占住联机。

三层式架构

三层式架构是将数据库、应用程序和显示服务层放在不同的系统上。这种架构利用中间的应用程序层，多任务连结至显示服务层，以此来减少使用者直接与 SQL Server 联机的机会。此外，中间的应用程序层也可大量的执行运算逻辑，使 SQL Server 好好的扮演数据递送的角色。

对于 Web 架构的应用程序是两层式或三层式则是有些争议。其实您可以做个简单的分析，如果说显示服务端只是透过终端处理机或浏览器就可浏览数据库数据，那此应用程序就很可能是采两层式架构。

如上述所见，如果将服务范围分开，您就可以运用到很多不同的系统了。在实际的应用方面，很多系统就是把一台数据库服务器连结到不同的应用程序服务器上以服务更多的用户。所以当您设计一个系统时，就得考虑使用者的多寡以及系统将支持哪种应用程序。

执行效能与延展性

当您在架构一个应用程序及数据库时，要考虑此结构是否具执行效能及延展性。下列的选项可能会影响这系统的执行效能与延展性。

• 使用暂存工作暂存工作表适用于较小规模的数据库，对较大规模的数据库则不适用。

• 使用汇总函数功能使用汇总函数功能如 MIN( )、MAX( ) 和 AVG( )的比例和资料的多寡有绝对的关系。所以要小心不要因为使用了这个功能而影响系统执行效能。

• 使用索引当数据量越来越大时，就需要用到索引，我们会在第十七章继续讨论索引。

• 使用交易明确的交易使用可以确保整个运作过程的完整性。不过，当同时联机的使用者数量成长时，尽可能降低资源锁定是相当重要的。

如上所述，当您设计一个系统时必须考虑许多层面以因应工作量的成长。如果能在设计之初就可将系统以最佳化的技巧来设计，便可设定出一个有延展性的系统了。

本章总结

如本章所述，在设计 SQL Server 系统的同时要将很多事情列入考虑。而且因为每个公司的需求不尽相同，即使您专职系统设计，您所设计的每一个系统也很难跑出一样的设计效果，更别说可以找到一个人简单的告诉您要怎样来设计您的系统了。

本章讨论了几个设计上的要点。您必须了解一个公司的最佳执行时间需求，并基于此而设计合适的系统。这些可能包括设计数据中心的数量、将系统丛集化、使用数组输出入装置或复制功能。此外，系统的延展性和其执行效能也是整体设计的考虑范围，最后还要注意应用程序的执行效能。这些项目会避免日后使用者数量增加时让系统处理速度变慢。

在下一章，我们会对许多本章介绍过的项目深入探讨。下一章会告诉您关于 I/O子系统的运作，其执行效能与容错功能，以及如何计划与安装一个好的 I/O 子系统。