USO800

[Hibernate] O/Rマッパーって、ほんとに必要？

Oakbow — Thu, 12 Aug 2010 23:43:00 GMT

O/Rマッパー。
半ば常識、使って当たり前みたいに言われているフレームワーク。
多分この分野で一番元気なのはJavaだと思うんだけど、Javaに限っても結構な数があります。

私の初O/RマッパーはHibernateでした。
全体の開発期間は2年、実装からリリースまでの期間は1年半という、中規模程度のWebアプリケーションで採用。
実際にはHibernateを素で触ることはほとんどなく、SpringのHibernateサポート機能を通じて操作しています。

初見の感想は、
「軍手二枚重ねにした上で、箸で皿に盛られた豆つまんでる様な感覚」
でした。
素手で掴めばいいだろうと。

Hibernateを含めたO/Rマッパーの情報を漁ると、ほとんどが礼賛、という状況です。
個人的には不思議でなりません。
SQL覚えてなくていいとか分からなくてもいいなんて書いてある場合は、嘘はやめろとさえ思います。
デバッグモードなりでコンソールにSQLを吐かせて、意図通りのクエリが発行されているか確認するのは必須でしょう。

Javaのように、オブジェクトありきの言語では、実際O/Rマッパーは必要だと思います。
オブジェクトへのマッピングを行うフレームワーク、という存在自体は。

でも、CriteriaやHQLなどの、SQLを自動発行できる仕組みはそれほど必要だろうか？と思ってしまいます。

もちろんあれば便利です。
SQLを組むときとJavaでプログラミングしているとき、私は頭の中の思考回路というか、ロジックの組み方というか、頭の回転方法自体がちょっと違っています。
しばらくJavaばかり触っていて、しばらくぶりにSQLを書くときなどは少々頭の切り替えが必要になります。
Criteriaを使うのであれば、Java的思考からSQL的思考に切り替えずに組むことが出来ます。
まあ、Criteria組み終えたらDAOをテスト実行して発行されるクエリを確認するので、そこで切り替えは必要にはなるのですけれど。

こういう感覚が一般的なものなのか私くらいのものなのか分かりませんが、JavaよりSQLの経験の方が長く、よりDBに親しんでいる私でさえこう感じるので、世のJavaプログラマーがJava上でのプログラムで完結させたくなる気持ちは分からないでもありません。
でも、私はこれ、RDBMSを使う時点で必要となる苦労だと思ってるんですよね。

Hibernate、決して簡単ではありません。
Hibernateトラブルシューティング
こちらの第1回と第2回に説明されている内容くらいは基本として踏まえていないとまともに使えないと思います。
さもないと、「動くけど使い物にならない」システムになりかねません。
テスト工程で様々な問題が発覚し、リリース直前まで慌てることになります。
･･･というかなりました。

こういった意見への反論はたいてい、「それはHibernateへの理解が足らないから」というもので、実際その通りだと思います。
逆に言うとそれだけ学習コストの高い代物で、1年程度のプロジェクトを１件こなして初級に到達できるように感じています。
自在に操れるようになるまで案件いくつこなせばいいんでしょうか？
少なくとも中級程度には使える人がプロジェクトメンバーにいないと、とても採用できないくらい難しいと感じています。

O/Rマッパーの謳い文句にはよく、「90%のSQLを自動発行することで効率化」というものがあります。
個人的に90%は眉唾ですが、少なくとも残り10%は手書きのSQLが必要であることを認めていることになります。
量にして10%ですが、当然そのクエリは自動発行では対応できないような複雑なものだったり、パフォーマンスを要求されるものだったりするわけです。
おそらく、RDBMSの実行計画とにらめっこしてクエリを書くことが出来る、中級以上のSQL熟練者が必要になるんじゃないでしょうか。

O/Rマッパーが自動発行してくれる90%のSQLは単純で組むのが簡単なものがほとんどなわけで。
あれ？
Hibernate使うならHibernate熟練者が必要だけど、どっちにしろSQLの熟練者もいるよね？
最初からその人に簡単な方までやってもらえばいいんじゃね？
数は多くて正直めんどくさいけど、書くのに時間はかからないわけで。

