Oracleを使い続けている毎日。Oracleいいところもあれば、よくないところもまだまだありますね。

うちに会社でもRACを使っていたりしますけど、RACでスケールアウトっていうのも、そのまま信じちゃいけない感じですよね。基幹DBがRACであっても、非定形検索業務には業務に与えるインパクトが未知数っていうことで、非定形検索業務専用のDBなんかを作ったりしてますが、これの運用管理の負荷が割と無視できないんですよね。

それまで作ったツールの作り直しとかには手をかけられないので、基幹DBのテーブルレイアウトのまま持ってきちゃったから、データの同期をどうしようで少々悩むことに。

データ同期の方法にもいくつか手段があるものの、決定版っていうのがないのが現状のようです。

マテリアライズド・ビュー

比較的シンプル。マスタサイト側への負荷が割と無視できない。大きな表のいちばん最初の完全リフレッシュの際、いつも長時間待たされるのにドキドキする。しかも基幹DBのパフォーマンス不足により再作成を指示されることがしばしば。あんまりたくさんの表のリフレッシュをあまりに短い間隔で行うと、リモートサイト側のOracleが不安定になりやすい？うちだけの問題？個人的にはそろそろ縁を切りたいが、どうも無理らしい。

Data Guard　- Physical Standby

マスタ側のDBの複製をOracle自体の機能で作るというもの。データ構造などもすべて同一のものが複数出きるので、本来はディザスタリカバリー用。リモートサイト側はリードオンリーでオープンできるらしいが、非定形業務向けのインデックスが作成できないのが最大のネック。運用実績数も結構あるらしい。RAC環境のData Guardの場合、リモートサイト側にもRAC構築のライセンスが必要だそうで、完全にうちら馬鹿にされてます状態。

Data Guard - Logical Standby

Physical Standbyがデータファイルやその中身までそっくりさんを作り上げるのに対して、こちらはデータだけがそっくりさん。ファイルの配置やインデックスの作成なども自由にできるらしい。こちらは運用実績が少なく、リセラーさんは及び腰。なんかの理由で、うちでは使えないと判明。さよならに。

Streams

REDOログの情報をリモートサイトに転送する技術っぽい。REDOから追い出されてしまった過去の更新履歴はアーカイブログから取得の模様。うまくいけばいい感じだけど、マスタサイトがRACの場合、REDOログの転送に問題があるみたい。RACノードすべてのREDOログを送りつけるわけではなくて、稼働ノードローカルのREDOログ転送なので、そりゃ無理っぽいって感じ。アーカイブログだけ適用っていう手もあるそうですが、そんなに待っていられないってことに却下。

個人的には見てはいけないと今思う、ネティーザを見てしまったので、リアルタイムに近い同期なんてやめて、一日一回のバッチ取り込みにして、相手先をネティーザにしちゃうっていうのが最高にうれしいな。でもむりだろうなー。どうするべ。

OLAPをやるには元のDBからデータを抜く必要があるわけですが、この抜きと入れる手間が結構大変なもんなんですよね。 DBの構造にも依存すると思いますけど、うちの会社はあんまりやりやすいDBの構造じゃないですね。OLTP的にはUpdateなんでしょうけど、OLAP的にはInsertでどかすか入れてくれたほうが、後戻りのないデータが作れるんですよね。 OLAPをやるにはその辺から考えてくれれば、実現は簡単そうですよね。でもそこまで考えている基幹システムって世の中にどれぐらいあるのかしら？

OnLine Analytical Processing だったか？ SQLを書かずにデータ検索が行えると思っている人ばかりで、正直言って疲れる。そうじゃないんだよー。もっとマクロな視点でビジネスを捕らえるためのものでしかないんだよー。

データをもっと手軽に検索するテクノロジーは存在しないものなんだろうか? いつまでたっても非定型業務には、AccessとExcel相手ではOLAPへの誤解というか幻想は解かれることはない気がする。

OLAP、それはパフォーマンスとの戦い。はぁ。