In-Memory：內存優化表的DMV

SQL Server 在執行查詢時，自動將活動的相關信息保存在內存中，這些活動信息稱做DMV（Dynamic Management View），DMV記錄SQL Server實例級別上的活動信息。因爲DMV使用內存做爲存儲媒介，在讀取DMV時，不須要IO操做，讀寫數據速度極快，不會對Server產生壓力，而且DMV直接存儲在服務器的內存中，可以及時、精確地反映系統性能的最新狀態。

一，使用DMV的注意事項

1，肯定數據保存的時間

內存是易失性的存儲媒介，一旦SQL Server實例重啓，DMV存儲的信息將所有重置。在使用DMV時，首先須要檢查這些信息在內存中保存了多長時間，以肯定DMV數據的可用性。若是SQL Server僅僅運行很短的一段時間，那麼對DMV數據進行統計和分析是不合適的，這些數據不是SQL Server 實例真實工做負載的數據樣本。SQL Server運行的時候越長，DMV中保存的信息就越多（固然，DMV很是小，不會對內存形成壓力），利用DMV分析就越準確。

2，DMV使用的內存有限

DMV可以使用的內存容量有限，這使得DMV只能存儲有限數量的數據。若是SQL Server運行了很長世間，SQL Server Engine會將DMV的一些老數據覆蓋。

二，查看內存優化表的DMV

SQL Server建立一些DMV，用於追蹤內存優化表的活動信息，在內存優化表的DMV中，有兩個對象ID（Object ID）：

• xtp_object_id 是內部的內存優化表（Internal Memory-Optimized Table)的ID，在對象的整個生命週期中，該ID可變；
• object_id 是User Table的ID，惟一標識該User Table，在對象的整個生命週期中，該ID不變；

xtp_object_id 是內部的內存優化表的ID（Internal Memory-Optimized Table)，每個User Table都對應一個或多個Internal Table：

• 一個Interal Table用於存儲核心數據（Core Data）；
• 其餘的Internal Table 用於存儲臨時數據，Columnstore Index ，Off-Row（Lob）；
• 詳細信息，請閱讀DMV: sys.memory_optimized_tables_internal_attributes

1，查看內存優化表佔用的物理內存

--memory usage
select tms.object_id
    ,object_schema_name(tms.object_id)+'.'+object_name(tms.object_id) as table_name
    ,(tms.memory_allocated_for_indexes_kb+tms.memory_allocated_for_table_kb)/1024 as total_allocated_mb
    ,tms.memory_allocated_for_table_kb/1024 as table_allocated_mb
    ,tms.memory_used_by_table_kb/1024 as table_used_mb
    ,(tms.memory_allocated_for_table_kb-tms.memory_used_by_table_kb)/1024 as table_unused_mb
    ,tms.memory_allocated_for_indexes_kb/1024 as index_allocated_mb
    ,tms.memory_used_by_indexes_kb/1024 as index_used_mb
    ,(tms.memory_allocated_for_indexes_kb-tms.memory_used_by_indexes_kb)/1024 as index_unused_mb
from sys.dm_db_xtp_table_memory_stats tms
where tms.object_id>0

2，查看內存消費者（Memory Consumer）

每個MOT都有單獨的Memory Heap，稱做VarHeap，是一個Memory Consumer，SQL Server從VarHeap中爲MOT的數據分配內存空間。varheap是可變大小的堆數據結構，可以收縮和增加。VarHeap是由固定數量的Allocation Unit組成的集合。Allocation Unit用於分配特定大小的Page，Page的大小是不固定的，最多見的Page Size是64KB。

VarHeap用於Table Row 和 Bw-Tree Index。每個LOB列（使用max指定大小）都有本身獨立的VarHeap。在建立MOT時，SQL Server決定哪些column存儲在Table的VarHeap中，哪些column存儲在本身獨立的VarHeap中。

Hash Index 使用另一個Memory Consumer，稱做Hash。

