Post stops due to ORA-12560 on target as shown:
Error 2009-05-07 12:15:55.795340 7967 81 Poster: 12032 - OCIServerAttach failed with ORA-12560. (posting from server_name, queue QUEUE_NAME, to SERVER_NAME1) [module osp]
Notice 2009-05-07 12:15:55.796057 7967 81 Poster: (posting from server_name, queue QUEUE_NAME , to SERVER_NAME1) [module osp]
Error 2009-05-07 12:15:55.796141 7967 81 Poster: Unexpected Oracle error: in ../src/opst_mt/opo_access7.c:304 (posting from server_name, queue QUEUE_NAME, to SERVER_NAME1) [module osp]
Info 2009-05-07 12:15:55.996006 7838 1 Poster exited with code=1, pid = 7967 (posting from server_name, queue QUEUE_NAME, to SERVER_NAME1)
The files opened by the Post as given by the following Unix command is very high:
/proddir/bin/ lsof -p <PID of Post> | wc -l
7945 (This number is just an example)
Too many rollbacks in the queue has caused Post to use a very large number of files.
A quick workaround can be tried by examining the stopped Post queue for any evidence of rollback activity in its transactions mix. This can be done by Shareplex command qview p which will not only identify the rollbacks but also remove them if found. This will not cause any out of sync. The following is the correct way to do this:
1.Make sure that Post is stopped due to error
2.Issue the following from target:
3.At OS prompt issue the following:
$ qview p (where $ denotes the OS prompt)
4.If it returns the output similar to following, then the rollbacks have been removed:
Read release full rollback subqueue nnn, seq nnnnn
The number of files opened by Post can be checked once again to see if they reduced. If they did, then Post will be able to run fine once manually restarted.
If it does not resolve the problem, then further investigation from Support may be required.
The solution only works in a specific situation involving too many files opened by Post due to rollback activity.