ITPub博客

在这三种压缩技术中，索引压缩和基础表压缩是产品自带的核心组件，但是，OLTP压缩需要独立的“Advanced Compression Option (ACO)” license授权。再第一篇文章中，我们先用基础表压缩造一些数据，把对数据更新删除的问题留到第二篇文章中，最后基于前两篇的铺垫，我们再研究下OLTP的压缩。索引压缩单独留在第四、第五篇中探讨。

在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。

前些天某客户反馈一个诡异的问题，一个MySQL实例一会可访问，一会不可访问，查看相关日志发现该实例反复执行高可用切换，在进行初略排查时，通过监控发现服务器故障时刻磁盘负载都较高，但是并没有完全用满。而在高可用切换之前，数据库中跑着一些insert…select语句和大量心跳检测语句，而心跳检测语句与业务表是独立的，且心跳检测语句只固定更新一行数据，怎么会被阻塞一堆心跳检测语句呢 ？经过了一番折腾总算把原因找到了，具体过程请看下文！

在上一篇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中。

1、首先介绍了Redo，Undo，Log Sequence Number (LSN)，Checkpoint，Rollback Pointer (ROLL_PTR)，Transaction ID (TRX_ID)，Transaction Serialization Number(TRX_NO) 是什么？2、然后介绍了MySQL Update过程中发生了什么？Redo,Undo,双写之间如何配合，脏页何时刷新？3、最后介绍了Crash Recovery时如何做恢复？

在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语句所需访问的所有对象（表和索引等）和系统有必要的描述信息。

我们都知道在MySQL搭建复制环境的时候，需要设置每个server的server_id不一致，如果主库与从库的server_id一致，那么复制会失败。但是最近在解决一个客户的问题的时候，遇到一个有意思的现象，客户环境有三台数据库服务器，一主两从，客户的两台从库设置了相同server_id，在排查问题的过程中，查看MySQL错误日志，发现有很多奇怪的信息。 我们模拟了客户的环境，并进行测试、分析，最终在代码中找到了我们想要的答案。下面就是我们测试、分析、总结的步骤以及内容。

当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做起。