NEW ENTRIES
COMMENTS

ORA-01013 AccessからのODBC接続
    「何も選ばない」生き方のすすめ



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

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

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


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

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

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

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

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

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


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

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



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



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


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行が選択されました。

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


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が5万件程度の処理でハングするのはあり得ない。
(何か、別の問題が発生していると考えた方が良い。)

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


■2011.11.02 追記

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

もしも、DBに問題が無く、それでも上記のコマンドでタイムアウトに
なるようなら、インデックスを必要最小限に追加することや
SQL文の見直しをすることが必要だと思う。それほど
複雑でないSQL文なのにタイムアウトするようなら
以下のように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


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








| ユニフォーム姿三四郎 | 10:06 | comments (x) | trackback (x) | ユニフォーム姿三四郎::備忘録 |
このページの先頭へ
CALENDAR
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28       
<<前月 2010/02 次月>>
ARCHIVES
LOGIN
現在のモード: ゲストモード
USER ID:
PASS:
POWERED BY
POWERED BY
ぶろぐん
SKIN BY
ゲットネット...¥
OTHERS


このページの先頭へ