有人试过在aix 5.2 ML06+oracle9i+jfs2文件系统下打开jfs2的concurrent i/o功能吗？

wuchengeng

如题，再补充一下情景，系统存储是fastT600,该系统使用两块73g的硬盘作raid1 ，系统刚开始使用的文件系统格式是jfs，应用开发的所有数据都建立在oracle9i数据库里的一个大的表空间里，且只有一个数据文件，用户都通过一个用户名来访问后台数据库，使用系统的回滚段和索引的表空间。系统运行后使用正常，磁盘i/o及cpu使用率也不高，后因为上tsm备份时，系统i/o达到100%，同时用户端无常正常使用。后在测试环境建立jfs2文件系统格式测试，备份的时间及磁盘i/o都大为减少，在客户端进行测试，数据库均可正常使用，因此，将生产环境的数据格式改为jfs2 格式，修改的方法是通过backup文件系统,重新新的jfs2文件系统，重建应用用户及表空间，imp进业务数据,修改后系统运行正常，几天后系统磁盘i/o达到100%，某些用户端访问非常慢，经查是发现用户访问的其中一个表被锁，后重启oracle服务正常，但这种情况差不多24小时左右就发生一次，并且都不是在业务高峰期。
      希望各位同仁能帮我分析一下，这个问题一个折腾好久了，请教了许多专家，还有IBM，问题都没有解决。
首先注明，虽然磁盘i/o的问题跟磁盘的数量有关，但我想这不是关键的问题，因为在未运行tsm备份之前，系统运行还是正常的。
    如果打开jfs2 的concurrent i/o功能，对性能的提升会有一定的效果吗？

yanbing

个人感觉:cio打开性能有一定改善，但是不能解决你碰到的这个具体问题。

上TSM应该不会对你日间的运作有任何影响啊！通常定义备份窗口的时候都会放在夜间啊！？

zql0624

我个人认为，文件系统的类型不会对系统IO的性能产生如此大的影响，如果你说的达到100%IO的情况是在备份时的话，那就是你备份Oracle的脚本开了过多的通道所致。concurront是在不同节点并行访问的意思，对于你的情况，不会对性能改善有用处。

yanbing

楼上的兄弟，这里jfs2文件系统的concurrent i/o并不是你说的那个意思。

其次，TSM备份开通道的个数决定于磁带驱动器的数量。（当然前提是备到磁带上）。

wuchengeng

　　问题是，应用是２４小时在线的。而且备份多个数据库总的时间加起来，以现在备份速度，一个晚上都很难完成。所以白天晚上都会有影响。
　　关于concurrent i/o 参与以下文章：

    http://www-1.ibm.com/support/doc ... 4a748256d2d002198ba
      http://www-1.ibm.com/support/doc ... 35e48256e8400058676
      关于备份通道的问题，我只开了一个通道，因为多开通道对性能提升好象没有太大的影响。我在测试机上模拟生产环境测试备份，备份也是没有问题的。
    现在的问题的是，应用开发的那家公司已经倒掉了，而且当初上线时也没有问题。现在是因为重新导入了库，改了一下文件系统格式，之后一段时间就出现了这样的问题。
    关于文件系统格式的问题，我请教过一些专家，应该是没有问题的。那现在问题出在哪儿呢？！
    再次感谢各位同仁关注！！！

yanbing

问题是：你到底想解决什么问题！？

按我的理解，你是想知道系统i/o为什么会变慢！！！

按你的描述，在你未改用jfs2之前系统i/o就已经达到了100%，是在你实施了TSM之后！！！

所以，系统I/O为什么会达到100%和你想知道的jfs2的cio没什么关系，也没人说跟这个jfs2格式有关系，你的那些专家也是这个意见！！！

rman的channel开几个是取决于你的目标设备的情况的，如果是磁带机或库，按照驱动器的数量来开；如果是磁盘，可以不限制；

从头到尾看你对TSM的描述都不清楚且不涉及重点，所以搞清楚你的TSM是什么机制是你的问题的关键！！！

最后，你在开帖提到的数据库环境不是如你第2帖所说是多数据库环境，24小时应用也不是24小时都是高峰的！！！

如果你想搞清楚的问题不是我所理解的这样，那估计不是你就是我语文要重修了！呵呵！！！

wuchengeng

sorry.是我表述问题不清。
首先，我提出的第一个问题版主已给解答了，也就是说打开concurrent i/o对性能会有一定的改善。ok.
  如版主所言，我所想知道的关键问题还是：磁盘i/o的高峰值导致应用无法登录的问题。
为了简化问题，先抛开TSM不谈。现在的情况是：
  在修改系统文件格式之后的一段时间后，系统会每隔24小时左右磁盘i/o会达到100%，并且跟是否是业务高峰期没有太大的关系，也就是，既使不是业务高峰期，它也会达到100%，导致用户登录非常之慢。
  我当时怀疑问题的原因是：
  1.在对数据exp和imp的过程中会不会出现问题？
  2.是不是因为修改了jfs2格式的问题？如果打开concurrent i/o会不会解决这个问题。
如果二者都不是的话，问题可能会出在哪里呢？

wuchengeng

感谢yanbing兄！

yanbing

建议在磁盘i/o出现100%时运行filemon观察是什么文件产生了大流量，占用了带宽。

如果是oracle的数据文件，也就是你提到的表空间被锁，可向oracle支持人员提出咨询，谢谢！

wuchengeng

昨晚将测试机切换成生产机，晚上运行的是急诊的业务，我在线做了一下tsm的备份，
18分钟备完了约20G多的数据库。客户端也很正常。早上门诊一上线，就出现了挂号的表被锁的情况，同样导致整个系统都不能用，最后只有重启数据库。以前有做过filemon，确实是应用的数据文件。但这样的问题是出现在修改文件系统格式和exp和imp之后。所以我考虑打开jfs2 的cio，并将oracle打补丁试一下。因为oracle现在也是我在做维护，所以。。。事情并未结束。。
感谢版主关注。