SQL Server 2016におけるIn-Memory OLTPのCTP 3に続く新たな改良

翻訳:https://blogs.msdn.microsoft.com/sqlserverstorageengine/2016/03/25/whats-new-for-in-memory-oltp-in-sql-server-2016-since-ctp3/SQLServer 2016はIn-Memory OLTP機能を一連強化しており、より使いやすく、より優れた性能を実現しています.以前の記事では、SQL Server 2016およびその後のCTP 3バージョンの新機能についてまとめました.その時から、空のインデックス・キー・カラム、LOBタイプ・フィールド、統計の自動更新など、既存の機能に基づいて新しい機能を追加しました.CTP 3とRC 0バージョンの間にあるIn-Memory OLT Pに追加した新しい特性を以下に示す.次の新しいプロパティのリストでは、LOBsおよびその他のoff-row列、テーブル構造の変更、統計の改善に関する詳細な説明を参照してください.CTP 3とRC 0機能層の間に新たに追加されたIn-Memory OLTの新特性Transact-SQL改善:1、ローカルモジュールにおけるクエリー表面:2、LOBデータ型:現在[varchar(max)、nvarchar(max)、varbinary(max)]を入力パラメータとして使用できるようになりました.3、OUTPUT句:現在、ローカルコンパイルストレージ中、INSERT、UPDATE、DELETEにもOUTPUT句が含まれています.4、@@SPID:この内蔵機能はローカルコンパイルT-SQLモジュールにサポートされており、制約条件はメモリ最適化テーブルを参照してください.5、メモリ最適化テーブルがサポートする機能は以下のように増加した:6、NULLableインデックスキー列.メモリ最適化テーブルのインデックスキーにNULLable列を追加できるようになりました.7、Large row:メモリ最適化テーブルの列には、LOBデータ型[varchar(max)、nvarchar(maxとvarbinary(max)]を使用します.また、カラムにLOBデータ型がない場合、メモリ最適化テーブルの行サイズは8060バイトを超えることもできます.詳細は以下の通り.8、メモリ最適化テーブルのユニークなインデックス.インデックスをUNIQUEとして指定できるようになりました.9、ヒープスキャン:クエリーハンドラは、ヒープデータ構造テーブルの各行をメモリ内で直接スキャンすることができる.フルテーブルスキャンが必要な場合、この方法はフルインデックススキャンよりも有効です.10、並列スキャン:すべてのインデックスタイプと基本スタックが並列スキャンをサポートしている.分析型クエリーによる大規模なデータセットのスキャンのパフォーマンスを向上させることができます.11、更新に必要なダウンタイムを短縮する:SQL Server 2016の以前のバージョンから最新バージョンに更新し、データベースリカバリを実行する必要がなくなりました.したがって、データ・サイズはアップグレード時間に影響しません.SQL Server 2014のアップグレードと追加/リストアに対して、データベースは一度再起動する必要があるため、SQL 2014データベースのアップグレードに必要なダウンタイムは約[データベースリカバリに必要な時間].12、ログ最適化と並列ALTER TABLE:現在、ほとんどのALTER TABLEは並列であり、トランザクションログの書き込みを最適化している.最適化とは、メタデータの変更のみを書き込むことです.例外に関する詳細な議論は以下を参照してください.
統計の改善:1、統計の自動更新をサポートします.統計を手動で更新する必要はありません.2、統計サンプリングがサポートされるようになりました.統計収集のパフォーマンスを向上させることができます.ローカルモジュールの自動再コンパイルはサポートされていません.spを使用する必要がありますrecompileは手動で再コンパイルされます.
LOBとその他のoff-row列メモリ最適化テーブルとローカルコンパイルT-SQLモジュールは、大きなオブジェクト(LOB)データ型varchar(max)をサポートし、nvarchar(max)とvarbinary(max)をサポートし、サイズ制限はディスクベースのテーブルと同じです(LOBデータ型データは2 GBを超えてはいけません).また、テーブルにLOBデータ型カラムがない場合でも、メモリ最適化テーブルのローサイズは8060バイトを超えることができます.テーブルの定義に従って、行のサイズまたは行のデータには実行時間の制限はありません.もちろん、すべてのデータもメモリにロードする必要があります.LOBタイプのカラムがサポートされている場合でも、最適なパフォーマンスを実現するために、カラムのサイズが8060バイト未満であることが推奨されます.詳細は以下を参照してください.次のT-SQLスクリプトは、複数のnon-LOB列と単一のLOB列を持つテーブルを示します.

