MS SQL Server 2008 server is experiencing blocking

Question

All,
The DBA & I are at a loss as to what could be causing an intermittent alert to be produced against the MS SQL Server 2008 server. The following email is what I've been provided:
SQL Services Alert: COMPANY.com - COMPSQL01 is experiencing blocking
spid BSPID DatabaseName    Login                          LastBatch        Runtime (Alert@:1) Command                                                                                            
394  0     ORAEPM_HP_HPBUD 102.16.4.126\ORAEPM_HP_HPBUD 2015-04-06 10:52                  5 (@P1 int)SELECT * FROM HSP_ACTIVITY_LEASE WHERE ACTIVITY_ID = @P1                                  
404  0     ORAEPM_HP_VISIO 102.16.4.126\ORAEPM_HP_VISION  2015-04-06 10:50                  7 (@P1 int)SELECT * FROM HSP_ACTIVITY_LEASE WHERE ACTIVITY_ID = @P1                                  
403  404   ORAEPM_HP_VISIO 102.16.4.126\ORAEPM_HP_VISION  2015-04-06 10:49                  8 (@P1 int)UPDATE HSP_ACTIVE_SERVERS SET LAST_ACTIVE_TIME = GETDATE() WHERE SERVER_ID = @P1          
395  394   ORAEPM_HP_HPBUD 102.16.4.126\ORAEPM_HP_HPBUD 2015-04-06 10:49                  8 (@P1 int)UPDATE HSP_ACTIVE_SERVERS SET LAST_ACTIVE_TIME = GETDATE() WHERE SERVER_ID = @P1         
From what I've been told, it appears that SPID 394 is the offending one but it appears to be clashing with SPID 404 and causing the blocking to occur. Both appear to be automatic processes executed by Planning to monitor\track the status of the various Planning applications in operation.
As background info, the following applies:
- All servers are MS Windows 2008 R2 Enterprise SP1 (64-bit);
- Hyperion Planning is v11.1.2.3.502;
- The RDBMS platform is a MS SQL Server 2008 (64-bit) instance;
- ORAEPM_HP_HPBUD is the RDBMS database accessed by a custom-developed Planning application while ORAEPM_HP_VISION is the RDBMS database for Oracle's Vision Planning application;
Has anyone ever encountered - and resolved - such an issue? If yes, how?
Many thanks in advance,
JBM

Answer 1

Can you pin point a particular TopLink query tied to the " FETCH_APICURSOR* " call in the app and post how it is being created?
My guess is that the application is specifying the TopLink query object to return a cursor or stream and not closing it in all cases, or keeping them open for a long period - did you say they were leaking, or is it just that a large number are open at a time leading to performance problems?
This streams+cursors are described in the TopLink docs here
http://docs.oracle.com/cd/E21764_01/web.1111/b32441/qryadv.htm#CJGJBHGJ
or the 10g docs here:
http://sqltech.cl/doc/oas10gR3/web.1013/b13593/qryadv010.htm
If this is the case, you might want to use a different strategy such as pagination instead of cursors, described here:
http://docs.oracle.com/cd/E17904_01/web.1111/b32441/optimiz.htm#CHDIBGFE
Best Regards,
Chris