In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-16 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >
Share
Shulou(Shulou.com)06/01 Report--
gc cr disk read event
When the block that node 1 needs to read is in the buffer cache of node 2, and the block contains transactions that have not yet been committed, then the LMS process of node 2 needs to use undo record to roll back the block to the content of node 1 at the time when it was initiated, and then send it to node 1. If the undo block where the undo record is located is not in the buffer cache of node 2 at this time, the gc cr disk read event will appear on node 1, indicating that node 1 is waiting for the LMS of node 2 to grant it permission to directly read the undo block from disk.
gc current block 2-way
There is no block A in the buffer cache of node 1 and node 2. In this case, node 1 reads a row in a certain block A, and then node 2 also reads block A or performs a DML operation on a row in block A. In both cases,"gc current block 2-way" will appear on node 2. Current here indicates that the block version read or modified by node 2 is the latest, and there are no uncommitted transactions in this block. It is worth noting that after the "gc current block 2-way" event occurs, GRD will lock KJUSERPR(read operation) or KJUSEREX (write operation) on the block.
gc cr block 2-way
Break it down. There are two situations.
(1)Node 1 modified the record but did not commit:
There is no block A in the buffer cache of node 1 and node 2. At this time, node 1 modifies a line in block A, but does not commit it. Then node 2 executes the Select block A operation. According to the definition of consistent reading, node 2 should receive the snapshot block A'corresponding to block A at the time when select is initiated. Block A' will be constructed by the LMS process on node 1 in the way of applying undo record to block A and then transmitted to node 2. At this time, a "gc cr block 2-way" waiting event occurs on node 2. Block A'received by node 2 is marked as cr type in buffer cache. Block of cr type only meets the needs of the current query and cannot be reused by subsequent queries. That is to say, if node 2 only initiates a select operation for block A again, LMS process on node 1 will reconstruct a block A''and pass it to node 2. Even though block A'' and block A'are exactly the same. This feature determines that cr blocks do not require any locks to protect them in the GRD during construction and transmission.
(2), node 1 modified the record and submitted:
There is no block A in the buffer cache of node 1 and node 2. At this time, node 1 has modified a line in block A and has already committed it. Because of the_fairness_threshold parameter, when node 2 performs the Select block A operation, it is still possible to trigger the LMS process on node 1 to construct a cr block and then transmit it to node 2. Node 2 will encounter gc cr block 2-way waiting.
It is worth mentioning that whether it is gc cr block 2-way or gc current block 2-way, their appearance does not mean that RAC performance problems occur. It can be considered as a waiting event of message type, which only indicates that there is block transmission between two nodes. However, if it is found that these two waiting events take a long time (>10ms) on average in AWR, it can be considered that there is a bottleneck on the network and it is necessary to contact the network administrator for intervention.
gc current block busy
When node 1 is updating block A, node 2 also initiates an update to block A. At this time, node 2 waits for the LMS process on node 1 to construct the block image of block A at the time when node 2 initiates the update. Node 2 will be in the gc current block busy state before receiving the block A image.
gc cr block busy
When node 1 is updating block A, node 2 initiates a query for block A. At this time, node 2 is waiting to receive the LMS process on node 1 to construct the block image of block A at the time when node 2 initiates the query. Node 2 will be in the gc cr block busy state before receiving the block A image.
gc buffer busy acquire
Both buffer caches of instance 1 and instance 2 contain a block. Instance 1 modifies this block at time T1. Session 1 on instance 2 reads this block at time T2. When this reading is not completed, Session 2 on instance 2 also initiates the operation of reading the same block. At this time, Session 2 will wait on gc buffer busy acquire. Example 2 The more simultaneous sessions that read the same block, the easier it is to observe gc buffer busy acquire waiting.
gc buffer busy release
When session#1 tries to request access to the local instance buffer, it finds that session#2 of the remote instance has requested access to the buffer before, and it has not completed, so session#1 waits for gc buffer busy release.
Prepared from:
How are those familiar global cache wait events triggered (1)
http://blog.itpub.net/53956/viewspace-2125576/
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.