GBase 8s共享内存段导致启动失败问题

## 一、问题现象

在执行数据库关闭操作后，重新启动 GBase 8s 数据库实例时，启动过程失败，并出现以下错误信息：

![](/media/202610/2026-10-10_164800_3147980.5988639380644897.png)

进一步检查数据库消息日志，发现以下异常信息：

```
Warning: The database license restriction limits
the total shared memory size for this server to 16777216 KB.
The size has been reset to the limit to bring up the database server.

shmget: [EEXIST][17]: key 52584801: shared memory already exists
mt_shm_init: can't create resident segment
```

其中，`shmget: [EEXIST][17]` 表示系统调用 `shmget()` 在尝试创建共享内存段时，发现指定键值对应的共享内存对象已经存在，且当前调用参数无法直接复用该对象。

该异常导致数据库无法正常完成共享内存初始化，最终出现 `Fatal error in shared memory creation` 错误。

## 二、原因分析

### 1. 共享内存资源残留

数据库实例关闭后，如果仍存在未清理的共享内存对象，重新启动时可能再次使用相同的共享内存键值，从而触发 `EEXIST` 错误。

需要注意，执行数据库关闭命令并不必然意味着所有操作系统级共享内存资源均已释放。是否存在残留资源，应结合共享内存状态、数据库进程状态以及数据库日志进行判断。

### 2. 数据库进程未完全退出

如果关闭操作完成后，仍有数据库相关进程处于运行状态，相关进程可能继续持有共享内存资源，导致后续启动失败。

因此，需要检查数据库实例是否已完全停止，以及是否存在异常退出或未正常清理的进程。

### 3. 共享内存键值冲突

数据库实例通过配置参数及内部初始化机制管理共享内存资源。如果原有共享内存对象尚未清理，而新实例初始化时再次申请相同键值，则可能发生资源冲突。

日志中的 `key 52584801` 是本次共享内存创建失败时涉及的键值，可用于辅助定位对应的共享内存对象。

### 4. 数据库许可证及共享内存容量限制

日志同时出现共享内存总量受到许可证限制的提示，说明当前实例的共享内存配置超过了对应许可允许的上限，数据库启动过程中对共享内存总量进行了调整。

该提示与共享内存创建失败同时出现，但不能仅凭这两条日志就认定许可证限制是本次启动失败的直接原因。应优先根据 `EEXIST` 错误排查共享内存对象冲突，并进一步核实实例许可证、共享内存配置及相关日志。

## 三、故障排查与处理

### 1. 检查数据库实例状态

首先确认数据库实例是否仍处于运行状态，并检查相关进程。

```
onstat -
onstat -m
ps -ef | grep -E '[o]ninit|[o]ninit'
```

其中，`onstat -` 用于查看实例状态，`onstat -m` 用于查看消息日志。进程检查命令仅用于辅助判断，不能仅根据进程名称判定实例是否已经完全停止。

如果数据库实例仍在运行，应优先通过数据库提供的正常关闭机制停止实例，避免直接删除正在使用的共享内存资源。

### 2. 检查操作系统共享内存

在 Linux 系统中，可通过以下命令查看 System V 共享内存对象：

```
ipcs -m
```

查看共享内存详细信息时，可重点关注以下字段：

* `shmid`：共享内存段标识符。

* `key`：共享内存键值。

* `owner`：共享内存对象所有者。

* `perms`：访问权限。

* `bytes`：共享内存段大小。

* `nattch`：当前连接到该共享内存段的进程数。

针对日志中出现的键值 `52584801`，可结合 `ipcs -m` 输出进行核对。需要注意，部分系统会以十六进制形式显示键值，因此应进行格式转换后再比较。

例如：

```
printf '%x\n' 52584801
```

如果发现相关共享内存对象，应进一步核实其归属实例、关联进程及当前使用状态，避免误判为无效残留资源。

### 3. 清理确认无用的共享内存对象

只有在确认数据库实例已经停止，且目标共享内存对象不再被任何有效数据库进程使用后，才可以考虑清理对应资源。

删除指定共享内存段的命令格式如下：

```
ipcrm -m <shmid>
```

其中，`<shmid>` 必须替换为 `ipcs -m` 输出中确认无误的共享内存段标识符。

例如：

```
ipcrm -m 16385
```

需要特别注意：`ipcrm -m` 接收的是共享内存段标识符 `shmid`，而不是共享内存键值 `key`。应逐个确认目标对象后再执行删除操作，不应直接批量清理所有属于数据库用户的共享内存段。

清理完成后，重新执行 `ipcs -m`，确认目标资源状态，再按照 GBase 8s 对应版本的标准流程启动数据库实例。

### 4. 检查数据库提供的清理工具

部分 Informix 版本提供了 `onclean` 等辅助工具，用于清理数据库相关共享内存、信号量及异常残留进程。

```
# 清理
./bin/onclean -vy
```

但 GBase 8s 属于 Informix 技术体系的衍生产品，具体命令是否存在、参数是否兼容以及清理行为是否一致，取决于实际产品版本和发行实现。

因此，不应直接假定 `onclean` 在所有 GBase 8s 版本中均可用。建议先检查当前安装目录中的工具及对应版本文档，确认适用性后再执行。

如果产品提供配套的数据库关闭脚本，应优先采用该版本官方支持的关闭和清理流程。

### 5. 谨慎评估 SERVERNUM 等配置参数

部分数据库实例的共享内存标识与实例配置参数存在关联。修改实例标识类参数可能改变后续启动时使用的资源标识，但不能保证原有共享内存对象会被自动清理。

因此，不建议将修改 `SERVERNUM` 作为共享内存冲突的首选解决方案。

如确需调整，应先确认 GBase 8s 当前版本对该参数的定义、适用范围及修改要求，并检查同一主机上其他数据库实例的配置，避免引入新的资源冲突。

## 四、建议的处理顺序

针对 `Fatal error in shared memory creation` 和 `shared memory already exists` 问题，建议按照以下顺序开展排查：

1. 查看数据库实例状态及消息日志，确认启动失败发生在共享内存初始化阶段。

2. 检查数据库相关进程，确认实例是否已经完全停止。

3. 使用 `ipcs -m` 检查共享内存对象，并核对日志中的键值。

```
# 指定shmid清理
ipcrm -m  {shmid}
```

4. 确认目标共享内存对象的归属、连接状态及是否仍被有效进程使用。

5. 按照当前 GBase 8s 版本支持的方式执行关闭、清理及资源回收操作。

6. 重新启动数据库，并检查实例状态及最新消息日志。

7. 如果仍然启动失败，继续核查共享内存容量、许可证限制、实例配置及操作系统资源限制。

## 五、总结

`Fatal error in shared memory creation` 是数据库共享内存初始化失败时出现的错误信息，而 `shmget: [EEXIST][17]: shared memory already exists` 则明确指向共享内存创建过程中存在对象冲突。

在 GBase 8s 故障排查过程中，应首先确认数据库进程是否完全退出，再检查操作系统共享内存对象的实际状态。对于已经确认无用的资源，可在满足安全条件后进行定向清理。

同时，需要区分共享内存对象冲突、共享内存容量不足以及许可证限制等不同问题，避免通过直接删除全部共享内存或随意修改实例配置的方式处理故障。

**核心原则：先确认实例状态，再定位共享内存对象，最后进行定向清理；所有操作均应以实际 GBase 8s 版本的产品行为和官方支持方式为依据。**