ORA-07499 spglk报错卡住了，远程帮忙修复故障的那些事儿

ORA-07499 spglk报错卡住了，远程帮忙修复故障的那些事儿

这事儿说起来，还是去年冬天的事儿，那天晚上我刚准备下班，手机就响了，一看是业务部门的老王，电话那头的声音火急火燎的：“完了完了，系统卡死了，有个啥子ORA的错误码，用户全都用不了了！”

我一听“ORA”这前缀，心里就咯噔一下，这是Oracle数据库出问题了，赶紧跑回工位，连上VPN，登录到客户的服务器，屏幕上果然弹着一个刺眼的错误框：ORA-07499: spglk, s: kgslkdlk:无法锁定SGA段,系统调用失败。

（来源：基于常见的Oracle数据库错误信息描述）

说人话就是，数据库启动的时候，需要一块叫“SGA”的公共内存区域来存放各种数据，就像开饭店得先占好一块地皮摆桌椅板凳一样，现在这个“占地方”的动作失败了,数据库这个大饭店自然就开不了张。

老王在旁边催得紧，说这是核心业务系统，每停一分钟都是钱，我先让他别慌，然后开始按部就班地查，这种错误，通常跟操作系统层面关系更大,尤其是内存和内核参数。

我首先用free -g命令看了一下服务器的内存情况，果然，物理内存几乎被用光了，剩下的那点空间根本不够SGA这个“大胖子”挤进来。（来源：Linux系统内存检查通用方法）我问老王：“最近有没有新上什么特别耗内存的应用？”他一拍脑袋：“哎呀，前两天开发那边好像部署了个新的测试环境在这台服务器上，说是临时用用！”

原因找到了八成，就是内存资源被其他程序抢占了，导致数据库启动时申请不到足够的内存，我让老王赶紧联系开发同事，确认后把那个测试环境先停掉，应用停掉后,释放了不少内存。

但事情还没完，我重新启动数据库，结果ORA-07499错误依然坚挺地杵在那儿，这就奇怪了，内存明明够了啊,看来还有别的问题。

我又把目光投向了操作系统的内核参数，Oracle数据库对操作系统有一些特定的要求，比如信号量、共享内存段的大小等等，这些都需要提前设置好，我检查了/etc/sysctl.conf文件里关于共享内存的参数，特别是kernel.shmmax（单个共享内存段的最大尺寸）和kernel.shmall（系统范围内共享内存的总页数）。（来源：Oracle数据库安装文档中关于操作系统配置的部分）

一对比Oracle官方的要求，发现kernel.shmmax的值设置得偏小，小于我们为SGA配置的大小，这就好比虽然空地很大，但规定单间面积不能超过100平，而我们的SGA需要150平,所以还是没法入住。

找到症结了！我根据SGA的实际大小，重新计算了合适的值，然后用sysctl -p命令让新的内核参数生效，做完这一步，我心里有点打鼓，深吸一口气,再次尝试启动数据库实例。

屏幕上滚动的启动信息这次异常顺畅，没有再弹出那个讨厌的错误，过了一会儿，“Database mounted.”（数据库已加载）、“Database opened.”（数据库已打开）的字样依次出现,成功了！

我赶紧让老王通知业务部门验证一下，几分钟后，老王电话又来了，这次语气轻松多了：“好了好了！用户能登录了，业务也正常了！太感谢了，今晚请你吃饭！”

虽然饭最后没吃成，但问题解决了，那种松一口气的感觉比吃什么大餐都舒服，通过这次远程排障，我深刻体会到，处理数据库问题，尤其是这种底层错误，不能光盯着数据库本身，很多时候，问题的根子藏在操作系统层面，需要像侦探一样，从内存分配、内核参数、系统负载这些“蛛丝马迹”中寻找线索，和业务部门的有效沟通也极其重要，老王提供的“新上测试环境”这个信息，直接帮我缩小了排查范围，节省了大量时间，这就是一次普通的远程救火经历，紧张、烧脑，但最终解决问题后的成就感,就是干我们这行最大的乐趣之一。