教你设计大型Oracle数据库

本文教你如何设计大型Oracle数据库 希望对大家有所帮助

一 概论

超大型系统的特点为

处理的用户数一般都超过百万 有的还超过千万 数据库的数据量一般超过 TB

系统必须提供实时响应功能 系统需不停机运行 要求系统有很高的可用性及可扩展性

为了能达到以上要求 除了需要性能优越的计算机和海量存储设备外 还需要先进的数据库结构设计和优化的应用系统

一般的超大型系统采用双机或多机集群系统 下面以数据库采用Oracle 并行服务器为例来谈谈超大型数据库设计方法

确定系统的ORACLE并行服务器应用划分策略

数据库物理结构的设计

系统硬盘的划分及分配

备份及恢复策略的考虑

二 Oracle并行服务器应用划分策略

Oracle并行服务器允许不同节点上的多个INSTANCE实例同时访问一个数据库 以提高系统的可用性 可扩展性及性能 Oracle并行服务器中的每个INSTANCE实例都可将共享数据库中的表或索引的数据块读入本地的缓冲区中 这就意味着一个数据块可存在于多个INSTANCE实例的SGA区中 那么保持这些缓冲区的数据的一致性就很重要 Oracle使用 PCM( Parallel Cache Management)锁维护缓冲区的一致性 Oracle同时通过I DLM(集成的分布式锁管理器)实现PCM 锁 并通过专门的LCK进程实现INSTANCE实例间的数据一致

考虑这种情况 INSTANCE 对BLOCK X块修改 这时INSTANCE 对BLOCK X块也需要修改 Oracle并行服务器利用PCM锁机制 使BLOCK X从INSTANCE 的SGA区写入数据库数据文件中 又从数据文件中把BLOCK X块读入INSTANCE 的SGA区中 发生这种情况即为一个PING PING使原来 个MEMORY IO可以完成的工作变成 个DISK IO和 个 MEMORY IO才能够完成 如果系统中有过多的PING 将大大降低系统的性能

Oracle并行服务器中的每个PCM锁可管理多个数据块 PCM锁管理的数据块的个数与分配给一个数据文件的PCM锁的个数及该数据文件的大小有关 当INSTANCE 和INSTANCE 要 *** 作不同的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 设计的关键是找出可能产生的冲突 从而决定应用划分的策略 应用划分有如下四种方法

根据功能模块划分 不同的节点运行不同的应用

根据用户划分 不同类型的用户运行在不同的节点上

根据数据划分 不同的节点访问不同的数据或索引

根据时间划分 不同的应用在不同的时间段运行

应用划分的两个重要原则是使PING最小化及使各节点的负载大致均衡

三 数据库物理结构的设计

数据库物理结构设计包括确定表及索引的物理存储参数 确定及分配数据库表空间 确定初始的回滚段 临时表空间 redo log files等 并确定主要的初始化参数 物理设计的目的是提高系统的性能 整个物理设计的参数可以根据实际运行情况作调整

表及索引数据量估算及物理存储参数的设置

lishixinzhi/Article/program/Oracle/201311/18944

