数据库云服务器

Oracle最高可用性架构Exadata数据库云服务器整合最佳实践Oracle最高可用性架构Oracle白皮书2013年1月Exadata数据库云服务器上的数据库整合最佳实践Oracle最高可用性架构Exadata数据库云服务器整合最佳实践执行概要.
3引言3Exadata整合规划.
4设置和管理关键资源以实现稳定性.
7推荐的存储网格(磁盘组)配置7推荐的数据库网格(集群)配置8推荐的参数设置.
9启动对系统的监视和检查20资源管理.
20将ResourceManager用于数据库内(模式)整合.
20将ResourceManager用于数据库整合.
21案例1:OLTP数据库的整合24案例2:混合负载的整合.
24案例3:数据仓库的整合.
25资源管理最佳实践25维护和管理考虑事项.
25Oracle软件和文件系统空间.
25安全性和管理角色26用于整合的ExadataMAA.
27打补丁和升级29备份和恢复.
30DataGuard.
31模式整合环境的恢复31总结32Oracle最高可用性架构Exadata数据库云服务器整合最佳实践3执行概要当您在目标系统上托管多个模式、应用程序或数据库时,通过整合能够最大限度减少闲置资源并降低成本.
整合是在公有云和私有云上部署Oracle数据库的核心驱动因素.
本白皮书为您提供Exadata数据库云服务器(简称Exadata)整合最佳实践,从而使您能够设置和管理系统和应用程序以实现最大稳定性和最高可用性.
引言在IT部门中,在组织致力于实现更高运营效率的过程中,整合是一项重要的战略.
通过整合,组织可以提高IT资源利用率,以便最大限度地缩短空闲周期.
相应的,由于能够以更少的资源实现相同的产出,从而可降低成本.
例如,在一天中不同时间经受峰值负载的各应用程序可以共享同一硬件,而不是使用专用的、在非高峰期将会空闲的硬件.

根据涉及的系统和环境,可通过多种不同方式实现数据库整合.
在单个数据库中运行多个应用程序模式、在单个平台上托管多个数据库或这两种配置的混合都是数据库整合的有效形式.

Exadata针对Oracle数据仓库和OLTP数据库负载进行了优化,其平衡的数据库服务器和存储网格基础架构使其成为用于数据库整合的理想平台.
Oracle数据库、存储和网络网格架构与Oracle资源管理特性相结合,为您提供一种比其他虚拟化战略(如硬件或操作系统虚拟化)更简单、更灵活的数据库整合方法.
Exadata目前依靠简化Oracle资源管理来实现高效数据库整合.
但Exadata目前尚不支持虚拟机或Solaris区域.
本白皮书为您介绍推荐用来在Exadata上整合数据库的方法,其中包含必需的初始规划阶段、设置阶段和管理阶段,当系统支持多个应用程序和数据库使用共享资源时,可通过此方法最大限度地提高系统稳定性和可用性.
Oracle最高可用性架构Exadata数据库云服务器整合最佳实践4本白皮书补充完善了其他Exadata最佳实践和最高可用性架构(MAA)最佳实践,同时也引用了其他适用的相关白皮书.
本白皮书不讨论SPARCSupercluster、Exalogic或虚拟机上的数据库整合.
Exadata整合规划1.
定义高可用性(HA)、计划维护和业务需求.
在Exadata上进行整合时,应该应用一些核心原则.
首先,各目标数据库的可用性和计划维护目标应该类似.
如果不是这样,那么不可避免,会对其中的一些应用程序在某些方面产生不利影响.
例如,如果任务关键型应用程序与开发系统或测试系统共享同一环境,那么开发和测试系统中频繁的变更会对任务关键型应用程序的可用性和稳定性造成影响.
考虑到管理通用基础架构(例如Oracle网格基础架构(包括OracleClusterware和OracleASM)以及Exadata存储单元)和运营系统环境的效率和相对简单性,Oracle将采用整合相似服务级别目标数据库的方法.
如果各目标应用程序的服务级别要求并不相似,那么整合的优势将不复存在.
企业应首先定义以下关键高可用性要求:恢复时间目标(RTO或应用程序的目标恢复时间)、恢复点目标(RPO或应用程序的最大数据丢失容限)、灾难恢复(DR)的恢复时间以及指定的计划维护时段.
还必须考虑其他事项,例如性能目标(预计的峰值负载时段、平均负载时段和空闲负载时段)、系统要求、安全性和组织边界,以确保各候选应用程序之间的兼容性.

2.
按类别将数据库分成多个组.
根据步骤1中确定的高可用性要求将计划进行整合的数据库分成组.
例如可按类别将数据库分成以下几个组:关键:与核心业务相关的面向客户的创收型数据库标准:其他非关键生产数据库非生产型:开发和测试数据库每个组都可进一步细分(如果需要),以使所有应用程序的高可用性要求和计划维护时段不会彼此冲突.
3.
创建Exadata硬件池.
硬件池一词描述的是用作目标整合平台的一台或一组机器.
企业可以创建多个硬件池,以使得每个整合目标平台更易于管理.
推荐的最小硬件池为半机架ExadataX3-2,推荐的最大硬件池为两台全机架Exadata数据库云服务器(如果需要,还可以加上Oracle最高可用性架构Exadata数据库云服务器整合最佳实践5额外Exadata存储扩展机架).
此范围的硬件池是最常见的用于整合的Exadata配置,它们能够提供足够的容量,可有效实现数据库整合目标.
对于初级整合,还可以选择部署一个只包含四分之一机架或八分之一机架ExadataX3-2的小型硬件池.
如果在单独的Exadata上部署了一个备用数据库,那么对于关键应用程序,上述方法是可接受的.
四分之一机架或八分之一机架ExadataX3-2在高可用性方面的一个小缺点是,没有足够的Exadata单元可供表决磁盘驻留在任何高冗余磁盘组中.
表决磁盘需要5个故障组或5个Exadata单元,这就是为何我们推荐将半机架Exadata作为最小硬件池的一个主要原因.
如果因为存储故障卸载了(驻留表决磁盘的)ASM磁盘组,那么会有OracleASM和OracleClusterware出故障的风险.
这种情况下,所有数据库都会出现故障,但是可以按照MyOracleSupport(MOS)说明1339373.
1中的方法手动重新启动这些数据库(请参阅"DBFS_DG丢失产生的影响"一节).
您还能够部署一个包含8台或更多全机架Exadata数据库云服务器的硬件池.
但不推荐这样做,因为调度和管理这样一个整合环境的复杂性会抵消整合带来的优势.

