HANA（High Performance Analytic Appliance高性能分析設備）全內存數據庫，2010年SAP 58億美金收購Sybase發展而來，用列式數據存儲、并行運算、內存計算等技術，極大地提高了數據處理效率，于2015年11月推出第一個ERP HANA版本SAP S/4 HANA 1511，實際使用下來在性能上相比之前版本確實大幅提升。
以下圖為Forrester Wave企業內存數據庫分析。
本文闡述版本SAP S/4 HANA1610，OP部署。
業務量劇增帶來的問題
隨著業務往電商方向蓬勃發展和系統的迭代，偶爾會出現系統宕機、卡頓。主要原因還是并發量大導致，SKU數量由最初的30萬增加到500萬，采購價格數量從200萬增加到2000萬，銷售單數從30萬單增加到770萬，MRP區域行數從1500萬增加到5億，日志表當日增加量在500萬條左右，同時分子公司增加十幾家，主數據從MDM同步幾百萬條時間太長，年度調價的時候往往是幾千萬條價格更新，這個時候可能就會造成擁堵。
以下為SAP應用架構，優化點考慮網絡、服務器、數據庫、軟件、日志、內存、實例等。
關于SAP S/4 性能優化最好的策略是在設計中解決，而非出現問題再解決。上線后要堅持優化并關注第二象限解決方案，因為很多穩定性問題長則需要半年時間分析解決。
主要優化事項：
- 代碼持續優化，貴在堅持，不多說
- 在云上增加災備環境供大數據平臺獲取數據，由原來5個小時降低到了1個小時，同時降低主庫壓力
- UPDATE壓力過大，取消一些日志更新（剛開始是刪CDHDR和CDPOS，發現刪除數據跑不贏新增，所以在函數COND_A_WRITE_DOCUMENT改成不更新日志了，把UPDATE線程釋放出來）
- 接口模式調整，Webservers改成RFC批量傳輸，然后解耦走Rabbit MQ消息隊列，對于幾千萬的MQ，消息隊列也會存在消費時間過長的情況，最后改成了批量直接走HANA數據庫，把幾千萬數據先進HANA中間表，內部通過并發模式處理，每天消費1500萬問題不大，到此基本上解決了數據同步問題
- 線程參數調優及工作負載分配（SM51查看，進程參數調優上監控了半年，結合實際情況優化了十幾個版本，難點是是否有人真正長期堅持）
- 采購、客服、計算，接口實例分開，避免相互影響
- 代碼優化要結合設計，當代碼優化到一定程度，就是設計問題了，很多人覺得是代碼效率問題，但是往往高手都是從設計角度去解決問題，比如在SQL取EKPO采購訂單價格的時候，保存的時候更新EKPO含稅和未稅及總金額，你就不用在Inner join PRCD_ELEMENTS，效率極大提升
- 數據SAP同步到外部系統，同步改異步，降低IO并發，同時保障數據一致性
- 應用服務器新增了2個實例（04_01,05_01），分流并發業務
- 單表容量超過最大（約21億），要做表分區，如果是CDPOS表滿了會導致所有更新操作寫入不了數據庫，詳細查詢2154870 - How-To Understanding and defining SAP HANA Limitation
- 業務問題顧問牽頭解決，代碼問題研發牽頭，整體解決顧問牽頭，BASIS保障系統穩定性
監控+持續優化
等優化進入深水區，除了硬件、軟件、操作系統的監控之外就要做業務側的監控，如果平常業務沒啥問題，偶爾出現問題，要通過監控策略把一些大報表，慢SQL，高并發的程序找出來優化，對應用服務器負載做到本質性的優化，而非頭痛醫頭腳痛醫腳，時不時還是出問題。
主要優化事項：
方式1：SAP Solution Management原生監控系統，可以做到郵件報警，對Baisis級排查和監控問題幫助較大，主要從Host、Databases、Instances、Systems監控，除了監控還有一些架構部署、缺陷糾正、請求履行等管理功能
方式2：Zabbix+Grafana搭建監控系統，相對看起來比SLM直觀，缺點是不能監控業務層級的報警，主要還是在操作系統，應用系統，數據庫，網絡
方式3：阿里云原生監控系統+企業微信報警機器人，類似Grafana，監控指標會多一點，感覺界面更直觀
方式4：借用云廠商自帶的監控系統，這個也是我們正在考慮的上云項目，借助云廠商的中間件工具監控更細的性能，比如響應時長，ABAP Dumps，Update等
方式5：業務類日志監控需要自己埋點，用BI平臺輸出，比如監控接口的出入負責情況，整體調用占比等等，然后針對性改善
提升HANA性能
HANA是內存計算、并行計算模式，對比分布式CAP原則，HANA則在Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性）綜合還不錯，為保證計算效率HANA會盡可能調用可用CPU并行計算以縮短所需時間，所以在OLAP領域是HANA強項。
那么為什么在ERP領域還是會存在性能挑戰呢，主要原因還是產品定位，ERP商務管理軟件屬于業務鏈條長數據邏輯復雜的場景，OLTP領域并發DML規模并未那么高。但是如果遇到高并發業務通信成本會飆升，高并發則會是一個挑戰，這個時候最好還是從整體IT架構入手，采用模塊外延更專業的應用系統承接，而不是所有業務都在ERP里面一勺燴。
主要優化事項：
- 互聯網業務更多由專業系統承接，讓專業的系統干專業的事，ERP聚焦本身的優勢領域，如逐步上線了OA、WMS、TMS、OMS、CRM、SRM、票務、低代碼等
- 持續監控ST22 Dump，該日志較大，注意不要Dump過大撐死日志盤帶著系統宕機
- SM51 Trace 是否關閉，等于1表示開啟，資源消耗還是很大
- HANA內存由1T增加到2T，可以運行SAPLWBABAP評估HANA內存目前業務是否夠用
- 我們內存增加后把大報表計算下沉到HANA，采用CDS-AMDP技術將高頻程序進行重構，使用AMDP 替換原有在ABAP層邏輯的處理
- HANA 1.0升級到2.0 利用災備庫可讀（1.0不行），大數據平臺獲取數據由5個小時降低為1個小時，同時降低主庫壓力
- 大報表SQL制定備機獲取數據，減少主庫壓力，平常備機基本上CPU利用率不到10%，充分利用起來
- 日志清理，很多是有標準程序可刪除的，比如RSCDOK99刪除修改記錄，RSSNAPDL刪除ST22，清理SM58處理異常數據
- 自定義表將大表數據同步到備份表，降低對大表的頻繁訪問；對配置表激活Buffer,提升I/O效率
- 做好中長期規劃，系統擴展方式 Scale up和Scale out，參考1825774 - SAP Business Suite Powered by SAP HANA - Multi-Node Support
關于Notes
Notes可能是解決Bug，也可能是提升性能，也有可能是增強包，這是一件細致的活，注意一點就是不要認為打Note就沒風險，一定要謹慎再謹慎，我們打了幾次后出現系統崩潰，立即做了回滾。使用4年一共打了168個Notes在解決系統Bug和性能，有的Notes在測試環境驗證了幾個月才敢往生產系統傳輸，千萬別拿生產環境試錯，否則你的代價太高。以下圖為168個Notes分類。
優化效果
經過一系列優化，最終解決了性能問題，單個接口效率最高提升56%，抗住了每天5000萬次左右的事務性調用，同時前端用戶不再卡頓，日常報表都可以查詢，提升了整體的運營效率。
長期考慮
性能優化是一件長期的事，涵蓋操作系統、硬件、數據庫、軟件、網絡、業務邏輯等，更有可能牽扯IT規劃，從業務層面上升到架構層面，持續監控優化，不斷探索未知，因為你所能做的改變是你所已知的部分。
