以下は、数十億レコードのテーブルで実行しているT-SQLコマンドの一部です。データベースのサイズのほとんどは、このように5つのテーブルで占められています。問題を引き起こさずにこれらの手順を実行する最も速い方法は何ですか?最初のコマンドを実行するだけで1時間以上かかります。テーブル全体を削除して再作成する方が簡単でしょうか?それとも、大量のデータでは不可能で安全ですか?誰かがこれをスピードアップするための他のアイデアを思いつくことができますか?データを切り捨てて、ETLプロセスでテーブルを最初から再構築しようとしています。
DROP INDEX [OF_IDX_ClusteredConcept] ON [dbo].[OBS_FACT] WITH ( ONLINE = OFF )
ALTER TABLE OBS_FACT DROP CONSTRAINT OBS_FACT_PK
ALTER INDEX ALL ON OBS_FACT disable;
-- add new data to OBS_FACT table via ETL process
ALTER TABLE [dbo].[OBS_FACT] ADD CONSTRAINT [OBS_FACT_PK] PRIMARY KEY NONCLUSTERED
(
[ENCOUNTER_NUM] ASC,
[CONCEPT_CD] ASC,
[PROVIDER_ID] ASC,
[START_DATE] ASC,
[MODIFIER_CD] ASC,
[INSTANCE_NUM] ASC
) ON [PRIMARY]
CREATE CLUSTERED INDEX [OF_IDX_ClusteredConcept] ON [dbo].[OBS_FACT]
(
[CONCEPT_CD] ASC
);
-- REBUILD indexes on OBSERVATION_FACT
ALTER INDEX ALL ON OBS_FACT REBUILD
多くの場合、SQL Server Management Studioで別のウィンドウでSQL Server Management Studioを再起動しようとすると、drop indexコマンドによってこのエラーがSQL Server Management Studioで発生します。
ロック要求のタイムアウト期間を超えました(Microsoft SQL Server、エラー:1222)
データを切り捨てて再ロードするだけの場合は、インデックスをいじくり回しても、必ずしも役に立ちません。
クラスタ化インデックスの順序でデータを挿入する場合、つまりCONCEPT_CD ASC
順序付けすると、クラスター化インデックスを削除しても実質的な利点はありません。最初にデータをクラスター化インデックスの順序で挿入するよりも、30億行を最後に再構築するほうがはるかに困難です。
ただし、インデックスを無効にする場合は、次のようになります。
-- Disable indexes on OBSERVATION_FACT
-- If you're dropping, don't disable. If you're disabling, don't drop...
ALTER INDEX ALL ON OBS_FACT DISABLE;
-- Truncate your table
TRUNCATE TABLE dbo.OBS_FACT;
-- ETL Process here....
-- REBUILD indexes on OBSERVATION_FACT
-- Or recreate them if you've dropped them in step 1
ALTER INDEX ALL ON OBS_FACT REBUILD WITH (ONLINE = ON);
スクリプトに従ってインデックスをすぐに再構築してフォローを作成しても、作成するとインデックスが構築されるため、無意味です。なぜすぐに再構築するのですか?