通过给节点和Exadata存储单元(也称为Exadata单元)分区,还可以在一个Exadata数据库云服务器上共存多个硬件池.
但也不建议使用此配置,因为分区方法可能会导致资源利用效率低下,并有以下缺点:限制对整个服务器和存储网格带宽的访问增加复杂性对于InfiniBand结构、Cisco交换机和物理机架本身等常用组件,缺乏完备的故障和维护隔离机制4.
将数据库组和应用程序组映射到特定硬件池.
继续上面的示例,每个数据库组和应用程序组都将部署到它们自己的硬件池上:关键、标准和非生产型.
不要将不同组的数据库整合到同一硬件池中.
如果一个组需要的容量超过了单个硬件池提供的容量,则将该组中的目标数据库分为两个单独的组,然后再将每个组部署在它自己的硬件池中.
任何一个数据库,如果它需要的容量超过了两台全机架Exadata数据库云服务器和附加Exadata存储扩展机架(此为推荐的最大硬件池)提供的容量,那么不应将该数据库视为能从整合获益的候选数据库;如果需要,这种数据库最好部署到由多个Exadata系统组成的专用集群上.
下表提供了一个使用Exadata硬件池时,不同高可用性要求可能需要哪些不同架构的示例.
Oracle最高可用性架构Exadata数据库云服务器整合最佳实践6表1.
高可用性要求及其推荐的架构高可用性要求推荐的架构具有以下要求的任务关键型应用程序:RTORTORPORTORPORTO云服务器整合最佳实践7应用程序合理地安装到一个硬件池中.
有关大小的详细信息,请联系Oracle咨询部门和Oracle高级客户支持服务(ACS)部门获取.
其他考虑事项包括:预留系统容量,以供各种高可用性(HA)和滚动升级活动使用,例如OracleRealApplicationClusters(OracleRAC)和Exadata单元滚动升级活动.
为关键硬件池预留系统容量,以实现最高稳定性.
例如,常用的最佳实践是,将关键硬件池配置为有25%的未分配资源,以适应高峰期负载.
请记住,如果关键硬件池使用OracleAutomaticStorageManagement(ASM)高冗余磁盘组,则可用的数据存储空间会更小.
评估应用程序之间及数据库之间的业务或负载周期是否允许进一步整合.
例如,应用程序A可能会在应用程序B相对空闲的时候拥有峰值负载.
6.
收集每个应用程序和数据库的准确性能要求.
收集每个应用程序对吞吐量和响应时间的准确性能预期.
使用OracleEnterpriseManager(EM)GridControl或EMCloudControl监视关键应用程序量度,包括应用程序、数据库和系统性能统计信息的历史记录.
在调试任何未来性能问题时会需要这些数据.
设置和管理关键资源以实现稳定性完成初始规划和大小调整活动后,将转到设置Exadata硬件池阶段.
本节为您提供与在Exadata上整合数据库相关的建议,从初始部署到特定配置设置都涵盖其中.
推荐的存储网格(磁盘组)配置推荐的存储配置是每个硬件池配有一个共享Exadata存储网格.
此存储网格包含所有Exadata单元和Exadata磁盘,并配置为具备ASM高冗余或常规冗余(将在后面进一步讨论ASM冗余).
图1.
共享Exadata存储网格Oracle最高可用性架构Exadata数据库云服务器整合最佳实践8主要优势是:管理简单且方便是最常用的经过充分验证的配置平衡配置,通过该配置,应用程序拥有对I/O带宽和存储的完全访问权限支持容错和滚动升级管理一个共享的Exadata存储网格比较简单,只需很少的管理成本.
通过共享存储,空间和带宽的利用也更高效.
如果存储空间和I/O带宽需求超过一个全机架Exadata所提供的容量,您可以添加一个Exadata存储扩展机架,也可以将应用程序迁移到其他硬件池.
如果该硬件池是关键硬件池,则强烈建议针对DATA和RECO磁盘组使用ASM高冗余,从而提供Exadata存储单元滚动升级和其他维护活动期间特殊需要的对存储故障的最佳容错能力.
有关DATA和RECO磁盘组配置、MAA存储网格配置以及四分之一和八分之一机架ExadataX2-2或X3-2限制的详细信息,请参阅OracleExadata存储服务器软件用户指南中的"关于通过OracleASM实现最高可用性".
当您的空间受限时,如果还部署了一个使用OracleDataGuard的备用硬件池(备用池),那么可考虑针对DATA和RECO磁盘组使用ASM常规冗余.
使用备用池,在数据库、集群或存储出现故障时,可实现最全面的数据损坏保护及快速故障切换,从而降低未在主硬件池上使用高冗余所带来的高可用性和数据保护方面的风险.
如果您的空间受限,而且又无法部署备用池,那么还有第二种方法,即针对DATA磁盘组使用高冗余,而针对RECO磁盘组使用常规冗余.
请注意,在发生存储故障时,此方法可能会影响可用性和简便性.
有关在丢失DATA或RECOASM磁盘组时应如何进行恢复的详细信息,请参阅MyOracleSupport(MOS)说明1339373.
1.
您应该使用OneCommand配置过程中的磁盘组配置(在Exadata数据库云服务器所有者指南中有所介绍).
默认情况下,第一个高冗余磁盘组存储联机日志、控制文件、服务器参数文件、集群件和表决设备.
DATA磁盘组存储数据库文件,而RECO磁盘组则包含针对快速恢复区(FRA)的与恢复相关的文件.
如果要求隔离应用程序,可创建单独的DATA和RECO磁盘组.
请参阅本文后面第26页上的"安全性和管理角色"一节或OracleExadata数据库云服务器整合:分离数据库和角色MAA白皮书.
此外,在创建ASM磁盘组时,确保将ASM磁盘组的COMPATIBLE.
RDBMS属性设置为硬件池中Oracle数据库软件的最低版本.
推荐的数据库网格(集群)配置Oracle最高可用性架构Exadata数据库云服务器整合最佳实践9推荐的Oracle网格基础架构(包括OracleClusterware和OracleASM)设置是每个硬件池使用一个集群.
应使用由OracleClusterware管理的Oracle数据库服务来进一步对应用程序进行负载平衡,从而将应用程序路由到集群中特定的Oracle数据库实例上.
主要优势有:管理简单且方便平衡配置,通过该配置,应用程序拥有对数据库CPU和内存带宽的完全访问权(如果需要)支持容错功能支持RAC和网格基础架构滚动升级功能当特定应用程序资源增长或收缩时,可方便、透明地对服务进行负载平衡并路由到可用的数据库实例和节点上.
OracleGridInfrastructure软件的版本必须等于或高于您计划在集群中使用的OracleRAC软件的最高版本.
虽然可随时升级GridInfrastructure软件,但是如果各数据库按不同时间表升级,则需要进行规划以降低修补GridInfrastructure的频率.
所有GridInfrastructure升级应是滚动升级.
应为关键硬件池分配一个DataGuard硬件池(备用池),以避免其受到集群故障、数据库故障、数据损坏和灾难的影响.
您还可以切换到备用池以进行站点、系统或数据库维护.
注意:对于Oracle11g第1版以及更高版本,每个集群中数据库实例的数量最多为512.
建议将每个X2-2或X3-2数据库节点的数据库实例数量的上限限定为128,而将每个X2-8或X3-8数据库节点的数据库实例数量的上限限定为256.
每个数据库节点或集群的实际数据库实例数量取决于应用程序负载及其相应的系统资源占用.

