トラブルは現場で起きている！トラブルシューティ...

Copyright Copyright ©©　　2007 Sumisho Computer Systems Corporation All rights reserved.2007 Sumisho Computer Systems Corporation All rights reserved.

トラブルは現場で起きている！トラブルシューティング・チューニング事例

住商情報システム株式会社関西支社製造システム営業部

伊藤勇樹

２００７年２月１６日

1Copyright Copyright ©©　　2007 Sumisho Computer Systems Corporation All rights reserved.2007 Sumisho Computer Systems Corporation All rights reserved.

本セミナーの目的

実際の現場で対応した事例をもとに、

特に効果が高かったトラブルシューティングや

チューニング情報をご紹介する。

運用の現場であまり知られていない情報を

ご紹介する。


AGENDA

アプリケーションサーバのトラブルシューティング事例

データベースのトラブルシューティング事例

運用の現場ですぐに利用できるノウハウ


アプリケーションサーバのトラブルシューティング事例

Case1：OC4Jのレスポンス悪化

Case2：OC4Jのハングアップ


トラブル事例その１　OC4Jのレスポンス悪化

OC4Jのレスポンスが悪い。アクセスが集中する９時から

１０時にかけてオンラインレスポンスが極端に悪くなる。通常１秒以内に返ってくる画面も１分近く返ってこない。

現象

・APサーバのCPUは高負荷状態である。(sarのusrが高い)・DBサーバのCPUはある程度余裕がある。・OC4Jのアクセスログが断続的に完全停止する。・FullGCの発生頻度が高い。

・新規アプリケーションを最近導入した。

調査

FullGCが短時間に複数回発生していることが原因。FullGCが発生している間はアプリケーションが完全停止

してしまうため、結果としてレスポンス遅延につながった。

新規アプリケーションを導入したことによって、FullGCの発生頻度が増加し、問題が顕在化した。

原因

JVMのヒープサイズのチューニングを実施。ヒープ領域を大きくし、FullGCの発生頻度を減らした。

対応

JVMにて短時間に複数回FullGCが発生

LB

Apache

OC4J

Apache

OC4J


トラブル事例その１　 OC4Jレスポンス悪化の対応詳細

‒ JVMヒープ領域の拡張

java –server –Xmx1024M -Xms1024M -jar orion.jar

FullGCFullGC

①新規アプリケーション導入によりMinorGCによる　　OLD領域への殿堂入りオブジェクトの数が増えた。

②殿堂入りオブジェクトの数が増え、その結果FullGCの回数が増えた。NEW OLDJVM

オブジェクトを格納する余裕ができ、FullGCの発生頻

度が減り、パフォーマンスアップ。

ヒープ領域拡張時のポイント！・動的拡張を防ぐためXmｘとXmsは同じサイズにする。

・物理メモリの範囲内にする。・大きくし過ぎるとGCにかかる時間が増え

　逆にパフォーマンスダウンにつながるので注意

ヒープ領域(Xmx)

NEW OLDJVM

対応

現象


トラブル事例その２　OC4Jがハングアップ

OC4JがOutOfMemoryを出力後、ハングアップ。

再起動で復旧。

現象

・APサーバのCPUは高負荷状態である。・DBサーバのCPUはある程度余裕がある。

・OC4Jのアクセスログが完全停止する。・FullGCが間髪おかずに連続して発生する。

・新人が配属され、利用ユーザが増えた。

調査

New領域の中のSurvivor領域の容量がEden領域に比べて小さかったため、GCが発生した際にEden領域からSurvivor領域にデータが格納されることなく、Old領域に移動。その結果Old領域

への閾値が1となり、Old領域へのプロモートが多発し、その結果FullGCが頻発し、OC4Jがハングした状態となり、最終的に

OutOfMemoryが発生し、OC4Jがダウンした状況に。

原因

JVMのヒープサイズのチューニングを実施。New領域の中のSurvivor領域のEden領域の割合(SurvivorRatio)を大きくし、閾値が32から1に下がることのないように設定。

対応

JVMにて短時間にFullGCが連続して発生。最終的にOutOfMemoryが発生し、ハングアップ

LB

Apache

OC4J

