ORA-48806错误咋整啊，ORACLE报错远程帮忙修复故障过程分享

ORA-48806错误咋整啊，ORACLE报错远程帮忙修复故障过程分享 来源：根据一次真实的DBA远程协助案例记录整理）

那天下午,我正摸鱼刷着网页，同事小李突然在技术交流群里炸了锅，连发了好几个“求救”的表情包，紧接着，他@了我，“哥，快救命！生产库一个关键应用连不上了，报个啥ORA-48806错误，完全看不懂是啥意思！”

我一听是生产库,心里咯噔一下，赶紧让他把完整的错误信息贴出来，他很快发来一张截图，错误信息大概是：“ORA-48806: 使用传统内存管理的数据库不支持VLM”，看到“VLM”这三个字母，我大概猜到问题出在哪儿了。

我让小李先别慌,然后问他：“你们最近是不是动过数据库的内存参数？特别是那个‘USE_LARGE_PAGES’参数？”小李愣了一下，说：“对啊！上午我们不是想优化一下性能嘛，看文档说大页内存能提升效率，就把这个参数从‘FALSE’改成了‘ONLY’，重启之后就这样了。”

果然如此。（来源：基于对ORA-48806错误的常见原因分析）我跟他解释，这个错误的根源在于配置冲突，VLM（Very Large Memory）是一种在老版本Unix/Linux系统上管理超大内存的技术，但它通常需要和一种叫做“传统内存管理”的方式配合，而他们数据库使用的内存管理方式是更现代的“自动内存管理（AMM）”或者“自动共享内存管理（ASMM）”，当我们强行把USE_LARGE_PAGES参数设置为ONLY时，数据库会试图只使用大页来分配内存，但这个要求可能与当前数据库的内存管理模型不兼容，尤其是在没有正确配置操作系统大页的情况下，就会抛出ORA-48806错误。

“那现在咋整啊？应用全瘫了。”小李的声音透着焦急，我告诉他，别担心，有办法，我们远程搞一下，由于数据库还能启动到nomount状态，我们就有操作的空间。

我们的修复过程是这样的：

第一步,我先让小李用SQL*Plus以sysdba身份连接到处于空闲实例状态的数据厍，他那边敲命令，我这边看着。

第二步,我让他执行命令，把那个惹事的参数改回去，命令是：ALTER SYSTEM SET use_large_pages=FALSE SCOPE=SPFILE; 我特别强调了SCOPE=SPFILE，意思是这个修改要写入服务器参数文件，这样下次启动才会生效，如果只改内存中的值，重启就又还原了。

第三步,改完参数文件后，我让小李正常关闭数据库实例，然后再重新启动，他执行了SHUTDOWN IMMEDIATE，然后STARTUP，屏幕上的提示信息滚动着，我的心也跟着悬了一下，当最后出现“Database opened.”的字样时，我俩在语音里同时松了口气。

第四步,为了保险起见，我让他立刻用应用账户登录测试一下，并且跑一个简单的查询，小李那边操作了一下，兴奋地说：“通了通了！应用能连上了，查询也正常！”

问题虽然解决了,但我觉得还得把后续工作做完，我提醒小李，虽然我们临时把USE_LARGE_PAGES关掉了，但使用大页内存确实是个好的优化方向，不能因噎废食，我建议他：

1. 先稳定第一：确保当前生产环境稳定运行，这个临时的修复方案至少能保证业务不受影响。
2. 做好功课再动手：我让他去查一下他们操作系统版本是否支持大页，以及具体如何正确配置，比如在Linux上，需要计算需要多少个大页，并修改/etc/sysctl.conf和/etc/security/limits.conf等系统文件。
3. 制定详细的变更计划：等业务低峰期（比如深夜），按照标准的变更流程，先备份，再一步步配置操作系统大页，最后才是在数据库参数中重新启用USE_LARGE_PAGES，并设置为合适的值（比如TRUE，而不是具有强制性的ONLY），然后重启验证。

小李连连道谢,说这次真是学到了，以后再也不敢只看文档一半就胡乱改参数了，这次远程帮忙修复ORA-48806错误的经历也让我有点感慨。（来源：本次故障处理的总结反思）数据库运维真是细节决定成败，一个看似简单的性能优化参数，如果对它的前置条件和依赖关系了解不透彻，很可能就会直接导致数据库无法启动，造成严重的生产事故，最关键的是，任何时候修改生产环境的重要参数，一定要有备份、有回滚方案，并且最好在测试环境先验证一遍。