Suppose you are a server process that is reading a row in a buffer. It would be extremely rude of someone to replace that specific buffer with another buffer while you were still accessing the row. It would be like you were reading a book, and someone saying, "Hey, let me see that!" and ripping it out of your hands. In fact, placing your hand on a book is a great picture of pinning a buffer. Whenever there is at least one hand on the book, then no other process can take the book away. Many processes can pin the same buffer (read the same book), but as long as one process has the buffer (the book) pinned, it cannot be replaced. When a free buffer's row is being queried, its status changes from free, to pinned, to free again. When a row in a free buffer is changed, its buffer status changes from free, to pinned, to dirty.

Oracle does not expose pinned buffers through v$bh, but any buffer that is touched has also been pinned. Oracle will also pin a buffer when it is being moved onto the write list and while updating its touch count (both discussed later in this chapter).

While buffers do reside in the buffer cache and buffers are indeed changed, list management acts on buffer headers, not the actual buffers. A buffer header is an optimized in-memory metastructure that contains information about a buffer and its associated block, but does not contain block data such as rows.