Apache

OC4J


トラブル事例その２　 OC4Jハングアップの対応詳細

現象

ＳｕｒｖｉｖｏｒＲａｔｉｏを8から2に変更し、Ｓｕｒｖｉｖｏｒ領域を拡張した。その結果、eden領域からOLD領域へ直接

殿堂入りすることがなくなり、閾値が32のままとなり、OC4Jのハングアップがなくなった。

JVMNEW

OLDeden

survivor

NEWOLDeden

survivor

JVM

‒ survivor領域の拡張 java –server –Xmx1024M -Xms1024M -XX:SurvivorRatio=2 -jar orion.jar

利用ユーザが増え、GCの対象にならないオブジェクトが増えてきたことにより、survivor領域で32回のGCを

生き抜く前にｅｄｅｎから直接ＯＬＤ領域へ殿堂入りしてしまうオブジェクトが発生する。そうすると殿堂入りの閾値(Max Tenuring Threshold)が32から1に下がって

しまい、次から次へとＯＬＤ領域へ殿堂入りしてしまう。その結果ＦｕｌｌＧＣが頻発し、ＯＣ４Ｊがハングアップしてしまう。

対応


データベースのトラブルシューティング事例

Case3：レスポンス悪化

Case4：バッチ処理の遅延

Case5： DWH系バッチ処理の遅延

Case6： Oracleが一時的にハングアップ

Case7： Oracle停止の遅延

Case8：動的SQLが遅い

Case9： SQLが遅い

Case10： InterMediaTextの検索遅延


トラブル事例その３　Oracleのレスポンス悪化

・オンラインレスポンスが遅い。・バッチ処理も処理本数が増えていることもあり、　夜間処理時間内に終了しなくなってきた。

現象

・DBサーバのCPUはioが高い(sarのwio)。・一時表領域へのIO負荷が高い。・DISK SORTに関する統計情報の値が高い。

調査

SORT_AREA_SIZEがデフォルト設定のため、一時表領域へのIOが発生していることが原因。

原因

・見積もった上でinit.oraのSORT_AREA_SIZEを　デフォルトの64Kから10MBに拡張した。・PGA_TARGETを設定(Oracle9i以降)・個別にALTER SESSIONでSORT_AREA_SIZEを　最大値の2GBに設定した。・HASH JOINを利用しているSQLは　HASH_AREA_SIZEを最大値の2GBに設定した。

対応

UGA内のソート領域

サーバプロセス

データ表領域一時表領域

一時セグメント

ソートラン１

ソートラン１

ソートラン３

ソートラン２

SQL> SELECT name, Value FROM v$sysstatSQL> WHERE name LIKE ‘sorts%’;

NAME VALUE-------------------- ----------sorts (memory) 1470sorts (disk) 304sorts (rows) 424958

SORT_AREA_SIZE拡張のポイント！・物理メモリの範囲内にする。・ディスクソートに対するメモリソートの比率を５％以内にする。

VALUE----------

162423

435326


トラブル事例その４　バッチ処理の遅延

バッチ処理が次第に全体的に遅延し始めた。

現象

・アラートログに「Checkpoint not complete 」、　「 cannot allocate new log 」が出力。・IO負荷が高い。・ログスイッチが頻繁(約1分毎)に行われている。

調査

REDOログのサイズが小さくログスイッチが頻繁に行われたことに起因する以下の二つが原因。・チェックポイントが完了する前に次のログスイッチが行われ、チェックポイントが完了するまで待機状態になっている。

・アーカイブが完了していないロググループにスイッチしようとしたため、アーカイブが完了するまで待機状態になっている。

原因

・1時間に1度程度のログスイッチになるようにログサイズを拡張し、　チェックポイントの頻度を減少・初期化パラメータをチューニングし、チェックポイントをログスイッチの　タイミングでのみ実施するように変更。　LOG_CHECKPOINT_INTERVALをREDOログサイズよりも大きい値に設定　LOG_CHECKPOINT_TIMEOUT=0にして、時間ベースのCHECKPOINTを　無効にする。・REDOロググループを追加し、アーカイブの待機を発生しないようにした。

対応

REDO1a

