Release unused memory sql server 2014 memory optimized table - sql-server

Question

My system
Microsoft SQL Server 2014 (SP1-CU4) (KB3106660) - 12.0.4436.0 (X64)
Dec 2 2015 16:09:44 Copyright (c) Microsoft Corporation Enterprise
Edition: Core-based Licensing (64-bit) on Windows NT 6.3 (Build
9600: ) (Hypervisor)
I use two table table1 and ``table2` memory optimazed table (each size 27 GB)
drop table1
IF OBJECT_ID('table1') IS NOT NULL
BEGIN
DROP TABLE [dbo].[table1]
END
After:
SQL server Memory Usage By Memory Optimazed Objects Reports
Table Name =table2 Table Used Memory = 26582,50 Table Unused Memory = 26792,69
How can I run sql server garbage collector manually ? this is possible or not ?
I need "Table Unused Memory" Release because another process always gives this error
"There is insufficient system memory in resource pool 'Pool' to run this query."
Thank you

Answer 1

Data for memory optimized tables is held in data & delta files.
A delete statement will not remove the data from the data file but insert a delete record into the delta file, hence your storage continuing to be large.
The data & delta file are maintained in pairs know as checkpoint file pairs (CFPs). Over time closed CFPs are merged based upon a merge policy from multiple CFPs into one merged target CFP.
A background thread evaluates all closed CFPs using a merge policy and then initiates one or more merge requests for the qualifying CFPs. These merge requests are processed by the offline checkpoint thread. The evaluation of merge policy is done periodically and also when a checkpoint is closed.
You can force merge the files using stored procedure sys.sp_xtp_merge_checkpoint_files following a checkpoint.
EDIT
Run statement:
SELECT
container_id,
internal_storage_slot,
file_type_desc,
state_desc,
inserted_row_count,
deleted_row_count,
lower_bound_tsn,
upper_bound_tsn
FROM
sys.dm_db_xtp_checkpoint_files
ORDER BY
file_type_desc,
state_desc
Then find the rows with status UNDER CONSTRUCTION and make a note of
the lower and upper transaction id.
Now execute:
EXEC sys.sp_xtp_merge_checkpoint_files 'myDB',1003,1004;
where 1003 and 1004 is the lower and upper transaction id.
To completely remove the files you will have to ensure that you have to:
Run Select statement from above
Run EXEC sys.sp_xtp_merge_checkpoint_files from above
Perform a Full Backup
CHECKPOINT
Backup the Log
EXEC sp_xtp_checkpoint_force_garbage_collection;
Checkpoint
Exec sp_filestream_force_garbage_collection 'MyDb' to remove files marked as Tombstone
You may need to run steps 3 - 7 twice to completely get rid of the files.
See The DBA who came to tea article
CFP's go through the following stages:
•PRECREATED – A small set of CFPs are kept pre-allocated to minimize or eliminate any waits to allocate new files as transactions are being executed. These are full sized with data file size of 128MB and delta file size of 8 MB but contain no data. The number of CFPs is computed as the number of logical processors or schedulers with a minimum of 8. This is a fixed storage overhead in databases with memory-optimized tables
•UNDER CONSTRUCTION – Set of CFPs that store newly inserted and possibly deleted data rows since the last checkpoint.
•ACTIVE - These contain the inserted/deleted rows from previous closed checkpoints. These CFPs contain all required inserted/deleted rows required before applying the active part of the transaction log at the database restart. We expect that size of these CFPs to be approximately 2x of the in-memory size of memory-optimized tables assuming merge operation is keeping up with the transactional workload.
•MERGE TARGET – CFP stores the consolidated data rows from the CFP(s) that were identified by the merge policy. Once the merge is installed, the MERGE TARGET transitions into ACTIVE state
•MERGED SOURCE – Once the merge operation is installed, the source CFPs are marked as MERGED SOURCE. Note, the merge policy evaluator may identify multiple merges a CFP can only participate in one merge operation.
•REQUIRED FOR BACKUP/HA – Once the merge has been installed and the MERGE TARGET CFP is part of durable checkpoint, the merge source CFPs transition into this state. CFPs in this state are needed for operational correctness of the database with memory-optimized table. For example, to recover from a durable checkpoint to go back in time. A CFP can be marked for garbage collection once the log truncation point moves beyond its transaction range.
•IN TRANSITION TO TOMBSTONE – These CFPs are not needed by in-memory OLTP engine can they can be garbage collected. This state indicates that these CFPs are waiting for the background thread to transition them to the next state TOMBSTONE
•TOMBSTONE – These CFPs are waiting to be garbage collected by the filestream garbage collector. Please refer to FS Garbage Collection for details