ITPub博客

在12c的CDB中，我们知道每个PDB都是独立的。但这些PDB为了能整合到一个CDB里，会共享一些公共资源。例如，CPU、内存、redo和undo。他们都被实例在CDB级别进行管理。对于数据来说，共享公共资源也很简单，因为PDB有自己独立的表空间，而且，可插拔特性仅仅是可传输表空间技术的一种拓展。

导语：“你不是不够好，你只是过时了”这句话用到 IT 行业特别合适，每隔一段时间都会有新的技术出现, 让码农们应接不暇。借着回顾DBA工作中的几个时期，跟大家分享我们对下一代数据库运维架构的理解和目前正在做的工作。

ASM中有部分的命令提供了force选项，它允许管理员不以默认的行为来做某些操作。在一些操作上使用force选项是十分安全且必要的，但一些操作上去使用就可能会致使磁盘组不可用，本文会针对具体的情况做详细说明。

ASM Metadata Dump Utility，即ASM元数据导出工具，它的简写amdu更被人所熟知，常被Oracle技术支持人员和Oracle开发人员用来诊断和解决ASM故障。它能输出ASM的元数据信息并且从ASM磁盘组中抽取元数据和数据文件。 amdu工具不依赖于ASM实例或者ASM磁盘组的状态，所以它能在ASM实例关闭和磁盘组未挂载的情况下正常使用，它甚至能在ASM磁盘出现故障或者不可见的场景下使用。

当一个ASM磁盘不可用时，ASM会把它从磁盘组里移除，对吗？要看情况，通常取决于ASM版本和磁盘组的冗余级别。因为一个external冗余的磁盘组会直接被dismount，所以主要关注normal和high冗余磁盘组的情况。ASM 10g版本，磁盘会被直接drop。

Application seed与CDB中的PDB$SEED类似，在使用Application seed做为Application PDBs的创建模板时，你可以快速且容易的创建一个满足要求的Application PDB，Application Container中最多只能创建一个Application seed，当然也可不包含Application seed。

在上一篇Oracle 12c R2版本 Application Containers 特性(一)中讲解了Application Root/PDBs的创建以及“Application”的维护，本篇将介绍“Application Common Objects”，即公共对象。公共对象是用户在Application Container特性下创建的共享对象，且只能创建在Application Root中，共享给Application PDB，其有三种类型可共选择，分别为：METADATA-LINKED、DATA-LINKED、EXTENDED DATA-LINKED.

在Application Container特性下还有另一个概念，被命名为“Application”，我们可以把“Application”理解为一个区域，“Application”只能创建在Application root中，其内可以创建表、视图、函数等公共对象，然后可在Application PDBs中使用sync同步命令，来实现“Application”内的公共对象共享到Application PDBs中。

在12.2之前的版本，我们根本没有办法控制一个单独的PDB能使用的内存总量。导致的结果就是“一个糟糕的邻居”可能占用大量内存从而导致同一个实例下其他PDB的性能下降。在Oracle 12.2中，你可以控制某单个PDB能使用的内存总量。

Flex ASM磁盘组继续让我惊叹。使用文件组，我可以单独为任意实体（non-CDB, CDB, PDB）定义属性，而且可以在磁盘组内部进行更细粒度的数据保护模式设置。在12c之前的版本，虽然我也可以完成同样的任务，但是操作要复杂很多很多。不得不承认，Flex磁盘组确实相当flexible。

虽然优化器需要准确的统计信息来选择最优的执行计划，但是有些场景下，收集统计信息比较困难，或消耗资源较高，或收集统计信息不能及时完成，那么就需要另一种备选策略。不稳定的表

本专题的上一部分中，我介绍了Flex ASM Diskgroup的两个相关概念，配额组和文件组。但配额组的配额是否真的写多少就是多少呢？（还是超出个百分之多少也没关系）我对此非常好奇。幸运的是，我又发现了12c ASM相关的值得写博客跟大家分享的一些点，所以：这并不是本专题的最后一章这篇文章可能比前两篇稍短（因为把这篇文章和我想写的下一篇文章结合在一起真的太长了......）

为了选择最佳执行计划，优化器必须可以获得有代表性的统计信息。有代表性的统计数据不必是最新的，而是一组能够帮助优化器确定执行计划中每个操作所能返回的行数。

Oracle优化器会为SQL语句产生所有可能的访问路径（执行计划），然后从中选择一条COST值最低的执行路径，这个cost值是指oracle估算执行SQL所消耗的资源。为了让优化器能够精确计算的每一条执行计划的COST值，这就需要被执行SQL语句所需访问的所有对象（表和索引等）和系统有必要的描述信息。

当Flex Diskgroup挂载之后，下一步就是创建一些新的实体（这里的实体指文件组和配额组等）了。首先，需要创建配额组（quota group），顾名思义，配额组可以给组内的实体设定配额（存储空间上限）。你可以选择自己根据自己的需求创建一个配额组，当然也可以不创建，因为Oracle会默认为你创建一个没有存储上限的默认配额组。稍后你将看到，默认配额组将被分配给这个Flex Diskgroup中所有新建的数据库。

笔者上一篇译文中在介绍Leaf Node时提到，**虽然leaf node不要求直接访问共享存储，但最好还是连上共享存储，因为说不准未来哪天就要把这个leaf node转为hub node使用。**其实这样的说法并不够准确，在12cR1时，leaf node上是无法运行只读数据库实例的，这时不连接共享存储完全不影响其使用。而12cR2的leaf node是可以运行只读数据库实例的，一旦leaf node上有了数据库，这时leaf node（确切的说这时leaf node应该叫做reader node）就必须连接共享存储了。这次就介绍下如何将节点的角色在hub node和leaf node之间互相转换。由于笔者实验环境中已经存在了一个leaf node，所以先从leaf node转为hub node做起。

Oracle 在12c中使用hub-and-spoken技术实现了Flex Cluster的功能(即RAC集群中的每个节点不再需要既运行ASM实例又运行DB实例，各节点可以扮演不同的角色)。相比12c以前的版本，该功能使集群规模的扩大和缩减变得更加靠谱。

近几年来，股市的跌宕起伏和井喷行情，给各大券商的业务系统带来巨大压力，其IT 系统面临前所未有的挑战。为应对日益增长的行情和业务需求，并通过信息技术的升级带动业务创新，打造差异化竞争力，证券公司均不断加强对 IT 系统的新建和改造的投入。目前，证券公司诸多关键业务和应用系统均运行在IOE（IBM 为代表的小型机、Oracle数据库、EMC为代表的集中式存储）架构的系统平台上，在应对突发实时交易流量暴增、保障系统高可用、提升移动互联网化的用户体验、满足行业监管要求等方面，原有的IOE基础架构平台面临着诸多不足。

当数据库出现严重的性能问题或者hang?的时候，我们非常需要通过systemstate dump来知道进程在做?么，在等待?么，谁是资源的持有者，谁阻塞了别人。

在我的课上一个经常被问到的问题是ASM如何计算磁盘组REQUIRED_MIRROR_FREE_MB和USABLE_FILE_MB的值，这个问题的答案跟很多复杂问题的答案一样：要看情况。简单来说，视图V$ASM_DISKGROUP中的REQUIRED_MIRROR_FREE_MB值代表了如果ASM磁盘或ASM磁盘组出现了故障，要重新满足冗余度的定义，要求有多少的空闲空间。USABLE_FILE_MB的值代表了在满足冗余度之后，还有多少的剩余空间可以用。