REDO1b

REDO2a

REDO2b

REDO3a

REDO3b

ARC0

アーカイブログ

REDOログファイルが小さいため、頻繁にログスイッチが

発生。ログスイッチ時にチェックポイントが発生したが、前回のチェックポイントが完了していないため、待機が発生。

ログスイッチ時にREDOログのアーカ

イブが完了していないため、待機が

発生。

チェックポイントのチューニングのポイント・パフォーマンスとMTTR(インスタンスリカバリ時間)は　トレードオフの関係にあるため、システム要件により調整する。


集計後

テーブル

インデックス

集計前

ワークテーブル

トラブル事例その５　DWHバッチ処理の遅延

少量のテストデータでは問題なかったが、本番データにてデータウェアハウス系システムのバッチ処理時間に時間がかかる。

現象

・個別にALTER SESSIONでSORT_AREA_SIZEを最大値の2GBに

　設定した。

・インデックスを削除し、集計処理後にインデックスを作成・不要インデックスを削除　ALTER INDEX <index_name> MONITORING USAGEによって

　インデックスを監視し、バッチ処理、オンライン処理を実行して不要な　インデックスを確認後、削除。約1時間の短縮。

・不要なExtent拡張を実行させないように集計処理前のTruncate　文にREUSE STORAGE句を付与した。・ディスクIOの分散。

対応

・DBサーバのCPUはioが高い(sarのwio)。・一時表領域へのIO負荷が高い。

・DISK SORTに関する統計情報の値が高い。

・インデックスを張ったまま集計処理を実施している箇所があった。・インデックスを作成する時間がかかっている。

調査

集計処理

集計後

テーブル

インデックス１

インデックス２インデックス３インデックス４インデックス５

未使用

--インデックスの利用状況を監視する。SQL> ALTER INDEX インデックスn MONITORING USAGE;

--一通りのバッチ処理、オンライン操作を実施後、--インデックスの利用状況を確認。SQL> SELECT index_name,table_name,used FROM v$object_usage;

INDEX_NAME TABLE_NAME USE-------------- ------------ ---インデックス1 テーブル名 YESインデックス2 テーブル名 NOインデックス3 テーブル名 NOインデックス4 テーブル名 NOインデックス5 テーブル名 YES

・インデックスを集計処理後に作成

・不要インデックスの削除


トラブル事例その６　Oracleが一時的にハングアップ

オンライン利用時間帯にOracleが一時的に

ハングアップし、無応答状態に。

現象

・sqlplusのローカル接続でもアクセスできない。・library cacheラッチ、PEenqueue待機イベントが多発。・STATSPACKの高負荷sqlのレポートでは特に目立った　sqlがなかった。

調査

・バッチ処理にSQL共有化出来ていないものがあり、

夜間処理のうちに共有プールを使い果たしてしまった。そのため、library cacheラッチが多発し、高負荷時に無応答状態

になった。・Latch Freeのバグで、高負荷時に不必要にメモリをロック状態に

してしまう。

原因

・v$db_object_cacheを定期的に確認し、共有化されていないSQLを特定する。　そのSQLにバインド変数を利用し、共有化するチューニングを実施。・Latch Freeの個別パッチを適用。(8i)・CURSOR_SHARINGのパラメータは不具合に合致し、利用できなかった。(8i)

対応

SGA

共有プール

ライブラリキャッシュ

データディクショナリキャッシュ

ユーザグローバルエリア

LibraryCachelatch

SQL

--下記のSQLを定期的(1時間に1度程度)に実行し、spoolしておく。SQL> SELECT name FROM v$db_object_cacheSQL> WHERE namespace = 'CURSOR‘SQL> AND executions = 1– 実行回数が1回のSQLを調査SQL> ORDER BY name;

・共有化できていないSQLを調査する。

Ｓｑｌの共有化ができていないため、バッチ処理の間に1.4GBもの共有プールを100%使い切ってしまっている。ユーザ利用最繁期にはライブラリキャッシュの領域を取得するためにl ibrary cacheラッチが多発し、競合してハングしたような状況となった。


トラブル事例その７　Oracle停止の遅延

Oracle停止に時間がかかる。

現象

