操作系统生成dump失败？

这种情况首先想到的是空间的问题，建议先检查一下dump文件存放空间是否足够

可能是dump空间不够吧，sysdumpdev -e看一下大小，可以适当扩大lv一下，然后#/usr/lib/ras/dumpcheck，无报错即正常

必须是空间问题，做个DUMP又不是难事。

空间放大一些，这个东西占用空间！

要先确认空间是否足够，如果问题依然存在，请将dump生成到其他空间大的盘内。

1. 检查系统当前的DUMP设备空间：** Primary DUMP 设备默认是 /dev/hd6 。 DUMP 设备应该有足够大的空间，否则会导致 DUMP 数据收集不完整。可用“ sysdumpdev –e ”命令估算系统 DUMP 的大小：
   # sysdumpdev –e
   0453-041 Estimated dump size in bytes: 18664652
   DUMP 设备的空间要比估算值大，并要留有足够的余量，例如比估算指大 30~50% 。 AIX 5L 中的 dumpcheck 命令用于检查 DUMP 设备及 DUMP 拷贝目录是否有足够的空间。系统默认会在每天 3:00PM 运行 dumpcheck ，如果发现空间不足会记录在系统 error log 中。

   由于默认的第一 DUMP 设备 /dev/hd6 是内存交换区，系统在重启时必须把 DUMP 拷贝到文件系统或磁带。这样系统重启过程比较长，在某些情况下客户因为急于恢复应用，而选择了放弃 DUMP 拷贝，从而导致 DUMP 数据的丢失！为此，如果 rootvg 有足够空间，应建立专用的第一 DUMP 设备，而不要用内存交换区。（如果系统内存大于 4GB ，则 AIX5L 会自动建立专用的 DUMP 设备： /dev/lg_dumplv ）。

   不要用 /dev/hd6 以外的内存交换区作 Primary DUMP 设备。

Secondary DUMP 设备默认是 /dev/sysdumpnull ，也就是如果 Primary DUMP 设备写失败，则 DUMP 信息会被丢掉。因此，客户如果有足够空间可以建立专用的 Secondary DUMP 设备或使用 rootvg 的内存交换区。

2. 检查DUMP拷贝目录所在的文件系统是否有足够剩余空间（若使用非内存交换区作为DUMP设备，可跳过此步）：** DUMP 的拷贝目录默认是 /var/adm/ras 。假如 DUMP 设备是用内存交换区，则系统重启时必须把 DUMP 文件从内存交换区拷贝到此目录。如果 DUMP 设备是专用的逻辑卷（非内存交换区）则系统在重启时不会拷贝 DUMP 到此目录， DUMP 会继续保存在逻辑卷中。拷贝目录所在的文件系统要有足够的剩余空间，否则拷贝会失败。可以用“ df -k ”命令检查文件系统的剩余空间然后对比“ sysdumpdev –e ”的估算值。用 dumpcheck 命令检查也可以。如果要改变 DUMP 的拷贝目录则必须保证其所在文件系统建立在 rootvg 上。
3. forced copy flag是否设为TRUE（若使用非内存交换区作为DUMP设备，可跳过此步）： Forced copy flag 用于设置是否强制拷贝在内存交换区中的 DUMP 文件，默认是 TRUE 。下表列出使用不同 DUMP 设备与 forced copy flag 的不同设置的关系：

建议把该参数设为TRUE（默认值），以确保DUMP拷贝到文件系统失败时不会被丢弃。**

4. always allow dump是否设为TRUE： always allow dump 用于设置 Force DUMP 功能打开或关闭，默认是 FASLE 。通常 AIX 操作系统在系统崩溃时会自动做 DUMP ，但对于一些系统挂死的情形（如性能问题导致响应非常缓慢） AIX 并不认为是系统崩溃而做 DUMP 。这就需要用户手工去做 Force DUMP 。对于古老的 MCA 总线的机器这个参数设不设为 TRUE 都可以做 Force DUMP 。而对于 PCI 总线的机器这个参数必须设为 TRUE 才可以做 Force DUMP 。由于我们目前绝大部分机器都是 PCI 总线的，所以这个参数必须设为 TRUE 。 命令为“ sysdumpdev –K” ，可在线修改。
5. DUMP压缩功能是否打开： dump compression 用于设置是否对 DUMP 进行压缩，默认是 OFF 。对 DUMP 进行压缩除了可以节省空间外（ DUMP 设备可以设小一点），还可以大大的缩短系统做 DUMP 的时间。一些内存很大的系统在做 DUMP 时要花很多的时间（有超过 30 分钟的个案），客户往往因急于恢复应用而无法等待 DUMP 完成。因此，建议把 dump compression 设为 ON ，以缩短系统做 DUMP 的时间。命令为“ sysdumpdev –C ”，可在线修改。
6. 如果主机机型为7040，微码版本是否在3H041021或以上：** 如果机型为 7040 ，且微码版本低于 3H041021 ，则有 Service Authority 授权的分区做 DUMP 的时间会很长。解决办法是升级微码版本到 3H041021 或以上。

不同机型做Force DUMP的方法：**

RS6000 和 pSeries 型号众多，不同机型做 Force DUMP 的方法各有不同，所以有必要作一个总结。做 Force DUMP 的方法并不仅限于以下所列，这里只是列举较为便捷的方法。
注：PCI机型做Force Dump的前提是always allow dump要设为TRUE。**

1. MCA机型 （这些机器年代久远，真正用于生产的已经非常稀少了）：
   不管 always allow dump 设为何值，只要把钥匙拨到 Service 位置，然后按 reset 按钮即可。
2. Power5系列服务器（p510/520/550/570/575/590/595）：

a) HMC管理的服务器： 在 HMC 图形管理界面上选 Server and Partition => Server Management => 选要做 DUMP 的主机 => 选要做 DUMP 的分区 => 单击鼠标右键 => Restart Partition => 选 Dump ，然后按 OK 。

b) 无HMC管理的服务器：
方法1： 在控制面板上用上下键选择 02 菜单，把 System operating mode 从 Normal 改为 Manual ，即把“ N ”改为“ M ”。然后选择 22 菜单，按控制面板的回车键，面板显示 A 1 0 0 3 0 2 2 ，用上下键再次选择 22 菜单，再按面板回车键。
方法2： 用 admin 用户登录 ASMI ，选 System Service Aids => Partition Dump => 选 Partition Dump

3. Power4系列服务器（p615/630/650/655/670/690）：

a) 没有逻辑分区的机器： 直接按控制面板的 reset 按钮。

b) 有逻辑分区的机器： 在 HMC 图形界面上选中需要做 DUMP 的分区 => 在菜单栏选 Selected => Operating System Reset => 选 soft reset 后按 yes

4. 7017-S70/S7A/S80/S85： 在控制面板上选择 22 菜单，按控制面板回车键，面板显示 A1003022 ，再次选择 22 菜单，再按回车，面板显示 D1823080 后开始做 DUMP 。

5.9076：**

a) 用 spmon 命令： # spmon -reset node

b) 用 SP PERSPECTIVES 管理界面做 DUMP ：
用命令 /usr/lpp/ssp/bin/perspectives& 启动 Perspectives => 双击 Launch Pad 中的 "Hardware Perspectives" 图标 => 选择要做 DUMP 的节点 => 在 title bar 中选 Actions => 选 Power Off, Reset or Shutdown => 选 Reset 然后按 Apply

6. 其他PCI服务器：** 如果控制面板有 reset 按钮：直接按 reset 按钮，某些机型可能要按住 reset 按钮 5 秒左右才开始做 DUMP ，面板显示代码 0C2 。如果控制面板没有 reset 按钮：按住 power 按钮 5 秒左右，面板显示代码 0C2 表示 Force DUMP 开始。

注意：**

主机（或分区）在做DUMP时控制面板（或HMC）会显示代码0C9或0C2，这个过程可能需要几分钟到几十分钟不等。通常内存越大的机器（或分区）做DUMP的时间越长，没有设DUMP压缩的比有压缩的时间要长。请耐心等待，DUMP完成后会显示代码0C0。只有等0C0显示后才可以重启机器，否则会导致DUMP数据的丢失！**

DUMP数据的收集
仅提供 DUMP 文件、或 DUMP 磁带是不足以分析问题的。正确的方法是用“ snap-r;snap –gfkDc ”命令打包，如果 DUMP 文件已拷到磁带，则 snap 命令会提示插入磁带。打包完成后把 /tmp/ibmsupt 目录下的 snap.pax.Z 或 snap.tar.Z 文件上传到 testcase.boulder.ibm.com 的 aix/toibm/ 目录，文件名为 pmh#.b000.c672.pax.Z

如果 /tmp 文件系统没有足够空间，则可以用在运行 snap 时用 -d 参数指定其他目录。

在SAN环境下，如果客户有用Concurrent VG则不建议在生产时运行snap –a，这样有可能会使共享的SAN磁盘被锁定从而导致数据访问中断！**

从报错日志看dump的代码是-3，就是莫名其妙的失败，怀疑是宕机的时候，磁盘vscsi路径就失败了，导致dump文件根本写入不了磁盘，如果是这种情况，是否有方法可以避免？

是否是空间不够了，可以savedump /tmp指定较空闲的保存路径试试。