数据库管理-第六十二期 操作系统（20230322）

第六十二期 操作系统

一直以来，我都认为操作系统的基本了解，就现在的大环境而言更多的是Linux，是一个DBA必需的基础技能。然而就目前接触的行业来看，很多DBA都几乎没有Linux基础，甚至有些提供DBA服务的公司还将DBA和操作系统团队进行了强力划分。下面就举几个最近遇到的一些涉及数据库与操作系统的问题来佐证我的观点。

1 RAC

RAC集群，非一体机的话是需要在所有数据库节点除了安装操作系统以外，还需要对存储磁盘进行识别处理，这中间一般就会用上multipath和udev实现存储链路聚合和权限控制，当然除了使用基础的vi/vim或其他文本编辑命令来编辑配置文件外，还需要用啥ls/ll、cat、fdisk、scsi_id等一些列命令来支持获取各类配置所需要的信息。除了磁盘，还需要使用ntp、chrony甚至是xinetd来做时间同步。当然，如果对各个命令和配置都不是太熟悉，除了寻求度娘协助以外可能要需要-h/–help和man之类的命令。当然，一个DBA也可以完全不会这些操作，在GUI打开之前的所有准备都交给操作系统工程师和存储工程师（如果用静默安装还是得改响应文件输入命令）。
最近遇到协助处理的一个故障就是和udev有关，存储已经由软件实现了链路聚合，需要udev进行权限控制和磁盘映射，结果很奇快的发现DATA磁盘组涉及的LUN书写没问题，但是OCR磁盘组涉及的LUN识别就完全是把对应的具体的/dev/sd?和映射路径进行应对，就造成了每次服务器重启，存储磁盘盘符产生变化后，OCR涉及磁盘就无法正确识别导致集群无法启动，需要手工改udev配置文件（还不给改对）解决。最后还是把OCR那几行改成用磁盘UUID来映射解决了重启无法正常启动的问题。这个问题其实我还很纳闷为啥配置文件会一半对一半错。其实这个问题就是对udev和为啥用udev（或者multipath）不甚了解造成的，不知道为啥操作系统重启后存储盘符有可能会改变。
之前还说过一个疑似bug导致oraagent导致操作系统重启的问题，从操作系统看也是涉及到bug所说的scsi相关故障，然而数据库和操作系统没想着一起排查问题而是互相甩锅。这一点不得不说如果是SR介入，还是能很好处理的，为啥SR现在总叫提交AHF（TFA）的诊断收集，因为里面除了数据库也会包含操作系统各项日志，能够更全面的判断问题并提出解决方案。
最后一个问题则是另一个兄弟用OL7.9装了一套11g RAC，需要用ACFS来放OGG相关文件，结果测试没啥问题，结果生产就无法使用ACFS，其实除了内核兼容性，我还是建议11g装在5、6上，12-19装在7上，21以后的再考虑8、9。由于时间紧任务重，找到我给解决方案，只能说用nfs先凑凑呗。

2 OCM

其实OCM考试介绍里面委婉的介绍了“熟悉基本的Linux命令语言”，但是考过OCM的人
都知道，里面好是涉及了很多Linux的命令与服务：nfs、ssh/scp、cp、mv等等（太久没碰了好多都忘了）。总而言之是Linux不好，OCM也很难考得过。

3 上期补遗

上期内容的测试虽然说了即便是使用了Exadata，还是需要根据实际情况建立索引。那么哪些情况下是可以不建索引而充分利用smart scan offload特性呢（必要时建索引也是充分利用哈），一般就查询数据返回量超过一般索引配置建议且越是倾向于全表扫描效果越好。当然如何调用smart scan offload的方法有很多，其中最简便的就是开并行。

总结

老规矩，知道写了些啥。