Oracle数据库规划设计和运行维护方案.docx
《Oracle数据库规划设计和运行维护方案.docx》由会员分享,可在线阅读,更多相关《Oracle数据库规划设计和运行维护方案.docx(198页珍藏版)》请在冰豆网上搜索。
Oracle数据库规划设计和运行维护方案
封面
作者:
PanHongliang
仅供个人学习
Oracle数据库规划设计
和运行维护方案
(V1.0)
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的大小(DataBuffer,SharedPool),PGA大小(排序区,Hash区等)等,这些参数对一个OLTP系统是非常重要的。
OLTP系统是一个数据块变化非常频繁,SQL语句提交非常频繁的一个系统。
对于数据块来说,应尽可能让数据块保存在内存当中,对于SQL来说,尽可能使用变量绑定技术来达到SQL的重用,减少物理I/O和重复的SQL解读,能极大的改善系统的性能。
此外,没有绑定变量的SQL会对OLTP数据库造成极大的性能影响,还有一些因素也会导致数据库的性能下降,比如热块(hotblock)的问题,当一个块被多个用户同时读取的时候,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有其特殊要求,所以在结合网络规划基本原则的基础上,可进行细化实施。
在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卡通过光纤交换机与后端存储通信。
4.2.1.1.公有IP和虚拟IP
OracleRAC中每个节点都有一个虚拟IP,简称VIP,与公网PUBLICIP在同一个网段。
VIP附属在public网口接口。
VIP和PUBLICIP最主要的不同之处在于:
VIP是浮动的,而PUBLICIP是固定的。
在所有节点都正常运行时,每个节点的VIP会被分配到publicNIC上;在linux下ifconfig查看,public网卡上是2个IP地址;如果一个节点宕机,这个节点的VIP会被转移到还在运行的节点上。
也就是幸存的节点的publicNIC这个网卡上,会有3个IP地址。
PUBLICIP地址是一个双网卡绑定的公有地址,用户通过交换机来进行访问。
4.2.1.2.RAC中的私有IP
RAC中的Private私有IP用于心跳同步,这个对于用户层面,可以直接忽略。
简单理解,这个IP用来保证数据库节点同步数据用的,属于RAC内部之间通信。
priv与public不应同属一个接口。
Metalink上的RAC文档是推荐使用交换机作为内部网卡的连接,而不使用交叉线,原因是避免因为对连节点关闭或重启而导致网卡检查到链接故障状态而删除绑定的协议。
导致高速缓存合并网络将会变为不可用。
4.2.1.3.SCANIP
在11gR2中,SCANIP是作为一个新增IP出现的,SCANIP其实是Oracle在客户端与数据库之间,新加的一个连接层,当有客户端访问时,连接到SCANIPLISTENER,而SCANIPLISTENER接收到连接请求时,会根据LBA算法将该客户端的连接请求,转发给对应的instance上的VIPLISTENER,从而完成了整个客户端与服务器的连接过程。
简化如下:
client->scanlistener->locallistener->localinstance
也可以把scan理解为一个虚拟主机名,它对应的是整个RAC集群。
客户端主机只需通过这个scanname即可访问数据库集群的任意节点。
当然访问的节点是随机的,Oracle强烈建议通过DNSServer的roundrobin模式配置解读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、数据表空间(permanencetablespace):
用来保存永久数据,包含永久数据文件。
强烈建议在永久表空间内创建永久数据文件,不要创建临时数据文件。
2、临时