推荐的参数设置以下参数设置对于每种硬件池都尤为重要.
它们有助于高效地分配系统资源和限制系统资源的使用.
随着负载的变化或数据库的添加或弃用,需要定期进行监视以调整和调优这些参数设置.
操作系统参数如果/proc/meminfo中的PageTables设置为大于物理内存的2%,则将操作系统参数HugePages设置为所有共享内存段的总和.
(仅限LINUX)HugePages是一种允许Linux内核使用多种页面大小功能的机制.
Linux将页作为内存的基本单元,按基本页单元划分和访问物理内存.
默认页面大小是4096字节.
Hugepages支持以低开销使用大量内存.
Linux使用CPU架构中的转换旁路缓冲区Oracle最高可用性架构Exadata数据库云服务器整合最佳实践10(TLB).
这些缓冲区中包含了虚拟内存到实际物理内存地址的映射.
因此具有较大页面大小的系统可提供更高密度的TLB条目,从而减少了页表空间.
此外,每个进程使用较小的私有页表,而随着进程数量的不断增多,由此实现的内存节省将非常明显.

如果/proc/meminfo中的PageTables大于物理内存的2%,则通常需要设置HugePages.
设置时,HugePages应等于所有数据库实例使用的共享内存段的总和.
当所有数据库实例都在运行时,可通过分析ipcs-m命令的输出来计算被使用的共享内存的数量.
MOS说明401749.
1提供了一个可用于确定在用共享内存数量的脚本.
MOS说明361468.
1介绍如何设置HugePages.
从版本11.
2.
0.
2开始,在所有实例上设置数据库初始化参数USE_LARGE_PAGES=ONLY,可防止在没有足够大页面的情况下启动实例.
注意:如果数据库参数SGA_TARGET有变化,或每当数据库实例数量变化时,都必须重新计算要使用的HugePages的值.
Hugepages只可用于SGA,因此不要过度分配.
此外,如果启用了HugePages,则数据库参数MEMORY_MAX_TARGET和MEMORY_TARGET互不兼容.
注意:在Solaris上,通过锁定共享内存(ISM)自动配置和使用HugePages.
将共享内存段的数量(kernel.
shmmni)设置为大于数据库的数量.
应将共享内存标识符的数量设置为大于节点上运行的数据库实例的数量.
可使用sysctl命令(如,/sbin/sysctl-a|grepshmmni)检查kernel.
shmmni的设置.
如果需要,可在Linux系统上通过设置/etc/sysctl.
conf中的kernel.
shmmni来进行调整.
SHMMNI的默认设置(4096)应能满足所有情况的需求.
将最大共享内存段大小(kernel.
shmmax)设置为物理内存大小的85%,这是默认设置应将最大共享内存段大小设置为数据库服务器物理内存大小的85%.
使用sysctl命令检查kernel.
shmmax的设置.
如果需要,可在Linux系统上通过设置/etc/sysctl.
conf中的kernel.
SHMMAX来进行调整.
将系统信号的最大总数(SEMMNS)设置为大于所有数据库进程的总数.
系统中信号的最大数量必须大于系统上运行的所有数据库实例的进程的总数(如数据库参数PROCESSES所指定的数值).
可使用sysctl命令检查kernel.
sem的设置.
kernel.
sem的设置包含一个由4个数字值组成的列表.
系统上信号总数的设置,Oracle最高可用性架构Exadata数据库云服务器整合最佳实践11也称为SEMMNS,是列表中的第二个值.
如果需要,通过设置/etc/sysctl.
conf中的kernel.
sem进行调整.
SEMMNS的默认设置(60000)应能满足所有情况的需求.
将一个信号集内的最大信号数量(SEMMSL)设置为大于任何一个数据库内的最大进程数量.
应将一个信号集内的最大信号数量设置为大于数据库服务器上运行的任何一个数据库实例的最大进程数量.
使用sysctl命令检查kernel.
sem的设置.
一个信号集内最大信号数量的设置,也称为SEMMSL,是上述列表中的第一个值.
如果需要,可在Linux系统上通过设置/etc/sysctl.
conf中的kernel.
sem来进行调整.
数据库内存设置Exadata系统提供以下物理内存:基于SunFireX4170OracleDatabaseServer的ExadataX2-2(也称为V2)的每台数据库服务器配有72GB内存ExadataX2-2默认配置配有96GB内存,可以选择扩展为144GB内存(通过Exadata内存扩展工具包实现).
ExadataX3-2配有256GB内存.
ExadataX2-8的每台数据库服务器配有1TB内存(对于X4800)或2TB内存(对于X4800M2).
ExadataX3-8的每台数据库服务器配有2TB内存.
应始终避免过度的内存分页(或称"页出"),因为这会导致应用程序性能变差及节点不稳定.
应定期监视系统内存以查看是否有页出情况.
注意:使用Linuxfree命令显示系统上的空闲内存和已用内存信息.
使用vmstat命令监视页出值是否为零或较低.
使用操作系统pstop(Linux)或prstat(Solaris)命令查看更多进程级信息,包括私有和共享内存利用率.
如果PGA_USED_MEM超过应用程序的阈值,针对V$PROCESS的数据库查询会向您发出警报.
在某些情况下,您可能需要终止进程以防止因节点不稳定而影响到该数据库节点上的所有数据库和应用程序.
例如,任何进程,如果其OLTP占用的PGA内存超过1GB,以及数据仓库报告占用的内存超过10GB,则终止掉该进程是合理的.
确切的阈值取决于已知的应用程序行为和要求,但是应小于PGA_AGGREGATE_TARGET.