select
    object_schema_name(mc.object_id)+'.'+object_name(mc.object_id) as table_name 
    ,a.xtp_object_id
    ,a.type_desc as xtp_object_type
    ,iif(a.minor_id=0,'User Table','Off-Row Column:'+col_name(a.object_id,a.minor_id)) as xtp_object
    ,mc.memory_consumer_id as consumer_id
    ,mc.memory_consumer_type_desc as consumer_type
    ,mc.memory_consumer_desc as consumer_desc
    ,i.name as index_name
    ,i.type_desc as index_type_desc
    ,mc.allocated_bytes/1024/1024 as allocated_mb
    ,mc.used_bytes/1024/1024 as used_mb
    ,mc.allocation_count
from sys.dm_db_xtp_memory_consumers mc
inner join sys.memory_optimized_tables_internal_attributes a
    on mc.object_id=a.object_id
        and mc.xtp_object_id=a.xtp_object_id
left join sys.indexes i 
    on mc.object_id=i.object_id
        and mc.index_id=i.index_id
where mc.object_id=object_id('[influencer].[Influencers]')

View Code

引用：SQL Server In-Memory OLTP Internals for SQL Server 2016

The varheaps are used for both table rows and Bw-tree indexes. (Hash indexes are the only structure used with memory-optimized tables that uses a different memory consumer.) In addition, each LOB, column (specified with the MAX qualifier in the datatype definition) has its own varheap. As mentioned earlier, SQL Server 2016 also supports large columns similar to the row-overflow columns for disk-based tables. For memory-optimized tables, SQL Server will decide when the table is created which of your variable length columns will be stored in the table’s varheap and which will be stored as overflow data and have their own varheap. You can think of LOB and row-overflow columns as being stored in their own internal tables.

You can examine the metadata for each varheap (and the other memory consumers) in a DMV called sys.dm_db_xtp_memory_consumers. Each memory-optimized table has a row in this view for each varheap and for each hash index. (We will see one more type of memory consumer, called HkCS Allocator, in the section on columnstore indexes on memory-optimized tables.) If we join this DMV with the catalog view called sys.memory_optimized_tables_internal_attributes we can see which varheap belongs to a specific column. Each user table has a unique object_id and xtp_object_id value which is used by all the indexes. Each additional varheap, for the row_overflow and LOB columns will have its own xtp_object_id. Note that if an object is altered, its xtp_object_id will change, but its object_id will not. 

3，Hash Index的鏈表長度

對於Hash Index，表示鏈長的字段有：avg_chain_length 和 max_chain_length ，鏈長應保持在2左右；鏈長過大，代表太多的數據行被映射到相同的Bucket中，這會顯著影響DML操做的性能。

致使鏈長過大的緣由是：

• 總的Bucket數量少，致使不一樣的Index Key映射到相同的Bucket上；
• 若是空的Bucket數量大，但鏈長過大，這說明，Hash Index存在大量重複的Index Key；相同的Index Key被映射到相同的bucket；
• 詳細信息，請閱讀：sys.dm_db_xtp_hash_index_stats (Transact-SQL)；

4，事務

在訪問MOT時，有兩種類型事務ID，在事務中，訪問MOT和訪問DBT的事務是獨立的：

• xtp_transaction_id：是訪問MOT的事務ID；
• transaction_id：是訪問DBT的事務ID，0表示事務沒有訪問MOT；
• 詳細信息，請閱讀：sys.dm_db_xtp_transactions (Transact-SQL)

 查看當前數據庫中活躍事務的信息：

select t.xtp_transaction_id
    ,t.transaction_id
    ,t.session_id
    ,t.begin_tsn
    ,t.end_tsn
    ,t.state_desc
    ,t.result_desc
from sys.dm_db_xtp_transactions t

 

參考文檔：

Baselining with SQL Server Dynamic Management Views

Memory-Optimized Table Dynamic Management Views (Transact-SQL)