Oracle数据库规划设计和运行维护方案.docx

Oracle数据库规划设计和运行维护方案

285
2020年4月19日
文档仅供参考

Oracle数据库规划设计
和运行维护方案
（V1.0）

目 录
1. 前言 7
1.1. 编写目的 7
1.2. 方案说明 7
1.3. 预期读者 8
2. 数据库部署模式 8
2.1. 单机模式 8
2.2. 双机热备模式（HA模式） 8
2.3. 集群模式（RAC） 9
2.4. 主从模式（DataGuard） 10
2.5. 混合模式（DataGrard+RAC） 11
2.6. 数据库运行模式选择 11
3. 系统特点和数据库类型 12
3.1. 业务系统的特点 12
3.1.1. OLTP特点 12
3.1.2. OLAP特点 13
3.2. 数据库的规模 13
3.3. 数据库版本建议 14
4. 数据库运行环境规划 14
4.1. 主机规划 14
4.2. 网络规划 15
4.3. 存储规划 17
5. 数据库安装部署规划 18
5.1. 软件安装路径 18
5.2. 表空间设计 19
5.2.1. 业务数据量估算 19
5.2.2. 表空间使用规则 20
5.2.3. 表空间的概念和分配原则 24
5.2.4. 表空间的参数配置 25
5.2.5. Undo/temp表空间的估算 29
5.2.6. 表的参数设置 29
5.2.7. 索引的使用原则 30
5.3. 文件设计 31
5.3.1. RAC配置文件 31
5.3.2. 参数文件 31
5.3.3. 控制文件 33
5.3.4. 重做日志文件 34
6. 数据库应用规划 35
6.1. 数据库用户设计 35
6.1.1. 用户权限规划 35
6.1.2. 用户安全实现 37
6.1.3. 用户类型及角色命名规范 39
6.2. 数据库分区 41
6.2.1. 数据库分区介绍 41
6.2.2. 逻辑分割 42
6.2.3. 物理分割 42
6.2.4. 数据分区的优点 42
6.2.5. 数据分区的不足 43
6.2.6. Oracle分区技术 43
6.2.7. 分区使用建议 44
6.2.8. 分区索引 44
6.3. 数据库实例配置 45
6.4. 数据库参数设置 46
6.4.1. 必须修改的初始化参数 46
6.4.2. 建议修改的初始化参数 51
6.4.3. 不可修改的初始化参数 53
6.4.4. 建议不可修改的初始化参数 54
6.4.5. 与并行有关的参数 57
6.5. 数据库连接服务 58
6.5.1. 专用服务器连接 58
6.5.2. 共享服务器连接 59
6.5.3. 连接服务建议 59
6.6. 数据库安全建议 59
6.7. 数据库备份和恢复 60
6.7.1. RMAN备份 60
6.7.2. EXP/IMP备份 61
6.7.3. 存储级备份 61
6.7.4. 数据库恢复 62
6.8. 数据库网络配置 63
6.8.1. 监听器的使用配置原则 63
6.8.2. TNSNAMES的使用配置原则 63
6.8.3. RAC环境下TNSNAMES的配置 63
7. 业务系统开发建议 65
7.1. 数据库模型设计规范 65
7.1.1. 命名规则 65
7.1.2. 数据库对象 66
7.2. PLSQL开发规则 69
7.2.1. 总体开发原则 69
7.2.2. 程序编写规范 70
7.3. SQL语句编写规则 97
7.3.1. 查询语句的使用原则 97
7.3.2. DML语句的调整原则 108
8. 数据库体系结构 112
8.1. 整体结构 112
8.2. 内存结构 112
8.2.1. 系统全局区（SGA） 113
8.2.2. 程序全局区（PGA） 116
8.2.3. 后台进程 116
8.3. 存储结构 119
8.3.1. 物理结构 119
8.3.2. 逻辑结构 121
9. 数据库基本管理 123
9.1. 参数文件管理 123
9.2. 表空间管理 124
9.2.1. 用户表空间管理 124
9.2.2. 临时表空间管理 127
9.2.3. 回滚段表空间管理 131
9.3. 重做日志文件管理 133
9.3.1. 增加重做日志文件组 133
9.3.2. 添加重做日志文件组成员 133
9.3.3. 改变重做日志文件组成员 134
9.3.4. 删除重做日志文件组成员 134
9.3.5. 删除重做日志文件组 134
9.3.6. 重做日志切换 135
9.3.7. 重做日志清理 135
9.3.8. 重做日志切换次数查询 135
9.4. 归档模式设置 137
9.4.1. 单实例数据库设置归档模式 137
9.4.2. RAC数据库设置归档模式 137
9.4.3. 归档路径设置 138
9.5. 控制文件重建 139
9.6. 内存参数管理 141
9.6.1. Oracle内存管理发展阶段 141
9.6.2. 自动内存管理AMM 141
9.6.3. 自动共享内存管理ASMM 141
9.6.4. 自动PGA管理 142
9.7. 其它管理内容 142
9.7.1. 查看数据库版本 142
9.7.2. 数据库字符集 143
9.7.3. 创立密码文件 143
9.7.4. 关闭数据库审计功能 143
9.7.5. 账号管理 144
9.7.6. Profile管理 144
10. 数据库集群（RAC）管理 144
10.1. RAC状态检查 144
10.1.1. 检查守护进程 144
10.1.2. 检查资源状态 145
10.2. RAC启动与关闭 145
10.3. 管理OCR 146
10.3.1. OCR盘状态查看 146
10.3.2. OCR备份与恢复 146
10.3.3. 查看OCR内容 147
10.3.4. 指定OCR盘 147
10.3.5. 增加OCR盘 147
10.3.6. 删除OCR盘 148
10.4. 管理VOTING DISK 148
10.4.1. 检查Voting Disl盘 148
10.4.2. VOTING DISK备份与恢复 148
10.4.3. 添加VOTING DISK盘 149
10.4.4. 删除VOTING DISK盘 149
10.5. CSS管理 149
10.6. SRVCTL管理工具 149
10.6.1. 管理实例 150
10.6.2. 管理监听程序 150
10.6.3. 管理ASM 151
10.6.4. 管理service 151
10.7. 修改RAC的IP及VIP 152
10.7.1. 修改外网IP和心跳IP 152
10.7.2. 修改VIP 152
10.7.3. 查看与删除IP 153
10.8. 管理ASM 154
10.8.1. 管理DiskGroup 154
10.8.2. ASM兼容性管理 156
10.8.3. ASM中添加disk的方法 158
10.8.4. ASMCMD管理命令介绍 159
10.8.5. ASM常见视图 162
11. 数据库备份 164
11.1. 备份概念说明 164
11.1.1. 脱机备份 164
11.1.2. 联机备份 165
11.1.3. RMAN备份 166
11.2. 备份策略规划 166
11.3. RMAN备份和恢复案例 167
11.3.1. 归档模式下的完全恢复 167
11.3.2. 归档模式下的不完全恢复 170
12. 数据库运维管理 172
12.1. 运维职责 172
12.2. 运维要求 172
12.3. 技能要求 172
12.4. 运维内容 173
12.4.1. 检查数据库运行情况 173
12.4.2. 检查操作系统和数据库日志文件 175
12.4.3. 检查Oracle对象状态 176
12.4.4. 检查数据库相关资源的使用 179
12.4.5. 检查数据库备份 183
12.4.6. 检查数据库的性能 183
12.4.7. 数据库安全性检查 189