下面是一个查询示例和操作流程:Oracle最高可用性架构Exadata数据库云服务器整合最佳实践12SELECTs.
inst_id,s.
sid,s.
serial#,p.
spid,s.
username,s.
program,p.
pga_used_memFROMgv$sessionsJOINgv$processpONp.
addr=s.
paddrANDp.
inst_id=s.
inst_idWHEREs.
type!
='BACKGROUND'ands.
programnotlike'%(P%'andp.
pga_used_mem>orderbys.
inst_id,s.
sid,s.
serial#;每15分钟执行一次上述查询,用应用程序内存阈值的数值替代.
调查任何正以不公平方式占用内存的可疑进程.
如果此元凶进程占用的内存超过了内存阈值,且该进程不是关键进程,则有必要终止该进程以维护节点稳定性和其他客户端的性能,这点也许非常重要.
例如,您可以使用SQL语句ALTERSYSTEMKILLSESSION',,@'终止该会话,如果万不得已,也可以使用操作系统命令KILL-9.
对于初始部署和将应用程序迁移到硬件池的情况,请使用以下公式,确保为SGA、PGA和各服务器进程提供足够内存.
如果某个应用程序需要更多SGA或PGA内存分配以满足其性能需求,而又没有足够物理内存,则可利用另一个硬件池.
对关键硬件池而言,我们建议采用更保守的方法,即不要超过每个数据库节点的物理内存的75%.
OLTP应用程序:数据库的总数(SGA_TARGET+PGA_AGGREGATE_TARGET)+4MB*(最大进程数)云服务器整合最佳实践13表2.
PGA内存COMPONENTBEGINSNAPCURRENTSIZEMINSIZE(MB)MAXSIZE(MB)OPERCOUNTLASTOPSIZE(MB)(MB)TYP/MODPGATarget16,384.
0016,384.
0016,384.
0029,384.
000STA/表3.
内存统计BEGINENDHostMem(MB)96,531.
596,531.
5SGAUse(MB)24,576.
024,576.
0PGAUse(MB)577.
7578.
2%HostMemusedforSGA+PGA26.
0626.
06从上例可观测到,PGA_AGGREGATE_TARGET不是一个硬性限制.
在一些数据仓库应用程序中,已观测到累积的PGA内存使用是PGA_AGGREGATE_TARGET的三倍.
对于OLTP应用程序,内存使用超出的可能性通常非常低,除非应用程序使用大量PL/SQL.
查询V$PGASTAT提供PGA内存使用的实例级统计信息,其中包括:当前目标设置、内存使用总计、已分配内存总计以及分配的最大内存.
如果观测到PGA增长,您必须确定此增长是否是所预期的,且数据库服务器上是否有足够内存可用于满足此增长的需求.
如果答案是否定的,您可能需要提高PGA_AGGREGATE_TARGET设置并降低SGA_TARGET设置,以满足更大PGA内存分配的要求,或将应用程序迁移到其他数据库服务器或硬件池以从根本上解决此问题.
数据库CPU设置和实例囚笼实例囚笼是一个重要的工具,用于管理和限制每个数据库对CPU的使用.
通过实例囚笼,可防止失控进程和高应用程序负载产生非常高的系统负载,从而导致系统不稳定或导致其他数据库的性能变差.
要启用实例囚笼,请为服务器上的每个实例执行以下操作:1.
通过为RESOURCE_MANAGER_PLAN初始化参数分配一个资源计划来启用OracleDatabaseResourceManager.
此资源计划必须包含CPU指令才能启用实例囚笼.
有关说明,请参阅OracleDatabase11g第2版管理指南中的"启用OracleDatabaseResourceManager和切换计划".
如果您不打算管理数据库内的负载,只需将RESOURCE_MANAGER_PLAN设置为"DEFAULT_PLAN"即可.
Oracle最高可用性架构Exadata数据库云服务器整合最佳实践14SQL>ALTERSYSTEMSETRESOURCE_MANAGER_PLAN='DEFAULT_PLAN'SID='*'SCOPE='BOTH';2.
将CPU_COUNT初始化参数设置为实例随时会使用的最多CPU的个数.
默认情况下,将CPU_COUNT设置为服务器CPU的总个数.
对于超线程CPU,CPU_COUNT包含CPU线程数.
CPU_COUNT是一个动态参数,因此其值会随时变化,但是最好在启动实例时就设置此参数,因为它会影响其他Oracle参数和内部结构(例如PARALLEL_MAX_SERVERS、缓冲区缓存以及闩锁结构分配).
服务器可能的峰值负载等于该服务器上所有数据库实例的CPU_COUNT参数的总和.
通过将可能的峰值负载与每台服务器的CPU个数进行比较,可评估数据库实例间潜在的资源争用情况.
Exadata的每台服务器配有的CPU数量如下所述.
请注意,这些计数取决于CPU线程数,而不取决于内核数或插槽数.
ExadataV2的每台数据库服务器配有8个内核或16个CPU.
ExadataX2-2的每台数据库服务器配有12个内核或24个CPU.
ExadataX3-2的每台数据库服务器配有16个内核或32个CPU.
ExadataX2-8的每台X4800数据库服务器配有64个内核或128个CPU.
ExadataX2-8的每台X4800M2数据库服务器配有80个内核或160个CPU.
ExadataX3-8的每台数据库服务器配有80个内核或160个CPU.
配置实例囚笼最重要的步骤是确定每个数据库实例的CPU_COUNT值以及整个服务器的CPU_COUNT值的总和.
有以下两种方法:针对任务关键型硬件池采用分区方法.
如果目标数据库服务器上所有数据库实例的CPU_COUNT值的总和不超过该服务器的CPU的个数,则服务器已自然分区.
这种情况下,数据库实例间应不存在CPU资源争用.
但是如此一来,即使某个数据库实例未使用分配给它的CPU资源,其他数据库实例也无法使用这些CPU资源.
分区方法的优势是不存在CPU争用,但是有可能CPU未得到充分利用.
因此,建议将此分区方法用于关键硬件池中的任务关键型数据库.
建议使用以下特定大小调整方法:通过将CPU_COUNT值的总和限制为小于服务器CPU总数的75%,使得CPU资源可用于其他进程(PMON、SMON、LMS、LMON、LGWR等).
此外,由于Exadata使用超线程CPU,因此上述限制能够最大限度减少共享一个内核的各CPU线程之间的资源争用.
Oracle最高可用性架构Exadata数据库云服务器整合最佳实践15(CPU_COUNT)总数云服务器整合最佳实践16X2-8和X3-8:所有实例的(PARALLEL_MAX_SERVERS)总和RECOVERMANAGEDSTANDBYDATABASE…PARALLEL16.
限制进程数量以及到数据库服务器的连接数拥有较低的进程数或合适的进程数会带来很多优势,例如可避免或减少内存、CPU和数据库闩锁争用,缩短日志文件同步等待时间以及应用程序故障切换的总时间.
进程数和连接数的减少还会提高性能和吞吐量.
请参见"实际性能"培训视频,以了解进程数和连接数与性能之间的相关性,网址是:http://www.
youtube.
com/watchv=xNDnVOCdvQ0Oracle性能专家建议,可保守地将活动进程数设置为CPU内核数的5倍,或者,可将Siebel等CPU密集型应用程序的活动进程数设置为CPU内核数的1倍或2倍.
通过使用以下一项或多项技术,可以降低进程总数,从而提高性能:1.
具有最小连接数设置和最大连接数设置的应用程序连接池通过使用应用程序连接池,可以避免代价高昂的打开和关闭连接的过程,从而节省宝贵的系统资源.
通过使用连接池中的最小连接数设置和最大连接数设置,可以实现快速的响应速度、高效的内存和CPU使用,并能避免登录风暴.
该技术可显著减少连接的总数,而不会对任何性能目标产生影响.
1通过查询V$SESSIONwhereSTATUS="ACTIVE"或监视V$ACTIVE_SESSION_HISTORY,可获得活动的进程数量.
EnterpriseManager的性能页提供与此相关的详细信息以及对任何潜在争用的有益见解.
Oracle最高可用性架构Exadata数据库云服务器整合最佳实践17连接池是数据库连接对象的缓存.
这些对象表示可被应用程序用来连接到数据库的物理数据库连接.
在运行时,应用程序从连接池请求连接.
如果连接池包含满足此请求的连接,则将该连接返回给应用程序.
如果找不到可用的连接,则创建一个新连接,并将它返回给应用程序.
应用程序使用此连接在数据库上执行一些任务,完成任务后将此连接对象返回给连接池.
之后此连接可供下一个连接请求使用.

