做 SAP 这行十几年从最早 Oracle 配 ECC 的那套老组合到后来一柜子一柜子的 HANA 一体机再到现在随手在云端开一个 HANA Cloud 实例就能跑开发我最大的感受是大家嘴上说的SAP HANA往往根本不是同一个东西。有人在说那台带闪存的硬件盒子有人在说 S/4HANA 这个新版 ERP有人在说一个内存里跑列存的数据库还有人在说 BTP 上的云原生数据库服务。概念一旦混在一起后面所有的容量规划、性能调优、迁移方案都会跟着跑偏。这篇东西我打算按一线干活的角度把 SAP HANA 从头到尾捋一遍它到底是什么、凭什么快、在哪些场景下能救命、装和连要怎么做、日常怎么盯怎么调、踩过的坑有哪些。不管你是刚接手 Basis 的新人、写 ABAP 的开发、还是做 MM/SD/FICO 的顾问只要你的系统跑在 HANA 上、或者正准备迁过去这篇里的内容应该都能直接拿去用。我会尽量把为什么这么做说清楚而不是只丢一堆命令给你抄。1. 先把 HANA 的定位说清楚它不只是换了个数据库1.1 内存加列存到底解决了什么老问题传统 ERP 的数据库基本都是行式存储 磁盘为中心的架构。一条销售订单它的所有字段是挨着放在同一个数据块里的你要查2024 年华东区所有客户的开票金额合计数据库就得把几千万行整行整行地读进来再把不需要的列丢掉。这个过程中 90% 以上的 IO 都是白费的。行存的适合场景是取一整行这类事务操作可 ERP 里真正让人崩溃的偏偏是那些跨年跨组织的汇总报表。HANA 的路子是把这两件事拆开。第一数据常驻内存不再指望磁盘的随机读第二主存储用列式组织同一列的值连续存放压缩比高、扫描时只碰需要的列。还是上面那个例子列存下数据库只需要读 KUNNR、NETWR、ERDAT 这三列加上内存带宽的加持几千万行的聚合能在秒级甚至亚秒级返回。这也是为什么那么多顾问发现同一张 ACDOCA、同一张 BSEG迁到 HANA 之后报表从泡杯咖啡等变成点一下就出来。但别把 HANA 想成内存越大越快的暴力机器。列存是有代价的单行更新会被拆成往 delta 区插一条 后台合并所以写密集场景的表现跟行存完全不是一回事。理解这一点后面调优才不会南辕北辙。1.2 HANA 与 S/4HANA 的关系一个是引擎一个是整车这两个词天天被混用我在项目上见过不止一次甲方把HANA 升级和S/4HANA 升级当成一件事报价。准确的说法是SAP HANA 是数据库和计算平台S/4HANA 是建立在它上面的下一代 ERP 产品。S/4HANA 之所以能做到简化数据模型前提就是 HANA 的列存和计算能力。举个最典型的例子老 ECC 里总账、应收、应付、资产各自有汇总表和明细表BSIS、BSAS、BSID、BSAD 一大堆到了 S/4HANA 全部合并成一张又宽又大的 ACDOCA行数直接上十亿级。这种设计放在老的行存数据库上基本没法跑只有列存加内存才撑得住。所以你会看到凭证分割库存细分科目余额表实时出这类需求在 S/4 上变得理所当然——不是功能变了是底座换了。反过来说你完全可以在本地部署一个纯 HANA 数据库上面跑着自己写的 SQLScript 或者接个非 SAP 的应用跟 S/4HANA 一点关系都没有。分清楚这一层你在跟人讨论要不要上 HANA时就不会被带节奏。1.3 部署形态怎么选本地、私有云、HANA Cloud选形态这件事我的经验是别一上来就谈技术先谈谁负责半夜三点起来重启。下面这张表是我这几年做选型时常用的一个对照参数是经验值具体还得按项目算。形态典型场景起量门槛经验值运维归属主要顾虑本地一体机 / 认证硬件核心生产 ERP、数据敏感、要求极致性能内存 512GB 起主流 1TB~4TB自有 Basis 或外包一次性投入大扩容要停机加节点私有云 / 虚拟化中大型企业已有云平台想弹性内存 256GB 起云平台 Basis 共管虚拟化层参数、NUMA、THP 要按 SAP 要求调HANA CloudBTP 上新应用开发、数据集成、分析型负载按需最小规格即可开SAP 托管为主成本随规模上升部分底层参数不可见有个细节值得提醒HANA 对硬件是相当挑剔的CPU 的指令集、内存通道数、NUMA 拓扑都会影响实际表现。虚拟化环境下如果 THP透明大页没关、CPU 电源策略还是省电模式跑分可能只有物理机的六七成而且时不时出现莫名其妙的延迟抖动。这类问题排查起来极其费时间所以部署前一定要把 SAP 官方的硬件与操作系统检查清单过一遍别嫌麻烦。2. 核心技术底座拆解快在哪里慢在哪里2.1 列式存储与压缩字典数据是怎么被挤进去的列存最迷人的地方是压缩。同一个列里的值往往高度重复比如 MANDT 全是同一个客户端号WERKS 就那么几十个工厂ERDAT 在同一个月里高度集中。HANA 会用几种手段把它们压下去字典编码把重复字符串映射成整型 ID、RLE连续重复值只存一份加长度、簇编码、稀疏编码、间接编码等具体用哪种由系统根据列的基数自动选。实际效果有多夸张ERP 场景里原始数据压缩到三分之一甚至七分之一都是常见的我见过一张日志类表压到接近十分之一。但这里有个坑压缩率是牺牲写入灵活性换来的。列存表的更新走的是 delta 区写优化、基本不压后台再定期 merge 进主存储读优化、高度压缩。所以你看到这张表占了 200GB 内存可能是主存储 180GB 加 delta 区 20GB而 delta 区那部分才是真正在拖慢查询的元凶。另外要记住一点表不是一直待在内存里的。内存吃紧时 HANA 会把不常访问的列存表卸载unload下次访问再按列按需加载。这意味着冷表第一次查会慢是正常现象不是性能问题。你可以从 M_CS_TABLES 的 LOADED 字段看出这张表当前在不在内存里排查为什么昨晚还好今天这张表查得慢时这一步很关键。2.2 Delta Merge 与数据分层NSE、动态分层、数据老化Delta merge 是 HANA 里最值得弄明白的一个机制。每个列存表都有主存储和 delta 存储两部分新写入的数据先进 delta后台在满足条件时把 delta 合并进主存储并重新压缩排序。合并本身是资源密集型的会吃 CPU、吃内存、还会短暂加锁。我踩过的坑是某次大批量数据导入完运维同事下午三点正好在生产上手动触发了一次大表的全量 merge结果业务那边反馈系统卡了两分钟。后来我们把 merge 的控制权交给自动策略只在维护窗口里手工干预。要到哪些地方看M_CS_TABLES 里能看 RECORD_COUNT、MEMORY_SIZE_IN_TOTAL、LAST_MERGE_TIME配上 DBACOCKPIT 里的表监控基本能判断出哪些表长期 delta 偏大。Delta 一直不收缩通常意味着有长事务压着、或者写入量持续超过合并速度。内存不够用怎么办HANA 提供了一条往下走的路径NSENative Storage Extension本地存储扩展。它把一部分不常访问的数据放到磁盘上但保留在 HANA 的缓冲区管理里访问延迟比纯内存高但远好于传统磁盘数据库。默认情况下 NSE 的缓冲区预算大概占全局内存分配上限的 5%这个比例是可以调的。哪些表适合放 NSE我的判断标准是业务上能容忍毫秒级变几十毫秒——比如历史日志、归档类明细、几年都不查一次的凭证行。千万别把正在被高频点开的表丢上去那是自找麻烦。更早的动态分层Dynamic Tiering是另一条思路现在新项目基本直接用 NSE 了。2.3 计算下推与三大开发载体CDS、AMDP、SQLScriptHANA 真正的价值不在数据库变快了而在计算可以挪到数据库里做。老 ABAP 的经典写法是从数据库把几百万行取到应用服务器用内表循环算完再写回去。这条链路里应用服务器和数据库之间的网络传输才是瓶颈。计算下推Code Pushdown说的就是把这些逻辑用 SQL 表达出来交给 HANA 执行。三种常用载体我按使用频率和适用场景做了一张对照表载体定义位置上手难度适合场景需要留意的点ABAP CDS ViewEclipse ADTDDL Source低绝大多数查询、分析、给 Fiori 供数只能用 ABAP 支持的 SQL 子集逻辑复杂时要拆AMDPABAP 类方法里中CDS 表达不了的复杂逻辑、临时表运算语法检查弱、调试不方便、HANA 版本强绑定原生 SQLScriptHANA 侧存储过程/表函数中高纯数据库侧逻辑、非 ABAP 应用共用与 ABAP 解耦权限和传输管理要另想办法我个人的取舍原则很简单能用 CDS 解决的就别上 AMDP能上 AMDP 的就别写原生存储过程。理由不是语法优劣而是维护成本。CDS 有 ABAP 的传输管理、有权限注解、有 ATC 静态检查兜底AMDP 一进去就是数据库世界出错只能看 trace原生存储过程更麻烦跨系统传输、版本比对都得自己想办法。顺手说一句开发工具。写 CDS 和 AMDP 必须用 Eclipse 的 ABAP Development ToolsADTSAP GUI 里的 SE11、SE80 是维护不了的。很多老顾问第一次被要求装 Eclipse 都很抵触觉得 SAP GUI 用着挺顺但用过 ADT 的跳到定义数据预览SQL 控制台之后基本回不去了。这块我在第 3 章会给出具体连接步骤。2.4 并发控制、锁与事务隔离MVCC 的实际表现HANA 用的是 MVCC多版本并发控制。翻译成人话读的人不去堵写的人写的人也不去堵读的人数据库给每个事务看它该看到的那个版本。这个设计对报表系统是巨大的利好——你跑一个扫几十亿行的大查询不会把业务用户的开单操作卡死。但 MVCC 有个隐形成本旧版本要靠垃圾回收清掉而回收的前提是没有活跃事务还需要那个版本。如果系统里存在一个开了几个小时没提交的事务典型的比如某个调试中的程序停在断点上、或者某段逻辑忘了 COMMIT那么它之后产生的所有历史版本都清不掉内存会一直涨涨到一定程度就开始报内存不足。我遇到过一次一个开发同事中午挂着调试没关下午三点系统告警内存使用率飙到 90% 以上把那个会话 kill 掉之后五分钟内存自己就回落了。排查入口很固定M_BLOCKED_TRANSACTIONS 看锁等待M_ACTIVE_STATEMENTS 看当前在跑什么M_TRANSACTIONS 看有没有超长事务。至于记录锁HANA 在单个事务持有的记录锁数量超过阈值时会做锁升级从小粒度的记录锁升到表级锁这时候并发度会断崖式下跌。看到明明各操作不同的行却在互相等的现象第一反应就该去查锁升级。3. 动手实操从零把一个 HANA 环境跑起来并连上3.1 安装前的硬件与系统参数检查这一步是纯体力活但跳过它的代价极大。我整理了一份自己每次装机都会过一遍的清单数值是通用经验值具体以你所用操作系统版本对应的官方说明为准。检查项经验值 / 做法踩坑提示内存预留给操作系统的余量不少于总内存的 1/8别忘了算文件系统缓存和监控代理的开销磁盘数据卷 日志卷分离日志至少要能放一天的量日志卷和备份卷放同一块盘是常见的自坑Swap必须配置别关掉有些优化教程教你禁 swap在 HANA 上是反的透明大页 THP关闭never开着会导致延迟抖动且极难排查vm.max_map_count大幅调高默认值在加载大表时会直接报错文件句柄 ulimit nofile一百万级并发高时会莫名其妙连接失败memlockunlimited不设会影响内存锁定CPU 电源策略performance省电模式让性能凭空掉一截时间同步NTP 必须正常时间漂移会让集群和复制出诡异问题主机名解析/etc/hosts 正反向都能解析安装程序在这一步失败过太多次还有一件事必须提前做跑一遍官方提供的容量评估工具它会去读现有系统的表行数、增长趋势结合压缩经验值给你一个内存建议。很多人拍脑袋按现有数据库大小除以二来买机器结果是三年后不