Oracle Database 10g Express Edition

ついこないだこんな事書いたばかりですが、
さっそくニューPCにOracle入れちゃいましたｗ
MYフリーソフト作成のために必要だったのですよ。


Oracle10gの無償版と呼ばれる
Oracle Database 10g XE
です。


で入れてみたんですけど、
ナニコレちょー簡単！


「SolarisにOracleインストールする」で苦労したのが
ウソの様な簡易インストール。

だって、自分で入力した項目が
管理者のパスワードのみですよ！
拍子抜けすぎ。

まあこれは本当のOracleではないですからね。
逆に「興味あるから触ってみたいな」という方には
ちょうど良いかもしれません。

ORACLE小話その１７ SQL*Loaderについて

こないだSQL＊Loaderについて一つお勉強しました。

というのは以下の現象。

主キーがついているテーブルに対して キー違反が存在するデータをロードした時、 キー違反しているデータもロードされてしまう場合がある

この「場合」っていうのはダイレクトロードの場合。
一応エラーは吐かれるんだけど、データはロードされちゃうんです。

基本的にプライマリキーって100%生きるんだろうなぁ
と思っていたので、キーが負けちゃう場合があるのには
少し驚きました。


この時に

select count(*) from テーブル;

とかやっても特にエラーは出ないんですが、

select count(*) from テーブル WHERE プライマリキー = XXXXX;

という具合に主キーにアクセスした時点で

ORA-01502: 索引'プライマリキー名'またはそのパーティションが使用不可の状態です。

こんなエラーが出ます。
もちろんデータの重複を直さない限り
主キーを直すことはできません。


勉強になりました(*゜ー゜)

ORACLE小話その１６ 隠しコマンド？

Windows版のOracleクライアントに付属している
SQL＊Plusありますよね。

あれで隠しコマンド？っぽいのを偶然見つけた！


普通はSQL*Plusで文字列コピぺをする際、

文字列ドラッグ ↓ Ctrl+Cでコピー ↓ Ctrl+Vで貼り付け

という一連の動作で行いますよね。


それと同じことが以下の動作でも行うことが出来るのです！

文字列ドラッグ（左クリックは押したまま） ↓ 右クリック

SQL*Plusマニュアルも確認しましたが、
記述されて無かったと思いますので
隠しコマンドかと。
（全然隠しコマンドじゃねーよ！ということであればご指摘下さいｗ）


みなさんも一度お試しあれ！

ORACLE小話その１５ 共有サーバプロセス

こないだは共有サーバプロセス関連で
トラブルがあったみたいです。

現象としては共有サーバプロセスが
MAX_SHARED_SERVERS接続数まで使い切っちゃって
全然応答が返ってこなくなった、
というもの。

根本的な原因は、MAX_SHARED_SERVERSの設定値が低かった（４０）
という基本的なことなんですけどね。



Oracleのマニュアルも見たんですけど、
そもそも共有サーバプロセスの見積もりって結構難しいらしい。
以下はマニュアルの抜粋。

まず、psコマンドなどでシステムの使用可能なRAM容量を調べて
追加できる共有サーバプロセスの数を見積もる。
その後、少しずつMAX_SHARED_SERVERSの値を増加していって
スワッピングが発生したところが一杯一杯なので
そこから最適な設定を見つけだす

こんな感じで書かれてました。
普通そこまでするの？



あと、共有サーバープロセスについて
ちょっと疑問があるんですよね。
それは
　１つのセッション（SQL文）に対し、
　１つのサーバープロセスが対応するのか？

というもの。要は１対１になっているか。

コネクション自体はディスパッチャで
複数の接続に対応してくれるのはわかるけど、
その後、要求キューに入れられた１つの処理は
１つのサーバープロセスが対応するものなの？
とすると結局、重いSQL処理がMAXまで（今回の場合は４０個）発行されて
すべての共有サーバプロセスがお仕事中だとしたら、
その後に入ってきたSQLは待たされちゃうって事？
それもなんだかなぁって感じがするんだけど…