CREATE TABLE dbo.LargeTableSample
(
      Id   int IDENTITY PRIMARY KEY NONCLUSTERED,
      C1   nvarchar(4000),
      C2   nvarchar(4000),
      C3   nvarchar(4000),
      C4   nvarchar(4000),
      Misc nvarchar(max)
) WITH (MEMORY_OPTIMIZED = ON);
GO

 
LOB列や他の列などin-rowを読み込めない8060バイトはoff-rowに格納され、in-rowはoff-rowの8バイト参照のみを格納する.各off-row列を個別に格納する内部テーブルもあります.on-rowまたはoff-rowにカラムをロードするロジックは、以下のようになります.ALTER TABLE操作のたびに、次のルールに従うことを確認します.1、データ列が行サイズ制限の8060バイトを超えた場合、最大列はoff-rowに格納されます.たとえば、1つのテーブルにvarbinary(8000)を含むカラムにvarbinary(2000)カラムを追加すると、in-rowにあるvarbinary(8000)カラムがoff-rowに移動されます.2、すべてのインデックスキー列はin-rowに保存しなければならない.インデックスキー列がin-rowに存在しないテーブルの場合、インデックスを追加できません.前の例の表を考えます.varbinary(8000)列にインデックスが作成されると、varbinary(8000)列はin-rowに移され、varbinary(2000)列はoff-rowに移される.インデックスキー列はin-rowに格納されなければならないからである.次のクエリは、すべてのカラムがoff-rowに格納され、カラムのサイズとメモリの使用状況に基づいています.

SELECT object_name(moa.object_id) AD 'table', c.name AS 'column', c.max_length
FROM sys.memory_optimized_tables_internal_attributes moa
     JOIN sys.columns c ON moa.object_id = c.object_id AND moa.minor_id=c.column_id
WHERE moa.type=5

 
次のクエリを使用すると、ローoff-rowのメモリ消費量について詳しく説明します.クエリには、内部テーブルに格納されているoff-row列とoff-rowインデックスのメモリ消費量がすべて表示されます.

SELECT
  OBJECT_NAME(moa.object_id) AS 'table',
  c.name AS 'column',
  c.max_length,
  mc.memory_consumer_desc,
  mc.index_id,
  mc.allocated_bytes,
  mc.used_bytes
FROM sys.memory_optimized_tables_internal_attributes moa
   JOIN sys.columns c ON moa.object_id = c.object_id AND moa.minor_id=c.column_id
   JOIN sys.dm_db_xtp_memory_consumers mc ON moa.xtp_object_id=mc.xtp_object_id
WHERE moa.type=5