1. 前言
1.1. 编写目的
随着以使用Oracle数据库的应用系统不断增加，为了加强应用系统在规划、开发、实施、维护等环节工作的规范化，特编写本文档，力求对实际的设计、实施工作起到规范和指导作用。
本方案以设计者的角度进行组织编写，其主要思路是：作为设计人员首先要了解数据库系统的运行模式，如何选择运行模式，其次要考虑系统的规划设计因素，有针对性的做好数据库的设计，提高数据库的性能，并对系统开发也提出相关要求。
1.2. 方案说明
本方案分为两大部分，其中第一部分是第二到七章，主要介绍Oracle数据库的运行方式和规划设计以及与开发相关内容；第二部分是第八到十二章，主要介绍数据库的日常运行维护相关的内容。第一部分偏重于规划和开发，第二部分偏重于实际管理及命令。
其中：第二章介绍了Oracle数据库的部署运行方式；第三章介绍了业务系统特点和数据库的类型规模以及部署前的建议；第四章介绍了数据库运行的物理环境的配置规划；第五章介绍了Oracle数据库的安装部署规划以及命名原则；第六章介绍了数据库的应用规划；第七章介绍了系统开发的建议；第八章介绍数据库的体系架构；第九章介绍数据库的基本管理方法；第十章介绍了数据库集群的管理；第十一章介绍了数据库的备份和恢复；第十二章介绍了数据库的日常运行维护管理。
本方案编写过程中注重实际的可操作性，所提出的建议尽量覆盖系统生命周期中的各个关键点。其中所涉及的参数和指标对系统的建设和运营起指导作用，可是在实际工作中，每个系统都有各自的特点，因此建议在初期对系统进行初始配置后，应根据系统的实际运行状态进行相应调整。
1.3. 预期读者
项目基础设施可行性研究、设计和实施人员，项目组系统设计开发人员，相关运行维护技术人员。
2. 数据库部署模式
2.1. 单机模式
数据库服务器采用单服务器模式，满足对可用性和性能要求不高的应用，具备以下特点:
1、硬件成本低。单节点，硬件投入较低，满足非重要系统的需求。
2、安装配置简单。由于是单节点、单实例，因此安装配置比较简单。
3、管理维护成本低。单实例，维护成本低。
4、对应用设计的要求较低。由于是单实例，不存在RAC系统应用设计时需要注意的事项，因此应用设计的要求较低。
5、可用性不高。由于是单服务器、单实例，因此服务器和实例的故障都会导致数据库不可用。
6、扩展性差。无法进行横向扩展，只能进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能进行增加硬件配置等纵向扩展，且扩展性有局限。
7、根据该模式的特点有如下要求：
1) 硬件配置方面预留扩展量。由于该模式无法进行横向扩展，因此在选择硬件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。
2) 充分考虑该模式是否满足应用未来一段时间的需求。需要考虑应用在未来一段时间是否会发生变化，该模式是否满足应用变化的需求。
2.2. 双机热备模式（HA模式）
数据库服务器采用双机热备模式，能够满足对可用性有一定要求的应用，
具备以下特点：
1、需要冗余的服务器设备。该模式需要有冗余的服务器硬件，以满足一备一或者一备多的需求。硬件成本较高。
2、需要HA软件的支持。该模式需要配合HA软件才能够实现。
3、安装配置相对简单。该模式比单节点、单实例的模式配置复杂一些，需要更多的配置步骤，但相比较RAC、DATAGUARD等模式要简单。
4、管理维护成本低。单实例，对维护人员的要求较低，维护成本低。
5、对应用设计的要求较低。由于是单实例，不存在RAC系统应用设计时需要注意的事项，因此应用设计的要求较低。
6、具备一定的高可用性。由于是多服务器、单实例，因此服务器和实例有故障时会发生实例在不同服务器上的切换，导致数据库的暂时不可用。无法满足对可用性有严格要求的应用类型。
7、扩展性差。无法进行横向扩展，只能进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能进行增加硬件配置等纵向扩展，且扩展性有局限。
根据该模式的特点有如下要求：
1) 硬件配置方面预留扩展量。由于该模式无法进行横向扩展，因此在选择硬件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。
2) 充分考虑该模式是否满足应用未来一段时间的需求。需要考虑应用在未来一段时间是否会发生变化，该模式是否满足应用变化的需求。
2.3. 集群模式（RAC）
数据库服务器采用RAC模式，满足对高可用性要求高的应用类型，
具备以下特点:
1、需要多个硬件服务器。根据节点的个数，相应的需要多个硬件服务器。硬件成本较高。
2、某些数据库版本需要HA软件的支持。该模式下，某些数据库版本需要配合HA软件才能够实现。
3、安装配置复杂。该模式比起单实例模式，安装配置相对复杂，安装配置周期长。
4、管理维护成本高。该模式的管理维护，对管理维护人员的要求较高，管理维护成本较高。
5、对应用设计的要求较高。需要充分考虑业务的逻辑性，以避免在多节点之间的信息交换和全局锁的产生。
6、具备较高的高可用性。由于是多服务器、多实例，单服务器和实例有故障不会影响数据库的可用性。能够满足对可用性有严格要求的应用类型。
7、扩展性好。既能够进行横向扩展，也能够进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库能够经过增加节点的方式进行横向扩展，也能够经过增加硬件配置等纵向扩展，具备良好的扩展性。
根据该模式的特点有如下要求：
1)硬件配置方面预留扩展量。预留一定的硬件扩展量，能够更灵活的进行扩展。
2)在应用设计时，充分考虑业务逻辑，减少多节点间的信息交换量，更好的发挥RAC的优点。
2.4. 主从模式（DataGuard）
数据库服务器采用DataGuard主从模式，能够满足对可用性有特殊需求的应用，具备以下特点：
1、需要冗余的服务器设备。该模式需要有冗余的服务器硬件。硬件成本较高。
2、需要冗余的存储设备。主机和备机都需要同样的存储空间，成本较高。
3、安装配置比较复杂。该模式比单节点、单实例的模式配置复杂一些，需要更多的配置步骤。
4、管理维护成本高。该模式对维护人员的要求较高，维护成本高。
5、具备一定的容灾特性。当主机整个数据库系统不可用并短期内无法恢复时，能够把数据库系统切换到备机上，具备容灾的功能。
6、备机能够用作只读查询。备机能够切换到只读状态供报表之类的查询操作，减轻主机的压力。
根据该模式的特点有如下要求：
1）主机与备机在物理上要分开。为了实现容灾的特性，需要在物理上分割主机和备机。
2）进行合理的设计，充分实现DATAGUARD的功能。
2.5. 混合模式（DataGrard+RAC）
数据库服务器采用DataGuard+RAC模式，能够满足对可用性和容灾都有特定需求的应用，具备以下特点：
1、需要冗余的服务器设备。该模式需要有冗余的服务器硬件。硬件成本较高。
2、需要冗余的存储设备。主机和备机都需要同样的存储空间，成本较高。
3、安装配置比较复杂。该模式既需要配置RAC又需要配置DATAGUARD，配置过程比较复杂，配置周期长。
4、管理维护成本高。该模式对维护人员的要求较高，维护成本高。
5、具备很高的可用性和容灾性。该模式既满足高可用性也满足容灾的需求。
6、备机能够用作只读查询。备机能够切换到只读状态供报表之类的查询操作，减轻主机的压力。
根据该模式的特点有如下要求：
1）主机与备机在物理上要分开。为了实现容灾的特性，需要在物理上分割主机和备机。
2）进行合理的设计，充分实现DataGuard的功能。
2.6. 数据库运行模式选择
在设计数据库时必须考虑系统的可用性、业务连续性，针对系统所能容忍的最大业务中断时间（RTO）和最大数据丢失数量（RPO）需求，采用不同的数据库部署模式：
1、系统不能中断且不允许数据丢失的业务，建议数据库采用集群或混合模式，数据库单台设备故障时对业务没有影响，并考虑灾备系统的设计。
2、对于允许以分钟级别中断，数据不能丢失的系统，建议数据库采用双机热备或主从的模式，设备故障时经过HA技术切换到备用设备，保证系统的可用性，对重要的系统要考虑灾备的设计。
3、对于允许以天为级别中断的业务系统，建议可采用双机热备模式，或单机。
4、对非关键系统、开发环境、测试环境，建议采用PC服务器、冷备或单机的模式。
3. 系统特点和数据库类型
3.1. 业务系统的特点
业务系统处理数据的特点决定了设计人员规划和创立什么样的数据库，一般来说，业务分为两类：在线事务处理系统（OLTP）和在线分析系统（OLAP）或者DSS（决策支持系统）。这两类系统在数据库的设计上是不同的，比如OLTP 系统强调数据库的内存效率，强调各种内存指标的命中率，强调绑定变量，强调并发操作：而OLAP 系统则强调数据分析，强调SQL 执行时长，强调磁盘I/O，强调分区等。
3.1.1. OLTP特点
一般OLTP（在线事务处理系统）的用户并发数很多，但只对数据库做很小的操作，数据库侧重于对用户操作的快速响应，这是对数据库最重要的性能要求。
对于一个OLTP 系统来说，数据库内存设计非常重要，如果数据都能够在内存中处理，那么数据库的性能会提高很多。
内存的设计一般是经过调整Oracle 和内存相关的初始化参数来实现的，比较重要的几个是内存相关的参数，包括SGA 的大小（Data Buffer，Shared Pool），PGA 大小（排序区，Hash 区等）等，这些参数对一个OLTP系统是非常重要的。OLTP 系统是一个数据块变化非常频繁，SQL 语句提交非常频繁的一个系统。对于数据块来说，应尽可能让数据块保存在内存当中，对于SQL 来说，尽可能使用变量绑定技术来达到SQL的重用，减少物理I/O 和重复的SQL解析，能极大的改进系统的性能。
另外，没有绑定变量的SQL会对OLTP 数据库造成极大的性能影响，还有一些因素也会导致数据库的性能下降，比如热块（hot block）的问题，当一个块被多个用户同时读取的时候，Oracle 为了维护数据的一致性，需要使用Latch 来串行化用户的操作，当一个用户获得了这个Latch，其它的用户就只能被迫的等待，获取这个数据块的用户越多，等待就越明显，就造成了这种热块问题。这种热块可能是数据块，也可能是回滚段块。对于数据块来讲，一般是数据块上的数据分布不均匀导致，如果是索引的数据块，能够考虑创立反向索引来达到重新分布数据的目的，对于回滚段数据块，能够适当多增加几个回滚段来避免这种争用。
3.1.2. OLAP特点
OLAP 数据库在内存上可优化的余地很小，但提升CPU 处理速度和磁盘I/O 速度是最直接的提高数据库性能的方式。实际上，用户对OLAP 系统性能的期望远远没有对OLTP 性能的期望那么高。
对于OLAP 系统，SQL 的优化显得非常重要，如果一张表中只有几千数据，无论执行全表扫描或是使用索引，对用户来说差异都很小，几乎感觉不出来，可是当数据量提升到几亿或者几十亿或者更多的时候，全表扫描，索引可能导致极大的性能差异，因此SQL语句的优化显得重要起来。
分区技术在OLAP 数据库中很重要，这种重要主要是体现在数据管理上，比如数据加载，能够经过分区交换的方式实现，备份能够经过备份分区表空间，删除数据能够经过分区进行删除。
3.2. 数据库的规模
对于数据库的规模，仅从数据量来衡量其规模的大小。因为数据量的规模是反映数据库规模的主要指标。具体如下：
1）数据库业务数据量小于100GB 属小规模数据库
2）数据库业务数据量1TB 以内属中大规模数据库
3）数据库业务数据量大于1TB 属大规模数据库
3.3. 数据库版本建议
Oracle数据库产品推出新的主要版本后，要经历一个版本不稳定期。在此期间新版的数据库产品存在较多的bug。在安装和运行过程中，会存在数据库安装困难和运行不稳定现象。因此在选择版本时，要选择成熟稳定的版本。
4. 数据库运行环境规划
根据用户需求在业务系统前期的实施规划上，需要做好详细的规划设计，包括主机、网络和存储环境规划等，要将整个软硬件融为一体，充分考虑系统的安全性，可靠性，高可用性等因素，只有一个规划好的系统才能充分发挥其优于单节点的优势，同时也为后期的运维管理提供方便。
在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些因素等。理想情况下，应考虑下列要素：交易的复杂性、交易率、数据读/写比例、并发连接数目、并发交易数目、数据库最大表的大小、性能度量的目标。
4.1. 主机规划
主机规划主要需考虑服务器在不同的用户数量下，系统的响应时间和吞吐量，并得出当前服务器的各种资源的利用情况。在规划系统配置时要预留做系统管理时所消耗的资源，如在做备份、恢复、问题诊断、性能分析、系统维护时都会对系统资源带来额外的消耗，对重要资源要考虑为将来留下升级和可扩展的余地。
在进行服务器配置规划时，要注意以下几点：
1）CPU：要考虑业务高峰时处理器的能力，并适当保留一些缓冲，确保在业务增长时，系统有扩展的余地。
2）内存：要为运行在此服务器的所有应用软件考虑内存，所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。
3）磁盘：评估业务的实际用户的数据量，以此推算出磁盘的最小个数，不要忘记选择备份设备（如磁带机）。
4）IO槽：尽量保留更多的IO槽，防止将来插更多的PCI卡。
5）网络：选择合适的网卡，保证网络不是系统的瓶颈。
数据库服务器优先考虑使用小型机和UNIX操作系统，可是当前用户大都选择PC服务器和Linux操作系统，推荐的数据库服务器配置如下：
处理器：核心不低于24，主频不低于2.6GHz，三级缓存不低于30MB。
内存：容量不低于256G，DDR4频率不低于2133MHz，支持ECC纠错、内存镜像、内存热备等功能。
存储：双盘，单盘容量不低于300GB，支持RAID。
网卡和HBA卡：2个千兆网口，2个万兆网口，2个FC接口。网卡进行绑定。
操作系统：Linux。
4.2. 网络规划
网络规划的基本原则就是将业务生产网络、存储网络和管理网络分开，推荐在生产网络使用万兆网，存储使用SAN存储网络，管理网可使用千兆网。
对于数据库单机模式、HA双机模式以及主备模式的生产环境，主要基本符合网络规划的基本原则即可。对于集群模式，因Oracle有其特殊要求，因此在结合网络规划基本原则的基础上，可进行细化实施。
在Oracle 11gR2中，安装RAC发生了显著变化。在10g以及11gR1的时代，安装RAC的步骤是先安装CRS，再安装DB，而到了11gR2的时代，crs与asm被集成在一起，合称为GRID，必须先安装GRID后，才能继续安装DB。本方案以主流的ORACLE 11g R2 RAC的网络规划为例进行详细说明。
假设服务器上有4块网卡：eth0,eth1,eth2，eth3.能够将eth0 和 eth2绑定成bond0。作为RAC的public-ip，提供外部通信。然后将eth1和eth3 绑定成bond1，作为RAC的private-ip，提供内部心跳通信。服务器上的HBA卡经过光纤交换机与后端存储通信。
4.2.1.1. 公有IP和虚拟IP
Oracle RAC中每个节点都有一个虚拟IP，简称VIP，与公网PUBLIC IP在同一个网段。VIP附属在public网口接口。
VIP和PUBLIC IP最主要的不同之处在于：VIP是浮动的，而PUBLIC IP是固定的。在所有节点都正常运行时，每个节点的VIP会被分配到public NIC上；在linux下ifconfig查看，public网卡上是2个IP地址；如果一个节点宕机，这个节点的VIP会被转移到还在运行的节点上。也就是幸存的节点的public NIC这个网卡上，会有3个IP地址。
PUBLIC IP地址是一个双网卡绑定的公有地址，用户经过交换机来进行访问。
4.2.1.2. RAC中的私有IP
RAC中的 Private私有IP用于心跳同步，这个对于用户层面，能够直接忽略。简单理解，这个IP用来保证数据库节点同步数据用的，属于RAC内部之间通信。priv 与public不应同属一个接口。
Metalink上的RAC文档是推荐使用交换机作为内部网卡的连接,而不使用交叉线,原因是避免因为对连节点关闭或重启而导致网卡检查到链接故障状态而删除绑定的协议。导致高速缓存合并网络将会变为不可用。
4.2.1.3. SCAN IP
在11gR2中，SCAN IP是作为一个新增IP出现的, SCAN IP其实是Oracle在客户端与数据库之间，新加的一个连接层，当有客户端访问时，连接到 SCAN IP LISTENER，而SCAN IP LISTENER接收到连接请求时，会根据 LBA 算法将该客户端的连接请求，转发给对应的instance上的VIP LISTENER，从而完成了整个客户端与服务器的连接过程。简化如下：
client -> scan listener -> local listener -> local instance
也能够把scan理解为一个虚拟主机名，它对应的是整个RAC集群。客户端主机只需经过这个scan name即可访问数据库集群的任意节点。当然访问的节点是随机的，Oracle强烈建议经过DNS Server的round robin模式配置解析SCAN，实现负载均衡（即轮换连接SCAN对应的IP地址）。
4.3. 存储规划
数据库一般使用磁盘阵列（RAID）保存数据，使用磁盘阵列有两个优点：首先，盘阵能够提供一个具有容错能力的I/O系统，当系统中某个磁盘驱动器出现故障时，可避免丢失数据，因此具有容错能力；其次，允许多个但磁盘驱动器配置成为一个大的虚拟磁盘驱动器，从而方便管理，提高性能。
盘阵RAID方式分为RAID0，RAID1，RAID10，RAID2，RAID3，RAID4，RAID5等，其逻辑和物理组合方式各有差异。
基于Oracle数据库配置RAID系统，有以下几种解决方案：
1、最佳解决方案
对容错能力最好的解决方案就是最大限度地使用RAID1和RAID10，规划部署时遵循以下原则：
1）对操作系统和Oracle程序使用RAID1；
2）对数据库重做日志文件使用RAID1，能够优化性能；
3）对归档日志文件使用RAID01，既能保护数据，又不会影响性能；
4）对数据文件使用RAID10，并使用多个磁盘驱动器以保证不超过单块盘的负载。
2、较好的解决方案
对于容错能力，较好的解决方案是混合使用RAID10和RAID5，遵循以下原则：
1）对操作系统和Oracle程序使用RAID1；
2）对数据库重做日志文件共享一个RAID1或RAID10；
3）对归档日志文件可使用RAID10或RAID5，这两种方式均可保护数据且不影响性能；
4）对数据文件使用RAID10，并使用过个磁盘驱动器以保证不超过单个磁盘负载。混合使用RAID10和RAID5可实现很好的性能，容错能力也很高。
3、经济型解决方案
对容错能力，此方案使用RAID1和RAID5，遵循以下原则：
1）对操作系统和Oracle程序使用RAID1;
2）对重做日志文件使用RAID1;
3）对归档日志文件使用RAID10或RAID5;
4）对数据文件使用RAID5或RAID0，其中RAID0用来提供必要的性能，并使用过个磁盘驱动器以保证不超过单盘的负载。
此方案提供的系统性能比前两个方案要低，其价格是优势。
在进行存储规划时，需要特别注意：
1）若系统没有使用容错功能，那么只要有一块磁盘驱动器发生故障，就必须恢复整个数据库；
2）容错磁盘不能替代数据库备份策略；
3）系统可能会发生变化，要紧跟用户的需求；
4）以上的解决方案都要考虑磁盘驱动器的数量，应具备足够数量的磁盘驱动器以防系统瓶颈的产生；
5）对于硬件的保护不但仅是磁盘驱动器，还包括冗余电源，磁盘控制卡和风扇等等，如果存储系统没有冗余机制，则这其中任何一项故障都会导致业务系统停机和丢失数据等损失。
5. 数据库安装部署规划
5.1. 软件安装路径
建立单独的文件系统来安装数据库软件，且文件系统的mount点不要直接建立在根目录下。
安装路径： /home/db/oracle
各种环境变量设置：
ORACLE_BASE=/home/db/oracle
CRS_HOME=/home/db/oracle/crs/{数据库release版本}
ORACLE_HOME=/home/db/oracle/product/{数据库release版本}
普通使用模式的Oracle数据库的服务名和实例名（SID）是相同的；RAC模式下的Oracle数据库的服务名与实例名不同。
数据库服务名的命名格式为：XXXYYdb{m}
数据库的SID的命名格式为：XXXYYdb{m}{n}
说明：
1、其中XXX表示长度为3个字符的应用项目缩写，具体的见相关设计文档。
2、YY：代表数据库用途，pd代表生产库，hi代表历史库，rp代表报表库，cf代表配置库；
3、m表示数据库序号，从0-9，根据项目的数据库数量进行编号。
4、n表示RAC节点实例序号1,2,3……。用以区分多节点的RAC数据库的不同实例。对于普通模式的数据库，该位不指定。
5.2. 表空间设计
5.2.1. 业务数据量估算
估算所有业务对象下的所有表的尺寸。
数据量估算的前提：
1）数据库的物理表结构已经确定，而且设计已凝固。
2）用户方提供较为准确的估算依据，例如业务变动的频率、数据需要保存的周期等。
该表是一个示例，可根据业务的不同有所变化。
序号
表名
增长量
（/小时/天/周）
增长量
（/月/半年）
年数据量