データファイルのディスク再配置、インターメディアテキストのインデックスをリビルドをしてから停止遅延が発生。約45分かかるようになった。

調査

原因不明。

原因

・データファイルを元のディスクに戻しても元に戻らなかった。その後、全文検索のインデックスをリビルドではなく、Dropし、その後表領域のコアレスを実施し、インデックスを再作成し、表領域の縮小を行ったところ、停止時間が10分程度になった。・REDOログファイルを再配置し、同一グループのメンバが同一ディスクにあったのを別ディスクに分散したところ、停止時間が短縮された。

対応


トラブル事例その８　動的SQLが遅い

動的SQLを利用したPLSQLが遅い。

現象

・DBMS_SQLを利用している。・動的SQLの中でバインド変数を利用せず、値を　直接SQLにハードコーディングしてしまい、SQLの

　再解析が発生している。

原因

・EXECUTE IMMEDIATEを利用。　⇒Oracle8iよりシステム固有の動的SQL の　　サポートがされている。・バインド変数を利用し、SQLを共有化。

対応

・DBMS_SQLを使用した例

BEGINstmt_str := 'INSERT INTO ' ¦¦ table_name ¦¦ 　　　　　　　' VALUES (:deptno, :dname, :loc)';cur_hdl := DBMS_SQL.open_cursor;DBMS_SQL.PARSE(cur_hdl, stmt_str,DBMS_SQL.NATIVE);DBMS_SQL.BIND_VARIABLE(cur_hdl, ':deptno', deptnumber);DBMS_SQL.BIND_VARIABLE(cur_hdl, ':dname', deptname);DBMS_SQL.BIND_VARIABLE(cur_hdl, ':loc', location);rows_processed := DBMS_SQL.EXECUTE(cur_hdl);DBMS_SQL.CLOSE_CURSOR(cur_hdl);END;/

BEGINstmt_str := 'INSERT INTO ' ¦¦ table_name ¦¦ 　　　　　　　' values (:deptno, :dname, :loc)';EXECUTE IMMEDIATE stmt_str　USING deptnumber, deptname, location;END;/

・EXECUTE IMMEDIATEを使用した例

Oracle8iアプリケーション開発者ガイドに以下の通りある。

「PL/SQL インタプリタにはシステム固有の動的SQL のサポートが組み込まれているため、PL/SQL でのシステム固有の動的SQL のパフォーマンスは、静的SQL のパフォーマンスと同等になります。このため、システム固有の動的SQL を使用するプログラムは、DBMS_SQLパッケージを使用するプログラムよりもパフォーマンスが向上します。通常、システム固有の動的SQL 文では、DBMS_SQL パッケージを使用する同等の文よりも1.5 ～ 3 倍パフォーマンスが向上します。もちろん、パフォーマンスの向上は、アプリケーションによっても異なる可能性があります。」

プログラムの可読性も高く、パフォーマンスもいい！


トラブル事例その８　動的SQLが遅い　詳細

DECLARETYPE cur_typ IS REF CURSOR;c cur_typ;

query_str VARCHAR2(1000);w_dname dept.dname%TYPE;

CURSOR c_emp ISSELECT deptnoFROM emp;

cr_emp c_emp%ROWTYPE;

BEGINFOR cr_emp IN c_emp LOOPquery_str := 'SELECT dname FROM dept WHERE deptno = '¦¦ cr_emp.deptno ;OPEN c FOR query_str;LOOPFETCH c INTO w_dname ;EXIT WHEN c%NOTFOUND OR c%NOTFOUND IS NULL;DBMS_OUTPUT.put_line(cr_emp.deptno ¦¦ ',' ¦¦ w_dname);

END LOOP;CLOSE c;

END LOOP;END;/

query_str := 'SELECT dname FROM dept WHERE deptno = :deptno' ;OPEN c FOR query_strUSING cr_emp.deptno;

修正

Bind変数を使用し、sqlを共有化


トラブル事例その９　SQLが遅い

UNIONを利用したSQLが遅い。

現象

重複がないにもかかわらずUNIONを利用しているため。UNIONを利用すると、重複排除のためにソート処理が実行される。

原因

