• ベストアンサー

INDEX作成による更新系の影響範囲

環境：Oracle9i 9.2.0.1 言語：VB6 システム：受注管理システム ある業務アプリの性能改善の為、顧客マスタにインデックスを作成したいのですが、更新系の処理が遅くなることを嫌ってなかなか承認が下りないです。 そんなに負荷はかからないと思うのですが、実際インデックスを１つ作成するとどの程度影響があるのか客観的に証明できないから困っています。 上記の業務アプリは毎日使用しています。 データ件数は100万件程度です。 参考までにインデックス作成前のINSERT文実行した実行計画とインデックス作成後のINSERT文実行した実行計画を記述します。 作成前 統計 ---------------------------------------------------------- 86 recursive calls 26 db block gets 14 consistent gets 29 physical reads 2956 redo size 628 bytes sent via SQL*Net to client 825 bytes received via SQL*Net from client 3 SQL*Net roundtrips to/from client 4 sorts (memory) 0 sorts (disk) 1 rows processed 実行後 統計 ---------------------------------------------------------- 281 recursive calls 27 db block gets 73 consistent gets 20 physical reads 3044 redo size 633 bytes sent via SQL*Net to client 825 bytes received via SQL*Net from client 3 SQL*Net roundtrips to/from client 7 sorts (memory) 0 sorts (disk) 1 rows processed そんなに影響がないということを証明したいのですが、上記統計で大したことないと証明できますでしょうか？

  • Oracle
  • 回答数2
  • ありがとう数1

質問者が選んだベストアンサー

  • ベストアンサー
  • entree
  • ベストアンサー率55% (405/735)
回答No.2

索引に指定するキーの数や更新頻度にもよるでしょうが、１キーや２キー索引くらいでは SQL*Loader 等で大量のデータをロードしたりするような処理がない限り、たかが１００万件程度で極端な性能劣化が起こるということはまずありません。 ただし、SELECT 時に作成した索引が効率的に使用されるかどうかも含めて、検証環境などで性能試験をされることを強くお勧めします。 statspack ユーティリティなどもインストールして、ディスク I/O 等にも注目してみてください。

その他の回答 (1)

回答No.1

この実行計画の結果からではないのですが、 インデックスの作成前と作成後のSELECTとINSERTの ベンチマークを実施（もちろんテスト環境で）して INSERTでの時間差がそれほど無い事、SELECTを実行したときのパフォーマンスの改善したことを提示してみてはいかがでしょうか？

  1. カテゴリ
  2. [技術者向] コンピューター
  3. データベース
  4. Oracle

