Issues while migrating data from a disk based table to a memory optimized table

Question

Hi All,
I have a Disk based table with 400000000 rows in it, We are trying to convert it into a memory optimized table.
We have  already created a memory optimized table with similar structure and trying to import data into this mem optimized table using 'insert into' from the disk table.
I am trying to Migrate around 10000000 rows at a time,  but I am getting an error 'There is insufficient system memory in resource pool 'default' to run this query.' Altough we have 128 GB RAM on the server and SS is utilizing more than 120 GB RAM.
Altough the query has been cancelled.
Wanted to Know how could we migrate the table with the available RAM or do we have increase our RAM?
aa

Answer 1

Josh,
Microsoft's documentation on this subject isn't at its best right now (I believe there will be incremental improvements for better understanding), but here is what I read so far.
http://msdn.microsoft.com/en-us/library/dn133190.aspx
"A hash index consists of a collection of buckets organized in an array. A hash function maps
index keys to corresponding buckets in the hash index."
Judging by this statement, a hash index is a hash table just like the ones used as work tables for hash operators in queries (hash matching or grouping). Doesn't contain (or include) other columns, i. e. it doesnt store any data.
"Multiple index keys may be mapped to the same hash bucket."
This means there is some kind of mapping, but this is not explained in the article above. However...
http://msdn.microsoft.com/en-us/library/dn282389.aspx
"For each hash index in the table, each row has an 8-byte address pointer to the next row in the index. Since there are 4 indexes, each row will allocate 32 bytes for index pointers (an 8 byte pointer for each index)."
Each row (in the table) has a pointer (for every index, 1:1 ratio) that points to a row (also known as bucket) in the hash index. So that is how the aforementioned mapping works huh!
> What happens if you include a column in two or three different indexes, or is that not allowed?
My conclusion is that the hash indexes works the same way as a hash worktable, with the addition of the column in the base table that is added to store pointers to the hash index.
When you create a new index, even if you use the same column twice, a hash table is created, hash calculations are distinctly made for each key and stored on it, and while this is done, the column that is exclusively used for this new index is populated
with pointers to this index. You can add a given column to the set of keys of different hash indexes as many times as you want. Correct if i'm wrong, I'm also new on this subject :D