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

1、Oracle数据库规划设计和运行维护方案Oracle数据库规划设计和运行维护方案（V1.0）1. 前言 71.1. 编写目的 71.2. 方案说明 71.3. 预期读者 82. 数据库部署模式 82.1. 单机模式 82.2. 双机热备模式（HA模式） 82.3. 集群模式（RAC） 92.4. 主从模式（DataGuard） 102.5. 混合模式（DataGrard+RAC） 112.6. 数据库运行模式选择 113. 系统特点和数据库类型 123.1. 业务系统的特点 12 OLTP特点 12 OLAP特点 133.2. 数据库的规模 133.3. 数据库版本建议 144. 数据库运行环

2、境规划 144.1. 主机规划 144.2. 网络规划 154.3. 存储规划 175. 数据库安装部署规划 185.1. 软件安装路径 185.2. 表空间设计 19 业务数据量估算 19 表空间使用规则 20 表空间的概念和分配原则 24 表空间的参数配置 25 Undo/temp表空间的估算 29 表的参数设置 29 索引的使用原则 305.3. 文件设计 31 RAC配置文件 31 参数文件 31 控制文件 33 重做日志文件 346. 数据库应用规划 356.1. 数据库用户设计 35 用户权限规划 35 用户安全实现 37 用户类型及角色命名规范 396.2. 数据库分区 41 数

3、据库分区介绍 41 逻辑分割 42 物理分割 42 数据分区的优点 42 数据分区的不足 43 Oracle分区技术 43 分区使用建议 44 分区索引 446.3. 数据库实例配置 456.4. 数据库参数设置 46 必须修改的初始化参数 46 建议修改的初始化参数 51 不可修改的初始化参数 53 建议不可修改的初始化参数 54 与并行有关的参数 576.5. 数据库连接服务 58 专用服务器连接 58 共享服务器连接 59 连接服务建议 596.6. 数据库安全建议 596.7. 数据库备份和恢复 60 RMAN备份 60 EXP/IMP备份 61 存储级备份 61 数据库恢复 626.

4、8. 数据库网络配置 63 监听器的使用配置原则 63 TNSNAMES的使用配置原则 63 RAC环境下TNSNAMES的配置 637. 业务系统开发建议 657.1. 数据库模型设计规范 65 命名规则 65 数据库对象 667.2. PLSQL开发规则 69 总体开发原则 69 程序编写规范 707.3. SQL语句编写规则 97 查询语句的使用原则 97 DML语句的调整原则 1088. 数据库体系结构 1128.1. 整体结构 1128.2. 内存结构 112 系统全局区（SGA） 113 程序全局区（PGA） 116 后台进程 1168.3. 存储结构 119 物理结构 119 逻

5、辑结构 1219. 数据库基本管理 1239.1. 参数文件管理 1239.2. 表空间管理 124 用户表空间管理 124 临时表空间管理 127 回滚段表空间管理 1319.3. 重做日志文件管理 133 增加重做日志文件组 133 添加重做日志文件组成员 133 改变重做日志文件组成员 134 删除重做日志文件组成员 134 删除重做日志文件组 134 重做日志切换 135 重做日志清理 135 重做日志切换次数查询 1359.4. 归档模式设置 137 单实例数据库设置归档模式 137 RAC数据库设置归档模式 137 归档路径设置 1389.5. 控制文件重建 1399.6. 内存参

6、数管理 141 Oracle内存管理发展阶段 141 自动内存管理AMM 141 自动共享内存管理ASMM 141 自动PGA管理 1429.7. 其它管理内容 142 查看数据库版本 142 数据库字符集 143 创建密码文件 143 关闭数据库审计功能 143 账号管理 144 Profile管理 14410. 数据库集群（RAC）管理 14410.1. RAC状态检查 144 检查守护进程 144 检查资源状态 14510.2. RAC启动与关闭 14510.3. 管理OCR 146 OCR盘状态查看 146 OCR备份与恢复 146 查看OCR内容 147 指定OCR盘 147 增加O

7、CR盘 147 删除OCR盘 14810.4. 管理VOTING DISK 148 检查Voting Disl盘 148 VOTING DISK备份与恢复 148 添加VOTING DISK盘 149 删除VOTING DISK盘 14910.5. CSS管理 14910.6. SRVCTL管理工具 149 管理实例 150 管理监听程序 150 管理ASM 151 管理service 15110.7. 修改RAC的IP及VIP 152 修改外网IP和心跳IP 152 修改VIP 152 查看与删除IP 15310.8. 管理ASM 154 管理DiskGroup 154 ASM兼容性管理 1

