buffer cache和log buffer都是以块大小为单位分配的，buffer cache的块单位大小可以为2k，4k，8k，16，32k，但并不是所有的平台都能支持这五种块大小TBS。

buffer cache是数据块在内存中的隐射，几乎所有的对数据的I/O操作都要经过buffer cache(有例外，比如直接路径读写)。对于buffer cache，如果我们期望有更深入的理解，只需要回答两个问题：1）如果需要读的buffer已经加载在buffer cache中了，如何最快的定位这个内存块；2）如果需要读的数据块不在buffer cache中，如何最快的找到空闲的buffer cache块，并把数据加载到buffer cache。

log buffer同样也是以块大小作为I/O单位，但是这个块大小通常与OS块大小一致，512bytes。这里就有一个很有意思的问题，假设一个commit操作，log buffer中只有100bytes的内容，写到log file后，所写的这个块所剩下的空间会不会留着下一次写的时候继续填满？答案是否定的，这也就是为什么Oracle有redo wastage。

我们经常听说坏块，但这个坏块通常局限于数据块坏块，而极少听说（至少我没有听说过）日志文件坏块。而这得益于日志文件通常和OS块大小一致。为什么说通常，因为从11g开始，Oracle开始支持指定块大小的log file(512bytes,2k,4k)。

SQL执行过程的第一步是，语法分析，然后是语义分析。语法分析无需赘言。那什么是语义分析？拿"select empno,ename from emp“来说吧，我们需要确认emp这个对象是否存在，如果存在，SQL的执行这是否有权限访问这个对象(或者这个对象的部分数据)，emp这个对象，是否有empno,ename这个两个列。那关于对象，权限的描述在哪里？在数据字典中，因此，我们在shared pool中看到了dictionary cache(row cache)。

shared pool中的另一个重要结构是library cache。library cache所使用的结构和算法与buffer cache的结构和算法非常的类似。需要回答的问题也雷同。1）如果SQL被执行过(共享)，如何最快的定位这个SQL所共享的信息；2）如果这个SQL没有被执行过，如何最快的分配内存资源，并加载这个SQL的相关信息到内存中。

思考：假设，有一个表，有两行记录，两行记录在同一个数据块内。现在，A用户修改第一行记录的同时，注意是同时，B用户尝试修改第二行记录，请问，这个两个操作是否会”打架“？

-- 待续