これも順次動きを追って、見ていきたい。競合その1]まず、CRブロックは、「単一サーバ」、「単一セッション」の場合でも作成された通り、全件検索でのUPDATEで作られるブロックである。SCURはセグメントヘッダで、このヘッダの更新は行っていないので、共有のカレント・ブロックとなっている。それに対して、データ・ブロックは更新をおこなっているので、排他のカレント・ブロック(XCUR)となっている。一方のノード(NODE2)からSELECT(Read)を行う。競合その2]まず、両ノードでのSCURブロックを見て欲しい。セグメントヘッダへの更新は行われていないので、共有のカレント・ブロックを両ノードで保持している状態である。次に両ノードでCRブロックがあるのが分かる。成され作成されたCRブロックがNODE2へ転送されている状態である。このあとは何度、NODE2からSELECTを行っても、上記と同様に以下のCRブロックの転送を繰り返す。Second)を表示する。1ブロックに対してアクセスを行う検証を行っているので、100%競合が発生している状態である。正確な値とは言えないが、どの程度パフォーマンスが低下するかの目安として欲しい。トランザクション数は各ノードとも1セッションである。処理性能の相対評価の指針として使用している。◇同一の位置ブロックに対して以下の処理を行う。評価の基準となる、EPS値を取得した所以下の様になった。416******************************************競合させた場合のEPS値である。192[0.46]******************************************Read/Readでの競合では全くレスポンスの悪化はなく、やはり、書込み処理が入った競合で、レスポンスの悪化が見られる。ロックダウンやCRブロックの作成ブロックの転送の負荷が大きく影響していると言える次回はWrite/Writeの競合を見ていきたい。reserved.トップページ企業概要プライバシーポリシ。