Question

所以我试图为我的informix数据库创建一个新的db_space。我已经创建了一个文件（ / matiasInformixDBSpaces / dbspace_proyectoUTU ），并为informix用户和组提供了必要的权限。

现在，以 root 用户身份登录我正在尝试创建新的db_space。第一个是500 MB，这个我打算是1 GB。我面临的问题是，当我运行下面的命令时，它会显示“验证物理磁盘空间，请稍候......”它会永远停留在那里。

不会抛出任何错误或警告。我第一次这样做是超级快的。我不知道现在发生了什么。

onspaces -c -d proyectoUTUinformix -p /matiasInformixDBSpaces/dbspace_proyectoUTU -o 5000 -s 1000240

有人可以帮我弄清楚出了什么问题吗？

Answer 1

诊断步骤

我很好奇为什么你有一个非零偏移。如果名称引用原始设备而卷管理器使用start，那么它是有意义的。否则，很少使用非零偏移。但是，这对速度的影响可以忽略不计;它只是浪费了一点空间。

请标识您的平台以及您正在使用的Informix版本。

您是否从另一个终端窗口查看了文件的大小？

$ a6 timecmd -m -- onspaces -c -d auxilliary -p /opt/informix/dev/$IXS.auxilliary.c0 -o 0 -s 1000240
2018-04-16 22:27:07.348 [PID 71071] onspaces -c -d auxilliary -p /opt/informix/dev/osiris_19.auxilliary.c0 -o 0 -s 1000240
Verifying physical disk space, please wait ...
Space successfully added.

** WARNING **  A level 0 archive of Root DBSpace will need to be done.
2018-04-16 22:27:07.969 [PID 71071; status 0x0000]  -  0.620s
$

我在我自己的Mac上运行上面的命令（运行macOS 10.13.4，使用Informix 12.10.FC6 - 我需要升级！）创建了空文件并设置了权限。这台Mac有固态硬盘（SSD）。 a6命令运行程序'as informix'; timecmd比简单的time命令回应更多的时间信息 - 开始时间，执行命令，PID，然后完成时间，退出状态和持续时间。我将它用于长时间运行的命令，知道它在几个小时前启动是有帮助的。

显然，0.620秒很快 - 基本上是即时的。在你的系统上花费很长时间 - 最多几秒钟 - 写一个长度为1,024,245,760字节的文件，这是我最终得到的文件的大小。

因此，您需要仔细查看正在使用的磁盘。如果它是记忆棒，或通过调制解调器线路连接的远程安装文件系统，则可能需要很长时间。但主流SSD或旋转磁盘应该不会花很长时间。

鉴于发生了什么，请中断命令。查看在线日志文件中的内容 - onstat -m为我显示：

05:27:07 Space 'auxilliary' added.
05:30:18 Space 'auxilliary' dropped.

我在UTC时区运行我的服务器;我在美国/太平洋地区，目前是UTC-7。因此22:27在本地对应于UTC中的05:27。

显然，'删除'消息对应于我的onspaces -d auxilliary命令，在add命令后大约运行三分钟。如果在联机日志文件中找不到“添加空格”消息，则操作失败。如果您发现“添加空间”消息，则终端会冻结。（你没有在其中键入 control-S ，是吗？尝试 control-Q 重新启动它。）你需要做一个提到的档案，如果空间被添加，当然（在掉落后也需要一个）。

尝试使用：

time dd if=/dev/zero of=/matiasInformixDBSpaces/dbspace_proyectoUTU bs=1024 count=1000240

看看需要多长时间。我跑了：

$ a6 timecmd -m -- dd if=/dev/zero of=/opt/informix/dev/$IXS.auxilliary.c0 bs=1024 count=1000240
2018-04-16 22:43:05.006 [PID 71161] a6 dd 'if=/dev/zero' 'of=/opt/informix/dev/osiris_19.auxilliary.c0' 'bs=1024' 'count=1000240'
1000240+0 records in
1000240+0 records out
1024245760 bytes transferred in 6.740104 secs (151962902 bytes/sec)
2018-04-16 22:43:11.765 [PID 71161; status 0x0000]  -  6.758s
$

这比onspaces命令长得多，这意味着onspaces没有写入磁盘文件中的每个块。当我分析文件的内容时，我得到了：