もちろんホンモノの世のHibernate熟練者はSQL覚えなくていいなんてタワゴト吐いたりはしてないでしょうし、SQL熟練者を兼ねている可能性は高いです。
でも、Hibernate熟練者とSQL熟練者、探すならどっちが楽でしょうね？
彼らが技術リーダー的立場になって、他のプロジェクトメンバーにノウハウ伝授しつつスキルレベルを向上させながら開発していく、なんてことも多いと思いますが、どっちが習得しやすくて、以後のプロジェクトでもより活用しやすいでしょうね？

Hibernateは現状、JavaのO/Rマッパーの中では最も評価が高く、おそらく採用実績も多いと思いますが、10年後には存在しているかすら怪しいです。
RDBMSは10年後も現役でしょうし、今のSQLの知識は変わらず活きると思いますけどね。
KVSって対抗馬がいるんで今より地位は下がる可能性は結構高いとは思いますけれど。

「軍手二枚重ねにした上で、箸で皿に盛られた豆つまんでる様な感覚」
Hibernateを触り始めてもう二年になりますが、この感覚はあまり変わりません。
さすがに慣れたので、軍手二枚重ねが一枚になったくらいではありますけれど。
「動くけど使い物にならない」ところをNative Queryに書き換えまくり（HQLはハナから考慮の対象外）ましたが、もっと早くからCriteriaの仕様箇所を限定すべきだった、という思いが強いです。
書き換えた方がよい箇所はまだまだあるんですが、優先度や工数、金銭的な問題で手を出せないという現実がありまして。
技術者的感覚では手を出したくてたまらないところですが、運用に入っているとそうもいきません。

Hibernateがもたらしたものはなにか？
純粋な意味でのO/Rマッピングでは助けてくれました。
オブジェクトへのマッピングを手作業でやっていてはとても大変だったでしょう。
でも、Natige Queryへの書き換えを余儀なくされた分、楽させてもらった部分、効率化の恩恵は軽く吹っ飛んでいます。
Native Queryへの書き換え（できればストアドへの書き換え）を行いたい部分は要するに使えはするけど重ったるいとか、もっさりしてるとかそういう機能な訳でして。
そういった部分で顧客の心象を悪くしているだろうなーとか思ったりもする訳で。

私自身はフルストアドを真面目に提案したくらいSQL寄りな考え方なので割り引いてもらう必要があるとは思いますが、Hibernateがもたらした効率化は軽くマイナスになっています。
O/Rマッパーというものを経験できたという意味で私の経歴にはプラスになっているのですが、こと採用プロジェクトにかんしてはマイナスです。
使わなかった方がマシか、発行クエリをすべてNative Queryにしてしまうか、まあコレクションじゃないオブジェクトに対する単純なCRUD操作くらいに限定すべきだった、という感想です。
それもまた、プロジェクトが終わったあと、ある意味神の視点からじゃないと出せない都合のいい感想ですけれど。

まあ私が見た痛い目は、対象となるデータ量の見積もりが甘かったってことに尽きるんですけどね。
バッチ処理やバルク処理に弱いとは聞いてたけど、四日かかる処理が15分に短縮できたとかどこの世界ですかって話になる訳で。

というわけで、私自身は今後Hibernateを他のプロジェクトで使うことはないと思います。
iBatisとかS2JDBCとかS2DAOに興味はありますけどね。
正直アプリケーションが吐くクエリは完全に管理したいので、フルストアドが理想なのは変わりません。
メンバーの担当分野を層で分けるやり方って、あんまり一般的じゃないのかなあ。

[Small Talk]「～を検索」は正直邪魔だと思います。

Oakbow — Tue, 12 Jan 2010 21:15:00 GMT

Google Tool Barのアレです。

検索キーワードの入力欄に文字列を入力すると、全角スペース一個分くらいの隙間の跡に「を検索」って表示されるようになりましたね。

慣れてはきましたが、治りかけのかさぶた（今剥がすと確実に出血）くらいどうにかしたくなってくるのは私だけでしょうか。