8、56 ASM中添加disk的方法 158 ASMCMD管理命令介绍 159 ASM常用视图 16211. 数据库备份 16411.1. 备份概念说明 164 脱机备份 164 联机备份 165 RMAN备份 16611.2. 备份策略规划 16611.3. RMAN备份和恢复案例 167 归档模式下的完全恢复 167 归档模式下的不完全恢复 17012. 数据库运维管理 17212.1. 运维职责 17212.2. 运维要求 17212.3. 技能要求 17212.4. 运维内容 173 检查数据库运行情况 173 检查操作系统和数据库日志文件 175 检查Oracle对象状态 176 检查数

9、据库相关资源的使用 179 检查数据库备份 183 检查数据库的性能 183 数据库安全性检查 189前言编写目的随着以使用Oracle数据库的应用系统不断增加，为了加强应用系统在规划、开发、实施、维护等环节工作的规范化，特编写本文档，力求对实际的设计、实施工作起到规范和指导作用。本方案以设计者的角度进行组织编写，其主要思路是：作为设计人员首先要了解数据库系统的运行模式，如何选择运行模式，其次要考虑系统的规划设计因素，有针对性的做好数据库的设计，提高数据库的性能，并对系统开发也提出相关要求。方案说明本方案分为两大部分，其中第一部分是第二到七章，主要介绍Oracle数据库的运行方式和规划设计以及

10、与开发相关内容；第二部分是第八到十二章，主要介绍数据库的日常运行维护相关的内容。第一部分偏重于规划和开发，第二部分偏重于实际管理及命令。其中：第二章介绍了Oracle数据库的部署运行方式；第三章介绍了业务系统特点和数据库的类型规模以及部署前的建议；第四章介绍了数据库运行的物理环境的配置规划；第五章介绍了Oracle数据库的安装部署规划以及命名原则；第六章介绍了数据库的应用规划；第七章介绍了系统开发的建议；第八章介绍数据库的体系架构；第九章介绍数据库的基本管理方法；第十章介绍了数据库集群的管理；第十一章介绍了数据库的备份和恢复；第十二章介绍了数据库的日常运行维护管理。本方案编写过程中注重实际的可

11、操作性，所提出的建议尽量覆盖系统生命周期中的各个关键点。其中所涉及的参数和指标对系统的建设和运营起指导作用，但是在实际工作中，每个系统都有各自的特点，所以建议在初期对系统进行初始配置后，应根据系统的实际运行状态进行相应调整。预期读者项目基础设施可行性研究、设计和实施人员，项目组系统设计开发人员，相关运行维护技术人员。数据库部署模式单机模式数据库服务器采用单服务器模式，满足对可用性和性能要求不高的应用，具备以下特点:1、硬件成本低。单节点，硬件投入较低，满足非重要系统的需求。2、安装配置简单。由于是单节点、单实例，所以安装配置比较简单。3、管理维护成本低。单实例，维护成本低。4、对应用设计的要求

12、较低。由于是单实例，不存在RAC系统应用设计时需要注意的事项，所以应用设计的要求较低。5、可用性不高。由于是单服务器、单实例，所以服务器和实例的故障都会导致数据库不可用。6、扩展性差。无法进行横向扩展，只能进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能进行增加硬件配置等纵向扩展，且扩展性有局限。7、根据该模式的特点有如下要求：1) 硬件配置方面预留扩展量。由于该模式无法进行横向扩展，所以在选择硬件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。2) 充分考虑该模式是否满足应用未来一段时间的需求。需要考虑应用在未来一段时间

13、是否会发生变化，该模式是否满足应用变化的需求。双机热备模式（HA模式）数据库服务器采用双机热备模式，可以满足对可用性有一定要求的应用，具备以下特点：1、需要冗余的服务器设备。该模式需要有冗余的服务器硬件，以满足一备一或者一备多的需求。硬件成本较高。2、需要HA软件的支持。该模式需要配合HA软件才可以实现。3、安装配置相对简单。该模式比单节点、单实例的模式配置复杂一些，需要更多的配置步骤，但相比较RAC、DATAGUARD等模式要简单。4、管理维护成本低。单实例，对维护人员的要求较低，维护成本低。5、对应用设计的要求较低。由于是单实例，不存在RAC系统应用设计时需要注意的事项，所以应用设计的要求