また、Oracleマニュアルには
「ユーザーが比較的少数の要求しか行わない場合、
　１０～２０ユーザーに対し１つの共有サーバプロセスで十分」
と記述されております。


今回共有サーバプロセスが溢れた時は約２００セッションだったんですけど
すべてのセッションが要求中だったとしても
共有サーバプロセスは２０で十分っていう計算なんですけど…
まあ要求が重かったからって事ですかね。


さっきも書きましたけど、個々のシステムによって最適な
プロセスの数があるみたいですしね。
こんなに単純な計算では行かないって事か。


■共有サーバの診断
V$SHARED_SERVER_MONITOR
V$SHARED_SERVER
V$SESSION
V$CIRCUIT

■ディスパッチャの診断
V$DISPATCHER
V$DISPATCHER_RATE
V$QUEUE

ORACLE小話その１４ ライブラリキャッシュでデッドロック？

以前、ロックのお話をしましたが…


普通、デッドロックといえば
ORA-00060　リソース待機の間にデッドロックが検出されました。
ですよね？
１つのテーブル内に対する更新で
２つのセッションがあべこべなロック待ちをしてしまい、
デッドロックが発生します。


でもこないだ発生したデッドロックはちょっと違うんです。

ORA-04020　オブジェクト 'テーブルA' をロックしようとしてデッドロックを検出しました。

テーブルでデッドロック？

ちなみに、同じ時刻でまったく別のテーブルに対しても同じ現象が発生していました。

ORA-04020　オブジェクト 'テーブルB' をロックしようとしてデッドロックを検出しました。

このテーブルAとテーブルB、全く関連性はありません。
本当に何がなんだか…



まず夜間バッチで一括ロードをしています。
その時、パラレルでテーブルAとテーブルBに対して
TRUNCATE→SQL*Loader（TRUNCATEは、ロードのオプションで行っている）
を行っているのですが、そのTRUNCATE中にデッドロックが発生した模様。
つかテーブルに対するデッドロックって意味わからん。

テーブルの状態としては、TRUNCATEのみが実行された感じでロードが動かず、
テーブルがどちらも０件のままになっていました。
一応、ORACLEマニュアルの対処法にもある通り
時間を置いて再実行したらうまく行ったみたいなのですが…。




トレースファイルを見てみると、以下のような循環ロックが発生していたようです。

セッション①がテーブルＡに対し共有ロックしようとしたところ、セッション④によるロックによりブロック。
セッション②がテーブルＢに対し排他ロックしようとしたところ、セッション①によるロックによりブロック。
セッション③がテーブルＢに対し共有ロックしようとしたところ、セッション②によるロックによりブロック。
セッション④がテーブルＡに対し排他ロックしようとしたところ、セッション③によるロックによりブロック。

つまり４つのセッションが互いのオブジェクトをロックしようとしたところでエラーが発生。
この内、２つの排他ロックというのは
並列実行のSQL*LoaderによるTRUNCATEだと推測されます。

問題は残りの２つ。
もうセッション情報が残っていないので調べようが無いのですが
おそらくはなんらかの他アプリケーションにより実行されたもので、
不正終了か何かでライブラリ内のオブジェクトをロックしたまま残ってしまい
オブジェクトを掴んだままになってしまったと思われます。
…もしくは、Oracle側の不具合ｗ


と言いますのも、いろいろ検索してみたのですが
このエラー番号で調べてみると
ORACLEの不具合で発生してる事象がほとんどでした。
まあその場合、PL/SQL関連の不具合なので今回のとは少し違うんですけどね…。
しかもこのデッドロックって、ライブラリキャッシュ内で発生してるようなので
あまりこちら側で意識できない所のような気がするんですが。


レアケースみたいなので
とりあえずほって置くということでｗ