携帯電話の予測変換ばりに、入力中の検索キーワードの文字列に対して補完機能が働くようになりましたね。

この機能自体には結構感心しました。IMEをONにするの忘れて直接入力していても、ローマ字から日本語に補完してくれるし。

でも、でもね。

私の環境だけなのか分かりませんが、リコメンド機能よろしく出てくるプルダウンメニューが、びろーんと下に垂れ下がったままになることがよくあります。

舌をびろーんと垂れ下げたまましまい忘れてるシュウたんは可愛いですが、こちらは可愛くありません。

タブに重なるので切り替えにくくなるし、当座の作業に問題なくても気になって仕方ないのでなんとか閉じさせようとするんですが、これがなぜかなかなか閉じないんですね。

自宅環境のIE8ではあんまり起きない気がするので、会社環境のIE7が原因なのかな？

できればさっさとIE8にしたいところですが、Webアプリケーションの動作確認の時には重宝するので悩みどころです。

[Small Talk]ごめん、組閣で忙しくて･･･

Oakbow — Mon, 14 Sep 2009 23:43:00 GMT

（最長）4年に一度の一発ネタ。もうすぐ期限切れです。ご賞味はお早めに。

私は麻生内閣と福田内閣と安倍内閣でもう使っちゃったので今回は見送ります。

「ちょっと～～、30分の遅刻よ！」
「今日は早く帰れるって言ったでしょ！」
「晩御飯ま～だ～？」
「仕事とあたし、どっちが大事？」
「君、昨日中に仕上げるっていってた企画書、まだできとらんのかね？！」
「おい、上原ぁ！！！！！！！！」
「奥さん、今日こそは耳揃えて返してくれるんだろうなァ」

などなど、ちょっとしたピンチにご活用ください（最後のはアウトかもしれん）。

ちょっとした変化球として

「燕尾服仕立てるの結構時間かかっちゃって・・・」

「連立調整に手間取ってさ・・・」

などがあります。

応用すれば「補正予算が・・・」「内閣不信任案が・・・」とかちょっと前だったら「衆院選が・・・」いろいろいくらでも活用できますが、あまり政治ネタばかり使うとウザくなるのでほどほどに。

ほとぼりが冷めたころに、できればスポーツとか別ジャンルでやるとよいです☆

[Browser]IEのウィンドウごとのセッション共有・非共有

Oakbow — Sun, 13 Sep 2009 00:26:00 GMT

私の自宅環境（Windows Xp Professional）でも、とうとうWindows UpdateでIE8が入りました。

会社では3台のPCがあって、それぞれブラウザが違ったりします。

Windows Server2003 R2 日本語版を2年ほど前に自分でインストール。最初に入ってたブラウザはIE6。
自動更新が利かない環境なので、手動でWindows Updateをやっている。
1～2ヶ月ほど前から重要な更新でIE8が出てくるようになるも、IE6のまま使用。
Windows Server2003 R2 英語版を2年ほど前に自分でインストール。最初に入っていたブラウザは多分IE7。
自動更新が利かない環境なので、手動でWindows Updateをやっている。
2～3ヶ月ほど前に重要な更新でIE8が出てきたので、そのまま入れて使用。
Windows Xp Professional 日本語版のプリインストールマシン。1年半ほど前に購入。最初に入っていたブラウザはIE7。
会社のWSUSの環境下にあるので、自動更新でWindows Updateをやっている。
IE8は会社的にまだっぽいので、重要な更新に出てくることは無い。IE7のまま使用。

WindowsXpプリインストールマシンでも、ブラウザがIE6だったりIE7だったりする。

重要な更新でIE8が出てくるようになった時期もなんかちょっと違ったりしますね。環境かな？

IE7は日本だけなぜかまともにWindows Updateで配信されていないので、ほとんどの人がIE6→IE8に一気に飛んじゃうでしょうか。

重要な更新に含まれているので、今後一気に移行が進んでいきそうですね。

さて、前置きが長くなりましたが、IEのセッションクッキーについて。

Webアプリケーションで一般的に使用されるセッションは、セッションIDと呼ばれるキーとなる情報をクライアントとサーバ双方で保持することで成り立っています。