・重複しないことが分かっているなら、UNION ALLを　利用するように変更

対応


SQL> select token_text from dr$test_i$i;

TOKEN_TEXT

-----------あいいううえ

えおおあいいう

う

トラブル事例その１０　InterMediaTextの検索遅延

たった２万件のデータに対するinterMediaTextを利用した

全文検索に時間がかかるようになってきた。

現象

インデックスのREBUILDを最適化ではなく、同期化(SYNC)を実施していたために、重複するトークンが増えて、トークンを格納しているdr$<tablename>$Iというテーブルのデータ件数が４３００万件にもなり、

検索に時間がかかった。

原因

同期化に比べ、最適化は時間がかかるため、通常は同期化を実施し、サービス停止日前日は最適化を実施するように変更。

対応

IMTインデックス

dr$<tablename>$I

TOKEN_TEXT-----------あい

いうううええお

お

ALTER INDEX <indexname> REBUILD PARAMETERS('sync memory 10M');

同期化

ALTER INDEX <indexname> REBUILD PARAMETERS('optimize full');最適化

InterMediaTextの最適化が必要な指標select count(*) from dr$<tablename>$i; の結果から

select distinct(token_text) from dr$<tablename>$i; の結果を割り算し、もし比が3:1以上だったら最適化を実施する。


運用の現場ですぐに利用できるノウハウ

運用の現場で利用できるノウハウのご紹介

1. PL/SQLのパフォーマンス・ボトルネックを検出する方法

2. Oracleのオブジェクトを再作成したり、MOVEした場合に必要となる作業

3. アラートログの監視するべき内容


運用の現場ですぐに利用できるノウハウ（１－１）

PL/SQLのパフォーマンス・ボトルネックを検出する方法

・プログラムに時間出力のデバッグログを埋め込む。①秒単位の場合は、SYSDATEを利用。②1/100秒単位の場合は、DBMS_UTILITY.GET_TIMEを利用。

従来から現場でよく利用されている方法

・プログラムを修正する必要がある。・長いプログラムの場合、ボトルネックを特定するのに時間がかかる。

従来の方法の問題点

・DBMS_PROFILERを利用する。

・デバッグログをプログラムに埋め込む必要がない。・プログラムの各行の実行回数が分かる。・プログラムの各行の実行時間が分かる。

解決方法


運用の現場ですぐに利用できるノウハウ（１－２）

事前準備

‒ DBMS_PROFILERパッケージのインストール

‒ テストを実行するスキーマに、プロファイラが使用するテーブルを作成

テストの実行‒ 調査対象プログラム実行前後にDBMS_PROFILERのプロシジャを実行するだけ

SQL> DECLARE2 err number;3 BEGIN4 err:=DBMS_PROFILER.START_PROFILER (TO_CHAR(SYSDATE,'dd-Mon-YYYY hh:mi:ss'));5 <プロシージャ名>; -- 対象となるプロシージャ名6 err:=DBMS_PROFILER.STOP_PROFILER;7 END;8 /

% sqlplus "/ as sysdba"SQL> @$ORACLE_HOME/rdbms/admin/profload.sql

% sqlplus ユーザー名/パスワードSQL> @$ORACLE_HOME/rdbms/admin/proftab.sql


運用の現場ですぐに利用できるノウハウ（１－３）

プロファイル対象のrunid を取得

プロファイリング結果の取得

SQL> column RUN_COMMENT format a40SQL> select runid, run_date, RUN_COMMENT from plsql_profiler_runs order by runid;

RUNID RUN_DATE RUN_COMMENT---------- -------- ----------------------------------------

1 03-04-04 04-Apr-2003 08:02:472 03-04-04 04-Apr-2003 08:17:22

SQL> column unit_name format a15SQL> column occured format 999999SQL> column line# format 99999SQL> column tot_time format 999.999999SQL> column text format a40SQL> select p.unit_name, p.occured, p.tot_time, p.line# line,2 substr(s.text, 1,75) text3 from4 (select u.unit_name, d.TOTAL_OCCUR occured,5 (d.TOTAL_TIME/1000000000) tot_time, d.line#6 from plsql_profiler_units u, plsql_profiler_data d7 where d.RUNID=u.runid and d.UNIT_NUMBER = u.unit_number8 and d.TOTAL_OCCUR >09 and u.unit_name = 'プロシージャ名' 10 and u.runid = 2) p, --このrunid の値は、上記で取得したrunidとして下さい10 user_source s11 where p.unit_name = s.name(+) and p.line# = s.line (+)12 order by p.unit_name, p.line#;


