2012-01-25 4 views
3

私は、クエリを実行しているデータテーブルを30個持っており、クエリ結果を1つのメインテーブルに挿入しています。 30個の各テーブルのクエリは2〜3百万行を返すので、クエリ自体の最後までにテーブル自体には約6,000万行が必要です。テーブルへのINSERT回数が増えています

バッチスクリプトで一度に1つずつ、それぞれ独自のトランザクションで各クエリを個別に実行し、挿入後にコミットするので、トランザクションログの問題は発生しません。

私は、より多くのデータがテーブルに挿入されると、最初の数テーブルでは約5分から20番目のテーブルでは2時間以上になります。私はこれがなぜであるか把握しようとしています。

insert into maintable <columns> 
select <columns> from table1 

クエリは少し複雑よりもですが、私は、クエリが問題であるとは思わない:

私のクエリは、本質的です。私はクエリをテストしましたが、挿入しないと2〜3分以内に戻るので、問題ではありません。私はまた、結果を魅力的なものに挿入することをテストしました。魅力的なものに数分しかかからず、そして魅力的なものを選択してメインテーブルに挿入しました。

私が挿入しようとしているメインテーブルでは、クラスタードインデックスを削除しているため、単一のインデックスしか持たないため、問題ではありません。

問題が何であるかを診断するために私が探す必要があるものは誰にもありますか?

これはVMWare VM上にあり、データベースは同じデータストアに配置されています。これは問題なのでしょうか?

UPDATE:

メインテーブルのcreate文以下の通りです:

CREATE TABLE [dbo].[dow30_1s](
[id] [bigint] IDENTITY(1,1) NOT NULL, 
[symbol] [varchar](20) NOT NULL, 
[transactionTime] [datetime] NOT NULL, 
[openPrice] [decimal](20, 8) NOT NULL, 
[highPrice] [decimal](20, 8) NOT NULL, 
[lowPrice] [decimal](20, 8) NOT NULL, 
[closePrice] [decimal](20, 8) NOT NULL, 
[vol] [int] NOT NULL 
) ON [PRIMARY] 

CREATE NONCLUSTERED INDEX [dow30_1s_tt] ON [dbo].[dow30_1s] 
(
[transactionTime] ASC 
) 
INCLUDE ([closePrice], 
[vol]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, 
IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON,  
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
+0

おそらく –

+0

テーブルに一意のキーまたはプライマリキーがありますか?SQL Serverがレコードを挿入する前にチェックする必要があります。おそらく統計はオフです...このupdate statistics を実行し、挿入時間が改善されたかどうかを確認してください。ちょうどアイデア –

+0

実行計画を一度見ましたか? –

答えて

2

インデックスをtransactionTimeにドロップします。 統計情報のような匂いは更新されていません(テーブルが大きくなるにつれてよりゆっくりと実行されます)...それが原因であるかどうか、またはデータが広く分散されていて、 SQL Serverがダウンしてしまう。良いニュースは、すべてのレコードの挿入が完了するまで、そのインデックスを必要としないため、ドロップするだけです。

+0

はい、上記のコメントに示されているように、これが私の問題の原因でした。インデックスを削除した後、私のインサートは数時間から約6分になりました。これは私のハードウェアがあれば完全に合理的です。これはインデックスのスラッシングやそのようなものと関連しているのでしょうか、それとも単に最新の統計の問題ですか?インデックス自体が一意性を強制しない単なる通常のインデックスであるため、挿入時にインデックス自体にアクセスする必要がある理由はわかりません。 – steve8918

+0

@ stev8918-本当に「クエリの計画とioの統計など」をチェックすることができなかったかどうかはっきり言うことはできません。「インデックスのスラッシング」となる可能性があります。彼らは良いビットをパフォーマンスに負担をかけるので。 –

+0

の統計情報は、挿入操作のパフォーマンスとは関係ありません。 –

0

私は非常に一度に大きなバッチではなく、一列にこれらの挿入を行うことをお勧めします。私はあなたのテーブルについての詳細を提供していないので、あなたにそれを行うためのクエリを実際に表示することはできません。

VMWareは問題ありません。

は、クラスタ化インデックスが問題になる可能性があるわけではありません。ヒープに挿入するほうが高速になることもありますが、クラスタ化インデックスと同じ順序でデータを挿入することを目指してください。

また、すべてのデータを常に移動する代わりに、ビュー(または複数のビュー)を作成することを検討することもできます。

+0

彼は一度に一つのレコードを挿入しているようには聞こえません。私が集めるものから一度に一度に一度に一度に一度に一度に一度に一度に一度に一度に一度に一度に一度に一度に300万レコードのレコードを挿入しています –

+0

私のテーブルについては、 2011年のDow 30コンポーネントのすべての株式取引が含まれています。私はそこに情報を入れたくないので、私はその質問にそれらを記述したくありませんでした。基本的に、各在庫は独自のテーブルです。私は各テーブルで単一のクエリを実行し、1秒ごとにグループバイを行い、オープンプライス、ハイ、ロー、クローズ価格、1秒あたりの総ボリュームを取得し、メインテーブルにダンプします。私はすべてのdowコンポーネントにわたってクエリを実行できます。 – steve8918

関連する問題