クライアント（ブラウザ）がWebアプリケーションに最初にアクセスしたときに、WebアプリケーションはセッションIDを生成し、その値を持つクッキーの発行をブラウザに要求します。

クッキーに対応したブラウザであればその要求を受け入れ、以後同じサイトへのアクセスであれば、毎回セッションIDをクッキーで送信するようになります。

通常のクッキーはプレーンテキストでブラウザが管理する一時ファイル領域に保存され、ブラウザやOSがシャットダウンされても、次回アクセス時にそのまま使用できるようになっています。

が、セッションクッキーだけは別で、これはブラウザが保持するメモリ領域のみに保持され、ブラウザやOSがシャットダウンされると消えてしまうようになっています。

ここまでが一般のセッションクッキーの共通知識ですよね。

で、複数のウィンドウを開いているときに、セッションクッキーがブラウザでどう扱われているかって情報は見かけない気がして、数年前に一度調べたことがあります。

IE8が出てから復習もかねて調べなおしたりしたので、そのまとめ。

IE6
セッションはプロセス単位で共有しています。ごく普通のマルチスレッドアプリケーションのメモリの扱いと一緒っていっていいかな？
IE6では、「CTRL+N」や「ファイル」→「新規ウィンドウ」、ハイパーリンクをShiftキーを押しながらクリック、ページ内のHTMLやJavaScriptの記述により別ウィンドウを開く、という操作では、ウィンドウ自体は別であっても同じプロセス内で動作しています。
すでに存在するウィンドウから開いたウィンドウであれば同じプロセス、と考えていいと思います。
それに対して、スタートメニューやデスクトップのアイコンからなど、既存のウィンドウに依存しないやり方で新しくウィンドウを開いた場合は、別のプロセスで起動します。
このような違いが発生するので、例えば後者のやり方で二つのウィンドウを開いた状態にすると、セッション管理された会員ページとかで、別々の会員としてログインして動作確認をしたりって事が可能です。
前者のやり方でウィンドウを二つ開くと、片方で会員ページにログインすれば、もう片方はいきなり会員ページ内にアクセスさせても普通に操作できたりもします。
一人の会員に対して何度もログインログアウトを繰り返すような動作確認を行う場合、こちらのやり方を採用するとちょっとだけ楽が出来ます。
IE7
IE6と同じと考えてもらっていいです。当然ですがタブは同じウィンドウであれば同じプロセス内にあり、セッションを共有します。
IE8
IE6/7の考え方は通用せず、上記のようなやり方であればいずれもセッションを共有します。プロセスが違うウィンドウであっても。
そもそもIE6/7であればウィンドウの数よりプロセスの数が多くなることはありませんでしたが、IE8の場合はプロセスがひとつであっても、タブを増やすと複数のプロセスが出来たりします。
IE8でセッションを共有しない新しいウィンドウを開きたい場合は、「ファイル」→「新規セッション」でウィンドウを開きます。

たいていのWebアプリケーションではセッションを使用するでしょうから、ページ遷移などで予期せぬセッション情報の書き換えなどが発生しないように、ブラウザでどのようにセッションが共有されているかは抑えておきたいところです。

私は機能ごとに必要な値をできるだけセッションに持たせないように作るんですが、その理由が複数のウィンドウ開いたときに問題が発生するからだったりします。

ごく普通にユーザーが行う操作を制限したりするのは昨今のトレンドに反するし、何より複数のウィンドウ開いて操作しちゃったせいで問題が発生したって問い合わせがエンドユーザーから結構あったから。

エンドユーザーからの問い合わせは「入力値とは異なる値に書き換わった」ってなものになるので、上のようなウィンドウ間でのセッション共有が発生する仕組みを知らないと、原因すら分からないことになったりもします。

[Oracle] 権限管理はどうする？

Oakbow — Sun, 09 Aug 2009 13:16:00 GMT

DB の権限管理って、一般的にはデータベースロール、データベースユーザー、データベーススキーマの仕組みを駆使するものだと思っています。