$ a6 timecmd -m -- odx $opt/$IXS.auxilliary.c0
2018-04-16 23:10:26.836 [PID 71321] odx /opt/informix/dev/osiris_19.auxilliary.c0
0x0000: 00 00 00 00 04 00 50 35 00 00 00 18 18 00 E4 0F   ......P5........
0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
* (253)
0x0FF0: 00 00 00 00 00 00 00 00 00 00 00 00 42 35 16 00   ............B5..
0x1000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
* (255)
0x2000: 02 00 00 00 04 00 50 35 01 00 08 08 20 00 D8 0F   ......P5.... ...
0x2010: 00 00 00 00 00 00 00 00 35 00 00 00 97 D0 03 00   ........5.......
0x2020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
* (252)
0x2FF0: 00 00 00 00 00 00 00 00 18 00 08 00 40 35 16 00   ............@5..
0x3000: 03 00 00 00 04 00 55 35 00 00 04 08 18 00 E4 0F   ......U5........
0x3010: 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00   ................
0x3020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
* (252)
0x3FF0: 00 00 00 00 00 00 00 00 00 00 00 00 44 35 16 00   ............D5..
0x4000: 04 00 00 00 04 00 51 35 05 00 02 08 D4 00 14 0F   ......Q5........
0x4010: 00 00 00 00 00 00 00 00 01 00 40 00 01 28 00 00   ..........@..(..
0x4020: 88 00 00 00 00 00 00 00 01 00 00 10 12 8F D5 5A   ...............Z
0x4030: 01 00 00 00 32 00 00 00 32 00 00 00 32 00 00 00   ....2...2...2...
0x4040: 02 00 00 00 00 00 00 00 FF FF FF FF 01 00 40 00   ..............@.
0x4050: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x4060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x4070: 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00   ................
0x4080: 01 00 00 00 00 00 00 00 01 00 00 00 0C 00 00 00   ................
0x4090: 18 00 6D 00 00 00 00 00 00 00 00 00 00 00 00 00   ..m.............
0x40A0: 61 75 78 69 6C 6C 69 61 72 79 00 69 6E 66 6F 72   auxilliary.infor
0x40B0: 6D 69 78 00 54 42 4C 53 70 61 63 65 00 00 00 00   mix.TBLSpace....
0x40C0: 00 00 00 00 00 04 00 00 00 03 00 00 00 32 00 00   .............2..
0x40D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
* (240)
0x4FE0: 00 00 00 00 00 00 00 00 C0 00 14 00 C0 00 00 00   ................
0x4FF0: C0 00 00 00 A0 00 20 00 18 00 88 00 47 35 16 00   ...... .....G5..
0x5000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
* (64014079)
0x3D0CC000:
2018-04-16 23:10:30.808 [PID 71321; status 0x0000]  -  3.971s
$

如您所见，某些控制信息被写入第一个0x5000字节，但此后，该文件全部为空字节。鉴于onspaces的亚秒级时间意味着它实际上没有写入空间，我不太确定'验证物理磁盘空间'是什么意思。

分辨率

如果您按照以下评论中的讨论进行操作，您将看到保留的原因是系统处于状态CKPT REQ（需要检查点）。例如，可以从onstat输出中看到这一点。为了解决这个问题，需要添加新日志或者需要备份逻辑日志。

警告：通过将备份设备设置为/dev/null，您可以让服务器运行而不会被阻止，这在设置系统时可能没问题，但不会是生产中的好主意。

查看Backup and Restore Guide以了解ON-BAR和ON-Tape两种可能的备份系统。

很大程度上取决于您将运行服务器的上下文。如果已经存在用于运行使用BSA接口的备份的系统，则使用ON-BAR进行集成可能是最合适的。如果您没有这样的企业备份系统，那么ON-Tape可能会更简单。

在投入生产之前，请确保您有适当的备份策略，并且您已经实践了系统的备份和恢复。您需要确信备份有效。您需要确信自己知道如何使用它们。

确保您的磁盘没有直接硬连接到设备名称。您可以使用符号链接，也可以使用文件名。您需要能够重新定位数据，并且硬连线设备名称可能会使这一点变得困难。

Informix - 创建db_space时没有发生任何事情

1 个答案:

诊断步骤

分辨率