ALTER TABLE最適化ALTER TABLEは、一般的にアーキテクチャの変更やインデックスのチューニングに使用されます.詳細な構文と例については、Altering Memory-Optimizes Tableのドキュメントを参照してください.SQL Server 2016では、メモリ最適化テーブル内のALTER TABLE操作はオフラインで完了している.つまり、操作中にテーブルのクエリーを行うことができない.メモリ最適化テーブルのデータ構造の変更と操作、カラムおよびインデックスの変更は、新しいテーブルの作成と古いテーブルデータのコピーによって行われます.1つの10 GBのテーブルでALTER操作を行い、24個の論理プロセッサを採用したサーバ上で並列に実行し、約1分で完了します.この時間はテーブルのサイズによって変わります.もう1つの良いニュースは、1つのALTER TABLE文で複数のADD、DROP、またはALTER操作を組み合わせることができるようになったことです.たとえば、ALTER TABLE文にカラム、インデックス、コンストレイントを追加することができます.ほとんどのALTER TABLEシーンは並列に実行され、トランザクション・ログの最適化が行われます.トランザクション・ログの最適化は、トランザクション・ログにメタデータの変更のみが書き込まれることを意味します.ただし、一部のALTER TABLE操作は単一スレッドであり、ログ最適化はできません.つまり、ALTER TABLEトランザクションの一部として完全なテーブルをトランザクションログにコピーします.以下に示すALTER操作はすべて単一スレッドであり、ログ最適化はできません.1、ADD/ALTER大きなオブジェクト(LOB)データ型を使用する列:nvarchar(max)、varchar(max)、varbinary(max)です.2、ADD/DROP COLUMNSTORE列にインデックスを格納する.3、ADD/ALTER 1つのoff-row列である場合、ADD/ALTER/DROP操作によりin-row列がoff-rowに移動するか、off-row列がin-rowに移動する.注意:ALTER文を使用してoff-row列の長さを増やすと、ログの最適化が可能になります.
 
統計の改善により、メモリ最適化テーブルの統計が自動的に更新され、統計サンプリングがサポートされます.この井戸があるだけに,メモリ最適化テーブルの統計情報管理方式はディスクテーブルベースの統計情報管理方式と同様であり,同様のトレードオフもある.1、統計を更新する必要があるかどうかの論理はディスクテーブルの論理と同じですが、例外があります.ディスクテーブルのmodifyカウンタmod-counterは各データ列にあり、メモリ最適化テーブルのmod-counterは行レベルです.Modifyカウンタは、通常、テーブル内のデータがどれだけ変化したかを追跡するために使用され、バルブ値に達すると自動的に統計情報を更新する機能が起動します.TF 2453および(RECOMPILE再コンパイル)オプションは、テーブル変数でサポートされています.2、AUTOをサポートするUPDATE_STATISTICS_ASYNC.3、統計サンプリングレートはハードディスクベースのテーブルと同じで、並列サンプリングをサポートする.4、統計の改善の大部分について、データベース・オプション設定の互換性レベルが130であることを確認してください.5、既存の統計を自動的に更新するには、手動で更新する必要があります(次のスクリプトを参照).6、ローカルコンパイルモジュールを手動で再コンパイルする.sp_の使用recompileローカルコンパイルモジュールを再コンパイルします.統計の使い捨てスクリプト:次のTransact-SQLスクリプトを1回実行して、すべてのメモリ最適化テーブルの統計を更新し、統計の自動更新を有効にできます(データベースがAUTO_UPDATE_STATISTICSを開いていると仮定します).

-- Assuming AUTO_UPDATE_STATISTICS is already ON for your database:
-- ALTER DATABASE CURRENT SET AUTO_UPDATE_STATISTICS ON;
GO
ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 130;
GO
DECLARE @sql NVARCHAR(MAX) = N'';
SELECT
      @sql += N'UPDATE STATISTICS '
         + quotename(schema_name(t.schema_id))
         + N'.'
         + quotename(t.name)
         + ';' + CHAR(13) + CHAR(10)
   FROM sys.tables AS t
   WHERE t.is_memory_optimized = 1
;
EXECUTE sp_executesql @sql;
GO
-- Each row appended to @sql looks roughly like:
-- UPDATE STATISTICS [dbo].[MyMemoryOptimizedTable];

 
以上がSQL Server 2016におけるIn-Memory OLT Pの新たな改良である
本文の著作権は作者の所有であり、作者の同意を得ずに転載してはならない.
転載先:https://www.cnblogs.com/lyhabc/p/5347263.html