スマートスキャンの結果不正に遭遇

世の中10連休であるが、ほとんどExa19cへのアップグレードで費やしてしまった自分にとって、もはや改元とかなにか遠い世界のことのように過ぎ去ってしまった。この話は別に書くこととし、今回はExadataの結果不正に遭遇した話をしたい。

さて、最近、業務TmからIS NOT NULLを条件指定したSQLの結果にNULL列が含まれているという問い合わせがあった。SQLを見てみると、以下のようにとてもシンプルなSELECT文（もちろん実際はテーブルはemp表ではないが）

　select * from emp where job is not null

まさかと思い、自分で実行してみると確かに結果にjob列がNULLの行が含まれていた。確かに（1行だけであったが）NULLの行が入っていた。autotraceとって見ると、predicateにstorageが出ていたので、ストレージサーバへのオフロード（スマートスキャン）が走っていそうだった。SQLトレースで見たところ、確かにスマートスキャンが走っていた。そこで、試しにcell_offload_processingをfalseにして実行してみたところ、なんとNULLの行が消え、あるべき結果となった。スマートスキャンの挙動がおかしいのである。

サポートに確認したところ、ESS(Exadata Storage Server Software)の不具合であることが判明。条件はスマートスキャン、IS NOT NULL、行連鎖が発生していること。実際にこのテーブルは255カラム以上だったので、INSERT時に行連鎖が発生する。

なぜ行連鎖がこの不具合の挙動に関係するのか？本来このような行連鎖ブロックはスマートスキャンにはならず、DBサーバへブロックをそのまま返却し、DBサーバ側でfilter処理を行うべきものである。おそらく不具合はここの挙動が正常に動かなかったことによると考えられる。

ちなみにこの不具合、既にパッチ、というかESSの特定のバージョン以上で修正されているため、ESSを最新にすれば防ぐことができる。運よく、今回のGWでたまたまESSバージョンアップを予定していたので、19.2.0にしたらこの事象は発生しなくなった。

今回は開発中に検出できたのでまだ良かったが、この手の不具合は運用中に検出したら結構痛い。ストレージサーバ側のオフロード機能が充実するのは嬉しいことではあるが、不具合の確率も高まることは避けられない。不具合に遭遇して調べると、多くの場合は既知不具合でパッチも用意されていたりするのである。その意味でESS（だけではないが）のバージョンはなるべく新しくしておきたい。また、停止の影響を局所化する上でもベンダには個別パッチ提供を引き続きお願いしたいところである。

なお、スマートスキャンの結果不正については、以下のドキュメントに解析に必要なログ取得方法が記載されている。SQLをいくつかの初期化パラメータ（上記のcell_offload_processing含め）を変更しながらSQLを実行するものと、結果不正となった行のブロックダンプを取得するものである。使うことがないに越したことはないが、Exadataを扱うDBAとしては、このようなドキュメントがあることは知っておいたほうが良いかもしれない。

Exadata: How to diagnose smart scan and wrong results (ドキュメントID 1260804.1)

以上