数据库生命周期内的总计
1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

合计

新上线或扩容时，对所申请的存储不得全部一次性挂上，应该预留出30％左右的空间用于追加，以防止出现业务发展和预期不一致时剩余空间多寡不均，调整困难。
操作系统上应该预先做好几个合适大小的逻辑卷备用，包括用于system/sysaux等表空间的小尺寸的逻辑卷和用于数据表空间、索引表空间的大尺寸逻辑卷，这些逻辑卷要求在HA两边主机都可见，不必单纯因为数据库增加数据文件而需要重新同步HA。
5.2.2. 表空间使用规则
当前多数数据库系统采用数据“大集中”原则，对数据库的性能要求较高。这就要求对数据库进行必要的优化配置。在表空间的配置上，应遵循以下原则：
1、最小化磁盘I/O。
2、在不同的物理磁盘设备上，分配数据。
3、尽可能使用本地管理表空间。
多数系统采用RAID1+0 或 RAID0+1，该技术很好的解决了最小化磁盘I/O。基本不必考虑在不同的物理磁盘设备上，分配数据的原则。
5.2.2.1. 表空间的类型
按照表空间所包含的数据文件类型，Oracle表空间类型有三类：
1、数据表空间（permanence tablespace）：用来保存永久数据，包含永久数据文件。强烈建议在永久表空间内创立永久数据文件，不要创立临时数据文件。
2、临时表空间（temporary tablespace）：用来保存临时数据，多用于数据的磁盘排序。强烈建议在临时表空间内创立临时数据文件，不要创立永久数据文件。
3、回滚表空间（rollback/undo tablespace）：仅用来保存回退信息。不能在该表空间创立其它类型的段（如表、索引等）。
为了更好的管理表空间，同时提高Oracle数据库系统性能，在上述三类基础上，针对数据的业务功能，进一步对其加以分类。因此Oracle数据库的表空间划分为基本表空间和应用表空间。如下表：
1）基本表空间：是指Oracle数据库系统为其自身运行而使用的表空间。
表空间类别
表空间名称
存储内容
说明
数据表空间
SYSTEM表空间
存储oracle数据库系统数据字典对象
Oracle数据库系统自身生成的和使用—基本表空间
数据表空间
SYSAUX
存储SYSAUX数据
Oracle数据库系统自身生成的和使用—基本表空间
回滚表空间
UNDO表空间
容纳回滚数据
如果UNDO表空间是自动管理，则Oracle数据库系统自身生成的。
生产数据库不得有如TOOLS、XDB、EXAMPLE等oracle默认安装表空间。
2）应用表空间：是指业务应用数据保存在此类表空间中。它由DBA或相关的数据库规划设计人员创立和规划。
表空间类别
表空间名称
存储内容
说明
临时表空间
TEMP表空间
容纳排序数据
由DBA设定—应用表空间
数据表空间
TABLES表空间
存储小数据表公用业务数据
由DBA设定—应用表空间
数据表空间
TABLES PARTITION表空间
存储巨型表数据
由DBA设定—应用表空间
数据表空间
INDEXS表空间
存储小数据表的索引
由DBA设定—应用表空间
数据表空间
INDEXS PARTITION表空间
存储巨型数据表的索引
由DBA设定—应用表空间
数据表空间
LOB表空间
存储LOB的数据
由DBA设定—应用表空间
5.2.2.2. 表空间和数据文件的命名规则
数据文件都使用裸设备方式，使用固定大小，不得设置为自动扩展。
1、基本表空间及其文件命名规范
表空间名称
裸设备连接文件名
普通文件名
说明
SYSTEM
rsystem_nn_size
systemnn.dbf
总空间大小设置为2G
SYSAUX
rsysaux_nn_size
sysauxnn.dbf
Oracle10g中必须有的表空间。总空间大小设置为4G，如果空间非常紧张，可设置为2G
UNDOTBS1
rundotbs_nn_size
undotbsnn.dbf
总空间不小于8G
TEMP
rtemp_nn_size
tempnn.dbf
总空间不小于4G
说明：
l 裸设备连接文件名
nn为从01开始计数的序号，表示文件的个数。如：01，02，03，04……
size表示了设备的大小，由数字部分和单位部分组成：XU。其中，X是一个正整数，取值范围从1～1023，U是单位标识位，是1位的字符，取值范围为k、m、g、t，分别表示了KByte、MByte、GByte、TByte，size的值应该根据设备的数据大小指定。
l 普通文件名（即创立在文件系统上的文件）
nn为从01开始计数的两位整数序号。如：01，02，03，04……
各表空间根据需求在建库时确定。
l 数据文件路径：/home/db/or