MS SQL で自分で DB 設計をした過去のWebアプリケーションは、DB アクセスはすべてストアドでした。
ActiveDirectory 環境ではなかったので、Web サーバとDB サーバ双方に ID とパスワードが同じアカウントを作成し、Windows 認証で DB に接続するようにします。
Web アプリケーションは管理側と一般ユーザー側という構成だったので、管理側が実行できる必要のあるストアドに対して EXECUTE 権限のある DB ロールと、一般ユーザー側が実行できる必要のあるストアドに対して EXECUTE 権限のある DB ロールを作成。
実際に Web アプリケーションが接続するユーザーにこのロールを割り当てれば基本的にそれで終わり。

ストアド内で普通に SELECT とかしているものに関して SELECT 権限を実行者に与えなくてもいいんですが、 sp_executesql などで DynamicSQL 発行してる場合は別。
なので sp_executesql でアクセスしているテーブルやビューなどのデータベースオブジェクトがあるストアドを実行しているユーザーには、必要最低限の CRUD の権限を与えました。
今思えば敢えて sp_executesql 使う必要は全くないストアドばっかだった気がしますが･･･。
SQL インジェクションの脆弱性も出る可能性あるんだし。

まあ、MS SQL での権限管理はとても簡単でした。
sp_executesql 使ってない場合はストアドの実行権限しか付与しないですみます。
DB からみたらクライアントに相当する Web アプリケーションには一切の CRUD 権限を与えなくていいので、DB 関連のセキュリティにあまり悩まなくていいです。
他にもたくさんある、ストアドを使う利点の一つでしかないですけれど。

そんな MS SQL での踏まえた後の Oracle。
残念ながらオールストアドという私の野望は達成できなかった上、ビューも禁止されているので、Hibernate 経由ながら直にテーブルアクセスです。
DBアクセスするアプリケーションの構成は、例えるとこんな感じ。

わんくま運営者･･･システム全体を統括する管理ページ
わんくまメンバー･･･個々のブログの管理ページ
一般ユーザー･･･外部に一般公開されているページ
月次バッチ･･･月初に一回だけ実行されるバッチ処理

月次バッチは Web アプリじゃなくて、cron で定期実行される Java アプリ。
管理ページが複数ないことも多いけど、構成としては割と一般的でしょうか。

Oracle では以下のような権限管理の構成にしてみました。

WANKUMA_ADMIN（DBユーザー）
WANKUMA_ADMIN_ROLE というデータベースロールを付与。このロールはわんくま運営者が扱う管理ページで必要とされる CRUD 操作の権限をまとめたもの。
直接オブジェクト権限を与えることはしない。
システム権限は CONNECT 権限のみ付与。
ユーザーテーブル領域に対する権限は与えていないので、自スキーマですら CREATE TABLE を行うことは出来ない。
ただし Oracle の仕様により、自スキーマであれば一時表（一時テーブル）を作成することは出来る。
後述する WANKUMA スキーマ内のすべてのテーブルとシーケンスに対して、シノニムを作成。

WANKUMA_MEMBER（DBユーザー）
WANKUMA_MEMBER_ROLE というデータベースロールを付与。このロールは個々のブログ保有者が扱う管理ページで必要とされる CRUD 操作の権限をまとめたもの。
あとは WANKUMA_ADMIN と同じ。

WANKUMA_GENERAL（DBユーザー）
WANKUMA_GENERAL_ROLE というデータベースロールを付与。このロールは一般公開されたページで必要とされる CRUD 操作の権限をまとめたもの。
あとは WANKUMA_ADMIN と同じ。

WANKUMA_BATCH（DBユーザー）
WANKUMA_BATCHL_ROLE というデータベースロールを付与。このロールは月次バッチで必要とされる CRUD 操作の権限をまとめたもの。
あとは WANKUMA_ADMIN と同じ。

このようにして、データベースユーザーとデータベーススキーマを切り離すことが出来ない Oracle で、実質的に DB 接続にしか使用できない、スキーマとしての存在を殺した DBユーザーを作成。
これらとは別に、以下のようなデータベーススキーマを作成しています。