14、较低。6、具备一定的高可用性。由于是多服务器、单实例，所以服务器和实例有故障时会发生实例在不同服务器上的切换，导致数据库的暂时不可用。无法满足对可用性有严格要求的应用类型。7、扩展性差。无法进行横向扩展，只能进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能进行增加硬件配置等纵向扩展，且扩展性有局限。根据该模式的特点有如下要求：1) 硬件配置方面预留扩展量。由于该模式无法进行横向扩展，所以在选择硬件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。2) 充分考虑该模式是否满足应用未来一段时间的需求。需要考虑应用在未来一段时间是

15、否会发生变化，该模式是否满足应用变化的需求。集群模式（RAC）数据库服务器采用RAC模式，满足对高可用性要求高的应用类型，具备以下特点:1、需要多个硬件服务器。根据节点的个数，相应的需要多个硬件服务器。硬件成本较高。2、某些数据库版本需要HA软件的支持。该模式下，某些数据库版本需要配合HA软件才可以实现。3、安装配置复杂。该模式比起单实例模式，安装配置相对复杂，安装配置周期长。4、管理维护成本高。该模式的管理维护，对管理维护人员的要求较高，管理维护成本较高。5、对应用设计的要求较高。需要充分考虑业务的逻辑性，以避免在多节点之间的信息交换和全局锁的产生。6、具备较高的高可用性。由于是多服务器、多

16、实例，单服务器和实例有故障不会影响数据库的可用性。可以满足对可用性有严格要求的应用类型。7、扩展性好。既可以进行横向扩展，也可以进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库可以通过增加节点的方式进行横向扩展，也可以通过增加硬件配置等纵向扩展，具备良好的扩展性。根据该模式的特点有如下要求：1)硬件配置方面预留扩展量。预留一定的硬件扩展量，可以更灵活的进行扩展。2)在应用设计时，充分考虑业务逻辑，减少多节点间的信息交换量，更好的发挥RAC的优点。主从模式（DataGuard）数据库服务器采用DataGuard主从模式，可以满足对可用性有特殊需求的应用，具备以下特点：1、需要冗余的服务器

17、设备。该模式需要有冗余的服务器硬件。硬件成本较高。2、需要冗余的存储设备。主机和备机都需要同样的存储空间，成本较高。3、安装配置比较复杂。该模式比单节点、单实例的模式配置复杂一些，需要更多的配置步骤。4、管理维护成本高。该模式对维护人员的要求较高，维护成本高。5、具备一定的容灾特性。当主机整个数据库系统不可用并短期内无法恢复时，可以把数据库系统切换到备机上，具备容灾的功能。6、备机可以用作只读查询。备机可以切换到只读状态供报表之类的查询操作，减轻主机的压力。根据该模式的特点有如下要求：1）主机与备机在物理上要分开。为了实现容灾的特性，需要在物理上分割主机和备机。2）进行合理的设计，充分实现DA

18、TAGUARD的功能。混合模式（DataGrard+RAC）数据库服务器采用DataGuard+RAC模式，可以满足对可用性和容灾都有特定需求的应用，具备以下特点：1、需要冗余的服务器设备。该模式需要有冗余的服务器硬件。硬件成本较高。2、需要冗余的存储设备。主机和备机都需要同样的存储空间，成本较高。3、安装配置比较复杂。该模式既需要配置RAC又需要配置DATAGUARD，配置过程比较复杂，配置周期长。4、管理维护成本高。该模式对维护人员的要求较高，维护成本高。5、具备很高的可用性和容灾性。该模式既满足高可用性也满足容灾的需求。6、备机可以用作只读查询。备机可以切换到只读状态供报表之类的查询操作

19、，减轻主机的压力。根据该模式的特点有如下要求：1）主机与备机在物理上要分开。为了实现容灾的特性，需要在物理上分割主机和备机。2）进行合理的设计，充分实现DataGuard的功能。数据库运行模式选择在设计数据库时必须考虑系统的可用性、业务连续性，针对系统所能容忍的最大业务中断时间（RTO）和最大数据丢失数量（RPO）需求，采用不同的数据库部署模式：1、系统不能中断且不允许数据丢失的业务，建议数据库采用集群或混合模式，数据库单台设备故障时对业务没有影响，并考虑灾备系统的设计。2、对于允许以分钟级别中断，数据不能丢失的系统，建议数据库采用双机热备或主从的模式，设备故障时通过HA技术切换到备用设备，保