连接池促进了连接对象的重用,从而减少创建连接对象的次数.
创建连接对象在时间和资源上的开销都很大,而连接池减少了这些方面的开销,因此可显著提高数据库密集型应用程序的性能.
创建连接对象需要执行多项任务,例如网络通信、读取连接字符串、身份验证、事务登记以及内存分配等,所有这些都会占用时间和资源.
此外,因为这些连接都是事先创建好的,所以应用程序只需等待很少时间即可获得连接.
连接池通常会有一些属性用来优化自身的性能.
这些属性控制连接或连接池的行为,例如连接池内允许的最少和最多连接数,或一个连接在返回到连接池之前可保持为空闲状态的时间.
最佳配置的连接池能够使快速响应时间与维护连接池中的连接所占用的内存之间取得平衡.
通常需要尝试多种不同设置才能让一个特定应用程序达到最佳平衡.
此外,应用程序连接池的配置会因应用程序而异,因此可能无法用于其他应用程序.
有关详细信息,请参阅您的应用程序文档.
2.
数据库共享服务器在Oracle数据库共享服务器架构中,调度程序将多个传入网络会话请求导向一个共享服务器进程池,从而避免了为每个连接指定一个专用服务器进程的需求.
此池中的空闲共享服务器进程从公共队列中选择请求.
如果无法改变应用程序层,则可针对大量短请求和事务使用共享服务器架构,由此可显著减少进程总数.
有关使用Oracle数据库共享服务器架构的所有限制或具体指南,请查看您的应用程序文档.
在首次评估数据库共享服务器时,请查看以下文档并采用这些实践:Oracle数据库管理指南中中的"配置Oracle数据库以支持共享服务器"Oracle最高可用性架构Exadata数据库云服务器整合最佳实践18Oracle数据库性能调优指南中的"共享服务器和调度程序的性能考虑事项"最初每500个会话使用20-30个共享服务器,随后可进行调优(OracleNetServices最佳实践中的第44页幻灯片)最初每50-100个会话使用1个调度程序,然后可进行调优对于长时间运行的查询、报告任务、DataGuard传输以及管理用连接,请继续使用专用服务器.
您可始终混合使用共享服务器和专用服务器,当转变为使用数据库共享服务器时,这样做将非常有效.
在sqlnet.
ora文件中,进行如下设置,USE_ENHANCED_POLL=on(OracleNetServices最佳实践中的第46页幻灯片)3.
数据库驻留连接池(DRCP)—OracleDatabase11g中的新特性DRCP使用池化服务器,相当于将专用服务器进程(而不是共享服务器进程)和数据库会话相结合.
通过池化服务器模型,可避免为每个不需要长时间访问数据库的连接指定一个专用服务器进程.
从DRCP获取了连接的客户端将连接到被称为"连接代理"的Oracle后台进程.
连接代理实现DRCP池功能,并在客户端进程的入站连接中实现池化服务器的多路复用.
虽然DRCP比共享服务器更高效,但是它仍需要少量应用程序代码更改才能获取和释放会话.
请参阅OTN上的"数据库驻留连接池(DRCP)"白皮书,网址为http://www.
oracle.
com/us/products/database/oracledrcp11g-1-133381.
pdf.
有关使用DRCP的所有限制或具体指南,请查看您的应用程序文档.
11.
2.
3.
1或更高版本的Exadata软件最多可支持源自一个硬件池中的一个或多个数据库服务器的60,000个并发连接.
这意味着同时连接到一个Exadata单元并执行I/O操作的进程数不会超过60,000.
在Exadata11.
2.
2.
4.
版本中,此限制是32,000个连接.
而在Exadata11.
2.
2.
4之前,此限制是20,000个连接.
这里的上限目标取决于内存或CPU消耗,不过对于X2-2或X3-2,每个节点大约可容纳7,500个进程,而对于X2-8或X3-8,每个节点大约可容纳30,000个进程.
要计算每个硬件池的进程数,需通过以下命令查询包含OracleASM实例、数据库文件系统(DBFS)实例以及应用程序数据库在内的每个数据库:Oracle最高可用性架构Exadata数据库云服务器整合最佳实践19SQL>SELECTCOUNT(1)FROMGV$PROCESS;.
较高的进程数会导致内存分页,从而导致节点不稳定、CPU争用、数据库闩锁争用以及长时间应用程序故障切换或中断.
在增加进程数之前,进行测试非常重要.

可将Oracle监听器配置为限制传入连接数,以避免在数据库节点或实例出现故障后产生登录风暴.
通过OracleNetListener中的连接率限制器特性,数据库管理员(DBA)可以限制监听器处理的新连接的数量.
如果启用该特性,OracleNetListener会将监听器每秒处理的最大新连接数强制设定为用户指定的值.
根据配置,此连接率会应用到一组端点或一个特定端点.
通过以下两个listener.
ora配置参数控制此特性:CONNECTION_RATE_=number_of_connections_per_second设定所有受连接率限制的监听端点的总连接率.
如果指定了此参数,其优先级高于任何指定的端点级的连接率数值.
RATE_LIMIT表示某特定监听端点受连接率限制.
在监听器端点配置的ADDRESS部分指定此参数.
如果将RATE_LIMIT参数设定为大于0的值,则在该端点级实施连接率限制.
示例:限制新连接数以防止登录风暴.
APP_LSNR=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)(RATE_LIMIT=10))(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1522)(RATE_LIMIT=20))(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1523)))在上面示例中,在端点级实施了连接率限制.
端口1521每秒最多处理10个连接.
端口1522每秒处理的连接数限制为20.
端口1523处理的连接数没有限制.
如果超过设定的连接数,系统会记录一条TNS-01158错误消息:Internalconnectionlimitreachedislogged.
请参阅NetServices参考指南.
其他设置Exadata配置和参数的最佳实践已记录在MOS说明1274318.
1和1347995.
1中.
Oracle最高可用性架构Exadata数据库云服务器整合最佳实践20启动对系统的监视和检查需要通过EnterpriseManager、由自动负载信息库(AWR)收集的统计信息或针对ActiveDataGuard环境的ActiveDataGuardStatspack来监视和管理您的数据库和系统资源.
有关详细信息,请参阅以下文档:MOS说明1070954.
1中的ExachkOracleEnterpriseManager12c:OracleExadataDiscoveryCookbook中的"通过EnterpriseManager12c实现Exadata监视最佳实践"和MOS说明1110675.
1位于http://www.
oracle.
com/asr的"Exadata自动服务请求"MOS说明454848.
1中的"ActiveDataGuardstatspack"OracleClusterware管理和部署指南中的"集群运行情况监视".
资源管理OracleDatabaseResourceManager(简称ResourceManager))是一个对负载和数据库之间的系统资源进行精细控制的基础架构.
您可以使用ResourceManager管理CPU、磁盘I/O以及并行执行.
ResourceManager在以下两个不同场景下对您很有用:对于数据库内整合,该工具可用来管理应用程序间的资源使用和争用.
对于数据库间整合,该工具可用来管理数据库实例间的资源使用和争用.

