タグ付けされた質問 「memory-optimized-tables」

4
データベース 'database_name'のトランザクションログは、 'XTP_CHECKPOINT'が原因でいっぱいです。
について質問がありXTP_CHECKPOINTます。 SQL Server 2014を使用しています。シンプルリカバリモデルモードのデータベースがあります。また、複製されています。 開いているトランザクションはありません。私は実行しDBCC OPENTRAN、それが返されます: 「アクティブなオープントランザクションはありません。」 しかし、テーブルを作成または削除、またはデータを削除しようとするたびに、このメッセージが表示され続けます (実際のデータベース名をに置き換えましたdatabase_name)。 「データベース「database_name」のトランザクションログは、「XTP_CHECKPOINT」が原因でいっぱいです」 なぜこれが起こっているのか誰も知っていますか、そしてもっと重要なことは、どうすればそれを止めることができますか? そして、はい、データベースは本当に単純復旧モデルモードです。つまり、トランザクションログは自動的に切り捨てられます。 ちなみに、完全復旧モードで使用している別のデータベースは同じことを行い、同じエラーを返し始めました。 データベース 'database_name'のトランザクションログは、 'XTP_CHECKPOINT'が原因でいっぱいです。 ログの増加設定を無制限の増加に変更しようとしましたが、同じエラーが返されてしまいました。 ファイルグループのみを除いて、XTPを一切使用せずに問題を再現できます。方法は次のとおりです。http://pastebin.com/jWSiEU9U

4
メモリ最適化テーブル-メンテナンスが本当に難しいのでしょうか?
私は、MS SQL 2012から2014へのアップグレードの利点を調査しています。SQL2014の大きなセールスポイントの1つは、クエリを超高速にするメモリ最適化テーブルです。 メモリ最適化テーブルには、次のようないくつかの制限があることがわかりました。 いいえ(max)サイズのフィールドありません 行ごとに最大1 KB timestampフィールドなし 計算列はありません UNIQUE制約なし これらはすべて迷惑と見なされますが、パフォーマンス上のメリットを得るために本当に回避したい場合は、計画を立てることができます。 実際のキッカーは、ALTER TABLEステートメントを実行できないという事実であり、インデックスのリストにフィールドを追加するたびに、このリマロールを実行する必要がINCLUDEあります。さらに、ライブDBのMOテーブルにスキーマを変更するには、ユーザーをシステムから締め出す必要があるようです。 マイクロソフトがこの機能にこれほど多くの開発資金を投資したとは信じられないほど、これはまったくとんでもないことであり、維持するのは非常に実用的ではありません。これは、私がスティックの間違った終わりを得たに違いないという結論に私を導きます。メモリを最適化したテーブルについて誤解していたため、実際よりも保守がはるかに困難であると思われました。 それで、私は何を誤解しましたか?MOテーブルを使用しましたか?それらを使用および保守するのに実用的な何らかの種類の秘密のスイッチまたはプロセスがありますか?

1
メモリ最適化テーブルを使用したSQL Server 2016の不適切な動作
次のSQLクエリをご覧ください。 CREATE TYPE dbo.IN_MEMORY_TABLE_TYPE AS TABLE ( source_col INT NULL, target_col INT not NULL INDEX ix_InMemoryTable NONCLUSTERED (target_col) ) WITH (MEMORY_OPTIMIZED = ON) GO DECLARE @t dbo.IN_MEMORY_TABLE_TYPE INSERT @t ( source_col, target_col ) VALUES (10, 0), (0, 0) UPDATE r1 SET target_col = -1 FROM @t r1 WHERE EXISTS ( …

1
インメモリテーブルのパフォーマンスがディスクベースのテーブルよりも悪い
SQL Server 2014に次のようなテーブルがあります。 CREATE TABLE dbo.MyTable ( [id1] [bigint] NOT NULL, [id2] [bigint] NOT NULL, [col1] [int] NOT NULL default(0), [col2] [int] NOT NULL default(0) ) (id1、id2)はPKです。基本的に、id1は結果のセット(id2、col1、col2)をグループ化する識別子であり、pkはid2です。 私のボトルネックである既存のディスクベースのテーブルを取り除くために、メモリ内のテーブルを使用しようとしています。 テーブル内のデータが書き込まれます->読み取り->一度削除されます。 各id1値には、数千(数十/数十万)のid2があります。 データは、非常に短時間、たとえば20秒の間、テーブルに保存されます。 このテーブルで実行されるクエリは次のとおりです。 -- INSERT (can vary from 10s to 10,000s of records): INSERT INTO MyTable SELECT @fixedValue, id2, col1, col2 …

1
削除されていないメモリ最適化DLL
BOLから、私の理解は、SQL Serverサービスが開始すると自動的に再コンパイルされ、不要になったときに削除されるため、DBAはメモリ最適化テーブル用に作成されたDLL、またはネイティブにコンパイルされたストアドプロシージャを管理する必要がないということです。しかし、私は目撃しています。メモリ最適化テーブルが削除され、サービスが再起動された後でも、DLLはファイルシステムに存在し、SQLメモリにロードされ、プロセスにアタッチされています。これは、それらがまだsys_dm_os_loaded_modulesに表示されており、SQLサービスの実行中にそれらを削除しようとすると、ファイルシステムでロックされるという事実からもわかります。 これはバグですか?または、後日クリーンアップされますか?後日、インスタンスの再起動でない場合、クリーンアップをトリガーするものは何ですか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.