刑務所長は面食らった。看守は1度に1人の囚人にしか対応してはならず、しかも、それは5丁の銃の1丁を持っている場合に限られるからだ。彼は尋ねた。「看守を増やして銃は増やさないんですか」。高給取りのコンサルタントは、「そうです」とだけ答えた。

　刑務所長はすっかり困惑して、コンサルタントに疑問をぶつけた。「そんなばかな。たとえ囚人1人につき1人の看守を雇ったとしても、銃は5丁しかありません。銃がなければ、看守は囚人に対応できないんですよ」

　高給取りのコンサルタントは、悠然と長いキューバ葉巻を取り出して火をつけ、ゆっくり2～3服吹かすと、おもむろに言った。「確かにそうです。現状では、もし看守が担当している囚人のうち、2人の『世話』が必要になったら、看守はその1人の世話しかできず、もう1人は放置されることになります。ですが、看守を増やせば、銃を持った看守が、世話が必要な囚人に対応できる確率が上がります」

　刑務所長はコンサルタントの知恵に舌を巻き、こう言った。「なるほど。今は、看守が20人の囚人のうち1人に対応していたら、ほかにもう1人を相手にすることはできません。しかし、看守を増やせば、看守の1人が（銃を持って）1人の囚人に対応していても、別の看守が（同じく銃を持って）もう1人の囚人に対応できるわけですね」

　こうして問題は解決され、高給取りのコンサルタントは、たっぷりボーナスを受け取った。

　では、以上の話が、Oracleのラッチングとどのように関連しているかを見ていこう。この話のそれぞれの銃はCPUを、それぞれの看守はラッチを、それぞれの囚人はメモリ構造（例えば、キャッシュバッファチェーンの1つなど）を表している。この話では、5丁の銃（CPU）しか使用できないのは確かだが、この5丁の銃を、任意の囚人、つまりメモリ構造（例えば、ハッシュバケットチェーンの1つなど）に可能な限り迅速に割り当てるというところがミソだ。

　Oracleでは、1つのラッチでメモリ構造の複数の部分（例えば、複数のキャッシュバッファチェーンなど）がカバーされることが多い。これは、2つのプロセスが、近接したメモリ構造にアクセスする必要があっても、1つのラッチで両方がカバーされているため、アクセスできないということを意味する。この問題の1つの解決策は、ラッチの数がCPUの数を大幅に上回るとしても、ラッチを増やすことだ。一般に、メモリ構造の数に対するラッチの数の比率を、1に近づけるのがよいと考えられている。そうすることで、任意のメモリ構造についてラッチが使用可能になる可能性が高まる。高給取りのコンサルタントが、銃が5丁しかないと分かっていても、看守の増員を提案したのはそのためだ。

　具体的な例で言えば、ラッチをCPUの数より大幅に増やすのが効果的な場合の1つとして、キャッシュバッファチェーンラッチの場合がある。手短に説明しよう。

　詳細は省くが、Oracleが「このブロックはバッファキャッシュにあるか」と問い合わせると、キャッシュバッファチェーンの1つにこの問い合わせが送られる。このチェーンを対象に順次検索が行われ、正しいバッファが探される。Oracle 9から、チェーンの数はブロックバッファの数の2倍強となっている。

　キャッシュバッファチェーン（CBC）ラッチの数は、構成可能なインスタンスパラメータだ。各CBCラッチは、1つ以上のキャッシュバッファチェーンを保護する。つまり、カーネルコードは、特定のチェーンにアクセスする前に、そのチェーンをカバーする特定のCBCラッチを取得しなければならない。Oracle 9から、1つのCBCラッチは、場合によっては700以上のキャッシュバッファチェーンをカバーするようになった。複数のプロセスが、同じCBCラッチで保護されている1つ以上のチェーンにアクセスしようとすると、CBCラッチ競合が発生する。その解決策の候補の1つ（ほかにもたくさんある）が、CBCラッチを増やすことだ。

　なぜか。ラッチを増やせば、1つのラッチが保護するチェーンの数が減るため、取得しなければならないラッチを取得できる可能性が大きくなるからだ。実のところ、この一般的な解決策は、CPUの数に着目したものではない。複数のプロセスが同じラッチを要求する可能性を減らすという発想に基づいているのである。

　従って、Oracleのプロセスは、CPUの数より多くのCBCラッチを要求しないかもしれないが、CBCラッチをCPUの数より増やすのは、非常にいいアイデアだ。

　以上の説明が参考になるとともに、Oracleの内部の仕組みに改めて関心を持っていただくきっかけになれば幸いだ。

本稿筆者のクレイグ・シャラハマー氏は、IT業界で18年以上の経験を持つ。オラパブの社長として、Oracleベースのシステムの包括的なパフォーマンス最適化（事前および事後の）を実践し、その方法を教育することで、Oracleパフォーマンス管理者を支援することを目指している。同氏は教育コースの開発、提供に加えてコンサルタントの仕事もしている。コンサルタントとして、画期的なパフォーマンス管理製品の開発にかかわった経験を持つほか、Oracleに関する書籍の出版や技術レビュー記事の執筆、さまざまなOracleカンファレンスでの基調講演を行っている。