http://tech.ccidnet.com/zt/she/
超大型Oracle数据库应用系统的设计
一、概论
超大型系统的特点为：
1.处理的用户数一般都超过百万，有的还超过千万，数据库的数据量一般超过1TB；
2.系统必须提供实时响应功能，系统需不停机运行，要求系统有很高的可用性及可扩展性。
为了能达到以上要求，除了需要性能优越的计算机和海量存储设备外，还需要先进的数据库结构设计和优化的应用系统。
一般的超大型系统采用双机或多机集群系统。下面以数据库采用ORACLE 8.0.6并行服务器为例来谈谈超大型数据库设计方法：
·确定系统的ORACLE并行服务器应用划分策略
·数据库物理结构的设计
·系统硬盘的划分及分配
·备份及恢复策略的考虑
二、ORACLE并行服务器应用划分策略
ORACLE并行服务器允许不同节点上的多个INSTANCE实例同时访问一个数据库，以提高系统的可用性、可扩展性及性能。ORACLE并行服务器中的每个INSTANCE实例都可将共享数据库中的表或索引的数据块读入本地的缓冲区中，这就意味着一个数据块可存在于多个INSTANCE实例的SGA区中。那么保持这些缓冲区的数据的一致性就很重要。ORACLE 使用 PCM（ Parallel Cache Management） 锁维护缓冲区的一致性，ORACLE同时通过I DLM（ 集成的分布式锁管理器）实现PCM 锁,并通过专门的LCK进程实现INSTANCE实例间的数据一致。
考虑这种情况：INSTANCE1对BLOCK X块修改，这时INSTANCE2对BLOCK X块也需要修改。ORACLE并行服务器利用PCM锁机制，使BLOCK X从INSTANCE 1的SGA区写入数据库数据文件中，又从数据文件中把BLOCK X块读入INSTANCE2的SGA区中。发生这种情况即为一个PING。PING使原来1个MEMORY IO可以完成的工作,变成2个DISK IO和1个 MEMORY IO才能够完成,如果系统中有过多的PING，将大大降低系统的性能。
ORACLE并行服务器中的每个PCM锁可管理多个数据块。PCM锁管理的数据块的个数与分配给一个数据文件的PCM锁的个数及该数据文件的大小有关。当INSTANCE 1和INSTANCE 2要操作不同的BLOCK，如果这些BLOCK 是由同一个PCM 锁管理的,仍然会发生PING。这些PING称为FALSE PING。当多个INSTANCE访问相同的BLOCK而产生的PING是TRUE PING。
合理的应用划分使不同的应用访问不同的数据，可避免或减少TRUE PING；通过给FALSE PING较多的数据文件分配更多的PCM锁可减少 FALSE PING的次数，增加PCM锁不能减少TRUE PING。
所以, ORACLE并行服务器设计的目的是使系统交易处理合理的分布在INSTANCE实例间，以最小化PING，同时合理的分配PCM锁，减少FALSE PING。设计的关键是找出可能产生的冲突，从而决定应用划分的策略。应用划分有如下四种方法:
1.根据功能模块划分，不同的节点运行不同的应用
2.根据用户划分，不同类型的用户运行在不同的节点上
3.根据数据划分，不同的节点访问不同的数据或索引
4.根据时间划分，不同的应用在不同的时间段运行
应用划分的两个重要原则是使PING最小化及使各节点的负载大致均衡。
三、数据库物理结构的设计
数据库物理结构设计包括确定表及索引的物理存储参数，确定及分配数据库表空间，确定初始的回滚段，临时表空间，redo log files等，并确定主要的初始化参数。物理设计的目的是提高系统的性能。整个物理设计的参数可以根据实际运行情况作调整。
● 表及索引数据量估算及物理存储参数的设置
表及索引的存储容量估算是根据其记录长度及估算的最大记录数确定的。在容量计算中考虑了数据块的头开销及记录和字段的头开销等等。表及索引的initial和next存储参数一般设为相等，pctincrease设为0。
● 表空间的设计
ORACLE数据库的表和索引是透过表空间tablespace存储在数据库中的。在tablespace设计时一般作以下考虑：
1、一般较大的表或索引单独分配一个tablespace。
2、Read only对象或Read mostly对象分成一组，存在对应的tablespace中。
3、若tablespace中的对象皆是read only对象，可将tablespace设置成read only模式，在备份时，read only tablespace只需备份一次。
4、高频率insert的对象分成一组，存在对应的tablespace中。
5、增、删、改的对象分成一组，存在对应的tablespace中。
6、表和索引分别存于不同的tablespace。
7、存于同一个 tablespace中的表（或索引）的extent 大小最好成倍数关系，有利于空间的重利用和减少碎片。
● DB BLOCK SIZE
超大型数据库DB BLOCK SIZE一般在4KB 至 64KB，而最常用的是8KB、 16KB或32KB。选用较大的DB BLOCK SIZE可使INDEX的高度降低，也会提高IO效率。
● Redo Log Files
ORACLE 使用专用的进程redo log writer (LGWR)将日志写入日志文件。一般日志文件最好建在专用的镜像盘上。日志文件组的个数及文件的大小的设定与系统交易量的大小有关。ORACLE并行服务器中每个INSTANCE使用各自的一组rego log files。一般的每组日志文件的个数为3-7个，每个的大小为200MB－500MB。
● 数据文件大小
建议用标准的文件大小，如200M、１GB、２GB、4GB、8GB等，可简化空间的维护工作。
● 回滚段
回滚段一般建在专用的表空间中。每一个INSTANCE实例拥有各自的回滚段。设置回滚段的一般原则是： initial 及 next 存储参数的值是相等的，同时还是DB BLOCK SIZE的倍数。每个回滚段的minextents设为20，optimal参数的值保证回滚段缩小时不低于20个extents。
● 临时表空间
临时表空间一般建在专用的表空间中。每一个INSTANCE实例拥有各自的临时表空间。这样使用临时表空间时不会有PING。设置临时表空间的initial=next。
四、系统硬盘的划分及分配
在多机集群环境下，ORACLE并行服务器通过操作系统提供的DRD服务来共享同一个数据库。每一个INSTANCE对数据库的数据文件的访问都是通过该数据文件所在的DRD服务进行的。
考虑以下情况：主机1上有DRD服务1，该服务对应的数据文件有1、2、13、35、67等，这时如果主机2上的INSTANCE2需要读取数据文件13，通过DRD服务调度，主机1通过DRD服务访问磁盘阵列上的数据文件13，把INSTANCE2需要的数据读到内存，然后通过MEMORY IO把数据传到主机2的INSTANCE2。写操作是读操作的逆过程。
通过以上分析可知，系统硬盘的划分及分配的原则是尽量减少MEMORY IO。
五、备份及恢复策略的考虑
数据库的备份与恢复在系统设计中占很重要的地位。好的备份及恢复策略可以降低系统的运行风险，减少因硬件故障而造成的损失。
ORACLE备份方法：
1.物理备份
将数据库的物理文件通过操作系统的命令或工具备份到备份介质上。物理备份往往用于存储介质故障时恢复数据库系统的数据。
根据数据库运行方式的不同，可进行不同的物理备份：
a)物理冷备份（offline backup）
物理冷备份要求数据库在关闭(所有INSTANCEs停止)的情况下进行。这种备份必须是完全备份，即需备份所有的数据文件、控制文件(control file)、日志文件(redo log file)、初始参数文件等等。
物理冷备份的步骤简单，但要求系统能够停止。
b)物理热备份（online backup）
物理热备份是在数据库系统正常运行的情况下进行的数据库备份。这种备份可以是数据库的部分备份，既备份数据库的某个表空间(tablespace)或某个数据文件(datafile)，也可备份控制文件(control file)。
物理热备份要求数据库在ARCHIVELOG模式下运行。这种备份一般用于应用系统不能停机的情况。
c)归档日志文件备份（archived log file backup)
要使数据库系统能够恢复到故障点前一时刻状态，或恢复到某指定时刻状态，数据库必须采用ARCHIVELOG模式。在ARCHIVELOG模式下，数据库系统会产生归档日志文件(archive log files)。归档日志文件也需备份到备份介质上。在恢复时，这些文件可使数据库恢复到最近状态。
归档日志文件产生在指定目录下，这些文件一生成就可以备份到备份介质上，DBA可根据磁盘空间情况，定时将它们备份出去。
2.逻辑备份
逻辑备份是通过ORACLE提供的Export工具，将数据库的结构定义及其数据卸出到特定格式的文件中，并备份该文件。
在实际应用中，逻辑备份与物理备份并用。一般来说，物理备份用于磁盘介质损坏或数据文件损坏；逻辑备份用于数据库中的某些对象被破坏或用户误操作。
备份策略的考虑主要在以下三个方面：
● 存储空间
● 对现行运行的系统的性能影响
● 恢复时间的影响
如果需要节省空间和恢复时间就需要增加备份的频率，但是备份操作会明显增加现行运行的系统的负载。、
ORACLE的恢复方法
根据不同的备份方法采用不同的恢复方法。
使用物理备份恢复
ORACLE提供了三种恢复手段：
1、数据库级的恢复
2、表空间(Tablespace)的恢复
3、数据文件的恢复
数据库级的恢复要求数据库在关闭但Mount的状态下进行。表空间及数据文件的恢复可在数据库运行的状态下进行。
使用逻辑备份恢复
当数据库中的某一对象被损坏，或用户的误操作使数据破坏（如误删表） 时可用逻辑备份恢复。用逻辑备份只能恢复到备份时刻的状态。
总之，数据库系统的设计是一门高深的学问。本文是作者基于几年管理超大型计费系统经验和教训，参考ORACLE8.0.6文档的基础上完成的。由于本人才疏学浅，难免有不当和错误之处，敬请有识之士批评指正
数据表的设计原则
1)不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。
2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。
3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。
4)由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。
5)同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，所以在领域模型中的对象存在主对象和从对象之分，从对象是从1－N或N－N的角度进一步主对象的业务逻辑，所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。
6)在映射后得出的数据库表结构中，应再根据第四范式进行进一步修改，确保不存在多值依赖。这时，应根据反向工程的思路反馈给领域模型。如果表结构中存在多值依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式：一个表如果满足BCNF，不应存在多值依赖。
7)在经过分析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且，我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。当然，从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个折中的方案。
8)应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比较起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响，以及无索引时的排序操作所带来的性能影响，这种方式仍然是值得提倡的。
9)尽量少采用存储过程，目前已经有很多技术可以替代存储过程的功能如“对象/关系映射”等，将数据一致性的保证放在数据库中，无论对于版本控制、开发和部署、以及数据库的迁移都会带来很大的影响。但不可否认，存储过程具有性能上的优势，所以，当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时，可经过平衡考虑选用存储过程。
10)当处理表间的关联约束所付出的代价（常常是使用性上的代价）超过了保证不会出现修改、删除、更改异常所付出的代价，并且数据冗余也不是主要的问题时，表设计可以不符合四个范式。四个范式确保了不会出现异常，但也可能由此导致过于纯洁的设计，使得表结构难于使用，所以在设计时需要进行综合判断，但首先确保符合四个范式，然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法。
11)设计出的表要具有较好的使用性，主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧。
12)设计出的表要尽可能减少数据冗余，确保数据的准确性，有效的控制冗余有助于提高数据库的性能。