将ResourceManager用于数据库内(模式)整合在数据库内(模式级)整合中,您可以使用ResourceManager控制应用程序如何在一个数据库内共享CPU、I/O和并行服务器.
它将依据数据库管理员指定的资源计划将资源分配给用户会话.
资源计划指定如何将资源分发给各资源用户组,资源用户组是按照资源需求对用户会话进行分组而形成的.
对于模式整合,通常需要为每个应用程序创建一个用户组.
资源计划指令将资源用户组和资源计划关联到一起,从而指定如何将CPU、I/O和并行服务器资源分配给用户组.
CPU资源管理另外一个优势是,可使关键的后台进程(例如LGWR、PMON和LMS)不会遇到资源缺乏的情况.
从而可提高OLTP负载的性能,并降低OracleRAC数据库实例被逐出的风险.
Oracle最高可用性架构Exadata数据库云服务器整合最佳实践21要管理每个应用程序的资源使用,必须配置并启用资源计划.
有关如何进行这些操作的详细信息,请参阅Oracle数据库管理员指南中的"使用OracleDatabaseResourceManager管理资源"、MAA白皮书"使用OracleDatabaseResourceManager",并可从MOS说明1339769.
1中获取设置示例脚本.
要管理每个应用程序的磁盘I/O,必须启用I/O资源管理(IORM).
用于管理CPU的资源计划也可用于管理磁盘I/O.
IORM以单元为单位管理Exadata单元的I/O资源.
只要I/O请求会导致单元磁盘过载,IORM就会依照已配置的资源计划对I/O请求进行调度.
IORM调度I/O请求的方法是,立即发出一些I/O请求,而让其他请求排队.
IORM根据资源计划中的资源分配来选择要发出的I/O请求:相对于那些获得较少资源分配的数据库和用户组,获得较多资源分配的数据库和用户组将得到更频繁的调度.
如果未达到单元的运行容量限制,IORM不会让I/O请求排队等候.
如果启用了IORM,它会自动管理后台I/O.
日志文件同步以及控制文件的读写等关键后台I/O的优先级较高,而非关键后台I/O的优先级较低.
将ResourceManager用于数据库整合ResourceManager可在两个方面对数据库整合提供帮助.
首先,ResourceManager可通过实例囚笼来帮助控制CPU使用和管理CPU争用.
其次,ResourceManager可通过IORM的数据库间资源计划来控制磁盘I/O使用和争用.
通过数据库间IORM计划,您可以对共享Exadata单元的多个数据库进行管理.
您可通过单元控制命令行界面(CellCLI)实用程序来配置数据库间IORM计划.
通过数据库间IORM计划,您可以对每个数据库的以下几方面做出规定:磁盘I/O资源分配:获得较多资源分配的数据库能够更快地发出磁盘I/O请求.
通过数据库资源计划指定数据库内各负载的资源分配.
如果未启用数据库资源计划,则数据库中的所有用户I/O请求都将得到平等对待.
但是后台I/O仍自动具有高优先级.
磁盘利用率限制:除了指定资源分配外,您还可以指定每个数据库的最高磁盘利用率.