運用の現場ですぐに利用できるノウハウ（１－４）

実行結果を確認する

OCCURED：当該行(LINE列で表される)が実行された回数

TOT_TIME：当該行の実行に要した総時間(単位:秒)

UNIT_NAME OCCURED TOT_TIME LINE TEXT--------------- ------- ----------- --------------------------------------------------NUMBER_TEST 1 .000004 2 n number:=1;NUMBER_TEST 1 .000002 3 b binary_integer:=1;NUMBER_TEST 1 .000001 4 p pls_integer:=1;NUMBER_TEST 1001 .003780 7 FOR i IN 1..1000 LOOPNUMBER_TEST 1000 .003821 8 n:=n+1;NUMBER_TEST 1000 .005015 9 b:=b+1;NUMBER_TEST 1000 .003338 10 p:=p+1;NUMBER_TEST 1000 .003207 11 dummy:='counts for ENDLOOP';NUMBER_TEST 1 .000003 13 dummy:='end of PLSQL';NUMBER_TEST 1 .000005 14 END;

PLS_INTEGERの演算が

最も早いことが分かる


運用の現場ですぐに利用できるノウハウ（２－１）

Oracleのオブジェクトを再作成したり、MOVEした場合に必要となる作業

‒ 列追加などでテーブルなどのオブジェクトを再作成したり、領域再編成のためにテーブルをMOVEするのは非常に危険な作業。

‒ 以下の危険性をはらんでいる。

インデックスの作成漏れ

権限の付与漏れ

統計情報の取得漏れ

INVALIDオブジェクトの再コンパイル漏れ

マテリアライズドビューログのクリア漏れ(完全リフレッシュ漏れ)

‒ 問題を発生させないために、バックアップを取得し、作業前後に確認作業を行い、漏れがある場合は個別に対応する。


運用の現場ですぐに利用できるノウハウ（２－２）

作業手順

1. エクスポートバックアップを実施

2. インデックス確認

再作成対象のテーブルの現在のインデックス情報を確認しておく。テーブル再作成後、もともとあったインデックスが正しく作成されていることを確認するために使用する。

3. 権限の確認

以下のSQLを実行し、権限付与スクリプトを作成する。テーブル再作成後に使用する。

SQL> SELECT * SQL> FROM user_indexes SQL> WHERE table_name = UPPER('${TABLE_NAME}');

SQL> SELECT * SQL> FROM user_ind_columns SQL> WHERE table_name = UPPER('${TABLE_NAME}') SQL> ORDER BY index_name,column_position;

SQL> SELECT 'GRANT ' ¦¦ PRIVILEGE ¦¦ ' ON ' ¦¦ LOWER(TABLE_NAME) ¦¦ ' TO ' ¦¦ LOWER(GRANTEE) ¦¦ ';' SQL> FROM user_tab_privs SQL> WHERE table_name = UPPER('${TABLE_NAME}');


運用の現場ですぐに利用できるノウハウ（２－３）

4. 統計情報の確認

以下のSQLを実行し、統計情報作成スクリプトを作成する。テーブル再作成後に使

用する。

5. オブジェクトステータスの確認

現在のステータスがINVALIDのオブジェクトを確認しておく。テーブル再作成後にINVALIDになったオブジェクトを確認するために使用する。

SQL> SELECT 'ANALYZE TABLE ' ¦¦ LOWER(table_name) ¦¦ ' COMPUTE STATISTICS;' SQL> FROM user_tables SQL> WHERE table_name = UPPER('${TABLE_NAME}') SQL> AND last_analyzed IS NOT NULL;