ORACLE数据库中 表是最基本的内容 可以说 表设计的好坏直接跟数据库的性能相关 所以 在设计表的时候 除了要遵循其固有的数据库准则之外 还需要看个人的数据库管理经验 下面我就把这些经验分享一下 或许对大家有所帮助 一 表该存放在哪里? 我们都知道 在ORACLE数据库中 使利用空间这个概念来管理表对象的 在数据库创建的时候 数据库中已经建立了一些表空间 那么当我们新建立表的时候 这个新表的位置该放在什么地方呢?这就好像吃饭时的坐的位置一样 是有讲究的 一般来说 我们在新建表的时候 至少要遵循如下建议 一是在数据库创建的时候 在数据库中已经有了一个SYSTEM的表空间 一般情况下 这个表空间中 只包含数据字典及Oracle系统对象 如果我们将我们的表建立在这个空间上的话 那是要降低数据库的性能的 所以 一般我们是不建议用户把表格建立在这个空间上 但是 若我们不只一个人维护数据库 如有八个人共同设计数据库系统时 如何才能保证其他用户不在SYSTEM表空间中建立数据库表格呢?最好的办法就是通过权限控制 如我们可以给每个数据库设计人员指定一个默认的表空间 让他们只能在这个表空间中建立表格 如此的话 就能防止他们在SYSTEM表空间中建立自己的数据表格 从而对数据库的运行性能产生不良影响 所以 若给每个用户设置默认表空间的话 那么用户在建立具体的表时 不用具体指定表空间了 二是我们在为某个应用设计数据库的时候 最好先对表的空间进行规划 一般情况下 不要把数据表随意的分散到不同的表空间中去 如我们在为一个ERP系统设计数据库的时候 若把采购部门相关的表跟销售部门相关的表放到两个不同的表空间中去 这是不明智的做法 这么处理的话 会降低某些数据库管理和维护 *** 作的效率 如数据的备份与恢复 *** 作而且 也无法集中管理属于某个特定应用的数据 所以 我们一般建议 在规划数据库表空间的时候 把相同应用的表放在同一个表空间中去 如果要区分不同部门或者不同模块的表的话 我们可以在表的命名上动脑子 如我们在设计ERP系统的数据库中 可以根据其应用模块的不同 在前面加上前缀来进行识别 如跟系统基本配置相关的表 我们可以用AD为前缀而跟销售部门相关的表 我们可以加上SA前缀等等 如此的话 这些表具体是属于哪个模块的 就一清二楚了 完全没有必要为此设置不同的表空间 这是ORACLE数据库初学者经常会犯的错误 主要是对ORACLE表空间的定义不是很熟悉所导致的 二 对预计存储数量比较大的表时 要给与额外的重视 有些表非常的大 我们这边说的大 不一定是说结构复杂 而是指在这个表格中 预期会存储比较多的数据 为了提高对这个表格的处理效率 我们在事先要做出一定的安排 否则的话 后续对这些大表进行查询 插入等 *** 作的话 速度会很慢 所以 我们就有必要在数据库设计的时候 先预先估计一下表的数据存储量 把一些数据量大的表格 做一些额外的设置 如在ERP软件的数据库设置中 一般来说 产品数据与物料清单数据这两个表的数据量会比较大而从长远看的话 销售订单 采购订单 生产订单 记账凭证等这种单据类相关的表格其数据量也会比较大 一年两年可能感觉不出来 但是 到十年后 这个纪录数量就会很庞大 而像ERP系统这种大型的信息化管理项目 用个几十年时很正常的事情 而且 为了记录的完整性 也不建议用户把以前的数据删除 所以 为这种应用进行数据库设计的时候 要充分考虑这些大表的性能问题 具体的来说 设计大表的时候 可以考虑遵循如下的建议 一是不要为大表设置存储的限制 在ORACLE数据库中 可以为每张表格设置存储配额限制 如此的话 表最大容量就不能超过这个限制 对于一些数据容量比较小的表格 这么设置时合理的 可以提高空间的利用率 但是 若数据量比较大的话 就不建议事先设置表的存储空间了 如ERP系统的销售订单表 其刚开始可能记录量很小 第一年预计只有 G的记录容量 但是 估计在十年后 这个记录容量就会达到 G了 在这种情况下 我们怎么来给其设置存储空间呢?一开就设置 G空间 这也是不合理的 而且 设置存储空间 就意味着有可能产生存储碎片 从而影响到数据查询的效率 所以 在数据库表的设计过程中 若某些应用的表可能会有比较大的数据容量时 建议不要对其存储空间做出任何的限制 二是要为这大表分配足够的临时空间 如我们使用ERP系统时 要查询产品资料信息 我们都知道 产品信息的话 有些企业这个纪录数非常的庞大 而且在查询时 我们还会经常的进行排序 *** 作 如有时候会按照产品编码对查询出来的数据进行排序 当记录少的话 还好但是 当记录多的话 这个排序动作 要求具有比较大的临时存储空间 所以 当某个表预计会有很大的记录数量的时候 我们就要给其分配足够多的临时空间 临时空间的存储参数设置取决于临时表空间的默认储存参数设置 我们可以更改这些参数 以达到我们对要求 若没有给大表分配足够多的临时空间的话 则排序的动作将会很慢 而且很可能不成功 三是要考虑将表与表的索引分离存放 大表所对应的索引通常也比较大 一般来说 索引的数量是随着表记录的数量增加而增加 两者是接近于一个正比例的关系 所以 通常表的记录容量大的时候 索引数量也会很庞大 针对这种情况 我们考虑突破我们上面讲的表空间的规则定义 而考虑把表和他的索引分别存储于不同的表空间中 甚至在条件允许的情况下 分别存储于不同的硬盘中 这么做的好处是什么呢?最大的好处是让索引比较容易的获得所需要的连续的存储空间 从而提高输入输入的效率 通俗的说 就是可以提高数据的查询效率 如不这么处理的话 查询大容量的记录的话 数据库可能需要花费 秒而如此设计的话 就可能把时间缩短为 秒 这是一个很明显的性能改善 三 如何给表命名? 上面我在讲如何为表分配存储空间的时候 已经讲到过这方面的问题 下面 我就将对这个问题进行详细的描述 以帮助数据库管理员掌握一套好的数据库命名规则 首先 毋庸置疑的 在为标命名的时候 要遵循ORACLE数据库的基本命名规则 如不能以数字开头为表命名 如不能利用数据库的关键字为表命名 如表的名字不能重复等等 这些是最基本的要求 就不用我多费口舌了 除了要遵循这些基本的命名规则外 在实际工作中 为了数据库后续的维护等方面出发 我们还是要遵循一些额外的规则 这些规则跟ORACLE定义的规则不同 我们所讲的规则没有约束力 可以说 只是业界的一些共识而已 你若不怎么处理 ORACLE数据库也不会说你错误 只是后续维护的时候 会比较麻烦而已 一是在对数据库命名的时候 最好能跟体现表的分类关系 如最常见的 我们在设计数据库的时候 表都是按系统的具体模块来区分的 如根据前端系统要求的不同 数据库的表大致可以分为系统基本配置表 销售模块表 采购模块表 报表模块表等等 我们可以根据这些模块的不同 分别给与不同的前缀来区分 这么做的好处是很明显的 如一看到表最大名字 就可以知道这个表是属于哪个应用的 哪个模块的 这无疑可以提高数据库设计与前台软件开发的效率 同时 数据库中默认的排序规则是按名字来排序的 所以 为表格设置类别前缀的话 可以把同一类的表格排在一起 方便我们察看 二是对表格命名的时候 要考虑可读性 而不能随便阿狗阿猫的乱取名字 最常见的是 那些刚学数据库的人 在表命名的时候 如要建几张测试表 就会随便命名如TEST TEST 之类的 虽然这只是测试 但是 也不符合我们的命名过则 要做测试的话 那就以TEST开头 然后后面加上具体要测试的内容 如此的话 我们才可以通过表的名字知道该表具体的用途 而不用打开表去看里面具体的结构或者注释才能知道我们需要的信息 所以 在设计表的名字的时候 还要关注一下其的可读性 lishixinzhi/Article/program/Oracle/201311/18317

---