一次inmemory丟失引起的問題分析

   Inmemory是Oracle12C開始推出的一個功能。我們一般OLTP資料庫中資料是按照行的形式儲存的，因為我們新增記錄都是insert into，這是一行行的寫入。而我們在分析的時候一般都是對一列或者幾列聚合統計，count，max，min，avg等等，這些統計的時候對於OLTP資料庫其實是一行行的讀一次，最後得出的（max和min有索引不會這樣）。所以如果一個表列越多，那麼做起來就越慢，因為count1列和count100列的值是一樣的，所以大部分列做的是無用功。所以從前資料庫上做報表效率不高，也就是為什麼我們從前會提讀寫分離，甚至覺得關聯式資料庫處理這個不行，改用hadoop來處理。

   但是有了inmemory這種列式儲存，這樣就解決了這個問題。它的特點是把磁碟上的行儲存資料，在記憶體中以列的形式又存了一份。這樣當執行一般的索引查詢時候，操作的是行（可能是硬碟也可能是記憶體），如果執行聚合查詢的時候（那麼查詢的都是記憶體的列式資料表，這個前提是把這個表做了一下載入到inmemory的動作。就像把hive的資料載入到impala一樣其實hadoop也沒快，主要是靠機器多機器好。）

    這個效果有多大？我用一次問題來說明，日常看到我們很多場景執行一天上億次的SQL，對資料庫幾乎沒什麼衝擊（哪怕他是全表），單次執行都是在微秒級別。有一天我被通知說測試資料庫訪問不到了，我去看看，意外被關閉了。測試環境手工啟動一下就行。資料庫雖然脆弱，但是隻要硬體不壞，基本來說自愈能力還是很強的，這也就是我一直覺得備份意義不大的原因。當然我不是說一點都不要，只是價值不大。資料庫一般情況意外可以自己恢復，實在不行，可以依靠高可用。指望備份的話真的是職業生涯的終止了。備份就像我們的保險一樣，都要買，但是希望這輩子一次都用不到。因為遇到用保險的話，基本也是大問題了。我們每個人最大的希望就是保險一點作用都沒起，這個錢白花了，這是最好的結果。對不對？

    好了回過來說重啟以後我也沒在意，第二天有人說這個資料庫比較卡。我們檢查了CPU、IO以及OGG等相關。發現就是CPU不高、IO大，會話數多，應用程式連線資料庫都成問題。在經過一些列查詢之後，從AWR中看到SQL執行的都不快，就是之前說的那種全表關聯查詢而且頻次很高的那種。看了一下執行計劃是全表掃描table access full，可是這個是已經載入到inmemory，應該是table access inmemory full才對啊。猛然想到昨晚重啟後可能丟失了。於是馬上把這些表全部載入一下。效果是立竿見影。開發反饋所有問題全部沒有了。

    問題解決了，我查詢資料看看這個能不能設定成重啟以後不丟失。答案是可以的。只要這個操作就可以了。

      引申思考。

1、inmemory之前我一直信任他count  一億可以秒出，甚至不到一秒。（因為列式儲存，而且還是記憶體計算）但是沒有想到的是他對於多表關聯（目前是2表關聯）的提升也是50到100倍的提升，這是我沒有想到的。

2、HATP的確對我們真的很重要，避免了讀寫分離和架構的複雜

3、工信部定義七大未來資料庫的第一是多模，第二個就是HATP。MySQL用了heatwave實現，tidb用了tiflash實現，等等大家都在這個方面做足了文章，就是用列式儲存來解決關係型資料庫上OLTP和OLAP的融合問題。

4、HATP有利於線上資料庫上進行大資料場景應用。hadoop會過時或者說已經過時，但是大資料不會過時。