SQL> SELECT 'ALTER ' ¦¦ DECODE(object_type,'UNDEFINED','MATERIALIZED VIEW','PACKAGE BODY','PACKAGE',object_type) ¦¦SQL> 　　　　' ' ¦¦ LOWER(object_name) ¦¦ ' COMPILE ' ¦¦ SQL> 　　　　DECODE(object_type,'PACKAGE','PACKAGE','PACKAGE BODY','BODY',NULL) ¦¦ ';' SQL> FROM user_objects SQL> WHERE status = 'INVALID' SQL> ORDER BY 1;


運用の現場ですぐに利用できるノウハウ（２－４）

6. マテリアライズドビューログの確認‒ 以下のSQLを実行し、削除対象のテーブルに作成されているマテリアライズドビュー

ログを使用しているマテリアライズドビューの完全リフレッシュスクリプトを作成する。テーブル再作成後に使用する。

7. 対象オブジェクトの再作成（DROP&CREATE）

8. インデックス確認‒ ２で実行したSQLを再度実行し、先ほど取得した結果と同じになることを確認する。

9. 権限付与‒ ３で取得した権限付与のSQLを実行する。その後３で実行したSQLを再度実行し、

先ほど取得した結果と同じになることを確認する。

10. 統計情報作成‒ ４で取得した統計情報取得のSQLを実行する。その後４で実行したSQLを再度実行

し、先ほど取得した結果と同じになることを確認する。

SQL> SELECT 'SID = ' ¦¦ r.snapshot_site ¦¦ ' USER= ' ¦¦ r.owner ¦¦ ' にて次のスクリプトを実行 : ' ¦¦SQL> 　　　　'EXECUTE DBMS_MVIEW.REFRESH(''' ¦¦ r.name ¦¦ ''' , ''C''); ' SQL> FROM user_registered_snapshots r,user_snapshot_logs l SQL> WHERE r.snapshot_id=l.snapshot_id SQL> AND l.master = ${TABLE_NAME}


運用の現場ですぐに利用できるノウハウ（２－５）

11. オブジェクトのリコンパイル

‒ ５で実行したSQLを再度実行し、先ほど取得した結果と差分を取得する。差分が出

たSQLを実行し、リコンパイルを行う。再度差分がなくなったことを確認する。

12. マテリアライズドビューの完全リフレッシュ

‒ ６で取得したマテリアライズドビューの完全リフレッシュのSQLを実行する。その後、以下のSQLを実行し、last_refresh_typeが「COMPLETE」に、last_refresh_dateが「実行日時」に、compile_stateが「VALID」になっていることを確認する。

SQL> SELECT mview_name,last_refresh_type,TO_CHAR(last_refresh_date,'YYYY/MM/DD HH24:MI:SS'),compile_stateSQL> FROM user_mviewsSQL> WHERE mview_name = ６で取得したmview名;


運用の現場ですぐに利用できるノウハウ（３）

アラートログはORA-XXXXXの監視だけでは足りない！

アラートログの監視するべき内容

– checkpoint not complete– cannot allocate new log

現象：新規接続ができなくなったり、既存のセッションがハング状態になったりする。

対応：(1)オンライン・ログの数や大きさを変更する

(2)初期化パラメータによるチェックポイント発生頻度の調整

(3)ディスクIOの調整(REDOログとアーカイブログのディスクを分ける等)

– Archiving not possible: No primary destinations 現象：新規接続ができなくなったり、既存のセッションがハング状態になったりする。

対応：(1)アーカイブログ先のディレクトリの空き容量を確保する。

(2) ALTER SYSTEM ARCHIVE LOG START ;(3)空き容量を確保次第、アーカイブが開始されるように、

　　　　　　　　LOG_ARCHIVE_DEST_nにREOPENオプションを指定しておく。

– kccrsz: denied expansion of controlfile section 9 by 65535 record(s) ... 現象：control_file_record_keep_timeで指定された日数を経過していない情報を上書きしてしまう。

対応：オンライン・ログを大きくし、ログスイッチの間隔を減らす。

– WARNING: EINVAL creating segment of size ... 対応：カーネルパラメータSHMMAXの値をSGAの最大サイズよりも大きく設定する

トラブルは現場で起きている！ トラブルシューティ...

Documents

トラブルは現場で起きている！トラブルシューティ...