1. 先认清现实国产化数据库运维难点从来不在安装部署接手国产化数据库运维之前我一直是MySQL和Oracle的老玩家。最初接到任务时我的心理预期是无非就是换个数据库SQL差不多工具链差点意思。真正上手才发现这个判断错得离谱。国产化数据库不是某一款产品而是一个庞大的家族大致可以分成几条技术路线基于PostgreSQL内核的openGauss、KingbaseES、Vastbase基于MySQL生态的TDSQL、GreatSQL走Oracle兼容路线的达梦DM、GBase 8t以及自研分布式架构的GaussDB、OceanBase。这个分类不是做学术研究而是运维的底层认知。因为不同路线的数据库排查问题和调优的手段差异极大。比如达梦的很多视图和命令长得像Oracle但底层实现完全不同openGauss的很多参数名字继承自PostgreSQL但共享缓冲区的管理逻辑又做了改造OceanBase在MySQL兼容模式下能跑大部分应用可一旦遇到分布式事务和副本调度问题MySQL那套思维方式就完全派不上用场。真正让我意识到问题严重性的是一次所谓迁移成功后的性能事故。当时一套业务系统从Oracle迁移到达梦功能测试全过结果一上线原本2秒的查询变成了40秒。后来排查发现问题根本不在SQL本身——迁移工具把Oracle的VARCHAR2字段原样搬了过来但达梦对字符集和字段长度的处理逻辑不同导致SQL里的大量条件判断走了全表扫描。这件事给我上了一课国产化数据库运维第一要务是先重新认识你要运维的库里到底有哪些看似熟悉实则陌生的机制。这篇文章就是围绕这个主题展开的。我会从性能调优、故障排查、备份恢复和日常运维体系四个维度把这几年来在国产化数据库上踩过的坑、验证过的方法、沉淀下来的流程一条条拆开讲清楚。内容主要面向已经从传统数据库迁移过来、或者正准备接手国产化库的DBA和运维工程师。你会看到具体参数、真实案例和排查路径而不是泛泛而谈的加强监控、重视备份。2. 性能调优的第一步给数据库建立环境基线很多运维兄弟一上来就调参数这个习惯非常危险。国产化数据库不像MySQL有那么多社区最佳实践可以参考不同版本、不同部署方式的默认参数差异很大。我见过有人把openGauss的shared_buffers调到物理内存的50%结果操作系统因为缺页交换直接卡死也见过达梦库的buffer命中率只有70%还在拼命加内存参数实际瓶颈是SQL里的笛卡尔积。调优之前必须先建立环境基线。2.1 内存与缓冲池先会看命中率再动手改参数数据库性能调优的第一站永远是内存。对于PostgreSQL系的openGauss和KingbaseES核心参数是shared_buffers对达梦来说是BUFFER缓冲区对OceanBase来说则是memstore和block cache的协同。无论哪款你都要先学会一件事看缓存命中率。以openGauss为例可以通过系统视图dba_cache或者pg_stat_database查看缓存情况。一个健康的OLTP系统shared_buffers命中率长期应该在99%以上低于95%就要警惕了。但这里有个容易犯的错误很多人只看命中率指标忽略了命中率背后的代价。PostgreSQL系数据库有个特性叫double buffering——数据先经过操作系统文件缓存再进入shared_buffers。所以即使shared_buffers命中率不高操作系统缓存也能兜底一部分读请求。这时候盲目调大shared_buffers反而可能因为双份缓存导致内存浪费甚至触发OOM。达梦的缓冲区调优逻辑又不一样。它的BUFFER参数直接决定数据页在内存中的缓存大小相关视图是V$BUFFERPOOL里面有各缓冲区的大小、命中次数和淘汰次数。我在一次达梦调优中发现命中率低的原因是初始化参数BUFFER设置过小但单纯调大BUFFER后伴随大量更新操作日志缓冲区又成了瓶颈。所以达梦的调优思路更像Oracle内存参数是一个组合数据缓冲区、日志缓冲区、排序区、字典缓存必须一起看。这里分享一个我常用的基线检查套路。拿到一台新接手的国产化库我会先做四件事第一查看数据库版本和部署架构确认是单机还是主备或集群第二检查操作系统层的内存、swap和文件系统缓存现状搞清楚物理机的真实负载情况第三在业务低峰期抓一次全量的关键性能视图快照包括缓冲区命中率、连接数、活跃会话数和锁等待情况第四花一天时间记录业务高峰期的指标变化而不是看一个静态值就下结论。提示所有参数调整必须记录变更前后的基线数据。我见过太多人调参后说不出到底带来了多少提升就是因为缺失基线。没有基线就没有调优。2.2 连接数99%的数据库卡死其实是连接打满运维国产化数据库的过程中我遇到过最频繁的故障就是数据库无法连接。排查后往往发现不是数据库挂了而是连接数被占满。国产化数据库的连接管理各有各的脾气。openGauss的max_connections默认值通常不大应用侧连接池配置不合理时很容易打满达梦的会话数由参数MAX_SESSIONS控制而且每个会话还会占用内存资源两层因素叠加会导致实例响应变慢。连接数打满的经典场景是这样的业务高峰期应用连接池设置的maxActive是100但数据库的max_connections只有80。请求一多连接池不断尝试建连数据库端连接满后开始排队应用端等待超时后再次重试形成连接风暴。更可怕的是很多国产化数据库的连接建立比MySQL要重握手过程涉及认证、会话初始化、权限检查一旦连接风暴起来CPU也会被打高。处理这类问题我不会急着改max_connections。先要搞清楚到底是谁在占用连接。openGauss可以通过pg_stat_activity查看每个会话的来源IP、应用名和当前状态达梦则看V$SESSIONS。我通常会重点排查两类会话一类是长时间处于IDLE状态的空闲连接这种往往是应用连接池配置了空闲连接不回收导致的另一类是大量处于ACTIVE状态但执行时间很短的会话这种多半是应用代码里没有使用连接池每次请求都新建连接。如果是连接池配置问题我会建议开发侧把连接池的maxActive设置成数据库max_connections的70%左右同时配置合理的空闲回收时间。数据库侧则根据实际物理内存来评估可以支撑的最大连接数。以达梦为例一个会话的内存开销大概在2MB到5MB之间假设机器有64GB内存分配给实例32GB理论上支撑3000个会话没问题但还要留出执行SQL时的排序和临时空间。我一般会按每个会话8MB来估算给自己留足余量。2.3 日志与检查点参数性能调优里最容易被忽视的环节说到国产化数据库的性能调优大家关注最多的是内存和SQL但日志和检查点参数往往是拖垮性能的隐形杀手。PostgreSQL系的数据库有WAL日志机制达梦有REDO日志OceanBase则需要同时管理事务日志和合并major freeze机制。日志设计的好坏直接决定了数据库的写入性能和崩溃恢复时间。openGauss的checkpoint参数有个明显特点checkpoint_timeout默认值较保守每次触发检查点时需要把shared_buffers里的脏页全部刷到磁盘。如果业务写入量大而checkpoint间隔过短你就会看到磁盘I/O周期性飙升应用侧则表现为每隔几分钟出现一次写入抖动。我会把checkpoint_completion_target调整到0.8甚至0.9让刷盘动作平滑分摊到整个周期而不是集中在短时间内爆发。WAL日志的容量和归档策略同样关键。国产化数据库的数据目录如果被WAL日志文件占满会导致数据库直接停止写入。openGauss的wal_keep_size参数控制保留多少WAL日志用于备机同步设得太大会占磁盘设得太小会导致备机追不上日志而重建。这不是一个可以设置完就不管的参数需要结合主备之间的网络带宽和延迟来综合判断。达梦的REDO日志管理则是另一种风格。默认情况下达梦有多个REDO日志文件循环使用日志文件大小在初始化实例时确定。如果业务量激增而日志文件偏小日志切换会非常频繁每次切换可能伴随轻微的I/O波动。我遇到过一个案例达梦库的REDO日志只有256MB业务高峰每秒产生超过10MB的日志基本一两分钟就切一次导致系统整体响应变慢。这个问题的解法不是动态调整日志大小而是需要规划业务低峰期重建日志文件组把日志文件调整到合理大小。3. SQL调优实战九成性能问题都藏在执行计划里如果说环境基线是地基那SQL调优就是国产化数据库运维的主体工程。从我这些年的经验来看迁移到国产化数据库后出现的性能问题90%以上都能在执行计划里找到答案。但问题的关键恰恰在于——国产化数据库的执行计划跟你在MySQL和Oracle里习惯看到的有很大差异。3.1 看懂三种风格迥异的执行计划先说说怎么获取执行计划。openGauss和KingbaseES这类PostgreSQL系的库使用EXPLAIN命令输出的是树状节点结构从下往上读每个节点会展示扫描方式、预估行数、实际行数和执行时间。达梦更接近Oracle风格EXPLAIN输出的是执行计划表格每一行代表一个操作步骤ID从0开始往后递增父ID和子ID的关系需要仔细分辨。OceanBase在MySQL兼容模式下EXPLAIN输出的格式和MySQL几乎一致但你会发现一个特殊现象分布式计划中会出现EXCHANGE节点这是数据在节点间流转的标志MySQL里根本不存在。这里我想重点讲一个容易被误解的概念执行计划里的预估行数和实际行数。在PostgreSQL系数据库里EXPLAIN默认显示的是预估行数是基于统计信息计算出来的不是真实执行结果。如果你用EXPLAIN看一个查询发现预估行数和实际执行效果差距很大通常意味着统计信息过期了。而EXPLAIN ANALYZE才会真正执行SQL输出实际行数和真实耗时代价是你必须接受这条SQL在线上真跑一遍。我处理过的一个真实案例某系统从Oracle迁移到openGauss后有一条查询原来只要300毫秒迁移后变成了15秒。查看执行计划后发现驱动表选择错误优化器选择了从大表开始嵌套循环连接而不是先扫描小表。原因是迁移后统计信息没有采集优化器对小表的行数评估严重偏高。解决方式很简单执行ANALYZE重新采集统计信息问题立竿见影地消失了。这个案例的教训是遇到国产化数据库性能问题先看执行计划再查统计信息千万不要上来就改写SQL。注意国产化数据库的优化器成熟度参差不齐。以openGauss为代表的PostgreSQL系优化器能力相对成熟但需要统计信息支撑达梦的优化器在某些复杂关联查询上的表现不如Oracle稳定分布式数据库如OceanBase则受数据分布和副本路由策略影响较大。理解每款数据库的优化器特点是SQL调优的前提。3.2 索引失效隐式转换和函数包裹的坑国产化数据库上最常见的索引失效原因和传统数据库没什么两样但杀伤力更大。因为很多国产化数据库的优化器在做隐式转换时策略比MySQL更保守更容易放弃索引。举一个高频场景。某表的主键字段是VARCHAR类型存储的是纯数字字符串。应用代码里写查询条件时用了WHERE id 123456这里的123456是数字类型。openGauss在执行这条SQL时会把VARCHAR字段隐式转换为数字再比较这种转换会直接导致索引失效。在MySQL里某些情况下优化器还能通过内部转换走索引但在PostgreSQL系里基本是必走全表扫描。排查的时候你可能会去怀疑SQL复杂、怀疑统计信息、怀疑硬件性能但真正的凶手就是一行不起眼的类型不匹配。函数包裹索引列是另一个重灾区。比如在时间字段上用了TO_CHAR(create_time) 2024-01-01这样的写法索引列被函数包裹后索引完全无法使用。正确的写法是create_time BETWEEN 2024-01-01 AND 2024-01-02。这类问题在国产化数据库上尤其隐蔽因为很多应用是从Oracle迁移过来的Oracle里对函数索引的使用比较普遍迁移后函数索引没有跟着建上或者国产化库对函数索引的支持不如Oracle完善结果就是SQL语义没变、性能却崩了。索引维护上还有一类容易被忽略的问题国产化数据库的大多数索引在大量删除和更新后会产生膨胀。PostgreSQL系的数据库有专门的VACUUM机制来清理死元组达梦也类似。如果长期不做清理索引膨胀到一定程度即使有索引也会因为扫描大量无效页而变慢。这不是索引失效但表现一模一样。我建议运维国产化库时把索引膨胀检查做成例行任务通过查系统表定期统计每个索引的大小和有效数据量的比例。3.3 统计信息国产化优化器的命根子前面反复提到统计信息这里展开说说。国产化数据库的优化器生成执行计划依赖的是表和索引的统计信息——包括行数、数据分布、空值比例、平均字段长度等。这些信息不是实时准确的而是通过ANALYZE或类似命令周期性采集的。如果采集不及时优化器就是在闭着眼睛做决策。我见过一个典型问题某业务表每天新增大量数据但统计信息采集任务配置的是一周执行一次。优化器拿到一周前的统计信息以为表只有100万行实际已经涨到500万行。执行关联查询时优化器选择了嵌套循环连接执行了超过一亿次的内层循环扫描数据库直接被拖垮。国产化数据库的统计信息采集有几个细节需要注意。第一采集的触发时机要合理。建议在业务低峰期每天执行一次位置可以选择深夜2点到4点之间。第二采样比例不是越高越好。全量采样100%采样耗时很长在几十GB的大表上会造成严重I/O压力对于大部分场景10%到30%的采样率已经足够优化器做判断。第三采集任务本身也要有监控。如果采集任务失败连续两天没有人发现线上SQL已经开始走错执行计划了。还有一个小技巧对于数据分布极度不均匀的字段比如订单状态这类只有少数几个值的字段普通统计信息根本无法真实反映分布情况。这时候要利用数据库提供的高级统计能力比如openGauss支持的直方图来帮助优化器做出正确估算。4. 故障排查从收到告警到定位根因的完整链路这一章是实战经验最集中的部分。国产化数据库的故障排查难的不是某个具体问题的处理而是缺乏一套完整的排查方法论。遇到问题就重启是我见过最普遍也最危险的做法。下面我把这些年踩过的坑按照故障类型逐个拆解。4.1 数据库卡死了先分清是真死还是假死数据库卡死了是我接手运维以来听到最多的描述。但所谓卡死可能是完全不同的几种情况。第一种是数据库进程假死实例还在运行但所有会话都阻塞了新连接也进不来第二种是数据库进程真的退出服务不可用第三种是数据库本身正常但应用服务器和数据库之间的网络出了问题表现也是连不上。判断真假死最直接的方式是看操作系统层。我一般会先查数据库进程状态和CPU占用然后看系统负载和I/O等待。如果数据库进程的CPU占用很高但响应极慢说明实例内部在做大量计算很可能是某条SQL引发了资源争用如果数据库进程CPU很低但系统I/O等待很高那问题大概率在存储层可能是其他业务抢占磁盘I/O也可能是磁盘本身性能下降。我在达梦上遇到过一次典型案例业务反馈系统崩溃了但数据库进程还在CPU占用只有个位数。排查后发现一条UPDATE语句持有了一张表的行锁后续所有针对这张表的写操作都在等待锁释放而持有锁的事务因为应用端没有提交一直挂着。这种场景下数据库从外面看毫无负载实际上内部已经乱成一锅粥。处理方式不是重启而是找到阻塞源头确认事务后在业务侧协调提交或回滚必要时才考虑由DBA手动终止该会话。4.2 慢SQL定位把慢查询日志用出花来国产化数据库基本都有慢查询日志但很多人的配置方式是开了就行从来没有认真分析过里面的内容。慢查询日志的价值不只是记录哪条SQL慢而是通过分析能得出业务负载的全貌。openGauss的慢查询日志默认可能没开启或者阈值设置不合理。我建议把慢查询阈值设置为1秒这个设置足够发现大多数需要优化的SQL又不会因为采集过多噪声影响排查。达梦的慢查询相关参数则在配置文件里控制。开启慢查询日志后还需要保证日志不会被频繁覆盖要给日志文件设置合理的滚动策略否则你会在需要排查的时候发现最早的日志已经被冲掉了。拿到慢SQL后不要一条一条手工看。先做聚合分析找出执行次数多、平均耗时长、总耗时占比高的SQL这些才是真正消耗数据库资源的大头。我习惯的做法是写一个简单的脚本来解析慢查询日志按SQL文本取模汇总输出执行次数、平均耗时、最大耗时和总耗时然后排序取前20条。分析的结果往往很有意思系统里80%的资源消耗集中在不到10条SQL上。有一次我在openGauss上做慢SQL分析发现一条SELECT COUNT(*)语句每秒钟被执行上百次每次耗时50到100毫秒总量惊人。调用链追溯后发现是应用里某个定时任务在循环调用而不是什么复杂的业务逻辑。这种问题单纯调优SQL没用必须推动应用侧改代码。这也是我想强调的运维工程师排查慢SQL时不能只盯着数据库端的执行计划还要有全局视角追踪SQL从哪里来、为什么这么频繁。4.3 主备切换与脑裂分布式架构下的高可用之痛国产化数据库的高可用方案五花八门。达梦有数据守护Data WatchopenGauss有自带的流复制和相应的管理工具OceanBase本身是分布式架构节点角色有选举机制。不同架构的高可用切换故障表现和处理方式完全不同。先说PostgreSQL系的主备架构。openGauss的主备复制是物理流复制模式备机通过接收WAL日志进行回放。常见故障是主备延迟持续增大。有一次我发现备机的replay lag一直在涨主库的WAL日志发送不过来。排查结果是备机的磁盘I/O能力不如主机回放速度跟不上主库的写入速度。这个问题的本质是硬件选型问题不是软件配置能彻底解决的但可以通过在主库侧调整WAL发送参数、在备机侧优化回放进程的方式缓解。达梦的数据守护机制是另一种风格。主备之间通过REDO日志传输实现同步切换时需要调用DM Watcher组件来检测故障并执行切换。我在达梦主备切换演练中踩过一个坑切换完成后新主库开始接收业务写入但原来的主库在恢复网络后并没有自动降级为备机导致两个节点同时接受写入请求数据出现分叉。解决方式是在切换流程里必须明确执行原主库降级这一步骤并且要有专门的脚本处理异常场景下的冲突解决。OceanBase这类分布式数据库的高可用又是完全不同的思路。节点的状态由选举协议决定故障节点会被自动踢出副本成员列表。我在这里的运维经验是不要试图手工介入节点角色而是通过运维平台观察副本状态和成员变化。分布式数据库的脑裂问题是靠协议层解决的人工干预反而容易造成二次故障。你需要做的是保证网络连通性、保证时钟同步然后相信协议做好监控和告警。5. 备份恢复与容灾演练平时不练出事必乱运维圈有句话备份做了不代表能恢复恢复演练过了才算数。这句话在国产化数据库上尤其适用。因为很多国产化数据库的备份工具和恢复流程跟传统数据库差异太大如果平时不做演练真出事的时候根本来不及研究。5.1 备份工具选型与策略制定国产化数据库大多自带物理备份工具。openGauss提供了gs_backup等工具支持全量备份和增量备份达梦的备份命令是BACKUP DATABASE支持全备、增备和归档日志备份OceanBase这类分布式数据库则需要通过专用的备份恢复组件配合对象存储或文件系统来存放备份集。备份策略的核心参数有三个全备频率、增备频率和备份保留周期。我建议的策略是核心业务库每天做一次增量备份每周做一次全量备份保留最近30天的备份集。如果业务是关键交易型系统还要把归档日志每30分钟备份一次这样即使数据库发生故障也能通过全量备份增量备份归档日志的组合恢复到最近30分钟内。有一点特别想提醒不要只看备份是否成功还要看备份集是否完整可读。我在一次检查中发现某达梦库的备份任务连续一周执行成功但备份文件所在磁盘已经满了新的备份其实是覆盖了旧备份后才写进去的等于实际只有最近一天的备份可用。这类问题靠告警是发现不了的必须定期检查备份文件的真实大小、数量和一致性。5.2 恢复演练中踩过的真实教训恢复演练这件事理论大家都懂但实操总会有意外。我做国产化数据库恢复演练时遇到过几个印象深刻的坑。第一次是openGauss的恢复演练。测试环境做了全量备份然后模拟数据文件损坏执行恢复操作。结果发现光恢复数据文件还不够还需要把备份期间的WAL日志一并恢复否则数据库无法启动到一致性状态。我花了很长时间才搞清楚这个流程原因是测试环境没有提前准备好归档日志目录的清理策略导致恢复时找不到对应的日志段。第二次是达梦的恢复演练。当时的场景是要恢复到某个时间点需要使用归档日志执行不完全恢复。我在恢复过程中漏了一步——没有先备份原有的归档日志导致恢复过程中需要应用某个归档时发现文件已被重新生成。这些细节文档里都写了但只有亲手操作过一次才能真正形成肌肉记忆。我现在的建议是每个季度至少做一次全流程恢复演练演练内容包括全量恢复、增量应用、日志应用和启动验证。演练要模拟真实故障场景比如数据库误删了一张表或者数据目录损坏。每次演练后写一份恢复报告记录实际耗时、操作步骤、遇到的问题和优化项。这样真出事故的时候你手里有一本已经验证过的操作手册而不是临时翻文档。6. 常见问题速查表与避坑心得最后这部分我把这些年运维国产化数据库遇到过的高频问题整理成速查表再补充一些常规文档里不会写的实操心得。建议把这个表打印出来贴在工位排查问题时先对照一遍。现象可能原因排查手段解决方案数据库无法连接连接数打满查pg_stat_activity或V$SESSIONS统计活跃会话数调整连接池配置、清理空闲会话、评估max_connectionsSQL执行突然变慢统计信息过期、索引失效EXPLAIN查看执行计划和实际行数执行ANALYZE、重建索引、改写SQL消除隐式转换数据库CPU飙升大量慢SQL并发抓取活跃会话定位TOP SQL针对SQL做调优、必要时限流或拆分大事务磁盘I/O周期性抖动checkpoint集中刷盘观察I/O曲线时间点调整checkpoint_timeout和completion_target参数主备延迟持续增大备机性能不足或网络带宽瓶颈查主备复制状态和延迟指标硬件排查、WAL发送参数优化、网络带宽扩容事务一直不提交应用代码遗漏提交查长事务和锁等待协调应用侧处理、必要时终止该会话备份文件占用异常增长备份保留策略未生效检查备份目录和日志清理过期备份、重新配置保留周期几个想补充的避坑心得都是拿真金白银换来的。第一个心得不要在业务高峰期做任何有风险的变更。这话听起来像废话但国产化数据库运维中我见过太多人为了赶进度在下午三点改一个内存参数然后引发雪崩。所有涉及重启或参数生效范围较大的变更一律安排在业务低峰窗口并且要有回退方案。第二个心得国产化数据库的官方文档一定要逐字读特别是参数说明部分。我遇到过明明参数名一样但openGauss和KingbaseES的默认值、取值范围、生效方式完全不同的情况。不要凭PostgreSQL的经验去套openGauss的参数也不要凭Oracle的经验去套达梦的参数。版本之间也有差异生产环境升级前一定要在测试环境把升级影响面完整验证一遍。第三个心得监控告警宁可过度也不要缺失。国产化数据库的监控生态不如MySQL和Oracle丰富但采集关键指标这件事不能省。至少要把实例存活、连接数使用率、缓冲区命中率、慢SQL数量、主备复制状态、磁盘空间这几个指标纳入监控。告警阈值要结合你自己的基线数据来定不要照抄别人的配置。写在最后的几句体己话这几年代维国产化数据库我的最大感受是技术本身并不神秘难的是心态和习惯的转变。很多人遇到国产化库的问题第一反应是是不是数据库不行但我验证过太多次——最后查出来都是应用侧SQL写法、配置不合理、硬件选型不合适这些老问题。国产化数据库确实有生态不如成熟商业库的短板但这不代表它可以被当作性能问题的背锅侠。我的切身体会是做好国产化数据库运维核心就三件事一是建立基线让你对每个指标的正常范围心中有数二是重视执行计划和统计信息这是所有调优动作的出发点三是把备份恢复和故障演练当成和日常监控同等重要的工作来对待。这三件事做扎实了不管是openGauss、达梦还是OceanBase你都能吃得透、扛得住。最后再分享一个小技巧每接手一个新环境我做的第一件事永远是建一个运维手册文档把版本信息、参数配置、备份策略、历史故障都记录在案。这个文档平时看着没什么用等出了事需要快速定位的时候它就是你的救命稻草。运维这个活儿拼的从来不是临场发挥而是平时的积累和准备。