SAP HANA 安裝後的日常維運 Part 1
在完成HANA平台的安裝後有一些事項需要注意與日常的維運設定
License key 相關
HANA在安裝完成後有一個90天的license key產生。另外正式的license key有兩種，Unenforced 與Enforced,主要差異就在於可以使用到的主機的記憶體量。unenforced沒有限制HANA system可以用多少主機記憶體，若主機有2T memory HANA就可以用到2T. Enforced就是有限制使用量了，端看買的license到哪個等級。license key的安裝可以在system DB or tenant DB.
升級SAP HANA
升級的狀況有三種，如下圖
由上圖可了解HANA升級的三種狀況與需要使用的工具，透過HDBLCM不管是要做version update/patch update或是變更HANA版本都可以。但在不同的位置啟動該工具所對應的功能也不同，若是做update是需要從dowmload下來的軟體位置來做，而在已安裝好的位置啟動只有元件的增減。詳細的兩種不同路徑的對應表如下
系統升級階段:
在系統升級時主要會有系統運行中與非運行中。運行中階段有一些準備工作需要執行，以下是一些比較重要的部分。|
1. 停止 data replication
2. system backup
3. 使用 HDBLCM(HANA database lifecycle manager)工具 SPS10以後的版本升級。
在下載下來的安裝軟體路徑上，例如執行
cd <installation medium>/ DATA_UNITS/HDB_LCM_LINUX_X86_64
GUI模式或CLI模式,如下圖
由上圖的參數我們可以看到LCM會檢查升級前相關的整個HANA系統，這時系統還處於服務狀態。完成後需要執行第二次，這一次系統就會停止服務了。階段程序如下圖
新增或移除主機(for scale out)
因為HANA是支援scale out的架構，所以安裝完成後也有可能要做這一個動作，後期的維運工作也可能會用到。這時我們可以使用cockpit中的 Platform Lifecycle Management來實現此一工作。如下圖
然後輸入要加入的主機相關資訊
另外有關安全方面，HANA系統之間元件服務的溝通。我們可以把它定位在同一台主機或同一個LAN甚至是跨Internet.這時Inter_service communication會有如下圖不同的選擇
主機升級( for scale up)
剛剛講的是多機作業，但萬一你只有單機。原有的硬體太老舊或是到的硬體極限，要換機怎麼辦呢?兩個步驟就可以
如上圖，先移除原來機器的註冊
之後在新機器上註冊該台機器即可，因為所有的相關的設定與執行檔都還在shared storage上。但若要更換的是storage,哪又是另一個issue了。
記憶體的管理
既然是In-menory Database,哪記憶體的管理就是重要的工作了。最重要的兩個觀察指標就是” used memory” and “peak used memory”.
Used memory是指現行主機中HANA用掉了多少記憶體，HANA使用掉的記憶體則是有很多HANA的服務在使用的。如下圖
最底層的Code and Stack大約會暫6G的記憶體，主要是運算功能與DB的管理。接下來我們個別拆解HANA各個元件的記憶體使用
Service Used Memory:
這時我們要來看一下一些核心服務的列表與功能，如下圖
每一個Server process都有它自己的資料與log檔案放在file system裡。每一個HANA service都使用不一樣的port number來溝通，有些服務可以改port有些則不行。各服務的port number 如下圖
port number 的規則如下
第一碼一定是3
中間兩碼是instance number
最後兩碼是各服務預先定義好的號碼，例如compile就是用10
特別要提及index server,因為index service是實際儲存資料並運算與儲存暫時資料的地方。下圖為index service的元件架構圖
另外資料在memory 與Disk(storage)的運行關聯如下圖(PS這一段對資料庫有基本概念的人可以跳過，因為基本概念方式是一樣的)
上圖可以分為二個部分， Data/Log
Data是主要資料運行的地方資料會定期的寫到HD中(預設是每五分鐘一次)，另外是 log(hana在這邊稱redo log),每次資料commit會及時同步(資料一致)到log volumn中。所以這一部分的硬碟效能要很好像是使用SSD HD。這邊要提一下HANA跟一般DB在開機或服務停止再重啟時需要注意的，因為這會關乎到開機的時間(不論之間是正常關機或不正常關機)
Savepoint 的時間調整，剛剛提到預設5分鐘寫入硬碟一次。若時間太短寫入的次數頻繁哪就會影響到整體效能。但時間調整太長哪redo log就會變多，開機時HANA是需要把DATA + redo log才能拼湊完整資料出來。所以redo log越多開機就要越久(因為HANA是重新跑一次在redo log中的SQL command)。
關於開機時HANA將資料載入的過程:
在HANA服務開始啟動時只有 row store的會全部載入到memory，當然設定上你也可以選擇要的Table載入memory.但需要考慮到效能問題(畢竟叫In memory DB嗎?選擇這種方式除非你很了解整個業務流程會常用到那些table.那些作業可以不需要哪麼高效能可以等待的)。與此同時第二個 index 也會出現。再來是 column store, 這個型態的資料開機時是不再載入memory的而是第一次在query此類資料時才會載入到memory所以又叫lazy loading。不過你也是可以選擇此類開機時將資料載入memory,與row store不一樣的是雖然都可以選擇開機時選擇性的載入memory。但column型態可以選擇個別的table or column而row store只能選擇table載入。
另外開機時除了redo log的量影響到開機時間，I/O的performance也很重要，如果可以data/log/backup這三種資料的disk I/O最好都是獨立的。我們看一下以下HANA使用記憶體的使用過程
若使用過程中HANA記憶體需求不夠當然是一直往上加，但若Process 結束或 table unload，記憶體是會被釋放出來的。
Column store 在Memory中的運作:
在一般的Cloumn DataBase中最主要都是以讀取(read)為主，但HANA DB也提供了在cloumn 這個型態能夠寫入資料(當然也是高效的)。接下來解釋column store在memory的架構與運作。在memory column store會有兩個部分， Main and Delta storage
Main storage : 主要存放column資料(高度壓縮型態資料)，並提提供讀取(read)最佳化。
Delta storage : 存放異動資料，也就是write operations.基本資料壓縮並且寫入最佳化。
讀取資料時Main and Delta都會用到並且在讀取後會將結果合併並同步寫回Main storage，而寫入時只有用到Delta.參閱下圖
合併的過程:
合併前後就如同剛剛解釋過的，上面示意圖也很清楚。我們來解釋一下合併的過程。
為了達到資料的一致性在合併過程中HANA會產生Main 2 and Delta 2的空間出來，新的write operation就會到Delta 2上但若Delta 1 上的資料若還沒有commit就會被copy 到 Delta 2上。而這時如果有read哪就會讀取Main 1 and Delta 1 跟 2.一旦讀取完畢就會就會將資料寫回Main 2同時刪除Main 1 and Delta 1.周而復始這種作業方式達到讀寫最佳化。
那些情況下發生合併資料，可參考下圖
再來剛剛提及了資料壓縮，我們看一下那些參數是跟資料壓縮有關的