関連するQ&A

  • 統計情報について

    以下の統計情報ですが、各項目が具体的にわかる資料は何を見たらわかりますか？ ちなみに「consistent gets」が多いと重いのかなぁと考えてる程度の知識です。 宜しくお願いします。 ---------------統計情報------------------------ 統計 ---------------------------------------------------------- 187 recursive calls 0 db block gets 176479 consistent gets 63028 physical reads 0 redo size 391 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 1 rows processed ---------------統計情報------------------------

  • レスポンスをよくするには？

    こんにちは。 最近ずっと仕事でシステムのレスポンスの改善を行っています。 ログをとり、VIEWが遅いのはわかりました。 INDEXを貼ってみたりヒント文を使ってみたりしたのですが、 なかなか早くなりません。 コストが現在2693あります。 これを100未満にしたいのですが・・・ 使っているテーブルは２つあり、 両方ともデータ件数は100万件ほどあります。 それぐらいの件数になると、コストはどうしても増えてしまうのでしょうか？ こうしたら早くなるのでは？等の 案があったら教えてください、お願いします。 VIEWの中のSQL部 SELECT TP.STATUS , TP.DENPYO_NO, TP.EDABAN, JH.USER_ID FROM (SELECT P.DENPYO_NO, P.EDABAN, P.STATUS FROM TBL_CHOHYO_KANRI P WHERE P.HAKO_KBN = '99') TP ,(SELECT J.DENPYO_NO, J.EDABAN FROM TBL_DENPYO_RIREKI J) JH WHERE JH.DENPYO_NO = TP.DENPYO_NO AND JH.EDABAN = TP.EDABAN ; 実行計画 ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2693 Card=33854 By tes=1117182) 1 0 HASH JOIN (Cost=2693 Card=33854 Bytes=1117182) 2 1 TABLE ACCESS (FULL) OF 'TBL_CHOHYO_KANRI' (TABLE) (Cost=2 027 Card=127611 Bytes=2424609) 3 1 INDEX (FAST FULL SCAN) OF 'IDX$$_2CCE0006' (INDEX) (Cost =157 Card=203124 Bytes=2843736) 統計 ---------------------------------------------------------- 11 recursive calls 0 db block gets 9812 consistent gets 11039 physical reads 0 redo size 7925659 bytes sent via SQL*Net to client 147915 bytes received via SQL*Net from client 13403 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 201021 rows processed

  • Oracle 実行計画の読み方

    コメントあれば、よろしくお願い致します。 0 recursive calls 0 db block gets 7,800,000 consistent gets --select文でアクセスしたバッファキャッシュのブロック数。ディスクとメモリへの総アクセス数　A 3,500,000 physical reads --ディスク上のデータファイルにアクセスしたデータ要求の総ブロック数　B 0 redo size 219,000,000 bytes sent via SQL*Net to client 7,100,000 bytes received via SQL*Net from client 500,000 SQL*Net roundtrips to/from client 100 sorts (memory) --メモリ内でソートした回数　C 0 sorts (disk) 9,200,000 rows processed --処理対象となった行数　D 一番、重視しなければいけないのは、A だと思っています。 780万回もアクセスされていますが、 ブロック数が 8K に設定されている環境であったとして、 1024*8*780万 = 63,897,600,000約 63GB の i/o が一つのSQLで発生 B に関しても一応計算してみると、 1024*8*350万 = 28,672,000,000約 28GB の i/o が一つのSQLで発生 D に関しては、920万行という結果は分かるが、1行辺りの幅が分からないので、 幅を別途SQLから計算し、どういった負荷を与えている文なのかを分析する必要がある。 select statement optimizer=choose からの数十行には、 (FULL)が、(UNIQUE INDEX)に比較して、10倍ぐらい表示されていると仮定します。 それぞれの検索テーブルの件数ははっきりしていたとして(1件～2000万件ぐらい(400万件以上が5テーブル))、 何をどうするのがSQLチューニングでしょうか。

  • MySQLのインデックスについて

    MySQLのインデックスについて 以下のSQLにてお聞きしたいことがあります。 SELECT * FROM table1 WHERE num = '1' numはint型でインデックスを作成済の列なのですが、 問い合わせでは'1'のように文字列型で条件指定しています。 この場合、numに対するインデックスは効くでしょうか？ よろしくお願い致します。 追伸 なぜこのような質問をさせて頂くかと申しますと、 私は開発環境でZend Frameworkを使用しておりまして、 その中のZend_Dbを使用しているのですが、 名前つきパラメータを使用してSQLを実行した場合に、 実際の実行されているSQLではどのパラメータも、 シングルクォーテーションで囲われているのではと思うんです。 以前、SQL実行に失敗して出力されたエラーメッセージの一部に、 実際に実行されたSQLが記述されていたのですが、 数値型の列もシングルクォーテーションで囲われていたんです。 もしかしたら名前つきパラメータを使用すると、 すべてのパラメータが文字列型扱いされているのではと思い、 こちらに投稿させて頂きました。

    • ベストアンサー
    • MySQL
  • DATE型カラムのインデックスが効かない

    Oracle初心者です。 以下のような2種類のSQLをSQLPLUSで実行し、 実行計画を取得しました。 end_timeでfilterをかける際に、"TABLE ACCESS FULL"となっており、貼っているインデックスが使われていないことがわかりました。 ＃これがSQLの遅い主要因と考えています。。。。勘です。 インデックスが活用されていない原因としてはどのようなものが考えられるのでしょうか。 宜しくお願いいたします。 １） set autotrace traceonly select * from t_sample where end_time >= '2009-08-25' and end_time <= '2009-11-26' ２） set autotrace traceonly select * from t_sample where end_time >= to_date('2009-08-25', 'yyyy-mm-dd') and end_time <= to_date('2009-11-26', 'yyyy-mm-dd')

  • 最適なインデックス作成

    いつもお世話になってます。 下記のSQLがあるとします。 SELECT A.COL3, A.COL4, B.COL5, SUM(A.COL6) -- (5) FROM TABLE1 A INNER JOIN TABLE2 B ON A.COL1 = B.COL1 -- (2) WHERE -- (1) A.COL1 = '1' AND A.COL2 = '2' GROUP BY A.COL3 ,A.COL4　-- (3) ORDER BY A.COL3, A.COL4　-- (4) 番号はSQLが内部処理(絞りこみやソート)される順番とも考えています。 この場合にてインデックスを作成する場合 「TABLE1 A」に IND1（A.COL1,A.COL2,A.COL3,A.COL4,A.COL6） ON TABLE1 の複合インデックスを作成すべきか、それとも番号単位に個別に索引を作成した方が良いのか悩んでいます。 番号単位だと例えば IND1（A.COL1,A.COL2） IND2（A.COL3,A.COL4） IND3（A.COL6） アドバイスなどあればよろしくお願いします。

  • INDEXの仕様

    PostgreSQL8.1.1（RedHatLinux）にて テーブルのtext列に対してindexを作成しました。 作成した列に対して、LIKE検索を行っております。 しかし、「EXPLAIN」を利用してSQLの実行計画を見たんですが、 「Seq Scan」からしか始まらず、 「Index Scan」という文字が見当たりません。 PostgreSQLにてindexを張った列に対するLIKE検索では、 indexは使用されないのでしょうか？

  • インデックスを使用して・・・

    おはようございます。 SQLServerのテーブルに格納された情報が多いので インデックスを用いて検索処理を早めたいと考えました。 ---テーブル構成-------------- name / varchar address / varchar age / int ---------------------------- name,addressフィールドにインデックスを指定したのですが、 インデックスを指定することにより検索するSQL文に なにか特別な書き方をしなくてはいけないのでしょうか？ select name, address, age from test_table; ってSQLを記述しただけでは、 インデックスを作成する前と後では意味はないのでしょうか？ 宜しくお願い致します。m(_ _)m

  • ORACLEのインデックスについて

    現在、ORACLE9を使用しているのですが INDEXについて理解できないことがあったので 教えてください。 組織、社員という2つしか項目を持たない 従業員という表があり600件ほどのデータがあります。 変更前は、 ・組織、社員にユニークインデックスは作成されていた。 ・600件ほどのデータの組織は全て同一。 となっており、その状態で select * from 従業員 where 組織 = 'ALL' and 社員 = '001' を流すとFULL　SCANになっていました。 FULL　SCANを回避できないかと思い、社員のみのインデックスを 追加し（* 一番下にインデックス追加時のSQLをはっています） 　select * from 従業員 where 組織 = 'ALL' and 社員 = '001' を流すと追加したインデックスを読んでいました。 既に作成されていたユニークインデックスと異なるインデックスが 追加されたのかと思い、DBA_INDEXESの中を確認しましたが 異なっているのは、 ・UNIQUENESS ・INITIAL_EXTENT（ユニークインデックスは24576、 　追加したインデックスは40960） ・LEAF_BLOCKS（ユニークインデックスは3、 　追加したインデックスは2） の3点のみでした。 なぜこのような動きになるか理解できず、今後の対応に 迷っています。 ・原因 ・調査したらいい場所 ・参考資料 などがありましたら教えてください。 よろしくお願いします。 (*) インデックス追加時のSQL文は、create index 従業員A on 従業員 (社員) tablespace index storage (initial 40000 next 100000 maxextents unlimited pctincrease 0) pctfree 10となっています。

  • ビューにインデックスを設定できませんか？

    SQL Server 2005 EXPRESS を使用しています。 トランザクションのテーブルにマスタを結合して表示するビューを作成しました。 実際に利用する時はトランザクションテーブルの主キーを検索に多用すると予想されるので、該当のフィールドにインデックスを設定したいのですが… Management Studio　でインデックスを設定しようとするとエラーになります。 エラーメッセージは インデックス '' の作成に失敗しました。 (Microsoft.SqlServer.Express.Smo) ------------------------------ ADDITIONAL INFORMATION: Transact-SQL ステートメントまたはバッチの実行中に例外が発生しました。 (Microsoft.SqlServer.Express.ConnectionInfo) ------------------------------ ビュー 'View' に インデックス を作成できません。ビューにはスキーマがバインドされていません。 (Microsoft SQL Server, Error: 1939) となっています。まさにメッセージのとおりだとは思うのですが 「ビューにスキーマをバインドする」方法がわかりません。 どなたかご教授いただければ助かります。 よろしくお願いいたします。

注目のQ&A

カテゴリ

専門家に質問してみよう

職業から探して質問する

あなたにピッタリな商品が見つかる！ OKWAVEセレクト

質問する