2

(データベース: Oracle 10G R2)

100,000 レコードをテーブルに挿入するのに 1 分かかります。ただし、テーブルに既にいくつかのレコード (400K) が含まれている場合は、4 分 12 秒かかります。また、CPU 待機が急増し、「Free Buffer Waits」が非常に高くなります (dbconsole から)。

ここで何が起こっているか知っていますか?これは、テーブルのエクステントが頻繁に発生するためですか? これらのテーブルのエクステント サイズは 1,048,576 バイトです。DB がテーブル ストレージを拡張しようとしているような気がします。

私はこれについて本当に混乱しています。だから、どんな助けも素晴らしいでしょう!


これは挿入ステートメントです。

始める
  for i in 1 .. 100000 ループ
    顧客に挿入
                (id、ビジネス名、住所 1、
                 住所2、都市、
                 郵便番号、州、国、ファックス、
                 電話、メール
                )
         値 (customer_seq.nextval、dbms_random.string ('A'、20)、dbms_random.string ('A'、20)、
                 dbms_random.string ('A', 20), dbms_random.string ('A', 20),
                 trunc (dbms_random.value (10000, 99999)), 'CA', 'US', '798-779-7987',
                 「798-779-7987」、「asdfasf@asfasf.com」
                );
  ループを終了します。
終わり;

ここでのdstat出力 (CPU、IO、MEMORY、NET):

  1. 空のテーブルの挿入: http://pastebin.com/f40f50dbb
  2. 400K レコードのテーブル: http://pastebin.com/f48d8ebc7

からの出力v$buffer_pool_statistics

ID: 3
名前: デフォルト
ブロックサイズ: 8192
SET_MSIZE: 4446
CNUM_REPL: 4446
CNUM_WRITE: 0
CNUM_SET: 4446
BUF_GOT: 1407656
SUM_WRITE: 1244533
SUM_SCAN: 0
FREE_BUFFER_WAIT: 93314
WRITE_COMPLETE_WAIT: 832
BUFFER_BUSY_WAIT: 788
FREE_BUFFER_INSPECTED: 2141883
DIRTY_BUFFERS_INSPECTED: 1030570
DB_BLOCK_CHANGE: 44445969
DB_BLOCK_GETS: 44866836
CONSISTENT_GETS: 8195371
PHYSICAL_READS: 930646
PHYSICAL_WRITES: 1244533


アップデート

このテーブルからインデックスを削除したところ、100K を 600K レコード テーブルに挿入してもパフォーマンスが大幅に向上しました (CPU 待機なしで 47 秒かかりました - dstat の出力http://pastebin.com/fbaccb10を参照)。

4

7 に答える 7

5

これが Oracle でも同じかどうかはわかりませんが、SQL Server で最初にチェックするのは、テーブルにいくつのインデックスがあるかです。大量の場合、DB は、レコードが挿入されるときにテーブルのインデックスを再作成するために多くの作業を行う必要があります。100k よりも 500k 行を再インデックス化する方が困難です。

于 2009-02-26T04:02:49.020 に答える
1

インデックスがあっても、100,000 レコードを挿入するのに 4 分かかるのは私には問題のように思えます。

このデータベースに I/O の問題がある場合は、それらを修正していないため、再び表示されます。根本原因を特定することをお勧めします。

インデックス DDL を投稿する場合は、比較のために時間を計ります。


id と business_name にインデックスを追加しました。ループで 10 回の反復を実行すると、100,000 行あたりの平均時間は 25 秒でした。これは、すべて単一のディスクで実行されている自宅の PC/サーバー上にありました。

于 2009-02-26T12:21:43.873 に答える
1

インデックスは何らかの形式のツリーです。つまり、レコードを挿入する時間は O(log n) になります。ここで、n はツリーのサイズ (≈ 標準の一意のインデックスの行数) です。

それらを挿入する最も速い方法は、既にわかっているように、挿入中にインデックスを削除/無効にし、後で再作成することです。

于 2009-02-26T05:40:12.390 に答える
1

パフォーマンスを向上させるもう 1 つの方法は、シーケンス (customer_seq) でキャッシュをオンにするか、キャッシュを高く設定することです。これにより、オラクルは、挿入ごとにオブジェクトをヒットする代わりに、シーケンスをメモリに割り当てることができます。

ただし、これには注意してください。状況によっては、これによりシーケンスの値間にギャップが生じることがあります。

詳細はこちら: Oracle/PLSQL: Sequences (Autonumber)

于 2009-03-01T19:25:10.227 に答える
0

どの列にインデックスが付けられているかはわかりません。ファックス、電話、または電子メールにインデックスがある場合は、多数の重複 (つまり、すべての行) があったでしょう。Oracle は、一意でないインデックスを持つように「ふりをします」。実際には、すべてのインデックス エントリは一意であり、実際のテーブル行の ROWID が決定要因となります。行 ID は、ファイル/ブロック/レコードで構成されます。

特定の数のレコードにヒットすると、新しいレコードがROWIDを取得していた可能性があります。これは、多くのインデックスの再書き込みが行われている既存のインデックスの真ん中に収まらなければならなかったことを意味します.

完全なテーブルとインデックスの作成ステートメントを提供すると、他の人が経験を再現できるため、より証拠に基づいた回答が可能になります。

于 2009-02-28T04:10:53.087 に答える
0

ソートされた挿入は、テーブル内のエントリが多いほど、常に時間がかかります。

于 2009-02-26T04:01:47.600 に答える
-1

ファイルの内部構造の拡張と、追加された情報のデータベースインデックスの構築に関係していると思います-データベースは、選択時のデータ検索の高速化に役立つ非線形の方法でデータを配置すると思います

于 2009-02-26T04:01:53.280 に答える