WANKUMA
すべてのテーブルはこのスキーマ内に作成。
システム権限は UNLIMITED TABLESPACE のみ付与。
CONNECT 権限を与えていないので、このスキーマ（≒ DB ユーザー）に直接接続することは出来ない。

こんな感じにして、上とは逆に実質的に DB ユーザーとしての存在を殺して、スキーマとしてしか機能しないって風に。

正直「Oracleでは普通こういう風にやるよ！」ってのを知らないんですね。
さすがにデータベースオブジェクトの所有者に直接アクセス、とかいうのは無いだろうなあと思っていろいろ考えてたら、こういう形に行き着いたというところ。
「MS SQLだったらこうするよ！」みたいな権限管理ベストプラクティスを知ってるって言えるほどじゃないですけれど、マイクロソフトは結構その手の資料が充実してるので、（多分）なんとかなりました。
Oracle も Books Online に相当する結構膨大な資料があるんですが、あれ読んでても正直よくわからなかったというところ。
メーカーサイドじゃない技術資料は例えば @IT とかにかなり豊富に存在する Oracle ですが、権限管理に関するものは見つけられませんでした。
こういうのは書籍ベースじゃないとなかなかないのかしらん。

[Oracle] 照合順序はどう使う？

Oakbow — Sun, 09 Aug 2009 01:33:00 GMT

MS SQL には照合順序というものがあります。英語で言うと COLLATION でしょうか。

手っ取り早く言うと文字の大小比較に使う設定で、例えば CS （Case Sensitive）だと大文字小文字を区別するし、CI（Case Ignore）だと区別しません。

MS SQLの照合順序は日本語だけでもかなりの数があるので、最初はちょっと混乱します。

若干複雑なところもありますが、使えるようになるととても便利なので、私は COLLATE とか結構多用していました。

インスタンス、データベース、テーブル、カラム、クエリそれぞれの単位で設定できるでとても便利。

大文字小文字やひらがなカタカナを区別しないLike検索とかソートとかって結構要求されることが多いし、これをアプリケーション側でちまちま実装するよりかは早くて簡単ですから。

ただし比較対照のカラムの照合順序があってないとエラーが発生するので、意味が分かっていない当時は結構苦慮していましたけれども。

一時テーブルの照合順序は確かインストール時の照合順序か何かがデフォルトになるので、一時テーブルと結合するときには注意が必要だったりとかもあったような。

ちゃんと触ったことはないけど、MySQLにも数は少ないながら照合順序の仕組みはちゃんとあって、テーブルやカラム単位での指定もできるし、COLLATE でクエリ単位で使うことも出来たと思います。

で、Oracle。

大文字小文字やひらがなカタカナを区別しないLike検索と、辞書順ソートの要求はやっぱりあったので、MS SQLと同じノリで照合順序で対応しようとしました。

が･･･。

なんか仕組みが違います。

Oracleには NLS という多言語対応の仕組みが合って、照合順序に相当するものは NLS_SORT とNLS_COMP のようです。

照合順序とはちょっと違うので、言語ソートとか呼んでいるみたい。

基本的に環境変数で設定を行う Oracle のやり方には混乱しっぱなしですが、これらの設定はインスタンス（≒データベース）、セッション単位で設定を行うことが出来ます。

テーブルやカラム単位では設定することはできないようです。

（権限があれば）必要とするクエリの直前に ALTER SESSION を発行してまた元に戻せばいいので、クエリ単位でできる、といえないこともないです。

COLLATE はどうやらありません。

NLSSORT 関数というものはあるので、単純な比較や order by だけであれば、クエリの内部で照合順序を使うようなことは可能です。

が、これは % や _ などのメタ文字との組み合わせがほぼ必須となる、like 検索では使用できないようです。

はて、と困りました。

「よーしパパ照合順序で対応しちゃうぞ～～！」と意気込んでみたら、なんか事情が違います。

生クエリをゴリゴリ書いたりできるプロジェクトであれば、 ALTER SESSION と NLSSORT 関数を使いまわしてなんとかできそうなんですが、今のプロジェクトでは O/Rマッパーである Hibernate を使っており、基本的に SQL は自動生成です。