例如,如果生产数据库OLTP和OLTP2共享Exadata存储,那么您可以为这两个数据库设置最高利用率限制.
通过设置数据库磁盘利用率限制,您能够获得更可预测的、一致的性能,而这在托管环境中通常很重要.
如果指定了最高利用率限制,数据库将无法使用超额容量.
同时,如果指定了最高利用率限制,磁盘就不会满负荷运行.
闪存缓存使用:自11.
2.
2.
3.
0起,在该版本和之后的Exadata软件中,IORM均支持闪存缓存管理.
可将ALTERIORMPLAN闪存缓存属性设置为"off",以防止数据库使用闪存缓存.
这样可将闪存缓存留给任务关键型数据库使用.
只有您确认该数据库对闪存缓存的使用影响了关键数据库对闪存缓存的命中率时,您才能禁用闪存缓存.
禁用闪存缓存Oracle最高可用性架构Exadata数据库云服务器整合最佳实践22会带来增加磁盘I/O负载这样的负面影响.
注意:在11.
2.
3.
1或更高版本的Exadata存储服务器软件中,数据库间IORM计划可以包含用于多达1023个数据库的指令,而在之前版本中,只包含用于31个数据库的指令.
可将未使用指令的所有数据库作为一个实体来管理.
按类资源管理是一个高级特性.
该特性允许您主要按照正在执行的任务的类别来分配资源.
例如,假设所有数据库都拥有三种负载:OLTP、报告和维护.
要根据这些负载类别分配I/O资源,您将使用按类资源管理特性.
请参阅"OracleExadata存储服务器软件用户指南"中的"关于按类资源管理".
本节重点介绍针对Exadata的关键整合实践.
有关全面Exadata资源管理的先决条件、最佳实践和补丁,请参阅OracleDatabaseResourceManager的主要说明(MOS说明1339769.
1).
管理一个硬件池中CPU和I/O资源的一些指导原则启用实例囚笼.
根据大小分析,为每个实例设置CPU_COUNT.
对于关键硬件池,请使用分区方法:(CPU_COUNT)总和selectto_char(begin_time,'HH24:MI')time,max(running_sessions_limit)cpu_count,sum(avg_running_sessions)avg_running_sessions,sum(avg_waiting_sessions)avg_waiting_sessionsfromv$rsrcmgrmetric_historygroupbybegin_timeorderbybegin_time;如果avg_running_sessions一直小于CPU_COUNT的值,那么您可以在不影响性能的条件下降低CPU_COUNT的值,而对于其他需要额外资源的实例,您可以增加CPU_COUNT的值.
Oracle最高可用性架构Exadata数据库云服务器整合最佳实践23如果avg_waiting_sessions一直大于CPU_COUNT的值,并且响应时间和吞吐量让人无法接受,您可以通过增大CPU_COUNT来改进性能(如果您有可用的CPU资源).
否则,可以考虑将此应用程序或数据库迁移到其他硬件池.
使用过度使用实例囚笼方法时,应对系统进行监视.
如果系统CPU运行队列大于9,则应考虑降低所有实例的CPU_COUNT总和.
使用MOS说明1337265.
1中的脚本监视I/O指标.
通过此脚本,可对数据库和用户组每分钟使用的磁盘和闪存指标进行监视.
还能监视每分钟的磁盘I/O延迟指标.
如果启用了IORM,还能提供对每分钟I/O限制指标的监视.
注意:对于高性能磁盘,每秒支持的I/O操作次数(IOPS)最高为300IOPS,而对于高容量磁盘,则为150IOPS.
使用高性能磁盘的Exadata单元支持的最大吞吐量约为1.
5-2.
0GB/秒,而使用高容量磁盘的Exadata单元的最大吞吐量则为1GB/秒.
I/O吞吐量问题的典型表现是:高I/O利用率(iostat命令中的%util参数)、高磁盘队列大小(iostat命令中的avgqu-sz参数)以及糟糕的响应时间、I/O延迟(通过iostat命令监视)和吞吐量.
调优以实现低延迟负载对于OLTP负载,低延迟极为重要.
请进行如下检查:1.
高缓冲区缓存命中率(>98%).
根据情况对缓冲区缓存进行相应调优.
2.
高闪存缓存命中率(>90%).
如果需要,将常用表保存在闪存缓存中.
3.
低磁盘利用率(云服务器整合最佳实践24案例1:OLTP数据库的整合此方案说明如何在三个关键OLTP数据库中分配I/O资源以及如何在Exadata数据库云服务器X3-2上配置实例囚笼.
通常,我们建议使用简单的单级资源计划.
除了指定资源分配外,以下资源计划根据其他数据库的负载情况,使用I/O限制指令将金级数据库的I/O利用率限定为50%,而将银级数据库的I/O利用率限定为30%,以使得性能不会有太大变化.
当其他数据库空闲时,要允许每个数据库使用100%的磁盘资源,可删除此限制指令.
表4.
OLTP整合数据库名称说明级别资源分配限制CPU_COUNTOLTP-A金级数据库135508OLTP-B金级数据库135508OLTP-C银级数据库120306其他(任何其他数据库)110304ALTERIORMPLAN-dbplan=((name=oltp-a,level=1,allocation=35,limit=50),-(name=oltp-b,level=1,allocation=35,limit=50),-(name=oltp-c,level=1,allocation=20,limit=30),-(name=other,level=1,allocation=10,limit=30))要启用实例囚笼,需设置每个实例的cpu_count,然后再启用CPUResourceManager.
例如,可通过以下语句为OLTP_A实例启用实例囚笼:SQL>ALTERSYSTEMSETCPU_COUNT=8SCOPE=SPFILE;SQL>ALTERSYSTEMSETRESOURCE_MANAGER_PLAN='DEFAULT_PLAN'SID='*'SCOPE='BOTH';案例2:混合负载的整合此案例说明如何将OLTP负载的优先级设置为高于数据仓库负载的优先级,以保持I/O低延迟.
表5.
具有OLTP优先的混合整合数据库名称说明级别资源分配Oracle最高可用性架构Exadata数据库云服务器整合最佳实践25OLTP-A金级数据库150OLTP-B银级数据库120DW-X铜级数据仓库110DW-Y铜级数据仓库110其他(任何其他数据库)110因为OLTP数据库分配的资源比数据仓库数据库多,因此IORM会自动优化以实现低磁盘延迟.
要显式控制此目标,请使用ALTERIORMPLAN将此目标设置为"低延迟".
在混合负载环境中,IORM可将磁盘延迟降低到约15毫秒.
案例3:数据仓库的整合此案例说明如何在三个数据仓库数据库中分配I/O资源.
通常,我们建议使用简单的单级资源计划.
除了指定资源分配外,以下资源计划根据其他数据库的负载情况,使用I/O限制指令将金级数据库的I/O利用率限定为50%,而将铜级数据库的I/O利用率限定为20%,以使性能不会有太大变化.
在要求使用"按性能付费"模型的托管环境中,利用率限制非常有用.
表6.
数据仓库整合数据库名称说明级别资源分配限制DW-X金级数据库仓库14050DW-Y金级数据库仓库14050DW-Z铜级数据仓库11020其他(任何其他数据库)11050资源管理最佳实践要了解包含脚本及推荐的特用于实现有效资源管理的软件版本在内的最新的资源管理最佳实践,请参阅MOS说明1339769.
1.
维护和管理考虑事项Oracle软件和文件系统空间只保留少量活动的Oracle主目录版本,因为大量不同的数据库版本会增加维护复杂性.
还请记住,OracleGridInfrastructure软件版本必须大于等于Oracle数据库软件的最高版Oracle最高可用性架构Exadata数据库云服务器整合最佳实践26本.
只要可能,尽量使用共享的Oracle主目录,并保留固定数量的终端版本.
为确保根分区空间能够最大化以容纳所有Oracle主目录、OracleGridInfrastructure主目录以及各种日志目录,请执行以下操作:确保在选择首选操作系统后已回收磁盘空间.
请参阅"OracleExadata数据库云服务器所有者指南"中的"选择操作系统后回收磁盘空间"一节.
评估是否可以为非根分区(/u01)增加更多空间.
请参阅"OracleExadata数据库云服务器所有者指南"中的"调整LVM分区大小"一节.
有关分步说明,请参阅"如何扩展Exadata计算节点文件系统"(MOS说明1357457.
1).
通过cron管理审计文件目录的增长(MOS说明1298957.
1).
或者您可将日志目录和文件复制和移除到DBFS或外部NFS目录中.
安全性和管理角色如果一个硬件池中整合了多个数据库,则可能需要隔离某些数据库组件或功能,以便将管理和权限明确分开.
有关如何通过使用操作系统和数据库范围的安全功能来防止管理员或最终用户的未授权访问的详细说明,请参阅OracleExadata数据库云服务器整合:隔离数据库和角色白皮书.
注意:在Oracle11g中,每个存储网格最多允许有63个ASM磁盘组.
下图描述了如何利用一些与默认推荐的单DATA和RECO磁盘组配置不同的安全实践来限制访问权限.
Oracle最高可用性架构Exadata数据库云服务器整合最佳实践27图2.
用于访问限制的安全实践用于整合的ExadataMAAOracle最高可用性架构(MAA)与整合环境密切相关,在整合环境中,计划停机和意外停机产生的影响要比应用程序运行在单独系统上时大很多.
有关Exadata的通用最佳实践,请参阅OracleExadata数据库云服务器MAA最佳实践白皮书.
以下各节以整合环境为背景,重点讲述一些主要MAA建议.
业务关键应用程序的整合MAA环境由以下部分组成:生产硬件池备用池.
备用池是生产硬件池的精确同步副本,使用DataGuard来维护它.
根据生产硬件池的重要程度,它可能会拥有一个采用同步零数据丢失保护措施的本地备用池,还可能会拥有一个采用异步传输方式的远程备用池,以便能够提供地域保护,防止大范围的服务中断.
理想情况下,备用池的容量配置应与生产硬件池类似,以在需要故障切换时能够提供等同的服务级别.
您可以通过一些策略来有效利用处于备用角色的备用池.
有关详细信息,请参阅MAA白皮书:OracleExadata数据库云服务器的灾难恢复.
通过对备用数据库首先打补丁(请参阅MOS说明1265700.
1),可使用备用池来验证补丁和软件更改.
Oracle最高可用性架构Exadata数据库云服务器整合最佳实践28开发/测试硬件池,它们也非常重要,因为所有更改都应该先在开发和测试系统中进行验证,以便在正式应用时能最大限度保持生产硬件池和备用硬件池的稳定性和可用性.

图3.
Exadata的最高可用性架构:保护整合数据库环境最高可用性架构(图3)为整合环境提供以下高可用性功能:OracleRealApplicationClusters(RAC)—提供针对节点和实例故障的容错功能.
OracleASM和OracleExadata—提供针对各种存储故障的容错功能.
ActiveDataGuard—自动修复物理块损坏,防止备用池出现可能影响到主硬件池的数据损坏或服务中断,并且在个别数据库或整个硬件池因某些原因出现故障时支持快速故障切换以保持高可用性.
损坏检测、预防和自动修复最佳实践—在DataGuard配置中(MOS1302539.
1)Oracle最高可用性架构Exadata数据库云服务器整合最佳实践29Oracle联机补丁安装、OracleGridInfrastructure和OracleExadata单元滚动补丁安装、OracleRAC滚动维护、OracleDataGuard备用数据库先打补丁、OracleDataGuard"临时逻辑"数据库滚动升级以及OracleGoldenGate异构迁移和零停机维护—这些都最大限度减少或消除了计划维护所需的停机.
闪回技术,当出现逻辑损坏时,通过该技术可实现快速具体时间点恢复.
有关上述高可用性功能的最佳实践都记录在技术白皮书OracleExadata数据库云服务器MAA最佳实践中.
以下ExadataMAA操作实践对于实现整合数据库环境的高可用性目标来说也非常重要:1.
将高可用性服务级别协议文档化.
2.
验证不同服务中断的修复策略和滚动升级解决方案.
3.
定期测试并升级到MOS说明888828.
1中建议和传达的软件版本和补丁,并参考MOS说明1461240.
1中介绍的常规硬件和软件维护建议.
4.
遵循MOS说明1262380.
1中介绍的测试和修补实践,包括备用数据库先打补丁(MOS说明1265700.
1).
5.
在计划维护活动的前后运行最新版本的exachk实用软件(MOS说明1070954.
1),并且每个月至少运行一次.
6.
定期执行DataGuard角色转换,例如每6个月执行一次.
7.
配置Exadata监视功能、OracleConfigurationManager(OCM)以及自动服务请求最佳实践(MOS说明1110675.
1和1319476.
1).
8.
请参阅位于http://www.
oracle.
com/goto/maa的最新MAA最佳实践和白皮书.
也请参阅OracleExadata数据库云服务器MAA最佳实践技术白皮书中的通用ExadataMAA实践.
以下各节重点介绍数据库整合的其他ExadataMAA考虑事项.
打补丁和升级在最初配置Exadata硬件池中的软件时,请参阅MOS说明888828.
1以了解受支持的最新Exadata软件配置.
除了滚动升级情况之外,各Exadata单元的版本应相同.
所有数据库节点应使用相同的OracleGridInfrastructure软件版本,并且有一些节点共享Oracle数据库主目录.
Oracle最高可用性架构Exadata数据库云服务器整合最佳实践30在更新Oracle数据库软件版本时,最好按照异地打补丁和升级程序进行.
此方法尤其适用于数据库整合环境,因为这样做可以在不影响其余数据库的情况下将目标数据库迁移到新版本,而且如果出现意外性能问题,还能回退到上一版本.
您可以利用各种工具,例如针对数据库服务器使用OPlan和OPatch,而针对Exadata单元则使用patchmgr.
备份和恢复您的备份、还原和恢复策略不会随整合而改变.
首先应该清楚如何针对不同恢复情况使用备份,并清楚您预期的恢复时间目标(RTO)、恢复点目标(RPO)和备份时窗.
您的硬件池应包含具有相似高可用性要求的应用程序和数据库.
对于采用MAA硬件池架构的关键硬件池,可能会将备份用于数据库节点裸机恢复、应对双重灾难以及一些损坏或逻辑故障情况.
其次,您应该了解通过Exadata上基于磁盘的备份(在系统内部或通过Exadata存储扩展机架备份)或将备份存放到磁带上可以实现什么目标.
有关可能的备份和还原速率以及配置实践的相关信息,请参阅Exadata数据库云服务器的备份与恢复性能和最佳实践和使用SunZFS存储设备备份和恢复OracleExadata数据库云服务器时的备份与恢复性能以及最佳实践技术白皮书.
下一步您应该了解的是,备份和还原数据库与可用系统资源密切相关,尤其是以下资源:用于备份和还原的Exadata磁盘吞吐量网络带宽:InfiniBand用于基于Exadata的备份,外部网用于Exadata以外设备的基于磁盘的备份或磁带备份第三方I/O吞吐量:磁带吞吐量,用于基于磁带的备份;存储吞吐量,用于非Exadata存储目标.
你可以选择同时备份或还原一个或多个数据库.
瓶颈问题将可能由上述的一个元凶引起.

示例1:将全机架Exadata数据库云服务器备份到磁盘在本示例中,在使用高性能SAS磁盘的全机架Exadata数据库云服务器X2-2上有5个数据库.
所有数据库占用的空间总和约为50TB.
根据我们的MAA研究,当RMAN操作利用所有数据库节点,并且为每个数据库节点分配2到8个RMAN通道时,预计备份速率可高达20TB/小时.
您可能会选择限制备份速率,以确保在执行备份操作期间不会影响应用程序性能.
假设只使用1或2个RMAN通道,备份速率是10TB/小时,那么可在5个小时内备份完所有数据库.
可以选择一次只备份一个数据库,也可以选择同时备份多个数据库.
关键是将任务分配给所有节点,以便使得各数据库节点受到的影响是均衡的.
例如,可以针对两个不同数据库执行两个Oracle最高可用性架构Exadata数据库云服务器整合最佳实践31RMAN操作,其中一个备份服务利用数据库节点1-4,而第2个备份服务利用数据库节点5-8.
此组合方法实现的备份速率仍然是10TB/小时.
而使用我们推荐的增量备份方法,备份时间可缩短为不到1个小时.
示例2:将全机架Exadata数据库云服务器备份到磁带在本示例中,在使用高性能SAS磁盘的全机架Exadata数据库云服务器X2-8上有10个数据库.
这些数据库采用基于磁带的备份解决方案,以使DATA区域有更多可用空间.
所有数据库占用的空间总和约为100TB.
本示例提供2个介质服务器和16个磁带驱动器(例如速率为200MB/秒)磁带驱动器的数量以及它们的吞吐量是造成瓶颈的原因.
使用此基于磁带的基础架构,备份/还原吞吐量接近11TB/小时.
将备份服务任务分配给两个数据库节点,并为每个数据库节点分配8个RMAN通道.
根据备份集合的实际大小,整个100TB数据库的完整备份可在10小时内完成,而日常的累积增量备份可在2小时内完成.
此外,您还可以使用资源管理来排定不同备份和应用程序负载的优先级.