Oracle数据库规划设计和运行维护方案.docx
《Oracle数据库规划设计和运行维护方案.docx》由会员分享，可在线阅读，更多相关《Oracle数据库规划设计和运行维护方案.docx（198页珍藏版）》请在冰豆网上搜索。
Oracle数据库规划设计和运行维护方案
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
OLTP特点12
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
业务数据量估算19
表空间使用规则20
表空间的概念和分配原则24
表空间的参数配置25
Undo/temp表空间的估算29
表的参数设置29
索引的使用原则30
5.3.文件设计31
RAC配置文件31
参数文件31
控制文件33
重做日志文件34
6.数据库应用规划35
6.1.数据库用户设计35
用户权限规划35
用户安全实现37
用户类型及角色命名规范39
6.2.数据库分区41
数据库分区介绍41
逻辑分割42
物理分割42
数据分区的优点42
数据分区的不足43
Oracle分区技术43
分区使用建议44
分区索引44
6.3.数据库实例配置45
6.4.数据库参数设置46
必须修改的初始化参数46
建议修改的初始化参数51
不可修改的初始化参数53
建议不可修改的初始化参数54
与并行有关的参数57
6.5.数据库连接服务58
专用服务器连接58
共享服务器连接59
连接服务建议59
6.6.数据库安全建议59
6.7.数据库备份和恢复60
RMAN备份60
EXP/IMP备份61
存储级备份61
数据库恢复62
6.8.数据库网络配置63
监听器的使用配置原则63
TNSNAMES的使用配置原则63
RAC环境下TNSNAMES的配置63
7.业务系统开发建议65
7.1.数据库模型设计规范65
命名规则65
数据库对象66
7.2.PLSQL开发规则69
总体开发原则69
程序编写规范70
7.3.SQL语句编写规则97
查询语句的使用原则97
DML语句的调整原则108
8.数据库体系结构112
8.1.整体结构112
8.2.内存结构112
系统全局区（SGA）113
程序全局区（PGA）116
后台进程116
8.3.存储结构119
物理结构119
逻辑结构121
9.数据库基本管理123
9.1.参数文件管理123
9.2.表空间管理124
用户表空间管理124
临时表空间管理127
回滚段表空间管理131
9.3.重做日志文件管理133
增加重做日志文件组133
添加重做日志文件组成员133
改变重做日志文件组成员134
删除重做日志文件组成员134
删除重做日志文件组134
重做日志切换135
重做日志清理135
重做日志切换次数查询135
9.4.归档模式设置137
单实例数据库设置归档模式137
RAC数据库设置归档模式137
归档路径设置138
9.5.控制文件重建139
9.6.内存参数管理141
Oracle内存管理发展阶段141
自动内存管理AMM141
自动共享内存管理ASMM141
自动PGA管理142
9.7.其它管理内容142
查看数据库版本142
数据库字符集143
创建密码文件143
关闭数据库审计功能143
账号管理144
Profile管理144
10.数据库集群（RAC）管理144
10.1.RAC状态检查144
检查守护进程144
检查资源状态145
10.2.RAC启动与关闭145
10.3.管理OCR146
OCR盘状态查看146
OCR备份与恢复146
查看OCR内容147
指定OCR盘147
增加OCR盘147
删除OCR盘148
10.4.管理VOTINGDISK148
检查VotingDisl盘148
VOTINGDISK备份与恢复148
添加VOTINGDISK盘149
删除VOTINGDISK盘149
10.5.CSS管理149
10.6.SRVCTL管理工具149
管理实例150
管理监听程序150
管理ASM151
管理service151
10.7.修改RAC的IP及VIP152
修改外网IP和心跳IP152
修改VIP152
查看与删除IP153
10.8.管理ASM154
管理DiskGroup154
ASM兼容性管理156
ASM中添加disk的方法158
ASMCMD管理命令介绍159
ASM常用视图162
11.数据库备份164
11.1.备份概念说明164
脱机备份164
联机备份165
RMAN备份166
11.2.备份策略规划166
11.3.RMAN备份和恢复案例167
归档模式下的完全恢复167
归档模式下的不完全恢复170
12.数据库运维管理172
12.1.运维职责172
12.2.运维要求172
12.3.技能要求172
12.4.运维内容173
检查数据库运行情况173
检查操作系统和数据库日志文件175
检查Oracle对象状态176
检查数据库相关资源的使用179
检查数据库备份183
检查数据库的性能183
数据库安全性检查189
前言
编写目的
随着以使用Oracle数据库的应用系统不断增加，为了加强应用系统在规划、开发、实施、维护等环节工作的规范化，特编写本文档，力求对实际的设计、实施工作起到规范和指导作用。
本方案以设计者的角度进行组织编写，其主要思路是：
作为设计人员首先要了解数据库系统的运行模式，如何选择运行模式，其次要考虑系统的规划设计因素，有针对性的做好数据库的设计，提高数据库的性能，并对系统开发也提出相关要求。
方案说明
本方案分为两大部分，其中第一部分是第二到七章，主要介绍Oracle数据库的运行方式和规划设计以及与开发相关内容；第二部分是第八到十二章，主要介绍数据库的日常运行维护相关的内容。
第一部分偏重于规划和开发，第二部分偏重于实际管理及命令。
其中：
第二章介绍了Oracle数据库的部署运行方式；第三章介绍了业务系统特点和数据库的类型规模以及部署前的建议；第四章介绍了数据库运行的物理环境的配置规划；第五章介绍了Oracle数据库的安装部署规划以及命名原则；第六章介绍了数据库的应用规划；第七章介绍了系统开发的建议；第八章介绍数据库的体系架构；第九章介绍数据库的基本管理方法；第十章介绍了数据库集群的管理；第十一章介绍了数据库的备份和恢复；第十二章介绍了数据库的日常运行维护管理。
本方案编写过程中注重实际的可操作性，所提出的建议尽量覆盖系统生命周期中的各个关键点。
其中所涉及的参数和指标对系统的建设和运营起指导作用，但是在实际工作中，每个系统都有各自的特点，所以建议在初期对系统进行初始配置后，应根据系统的实际运行状态进行相应调整。
预期读者
项目基础设施可行性研究、设计和实施人员，项目组系统设计开发人员，相关运行维护技术人员。
数据库部署模式
单机模式
数据库服务器采用单服务器模式，满足对可用性和性能要求不高的应用，具备以下特点:
1、硬件成本低。
单节点，硬件投入较低，满足非重要系统的需求。
2、安装配置简单。
由于是单节点、单实例，所以安装配置比较简单。
3、管理维护成本低。
单实例，维护成本低。
4、对应用设计的要求较低。
由于是单实例，不存在RAC系统应用设计时需要注意的事项，所以应用设计的要求较低。
5、可用性不高。
由于是单服务器、单实例，所以服务器和实例的故障都会导致数据库不可用。
6、扩展性差。
无法进行横向扩展，只能进行纵向扩展。
当应用对性能有更高的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能进行增加硬件配置等纵向扩展，且扩展性有局限。
7、根据该模式的特点有如下要求：
1）硬件配置方面预留扩展量。
由于该模式无法进行横向扩展，所以在选择硬件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。
2）充分考虑该模式是否满足应用未来一段时间的需求。
需要考虑应用在未来一段时间是否会发生变化，该模式是否满足应用变化的需求。
双机热备模式（HA模式）
数据库服务器采用双机热备模式，可以满足对可用性有一定要求的应用，
具备以下特点：
1、需要冗余的服务器设备。
该模式需要有冗余的服务器硬件，以满足一备一或者一备多的需求。
硬件成本较高。
2、需要HA软件的支持。
该模式需要配合HA软件才可以实现。
3、安装配置相对简单。
该模式比单节点、单实例的模式配置复杂一些，需要更多的配置步骤，但相比较RAC、DATAGUARD等模式要简单。
4、管理维护成本低。
单实例，对维护人员的要求较低，维护成本低。
5、对应用设计的要求较低。
由于是单实例，不存在RAC系统应用设计时需要注意的事项，所以应用设计的要求较低。
6、具备一定的高可用性。
由于是多服务器、单实例，所以服务器和实例有故障时会发生实例在不同服务器上的切换，导致数据库的暂时不可用。
无法满足对可用性有严格要求的应用类型。
7、扩展性差。
无法进行横向扩展，只能进行纵向扩展。
当应用对性能有更高的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能进行增加硬件配置等纵向扩展，且扩展性有局限。
根据该模式的特点有如下要求：
1）硬件配置方面预留扩展量。
由于该模式无法进行横向扩展，所以在选择硬件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。
2）充分考虑该模式是否满足应用未来一段时间的需求。
需要考虑应用在未来一段时间是否会发生变化，该模式是否满足应用变化的需求。
集群模式（RAC）
数据库服务器采用RAC模式，满足对高可用性要求高的应用类型，
具备以下特点:
1、需要多个硬件服务器。
根据节点的个数，相应的需要多个硬件服务器。
硬件成本较高。
2、某些数据库版本需要HA软件的支持。
该模式下，某些数据库版本需要配合HA软件才可以实现。
3、安装配置复杂。
该模式比起单实例模式，安装配置相对复杂，安装配置周期长。
4、管理维护成本高。
该模式的管理维护，对管理维护人员的要求较高，管理维护成本较高。
5、对应用设计的要求较高。
需要充分考虑业务的逻辑性，以避免在多节点之间的信息交换和全局锁的产生。
6、具备较高的高可用性。
由于是多服务器、多实例，单服务器和实例有故障不会影响数据库的可用性。
可以满足对可用性有严格要求的应用类型。
7、扩展性好。
既可以进行横向扩展，也可以进行纵向扩展。
当应用对性能有更高的要求时，该模式的数据库可以通过增加节点的方式进行横向扩展，也可以通过增加硬件配置等纵向扩展，具备良好的扩展性。
根据该模式的特点有如下要求：
1）硬件配置方面预留扩展量。
预留一定的硬件扩展量，可以更灵活的进行扩展。
2）在应用设计时，充分考虑业务逻辑，减少多节点间的信息交换量，更好的发挥RAC的优点。
主从模式（DataGuard）
数据库服务器采用DataGuard主从模式，可以满足对可用性有特殊需求的应用，具备以下特点：
1、需要冗余的服务器设备。
该模式需要有冗余的服务器硬件。
硬件成本较高。
2、需要冗余的存储设备。
主机和备机都需要同样的存储空间，成本较高。
3、安装配置比较复杂。
该模式比单节点、单实例的模式配置复杂一些，需要更多的配置步骤。
4、管理维护成本高。
该模式对维护人员的要求较高，维护成本高。
5、具备一定的容灾特性。
当主机整个数据库系统不可用并短期内无法恢复时，可以把数据库系统切换到备机上，具备容灾的功能。
6、备机可以用作只读查询。
备机可以切换到只读状态供报表之类的查询操作，减轻主机的压力。
根据该模式的特点有如下要求：
1）主机与备机在物理上要分开。
为了实现容灾的特性，需要在物理上分割主机和备机。
2）进行合理的设计，充分实现DATAGUARD的功能。
混合模式（DataGrard+RAC）
数据库服务器采用DataGuard+RAC模式，可以满足对可用性和容灾都有特定需求的应用，具备以下特点：
1、需要冗余的服务器设备。
该模式需要有冗余的服务器硬件。
硬件成本较高。
2、需要冗余的存储设备。
主机和备机都需要同样的存储空间，成本较高。
3、安装配置比较复杂。
该模式既需要配置RAC又需要配置DATAGUARD，配置过程比较复杂，配置周期长。
4、管理维护成本高。
该模式对维护人员的要求较高，维护成本高。
5、具备很高的可用性和容灾性。
该模式既满足高可用性也满足容灾的需求。
6、备机可以用作只读查询。
备机可以切换到只读状态供报表之类的查询操作，减轻主机的压力。
根据该模式的特点有如下要求：
1）主机与备机在物理上要分开。
为了实现容灾的特性，需要在物理上分割主机和备机。
2）进行合理的设计，充分实现DataGuard的功能。
数据库运行模式选择
在设计数据库时必须考虑系统的可用性、业务连续性，针对系统所能容忍的最大业务中断时间（RTO）和最大数据丢失数量（RPO）需求，采用不同的数据库部署模式：
1、系统不能中断且不允许数据丢失的业务，建议数据库采用集群或混合模式，数据库单台设备故障时对业务没有影响，并考虑灾备系统的设计。
2、对于允许以分钟级别中断，数据不能丢失的系统，建议数据库采用双机热备或主从的模式，设备故障时通过HA技术切换到备用设备，保证系统的可用性，对重要的系统要考虑灾备的设计。
3、对于允许以天为级别中断的业务系统，建议可采用双机热备模式，或单机。
4、对非关键系统、开发环境、测试环境，建议采用PC服务器、冷备或单机的模式。
系统特点和数据库类型
业务系统的特点
业务系统处理数据的特点决定了设计人员规划和创建什么样的数据库，通常来说，业务分为两类：
在线事务处理系统（OLTP）和在线分析系统（OLAP）或者DSS（决策支持系统）。
这两类系统在数据库的设计上是不同的，比如OLTP系统强调数据库的内存效率，强调各种内存指标的命中率，强调绑定变量，强调并发操作：
而OLAP系统则强调数据分析，强调SQL执行时长，强调磁盘I/O，强调分区等。
OLTP特点
通常OLTP（在线事务处理系统）的用户并发数很多，但只对数据库做很小的操作，数据库侧重于对用户操作的快速响应，这是对数据库最重要的性能要求。
对于一个OLTP系统来说，数据库内存设计非常重要，如果数据都可以在内存中处理，那么数据库的性能会提高很多。
内存的设计通常是通过调整Oracle和内存相关的初始化参数来实现的，比较重要的几个是内存相关的参数，包括SGA的大小（DataBuffer，SharedPool），PGA大小（排序区，Hash区等）等，这些参数对一个OLTP系统是非常重要的。
OLTP系统是一个数据块变化非常频繁，SQL语句提交非常频繁的一个系统。
对于数据块来说，应尽可能让数据块保存在内存当中，对于SQL来说，尽可能使用变量绑定技术来达到SQL的重用，减少物理I/O和重复的SQL解析，能极大的改善系统的性能。
此外，没有绑定变量的SQL会对OLTP数据库造成极大的性能影响，还有一些因素也会导致数据库的性能下降，比如热块（hotblock）的问题，当一个块被多个用户同时读取的时候，Oracle为了维护数据的一致性，需要使用Latch来串行化用户的操作，当一个用户获得了这个Latch，其他的用户就只能被迫的等待，获取这个数据块的用户越多，等待就越明显，就造成了这种热块问题。
这种热块可能是数据块，也可能是回滚段块。
对于数据块来讲，通常是数据块上的数据分布不均匀导致，如果是索引的数据块，可以考虑创建反向索引来达到重新分布数据的目的，对于回滚段数据块，可以适当多增加几个回滚段来避免这种争用。
OLAP特点
OLAP数据库在内存上可优化的余地很小，但提升CPU处理速度和磁盘I/O速度是最直接的提高数据库性能的方式。
实际上，用户对OLAP系统性能的期望远远没有对OLTP性能的期望那么高。
对于OLAP系统，SQL的优化显得非常重要，如果一张表中只有几千数据，无论执行全表扫描或是使用索引，对用户来说差异都很小，几乎感觉不出来，但是当数据量提升到几亿或者几十亿或者更多的时候，全表扫描，索引可能导致极大的性能差异，因此SQL语句的优化显得重要起来。
分区技术在OLAP数据库中很重要，这种重要主要是体现在数据管理上，比如数据加载，可以通过分区交换的方式实现，备份可以通过备份分区表空间，删除数据可以通过分区进行删除。
数据库的规模
对于数据库的规模，仅从数据量来衡量其规模的大小。
因为数据量的规模是反映数据库规模的主要指标。
具体如下：
1）数据库业务数据量小于100GB属小规模数据库
2）数据库业务数据量1TB以内属中大规模数据库
3）数据库业务数据量大于1TB属大规模数据库
数据库版本建议
Oracle数据库产品推出新的主要版本后，要经历一个版本不稳定期。
在此期间新版的数据库产品存在较多的bug。
在安装和运行过程中，会存在数据库安装困难和运行不稳定现象。
因此在选择版本时，要选择成熟稳定的版本。
数据库运行环境规划
根据用户需求在业务系统前期的实施规划上，需要做好详细的规划设计，包括主机、网络和存储环境规划等，要将整个软硬件融为一体，充分考虑系统的安全性，可靠性，高可用性等因素，只有一个规划好的系统才能充分发挥其优于单节点的优势，同时也为后期的运维管理提供方便。
在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些因素等。
理想情况下，应考虑下列要素：
交易的复杂性、交易率、数据读/写比例、并发连接数目、并发交易数目、数据库最大表的大小、性能度量的目标。
主机规划
主机规划主要需考虑服务器在不同的用户数量下，系统的响应时间和吞吐量，并得出当前服务器的各种资源的利用情况。
在规划系统配置时要预留做系统管理时所消耗的资源，如在做备份、恢复、问题诊断、性能分析、系统维护时都会对系统资源带来额外的消耗，对重要资源要考虑为将来留下升级和可扩展的余地。
在进行服务器配置规划时，要注意以下几点：
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。
网络规划
网络规划的基本原则就是将业务生产网络、存储网络和管理网络分开，推荐在生产网络使用万兆网，存储使用SAN存储网络，管理网可使用千兆网。
对于数据库单机模式、HA双机模式以及主备模式的生产环境，主要基本符合网络规划的基本原则即可。
对于集群模式，因Oracle有其特殊要求，所以在结合网络规划基本原则的基础上，可进行细化实施。
在Oracle11gR2中，安装RAC发生了显着变化。
在10g以及11gR1的时代，安装RAC的步骤是先安装CRS，再安装DB，而到了11gR2的时代，crs与asm被集成在一起，合称为GRID，必须先安装GRID后，才能继续安装DB。
本方案以主流的ORACLE11gR2RAC的网络规划为例进行详细说明。
假设服务器上有4块网卡：
eth0,eth1,eth2，eth3.可以将eth0和eth2绑定成bond0。
作为RAC的public-ip，提供外部通信。
然后将eth1和eth3绑定成bond1，作为RAC的private-ip，提供内部心跳通信。
服务器上的HBA卡通过光纤交换机与后端存储通信。
公有IP和虚拟IP
OracleRAC中每个节点都有一个虚拟IP，简称VIP，与公网PUBLICIP在同一个网段。
VIP附属在public网口接口。
VIP和PUBLICIP最主要的不同之处在于：
VIP是浮动的，而PUBLICIP是固定的。
在所有节点都正常运行时，每个节点的VIP会被分配到publicNIC上；在linux下ifconfig查看，public网卡上是2个IP地址；如果一个节点宕机，这个节点的VIP会被转移到还在运行的节点上。
也就是幸存的节点的publicNIC这个网卡上，会有3个IP地址。
PUBLICIP地址是一个双网卡绑定的公有地址，用户通过交换机来进行访问。
RAC中的私有IP
RAC中的Private私有IP用于心跳同步，这个对于用户层面，可以直接忽略。
简单理解，这个IP用来保证数据库节点同步数据用的，属于RAC内部之间通信。
priv与public不应同属一个接口。
Metalink上的RAC文档是推荐使用交换机作为内部网卡的连接,而不使用交叉线,原因是避免因为对连节点关闭或重启而导致网卡检查到链接故障状态而删除绑定的协议。
导致高速缓存合并网络将会变为不可用。
SCANIP
在11gR2中，SCANIP是作为一个新增IP出现的,SCANIP其实是Oracle在客户端与数据库之间，新加的一个连接层，当有客户端访问时，连接到SCANIPLISTENER，而SCANIPLISTENER接收到连接请求时，会根据LBA算法将该客户端的连接请求，转发给对应的instance上的VIPLISTENER，从而完成了整个客户端与服务器的连接过程。
简化如下：
client->scanlistener->locallistener->localinstance
也可以把scan理解为一个虚拟主机名，它对应的是整个RAC集群。
客户端主机只需通过这个scanname即可访问数据库集群的任意节点。
当然
升级会员 