report 开发过程中信号11问题的处理

   经常在report 开发中碰到信号11的问题，最近又碰到了几次。现在把信号11问题稍微总结一下。


1.信号11问题是怎样的？

如果并发请求报错，并且在其log 中看到如下的错误，就说明你正遭遇了信号11 问题。
因为报出来的信号11是很笼统的错误，它并不像其他具体错误那样清楚，因此，信号11问题一般不是太好解决。

 Current NLS_LANG and NLS_NUMERIC_CHARACTERS Environment Variables are :                     
SIMPLIFIED CHINESE_CHINA.UTF8                                                                
                                                                                             
'.,'                                                                                         
                                                                                             
stat_low = B                                                                                 
stat_high = 0                                                                                
emsg:因出现信号 11 而终止                                                                    
                                                                                             
+---------------------------------------------------------------------------+                
FND_FILE 中日志消息开始                                                                      
+---------------------------------------------------------------------------+                
+---------------------------------------------------------------------------+                
FND_FILE 中日志消息结束                                                                      
+---------------------------------------------------------------------------+                
程序 因出现信号 11 而终止                                                                    
在为并发请求 341376 运行 Oracle 报表管理系统时，并发管理器遇到了一个错误。                   
                                                                                             
有关详情，请复查您的并发请求日志和（或）报表输出文件。


2. 什么是信号11 ？

信号是操作系统中进程通信的一种方法。平时我们用的最多的信号可能是kill -9 了， -9 就代表了一种信号，它是一种比较强的信号，接收到该信号的进程会被比较彻底的杀掉，相关资源都会释放，该信号不能被忽略。

信号11 实际上类似于这里的9，不过有些不一样。  下面是9，10，11 号信号的含义.
SIGKILL
                  Kill (cannot be caught or ignored). (9)
SIGBUS
                          Specification exception. (10*)
 SIGSEGV
                          Segmentation violation. (11*)


实际上还有很多的信号，比如：
1) HUP 14) ALRM 27) MSG 40) bad trap 53) bad trap
2) INT 15) TERM 28) WINCH 41) bad trap 54) bad trap
3) QUIT 16) URG 29) PWR 42) bad trap 55) bad trap
4) ILL 17) STOP 30) USR1 43) bad trap 56) bad trap
5) TRAP 18) TSTP 31) USR2 44) bad trap 57) bad trap
6) ABRT 19) CONT 32) PROF 45) bad trap 58) bad trap
7) EMT 20) CHLD 33) DANGER 46) bad trap 59) CPUFAIL
8) FPE 21) TTIN 34) VTALRM 47) bad trap 60) GRANT
9) KILL 22) TTOU 35) MIGRATE 48) bad trap 61) RETRACT
10) BUS 23) IO 36) PRE 49) bad trap 62) SOUND
11) SEGV 24) XCPU 37) bad trap 50) bad trap 63) SAK
12) SYS 25) XFSZ 38) bad trap 51) bad trap
13) PIPE 26) bad trap 39) bad trap 52) bad trap

回归下本题，我们基本可以推断出信号11是怎么发生的:
我们定义了多个并发管理器，每次我们的请求都被分配给某个管理器进程来执行。当我们的某个请求在执行时，遭遇了莫名的错误，导致该管理器进程都被 kill -11 了，因此程序报出了信号11的错误。

3. 信号11问题的解决：
信号11问题我目前是采用这样的方法来解决：
首先report 的执行顺序是 before report trigger， 然后query ，对于生成的xml 文件然后 再根据模板文件来生成相应的pdf 或者excel等。

那么 xml 文件无疑可以作为一个重要的指标，通过它，我们来判断信号11问题出现在哪个环节上。
a.如果before report 报错，那么xml 是空的
b。如果query 中间报错，那么xml 应该只有 标签的前半部分，没有后半部分
c.如果query 没有报错，而是模板文件生成具体显示文件的时候报错，那么应该xml 文件是OK的，完整的， EXCEL,PDF 等显示文件是不完整的。


举个例子吧。
最近遇到一个信号11的错误，报表是从一个环境迁移到另一个环境，在旧环境运行不会报错，但是在新环境一运行会报信号11错。
因为前面可以正常运行，说明程序是正常的，那么在新环境的报错，我们推断是因为数据方面的原因，触发了程序中的某处逻辑，数据无法通过验证而报错。但是，什么样的数据呢？
我们发现在将程序的某行代码修改一下后，程序就可以正常运行。
对比了报错请求的out 和非报错请求的out，发现正常请求的out 是完整的，xml 标签是匹配的( 当然应该是匹配的，否则还怎么叫xml！ )。但是 报错请求的out 就是不完整的。
程序中有三个query，当时错误的out 为
<QUERY1> 。。。。</QUERY1>
<QUERY2>。。。。 </QUERY2>
<QUERY3>

输出停在query3处不动了。这样看来是在执行query3的时候出了错。
将query3 的变量用值来替换，在pl/sql dev 中执行的时候，果然报错,报错 时间的格式不匹配。
这个错误，其实就是并发管理器执行时遭遇的错了，当时是在执行query，又不像可以在pl/sql 块中那样可以catch exception，所以 进程执行报错信号11 然后退出了。
这个时间格式的错误也是有点意思，因为满足需要的数据都是满足时间格式的，不可能报错。
呵呵，但是，实际上sql 在执行的时候，当然也会访问到不满足条件的数据啊，将数据抓过来后再用条件去判断，最终得出的结果才是符合要求的数据。
解决其实很简单，结合业务要求，修改某些条件之后，语句就OK了。