做SAP HANA运维这些年最怕听到的一句话就是报表系统跑不动了。多半不是硬件缩水而是SAP HANA负载管理没理清。内存数据库的调度方式跟传统数据库完全不一样一个高并发查询就能把CPU吃满几个大报表能把内存挤爆。这篇把HANA负载管理这套东西从原理到落地完整捋一遍工作负载分类怎么配、优先级怎么定、内存和并发怎么限、排障路径怎么走适合刚接手HANA的DBA也适合做了几年但没系统看过负载管理的同行。每个人遇到的问题可能不同但底层逻辑是通的。1. 为什么说HANA负载管理本质是内存与CPU的调度艺术1.1 传统数据库的经验在HANA这里会失灵很多从传统数据库转过来的同事第一反应是加索引、调SQL、扩内存。这些东西在HANA上有没有用有用但不是最关键的。传统数据库的瓶颈大头在磁盘IO慢了之后查询会被卡在IO等待上反而变相保护了CPU和内存。HANA不一样数据全在内存里没有磁盘IO这道闸门。数据加载快、计算快但也意味着一个没写好限制的查询可以在极短时间内把CPU全部线程吃干抹净。没有了IO瓶颈的自然限流你必须主动给系统加闸门。HANA大量使用列式存储和并行执行引擎。一个查询会被拆成多个算子并行跑每个算子又可能开多个线程。如果同时进来几十个复杂报表查询线程池瞬间被打满内存被中间结果集堆满后面所有查询包括健康的OLTP小事务全都挤在一起等资源。表现出来的就是整个系统变慢、CPU 100%、内存告警。传统的锁等待还能靠锁监控定位HANA这种资源等待锁监视图里经常看不见东西因为根本没有锁冲突是纯粹的CPU和内存资源争抢。这是两个物种。1.2 HANA负载管理到底管哪三件事从实际运维视角看HANA负载管理主要管三件事。第一件事是分类。你不能让交易查询和大报表跑在同一条道上。通过工作负载分类把不同用户、不同语句类型分到不同的业务队列里每个队列有自己的特性参数。第二件事是定优先级。同样是排队不能让临时分析把核心生产查询堵住。通过优先级参数让高优业务在资源争抢时占先低优批处理靠边等。第三件事是设上限。防止单个查询吃太多内存防止某一类任务并发太高。通过语句内存限制和并发限制把系统总资源的天花板守住。这三件事做完了负载管理的骨架就算搭起来了。后面所有细节都是围着这三件事补血肉。1.3 什么情况下你才真的需要负载管理不是说所有HANA系统一上来就必须上负载管理。小系统、业务单一、查询量不大默认配置完全够用。但出现下面几种苗头时一定要开始动负载管理了。第一类是典型的混合负载场景。OLTP和OLAP跑在同一套HANA上ERP交易并发和报表分析并发叠加互相拖累。第二类是大查询失控场景。某个特定报表逻辑复杂跑起来就是几十亿行扫描资源占用肉眼可见。第三类是高峰期卡顿场景。每到月末结账、每天早晨批量跑数的时候系统响应时间明显劣化。这三类情况扩硬件只能缓解一时因为问题根源是资源分配策略不是资源总量。算一笔账加内存、加CPU成本高而且大查询照样可以把新资源吃掉。给查询分好类、排好队、限好量才是低成本的解决路径。2. 工作负载分类把好钢用在刀刃上的起点2.1 workload class一套参数定义一类业务HANA里的核心概念叫workload class中文叫工作负载类。可以把它理解成一张业务标签卡上面写清楚这类业务能用到多少资源、排多高的优先级、最多并行跑几个。创建语法很直接CREATE WORKLOAD CLASS OLTP_REALTIME DESCRIPTION OLTP实时交易业务 PRIORITY_LEVEL 2 MAX_CONCURRENCY 20 STATEMENT_MEMORY_LIMIT 2 GB;CREATE WORKLOAD CLASS BATCH_REPORT DESCRIPTION 批处理报表业务 PRIORITY_LEVEL 8 MAX_CONCURRENCY 5 STATEMENT_MEMORY_LIMIT 20 GB;上面两个类一个给OLTP实时交易一个给批处理报表。PRIORITY_LEVEL 数值含义下面细说先记住OLTP类并发高、内存限制小、优先级高批处理类并发低、内存限制大、优先级低。名字上建议直接用业务含义命名别用什么CLASS_ACLASS_B。系统里workload class多起来之后名字不说清楚根本没法维护。我曾经见过一个系统里有几百个workload class名字全是test1test2这种后期排查到想骂人。2.2 用户映射与会话级映射两种绑定方式建好workload class之后怎么把业务放进去最基础的方式是按用户绑定。ALTER USER SAP_ERP_APP SET WORKLOAD CLASS OLTP_REALTIME; ALTER USER REPORT_USER SET WORKLOAD CLASS BATCH_REPORT;用户一改他所有会话都会被拉到对应的workload class下。简单粗暴适合用户和业务绑得比较死的场景。但真实场景里一个用户可能既要跑事务又要跑报表。按用户绑就绑不准了。这时候用会话级映射单独指定某条连接走哪条道ALTER SYSTEM ALTER SESSION SET WORKLOAD CLASS BATCH_REPORT;这个命令在连接里执行后仅当前会话变了。适合程序里有单独的分析连接池的情况。更灵活、更可控。还有一个点容易忽略改了workload class映射后不是所有已存在的会话都立刻生效。会话建立时就已经绑定了当时的class改完之后新建立的会话才会走新规则。运维操作时要注意这个生效时机别改完以为生效了结果发现旧会话还在老队列里跑。2.3 触发器让系统自己判断该走哪条道用户映射和会话映射都是人工指定但很多场景下你希望系统自己识别。比如同一个报表用户跑小查询时走OLTP道跑大关联时自动改走批处理道。人工判断不现实得靠触发器。CREATE WORKLOAD TRIGGER TR_BATCH_DETECT WHEN STATEMENT TYPE(SELECT) ANALYZE STATEMENT STRING LIKE %FROM%MATERIAL% THEN SET WORKLOAD CLASS BATCH_REPORT;规则是当语句是SELECT并且SQL文本里包含某张关键大表的引用时自动把这个语句分配到BATCH_REPORT类。触发器最怕的是正则写太宽。LIKE %FROM%这种写法会把几乎所有SELECT都命中。建议触发器匹配条件一定要具体用大表名、特殊提示词、固定语句特征。我见过一个系统触发器写了一堆%SELECT%结果所有查询都被拉进批处理队列OLTP业务被自己写的触发器给堵死了。触发器发布前先统计一下当前活跃语句里有多少会命中规则用实际SQL验证匹配范围确认无爆炸性误命中后再上线。2.4 优先级值别记反了数值越小越优先这是最容易踩坑的地方之一。PRIORITY_LEVEL取值范围是0到9默认5。重点0是最高优先级9是最低优先级跟常规认知里数值越高越好完全相反。优先级影响的不只是CPU调度。在HANA里优先级还会影响内存分配、锁请求仲裁等资源竞争行为。高优先级的语句在争抢资源和等待队列排位上都明显比低优先级语句占优。实际经验是核心OLTP事务设1到2面向管理层的固定报表设6到7大批量批处理、数仓搬运类设8到9临时分析类设7左右。把四种典型业务拉开差距后高峰期的体验会明显改善。但差距也不是越大越好过于极端会导致低优任务几乎得不到资源反而不利于整体吞吐。3. 并发与内存限制拦住贪吃又捣乱的查询3.1 MAX_CONCURRENCY后厨只有一个灶台的时候怎么办MAX_CONCURRENCY 限制的是同一个workload class里同时处于正在执行状态的语句数量。超过这个数的语句会进入排队状态等前面的语句跑完再进去。打个比方一个餐厅后厨只有五个灶台。如果一次来了二十个订单后厨只能同时炒五个菜剩下十五个订单在窗口排队。HANA里这个参数就是在给后厨定灶台数量。设置多少合适不能拍脑袋。先看目前系统里这类业务高峰期并发是多少然后砍掉百分之二三十留下缓冲空间。比如批处理高峰期最多同时跑8个报表MAX_CONCURRENCY先设5或6。太小了会人为制造排队业务体验差太大了没什么意义保护作用不明显。观察队列不一定要额外工具。系统视图里可以看到语句状态如果大量语句显示排队中、等待资源就说明并发上限设小了。调整是一个动态过程改完观察一周再说。3.2 STATEMENT_MEMORY_LIMIT查询的内存贴标签HANA里一个查询吃多少内存直接影响整个系统的稳定性。列式存储下中间结果集可能极其庞大一个大排序、大哈希连接能把可用内存瞬间吃光。STATEMENT_MEMORY_LIMIT 给单个语句设了内存使用上限。超过这个上限时语句会被终止并报错不会让整个实例内存耗尽。设置这块的思路跟并发不一样。并发是限制数量内存限制是保护底线。建议按正常业务最坏情况的1.5倍到2倍来设。比如正常报表高峰期最占内存的查询用到6GB那限制设10GB或者12GB既留了余量又不至于让单个查询失控。千万别把语句内存限制设得太小。曾经有个同事把默认语句内存限制改成了512MB结果所有正常的统计报表全都报内存超限业务直接瘫痪。限制是为了拦住异常不是为了为难正常业务。可以在压测环境先跑一遍典型查询流程统计一下内存消耗分布再定阈值。3.3 队列观察查询到底是在跑还是排队很多运维同学看系统卡了第一反应是看CPU使用率、内存占用率。这些指标在高负载下一定会报警但报警了之后你还是不知道问题出在哪。HANA的系统视图可以看到每个工作负载类下的实时状态语句当前是正在执行还是排队。通过会话与负载类的关联视图可以查某个用户、某类语句被分配到了哪个workload class当前该类有多少并发语句。写个小查询就能看清全局SELECT WORKLOAD_CLASS_NAME, COUNT(*) AS ACTIVE_CNT FROM M_ACTIVE_STATEMENTS GROUP BY WORKLOAD_CLASS_NAME;更细一轮SELECT SESSION_ID, USER_NAME, STATEMENT_ID, WORKLOAD_CLASS_NAME, STATUS FROM M_WORKLOAD_SESSIONS WHERE WORKLOAD_CLASS_NAME LIKE BATCH% ORDER BY STATUS;如果BATCH类里大量语句状态是排队说明并发上限吃紧如果是正在执行说明这些语句本身跑得慢。两层结论对应完全不同的处置方向一个调参数一个调SQL。4. 从一次排障看HANA负载问题的完整定位链路4.1 现象与第一反应之前某制造企业的MES系统每到下午三点左右前端拣货终端就卡得不行。业务方反馈扫描枪扫一个条码要转五秒之前都是毫秒级。系统告警HANA CPU 100%内存使用率冲到90%以上。我的第一反应不是看资源而是先看有哪些语句在跑。执行SELECT SESSION_ID, USER_NAME, STATEMENT_ID, CPU_TIME, MEMORY, STATUS, STATEMENT_STRING FROM M_ACTIVE_STATEMENTS ORDER BY MEMORY DESC;结果很清晰某张十几亿行的物料库存表上跑着一个后台物料需求计划计算任务单条语句内存占用占了整个实例的将近四分之一CPU时间已经累积到几十分钟。后面大量拣货终端的小INSERT和短查询全都堵在资源池外面排队。4.2 从系统视图入手先分清忙和乱高负载时要分清楚是系统资源真的不够还是资源分配秩序出了问题。看事件等待视图。大量语句都在等待CPU或者内存资源而不是等待锁。锁等待是不会把CPU打满的但资源等待会。再结合活动语句列表发现几乎所有大内存语句都来自同一个后台计划任务基本可以定性不是硬件不够是一个贪吃任务把路占了。再把会话跟负载类的关联视图捞出来确认这个计划任务的会话属于哪个workload class。发现它绑定的是默认类也就是跟OLTP交易同用一套默认参数没有任何并发限制和内存限制。这就是问题根源。4.3 定位到罪魁祸首后的处置确认了元凶处置分两步。第一步是止血。把该条大查询会话终止掉让系统资源先释放出来。用ALTER SYSTEM CANCEL SESSION或者更重的KILL。先保证业务恢复。第二步是治本。给这个计划任务专用一个workload class限制并发为1不允许它同时多开设置语句内存上限让它不能无限吃内存优先级降到8或9确保它在跟OLTP抢资源时永远靠边站。核心逻辑是后台批处理任务必须低人一等。它不是实时业务晚跑十分钟没人投诉但挤占了交易资源整个产线都要投诉。4.4 事后的配置补救这个案例里最值得说的不是处置过程而是后续配置。计划任务的执行用户被单独划分出来绑定到新创建的批处理类。同时补了一个触发器当语句涉及核心大表且执行时间可能较长时自动归入低优先级批处理道。即便将来换了用户、换了任务名只要触发了匹配规则还是会被拦下来。又跑了两个月同样的时段不再卡顿。CPU还是会冲到百分之七八十因为低优先级任务也在跑但OLTP交易的响应时间已经稳定在几百毫秒以内。资源还是那些资源只是秩序变了。排障的完整链路就是现象确认、语句定位、原因定性、止血处置、配置根治、长期验证。每一步走扎实不要跳步。5. 一套能落地的HANA负载管理方案怎么搭5.1 第一步把业务负载分门别类动手配置前先梳理业务这步省不了。把系统里所有访问HANA的应用过一遍列清楚每个应用是OLTP型、报表型还是批处理型高峰时段大概什么时候单条语句内存消耗水平怎么样。梳理时最好让业务方参与确认别自己拍脑袋。比如某个模块看起来像报表实际上是对接产线的实时查询搞错了会出大事。整理出一个清单包含应用名称、典型用户、语句类型SELECT/INSERT/UPDATE/DELETE、平均内存、峰值内存、高峰并发、容忍延迟。这个清单就是后面所有参数设置的输入。5.2 第二步定优先级矩阵和并发阈值清单出来了就开始定策略。给每类业务定优先级和并发阈值建议写成一张矩阵表先跟团队评审再落配置。业务类型典型用户优先级并发上限语句内存上限核心OLTP生产执行、订单录入2202 GB运营视图计划员、库管员5104 GB固定报表领导层、财务月结668 GB临时分析数据专员自建查询786 GB后台批处理物料计划、库存重算8316 GB矩阵里的数值不是标准答案不同行业、不同机型差异很大。我这个是给中小型生产系统的典型起步值拿回去要根据实际情况调整重点是拉开层次而不是追求某个具体数字。5.3 第三步落配置的完整SQL示例矩阵评审通过后开始写配置。先把workload class建出来CREATE WORKLOAD CLASS WC_CORE_OLTP DESCRIPTION 核心OLTP交易类 PRIORITY_LEVEL 2 MAX_CONCURRENCY 20 STATEMENT_MEMORY_LIMIT 2 GB; CREATE WORKLOAD CLASS WC_VIEW_OPS DESCRIPTION 运营查询类 PRIORITY_LEVEL 5 MAX_CONCURRENCY 10 STATEMENT_MEMORY_LIMIT 4 GB; CREATE WORKLOAD CLASS WC_FIXED_REPORT DESCRIPTION 固定报表类 PRIORITY_LEVEL 6 MAX_CONCURRENCY 6 STATEMENT_MEMORY_LIMIT 8 GB; CREATE WORKLOAD CLASS WC_ADHOC DESCRIPTION 临时分析类 PRIORITY_LEVEL 7 MAX_CONCURRENCY 8 STATEMENT_MEMORY_LIMIT 6 GB; CREATE WORKLOAD CLASS WC_BATCH DESCRIPTION 后台批处理类 PRIORITY_LEVEL 8 MAX_CONCURRENCY 3 STATEMENT_MEMORY_LIMIT 16 GB;然后是映射。能按应用用户绑定的就直接绑定ALTER USER MES_APP SET WORKLOAD CLASS WC_CORE_OLTP; ALTER USER PLANNER SET WORKLOAD CLASS WC_VIEW_OPS; ALTER USER REPORT_USER SET WORKLOAD CLASS WC_FIXED_REPORT;临时分析类适合用会话级绑定由应用侧在工具里指定。触发器兜底识别批处理CREATE WORKLOAD TRIGGER TR_AUTO_BATCH WHEN STATEMENT TYPE(SELECT, UPDATE) ANALYZE STATEMENT STRING LIKE %MRP_RUN% THEN SET WORKLOAD CLASS WC_BATCH;触发器里的匹配条件必须先在生产环境的SQL审计或计划缓存里捞真实语句验证命中率。不要想当然写一个字符串就上线。5.4 第四步上线验证与回滚策略配置文件准备好后选一个业务低谷窗口执行。执行完别马上走人至少盯一个完整的高峰周期。验证重点看几个维度各类业务的响应时间是否有劣化活跃语句里有没有大量排队内存占用是否比配置前更平缓有没有正常语句被内存限制误杀。回滚策略必须提前想好。workload class本身删掉就行映射关系ALTER回默认即可。关键是回滚后原问题可能立刻重现所以变更窗口内要有人值守该终止异常查询就终止别等业务投诉。6. 复盘之后这几个坑值得单独拿出来说6.1 优先级数值用反等于没调PRIORITY_LEVEL从0到90最高9最低。这个跟Linux的nice值直觉相反但比nice更反直觉的是很多教程和资料里都没有专门强调这一点。我见过不止一次同事把核心业务设成9、批处理设成1结果调完之后核心业务反而更卡了。排查半天优先级方向搞反了。配置之前写一行注释在脚本里数值越小优先级越高能避免团队其他人重复踩坑。6.2 MAX_CONCURRENCY设太小报表排队排到怀疑人生并发保护的本质是限制同时跑的语句数量不是限制语句执行时间。如果并发设得太小执行时间又快不起来排队长度会滚雪球。判断办法观察语句排队数量。如果排队的语句数量持续高于并发上限的两三倍说明上限太紧了。适当调大给正常峰值留足空间。记住并发限制是用来防异常叠加的不是用来限制正常业务的。6.3 STATEMENT_MEMORY_LIMIT一刀切正常查询也被误杀内存限制最忌讳一刀切。一个系统里简单主键查询可能只要几十MB复杂聚合报表可能要几十GB。用同一个上限管所有人必然有人被误伤。正确做法是按workload class分别设每类业务看典型的最高内存消耗按1.5到2倍留余。宁可高一点也别低到误杀正常语句。被误杀一次业务方的信任要很久才能补回来。6.4 触发器匹配规则太宽全系统都乱了触发器是自动化的利器也是自动化的失控源。匹配字符串写得太宽一个小小的LIKE可能把所有SQL都兜进去业务瞬间全乱。上线触发器之前先在历史语句里做匹配演练确认命中清单跟预期一致。触发器不是越全越好匹配条件越具体越安全。宁可漏掉一小部分让它走默认保守配置也不要误伤核心业务。6.5 别忘了内部任务和DDL不归workload class管这是很多人忽略的一点。备份、恢复、DDL、一些系统内部任务有自己的调度机制不完全受workload class控制。你给某个用户配了低优先级类但他执行DDL建索引时行为可能跟普通DQL语句完全不同。所以在评估负载管理效果时不要把内部任务和DDL的波动也算进去。改善效果要看业务侧的实际响应时间不是看系统CPU降了多少。内部任务该跑的还在跑那块资源本来也不该指望靠workload class管住。做负载管理这几年我最大的体会是SAP HANA不是靠单条优化解决性能问题而是靠一套秩序。工作负载分类、优先级、并发和内存限制这些机制单独看都不复杂但组合起来能把混合负载场景下的混乱变成可控。刚开始调整时建议只动一两类业务观察一段时间确认正向收益后再逐步铺开。改动幅度越小出问题时的定位范围越窄。最后再分享一个小经验每次调整前把当前配置全量导出一份留着出问题还能对比参数差异。这个习惯帮我省过不止一次回滚的大麻烦。