特定のクエリ発行時だけ ALTER SESSION を発行するメソッドを呼び出すようにするとかなんとか考えたりもしたんですが、当時はある程度固まったDAO の使い方のルールに例外的措置を加えることになってしまうので、それもどうかという話になり。

あれこれ考えた末、結果的にはログイントリガで ALTER SESSION を発行することで対応しました。

NLS_SORT に JAPANESE_M_CI、NLS_COMP に LINGUISTIC を設定しています。

なんか CLOB なカラムには見事に効いていないようですが･･･（Oracle Textとか使わないとなのかしらん）。

しかしプロジェクト終盤に入った今は、このやり方は失敗だったのかなあと思っています。

当然すべての文字列型の比較やソートでこの NLS_SORT と NLS_COMP の設定が有効になるわけで、辞書順ソートや比較が必要のないケースではパフォーマンス上の問題が発生します。

というか、実際に発生したんですね。

CHAR型だけど値の中身は全部数値になってるカラムを IN 句で1000件条件指定して UPDATE するクエリを実行したら、10分以上ダンマリって結果が･･･。

2万件の UPDATE を1000件ずつ実行してるんですが、1時間たっても終わらないのでブラウザがタイムアウトとか阿保みたいな状態になってしまいました。

Oracleを扱う上でとても参考させていただいている Shift-The-Oracle さんも以下のように警告しています。

また NLS_COMP と NLS_SORT の NLS パラメータを設定することによってオプティマイザによるアクセスパスがパフォーマンスに影響が出るくらいに大きく変化することにも注意を払う必要がある。

全角・半角、大文字・小文字を区別しない検索

文字列型カラムを大量に指定しない限りそこまで影響が出たりはしないのか、ログイントリガを設定した当初はあれこれ心配したものの特に遅くなったりもしなかったので、大丈夫かなと踏んでいたんですが。

世のOracle使いの方々は、「大文字小文字やひらがなカタカナを区別しないLike検索」の際には、どうやっているんでしょうか？

[Oracle]ORA-00600エラー発生

Oakbow — Sun, 09 Aug 2009 00:21:00 GMT

ORA-00600。

（最近更新されてないけど）Oracleの技術情報が豊富な Shift-The-Oracle さんでは、以下の様に解説されています。

サポートに問い合わせるか、その機能や使用方法をやめる。の二択であると言っても過言ではない。
ORA-00600 - オラクル・Oracle エラー FAQ

また、 Archive Redo Blog さんのところでは以下のように解説されています。

内部エラーというのは、文字通りOracleの内部で発生したエラーで、メッセージが定義されていないものがすべてこのコードで返されるというわけです。

[Oracle] ORA-00600エラーへの対処方法

エラーコードが同じであっても全然別物だったりするってことですね。

斯様に恐ろしいエラーなんですが、うちとこでも発生しました。こんな感じの。

ORA-00600: 内部エラー・コード、引数: [qernsRowP],・・・

発生した原因のひとつは直前に行ったインデックスってのはすぐ分かったんですが、さすがにインデックス張っただけでエラーが発生するとは思えないので、原因の特定を若干行いました。
結果分かったことは以下のようなものです。
テーブルの形はこんな感じ。

create table MEMBER (
 USER_ID number(10) not null,
 NAME varchar(50 char) not null,
 primary key( USER_ID )
)

言語ソート JAPANESE_M_CI を使うと発生する。
業務上の理由から、辞書順のソートと比較が必要なため、JAPANESE_M_CI に設定しています。
具体的にはログオントリガで NLS_SORT を JAPANESE_M_CI に、NLS_COMP を LINGUISTIC に ALTER SESSION しています。

PK かつ FK（外部参照制約）と文字列カラムへの複合インデックスを張ると発生する。
USER_ID と NAMEに対して張っています。
実際には PK や FKであるかどうかは関係ないかもしれませんが、文字列カラムへの単体のインデックスを張るだけでは発生しませんでした。

複合インデックスを張っているカラムを SELECT し、distinct をかけたインラインビューに対して rownum するクエリを発行すると発生する。
具体的には以下のようなクエリです。

select *
from (
 select distinct USER_ID,NAME
 from MEMBER
 order by NAME
)
where rownum <= 10

