2010-02-08 Mon
「何も選ばない」生き方のすすめ

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
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆
☆☆☆ ☆☆☆
☆☆☆ ユニフォーム姿三四郎が紹介されています ☆☆☆
☆☆☆ ☆☆☆
☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

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) | ユニフォーム姿三四郎::備忘録 |