20、证系统的可用性，对重要的系统要考虑灾备的设计。3、对于允许以天为级别中断的业务系统，建议可采用双机热备模式，或单机。4、对非关键系统、开发环境、测试环境，建议采用PC服务器、冷备或单机的模式。系统特点和数据库类型业务系统的特点业务系统处理数据的特点决定了设计人员规划和创建什么样的数据库，通常来说，业务分为两类：在线事务处理系统（OLTP）和在线分析系统（OLAP）或者DSS（决策支持系统）。这两类系统在数据库的设计上是不同的，比如OLTP 系统强调数据库的内存效率，强调各种内存指标的命中率，强调绑定变量，强调并发操作：而OLAP 系统则强调数据分析，强调SQL 执行时长，强调磁盘I/O，强调分

21、区等。OLTP特点通常OLTP（在线事务处理系统）的用户并发数很多，但只对数据库做很小的操作，数据库侧重于对用户操作的快速响应，这是对数据库最重要的性能要求。对于一个OLTP 系统来说，数据库内存设计非常重要，如果数据都可以在内存中处理，那么数据库的性能会提高很多。内存的设计通常是通过调整Oracle 和内存相关的初始化参数来实现的，比较重要的几个是内存相关的参数，包括SGA 的大小（Data Buffer，Shared Pool），PGA 大小（排序区，Hash 区等）等，这些参数对一个OLTP系统是非常重要的。OLTP 系统是一个数据块变化非常频繁，SQL 语句提交非常频繁的一个系统。对于

22、数据块来说，应尽可能让数据块保存在内存当中，对于SQL 来说，尽可能使用变量绑定技术来达到SQL的重用，减少物理I/O 和重复的SQL解析，能极大的改善系统的性能。此外，没有绑定变量的SQL会对OLTP 数据库造成极大的性能影响，还有一些因素也会导致数据库的性能下降，比如热块（hot block）的问题，当一个块被多个用户同时读取的时候，Oracle 为了维护数据的一致性，需要使用Latch 来串行化用户的操作，当一个用户获得了这个Latch，其他的用户就只能被迫的等待，获取这个数据块的用户越多，等待就越明显，就造成了这种热块问题。这种热块可能是数据块，也可能是回滚段块。对于数据块来讲，通常是

23、数据块上的数据分布不均匀导致，如果是索引的数据块，可以考虑创建反向索引来达到重新分布数据的目的，对于回滚段数据块，可以适当多增加几个回滚段来避免这种争用。OLAP特点OLAP 数据库在内存上可优化的余地很小，但提升CPU 处理速度和磁盘I/O 速度是最直接的提高数据库性能的方式。实际上，用户对OLAP 系统性能的期望远远没有对OLTP 性能的期望那么高。对于OLAP 系统，SQL 的优化显得非常重要，如果一张表中只有几千数据，无论执行全表扫描或是使用索引，对用户来说差异都很小，几乎感觉不出来，但是当数据量提升到几亿或者几十亿或者更多的时候，全表扫描，索引可能导致极大的性能差异，因此SQL语句的

24、优化显得重要起来。分区技术在OLAP 数据库中很重要，这种重要主要是体现在数据管理上，比如数据加载，可以通过分区交换的方式实现，备份可以通过备份分区表空间，删除数据可以通过分区进行删除。数据库的规模对于数据库的规模，仅从数据量来衡量其规模的大小。因为数据量的规模是反映数据库规模的主要指标。具体如下：1）数据库业务数据量小于100GB 属小规模数据库2）数据库业务数据量1TB 以内属中大规模数据库3）数据库业务数据量大于1TB 属大规模数据库数据库版本建议Oracle数据库产品推出新的主要版本后，要经历一个版本不稳定期。在此期间新版的数据库产品存在较多的bug。在安装和运行过程中，会存在数据库安

