到这里为止，关于asm 的系列文章已经写了6篇，在这篇文章中将介绍Active Change Directory的结构。
何为ACD？大家如何把asm实例也看成一个微型的数据库实例的话，那么ACD信息，就好比是redo。换句话
将，ACD里面的信息，记录了asm的所有元数据block的操作记录。当然，有这个的好处是什么呢？

其实你可以想象，数据库实例中，如果实例crash掉，那么还可以借助redo去进行instance recover。
这里针对asm而已，ACD的功能有异曲同工之妙。

这里需要说明的是，每一个asm实例，都用有其自己的ACD目录，换句话讲，如果你是双节点的rac，那么就有84m的ACD 目录信息。
如下是来自的的vm 11gR2 rac环境信息：

我这是2个节点的rac，即有2个asm，所以这里file 3所占据的au extent为84个。

我们使用kfed来读取元数据，首先定位到active change directory 所在AU ：

从上面信息可以看出，ACD元数据和数据应该包含在其中一个AU 149中，如下：

通常来讲，一个block是元数据，而后面的block就是实际数据了。继续读取Active change directory data：

其他ACD 所在的AU也是一样，所以这里我以上面kfed的数据为例，进行剖析。首先我们先来看ACD 元数据.
我们可以看到，active change directory元数据，就2个部分；

我们接着来分解ACD data的结构，其结构主要分为如下部分:

上面有部分信息，我目前也不清楚具体的含义，只能猜测个大概。从上面我们所了解的信息来看，当asm实例
在对元数据进行变更以后，会将更改前的信息写入到ACD 数据中，而ACD data中记录了哪些数据呢？
主要是记录了这样一些数据：线程号，block号，opcode，sequences，记录长度等信息。

这样，当你处于运行的asm实例，突然crash后，那么重启asm实例以后，asm可以根据ACD信息去进行”instance recover”，
从而保证能够正常启动asm实例。

到这里，大家或许有个疑问，既然asm 中也有类似数据库实例的redo机制？那么是否存在类似undo的机制呢？后面会描述。

最后我们通过strace asm相关进程，来观察下相关的操作，已验证前面的提到的内容：

通过strace lgwr进程，你可以看到lgwr进行会更新ACD信息，通过上面的offset转换，你可以发现4194304其实就是au 4，
这就是说，lgwr进程更新了au 4，blk 0里面的信息，即就是ACD metadata。

如下是au 4，bllock 0在我进行操作前后的对比，通过resize 一个datafile离开进行观察：