お手製パーティションテーブルと分散データベース２

　分かりにくくてすみませんでした。

　元記事のようなシステムを想定していました。
　RACは使わず1億〜10億レコードになって、スケーラビリティをできる限り確保したい。
　TAT 1秒ぐらいで、基本は常に少量のデータのみにアクセスする。
　たまに、パーティションを横断検索する。← 元記事ではなさそうですが私が付加した条件

　つまり、基本は複数のパーティションにまたがる検索はシステム要件として起きない。もし、複数のパーティションにまたがっても動く。という条件で考えています。

　SELECT文を動的生成していて、指定された条件がお手製のパーティションテーブルを跨がなければ、UNION ALL は起きない（起こさない）ので、そう悪いアクセスパスにもなりませんし、チューニングは比較的簡単です。

　分割してしまっているのでフルアクセスは当然遅いですが、OLT的なシステムであれば LinkDB を使っても十分に動くはずです。

> パーティショニング対象テーブル数が多いと、作業工数がそれだけかかり、総費用では損するかも。

　仰るとおりですね。２つ、３つぐらいが限界じゃないかと想定していますが、元記事も1億レコードに達するテーブルはいくつもないでしょう。

　私がよくやるのが、パイプライン表関数の最後の引数にフラグを追加。

　フラグがFALSE（0）で、パーティションが複数に分かれるときや、パラメータの範囲が広すぎる、指定が少ないと判断したとき、

　RAISE_APPLICATION_ERROR で '抽出に時間が掛かる可能性がありますがよろしいですか？'というようなエラーを起こします。

　ユーザに条件を確認させて、同じ条件を望んでいるなら（メッセージに「Yes」ボタンを押下したとき）プログラムからフラグを立てて、もう一度実行する。もちろん、設計時に時間が掛かると認識しているときは、最初からフラグを立てて実行する。

　こういった、制御もパイプライン表関数で吸収することが可能なので、パーティショニング対象テーブル数が少なければ利用できるでしょう。

SQLer 生島勘富のブログ