LMSn-- Lock Monitor Services
LMS进程主要用来管理集群内数据块的访问，并在不同实例的BUFFER CACHE
中传输块镜像。
当在某个数据块上发生一致性读时，LMS负责回滚该数据块，并将它copy到请
求的实例上。
每个RAC节点至少有2个LMS进程。
也称作 GCS (Global Cache Services) processes.
GC Read Committed Block
当一个实例去读取另外一个实例上面的数据块可能有几种情况，一种是去读取的数据块已经提交了，还有一种可能是数据块没有提交，这两种机制上有一些区别。
全局内存要去请求一个一个已经提交的数据块，一种可能是提交的数据块在磁盘上面，要修改数据的时候先产生undo，保存一个之前的值，之后要把要修改的数据块从磁盘上面读取到内存里面，一直修改到205的时候在22:09提交了提交之后将数据刷到磁盘上面了，比如发生了一次checkpoint，这个实例1来读取这个数据块，这个时候就简单了，就之间从磁盘里面读到内存上面就行了。
GC Read Committed Block
如果要读取的数据块在内存里面，这样就有许多差别，还是和之前一样在实例2上面对数据块做修改操作，修改完之后提交了，一旦提交就证明这个数据修改完成了，此时此刻这个修改了的值对别人来说是可见的，如果另外的人在查这条记录的时候这个值是205了，因为提交了，实例1上面要查询该记录。这个时候就实例就要去请求一个锁，这个就是resource master，即LMS这个后台进程，实例1从这个后台进程请求一个锁之后，获得访问该数据块的资源了就可以直接将数据块传输到实例1上面了。
GC Read Uncommitted Block
如果在实例2上面修改的数据还没提交，那么意味着其他用户是看不到修改的数据块的，看到的还是最早的那个值，如果数据还在内存里面，一直修改数据到205之后，这个时候实例1来查询，获得的结果是199，因为中间的修改都没有提交，这几次中间的修改意味着其他会话是看不到的。
实例1开始去读取该数据块，首先获得一个锁资源，这个数据块要在本地做一复制，实例1在读取的时候就要发生一致性读，无论某个用户对数据修改了多少次，只要没有提交用户就没法看到当前的值，所以尽管是205，但是看到的是199，这个时候实例2要通过回滚段里面的信息一直回滚，回顾到199，一一次应用回滚段的信息，回顾到最早的时候的值再将该值拷贝到实例1上面。这个时候就是实例1应该看到的199的值。
这个和RAC没有关系，这个就是一致性读的机制。一个会话去读取另外一个会话修改数据的时候，它只能看到自己会话应该看到的状态。
GC Read Uncommitted Block
要读取的时候未提交，但是写到磁盘上面了，在实例2上面修改到205之后有一次check point发生，这个时候写到磁盘上面了，这个时候实例1要读取该数据，就要从磁盘上面读出来了，按照一致性读的时候，实例1从磁盘上读取会发现数据还没有提交，尽管数据块上面有数据1而且是205，这个时候因为发现没有提交就要去构造该数据，这个时候就要使用undo来构造，undo数据块还在实例2上面，这个时候实例1将undo数据块从实例2上面复制过去，然后再透过undo的数据一个一个应用，一个一个rollback，直到回退到199。