Sql Azure p4カラムストアインデックスを使用してメモリ内にダウン

Azure P4層には次の表があります。Sql Azure p4カラムストアインデックスを使用してメモリ内にダウン

CREATE TABLE [dbo].[UserTransactions] 
(
    [Id] [int] IDENTITY(1,1) NOT NULL, 
    [Points] [int] NOT NULL, 
    [Date] [datetime] NOT NULL, 
    [UserId] [int] NOT NULL, 
    [DeviceId] [char](36) COLLATE SQL_Latin1_General_CP1_CI_AS NULL, 
    [TransactionTypeId] [tinyint] NOT NULL, 
    [ActionBy] [int] NOT NULL,INDEX [idx_hash_UserTransactions_UserId] NONCLUSTERED HASH 
(
    [UserId] 
)WITH (BUCKET_COUNT = 524288), 
PRIMARY KEY NONCLUSTERED 
(
    [Id] ASC 
), 
INDEX [UserTransactionsUIX_NonClustered] NONCLUSTERED HASH 
(
    [ActionBy], 
    [TransactionTypeId] 
)WITH (BUCKET_COUNT = 262144) 
)WITH (MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_AND_DATA)

インサートの量が多い（約7000~10000 /秒）。私たちは次を追加しようとしました Alter table [UserTransactions] add index UserTransactions_idx clustered columnstore

しかし、何らかの理由で、いくつかのトランザクションを挿入すると、データベース全体が約40秒間ダウンしてから再びオンラインに戻ります。このシナリオはSQL Server 2016 Onプレム、同じ結果です。（ただし、今回は手動でサーバーを再起動する必要がありました）。ColumnStoreインデックスを追加すると、テーブルからの選択のパフォーマンスが向上すると考えられます（各挿入と共に2x selectステートメントが発生し、その後1x selectステートメントが発生します）。その前後にあるselect文を使用せずに手動でテーブルにレコードを挿入した場合でも同様です。

出典

2017-07-12 AhmedAsh

でそれを修正します。 Hekaton用のテーブル追加インデックスステートメントの変更は、オフライン操作であり、インデックスビルドが実行されている間にユーザーのアクティビティがブロックされます。質問：1） "データベース全体"と言うとき、あなたは本当にテーブルへのアクセスですか？ 2） "（各挿入に伴い、2倍のselect文がその前に発生し、1回のselect文がその後に起こります）"を明確にすることはできますか？また、joe.sack @ microsoft.comで私に電子メールで直接お問い合わせください。体系的な問題を確認できます。 –

1）いいえ、文字通りデータベース全体を意味するわけではありません。40秒後にすべてがダウンしてから2〜3分後に再び40秒間ダウンし、インデックスを削除するまで続きます。 2）我々は、ストアドプロシージャについて4つのステートメントから構成されています。3つ目のステートメントは、挿入前に2つのselectステートメントが実行され、その後に1つのselectステートメントが実行される「テーブル」への挿入です。 – AhmedAsh

私に電子メールを送ってください。バックエンドの問題を追跡できるかどうかがわかります。 –

私はマイクロソフトに連絡し、彼らはそれはバグだ確認し、あなたはワークロードがしばらくの間停止することが期待されるインデックスを追加するには、ALTER TABLE文を開始すると、彼らは新しいリリース

出典

2017-07-27 18:29:55 AhmedAsh

Sql Azure p4カラムストアインデックスを使用してメモリ内にダウン

答えて

関連する問題