ITPub博客

我们平时测试MySQL时，大多数时候都是使用的sysbench、tpcc-mysql等基准测试工具，现在，你可以尝试着使用hammerdb来对MySQL做一做基准测试，虽然hammerdb测试工具大多数时候我们听到的都是用于oracle测试。但却不失为一种选择。另外，前面提到过，hammerdb还支持olap场景的基准测试，大家有兴趣的可以试一试。

在本系列的第一篇文章中，我们看到了只有在直接路径加载、CTAS(create table as select)和"alter table move"时，基础表压缩机制才可以生效。同时当表启用了压缩时，Oracle会默认的将该表中数据块的pctfree设置为0，这也暗示了我们基础压缩应该作为一种只读数据的压缩策略。当我们查看一个对应块的dump文件时，会发现Oracle并不是“压缩”数据，他所做的是在每个块上创建重复值列表（即字典表），然后通过一些标志来代替那些重复值从而达到块级别的去重。并且，Oracle可以重新排列块中的字段顺序，从而增加用一个标志来代替多个字段的机会。这告诉我们，Oracle在读取块时并不需要“解压”数据，他需要做的仅仅是通过指针来重构数据，当然这是一个CPU密集型操作。

本文仅以RDS的视角，从三个层级讲述了对调度器的要求。真实的世界会更加复杂，比如针对Read Write Cluster，Slave 必须等待Master创建完毕，而Sharding Cluster，所有分片可以并发创建……在设计产品和完成编码的过程中，踩坑无数。不能否认的是，站在巨人的肩膀上可以让我们看的更远。

在这三种压缩技术中，索引压缩和基础表压缩是产品自带的核心组件，但是，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语句所需访问的所有对象（表和索引等）和系统有必要的描述信息。