25、装困难和运行不稳定现象。因此在选择版本时，要选择成熟稳定的版本。数据库运行环境规划根据用户需求在业务系统前期的实施规划上，需要做好详细的规划设计，包括主机、网络和存储环境规划等，要将整个软硬件融为一体，充分考虑系统的安全性，可靠性，高可用性等因素，只有一个规划好的系统才能充分发挥其优于单节点的优势，同时也为后期的运维管理提供方便。 在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些因素等。理想情况下，应考虑下列要素：交易的复杂性、交易率、数据读/写比例、并发连接数目、并发交易数目、数据库最大表的大小、性能度量的目标。主机规划主机规划主要需考虑服务器在不同的用户数量下，系统

26、的响应时间和吞吐量，并得出当前服务器的各种资源的利用情况。在规划系统配置时要预留做系统管理时所消耗的资源，如在做备份、恢复、问题诊断、性能分析、系统维护时都会对系统资源带来额外的消耗，对重要资源要考虑为将来留下升级和可扩展的余地。在进行服务器配置规划时，要注意以下几点：1）CPU：要考虑业务高峰时处理器的能力，并适当保留一些缓冲，确保在业务增长时，系统有扩展的余地。2）内存：要为运行在此服务器的所有应用软件考虑内存，所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。 3）磁盘：评估业务的实际用户的数据量，以此推算出磁盘的最小个数，不要忘记选择备份设备（如磁带机

27、）。4）IO槽：尽量保留更多的IO槽，防止将来插更多的PCI卡。 5）网络：选择合适的网卡，保证网络不是系统的瓶颈。数据库服务器优先考虑使用小型机和UNIX操作系统，但是当前用户大都选择PC服务器和Linux操作系统，推荐的数据库服务器配置如下：处理器：核心不低于24，主频不低于2.6GHz，三级缓存不低于30MB。内存：容量不低于256G，DDR4频率不低于2133MHz，支持ECC纠错、内存镜像、内存热备等功能。存储：双盘，单盘容量不低于300GB，支持RAID。网卡和HBA卡：2个千兆网口，2个万兆网口，2个FC接口。网卡进行绑定。操作系统：Linux。网络规划网络规划的基本原则就是将业

28、务生产网络、存储网络和管理网络分开，推荐在生产网络使用万兆网，存储使用SAN存储网络，管理网可使用千兆网。对于数据库单机模式、HA双机模式以及主备模式的生产环境，主要基本符合网络规划的基本原则即可。对于集群模式，因Oracle有其特殊要求，所以在结合网络规划基本原则的基础上，可进行细化实施。在Oracle 11gR2中，安装RAC发生了显着变化。在10g以及11gR1的时代，安装RAC的步骤是先安装CRS，再安装DB，而到了11gR2的时代，crs与asm被集成在一起，合称为GRID，必须先安装GRID后，才能继续安装DB。本方案以主流的ORACLE 11g R2 RAC的网络规划为例进行详细

29、说明。假设服务器上有4块网卡：eth0,eth1,eth2，eth3.可以将eth0 和 eth2绑定成bond0。作为RAC的public-ip，提供外部通信。然后将eth1和eth3 绑定成bond1，作为RAC的private-ip，提供内部心跳通信。服务器上的HBA卡通过光纤交换机与后端存储通信。公有IP和虚拟IPOracle RAC中每个节点都有一个虚拟IP，简称VIP，与公网PUBLIC IP在同一个网段。VIP附属在public网口接口。VIP和PUBLIC IP最主要的不同之处在于：VIP是浮动的，而PUBLIC IP是固定的。在所有节点都正常运行时，每个节点的VIP会被分配到

30、public NIC上；在linux下ifconfig查看，public网卡上是2个IP地址；如果一个节点宕机，这个节点的VIP会被转移到还在运行的节点上。也就是幸存的节点的public NIC这个网卡上，会有3个IP地址。PUBLIC IP地址是一个双网卡绑定的公有地址，用户通过交换机来进行访问。RAC中的私有IPRAC中的 Private私有IP用于心跳同步，这个对于用户层面，可以直接忽略。简单理解，这个IP用来保证数据库节点同步数据用的，属于RAC内部之间通信。priv 与public不应同属一个接口。Metalink上的RAC文档是推荐使用交换机作为内部网卡的连接,而不使用交叉线,原因

31、是避免因为对连节点关闭或重启而导致网卡检查到链接故障状态而删除绑定的协议。导致高速缓存合并网络将会变为不可用。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即可访问数据库集群的任意节点。当然