SHOUG成员 – ORACLE ACS高级顾问罗敏
本文永久地址：https://www.askmac.cn/?p=16572
简而言之，数据库物理设计就是为满足海量数据的高性能、可扩展性、高可用性等处理需求，在数据库逻辑设计基础上，结合具体的数据库管理系统平台和硬件平台，特别是运用Oracle相关特色技术，进行的详细物理级设计工作。
事实上，Oracle物理设计的内涵非常丰富，外延也非常广泛。例如Oracle每个被存储的对象（普通表、索引、大对象LOB字段等）几乎都涉及到相关物理属性的设计；还包括数据库实例初始化参数设计、数据库块选择、数据库字符集选择、控制文件规划、日志文件设计等诸多方面；还有数据文件、表空间，特别是分区方案设计；如果采用ASM技术，还有ASM实例设计、ASM磁盘组设计、ASM 文件设计等；以及操作系统参数设计、存储系统配置设计等更多方面。
真是林林总总，目不暇接。本章将以一个银行案例为背景，介绍物理设计一些主要内容，本书后面章节还将涉及物理设计其它方面的相关内容，例如分区、大对象LOB等。
20多年前的物理设计
前面章节对自己20多年前刚工作时，在领导带领下开展的数据库逻辑设计和数据流程图设计工作，不无得意。实际上，在当年技术环境下，露怯的事情太多了。以下以物理设计为例，讲述当年的趣事。
20多年前我们几乎没有物理设计的概念，就知道如何在逻辑上写出建表语句而已，连表空间都不指定，更别提表的pctfree, pctused等一堆物理属性参数了。大家知道当年Oracle 5.1版在不指定表空间的缺省情况下，把表搁哪儿了吗？SYSTEM表空间！
于是，在我们项目组历经半年的应用软件设计和开发之后，开始往数据库里灌数据时，不一会儿，数据库就报SYSTEM表空间满的错误（ORA-1652）了。此时，作为刚毕业的研究生，我被委以重任，研究如何解决该问题。在当年连Oracle联机文档都没有的情况下，抱着一本不知道是科海还是希望出版的，翻译得象天书一样的资料，苦苦研读，终于找到了如何扩表空间的命令。当年的Oracle 5.1版，居然要先通过一个Oracle提供的ccf工具，在操作系统创建一个文件，然后再通过“ alter tablespace <tablespace_name> add datafile <datafile name>”命令将该文件添加到指定表空间，从而完成表空间扩容工作。
就这样，我照猫画虎般地直接把SYSTEM表空间扩充了！也满足数据加载需求了。待任务完成之后，居然得到了领导的口头嘉奖。今天回忆起来，实在是汗颜。— 这就是我们20多年前的数据库物理设计水平。
一个项目的物理设计概貌
首先，我们瞥一下该银行大集中项目的物理设计部分章节内容，给大家一个总体感觉：
- 物理设计需求分析和设计原则
- 物理设计需求分析
- 物理设计基本原则
- 物理设计主要内容
- 数据库实例初始化参数设计
- 表设计基本建议
- 索引设计基本建议
- 数据库块选择
- 数据库字符集选择
- 控制文件规划
- 日志文件设计
- 表空间方案设计
- 10g/11g若干新特性使用建议
- 现有系统表空间设计思路分析
- 表空间设计基本思路
- 表空间详细设计建议
- 表空间设计总结
- 分区方案设计
- Oracle分区表技术简介
- Oracle 11g分区新特性简介
- 分区方案基本原则和方法
- 现有系统分区方案分析
- 分区方案与RAC实施
- 卡户及折户分区方案设计
- 帐户及分户登记簿分区方案设计
- 交易明细表分区方案设计
- 交易日志分区方案设计
- 其它日志分区方案设计
事实上，每个项目涉及的架构、数据对象的不同，将带来物理设计内涵的差异性。以下还是以该银行项目为背景，更翔实地介绍相关设计细节。
从总体上考虑物理设计
企业级数据库设计一定要综合平衡
Oracle公司一直标榜自己是最大的企业级软件供应商，更标榜Oracle数据库是真正适合于海量数据管理的企业级数据库管理产品。以自己从事Oracle数据库20余年的经验，的确感觉Oracle的上述标榜不是自封的，也的确感觉到GB级数据库和TB级数据库在设计理念、设计方法、技术运用等方面的迥然不同。部门级的GB级数据库采用大量缺省物理属性即可满足需求，而TB级则需要在各方面更加综合平衡地考虑问题，特别是在物理设计方面的相关技术运用中应更加精雕细琢。
以下就是我们在该银行项目上确定的物理设计原则：
“为充分满足xxxx系统对海量数据的上述高性能、扩展性、数据可管理性、历史数据转换和迁移、数据备份恢复等综合需求，XXXX系统物理设计应遵循如下原则：
- 充分考虑xxxx银行对xxxx系统的总体规划和建设目标
- 以业务需求为驱动，以逻辑模型为基础
- 充分利用硬件平台特性
- 充分发挥Oracle相关物理特性的作用
- 确保xxxx系统处理的高性能、高吞吐量和响应速度
- 确保数据的安全性及可用性
- 充分考虑xxxx系统数据的可管理性和可维护性
- 充分考虑xxxx数据库的可扩展性
一般而言，上述目标有时候是相互矛盾的，最佳设计应该是全面考虑这些目标，综合平衡之后的结果。”
大话一定要落地
上述物理设计原则中的高性能、高吞吐量、安全性、可用性、可管理性、可维护性、可扩展性等，也经常出现在大多数项目的方案设计书中，更被某些方案设计者美其名曰：非功能性需求和目标。
但本人发现，虽然在很多系统的设计方案前言部分，充满了上述这个性、那个性的华丽词汇，但在后面的具体设计和实施部分，往往却看不见这些大话如何具体落地的了，甚至仍然采用的是很业余的设计理念和技术，那些华丽词汇早已被设计者抛到九霄云天之外了。呵呵。
事实上，作为企业级数据库，Oracle提供了大量满足这个性、那个性的丰富技术。我们在物理设计的各个层面和各个角度、在各种技术运用过程中，应时刻牢记我们给客户许诺的各种大话，并时刻考虑如何落地，如何加以实施，这才会真正实现一个高质量的数据库系统。
表和索引设计基本建议
表物理设计基本建议
以下是该项目上，主要从物理设计角度，对表设计提供的基本建议：
- 除特殊需求，建议采用普通的堆表（Heap table）。
- 每个表在创建时候，建议指定所在的表空间，不要采用默认表空间以防止表建立在系统表空间上导致性能和安全问题。
- 建议应用设计开发人员提供每张表的DML操作频度数值，如果update操作频度高，则可将PCTFREE设置为较高（10%，20%…），反之，则可将PCTFREE设置为较高（1%…）。
- 当表中存在大量delete操作时，PCTUSED值的增大，将提高空间的利用率，并提高insert和update操作的性能。因此，建议将大量进行delete操作的表的PCTUSED设为60，否则设为缺省值40。
- 对并发访问量比较高的表和索引，将INITRANS设置较大，特别是针对索引，例如设置INITRANS设为10。
- 对比较小的代码和参数表，可考虑IOT表技术。
- 如果某几个静态表关系比较密切，则可以采用聚蔟表的方法。
以下就是卡表创建脚本：
CREATE TABLE T_CARD_ACCNT ( card_no CHAR (19) NOT NULL , card_medium CHAR (1) NOT NULL , card_type CHAR (1) NOT NULL , card_class CHAR (2) NOT NULL , cstm_name VARCHAR2 (40 CHAR) NOT NULL , app_date NUMBER (6) NOT NULL , open_date NUMBER (6) NOT NULL , open_inst CHAR (8) NOT NULL , due_date NUMBER (6) NOT NULL , Dac CHAR (16) NOT NULL , Pwd RAW (8) NOT NULL , b_flag NUMBER (6) NOT NULL ) PCTFREE 20 PCTUSED 40 INITRANS 2 MAXTRANS 255 TABLESPACE TS_TAB_ZH-FHDJB LOGGING STORAGE ( INITIAL 104857600 NEXT 10485760 PCTINCREASE 0 MINEXTENTS 1 MAXEXTENTS 2147483645 FREELISTS 5 FREELIST GROUPS 5 BUFFER_POOL DEFAULT ) ENABLE ROW MOVEMENT PARTITION BY HASH ( card_no ) PARTITIONS 64 STORE IN (TS_TAB_ZH-FHDJB) ;
需要说明的是，上述脚本是Oracle Data Modeler工具生成。实际上，如采取手工编写方式，大量物理属性可以采用缺省值，例如storage短语、ENABLE ROW MOVEMENT等均可省略。
索引设计基本建议
以下不仅从物理设计，而且从应用开发角度提供索引设计的基本建议：
- 通常而言，交易系统建立为B*树索引，对数据仓库系统，则可考虑Bitmap、Bitmap Join等索引
- 通过分析应用软件对数据访问方式，展开索引设计
- 索引与数据分别存储在不同的表空间
- 不要对索引字段进行运算
- 不要对索引字段进行格式转换
- 不要对索引字段使用函数
- 加强索引使用和索引效率的分析
B*树单字段索引设计建议
- 分析SQL语句中的约束条件字段
- 如果约束条件字段不固定，建议创建针对单字段的普通B*树索引
- 选择可选性最高的字段建立索引
- 如果是多表连接SQL语句，注意被驱动表（drived table）的连接字段是否需要创建索引
- 通过多种SQL分析工具，分析执行计划并以量化形式评估效果
复合索引设计建议
- 分析SQL语句中的约束条件字段
- 如果约束条件字段比较固定，则优先考虑创建针对多字段的普通B*树复合索引。例如同时涉及到月份、帐号、金融机构代码三个字段的条件，则可以考虑建立一个复合索引
- 如果单个字段是主键或唯一字段，或者可选性非常高的字段，尽管约束条件字段比较固定，也不一定要建成复合索引，可建成单字段索引，降低复合索引开销。
- 在复合索引设计中，需首先考虑复合索引第一个设计原则：复合索引的前缀性（prefixing）。即SQL语句中，只有复合索引的第一个字段作为约束条件，该复合索引才会启用。
- 在复合索引设计中，其次应考虑复合索引的可选性（Selectivity或Cardinality）。即按可选性高低，进行复合索引字段的排序。例如上述索引的的字段排列顺序为：帐号、金融机构代码、月份。
- 如果条件涉及的字段不固定，组合比较灵活，则分别为月份、帐号、金融机构三个字段建立索引
- 如果是多表连接SQL语句，注意是否可以在被驱动表（drived table）的连接字段与该表的其它约束条件字段上，创建复合索引。
通过多种SQL分析工具，分析执行计划并以量化形式评估效果。
表空间设计的新特性
在该银行项目上，为综合满足海量数据的高性能、易管理性等综合需求，我们在表空间设计方面，综合采用了ASM、OMF、大表空间技术。以下先简要介绍这些技术，然后再给出这些技术综合使用的过程。
ASM
自动存储管理（Automatic Storage Management），简称ASM，是Oracle 从10g开始推出，为满足海量数据库管理的需求，简化存储管理操作的一项新技术。简言之，Oracle通过ASM技术，部分代替了硬件存储厂商对磁盘阵列的管理工作，免去了卷组和裸设备的规划工作。只要将磁盘阵列直接交付给Oracle，甚至不用硬件存储厂商进行磁盘阵列的条块化处理，ASM就能高效率地直接管理所有的数据。ASM提供了几种条块化处理技术，并可灵活地增加和减少磁盘，自动进行数据的按比例负载均衡等。
本书后面还将专题介绍ASM，特别是11g ASM相关新技术。
大文件表空间（BFT）技术简介
Oracle 10g推出了大文件表空间（Big File Tablespace）技术。相比传统概念，一个表空间可以对应多个数据文件，而大表空间只包含一个数据文件，并且该文件可以最大扩展到16TB。以下是传统表空间和大表空间的示意图：
使用大表空间的好处如下：
- 通过少量数据文件，就可以支持更大数据量的存储和处理。
- 大表空间技术，可以简化掉数据文件的复杂处理。大大提高表空间的可管理性。即通过大表空间新技术，可以打破数据文件的概念，使得数据文件对用户完全透明。
OMF
OMF即Oracle Managed File的简称。通过OMF技术，例如DB_CREATE_FILE_DEST 等参数的设置，Oracle可通过SQL命令进行数据库相关文件的自动创建和管理，将大大简化数据库管理工作。
OMF并非10g/11g新技术，但通过与ASM、大表空间技术的结合，将极大地简化数据库管理工作。
ASM、OMF、大表空间技术综合使用建议
传统数据系统系统，尤其是在Oracle RAC上部署的数据库系统，采用的是经典的卷组和裸设备技术方案，这种方案将导致大量存储空间的设计工作，例如各个表空间、数据文件的大小、名称，以及相对应的卷组和裸设备的设计工作。在投入运行之后，由于裸设备不能自动扩展，而数据规模将不断增长，会给后期运行维护带来很大的负担。
- 建议
针对该银行数据量庞大、表空间多的海量系统特点，为简化管理，建议将ASM、OMF、BigFile Tablespace技术综合使用。为使用OMF，建议对数据库实例的如下参数进行设置：
DB_CREATE_FILE_DEST=‘+DISKGROUP1’
上述一个参数的简单设置，实际上涉及了OMF和ASM两种技术。
- 使用过程及效果评估
ASM、OMF、BigFile Tablespace技术的结合使用，可得到如下益处：
首先会使表空间的创建和删除脚本简化，不需要指定具体的data file。例如：
create bigfile tablespace TS_TAB_CREDIT_CARDS_TRANSACTIONS datafile size 1024M;
在删除表空间时，对应的ASM数据文件会自动被删除掉。
drop tablespace TS_TAB_CREDIT_CARDS_TRANSACTIONS_200801 including contents;
可直接对表空间进行自动扩充时，也不需要指定数据文件。例如：
alter tablespace TS_TAB_CREDIT_CARDS_TRANSACTIONS_200801 resize 2048M;
这样，将为海量系统的存储空间设计和管理工作，带来极大的便利。
简言之：根本不用设计卷组、裸设备，更不用关心每个裸设备应该设计多大了。
2.6 表空间设计原则和详细设计
表空间设计基本原则
以下就是该银行系统的表空间设计基本思路和原则：
“为满足XXXX系统对数据易管理性、历史数据迁移、提高备份恢复性能和灵活性、高性能、可扩展性等需求，并参考现有表空间设计思路，建议表空间设计遵循如下设计原则：
- 系统数据与应用数据必须存储于不同的表空间
- 按应用划分数据，不同应用的数据应存储于不同的表空间。例如不同产品表（卡、折等）应存储于不同表空间，提高数据管理灵活性，减小单个表空间故障的影响范围。
- 表和索引分离，需存储在不同的表空间，以便分布到不同的数据文件、硬盘上，并分别进行不同的物理存储参数优化。同时方便对表和索引进行不同的管理工作，例如数据备份恢复、数据迁移等。
- 相对静态的表和频繁变动的表分开存放在不同的表空间，以便分别进行不同的物理参数优化。
- 为中间表单独设计表空间。这样不仅便于管理，而且在备份中可不考虑此类数据的备份，提高备份效率、降低备份开销。
- 采用临时表空间组技术，提高大批量数据处理效率。”
表空间详细设计
以下是该系统部分表空间的详细设计。
- 系统级表空间设计
| 序号 | 表空间名 | 用途 | 大小(M) | 分配方式 | Uniform Size(M) | 段空间管理 | 备注 |
| 1. | SYSTEM | 系统表空间 | 1,024 | SYSTEM | N/A | MANUAL | |
| 2. | TS_UNDO_01 | UNDO表空间1 | 20,480 | SYSTEM | N/A | MANUAL | 实例1 |
| 3. | TS_UNDO_02 | UNDO表空间2 | 20,480 | SYSTEM | N/A | MANUAL | 实例2 |
| 4. | TS_TEMP_01 | 临时表空间 | 20,480 | UNIFORM | 64 | MANUAL | 临时表空间组 |
| 5. | TS_TEMP_02 | 临时表空间 | 20,480 | UNIFORM | 64 | MANUAL | |
| 6. | TS_TEMP_03 | 临时表空间 | 20,480 | UNIFORM | 64 | MANUAL | |
| 7. | TS_TEMP_04 | 临时表空间 | 20,480 | UNIFORM | 64 | MANUAL | |
| 8. | SYSAUX | 工具表空间 | 20,480 | UNIFORM | 64 | AUTO |
- 暂时假设XXXX系统采用2节点11g R2 RAC架构。
- 系统表空间(SYSTEM)为ORACLE系统运行时所必须的表空间，包括所有数据字典、系统审计信息等。一般设计为1G，足以满足XXXX系统运行需要。
- 分别为RAC的两个实例设计UNDO表空间。该表空间为数据库进行未提交事务的恢复操作的表空间。作为OLTP/OLAP的混合系统，XXXX系统存在大量大批量数据操作，即存在大量大事务操作，对UNDO表空间的需求会较大。初始各分别设计为20G。
- 为提高临时表空间的使用效率，设计四个大小分别为20G的临时表空间(TS_TEMP_01, TS_TEMP_02, TS_TEMP_03, TS_TEMP_04)，组成临时表空间组。
- SYSAUX为Oracle 10g/11g的辅助表空间。该表空间将存储所有Oracle后台监控和管理数据。例如AWR、ADDM、Statspack等数据。初试容量设计为20G。
- 帐户及分户登记簿表空间设计
| 序号 | 表空间名 | 用途 | 大小(M) | 分配方式 | Uniform Size(M) | 段空间管理 | 备注 |
| 1. | TS_TAB_ZH-FHDJB | 帐户及分户登记簿数据 | 102,400 | UNIFORM | 64 | AUTO | |
| 2. | TS_IND_ZH-FHDJB | 帐户及分户登记簿索引 | 102,400 | UNIFORM | 64 | AUTO |
- 将帐户及分户登记簿表数据存储在单独的表空间
- 数据和索引相分离
- 帐户及分户登记簿表数据和索引初始均分配100G空间
- 由于采用ASM技术，上述空间均可自动扩展
例如，TS_TAB_ZH-FHDJB表空间的创建脚本如下：
create bigfile tablespace TS_TAB_ZH-FHDJB datafile size 102400M
AUTOEXTEND ON NEXT 512M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64M
SEGMENT SPACE MANAGEMENT AUTO
ONLINE
PERMANENT;
数据库初始化参数设计
数据库初始化参数，特别是与内存管理相关的参数设置，直接影响到系统运行性能。再者，数据库初始化参数的确与硬件配置、数据库架构设计等紧密相关。因此，数据库初始化参数应该是物理设计的重要内容。
Oracle纷繁多彩的初始化参数非常眩人，也的确在故障处理、性能优化方面扮演着重要角色，所以也是很多技术发烧友所热衷钻研的东西。但是，Oracle在参数管理方面却是一种越来越自动化、智能化，简化甚至淡化的发展趋势。因此，下面将首先介绍这种趋势，然后再介绍在该银行项目上的设置原则和实施建议。
10g/11g初始化参数若干新特性介绍
提高IT系统可管理性，甚至实现完全自动化、智能化管理，是Oracle公司正追求的目标。例如，Oracle从9i开始，10g、11g，逐个版本在内存参数设置方面，越来越简化、自动化、智能化了。
如下是自动内存管理的示意图：
图中表示当夜间在进行RMAN备份、并行卸载数据等批处理业务中，如果需要更大的Large Pool时，10g和11g可在SGA范围内自动扩大Large Pool。
在11g情况下，不仅可在SGA内部对相关内存进行自我调整，甚至可以在SGA与PGA之间也进行调整。例如夜间若进行大量统计运算、排序等大批量数据处理时，对PGA的需要很大，Oracle则可以在不停机调整PGA_AGGREGATE_TARGET参数情况下，自动扩大PGA区域，在白天交易处理开始后，又可自动降低PGA区域，扩大SGA区域。
初始化参数设计原则建议
- 采取自动和传统技术相结合策略
即同时设置MEMORY_TARGET、SGA_TARGET、DB_CACHE_SIZE等自动和手工混合的内存管理参数。Oracle原则是：每个内存部件至少分配指定的内存，例如DB_CACHE_SIZE 设置成512M，则Buffer Cache永远不会低于512M，但是可以根据需要，自动调整到超过指定值的内存。
- 借鉴Oracle最佳实践经验
借鉴Oracle最佳实践经验，例如：
MEMOERY_TARGET = 物理内存*80%
MEMORY_MAX_SIZE = 物理内存*80%
对于OLTP系统：
SGA_TARGET = (物理内存*80%)*80%
SGA_MAX_SIZE = (物理内存*80%)*80%
PGA_AGGREGATE_TARGET=(物理内存*80%)*20%
对于DSS系统：
SGA_TARGET = (物理内存*80%)*50%
SGA_MAX_SIZE = (物理内存*80%)*50%
PGA_AGGREGATE_TARGET=(物理内存*80%)*50%
上述公式在《品悟》一书中已经出现，并受到一位读者的质疑。借新书写作之际进行一番解释：首先上述公式并非老罗自创，而是来源于Oracle官方文档，即是Oracle官方总结出来的最佳实践经验。其次，从原理本身分析，上述公式不无道理。例如，OLTP系统特点是大并发量的小事务处理，对Buffer Cache、Shared Pool等内存需求更高，所以 SGA应该大一些。而DSS系统则是并发量不高的大批量数据处理，特别是大量统计运算、排序、HASH_JOIN操作较多，对PGA区域要求更高，因此PGA可能占到50%甚至更高的物理内存。
- 掌握相关评估方法
建议经常访问对自动内存管理内部过程进行监控的若干视图：
V$MEMORY_DYNAMIC_COMPONENTS: 显示自动内存管理的各内存真实大小，包括SGA和PGA等。
V$MEMORY_RESIZE_OPS：显示最新的800个自动和手工进行内存调整操作，不包括正在进行调整的操作。
V$MEMORY_CURRENT_RESIZE_OPS：显示正在进行的内存调整操作，包括自动和手工进行的。
V$SGA_DYNAMIC_COMPONENTS：显示自动共享内存管理方式下SGA各内存真实大小。
V$SGA_RESIZE_OPS：显示最新的800个自动和手工进行SGA内存调整操作，不包括正在进行调整的操作。
V$SGA_CURRENT_RESIZE_OPS: 显示正在进行的SGA内存调整操作，包括自动和手工进行的。
V$SGA_DYNAMIC_FREE_MEMORY：显示系统可用的SGA动态调整内存空间
作为DBA，时常查询和分析这些视图的目的之一是监控Oracle自动内存管理的有效性，目的之二是及时发现问题，特别是Oracle在自动内存管理方面可能存在的Bug，并采取安装补丁、升级或关闭某些自动内存管理功能的策略。
2.8 物理设计中的感和悟
物理设计的变化趋势
在我从Oracle 5.1到11g的20余年使用经历中，在物理设计方面感觉到Oracle在发生如下的变化：
- 物理设计技术日益简化了
20多年来，Oracle在物理设计方面不断推出新的技术，给广大客户带来的好处首先是性能和处理能力越来越强，另外一个好处就是越来越多自动化技术的采用，使得物理设计日益简化了。例如，本地化管理表空间（locally managed tablespaces）代替了字典管理表空间（Dictionary-Managed Tablespaces）；段空间管理（Segment Space Management）由手工（MANUAL）转为自动（AUTO），这样STORAGE短语就取消了，大家不用再苦心钻研PCTUSED, FREELISTS, FREELISTS GROUPS等一大堆物理参数了。类似的还有11g新的大对象处理技术SecureFiles取代了传统LOB技术，大家也不用操心CHUNK、LOGGING/NOLOGGING、PCTVERSION、CACHE/NOCACHE/CACHE READS、ENABLE/DISABLE STORAGE IN ROW等传统LOB的大量物理属性了。
在本章开篇描述20多年前进行数据库设计时，我们曾经为根本不知道这些物理属性而汗颜，后来又曾经津津乐道这些诡异的参数。但世界变化就是这么快，当我们刚刚为弄懂这些东西而有点沾沾自喜时，这些东西又被淘汰了。其实仔细想想，世界本来就不应该有这么多的繁文缛节，一个清澈明亮的世界应该更加美好。
- 物理设计技术在不断推陈出新
虽然物理设计的一大趋势是日益简化，但不断推陈出新的物理设计新技术，也带来了一些新的需要斟酌和研究的细节。例如，11g针对ASM磁盘组推出了物理属性的概念，这样我们在11g中开展ASM磁盘组设计时，就需要研究AU_SIZE、DISK_REPARE_TIME、SECTOR_SIZE、COMPATIBLE.RDBMS、COMPATIBLE.RDBMS.ASM等参数的含义和如何正确设置了，切莫又回到20多年前的水平，对Oracle 的各种物理属性不管不顾，全部采用缺省属性。这绝对不是设计开发企业级TB级数据库的眼界和水平。
表空间设计的感和悟
- 表空间设计在性能方面已经不重要了
在Oracle传统的设计理念中，表空间设计的一个重要目标是为了提高性能。例如强调将数据和索引分别存在不同的表空间，进一步存储在不同的数据文件，特别是存储在不同的磁盘上，从而降低I/O访问冲突。这是当年使用普通物理磁盘存储数据的设计理念。
现在存储系统广泛使用条带化和磁盘镜像技术，一个数据文件实际上被条带化技术均匀打散在多块物理磁盘之上了，也就是说现在即便所有数据和文件都存储在一个表空间或数据文件上，理论上也不会有明显的性能问题。
总之，表空间设计在性能方面其实已经不那么重要了。
- 表空间设计目标的综合考虑
既然如此，是否未来就可以简化设计，甚至忽略表空间设计，简单将所有数据、索引存储在一个或少数几个表空间呢？我还真见过一个银行报表系统达到了数十TB容量了，所有数据存储在一个表空间、所有索引存储在另一个表空间，吓死我了。我当时就跟该系统DBA说：“你不害怕吗？如果这个大表空间中出现一个数据坏快，你的系统就完全不可访问了，RMAN恢复也是几乎不可能的。”
表空间设计目标除了性能，其实现在更应关注表空间在数据安全性、系统可用性 、数据可管理性和可操作性方面的作用了。把所有数据存储在一个表空间，就相当于把所有鸡蛋放在一个篮子里一样不安全。因此，合理划分和设计表空间粒度，可以有效隔离和降低数据故障风险。
通过表空间设计如何实现数据可管理性和可操作性呢？首先，针对大批量数据处理，Oracle提供了大量针对性技术。例如在表空间层面快速进行数据迁移的经典技术：表空间传输技术（Transportable Tablespace，简称TTS技术）。其次，这些技术的运用是与应用需求，包括表空间设计紧密相关的。如果设计者不考虑应用需求，简单、甚至杂乱无章地放置数据，TTS技术就无用武之地了。例如客户真有按月、按业务进行历史数据迁移和清理的需求了，而且想通过TTS实现，我们可能真需要按月、按业务进行数据组织和表空间设计了。
某种意义上，表空间设计就相当于一个大楼的结构设计图。如果设计的目的性不强，不仅带来的是数据安全性、可用性的下降，更将导致技术运用的简单化，使得Oracle众多高级技术无法运用。
说到这儿，请大家再回头看一遍前面我们项目组为某银行客户确定的表空间设计原则，体味一下我们在表空间设计方面的良苦用心。
Oracle到底能存多少数据？
10多年前在刚加入Oracle公司时，有幸参加一次中国移动举办的经营分析系统研讨会。该研讨会宗旨是为指导各省运营商的经营分析系统建设，在业务和技术层面制定相关规范和标准。于是，除移动公司内部相关业务和技术人员之外，研讨会还云集了各应用开发商，以及IBM、Oracle、NCR等各路精英。
可想而知，表面上大家似乎都在为一个同一个客户的同一个目标协同工作，实则是暗流涌动、明枪暗箭。不仅是各应用开发商之间互相掐，原厂商之间更是刀光剑影，天昏地暗。应用开发商和原厂商之间也是一会儿同盟关系，一会儿又成了陌路。—- 太佩服现在客户的精明了，让你们这些竞争对手面对面互相掐，然后再坐收渔翁之利。呵呵。
就在这次研讨会的某一天，另一个原厂商的代表突然向我射来一箭：“你们Oracle 9i到底能存多少数据啊？”面对大家齐刷刷的眼光，我摆出一副大义凛然的样子：“Oracle对数据库容量没有限制，有多少存多少！”什么叫无知者无畏，这就是典型写照！呵呵。
若干年后，在另外一个银行项目上，当客户提出如何进行超大型表空间的管理问题时，这次我才静下心来进行了一番深入研究。特别是仔细查阅了Oracle一篇官方文档：《Note:217143.1 Oracle 9i Database Limits》，才知道在9i下Oracle原来有那么多限制：一个数据库最多有64K个文件；一个数据文件最多有4M 个数据块；数据块最大为32K… …。 如此推算，Oracle 9i存储数据量是有上限的：64K*4M*32K = 8PB!可不是我当年的豪言壮语：有多少存多少。
为什么在物理设计一章说这段往事？是因为到了Oracle 10g推出大表空间技术之后，Oracle寻址空间更大了，可以存储到8EB了（1EB=1024PB，1PB=1024TB，1TB=1024GB……）。再则，随着大表空间、ASM、快速增量备份等众多新技术的推出，Oracle在物理设计方面有新的理念和目标了。
到了11g，Oracle有了更大的存储能力了，特别是采用ASM技术之后。例如：在一个ASM存储系统最多有63个磁盘组；一个ASM存储系统最多有1000个ASM磁盘；一个ASM存储系统最多存储40EB；等等。
听说这个世界上已经出现了PB级数据库，但还未听说过EB级数据库。还真无法想像EB级数据库的存储设备需要占多少机房空间，也许存储厂商还未制造出来这种产品，但Oracle在软件方面的确已经具备了这种处理能力，真快实现本人当年的豪言了。
在某些场合讲些气壮山河的话，营造一种气场有时候只是一种市场或商务策略而已，但科学本身还是严谨的。不过另一方面，过于追求技术的及至又显得太过天真、偏执了。世界上都没有这么大的存储需求，你管它的上限呢？凡事都要讲个度。
如果现在客户再问我同样问题，我可能会这样心平气和、更成熟稳健，也更聪明、更太极、更圆滑地回答了：“Oracle数据库每个版本的确都有不同的存储上限，但请大家放心，你现有系统的需求肯定达不到这种上限。”呵呵。
2.9本章参考资料及进一步读物
本章的参考资料及进一步读物：
| 序号 | 资料类别 | 资料名称 | 资料概述 |
| 1. | Oracle 11g R2联机文档 | 《Oracle Database Concept》 | 该书若干章节，特别是Part II的第2章至第6章，讲述了数据库表、索引、分区、视图、物化视图、数据库一致性、数据字典等相关技术原理和设计工作的方方面面。这些内容是普通数据库物理设计的重要内容。 |
| 2. | Oracle 11g R2联机文档 | 《Oracle Administrator’s Guide》 | 该书若干章节，特别是Part II Oracle Database Structure and Storage和Part III Schema Objects，也是数据库系统物理设计的重要内容，例如控制文件、联机日志文件、归档日志文件、表空间、UNDO等专题技术的设计等。 |
| 3. | Oracle 11g R2联机文档 | 《Oracle Data Warehousing Guide》 | 该书若干章节，特别是Part III Physical Design等是数据仓库系统物理设计的重要内容，例如表空间、分区、硬件和存储系统、并行处理、索引等技术的设计等。 |
| 4. | My Oracle Support | 《Master Note: Overview of Oracle Tablespace Management (Doc ID 1493350.1)》 | 这可是Oracle有关表空间设计的大全！不仅有表空间设计和管理的基本知识，更有很多最佳实践经验的文章。 |
| 5. | My Oracle Support | 《Master Note: Overview of Oracle Database Initialization Parameters (Doc ID 1496915.1)》 | 这是有关数据库初始化参数设置的导读文章，既有基础知识，也有如何查询Oracle隐含参数，以及如何在12c中进行初始化参数设置等技术高手感兴趣的话题。 |
| 6. | My Oracle Support | 《Master Note: Troubleshooting Oracle Database Initialization Parameters (Doc ID 1515259.1)》 | 数据库初始化参数设置出了问题，怎么办？就看这篇文章吧！ |
| 7. | My Oracle Support | 《Master Note for Automatic Storage Management (ASM) (Doc ID 1187723.1)》 | 欲深入了解ASM技术吗？这可是ASM技术海洋的入口，该文档包括了ASM林林总总的数百篇文章！ |
Leave a Reply