|
|
本章内容：第二章
＊针对特定架构作设计
＊为系统效能而设计
＊其它设计上的考虑
＊针对Oracle7设计
＊Oracle8简介为什么「设计」
如此重要？
本章将介绍对Oracle数据库而言，设计完备的重要性。之所以不同其它关连式资
料库，在于Oracle支持多种不同架构及操作环境。同样的应用程序可以在单机的
个人计算机上使用，也可以在上千人使用的大型主机上运作，影响效能最重要的因素
当然就是设计的好坏了。Oracle还提供许多功能，可以使用不同的方法和机制来达
成同样目标。身为设计师，必须在现有主客观的环境下，选择最恰当的设计和作
法。
在这一章将介绍Oracle支持的重要架构；包括主从式（client/server）、分布式数据
库（distributeddatabase）、数据仓储（datawarehousing）、以及平行处理（parallel
processing）。相关主题将在本书的第三部份深入讨索。我们也将勾勒出系统效能最
佳化的轮廓。最后，会扼要列出对设计师来说Oracle7相当重要的特性，并介绍
Oracle8即将引进的新功能。
35
36/第二章
针对特定的架构来作设计
有时候，目标系统架构会被主客观环境所局限；例如，公司?，每个人都使用个人
计算机的情况下，可说除了主从式架构外，几乎没有其它选择。通常在分析阶段产生
的限制（constraints），左右着我们对于相关作法的选择；产能（throughput）可能
是某个系统的主要诉求，而效能评估（benchmark）则透露出我们必须使用Oracle
的ParallelQueryOption才能达到要求。不管是什么原因，都该好好考虑其它选
择。有些人倾向使用较先进的技术（这样比较有趣，因为履历表上可增添比较炫丽
的纪录），但我们应当回过头来好好考虑现实情况，充分了解使用不同技术将会带
来什么样的结果。
让我们看看会影响设计的特定架构。
主从式架构
所谓主从式架构，就是客户端（client）通常与数据库服务器（server）分离的电
脑。客户端与服务器可能透过高频宽的局域网络（LocalAreaNetwork，简称
LAN），也可能是透过广域网络（WideAreaNetwork，简称WAN）（相对地，频宽
较低，速度较慢）的连结。
要建置好的主从式架构的关键，在于有效地分离客户端及服务器两边的程序运作，
像是讯息传送至两端的往返时间（roundtriptime，又称为messagepairs）降低。
其次，是要将传送的讯息长度减至最短。假使能够遵循这两个原则，会发现客户端
及服务器的状态都保持在颠峰。客户端以友善的接口引导使用者完成工作，服务器
则保证数据的整合性，以最快速度响应客户端的要求。
在设计程序（procedure）时，必须考虑将它放在客户端、服务器还是两边都要。某
些特殊情况，最好分开在客户端及服务器；而某些情况，最好是两边都复制一份。
不过，大致说来，应把使用者接口管理摆在客户端（前端），而数据逻辑处理摆在
服务器端（后端）。位置的误放往往会严重影响系统效能及使用率。
如果以三层式（three-tier）架构考虑，则期望能将接口逻辑（presentationlogic）
放在客户端，程序逻辑（applicationlogic）置于中间层，而数据逻辑（datalogic）
则位在数据服务器。Oracle网络运算架构（NetworkComputingArchitecture，简称
NCA），让three-tier、甚至n-tier架构的应用程序更易作到。（如需更多这方面的
信息，请详阅后头讨论「Version7.3」NCA的章节）
为什么「设计」如此重要？/37
让我们再回头看看租车公司的例子。该公司将在PC上执行主从式架构的应用软
体。对于使用者，最重要的是能快速处理归还的车子，因为客户通常在赶时间（比
方说赶飞机）。因此，我们决定将还车的程序设计成：输入租车号码时，会将该交
易所需的数据从服务器端下载，然后储存在客户端。这些数据不需要一次显示到萤
幕上，但是会被储存在客户端PC的内存或磁盘驱动器。当交易完成时，只需将更动
的部份传回服务器。从Oracle角度，我们需要一打的预储程序处理，客户端的要
求，而客户端不会直接参考服务器中的Oracle表格。
这部分在第十一章会有更详细的讨论。
分布式数据库
分布式数据库（distributeddatabase）会将数据管理及相关数据，储存在一个以上
的服务器上。设计分布式数据库最重要的课题，就是在不同的服务器间，找到分散
数据最佳化的方法。数据分散的好处，在于能将数据置于较接近主要使用者，提升
执行效率，并且降低对单一服务器的依赖。有很多可行的技术可供选择。
有些数据很难分割（partition），唯一的解决方式就是将这些数据摆在同一台服务器
上。有些数据可能天生就适合被放置在不同服务器上，比如说，依照地理位置分布
的数据（像是国家或区域性的数据就可放在该区域的服务器中）。分割过的数据可
以从远程利用分布式查询取得，甚至可以透过多点同时更新的方式进行数据更新。
另外一种分割数据的作法，是将其它服务器上备份的数据设定成只读，而这些备份
称之为快照（snapshot）。虽然它会定时更新，但并不保证每次的资料都是最新的。
对于不需要在特定服务器上储存的数据，可以使用名为multi-master的技术解决。
这项技术允许各个服务器拥有同样表格，就像任何本地的数据可以随时更新。表格
的变更需要同步（也就是确认更新数据时，所有服务器的复本也能同时更新），或
异步（过一段时间再执行更新程序）更新其它副本。
Oracle利用SQL*Net支持数据库连结（databaselink）、二段式委任（two-phase
commits）、snapshot、read-onlysnapshot、及复制等功能。
38/第二章
在我们的例子中，决定在每个较大的地点（如主要的机场）配置一台服务器。当地
的数据库储存预备出租车子的细节。一旦车子出租时，车子资料及租约会马上传到
中央的服务器（因为我们不知道车子会在哪里被归还）。所有的账面（billing）资
料都来自中央服务器，但是考虑到效能，我们还是在当地的计算机中，复制一份只读
的资料。当地的税务信息则存放于当地的服务器中。我们将基于Read-only
Snapshot（如价格及一些参考数据）和异步复制（车子的数据库）的原则，设计
分布式纲要（schema）。这样的设计是，当中央服务器挂掉时，各地的租车地点不
会受影响。
关于这部分，在第十二章会有更详细的介绍。
资料仓储
有些应用软件需要处理复杂的管理报表，但在第一章租车公司的Moscow分析中，
曾提及管理报表必定不属于项目的内容。为什么呢？原因如下：
无法预期所有使用者想要的报表，即使身为决策者也面临同样问题。决策
是抽象且重复的领域，看完报表后，常会让人更想看到另外一种报表。
营运数据库（operationaldatabase），通常是针对交易型态的运作作最佳
化。复杂的报表通常需要利用不同表格完成，而且会大大降低整个系统的
运作效能。
数据仓储的概念是从营运系统中撷取数据，转换成更适合复杂查询的格式，并且储
存于可容纳大量成长、且不须存在于现行系统的历史数据数据库中。在此数据库
中，增加一种特别的查询工具，让使用者能够自由查询所需的信息。这样的数据库
跟传统的在线交易处理（onlinetransactionprocessing，简称OLTP）相当不同，有
许多像是维度分析（dimensionalanalysis）的新技术需要学习。
在我们的例子，公司管理阶层想要进一步了解租车市场整体变化及趋势。有时，某
地会在忙碌的工作天中，将某款的车子全部出租；甚至会出租所有的车子！因此，
公司能有效掌握供需、并且事先做好调度，是非常重要。
细节留待第十三章，再做进一步的讨论。
为什么「设计」如此重要？/39
平行处理
平行处理的精神，在于尽可能的使用所有硬件资源（像是CPU及储存装置，特别
是磁盘驱动器）。Oracle为了支持多CPU的机器，也提供一些特别设计。使用Parallel
QueryOption，可以把某些查询分成不同部份，再将每部份送交不同的CPU处理。
同样地，平行处理的技巧也可以应用于磁盘驱动器上，将读写的动作划分于不同磁盘驱动器
上。此时，我们必须确实知道系统的瓶颈在哪?，像是「产能及服务器负荷，会不
会比网络限制还大」的这类问题。
即使没打算使用平行处理功能，仍可遵循一些标准和基本规则。让我们看看租车公
司的例子。
租车系统所使用的平台（Platform），是配置四颗CPU及128MB内存的Unix伺
服器。每个月结帐时，服务器上不会有其它任何的活动。所以，在正常情况下，其
它三颗CPU几乎都处于闲置状态。因此，决定藉由分割待处理数据，交由不同的
CPU同步处理，以增加系统产能。当然，必须确定是不会相互影响，不然，这个
聪明小技巧就会失灵了。
我们还打算使用RAID1技术，提供单一硬盘毁损时的回复动作，避免因损坏造成
财务损失，这样还能带来同步读写的好处。
要知道更详细的平行处理技巧，请参阅第十三章。
为系统效能而设计
确保系统具备足够效能，是数据库设计的主要目标之一。一般来说，设计不良的
Oracle数据库执行效能很差，而且无法藉由更新硬件的方法来改善。修正设计不良
的系统，所需的代价就是重新设计，也就是将旧有设计完全抛除，重新开始。使用
者越来越无法忍受缓慢的反应时间，完全是由于PC软件发达，硬设备不断改
进，人们认为系统效能也应增加才是。
Oracle注意到对高效能的需求，以及硬件技术不断进步，因此，设计Oracle
ParallelServer，以便在大量的平行处理系统发挥功效。在这种架构下，有些益处
是不容置疑，其它仍须小心的设计。
40/第二章
如果没有修好错误设计，系统将会付出极大代价，因为使用者会认为这套系统非常
差劲。许多使用者会对系统持疑，是因为以前就是使用相当差的系统。
几乎所有的设计层面都会对系统效能造成影响，在接下来的章节中，我们将讨论一
些较关键的因素。
Key和索引
我们必须小心选择表格的key以及索引（Index），将应用软件用到的数据列入考
量。此外，必须检视所有的模块，询问使用者较常查询那些类型的数据。我们必须
在查询（query）和新增（insert）／修改（update），取得很好的平衡点-因
为，表格加入的索引越多，当新增、更新、甚至删除纪录时，Oracle要作的事（维
护资料）就越多。所以，在执行包含许多新增、修改、或删除的批次作业时，应先
考虑除去一些索引。
在某些情形下，数据的放置位置对系统效能有相当大的影响。也许我们应当考虑将
数据丛集于key值的附近，具有相同key值的数据自然地就会很接近。另外，常藉
由特殊的uniquekey存取静态表格时，我们可能会使用一个hashcluster。
在我们的例子，我不认为有合适的丛集，不过，仍希望藉由在表格中增加额外的索
引，提升查询速度。举例来说，我们在RENTAL_CARS表格（RENTAL_CARS的主键
是CAR_ID）的REGISTRATION_NUMBER字段上，建立索引，如此一来，当我们想
用uniquekey找寻车子的时候，便可很快找到。
第六章会对key以及索引有更深入的探讨。
反正规化
反正规化（denormalization），是如何在数据库中选择重复储存数据的一门艺术。
假如信息可以从其它地方衍生而来，就称为redundant（重复）。到目前为止，最
常见的是在父纪录上记录子纪录的总和等数据，就不需要重新计算所有的子纪录。
至于，在key的选择上，反正规化的诉求是：在加快查询及降低数据维护速度上取
得平衡。
为什么「设计」如此重要？/41
有时候，除了反正规化外，还有其它的选择方案。假使报表必须全面的反正规化才
能改善速度，可以先将相关的数据，事先拷贝到暂时的表格?，就可以很快的产生
报表了。
范例中，我们在CUSTOMERS表格中增加OUTSTANDING_INVOICE_AMOUNT栏
位，代表顾客在INVOICES表格中，所有STATUS不是PAID的INVOICES_AMOUNT
的总和。因此，查阅顾客所有的发票，便能很快作信用查询。我们在INVOICES上建
立触发程序（trigger）来维护这个值。比如说，当STATUS更新为PAID时，
CUSTOMERS表格中属于该客户的OUTSTANDING_INVOICE_AMOUNT，便会自动扣
除INVOICE_AMOUNT。
第四章会更详细介绍反正规化的观念。
选择最佳化处理器
Oracle7提供两个最佳化处理器（optimizer），提供SQL查询最佳化不同的取向。
以往rules-based取向使用一系列规则，决定该采用什么样的存取路径（access
path），而cost-based则试图使用较聪明的方法：数据库大小及数据分散程度透过
它作决定。
也许，你会认为应能在这两种模式之间自由的切换，而不需要担心系统如何设计。
但事实上，仍须选择其中一个作为设计的基础，因为你已经知道哪一个才是最佳化
的路径，此时要能引导系统走向这个路径。
因为租车系统是全新的系统，不需采用旧程序，所以我们选择使用cost-based取
向。如果系统?数据的分布改变很多时，我们所选择的optimizer应该会自动的跟
着改变。
第六章将会有更详细的讨论。
程序设计技巧
先前提到系统效能技巧，大部份集中在数据库，但是我们还要看看设计程序时，需
要注意什么。在讨论主从式架构的时候，已经稍稍提过。比如说，我们会把共通及
经常存取数据库的程序，放在预储套件（storedpackage）及程序（procedure）
中。还决定把不常变动的数据放在本地的cache以加快速度。
42/第二章
也许还可以考虑如何减少客户端及服务器端间呼叫的次数。比方说，大部份Oracle
提供的工具能让你使用数组接口（arrayinterface），在单一查询（或其它修改、删
除等）中处理整个数组的数据域位。
其它设计上的考虑
这一节将讨论，在决定数据库设计上作时，需要考虑到关连式数据库的其它特性。
超大型数据库（简称VLDB）
现今大部份的数据库都要处理数亿或数兆的数据。数据逐年增长，但不该对系统产
生严重影响。数据库及数据本身必须能随时被适当管理及控制。不管是多有经验的
DBA，都无法弥补设计不良，无法处理高数据容量的数据库。
幸运的是，Oracle可以处理庞大的数据库，而不会对系统有显著影响。设计师在此
扮演的角色，是要能决定数据对象的适当大小，以及决定最适切数据可能增长的空
间，使得数据增长不会造成问题。
与时间序列有关的资料
因为关连式数据库将数据储存在表格中，因此数据本身就具有二维的本质。当你试
着想加入更多的维数时（也就是变成多维的数据），就得作调整。如果没有适当的
调整，系统就不会产生预期结果，或是需要很长时间才能得到正确结果。最糟的
是，甚至花好长时间却换来错误结果。
最常需要增加的维度就是时间。我们常常需要在更新一个字段时，将旧数据记录下
来，以保有该笔纪录的完整历史（history）资料。这样我们就能够使用过去数据，
查核或是执行交易（比如说，以上个月的价格开列账单），特别是在表格中加入像
DATE_TO及DATE_FROM的字段。不要被这看似简单的作法所欺骗了，蕴含许多
复杂的机制，在第七章会有更详细的讨论。
在租车例子中，我们在BILLING_RATES表格中增加一对字段（DATE_TO、
DATE_FROM），可以在需要的时候重新计算过去的账单。
为什么「设计」如此重要？/43
与其它系统连结
不幸的是，少有项目是从头开始，也就是说，接项目的时候，需要处理旧系统遗留
的资料。这些数据有可能是参考用的，也有可能是交易数据，或者两者都是。同样
地，计算机系统也不是一个与外界隔绝的世界?，通常都需要与其它外部系统作数据
交换。
数据交换有许多方法。使用档案交换数据到现在仍很普遍；提供数据的系统将数据
储存到固定格式的档案上，传送到接收数据的系统中，接收端再使用应用程序读取
并更新数据。但对现今的数据库，就不用这么麻烦了。透过某个接口直接读取资
料，再写到另一个系统上。但是，每个接口都需要仔细的评估，决定该数据应以何
种方式传送。当然，前提是接收端是否需要实时的数据。如果我们将数据在夜间传
送过去的话，就代表该数据是过期（二十四小时）的了，对于变动性的数据，这种
做法是不能被接受的。
在第八章将更进一步地探讨这个问题。
现在，让我们再回头看看租车的例子。旧系统留下具固定长度、旧系统产生的最简
单元格式的资料。当新系统上线时，会有一组和会计系统连结的中介表格。我们会设
计「快速还车」的功能，方便行程较匆忙的客户快速还车。只要在租赁契约?多填
一点数据，就可以完成还车手续。而我们只需使用条形码机及OCR（光学辨识系统）
将数据存入档案，并于夜间将数据加载系统中。
针对Oracle7设计
如同先前提到的，设计是为了能够使用所有的资源及技术。当你特别针对Oracle设
计时，会发现不同版本会对系统设计决策产生重大影响，因为越新的版本拥有越多
的功能。
本书假设你在Oracle有相当程度的经验。所以，这个章节不会试图完整描述
Oracle，仅是简单介绍会对系统有重大影响的功能，以及为何如此重要。
44/第二章
注意如果你对Oracle7相当了解，你可以跳过这个章节，不过请
先确定你已经很熟悉底下的名词。
触发程序及预储程序
Sharedpool
Bufferpool
宣告式限制（Declarativeconstraints）
只读（Read-only）tablespaces
对称式复制（Symmetricreplication）
手动分割（Manualpartitioning）
须注意，现今有许多Oracle客户，同时在不同服务器上使用Oracle不同版本，要
他们使用一致的版本是相当困难。也就是说，在任何时刻，不同地方，会有不同的
版本运作着，甚至同一台服务器上也可能有不同的版本共存。有许多原因造成这样
的结果，所以，最简单、也最常见的方法就是，当客户要使用新版本前，须先经过
测试。
更复杂的情况是该客户拥有多种不同的平台，而Oracle对于各个平台版本发行的
时间并不一致。事实上，还有一些平台从未出现某些版本。
Oracle最大的特色，就是旧版本能与新版本兼容。Oracle花了相当时间确定新版本
能与旧版本兼容。兼容的问题通常出现在Oracle5与Oracle6之间。对大多数读
者来说，这已经是历史事件了。虽然外头仍有某些地方还在使用Oracle5，像我们
知道在一九九六年六月时，在欧洲仍有许多的Oracle5，原因是仍能达到运行效能
的需求，因此没有理由改版。
不过须注意，当新的版本有任何改变时，比如说在SQL语言中增加一个保留字，
你会有两种选择：一是执行兼容模式（使一些新的功能失效），或者确定该保留字
并未出现任何对象或字段名称中。
为什么「设计」如此重要？/45
在底下的例子，我们不考虑软件授权的问题（虽然有许多功能是要多付点钱才有
的），而且Oracle付费规定会改变，因此建议在使用某些功能之前，能够事先检查
自己的版本有没有授权该项功能。
版本7.0
这一节将会简要提及Oracle7，对设计造成重大影响的关键功能。
触发程序、程序、以及函式
原始的Oracle7版本中，导入能在数据库引擎中、储存并执行程序代码的概念。触发
程序（trigger）是位于后端的程序代码，可用来处理表格，而程序（procedure）及函
式（function）则可以由客户端的应用程序透过PL/SQL来呼叫执行。
PL/SQL是Oracle专有的可携式3GL【译注：可以在不同平台的Oracle上执行】。
PL/SQL在Oracle6到Oracle7之间加入许多功能，但能做的事仍很有限。虽说
PL/SQL的一些功能很吸引人，可以有效建构数据规则和企业法则，但是缺少开发
一套完整应用程序的强大功能及弹性。
从架构来看，PL/SQL引擎是独立于SQL引擎，其它如OracleForm及Oracle
Report，也可以使用PL/SQL。
Oracle7数据库设计的关键要素，就是能有效分配前端及后端该做的事。
Cost-basedoptimizer
Oracle7还导入Oracle的cost-basedoptimizer（在前章有提到，以成本为基础的最
佳化处理器），及新的SQL指令ANALYZE来取得统计数据。虽然新的optimizer
带来一些好处，但是却没有达到许多客户的需求，因此他们仍继续使用旧的rules-
basedoptimizer。这一版的optimizer没能将key值的分布状况考虑进去，并且没有
执行查询的成本模型（costmodel）。
46/第二章
Cost-basedoptimizer最大的特色，就是允许程序设计师提供optimizer提示（hint）
来执行查询，不像前版Oracle使用暧昧的方法。即使有适当的索引，还要扫描整
个数据库的数据（fulltablescan）时，传统的作法是：
SELECTe.employee_name
FROMemployeese
WHERENVL(e.division,NULL)='SALES'.
而cost-basedoptimizer则使用更合理的方式达到同样的效果：
SELECT/*+FULLE*/e.employee_name
FROMemployeese
WHEREe.division='SALES'.
第二种作法在效率上有显著的好处，因为它不会执行多余的函式（此例为NVL）。
并不是SQL函式特别没有效率，只因它是直译式语言，因此应该避免执行多余的
函式。
注意附带一提，大部份的书及Oracle课程都建议使用字符串连结或
加法来避免使用索引。比如说：
WHEREe.division||''='SALES'
或
WHEREe.deptno+0=30
但是，在我们所测试过的Oracle版本中，都发现NVL函式比
字符串连结或加法，都要快的多。
能够控制查询的最佳化，对设计师来说是一大福音。有时设计师必须避开某种程序
结构，以免系统效能变差，控制最佳化就可以少了这层顾虑。但如同先前提到，要
想得到这个好处，必须等到Oracle7.3以后，才能够使Optimizer考虑数据分布的
情形。
Oracle7对于分布式join的最佳化有相当的改变，也解决一些重大的系统效能问
题。
为什么「设计」如此重要？/47
宣告性限制
除了能在表格中定义触发程序外，以及之前NOTNULL的限制外，Oracle7还增加
宣告性限制（declarativeconstraint）。虽然Oracle6中已经支持这个延伸功能，但
并没有实际强制执行。令技术人员惊讶的是，自从Oracle7引入这个功能后，数据
库设计师和DBA却不愿意使用。
使用宣告性限制将对系统设计有重大影响，特别是用FOREIGNKEY的constraint，
将会影响设计查询或参考的表格。虽然宣告性限制对数据整合重要贡献，它们却是
在命令层次（commandlevel）、而非交易层次（transactionlevel）执行，发生所谓
的「暂时性的冲突」（interimviolation）。
分布式数据库
Oracle7还增加两段式委任（two-phasecommit，简称2PC，用来确保正确更新及
删除数据），以便SQL*Net的DML（INSERT、UPDATE、DELETE、LOCK、SELECT
FORUPDATE）支持分布式数据库的运作。这么做相当有用，但却因为许多理由不
常被使用，我们会在第十二章讨论这些问题。各地对分布式系统网络拓蹼结构，及
分布式资料分布的研究，对Oracle是一个崭新的研究方向。
在这个版本，首次导入新的数据库对象-快照（snapshot），可以将地点已改变
的数据定时传送到其它地点，对系统造成一定程度的负面影响，我们将在稍后的版
本中提到。
服务器的效能
Oracle7还提到解决6.0版的系统效能，并对SQL引擎管理高速缓存的方法作了
重大改变。
对SQL，Oracle总是使用动态、非静态的配置。也就是说，SQL指令的执行计划
（executionplan）是在执行时（runtime）才被决定，而不是在准备（preparation）
阶段。因此，每执行一个SQL指令，数据库引擎总是会先决定该指令应该在那?
执行达到及最佳化。
48/第二章
7.0版引进一个新的概念-sharedpool。使用者能够使用其它人建立的执行计
画。如在客户端的程序执行一连串的步骤，则可完全感受这个功能所带来的好处。
从主从式的架构来看，Oracle较早期的版本总是传送太多的网络交换讯息，因此
7.0版正式导入复合式呼叫（compoundcalls）。这个功能将在第十一章有详细讨
论。
其它重要的功能
许多Oracle7新的功能，我们将探讨两个对系统设计产生重大影响的功能。
第一个是支持binarylongobjects（BLOB），能在单一字段中储存超过2GB的资
料。BLOB让我们能储存像是图形或是文字处理的档案，而不需将这类数据分散到
多个字段。虽然，7.0版只可读取一小部份的数据，但是整个BLOB仍需一次完成
新增（insert）的程序，因此，实际上仍有大约1MB的长度限制。在整个资料空
间管理例行程序（routine）无法最佳化处理BLOB的情况下，未来可能会有效率的
问题。
第二个改进的地方则是在系统安全方面，增加「角色」（role）以及profile。这么
一来，对系统要求不高的应用程序，安全控管子系统的设计会较容易，问题也较
少。与数据有关的安全问题（比如说，某个使用者只能够看到某些单位的薪资），
则仍属于应用程序设计的范畴。
版本7.1
基于Oracle7，7.1则增加许多与设计师及管理者取向的功能，对系统设计都有高度
的影响。
PL/SQL中的动态SQL
7.0版可以用PL/SQL预储程序（storedPL/SQLprocedure），包装应用程序的功
能，也就是客户端只需启动单一的程序，而不需要执行所有SQL命令，就可达到
同样的功能。更新变得相当简单，但查询就变得很没效率，无可避免的，客户端必
须指定选择的限制（selectioncriteria）。PL/SQL程序包含一组相当大、且需要执行
为什么「设计」如此重要？/49
的SQL查询指令，为了要解决这个问题，Oracle7.1可以让storedPL/SQL
procedure执行真正的动态SQL。程序可以自行在VARCHAR中建立自己的SQL指
令并执行之。
这样的作法，无疑是搭起前端应用程序和后端数据库之间友谊的桥梁。喔...不，是
中介层（middlelayer），免除应用程序对数据库结构的相依（dependency），也更容
易地移植到其它的DBMS上。
多重触发程序
为了应付复杂的确认及各个程序之间的交错讯息，我们会使用越来越多表格层次
（table-level）的触发程序。但是这样很可能会导致，使用者增加手稿（script）时
的失败，因为新增的触发程序可能与已存在的触发程序发生冲突。7.1版为了要解
决这个问题，允许一个事件可以有许多同时发生的触发程序。可以保证在同样的表
格上，所有触发程序会各自将数据改变的讯息传送出去。
这项功能的主要理念，是要将个别的商业或数据确认规则，对应到个别的触发程
序，而不要将许多不相关的规则合并到单一的触发程序中。
SQL中的PL/SQL函式
如同先前提到的，PL/SQL引擎是自外于SQL引擎的。在7.1版中，可以在SQL
当中呼叫PL/SQL函式。举例来说：
CREATEORREPLACEFUNCTIONcube(xINNUMBER)
RETURNNUMBERIS
BEGIN
RETURNx**3;
END;
可以扩充成SQL语言查询的型态：
SELECTe.emp_name
,e.basic
,t.gross
FROMemployeee
50/第二章
,emp_year_totalst
WHEREe.emp#=t.emp#
ANDt.year=1995
ANDt.gross>=CUBE(e.basic)
ORDERBYt.gross/e.basicDESC;
这会造成一些潜在问题，因为PL/SQL有永久性套件变量（persistentpackage
variable），发出DML命令。Oracle提供宣告PL/SQL函式的puritylevel的功能，
puritylevel可用来控制可能造成的后果，比如说改变数据库结构。
如果你要在SQL中使用PL/SQL，那就应该在数据库设计时期就作好测试。我们
建议不要在SQL指令中使用PL/SQL，除非它们确实是专门设计用来呼叫SQL
的。
只读的tablespace
Oracle在数据文件的开头，都会有一个用来告知数据库，在合法启动时，哪一个是
必须使用、且最旧的redolog的标头区（headerblock）。7.1版以前，这个意思
是：不管数据是否曾被更改过，所有的数据都必须定时的备份，不然，在系统回复
（recovery）时，Oracle会坚持从最旧的log档案开始处理。
为了减少备份及缩短回复时间，7.1版本提供能设定tablespace为只读（readonly）
状态的功能。一旦将tablespace备份后，就不需要再重新备份，因为回复的程序知
道该数据在备份后不可能被更改，也就不去处理这个档案。对大型的数据表格而
言，这种作法相当理想，而且也减少将近百分之九十的备份容量。缺点则是要将资
料设定成只读时，可能需要将数据分割（partition）才能够达成。
在设计实体数据库的位置时，可能希望区分出易变或不易变动的资料，而将较不易
变动的资料放置于只读的Tablespace中。当你和DBA一起规划备份计划时，别忘
了考虑此放置地点。
为什么「设计」如此重要？/51
PQO
Oracle具有合理的可扩展性架构。除了系统本身需要处理的读写工作外，使用者都
有单独的Oracleserver进程。可以在对称式多处理器（symmetric
multiprocessing，简称SMP）环境下，分配到所有可使用的CPU上。但是，对执
行一个既大且复杂的SQL查询进程，就没有太多效果。在7.1版中，平行查询选
项（parallelqueryoption，简称PQO）就可以将单一的fulltablescan查询，分布
在各个CPU上执行。PQO的功能可以查询任何型态的fulltablescan，达到CPU
及磁盘读写动作百分之百的使用率。
当你在设计批次进程及复杂的报表时，应该要检视哪些模块可以使用这项功能，并
且决定最适合该平台数目的进程。还需要与DBA讨论，如何将表格拆开，分散到
不同的磁盘上。
PQO对索引建立的时间，具有戏剧性的影响。
在第十四章，我们会针对这个功能做进一步的介绍。
版本7.1.6
版本7.1.6导入了一些对于系统设计会有影响的功能。
对称式复制
7.1.6版支持Oracle的对称式复制（symmetricreplication），也就是允许同样数据
的备份可以在不同地点独立更新，并且以异步的方式，将变动的数据传到其它备
份上，具有侦测冲突数据及解决的功能。
在分布式的环境中，我们必须要确定哪个复本执行了命令，所以Oracle建立了一
套RepCat（replicationcatalogue）程序，用来维护分散在各个不同复本的数据字
典（datadictionary）物件。
数据改变的传送方式，是使用异步的RPC（remoteprocedurecall，远程程序呼
叫）。利用二段式委任来确定，数据在不同备份上的完整性。这个功能也可用在资
料库服务器中，执行PL/SQL使用者应用程序代码。
52/第二章
第十二章详细介绍在使用异步更新设计时，需要考虑的问题。希望你能知道非同
步的运作不能是一个查询：原因在于它没有办法回答原呼叫者任何查询的结果，已
继续完成其它工作。
Sharedpool
较早的Oracle7版本面临管理sharedpool的问题。对于这些问题的深入研究并不
在本书讨论的范围内，而是在触发程序被放在高速缓存的方式，及pool会越来
越零碎的情形。
先前也提过，触发程序最主要的功能，就是在数据被更动时，执行辅助动作。大概
也可以猜想，Oracle对称式复制功能将使用许多触发程序，而它可能对sharedpool
所造成的影响，在这个版本也作了处理。
版本7.2
这一节将讨论7.2对系统设计的重大影响。
手动分割
版本7.2新增了手动分割（manualpartitioning）数据分割方式。简单地说，7.2版
的查询最佳化处理器，在某些限制下，可以延迟执行join的动作到UNIONALL
型态的视界（view）下。
假设有两个表格（ORDERS及OLD_ORDERS），有着一样的字段及索引，而我们
定义一个叫ALL_ORDERS的视界如下：
SELECT*fromORDERS
UNIONALL
SELECT*fromOLD_OLDERS;
查询为：
SELECTc.cust_name,o.order_date,o.order_value
FROMcustomersc
,all_orderso
WHEREc.zip=12345ANDc.cust#=o.cust#;
为什么「设计」如此重要？/53
将会用以下方式执行：
SELECTc.cust_name,o.order_date,o.order_value
FROMcustomersc
,orderso
WHEREc.zip=12345ANDc.cust#=o.cust#
UNIONALL
SELECTc.cust_name,o.order_date,o.order_value
FROMcustomersc
,old_orderso
WHEREc.zip=12345ANDc.cust#=o.cust#;
在早期的版本，这个视界在join之前就被初始化。视界的初始化需要先建立暂时
的表格，执行建立这个视界所需的join和运算。但是，对大型表格中执行高选择
性的查询，会产生很糟的效能。
这个功能对设计多维表格（比如，时间性（temporal）或空间性（spatial）的数据）
时，有特别重要的影响，因为它们经常使用「手动分割」这种技巧。这个技巧对设
计存盘（archive）资料策略也特别有用，因为经常需要同时处理存盘及目前资料。
PL/SQLscheduler
7.2版中包含PL/SQLscheduler（排程器），允许使用者或开发人员设定定时启动的
PL/SQL工作。这可以解决Oracle7子系统缺少定时处理批次作业的问题。
不需等待响应的程序呼叫接口（Nonblockingcall）
另一个设计师最想要的功能，便是不需任何响应，就可以让Oracle工作。在7.2
中，是以nonblockingcall的方式，出现在OracleCallInterface（OCI）中，也是
C/C++最常使用的接口。
多年前，当Oracle推出第一版的precompiler时，可以将SQL呼叫码直接写在C
及COBOL这类3GL中。当时，Oracle就宣称想要放弃支持OCI的意图。由于许
多技术上的因素，这个想法遭到开发Oracle软件的厂商强力反对，最重要的理由
是OCI可以让函式将数据库的cursor（指针），以参数的型态传给另一个函式，这
54/第二章
样就可以设计通用的函式，处理任何cursor。7.0版的Oracle更改一些内部结构，
OCI便有了最新的功能。尔后，7.2版又增加nonblockingcall的功能，这意谓着又
多一个只能透过OCI呼叫使用的重要功能。
当一个应用软件同时连接数个instance时，希望同时在所有instance执行一些动
作，nonblockingcall特别有用。还能让GUI设计师在使用者等待系统响应的时
候，显示动画转移使用者的注意。
使用OCI的代价就是开发的成本。一般来说，就算是同样的程序代码，使用OCI都
会比使用Oracleprecompiler还长。此时，必须要衡量使用OCI的好处和代价，甚
至考虑同时使用两个方法。早期Oracle版本，执行使用OCI编译的程序，会比
Pro*C或Pro*COBOL所产生的程序慢上好几倍。虽然这个问题已经在7.0版解决
了，但是使用者仍不会因为使用OCI、而增加系统效能。
版本7.3
7.3版引进相当多新的功能。事实上，Oracle已经说明7.3版不被称为Oracle8的
唯一理由是因为，Oracle8已经被保留作为对象导向化的名称。
Sharedpool
Oracle7.3重新设计sharedpool，不仅在数据字典中管理触发程序，并且改善预储
程序的高速缓存管理。这么做解决许多效能上的问题，特别是有关触发程序及预
储程序方面的问题。
数值分布状况
7.3版的cost-basedoptimizer能读取每个作为索引字段数值的分布状况，甚至那些
未作为索引的字段也可以。这个功能是不错，但也引发至少三个问题：
第一，数值分布状况（valuehistogram）是以字段值，而非key值作为数值分布状
况。当然，对于单一字段的索引来说，这两者是一样的，但是，对复合索引
（concatenatedindex）所代表的意义就大不相同了。如此一来，cost-basedoptimizer
为什么「设计」如此重要？/55
会在某些情况无法得到正确数据作判断，而不知道是否使用复合索引。常见的例子
就是，被当成索引的第一个字段数值分布会很平均，但是复合索引的数值分布却呈
现高度的集中（highlyselective）的状态。
第二，7.3版查询最佳化处理器仍然没有好的模式，可以将CPU执行SQL指令的
负荷考虑进去。即使使用索引搜寻，速度会较快，早期cost-basedoptimizer的版
本仍常使用fulltablescan。在7.3.2版一系列测试中，某些使用索引搜寻会比较快
的情况下，optimizer采取fulltablescan搜寻方式；相反的情况也会发生，像是使
用fulltablescan搜寻方式会较快的情况下，这版的optimizer有时会使用索引搜
寻。（那还不如不要optimizer）。
第三，Oracle在使用连结变量（bindvariable）查询时，并没有使用字段数值的分
布作最佳化。比如说这种查询：
SELECTCOUNT(*)FROMtradesWHEREcurrency='NOK'.
如果我们知道NOK的数值分布（如NOK的值出现不到1.25%），要对这样的查询作
最佳化就很简单。但如果同样的数值分布告诉我们USD的值出现超过85%的话，
那么对于底下的查询就没有正确的最佳化方法。
SELECTCOUNT(*)FROMtradesWHEREcurrency=:curr;
而且，还必须在选择存取方法之前，先知道连结变量的值，才可以选择好的读取方
案。这是一个特别的问题，因为多年来，程序设计师发现使用连结变量（如上例中
的:curr）是较好的方法，节省SQL指令解析的时间、且提升sharedpool。这是
因为Oracle保持传统最佳化的方法-在第一次执行前，先对个别的SQL指令
作最佳化，后来的执行则会使用同样的查询计划（queryplan）。
无限制的延展空间
7.3版数据库所有的对象（包括表格、索引、丛集、rollbacksegment、temporary
segment）都可有不限的延展空间（unlimitedextent）。对于DBA来说，特别有帮
助。对设计师，这个功能则减少在空间配置上，可能发生错误的后果。
56/第二章
Bitmap索引
7.0版之前的Oracle只支持B-Tree索引。7.0版本则加入Hashcluster，但对设计
师来说，并没有明显的吸引力。Hashcluster似乎很少人在用，而且有人说使用
后，并没有得到预期效能。
在7.3.3版中，Oracle在服务器中支持bitmap索引（在SQL*TextRetrieval产品中
已使用好几年了），这对字段中可能出现的数值很少时，特别有效率（例如，指向
代码表格的外来键（foreignkey）），特别是在WHERE子句中使用AND运算的时
候。
新的join策略
Oracle对于equijoin【译注：equijoin就是在WHERE子句中为WHEREX=Y形式的
join】的传统join方式是使用巢状循环（nestedloopjoin）以及排序合并（sort
mergejoin）。这两种方法都相当有效率。但在某些情况下，如数据仓储及OLAP应
用程序，就有相当差的效能。
7.3版，Oracle提供「starjoin」及「hashjoin」的功能。查询最佳化处理器可以选
择分别使用两者或者同时使用。
Starjoin是将许多要查询的表格join成fact表格，这些要查询的表格和join后的
大表格间，存有关连性的条件。但是，每个表格不是由其它表格合并而成的。Star
join正是利用这种缺乏相互关系的条件，从要查询的表格中，产生含有所有合格资
料列（row）的卡式积（Cartesianproduct），然后，再join到fact表格上。Star
join非常适合数据仓储的应用。
有时候，从数据量的角度看，hashjoin相当好用。因为hashjoin让数据库引擎利
用hashing的技术来代替执行完整的排序，然后再执行合并的工作。
在一般应用程序中，也可透过手动方式使用starjoin，只要在一个自行定义的表格
?，建立各个表格的卡式积。在某些特殊的情况下，可以得到许多效能上的好处，
而且比传统Oracleoptimizer采用的方法好的多。
为什么「设计」如此重要？/57
网络运算架构
自从Oracle从原本的SQL*Net发展出网络产品后，它们的通讯能力扩张到不仅可
以执行客户端发出的SQL指令，还能够传递远程过程调用（remoteprocedure
call，简称RPC）。
在新的网络运算架构（NetworkComputingArchitecture，简称NCA）（如图2-1）
中，Oracle发行一系列接口标准，让卡匣（cartridge）或namedservice回应其它
卡匣的请求。这些卡匣（含括传统的客户端及服务器），并不是以阶层式的架构存
在，而是在共同连接层中相互运作。显然地，这与WWW概念类似。事实上，Java
也是可以作为撰写卡匣的语言。我们还期望Oracle会将本身NetworkComputer
（NC）提升为主要的使用者接口装置，来执行用Java写的卡匣。
图2-1：Oracle的网络运算架构
也许对设计师来说，更感兴趣的会是能透过PL/SQL呼叫，对其它的卡匣作请求
（request）。这个功能对本书是相当新的，因为我们未能有机会使用这种功能建立一
些东西。不过，它似乎提供一个弹性的方法，让我们能够从Oracle呼叫任何卡匣
的服务。因为，传统的设计限制我们只能使用SQL或PL/SQL才能够呼叫其它
Oracleinstance，且必须透过Oracle的gateway服务，才能呼叫其它数据库引擎。
58/第二章
许多厂商已经和Oracle签约，作为开发各种卡匣的协力厂商，我们对这样的发展
相当感兴趣。写本书第二版时，相信会有许多关于使用数据卡匣（datacartridge）
的心得，以及许多使用Oracle8新功能优缺点的描述。
Oracle8简介
许多Oracle观察者，预期在一九九六年十一月旧金山，举行联合OracleOpen
World及InternationalOracleUserGroup的会议中，Oracle会发布有关Oracle8的
讯息，但是该会议中却没有有关Oracle8的内容或是发行日期。虽然许多客户及协
力厂商拥有Oracle8的beta测试版，但经验告诉我们，正式版通常和beta版相差
甚远。有些beta版中的功能很可能会因为反应不良而腰斩，更有可能会因为使用
者的关系，而有较大改变。基于这个原因，我们强烈建议设计者不要将beta版的
功能作为决策的基础。
这些建议对Oracle8来说，更显得重要，因为Oracle8许多新功能，主要是设计用
来支持比现行更大的数据库。更让人期望的是Oracle8应该会在SQL中支持对象
导向（ObjectOrientation，简称OO）。
分割
这个版本最重要的新功能是，能宣告key-partitioned表格。Key-partitioned表格是
指，将逻辑的表格定义成为一些字段与限制（constraint），定义一些实体的分割
（partition）储存该表格，并指定一个固定范围的值作为partitionkey。在本书，我
们会提供一些参考的步骤，协助Oracle7的设计师达到许多分割表格（partitioned
table）所赋予的优点。显然地，如果能在数据库服务器中直接支持是最理想的。最
主要的目标是要将partition（而不是表格本身）作为recovery（回复）的基本单
位，并且让分割索引配合optimizer来得到索引结构的最大好处。
这里有个问题是，uniquekey必须在表格层次（level）中执行，而非分割层次。假
如partitionkey（决定一笔数据储存在那一个partition当中的字段）既是主键
（primarykey）、也是其它所有的唯一键（uniquekey），那就没有太大的问题。但如
果不是这种情形，就需要一个表格层次的索引保证字段的唯一性。
为什么「设计」如此重要？/59
作为一个设计师还是会有需要妥协的地方。在本例中，必须在表格层次索引的缺点
（建立的时间、所需要的空间和单一节点损坏，会对所有partition造成影响），及
不使用限制（constraint）可能破坏数据整合性上做一个决策。
对Oracle7的向前兼容性
目前我们发现唯一一个潜在性兼容问题，是rowid的格式作很大改变，以至于现在
有两种rowid格式（format）。较短的格式是用来参考已知名称的表格中的一笔资
料列（row）；而较长的格式则用来参考数据库中的任何一笔数据。
虽然这些改变一定会造成很多DBA所写的手稿（script）无法继续使用，但是应该
只有少量的应用程序会用到rowid的内部结构。较短的格式（通常会伴随着
SELECTROWID...FORUPDATE出现）可以储存在旧格式中的18byte。那些使用
rowid内部格式的应用程序大概都应该值得升级到Oracle8吧！
但是...
再重复一次，在Oracle8这节开头所提到的讯息，虽然乍看下非常的吸引人，但是
你必须要在将它们应用到项目前考虑清楚。至少在应用到成品之前，必须先等到
Oracle发行正式版，并且在实际的营运环境下运作测试过，才能预期它们所带来的
影响。
那么本书当中Oracle7的内容怎么办？会不会被Oracle8所取代？我们现在的感觉
是Oracle8并不会造成本书的内容有太大的改变。但我们希望新功能能够对你的设
计问题提供更好的解决方案。
60/第二章 |
|
IP卡
狗仔卡
发表于 2011-4-8 15:20
收藏
提升卡
置顶卡
变色卡
显身卡
发表于 2011-4-8 15:27
楼主
