免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 5065 | 回复: 8
打印 上一主题 下一主题

关于 RGZPFM进行时中途停掉的处理. [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2005-12-07 19:42 |只看该作者 |倒序浏览
我在对一PF做RGZPFM的时候中途停掉了,结果其他RPG程序现在无法调用这个PF

每次操作关于这个PF 的RPG 时 系统报错程序不能打开PF 另外还有两个

LF1
LF2

目前系统出现

                                                                    
pt  Subsystem/Job  User        Type  CPU %  Function        Status  
    QDBSRV04       QSYS        SYS    12.0     IDX-LF1       RUN   
    QDBSRV05       QSYS        SYS    12.3     IDX-LF2      RUN   


大家遇到这种情况怎样处理呢.

[ 本帖最后由 leason 于 2005-12-8 11:58 编辑 ]

论坛徽章:
0
2 [报告]
发表于 2005-12-07 21:29 |只看该作者
Description of the QDBSRVxx System Jobs

Document Description:

At each IPL, numerous system jobs that start with the name of QDBSRV are
activated. The following is an overview description of the functions
performed by these jobs:

QDBSRVXR - This job maintains each of the system cross-reference files in
QSYS with the exception of the field cross-reference file. These files
contain cross-reference information about data base files and SQL
information across the system. The files all begin with the name of QADB in
library QSYS. The primary file that must be maintained is QADBXREF. This
file is the file cross-reference file. It contains a record for each
physical and logical file on the system. Create, change, or delete of any
file will cause the QDBSRVXR job to become active.

QDBSRVXR2 - This job maintains the only system cross-reference file that is
not maintained by QDBSRVXR, the field cross-reference file. This file is
QADBIFLD in library QSYS. This file contains a record for every field of
every physical and logical file on the system. Create, change, or delete of
any file causes the QDBSRVXR job to become active.

QDBSRV01 - This job can be viewed as the database maintenance task
dispatcher. Typically, it will be the most active immediately following the
restore of a library that contains database files. It's function includes:
                                                                           
o Signalling to the SMAPP (System Managed Access Path Protection) LIC     
   tasks that new access paths have been restored. SMAPP will then         
   determine whether these access paths need to be protected.              
                                                                           
o Sending data queue entries to the QDBSRVXR job of new database files   
   that were restored.                                                     
                                                                           
o Sending data queue entries to the QDBSRVXR2 job of new database file   
   fields that were restored.                                             
                                                                           
o Preparing the list of access paths that are required to be rebuilt      
   because the access paths were not restored. This is the list that is   
   viewed via the EDTRBDAP command.                                       
                                                                           


QDBSRV02-03 - These two jobs perform access path maintenance on system
files. Typically, the jobs are inactive.

QDBSRV04-05 - These two jobs perform access path maintenance on user data
files. Typically, these jobs are inactive. However, in certain cases, these
jobs will be active performing access path rebuilds. The access paths that
are being maintained can be viewed via the EDTRBDAP command. Some reasons
why these jobs could be active are:
                                                                           
o Restore of database files that were not saved with access paths.        
                                                                           
o Restore of logical files that are in the same library as the physical   
   file they are based upon.                                               
                                                                           
o Cancelling of a RGZPFM command while in process.                        
                                                                           
o Invalidation of an index due to damage found upon it.                  
                                                                           


QDBSRV06-09 - On systems with additional processors, additional system jobs
are started to allow for additional concurrent access path rebuilds. These
jobs perform the same tasks as QDBSRV04-05.

论坛徽章:
0
3 [报告]
发表于 2005-12-08 12:17 |只看该作者
楼主按照pro-group 说的方法试试看

论坛徽章:
0
4 [报告]
发表于 2005-12-08 13:16 |只看该作者
最后还是要等

QDBSRV04-05

这两个JOB 运行完成后,对PF里的数据进行重新排序程序就能正常使用这个PF了.

后来为了我了保证更稳定,我对刚才的PF重新做了一次RGZPFM.

但要有点注意的是,在做RGZPFM中途停止后,最好先把PF先备份一份再重新重组数据

这样尽量避免数据的掉失了.汗啊ING............

还好这个PF的数据不是很重要,记录可以恢复.........要上第一次做RGZPFM的朋友可要注意了,这也是俺不小心的"遭遇"哦.供大家借鉴.呵呵...

论坛徽章:
0
5 [报告]
发表于 2005-12-08 13:47 |只看该作者

v5r3的新功能

以前,rgzpfm一定要做完,中途停掉,就算IPL也没用,一定要做完才可以使用,对于大OBJ,这是比较麻烦。
后来,有一些工具,可以重组,如MIMIX的小工具。
到v5r3时,发现了有可以停掉的功能,据了解,IBM使用了把没用的纪录去掉,表结构重新链接。假如不指定重建逻辑文件,甚至应用还可以照跑。
楼主显然是选了重建逻辑文件,在重新索引时当然作业跑不了啦。
假如诸位有用MIMIX、OMS此类工具,对日志有了解,看一下日志,大家对原理接受就比较简单了。

论坛徽章:
0
6 [报告]
发表于 2005-12-08 14:23 |只看该作者
楼上的“layyf “ 老兄说得对。我是选择了重建逻辑文件,所以中途停掉问题就出现,后来也只有重新rgzpfm一遍了。因为哪个PF是个记录档,里面占用了有6G大的空间,其中有3G资料上删除后没有释放的空间,所以就进行rgzpfm,这个PF还对应两个LF。最后花了我1.5小时的时候做完了,真是晕哦。。

不知道用CLP程序可以写rgzpfm表格的命令不?这个倒是没写过,

要是可以的话,以后直接可以用WRKJOBSCDE。让系统自动做了

论坛徽章:
0
7 [报告]
发表于 2005-12-09 10:04 |只看该作者
可以把RGZPFM放在CL程序里,提交个BATCH作业运行。

论坛徽章:
0
8 [报告]
发表于 2009-03-13 17:01 |只看该作者
数据库重整,1、如果对于数据量比较大的文件,可以采用备份数据库到一个对应的数据库里,然后先删除原表的逻辑文件、再对表进行clrpfm,然后再拷贝数据回来,然后重新生成逻辑文件。
2、使用RGZPFM,对于数据量比较大的文件,还是建议采用删除逻辑文件后进行重组,但还是推荐第一种方案。

论坛徽章:
0
9 [报告]
发表于 2009-06-22 09:28 |只看该作者

回复 #8 紫衫威龙 的帖子

很好啊,谢谢了
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP