GBRSPECs

[samarchon]

Hello All,

I have a strange problem in our E1 8.9 (TR 8.93_K1) install. Once in a while the application server GBRSPECS (xdb and ddb) gets down to really small size (0K and 2K) and the jobs end in error. There is no set day and time or any particular job that causes this error. I am not sure what causes these spec files to become so small may be it is getting deleted and recreated. But why? Did anybody ever experience this? I have reindexed the following tables, still the issue is not fixed:

F98306 -- POTEXT
F98710 -- DDTABL
F98720 -- BOBSPEC
F98740 -- GBRLINK
F98741 -- GBRSPEC
F98743 -- DSTMPL
F98745 -- SMRTTMPL
F98750 -- FDATEXT
F98751 -- FDASPEC
F98760 -- RDATEXT
F98761 -- RDASPEC

I am not able to recreate this error when ever I want. Any help is appreciated.

Thanks,

--Sam
E189, TR 8.93K1, Oracle 9i, Windows 2003 App Servers, Citrix and HTML clients.

 

[qaqqini]

This has nothing to do with table index. In the spec encapsulation logic, for some reason if the files cannot be accessed while you run a UBE, it will try to create the file(just like auto install) as if the file is not there. That is why you will end up with a 0k GBRSPEC shell and jobs will start erroring out.
Now the question is why can't you access the files? Use filemon to see what is locking it.
Its most likely a local virus checked on the server doing this or a remote virus checker(most likely) that is creating file locks that JDE cannot unlock. Trust me on this one, I have seen this before and after trying to figure out what was causing this and digging through tons of debug information, we nailed it to a virus checker that was not even on the machine but on the domain level that was causing the file locks. Once we stopped that, we never faced this problem.

Hope this helps.

 

[samarchon]

Thanks so much. It was our back ups causing the problem. This problem has been resolved now.