凌晨三点，手机屏幕亮得像块烙铁。值班同事在群里连发三条语音，每条都是三十秒以上的急促语气，背景音里还混着机房空调的嗡鸣。我眯着眼点开一条，听到的关键词就四个字：数据库挂了。监控大屏上的告警红点从个位数跳到了三位数，像一场突然爆发的红色流感。这场景不陌生，但每次来，都让人头皮发麻。
先别急着往服务器跟前冲。数据库启动不了，最常见的原因往往是磁盘满了。你可能会觉得这说法太土，但操作系统的日志里，八成写着“No space left on device”。我见过不止一次，开发环境里跑着跑着，归档日志把分区撑爆，数据库进程想写自己的控制文件都腾不出地方，只能原地罢工。这时候你敲多少遍startup都没用，系统连个错误提示都懒得给你，就回你一句“ORA-xx”，剩下全靠你自己猜。先df -h看一眼，如果使用率到了99%，别犹豫，清理归档日志或者扩容，比你在那儿琢磨配置文件管用十倍。
磁盘没问题，那就得看看内存和进程。数据库启动是个精细活，它对内存的需求就像酒鬼对酒精的渴望，缺一口都不行。有时候你明明看到服务器还有几个G的free内存，但数据库就是起不来，报错说“ORA-27102: out of memory”。为啥？因为Linux的overcommit机制可能在跟你开玩笑。你设置了SGA和PGA的总和，超过了系统允许的overcommit额度，内核直接拒绝分配。这时候别光盯着free看，得检查/proc/sys/vm/overcommitmemory的值，还要翻翻dmesg，看看有没有“Out of memory: Kill process”之类的字样。我遇到过最离谱的一次，是隔壁部门有人偷偷跑了个大数据计算任务，把内存吃干抹净，数据库启动时申请不到一块连续的共享内存，直接放弃治疗。
内存和磁盘都正常，就要怀疑监听和端口了。有时候数据库进程其实已经起来了，但你连不上，以为启动失败。你去看lsnrctl status，发现监听服务根本没注册上。这可能是监听配置文件listener.ora里的主机名写错了，或者IP变了没同步。更常见的是端口被占用，8080这种端口谁都用，你要是没改过默认端口，很可能被某个web服务抢先占了。数据库起不来，你会看到日志里反复出现“TNS-12541: TNS:no listener”的报错，但服务器的端口监听状态却是正常的。这时候你得用netstat -tlnp看清楚，到底是谁霸占着那个端口。别小看这个环节，至少一半的“启动失败”其实是连接层面的乌龙。
再往下挖，是权限和属主的问题。数据库文件、日志文件、控制文件，每个都有自己该有的属主和权限。你要是用root用户去启动数据库，或者某个文件被chmod改成了600，而运行数据库的用户不是属主，启动时就会报“Permission denied”。有个经典坑：你备份数据文件时用root复制了一份，结果属主变成了root，数据库读不了。检查这种问题，ls -l看一遍文件权限就清楚了，但很多人就是懒得看，非要反复重启碰运气，结果越碰越糟。数据库启动失败在这个环节上，往往还伴随一个更隐蔽的现象——alert日志里一条记录停在“recovery”或者“open”阶段，然后就没有然后了。别慌，先确认文件属主，再确认目录权限，顺序不能乱。
要是前面都排查完了，问题依旧，那大概率是数据文件损坏或者日志文件不一致。数据库启动时有三个阶段：nomount、open。nomount阶段只读参数文件，mount阶段读控制文件，open阶段要验证数据文件和数据字典。你发现卡在哪个阶段，就能缩小范围。比如卡在mount阶段，控制文件可能坏了；卡在open阶段，某个数据文件可能丢了或者损坏。这时候启动日志会明确告诉你哪个文件是罪魁祸首，比如“ORA-01157: cannot identify/lock data file 6 - see DBWR trace file”。很多人的第一反应是去恢复，但恢复之前得想清楚：你是不是最近改过表空间大小？是不是有过掉电？是不是做过不规范的冷备份？这些都可能留下隐患。
还有一类情况，数据库启动不了是人为的，而且是那种让你哭笑不得的人为。比如，有人改了初始化参数文件里的某个值，比如processes设得太小，或者sgamaxsize超过了物理内存，然后重启，数据库就再也起不来了。这种问题最气人，因为报错信息通常很模糊，比如“ORA-01078: failure in processing system parameters”，你根本不知道是哪个参数惹的祸。排查方法倒是简单，用strings命令查一下spfile里的内容，或者用show parameter看最近改动过的参数。但前提是你得知道去查，而不是在那儿瞎猜。我见过最夸张的一次，是有人把dbblock_size从8K改成了16K，然后整个库直接报废，连mount都过不去，只能从备份里恢复。
还有一个容易被忽略的角落——备份和恢复脚本。有时候数据库启动不了，是因为你昨天刚跑过一个备份脚本，而这个脚本在备份完成后，错误地删除了某个在线日志文件。又或者，你配置了归档模式，但归档目录满了，数据库在启动时做实例恢复，需要读取归档日志，结果读不到，就卡死了。这时候你去看alert日志，会看到“ORA-00308: cannot open archived log”的报错。解决办法不算难，要么清理归档空间，要么把归档日志补回来，但如果你没有备份，那就真的只能欲哭无泪了。所以，每次启动失败，先想清楚最近做了什么操作，尤其是自动化脚本和定时任务，它们往往是“沉默的凶手”。
数据库启动失败这事，本质上是系统在跟你说话。它想告诉你的信息，藏在日志里，藏在文件权限里，藏在参数配置里。你越是急着重启，越容易错过它给的关键线索。我见过太多人，一看到启动失败就反复敲startup命令，好像多敲几次数据库就能被叫醒似的。结果呢？告警越响越密，系统越崩越彻底。真正靠谱的做法，是先停下来，看日志，看磁盘，看内存，看权限，看归档，一项一项排除。你把这些都查完了，问题基本就现形了。要是查完了还找不到，那你就该怀疑是不是硬件层面出了故障，比如磁盘坏了，或者内存条有问题，这时候就得看dmesg和硬件监控了。
数据库启动不了，从来不是单一原因造成的，它像一场多因素叠加的故障交响乐。但你别怕，只要按部就班，从磁盘到内存，从权限到参数，从日志到归档，逐层剥开，总能找到那个“元凶”。系统告警频发不可怕，可怕的是你乱了阵脚，把时间耗在无意义的重复重启上。下次再遇到这种凌晨三点的电话，先深吸一口气，然后从df -h开始，一步步来。记住，数据库的启动日志，永远是它留给你的第一份自白书，你愿意读，它就愿意告诉你答案。
