Oracle后台数据库设计规范.doc

Oracle后台数据库设计规范1732020年4月19日文档仅供参考目录1前言51.1编写目的51.2预期读者61.3数据库部署模式61.4单机模式61.5HA热备模式71.6RAC模式81.7DATAGUARD模式91.8RAC+DATAGUARD模式92数据库部署模式选择建议102.1部署模式的选择建议102.2各部署模式应用建议102.3RAC部署模式应用建议112.4操作系统参数建议122.4.1AIX122.4.2HP133数据库设计考虑的因素143.1数据库类型特点分析143.1.1OLTP（联机事务处理）153.1.2OLAP（联机分析处理）153.1.3BATCH（批处理系统）153.1.4DSS（决策支持系统）153.1.5Hybrid（混合类型系统）163.2数据库规模164数据库部署前提建议164.1数据库产品选择建议164.2磁盘阵列布局原则165数据库物理结构设计175.1软件安装路径及环境变量175.2数据库实例的命名规则185.3表空间设计185.3.1业务数据量的估算185.3.2表空间的使用规则195.3.2.1表空间的类型205.3.2.2表空间及其文件的命名规则215.3.3表空间的物理使用规则245.3.3.1表空间的物理分布245.3.3.2表空间的存储参数的设置245.3.4表空间的参数设置原则265.3.4.1Extent的管理265.3.4.2Segemnt的管理275.3.4.3Autoextend_Clause295.3.5表的参数设置原则295.3.5.1Undo/temp表空间的估算305.3.6索引的使用原则305.4文件设计325.4.1RAC配置文件325.4.2参数文件325.4.2.1参数文件命名规则325.4.3控制文件335.4.3.1控制文件命名规则345.4.4重做日志文件345.4.4.1日志文件命名规则356数据库应用366.1数据库用户设计366.1.1数据库用户的权限366.1.1.1用户权限控制原则366.1.1.2用户及其权限规范376.1.1.3各用户类型的角色命名规范386.1.2数据库用户安全的实现396.1.2.1数据库特权396.1.2.2角色396.1.2.3授予权限和角色416.1.2.4数据库默认用户436.1.2.5数据库用户密码446.2数据库分区446.2.1数据库分区介绍446.2.2逻辑分割446.2.3物理分割456.2.4分区后对数据库管理的好处456.2.5分区对数据库规划、创立带来的负面影响456.2.6Oracle分区技术456.2.7分区使用选择466.2.8分区索引476.2.8.1全局索引(GLOBAL index )476.2.8.2本地索引(LOCAL index)476.3数据库实例配置486.3.1数据库字符集486.3.2数据库版本和补丁集496.4数据库参数设置496.4.1必须修改的初始化参数496.4.1.1DB_CACHE_SIZE496.4.1.2SHARED_POOL_SIZE506.4.1.3LARGE_POOL_SIZE516.4.1.4DB_BLOCK_SIZE516.4.1.5SP_FILE526.4.1.6PGA_AGGREGATE_TARGET526.4.1.7PROCESSES526.4.1.8OPEN_CURSORS536.4.1.9MAX_DUMP_FILE_SIZE536.4.1.10RECOVERY_PARALLELISM536.4.1.11PARALLEL_EXECUTION_MESSAGE_SIZE536.4.1.12INSTANCE_GROUPS（RAC）546.4.1.13PARALLEL_INSTANCE_GROUP（RAC）546.4.1.14与DRM有关的隐藏参数（RAC）556.4.2系统优化建议修改的初始化参数556.4.2.1SESSION_CACHED_CURSORS556.4.2.2BACKUP_TAPE_IO_SLAVES556.4.2.3JAVA_POOL_SIZE566.4.2.4OPTIMIZER_INDEX_COST_ADJ566.4.3不得修改的初始化参数566.4.3.1COMPATIBLE566.4.3.2CURSOR_SHARING576.4.3.3SGA_TARGET576.4.3.4SGA_MAX_SIZE576.4.4建议不修改的初始化参数586.4.4.1UNDO_RETENTION586.4.4.2SESSIONS586.4.4.3TRANSACTIONS586.4.4.4DB_KEEP_CACHE_SIZE596.4.4.5LOCK_SGA596.4.4.6DB_FILES606.4.4.7DB_FILE_MULTIBLOCK_READ_COUNT606.4.4.8LOG_BUFFER606.4.4.9FAST_START_MTTR_TARGET616.4.5与并行操作有关的参数616.5数据库连接服务626.5.1专用服务器连接626.5.2共享服务器连接636.5.3连接服务建议636.5.3.1专用服务器连接636.6数据库安全建议646.6.1采用满足需求的最小安装646.6.2安装时的安全646.6.2.1删除或修改默认的用户名和密码646.6.2.2安装最新的安全补丁646.7数据库备份和恢复656.7.1RMAN 备份656.7.2Export/import备份656.7.3存储级备份虚拟带库666.7.4数据库恢复666.7.4.1实例故障的一致性恢复666.7.4.2介质故障或文件错误的不一致恢复666.8ORACLE NETWORK 配置676.8.1监听器的使用配置原则676.8.2TNSNAMES的使用配置原则676.8.3RAC环境下TNSNAMES的配置686.8.3.1各节点启用负载均衡686.8.3.2各节点不启用负载均衡697数据库开发建议697.1数据库模型设计规范697.1.1命名规则697.1.2表717.1.2.1建表的参数设置717.1.2.2主外键设计717.1.2.3列设计727.1.2.4临时表727.1.3索引727.1.4视图727.1.5存储过程、函数和包737.1.6触发器737.1.7序列737.1.8Directory737.1.9别名737.1.10Database Link747.2PLSQL开发规则747.2.1总体开发原则747.2.2程序编写规则747.2.2.1在PL/SQL中使用SQL747.2.2.2变量声明原则767.2.2.3游标777.2.2.4集合817.2.2.5动态PL/SQL867.2.2.6对象897.2.2.7大对象类型（LOB）927.2.2.8包（PACKAGE ）1017.2.3故障处理规则1027.3SQL语句编写规则1047.3.1查询语句的使用原则1047.3.1.1索引的正确使用1047.3.1.2使用连接方式的原则1077.3.1.3进行复杂查询的原则1117.3.2DML语句的调整原则1157.3.2.1Oracle存储参数的影响1157.3.2.2大数据类型的影响1167.3.2.3DML执行时约束的开销1177.3.2.4DML执行时维护索引所需的开销1171 前言1.1 编写目的为总结我XXXX建设的成果，加强XXXX平台建设工作的规范化管理，我们梳理了XXXX平台基础设施设计的相关文档，并进行了深化、细化，力求结合实际的设计、实施工作，对设计、实施起到规范、指导作用。本指南主要从一个设计者的角度进行阐述，相关章节也按此思路编写。作为一个设计者，首先要了解产品可实现的部署模式，如何选择部署模式，其次要考虑设计涉及到的因素，有针对性地做好数据库的设计等；为提高数据库的性能，对程序开发提出了的要求。在界线的划分上，基础产品只涉及本产品的设计，上层应用产品对基础产品的需求放在应用产品中，例如，ORACLE部署对AIX的要求，放在ORACLE设计指导中。在编写过程中，特别关注可操作性，不但仅是要求，而是提出建议，尽量覆盖设计工作中涉及的工作要点。本指南中参数建议值是对系统设计时的指导，是合理的经验值，但由于应用系统的复杂性，每个系统有自己的特点，建议按建议值进行系统的初始配置，在压力测试和系统上线后根据实际需要做相应的调整。附件中列出了ERP/CLPM/CCBSBS/EBANK四个系统的oracle数据库配置参数以及相应的AIX、HP系统配置参数，作为系统设计的参考。1.2 预期读者项目基础设施可行性研究、设计和实施人员，项目组应用系统设计人员，相关运行维护技术人员。1.3 数据库部署模式1.4 单机模式数据库服务器采用单服务器模式，满足对可用性和性能要求不高的应用，具备以下特点:1、 硬件成本低。单节点，硬件投入较低，满足非重要系统的需求。2、 安装配置简单。由于是单节点、单实例，因此安装配置比较简单。3、 管理维护成本低。单实例，维护成本低。4、 对应用设计的要求较低。由于是单实例，不存在RAC系统应用设计时需要注意的事项，因此应用设计的要求较低。5、 可用性不高。由于是单服务器、单实例，因此服务器和实例的故障都会导致数据库的不可用。6、 扩展性差。无法进行横向扩展，只能进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能进行增加硬件配置等纵向扩展，且扩展性有局限。7、 根据该模式的特点有如下要求：1) 硬件配置方面预留扩展量。由于该模式无法进行横向扩展，因此在选择硬件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。2) 充分考虑该模式是否满足应用未来一段时间的需求。需要考虑应用在未来一段时间是否会发生变化，该模式是否满足应用变化的需求。1.5 HA热备模式数据库服务器采用HA热备模式，能够满足对可用性有一定要求的应用，具备以下特点：1、 需要冗余的服务器设备。该模式需要有冗余的服务器硬件，以满足一备一或者一备多的需求。硬件成本较高。2、 需要HA软件的支持。该模式需要配合HA软件才能够实现。3、 安装配置相对简单。该模式比单节点、单实例的模式配置复杂一些，需要更多的配置步骤，但相比较RAC、DATAGUARD等模式要简单。4、 管理维护成本低。单实例，对维护人员的要求较低，维护成本低。5、 对应用设计的要求较低。由于是单实例，不存在RAC系统应用设计时需要注意的事项，因此应用设计的要求较低。6、 具备一定的高可用性。由于是多服务器、单实例，因此服务器和实例有故障时会发生实例在不同服务器上的切换，导致数据库的暂时不可用。无法满足对可用性有严格要求的应用类型。7、 扩展性差。无法进行横向扩展，只能进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能进行增加硬件配置等纵向扩展，且扩展性有局限。根据该模式的特点有如下要求：3) 硬件配置方面预留扩展量。由于该模式无法进行横向扩展，因此在选择硬件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。4) 充分考虑该模式是否满足应用未来一段时间的需求。需要考虑应用在未来一段时间是否会发生变化，该模式是否满足应用变化的需求。1.6 RAC模式数据库服务器采用RAC模式，满足对高可用性要求高的应用类型，具备以下特点:1、 需要多个硬件服务器。根据节点的个数，相应的需要多个硬件服务器。硬件成本较高。2、 某些数据库版本需要HA软件的支持。该模式下，某些数据库版本需要配合HA软件才能够实现。3、 安装配置复杂。该模式比起单实例模式，安装配置相对复杂，安装配置周期长。4、 管理维护成本高。该模式的管理维护，对管理维护人员的要求较高，管理维护成本较高。5、 对应用设计的要求较高。需要充分考虑业务的逻辑性，以避免在多节点之间的信息交换和全局锁的产生。6、 具备较高的高可用性。由于是多服务器、多实例，单服务器和实例有故障不会影响数据库的可用性。能够满足对可用性有严格要求的应用类型。7、 扩展性好。既能够进行横向扩展，也能够进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库能够经过增加节点的方式进行横向扩展，也能够经过增加硬件配置等纵向扩展，具备良好的扩展性。根据该模式的特点有如下要求：1、 硬件配置方面预留扩展量。预留一定的硬件扩展量，能够更灵活的进行扩展。2、 在应用设计时，充分考虑业务逻辑，减少多节点间的信息交换量，更好的发挥RAC的优点。1.7 DATAGUARD模式数据库服务器采用DATAGUARD灾备模式，能够满足对可用性有特殊需求的应用，具备以下特点：8、 需要冗余的服务器设备。该模式需要有冗余的服务器硬件。硬件成本较高。9、 需要冗余的存储设备。主机和备机都需要同样的存储空间，成本较高。10、 安装配置比较复杂。该模式比单节点、单实例的模式配置复杂一些，需要更多的配置步骤。11、 管理维护成本高。该模式对维护人员的要求较高，维护成本高。12、 具备一定的容灾特性。当主机整个数据库系统不可用并短期内无法恢复时，能够把数据库系统切换到备机上，具备容灾的功能。13、 备机能够用作只读查询。备机能够切换到只读状态供报表之类的查询操作，减轻主机的压力。根据该模式的特点有如下要求：1、 主机与备机在物理上要分开。为了实现容灾的特性，需要在物理上分割主机和备机。2、 进行合理的设计，充分实现DATAGUARD的功能。1.8 RAC+DATAGUARD模式数据库服务器采用RAC+DATAGUARD模式，能够满足对可用性和容灾都有特定需求的应用，具备以下特点：1、 需要冗余的服务器设备。该模式需要有冗余的服务器硬件。硬件成本较高。2、 需要冗余的存储设备。主机和备机都需要同样的存储空间，成本较高。3、 安装配置比较复杂。该模式既需要配置RAC又需要配置DATAGUARD，配置过程比较复杂，配置周期长。4、 管理维护成本高。该模式对维护人员的要求较高，维护成本高。5、 具备很高的可用性和容灾性。该模式既满足高可用性也满足容灾的需求。6、 备机能够用作只读查询。备机能够切换到只读状态供报表之类的查询操作，减轻主机的压力。根据该模式的特点有如下要求：1、 主机与备机在物理上要分开。为了实现容灾的特性，需要在物理上分割主机和备机。2、 进行合理的设计，充分实现DATAGUARD的功能。2 数据库部署模式选择建议2.1 部署模式的选择建议在设计数据库时必须考虑系统的可用性、业务连续性要求，针对系统的可用性需求，采用不同的数据库部署模式：1、 对RTO=0、RPO=0的系统，建议数据库采用RAC或 RAC+DataGuard模式，数据库单台设备故障时对业务没有影响，并考虑灾备系统的设计。2、 对RTO=4小时，RPO15分钟的系统，建议数据库采用HA热备或DataGuard的模式，设备故障时经过HA技术切换到备用设备，保证系统的可用性，对重要的系统要考虑灾备的设计。3、 对4小时RTO8小时，RPO15分钟的系统，数据库可采用冷备的模式，在系统故障时，启动设备，保障系统的可用性。4、 对8小时RTO，RPO15分钟的系统，数据库可考虑1备多的模式或不考虑设备的冗余。5、 对行内非关键系统，建议采用PC服务器、冷备或单机的处理模式。2.2 各部署模式应用建议1、 应用必须使用绑定变量（特别是OLTP型应用）；2、 对于aix系统，建议在操作系统配置文件.profile中设置 export AIXTHREAD_SCOPE = S；3、 频繁使用的小表要放入库缓存中；4、 频繁使用的index需要放入库缓存的keep池中；5、 不使用select * from xxxxx for update；如果可能的话，考虑使用select *from xxxxx for update no wait替代；6、 对于表空间，建议使用自动段空间管理（ASSM）；7、 对于存储频繁更新的数据的表空间或者表，建议设置较大的pctfree，以避免行迁移和行链接；8、 如果使用raw device，建议使用AIO，各个平台的配置稍有不同；2.3 RAC部署模式应用建议1、 尽可能主要是根据应用访问的数据进行划分，主要是减少不同数据库节点之间数据的交互；连接方式上，最好手工指定连接到特定节点，取消负载均衡，并打开failover；2、 在RAC环境下使用sequence，sequence的cache属性不建议使用缺省值（20），需要增加 cache size，如cache size 100000（能够根据业务需求定，如使用较频繁的设置为更多）。常见的sequence相关bug：Note:395314.1-RAC Hangs due to small cache size on SYS.AUDSES$；(10.2.0.3以前，SYS.AUDSES$的CACHE_SIZE默认为20,而在10.2.0.3以后，则修改为10000)3、 内部互连的连接方式：RAC之间的内部通讯网络（inter-connect）建议不使用交叉直连(crosscable)，Oracle不支持这种模式，一定要使用SAN(switch)的连接方式(如，交换机)，直连方式的稳定性差，在网络故障时，两个节点都会down或hang ；需要使用千兆网线（光纤）连接千兆网卡（光纤卡）；4、 关闭操作系统CLUSTER 软件中网卡的failover功能， 如HACMP 中的IP failover功能，MC SERVERS GUARD如果有类似功能也建议关闭。能够采用网卡绑定的方式实现网卡的failover功能；5、 对于较小的表或者访问较快的表，不使用parallel且不设置degree；对于一般的并行操作，经过设置并行参数（instance_groups和parallel_instance_group）将不同节点发起的请求设计在一个节点完成；(ALTER SYSTEM SET instance_groups=sjzzw1,sjzzw11 SCOPE=SPFILE SID=sjzzw11;ALTER SYSTEM SET instance_groups=sjzzw1,sjzzw12 SCOPE=SPFILE SID=sjzzw12;ALTER SYSTEM SET parallel_instance_group=sjzzw11 SCOPE=BOTH SID=sjzzw11;ALTER SYSTEM SET parallel_instance_group=sjzzw12 SCOPE=BOTH SID=sjzzw12;)6、 10g设置CSS diagwait参数为13以便在OS CPU资源紧张重启主机前有足够的时间导出trace文件。设置办法：在所有RAC节点关闭，且CRS各进程都退出后，运行#crsctl set css diagwait 13 force，确认办法：#crsctl get css diagwait。设置正确返回值13，未设置时，返回信息“Configuration parameter diagwait is not defined”7、 RAC 的private、public IP严格要求要在不同网段，两个IP都要求进行网卡绑定：HP使用APA，AIX使用EthernetChannel，按主备方式进行，需要保证网卡绑定后从ORACLE看到的是一个固定的逻辑设备。2.4 操作系统参数建议2.4.1 AIX以下是建议的网络参数配置：#/usr/sbin/no -r -o rfc1323=1#/usr/sbin/no -r -o ipqmaxlen=512#/usr/sbin/no -r -o sb_max=4*1048576 4M#/usr/sbin/no -r -o udp_sendspace=1048576 1M#/usr/sbin/no -r -o udp_recvspace=1048576 1M能够使用netstat -s命令检查是否有socket buffer overflows信息，如果有，则可能需要调整上述参数。打开对文件大小等的限制：fsize = -1cpu = -1data = -1stack = -1core = 2097151 rss = -1nofiles = -1fsize_hard = -1cpu_hard = -1data_hard = -1stack_hard = -1rss_hard = -1nofiles_hard = -12.4.2 HP参数名称HP默认值ORACLE要求值参数说明oracle计算公式MAX_THREAD_PROC2561024定义每个进程允许的最大线程数量，此值必须设置为64-nkthread之间MAXSSIZ8388608(8MB)设定32位系统堆栈段大小的最大值MAXSSIZ_64BIT(256MB)设定64位系统堆栈段大小的最大值NPROC 42008192设定系统支持的进程的最大数量，此值须设置为：100-60000之间NINODE 此值根据系统内存大小初定默认值，当内存1G时默认为819267584设定打开索引节点的最大数量，此值最小值为14，最大值则限于系统内存大小。 (8*NPROC+2048)MAXUPRC2567374设定用户进程数量的最大值，此值必须设置为：3到nproc-5之间(NPROC*9)/10)+1MSGMNI5128192设定系统允许消息队列标识符的最大数，必须设置为：1到1000000之间(NPROC) MSGTQL10248192设定系统允许消息的最大数，此值必须设置为：1到之间(NPROC) NCSIZE897668608设定索引节点所需的目录名查找高速缓存（DNLC）空间(NINODE+1024)NFLOCKS此值根据系统内存大小初定默认值，当内存1G时默认为40968192设定系统上可用文件锁的最大数量。此值须设置为50-16777216(NPROC) SEMMNI 20488192设定整个系统信号量集的最大数量。此值须设置为：2到semmns之间，(NPROC)SEMMNS 409616384设定整个系统信号量的数量.此值须设置为：semmni到之间(SEMMNI*2)SEMMNU 2568188设定信号量undo结构的数量。此值须设置为：1到nproc-4之间。(NPROC - 4) SHMMAX 1G可用内存数量设定一个共享内存段的最大允许尺寸。SHMMAX设定值应足够大，以便在一个共享内存段中装下整个SGA。设置过低的结果是创立多个共享内存段，这样会降低性能。此值须设置为：2k到4TB之间，此值的设定请根据系统内存容量以及应用需要综合考虑设置。SHMMNI 400512设定整个系统中共享内存段的最大数量。此值须设置为：3到32768之间VPS_CEILING16(KB)64设定由系统选择的页面的最大尺寸，以KB为单位。此值须设定为4(KB)到4194304(KB)之间。以上参数针对HP 11.313 数据库设计考虑的因素3.1 数据库类型特点分析在创立和规划一个Oracle数据库之前，首要任务应确定将来投产的数据库属于何种业务类型。当前的应用业务有以下类型：1、 OLTP(Online Transaction Processing)2、 OLAP（Online Analytiacl Processing）3、 BATCH 4、 DSS（Decision Support System）5、 Hybrid3.1.1 OLTP（联机事务处理）OLTP数据库支持某种特定的操作，OLTP系统是一个包含繁重及频繁执行的DML应用，其面向事务的活动主要包括更新，同时也包括一些插入和删除。经典的例子是预定系统或在线时时交易系统，例如网上银行和ATM自动取款机系统。OLTP系统能够允许有很高的并发性（在这种情况下，高并发性一般表示许多用户能够同时使用一个数据库系统）。3.1.2 OLAP（联机分析处理）OLAP系统可提供分析服务。这意味着数学、统计学、集合以及大量的计算，一个OLAP系统并不永远适合OLTP或DSS模型，有时它是两者之间的交叉。另外，也能够把OLAP看作是在OLTP系统或DSS之上的一个扩展或一个附加的功能层次。一般，地理信息系统或有关空间的数据库和OLAP数据库相集成，提供图表的映射能力。用于社会统计的人口统计数据库就是一个很好的例子。3.1.3 BATCH（批处理系统）批作业处理系统是作用于数据库的非交互性的自动应用。它一般含有繁忙DML语句并有较低的并发性（在这种情况下，较低的并发性一般表示少数几个用户能够同时使用一个数据库系统），该业务系统会在某一时段，大批量数据（少则几万，多则几十万，几百万条数据）更新/插入/删除该数据库。事务查询的比率决定了如何物理地设计它，经典的例子是与DW有关的成品数据库和可操作数据库，如：操作型数据存储系统（ODS）。3.1.4 DSS（决策支持系统）DSS系统一般是一个大型的、包含历史性内容的只读数据库，一般见于简单的固定查询或特别查询。DSS常常按某种方式变成一个VLDB（Very Large Database）或DW（Data Warehouse）。VLDB的例子如：企业资源管理财务系统（ERP）数据库，该数据库是一个长期存储数据库的历史数据库；DM的例子如：整个集团的工资和人事数据库。3.1.5 Hybrid（混合类型系统）同时数据库系统的应用类型可能是OLTP、OLAP、BATCH等的混合体。也意味着同时拥有上述业务类型特征，这就要求数据库管理员、应用系统分析员、操作系统管理员整体统筹考虑各种业务性能需求及功能需求，对这个系统制定出满足各种业务类型需求的规划，如：企业客户信息整合（ECIF）系统。3.2 数据库规模对于数据库的规模，仅从数据量来衡量其规模的大小。因为数据量的规模是反映数据库规模的主要指标。具体如下：1、 数据库业务数据量小于100GB 属小规模数据库2、 数据库业务数据量100GB-600GB属中等规模数据库3、 数据库业务数据量600GB-1TB 属大规模数据库4、 数据库业务数据量大于1TB 属超大规模数据库4 数据库部署前提建议4.1 数据库产品选择建议Oracle数据库产品推出新的主要版本后，要经历一个版本不稳定期。在此期间新版的数据库产品存在较多的bug。在安装和运行过程中，会存在数据库部署安装困难和运行出现不稳定现象。因此在选择版本时，要选择成熟稳定的版本。具体安装要求须参照Oracle版本策略最新版。4.2 磁盘阵列布局原则随着硬件技术的发展，当前磁盘阵列的使用变得越来越普遍，由于磁盘阵列和单个磁盘具有较大的不同，故此在数据库的物理划分上也有较大的不同。对于磁盘阵列系统，由于RAID的划分，不存在一个个真实的物理盘，对应的是物理卷(PV)，逻辑卷组(VG)，逻辑卷(LV)。在这种情况下Oracle推荐使用SAME技术，即全部镜像和条带化(Stripe And Mirror Everything)。在对磁盘阵列做SAME处理后，所有的逻辑卷都分布在所有的物理磁盘上，每个逻辑卷的读写都能够利用的到所有的物理磁盘的吞吐能力，同时获得较高的可靠性。同时我们在使用磁盘设备的时候不需要考虑各个不同文件的IO情况，因为它们都使用同样的全部磁盘的吞吐能力，这进一步简化了数据库系统的文件管理工作，避免一些意外的操作。对较重要、而且效率要求较高的系统推荐使用RAID0+1的磁盘配置而不使用RAID5，因为RAID5的校验技术会降低应用数据库系统的效率。但使用RAID0+1，比RAID5需要更多物理磁盘。不同的类型对象，尽量分布在不同的卷组上，建议：1、 表对应的数据和索引分别放置在不同的物理磁盘上；2、 控制文件的多个备份分别放置在不同的物理磁盘上；3、 REDO日志组的多个成员放置在不同的物理磁盘上；4、 建议将Oracle文件、SYSTEM表空间、TEMPORARY表空间、UNDO表空间放置在不同的物理磁盘上；5 数据库物理结构设计5.1 软件安装路径及环境变量建立单独的文件系统来安装数据库软件，且文件系统的mount点不要直接建立在根目录下。安装路径： /home/db/oracle各种环境变量设置：ORACLE_BASE=/home/db/oracleCRS_HOME=/home/db/oracle/crs/数据库release版本，如/home/db/oracle/crs/10.2.0ORACLE_HOME=/home/db/oracle/product/数据库release版本，如/home/db/oracle/product/10.2.0当前( .3)推荐版本为10gR2，写为10.2.0,下一个版本（计划从 .5开始推荐）为11gR2，写为11.2.0, 5.2 数据库实例的命名规则普通使用模式的Oracle数据库的服务名和实例名（SID）是相同的；RAC模式下的Oracle数据库的服务名与实例名不同。数据库服务名的命名格式为：XXXYYdbm数据库的SID的命名格式为：XXXYYdbmn说明：1、 其中XXX表示长度为3个字符的应用项目缩写，具体的见相关设计文档。2、 YY：代表数据库用途，pd代表生产库，hi代表历史库，rp代表报表库，cf代表配置库；3、 m表示数据库序号，从0-9，根据项目的数据库数量进行编号。4、 n表示RAC节点实例序号1,2,3。用以区分多节点的RAC数据库的不同实例。对于普通模式的数据库，该位不指定。5.3 表空间设计5.3.1 业务数据量的估算估算所有业务SCHEMA下的所有table的尺寸。数据量估算的前提：l 数据库的物理表结构已经确定，而且设计已凝固。l 用户方提供较为准确的估算依据，例如业务变动的频率、数据需要保存的周期等。该表是一个示例，可根据业务的不同有所变化。序号表名增长量（/小时/天/周）增长量（/月/半年）年数据量数据库生命周期内的总计1.2.3.4.5.6.7.8.9.10.11.合计新上线或扩容时，对所申请的存储不得全部一次性挂上，应该预留出30左右的空间用于追加，以防止出现业务发展和预期不一致时剩余空间多寡不均，调整困难。操作系统上应该预先做好几个合适大小的lv备用，包括用于system/sysaux等表空间的小尺寸的lv和用于数据表空间、索引表空间的大尺寸lv，这些lv要求在HA两边主机都可见，不必单纯因为数据库增加数据文件而需要重新同步HA。5.3.2 表空间的使用规则当前多数数据库系统采用数据“大集中”原则，对数据库的性能要求较高。这就要求对数据库进行必要的优化配置。表现在表空间的配置上，应遵循以下原则：1、 最小化磁盘I/O。2、 在不同的物理磁盘设备上，分配数据。3、 尽可能使用本地管理表空间。多数系统采用RAID1+0 或 RAID0+1，该技术很好的解决了最小化磁盘I/O。基本不必考虑在不同的物理磁盘设备上，分配数据的原则。5.3.2.1 表空间的类型按照表空间所包含的数据文件类型，Oracle表空间类型有三类：1、 数据表空间（permanence tablespace）-用来保存永久数据，包含永久数据文件。强烈建议在永久表空间内创立永久数据文件，不要创立临时数据文件。2、 临时表空间（temporary tablespace）-用来保存临时数据，多用于数据的磁盘排序。强烈建议在临时表空间内创立临时数据文件，不要创立永久数据文件。3、 回滚表空间（rollback/undo tablespace）-仅用来保存回退信息。不能在该表空间创立其它类型的段（如表、索引等）。为了更好的管理表空间，同时提高Oracle数据库系统性能，在上述三类基础上，针对数据的业务功能，进一步对其加以分类。因此Oracle数据库的表空间划分为基本表空间和应用表空间。如下表：（1） 基本表空间：是指Oracle数据库系统为其自身运行而使用的表空间。表空间类别表空间名称存储内容说明数据表空间SYSTEM表空间存储oracle数据库系统数据字典对象Oracle数据库系统