distinctをつけなかったり、インラインビューになっている中のクエリだけで実行した場合には発生しませんでした。
もしかしたら order by も影響しているかもしれません。

これらの条件をすべて満たした環境下で発生しました。
NLS_SORT や NLS_COMP の設定を行っているログイントリガを無効化したり、インデックスをはずしたり、エラーが発生するクエリの中身を書き換えたり、どれかひとつの条件を満たさないようにすると起きなくなります。
また、ややこしいことに、再現性は100%ではなく、50%程度。
業務上よく実行されるクエリなのですぐに問題発生に気づきましたが、エラーが起こらずすんなり意図した結果が出ることもあれば、エラーが発生して落ちることもあり。

サポート直行といわれる ORA-00600 の情報はネット上でもほとんど見つからないので、原因を特定することすら困難だったりするようです。
サポートで解決した情報は外部に公開できませんし。
うちとこはサポート契約していないので、とりあえず要因のひとつになっているインデックスをあきらめました。
そこまで固執する必要があるインデックスじゃなかったのでこの解決策自体はいいんですが、ちょっとインデックス張るのが怖くなりましたね･･･。

[Small Talk]わんくま勉強会、いけなくてごめんなさい

Oakbow — Sat, 08 Aug 2009 23:20:00 GMT

先日行われた「東京勉強会#36」ですが、体調不良で寝込んでしまい、行くことが出来ませんでした。

申し訳ありませんでした。

せめて当日朝にでも欠席の連絡が出来ればよかったんですが、勉強会の案内のメールに連絡先が書いてあることに気づいたのはかなり後・・・。

こういったユーザーイベントにかかるスタッフの労力は大変なものだと思いますので、それに応えるためにも、以後気をつけたいと思います。

Oracleは全角の%や_もメタ文字として認識してしまう

Oakbow — Fri, 24 Oct 2008 21:36:00 GMT

SQL Serverはどうなんだろう？　というのは調べてないんですけれども。

SQLのLIKE句で使える %（0文字以上の文字列に一致）や _（1文字に一致）などのメタ文字ですが。

Oracleではこれらが全角文字であってもメタ文字として動作してしまいます。

マニュアル読んでもそういった記述は見当たらなかったんですが、otn とかでもそういう話題があるし、Oracle使ってる人の間では一般的な認識なのかしら？

設定などで変更できるわけでもないみたいで。

先のエントリに書いたHibernateのメタ文字エスケープの問題もあって、結局半角全角両方のエスケープが必要でした。

エスケープシーケンスに設定した文字をあわせて、5文字ですね。

よくまとまってるのはこのあたりでしょうか。

http://ameblo.jp/archive-redo-blog/entry-10033356201.html

個人的にはこちらも、えー、なにこれ？　って仕様。

Hibernateは％メタ文字をエスケープしてくれない

Oakbow — Fri, 24 Oct 2008 21:30:00 GMT

Hibernateで、クライテリア使って開発してます。

あいまい検索とか俗に言われるSQLでのlike句では、

Restrictions.like("フィールド名", "文字列", MatchMode)

って書き方で実現できます。

MatchModeってのは前方一致とか後方一致の指定のための列挙型です。

DB内の文字列検索とかには普通に使うだろうと思います。

が、ユーザーの入力文字列が入るだろう文字列部分に % あたりが入ってても、Hibernateはエスケープなどはやってくれず、そのままクエリ投げてしまいます。

つまり、入力フォームのヴァリデーションなどで入力必須とかにして全件一致を防いだつもりでいても、全件一致のクエリが投げられるわけで。

個人的には　えー、なにこれ？　って仕様です。バグかと思うくらいの。

エスケープありとなしが用意されているとかなら分かるんですけど、どうやらなさそうだし。

あんまり騒がれてる様子もないけど、みんなどうしてるんだろ？

うちとこでは、フレームワーク全般を担当しているプロジェクトメンバーさんが、%や_などのメタ文字をエスケープしてくれるメソッドを追加してくれました。

プロジェクト内では Restrictions.like を避けて、追加したメソッドを使うことで解決してます。