教你设计大型Oracle数据库

教你设计大型Oracle数据库,第1张

本文教你如何设计大型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

采用自增长主要是性能

早期的数据库系统,经常采用某种编号,比如身份z号码,公司编号等等作为数据库表的

然而,很快,大家就发现其中的不利之处

比如早期的医院管理系统,用身份z号码作为病人表的

然而,第一,不是每个人都有身份z;第二,对于国外来的病人,不同国家的病人的证件号码并不见得没有重复

因此,用身份z号码作为病人表的是一个非常糟糕的设计

考虑到没有医生或者护士会刻意去记这些号码,使用自增长是更好的设计

公司编号采用某种特定的编码方法,这也是早期的数据库系统常见的做法

它的缺点也显而易见:很容易出现像千年虫的软件问题,因为当初设计数据库表的时候设计的位数太短,导致系统使用几年后不能满足要求,只有修改程序才能继续使用

问题在于,任何人设计系统的时候,在预计某某编号多少位可以够用的时候,都存在预计不准的风险

而采用自增长则不存在这种问题

同样的道理,没有人可以去记这些号码

使用自增长另外一个原因是性能问题

略有编程常识的人都知道,数字大小比较比字符串大小比较要快得多

使用自增长可以大大地提高数据查找速度

2

避免用复合主键(compound)这主要还是因为性能问题

数据检索是要用到大量的值比较,只比较一个字段比比较多个字段快很多

使用单个从编程的角度也很有好处,sql语句中where条件可以写更少的代码,这意味着出错的机会大大减少

3

双主键双主键是指数据库表有两个字段,这两个字段独立成为主键,但又同时存在

数据库系统的双主键最早用在用户管理模块

最早的来源可能是参照 *** 作系统的用户管理模块

*** 作系统的用户管理有两个独立的主键: *** 作系统自己自动生成的随机ID(Linux,windows的SID),loginid

这两个ID都必须是唯一的,不同的是,删除用户test然后增加一个用户test,SID不同,loginid相同

采用双主键主要目的是为了防止删除后增加同样的loginid造成的混乱

比如销售经理hellen本机共享文件给总经理peter,一年后总经理离开公司,进来一个普通员工peter,两个peter用同样的loginid,如果只用loginid作 *** 作系统的用户管理主键,则存在漏洞:普通员工peter可以访问原来只有总经理才能看的文件

*** 作系统自己自动生成的随机ID一般情况下面用户是看不到的

双主键现在已经广泛用在各种数据库系统中,不限于用户管理系统

4

以固定的数据库、表应付变化的客户需求这主要基于以下几个因素的考虑:4

1大型EPR系统的正常使用、维护需要软件厂商及其众多的合作伙伴共同给客户提供技术服务,包括大量的二次开发

如果用户在软件正常使用过程中需要增加新的表或者数据库,将给软件厂商及其众多的合作伙伴带来难题

4

2软件升级的需要

没有一个软件能够让客户使用几十上百年不用升级的

软件升级往往涉及数据库表结构的改变

软件厂商会做额外的程序将早期版本软件的数据库数据升级到新的版本,但是对于用户使用过程中生成的表进行处理就比较为难

4

3软件开发的需要

使用固定的数据库库表从开发、二次开发来说,更加容易

对于用户使用过程中生成的表,每次查找数据时都要先查表名,再找数据,比较麻烦

举例来说,早期的用友财务软件用Aess作数据库,每年建立一个新的数据库

很快,用户和用友公司都发现,跨年度数据分析很难做

因此这是一个不好的设计

在ERP中,很少有不同的年度数据单独分开

一般来说,所有年份的数据都在同一个表中

对于跨国公司甚至整个集团公司都用同一个ERP系统的时候,所有公司的数据都在一起

这样的好处是数据分析比较容易做

现在大多数数据库系统都能做到在常数时间内返回一定量的数据

比如,Oracle数据库中,根据在100万条数据中取10条数据,与在1亿条数据中取10条数据,时间相差并不多

5

避免一次取数据库大量数据,取大量数据一定要用分页

这基本上是现在很多数据库系统设计的基本守则

ERP系统中超过100万条数据的表很多,对于很多表中的任何一个,一次取所有的会导致数据库服务器长时间处于停滞状态,并且影响其它在线用户的系统响应速度

一般来说,日常 *** 作,在分页显示的情况下面,每次取得数据在1-100之间,系统响应速度足够快,客户端基本没有特别长的停顿

这是比较理想的设计

这也是大型数据库系统往往用ODBC,ADO等等通用的数据库联接组件而不用特定的速度较快的专用数据库联接组件的原因

因为系统瓶颈在于数据库(Database)方面(数据量大),而不在于客户端(客户端每次只取少量数据)

在B/S数据库系统中,分页非常普遍

早期的数据库系统经常有客户端程序中一次性取大量数据做缓冲

现在已经不是特别需要了,主要原因有:5

1数据库本身的缓冲技术大大提高

大部分数据库都会自动将常用的数据自动放在内存中缓冲,以提高性能

5

2数据库联接组件的缓冲技术也在提高

包括ADO在内的一些数据库联接组件都会自动对数据结果集(resultset)进行缓冲,并且效果不错

比较新颖的数据库联接组件,比如Hibernate也加入了一些数据结果集缓冲功能

当然,也有一些数据库联接组件没有对数据结果集进行缓冲,比如JDBCDriver,不过几年之内情况应该有所改观

也有些不太成功的数据缓冲,比如EJB中的实体Bean,性能就不尽如人意,实体Bean数据也是放在内存中,可能是因为占用内存过多的缘故

相对来说,今天的程序员写客户端数据缓冲,能够超过以上两个缓冲效果的,已经比较难了

以上就是关于教你设计大型Oracle数据库全部的内容,包括:教你设计大型Oracle数据库、大型ERP数据库系统常见的几种设计有什么(ERP系统设计)、等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址:https://54852.com/sjk/9438790.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-04-28
下一篇2023-04-28

发表评论

登录后才能评论

评论列表(0条)

    保存