ユニフォーム姿

　　　　「何も選ばない」生き方のすすめ



Accessから更新クエリーを実行したら、ORA-01013が表示
されて、更新に失敗する。

「ユーザーによって現行の操作の取り消しが要求されました。」
「ユーザーによってカレント操作の取消しが要求されました。」

思い当たることは、ODBC接続している、このテーブルの件数が
５万件を越えたくらいかなぁ・・・。


ネット上で対応策を探していると、同じように更新クエリーや
削除クエリーで失敗している例が見つかった。

アドバイスとして一番多かったものが、
「クエリーのタイムアウト時間を600に増加する」ことだった
ので、試してみたけれど同じ現象。
（もちろん、待ち時間だけは１分から１０分に増えた。）

次に、抽出条件を絞り込んでみたが、現象は変わらない。
（１件でやってみたら成功した。）

同じくらいの大きさのテーブルで試して見るが、やはり
現象は同じ。しかし、こちらのテーブルでは何故か
抽出条件を絞り込んでみたら成功した。

何か、oracleのデータベースマネージメントに問題が
発生しているのかを疑う。

それで、ＤＢベリファイ（dbv）してみたのだが、
”Total Pages Marked Corrupt:0”で損傷なし。これは
助かった。


次に、splplusに入って、同じsql文を実行してみた。
こちらはタイムアウトという概念が無いのだろうか、
ハングのような状態・・・。

かなり、根が深そうだということで、腰を入れて
調査することにした。なんとなく、放置されて
いるプロセスが残っているのかな？と考えて出した
結論！。

↓

【大規模なロック（ロールバックセグメントを消費など）
　　　　　　　　がかかっていないかどうかを疑うべき！！！】


以下、誰もＤＢを利用していない時間帯に調べてみる・・・・・


SQL> select * from V$LOCK;

ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
-------- -------- --------- ---- --------- --------- --------- --------- --------- ---------
56339F04 56339F14 2 MR 201 0 4 0 27631788 0
56339EB8 56339EC8 2 MR 10 0 4 0 27631788 0
56339E20 56339E30 2 MR 9 0 4 0 27631788 0
56339DD4 56339DE4 2 MR 8 0 4 0 27631788 0
56339D88 56339D98 2 MR 7 0 4 0 27631788 0
56339D3C 56339D4C 2 MR 6 0 4 0 27631788 0
56339CF0 56339D00 2 MR 5 0 4 0 27631788 0
56339CA4 56339CB4 2 MR 4 0 4 0 27631788 0
56339C58 56339C68 2 MR 3 0 4 0 27631788 0
56339C0C 56339C1C 2 MR 2 0 4 0 27631788 0
56339BC0 56339BD0 2 MR 1 0 4 0 27631788 0
56339ADC 56339AEC 3 RT 1 0 6 0 27631797 0
563399AC 563399BC 4 XR 4 0 1 0 27631799 0
56339B28 56339B38 5 TS 2 1 3 0 27631787 0
56ACB988 56ACBA94 35 TX 655360 564626 6 0 46641 1
56A99EDC 56A99EF0 35 TM 31312 0 2 0 46641 0
56AECDA4 56AECEB0 45 TX 393245 563638 6 0 33184 0
56A99F60 56A99F74 45 TM 31312 0 3 0 33182 0
56339A44 56339A54 45 TX 655360 564626 0 6 33180 0

19行が選択されました。

　　　　　　　　↑　やはり、あったあった！。最後の５行が怪しい。


SQL> select * from V$LOCKED_OBJECT;

XIDUSN XIDSLOT XIDSQN OBJECT_ID SESSION_ID
--------- --------- --------- --------- ----------
ORACLE_USERNAME
------------------------------------------------------------
OS_USER_NAME PROCESS LOCKED_MODE
------------------------------------------------------------ ---------
10 0 564626 31312 35
user
windows_user 2216:2584 2

6 29 563638 31312 45
user
windows_user 2640:2384 3

　　↑　誰も利用していないのに、表示行が存在しているのは怪しい



SQL> SELECT SID,SERIAL#,USERNAME,STATUS,SERVER,SCHEMANAME,OSUSER,MACHINE,PROGRAM FROM V$SESSION WHERE SID IN (SELECT SID FROM V$LOCK);


SID SERIAL# USERNAME STATUS
--------- --------- ------------------------------------------------------------ ----------------
SERVER SCHEMANAME
------------------ ------------------------------------------------------------
OSUSER
------------------------------------------------------------
MACHINE
----------------------------------------------------------------------------------------------------
PROGRAM
------------------------------------------------------------------------------------------------
DEDICATED SYS
ora
host.oralinux.com
oracle@host.oralinux.com (CKPT)

5 1 ACTIVE
DEDICATED SYS
ora
host.oralinux.com
oracle@host.oralinux.com (SMON)

35 34715 user INACTIVE
DEDICATED user

SID SERIAL# USERNAME STATUS
--------- --------- ------------------------------------------------------------ ----------------
SERVER SCHEMANAME
------------------ ------------------------------------------------------------
OSUSER
------------------------------------------------------------
MACHINE
----------------------------------------------------------------------------------------------------
PROGRAM
------------------------------------------------------------------------------------------------
windows_user
NetBIOSDELL3100C-587
C:Program FilesMicrosoftOffice97OfficeMSACCE

↑　これが、KILLするべきセッション


SQL> ALTER SYSTEM KILL SESSION '35,34715';

システムが変更されました。


↑　上記でKILLできない場合や、速度に改善が見られない場合は
　　オラクルをシャットダウンしたほうが良いが、新しいoracle
　　のバージョンでは、svrmgrlが廃止になっている。その場合、
　　windowsのoracleツールをマネージャーモードで
　　インストールしている端末から、シャットダウンする。




ALTER SYSTEM KILLしたことにより、クエリーは
通常のタイムアウト設定60で更新成功するように
なった。

超大規模なテーブルの場合はプログラムで抽出条件を
絞り込むなど、込み入った作業が必要かも知れないが、
oracleが５万件程度の処理でハングするのはあり得ない。
（何か、別の問題が発生していると考えた方が良い。）

ユニフォーム姿三四郎の備忘録として、残しておく。


■２０１１．１１.０２　追記

DoCmd.RunSQL "INSERT INTO ・・・・・"

もしも、ＤＢに問題が無く、それでも上記のコマンドでタイムアウトに
なるようなら、インデックスを必要最小限に追加することや
ＳＱＬ文の見直しをすることが必要だと思う。それほど
複雑でないＳＱＬ文なのにタイムアウトするようなら
以下のようにCreateQueryDefに書き直すことで
解消できる問題かもしれない。

StrSQL1 = "INSERT INTO ・・・・・;"
Set qdf1 = db.CreateQueryDef("", StrSQL1)
qdf1.ODBCTimeout = 5000
qdf1.Execute



参考：
第10章 ロック競合の診断
http://www.geocities.jp/a1770053/jyoho/pt/chapter10.htm#10.2.3

ALTER SYSTEM KILL SESSION
http://www.confrage.com/oracle/oracle_sql/lock/alter_system_kill_session/alter_system_kill_session.html


☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
☆☆☆　　　　　　　　　　　　　　　　　　　　　☆☆☆
☆☆☆　ユニフォーム姿三四郎が紹介されています　☆☆☆
☆☆☆　　　　　　　　　　　　　　　　　　　　　☆☆☆
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