Informix - 创建 db_space 时没有任何反应
Informix - Nothing happening when creating a db_space
所以我正在尝试为我的 informix 数据库创建一个新的 db_space。
我已经创建了一个文件 ( /matiasInformixDBSpaces/dbspace_proyectoUTU ) 并为 informix 用户和组授予了必要的权限。
现在，作为 root 用户登录，我正在尝试创建一个新的 db_space。第一个是 500 MB，这个我打算是 1 GB。我面临的问题是，当我 运行 下面的命令时，它说 "Verifying physical disk space, please wait..." 并且它永远留在那里。
没有抛出任何错误或警告。我第一次这样做的时候速度非常快。不知道现在怎么样了
onspaces -c -d proyectoUTUinformix -p /matiasInformixDBSpaces/dbspace_proyectoUTU -o 5000 -s 1000240
谁能帮我找出问题所在？
诊断步骤
我很好奇为什么你有一个非零偏移量。如果名称指的是原始设备并且卷管理器使用启动，那么它是有意义的。否则，很少使用非零偏移量。但是，这对速度的影响可以忽略不计；它只是浪费了一点 space.
请确定您的平台，以及您使用的 Informix 版本。
您是否从另一个终端查看过文件的大小window？
$ 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 （运行ning macOS 10.13.4，Informix 12.10.FC6 — 我需要升级！）创建了空的文件并设置权限。这个 Mac 有固态硬盘 (SSD)。 a6命令运行s程序'as informix'； timecmd 比简单的 time 命令回显更多的时间信息——开始时间、执行的命令、PID，然后是结束时间、退出状态和持续时间。我更多地将它用于长 运行ning 命令，知道它在几个小时前开始是有帮助的。
显然，0.620 秒很快——基本上是即时的。在您的系统上，写入一个 1,024,245,760 字节长的文件应该不会花费很长时间（最多几秒钟），这是我最终得到的文件的大小。
因此，您需要仔细查看您正在使用的磁盘。如果它是记忆棒，或通过调制解调器线路连接的远程安装的文件系统，则可能需要很长时间。但主流的 SSD 或旋转磁盘根本不会花很长时间。
鉴于发生的情况，中断命令。查看在线日志文件中的内容 — onstat -m 我显示：
05:27:07 Space 'auxilliary' added.
05:30:18 Space 'auxilliary' dropped.
我运行我的服务器在UTC时区；我在 US/Pacific，当前为 UTC-7。因此 22:27 在本地对应于 UTC 中的 05:27。
显然，'dropped' 消息对应于我的 onspaces -d auxilliary 命令，运行 在添加命令后大约三分钟。如果您在联机日志文件中找不到 'space added' 消息，则操作失败。如果您发现 'space added' 消息，您的终端将冻结。 （你没有在里面输入 control-S ，是吗？试试 control-Q 来重启它。）你需要如果添加了 space，当然要做提到的存档（删除后也需要一个）。
尝试使用：
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字节写入了一些控制信息，但此后文件全部为空字节。我不太确定 'verifying physical disk space' 是什么意思，因为 onspaces 的亚秒级时间意味着它实际上并没有写入 space.
分辨率
如果您关注下面评论中的讨论，您会发现阻塞的原因是系统处于 CKPT REQ 状态（需要检查点）。例如，这可以从 onstat 输出中看出。要解决这个问题，要么需要添加新日志，要么需要备份逻辑日志。
注意：通过将备份设备设置为/dev/null，您可以让服务器运行不被阻塞，这在设置时可能没问题系统，但在生产中不是一个好主意。
查看 Backup and Restore Guide 以了解 ON-BAR 和 ON-Tape 这两种可能的备份系统。
很大程度上取决于您 运行 安装服务器的环境。如果已经有一个使用 BSA 接口的 运行ning 备份系统，使用 ON-BAR 与之集成可能是最合适的。如果您没有这样的企业备份系统，那么 ON-Tape 可能更简单。
在投入生产之前，请确保您有正确的备份策略，并且您已经对系统进行了备份和恢复。
您需要确信您的备份有效。您需要确信自己知道如何使用它们。
请确保您的磁盘没有直接硬连接到设备名称。您可以使用符号链接，或使用文件名。您需要能够重新定位数据，而硬连线设备名称会使这变得困难。
所以我正在尝试为我的 informix 数据库创建一个新的 db_space。 我已经创建了一个文件 ( /matiasInformixDBSpaces/dbspace_proyectoUTU ) 并为 informix 用户和组授予了必要的权限。
现在，作为 root 用户登录，我正在尝试创建一个新的 db_space。第一个是 500 MB，这个我打算是 1 GB。我面临的问题是，当我 运行 下面的命令时，它说 "Verifying physical disk space, please wait..." 并且它永远留在那里。
没有抛出任何错误或警告。我第一次这样做的时候速度非常快。不知道现在怎么样了
onspaces -c -d proyectoUTUinformix -p /matiasInformixDBSpaces/dbspace_proyectoUTU -o 5000 -s 1000240
谁能帮我找出问题所在？
诊断步骤
我很好奇为什么你有一个非零偏移量。如果名称指的是原始设备并且卷管理器使用启动，那么它是有意义的。否则，很少使用非零偏移量。但是，这对速度的影响可以忽略不计；它只是浪费了一点 space.
请确定您的平台，以及您使用的 Informix 版本。
您是否从另一个终端查看过文件的大小window？
$ 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 （运行ning macOS 10.13.4，Informix 12.10.FC6 — 我需要升级！）创建了空的文件并设置权限。这个 Mac 有固态硬盘 (SSD)。 a6命令运行s程序'as informix'； timecmd 比简单的 time 命令回显更多的时间信息——开始时间、执行的命令、PID，然后是结束时间、退出状态和持续时间。我更多地将它用于长 运行ning 命令，知道它在几个小时前开始是有帮助的。
显然，0.620 秒很快——基本上是即时的。在您的系统上，写入一个 1,024,245,760 字节长的文件应该不会花费很长时间（最多几秒钟），这是我最终得到的文件的大小。
因此，您需要仔细查看您正在使用的磁盘。如果它是记忆棒，或通过调制解调器线路连接的远程安装的文件系统，则可能需要很长时间。但主流的 SSD 或旋转磁盘根本不会花很长时间。
鉴于发生的情况，中断命令。查看在线日志文件中的内容 — onstat -m 我显示：
05:27:07 Space 'auxilliary' added.
05:30:18 Space 'auxilliary' dropped.
我运行我的服务器在UTC时区；我在 US/Pacific，当前为 UTC-7。因此 22:27 在本地对应于 UTC 中的 05:27。
显然，'dropped' 消息对应于我的 onspaces -d auxilliary 命令，运行 在添加命令后大约三分钟。如果您在联机日志文件中找不到 'space added' 消息，则操作失败。如果您发现 'space added' 消息，您的终端将冻结。 （你没有在里面输入 control-S ，是吗？试试 control-Q 来重启它。）你需要如果添加了 space，当然要做提到的存档（删除后也需要一个）。
尝试使用：
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字节写入了一些控制信息，但此后文件全部为空字节。我不太确定 'verifying physical disk space' 是什么意思，因为 onspaces 的亚秒级时间意味着它实际上并没有写入 space.
分辨率
如果您关注下面评论中的讨论，您会发现阻塞的原因是系统处于 CKPT REQ 状态（需要检查点）。例如，这可以从 onstat 输出中看出。要解决这个问题，要么需要添加新日志，要么需要备份逻辑日志。
注意：通过将备份设备设置为/dev/null，您可以让服务器运行不被阻塞，这在设置时可能没问题系统，但在生产中不是一个好主意。
查看 Backup and Restore Guide 以了解 ON-BAR 和 ON-Tape 这两种可能的备份系统。
很大程度上取决于您 运行 安装服务器的环境。如果已经有一个使用 BSA 接口的 运行ning 备份系统，使用 ON-BAR 与之集成可能是最合适的。如果您没有这样的企业备份系统，那么 ON-Tape 可能更简单。
在投入生产之前，请确保您有正确的备份策略，并且您已经对系统进行了备份和恢复。 您需要确信您的备份有效。您需要确信自己知道如何使用它们。
请确保您的磁盘没有直接硬连接到设备名称。您可以使用符号链接，或使用文件名。您需要能够重新定位数据，而硬连线设备名称会使这变得困难。