Oracle

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

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

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

コードのカラム、型はなに？

Oakbow — Wed, 08 Oct 2008 01:37:00 GMT

仕事でOracle使ってます。

SQL Serverに馴染んでいるので、機能的な違いだけでなく、取り巻く環境の違いにもよく戸惑います。

列挙型ってありますよね。

この言い回しが一般的なものなのか分かりませんけれど、例えば住所のデータベースで都道府県を記録する場合、都道府県カラムに文字列でそのまま放り込むんじゃなくて、コードを記録するってやり方。

コードと実際の都道府県の文字列の対応表となるものは、アプリケーション側で保持したり。

これ、わたしはSQL Serverではtiny intとかsmall intとか使ってました。

誰かにそうするものって習ったのかどこかで見かけて真似したのかもう覚えてないんですけれど、それが普通になってました。

趣味で触ったmySQLにもこれらの数値型が確かあったので、同じようにやっぱりやってました。

Oracleの数値型だとnumberになっちゃうんだけど、そのままの流れでnumber(1)とかnumber(2)で設計しようとしました。

すると、Oracleでの経験も多いプロジェクトメンバーに　「Oracleだと普通char型使いますよ？」と言われ。

「え？そうなの？」　となんとなく納得いかない気持ちながら、そういう伝統は先人の経験から来るものだろうと素直にchar型にしました。

コードは数値型、ってのがあまりにも当たり前になってて、そうする理由とか考えたことなかったので、char型に対するメリットを訴えられなかったのもあるんですけれど。

これってどうなんだろう？と今でも思います。

Oracleのノウハウを紹介しているサイトとかでも、Oracleでのコード＝char型ってな説明があったので、実際そういう伝統はあるようなのですけれど。

みなさんはコードのカラム、型は何を選んでいますか？

その理由はなぜですか？