buffer cache —— enq: TC - contention

在手动执行检查点操作中，一部分需要获得TC锁（tablespace checkpoint lock）。在获得TC锁过程中，若发生争用，则需要等待enq: TC - contention事件。

enq: TC - contention等待即便在没有多个进程引起争用的情况下，也可以发生，这一点上与其他锁争用引起的等待现象不同。需要理解的是在等待现象中，存在只有争用才能引发的等待现象，但也存在不发生争用，也会单纯为了等待工作结束而等待的情况。

SQL> select name,parameter1,parameter2,parameter3 from v$event_name where name like 'enq: TC - contention';

NAME                           PARAMETER1           PARAMETER2           PARAMETER3
------------------------------ -------------------- -------------------- --------------------
enq: TC - contention           name|mode            checkpoint ID        0

enq: TC - contention等待发生的代表案例如下：

1、parallel query

parallel query（以下简称PQ）上，发生检查点的原因是slave session引起的direct path read。direct path read就是不经过高速缓冲区直接读取数据文件。slave session执行direct path read对象是数据文件。从数据文件上直接读取数据时，因为不经过SGA，所以可能发生当前SGA上的块和数据文件上的块之间版本不一致的现象。为防止这些现象，oracle对数据文件执行direct path read之前，应该执行检查点。coordinate session在驱动slave session之前，对于要执行direct path read的对象，请求段级别的检查点，检查点发生之前一直处于enq: TC - contention等待事件状态。coordinate session上可以发现enq: TC - contention等待，slave session上则可以发现direct path read等待。

2、tablespace hot backup

执行ALTER TABLESPACE ... BEGIN BACKUP后，将属于此表空间的所有高速缓冲区的脏块记录到磁盘上，这个过程经历enq: TC - contention等待。

TC锁争用引起的性能问题，不在于等待本身，而是在于人为执行检查点。假设，在混合系统上，每秒发生数百次以上事务的情况下，每秒执行数次以上的PQ。每次执行PQ时都会发生检查点。检查点不必要的过多发生时，DBWR上出现瓶颈，引发许多等待事件。考虑到这些，执行PQ时必须考虑相应系统和业务类型，只有在必须的时候使用。PQ引起的检查点，只影响执行PQ的对象。从这个方面看，它比一般检查点负荷少。
虽然是适用于oracle所有功能，但其中特别需要理解PQ是把双刃剑。PQ若能恰当使用，则可以将大量数据快速进行处理，特别是不经过SGA，因此能避免往高速缓冲区上载大量数据时的负面影响，这就是它的优点。但是从enq: TC - contention等待上可以得知，引发不必要的检查点，反而会对整个性能带来负面效果。