In-Memory OLTP のメモリ最適化テーブルですが、データをメモリ上に確保できなくなるとエラーとなります。
メモリが不足している状態でデータの追加をしようとすると以下のようなエラーになります。
# 実際には追加 (INSERT) だけでなく、更新 (UPDATE) をした場合にもエラーとなりますが。 
メモリが不足した際のリカバリー方法としては以下のような情報があります。
How to: Recover from OOM (Out Of Memory)
CTP2 向けの情報としてはいかがあります。
Increase value of MAX_MEMORY_PERCENT on the resource pool
If you have not created a named resource pool for your in-memory tables you should do that and bind your In-Memory OLTP databases to it. See the topic How to: Bind a Database with Memory Optimized Tables to a Resource Pool for guidance on creating and binding your In-Memory OLTP databases to a resource pool.
If your In-Memory OLTP database is bound to a resource pool you may be able to increase the percent of memory the pool can access. See the sub-topic Change MAX_MEMORY_PERCENT on an existing pool for guidance on changing the value of MAX_MEMORY_PERCENT for a resource pool.
CTP2 になりリソースガバナーと統合がされ、メモリ最適化テーブルのメモリ上限を指定できるようになりました。
現状のメモリ使用量ですが以下のようになっています。 
この状態に対してリソースガバナーを設定してみたいと思います。
リソースガバナーについての情報は How to: Bind a Database with Memory Optimized Tables to a Resource Pool に記載されています。
リソースプールについてはデフォルトですと default というプールに割り当てられます。 
メモリ最適化テーブル用のリソースプールを新規に定義します。
CREATE RESOURCE POOL Pool_Hekaton WITH (MAX_MEMORY_PERCENT = 50); ALTER RESOURCE GOVERNOR RECONFIGURE; GO
接続したプールにメモリ最適化テーブルを格納しているデータベースを関連付けします。
EXEC sp_xtp_bind_db_resource_pool 'TESTDB', 'Pool_Hekaton' GO
関連付けの状態については sys.databases から確認することができます。
SELECT d.database_id, d.name, d.resource_pool_id FROM sys.databases d GO
関連付けを設定した後はサービスの再起動または、データベースのオフライン → オンラインを行いデータベースの再起動をする必要があります。今回はサービスを再起動しています。
リソースガバナーで制御ができるようになった後の状態がこちらです。
リソースガバナーで制御をしているため、先ほどと比較して、使用できるメモリが減少していることが確認できます。
一度データベースを再起動した後はリソースプールと関連付けられていますので、動的にメモリを変更することが可能となります。
# 実際には減らすことはなく増やすことになると思いますが。
メモリの設定については下表を参考にするとよさそうですね。
メモリ最適化テーブルはメモリ上にデータを格納する必要があるため、メモリを可能な限り使用することになります。
そのため、ディスクベーステーブルに影響を与えないように、制限をかけることは意識しておくとよさそうですね。