一次由重复索引导致的问题
上一篇 /
下一篇 2012-10-23 13:20:09
/ 个人分类:数据库
6wAzU:]n0 最近一个朋友公司的OA系统总是出故障,具体表现在某个特定用户在登录后,无法查看自己的任务。等过了一会后,就报503错误。让我帮忙看看。51Testing软件测试网K+m%GP+\!D+Y%}
9M$Jczb ^ w.A
\b0 首先服务器是JBOSS,数据库是SQLServer 2005 64位企业版。
1V[F/U+o/c9v1L9xC051Testing软件测试网+O3N[YA
p 根据以上提供的信息,首先找到JBOSS日志,当某个用户登录后点查看待办任务,JBOSS日志就会显示:
'_'Im2l
yC4G0ERROR
[org.jboss.ejb.plugins.LogInterceptor]
TransactionRolledbackLocalException in method: public abstract xxxx
xxx(), causedBy: *k(f1K#d,i&E9[0org.jboss.util.NestedSQLException: No
ManagedConnections available within configured blocking timeout ( 30000
[ms] ); - nested throwable: (javax.resource.ResourceException: No
ManagedConnections available within configured blocking timeout ( 30000
[ms] )) I)b#o"{g0 at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:106) 5m"t6Xugx-u;K0 at com.adobe.pof.ConnectionWrapper.getConnection(ConnectionWrapper.java:25) ,c%{8Y&lQ t:R.eC8p0 at com.adobe.pof.ConnectionWrapper.getMetaData(ConnectionWrapper.java:101)51Testing软件测试网Qg%`'h| j&~
D/\c%D8U at com.adobe.pof.POFBean.getAdapter(POFBean.java:120) a._+i,\s7h'f8}7e0 at com.adobe.pof.omapi.POFObjectManagerRemoteBean.getObjectManagerImpl(POFObjectManagerRemoteBean.java:108) [1O$C"fV9\,rN4nP0 at com.adobe.pof.omapi.POFObjectManagerRemoteBean.getEnvironment(POFObjectManagerRemoteBean.java:489)51Testing软件测试网;nSr#K8AnD'gi%c at sun.reflect.GeneratedMethodAccessor144.invoke(Unknown Source)51Testing软件测试网f%znBHs.Z]V,R8@!Y at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)51Testing软件测试网}l,s+D*CJ)w|-X3B1U,D atjava.lang.reflect.Method.invoke(Method.java:592)51Testing软件测试网,c3I9D#BO/FdP at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:683) x;`?@.r+Sa0 |
51Testing软件测试网4?j^ReB1IF 根据报错日志,很明显问题是出在连接超时。当超时超过30秒后,数据库Session断开。然后服务器报503错误。而只有这个特定用户存在这个问题,测试了几个其它用户均不存在这个问题,因此可以知道错误应该没出在应用程序那一端。51Testing软件测试网(t|T9X!} ]
i[ ie*E*g0pZJy0 由于只有这个特定用户存在这个问题,因此也基本排除数据库无法连接,T-SQL代码存在一些问题等原因。51Testing软件测试网?qy-o:QD4k\
+a'f4CS%k E0 因此,超时我首先想到是阻塞,阻塞我首先想到可能是锁引起的。我先运行了这个代码来看哪个session下锁跑得最多。51Testing软件测试网H.MDD SNA
DF$`2o+T/as0SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED51Testing软件测试网P5D9A.rQ\&tm7e SELECT COUNT(*),request_session_id FROM51Testing软件测试网\:V(L7[(?1dU'y!^Z (51Testing软件测试网,o5y"KTt Z SELECT DB_NAME(resource_database_id) AS DatabaseName 8R I)n p!V,[`;D3W0, request_session_id kt$N3ZsL8Ln/E0, resource_type51Testing软件测试网 R9?-PK2H G"dos , CASE Eb\9S;LtQ3x0WHEN resource_type = 'OBJECT' +k5_ NB.r"\;r0THEN OBJECT_NAME(resource_associated_entity_id) 1dX"[z}#g$NF0WHEN resource_type IN ('KEY', 'PAGE', 'RID') l$d3`hWg0THEN (SELECT OBJECT_NAME(OBJECT_ID)51Testing软件测试网Cw
_%cpg"z1tW0Z FROM sys.partitions p !S6aV5Xr E(Y0WHERE p.hobt_id = l.resource_associated_entity_id) "H?%B"hIS2t0END AS resource_type_name51Testing软件测试网G'r/Xf\r;MZH ` , request_status H0p8EbsA$N'a0, request_mode !?t;O8\j%} Ru0`l0FROM sys.dm_tran_locks l51Testing软件测试网*v Q2}5c~)f aG5\8d!S 51Testing软件测试网C6]X#a)b%{3Fe51Testing软件测试网8q(bGIf ) AS a51Testing软件测试网!N]|"pi$S
g GROUP BY a.request_session_id +NP9{-{+fZo"|@_
^U9~0 |
4A V)E0fE*D.zg]0 发现session id为150的连接上跑了4000+个锁。再通过sys.dm_tran_locks 来具体的看,发现这些锁都是key级的S锁,以及对应Page和表上的IS锁。当30秒过后超时,所有这些锁都会被自动释放。51Testing软件测试网9|i$wNlv xT E{
51Testing软件测试网yOK.v4ow5G}L 我产生两个疑问:51Testing软件测试网*HKP-bo%^@](|m
!P P sJTf A!L0 1、为什么仅仅是这个用户一查看数据库就会产生这么多的锁,而其它用户不会产生这么多锁呢?
^Lqv9n[051Testing软件测试网R~e'p(vmm 2、为什么4000+个锁没有升级呢?51Testing软件测试网v8Q6i$QzE%a;H$e
51Testing软件测试网$Y yd~.i`YP 带着这个疑问,我使用Profiler对这个Session ID查看待办工作时
的操作进行了抓取。发现对应的T-SQL语句仅仅是一个普通的Select语句。为了看清返回的行数,我使用未提交读看到这个用户尚待办的工作有1900
条(用户是一个地区的经理,所有地区产生的任务无论他是否参与都要转给他一个),而其它不产生阻塞的用户待办工作不超过50条。51Testing软件测试网9qRx,NX/~
+Q q
b%`F!A1u
X.O0 4000+个锁没有升级我想是因为表上存在了意向锁。51Testing软件测试网kbo"I;f%Wr0A^
51Testing软件测试网pP\(EOf 因此我怀疑表上的多个索引之间在选择多条语句时可能产生互相阻塞。因此对相关的表上索引进行查看,发现在用于关联用户和任务的assignment表中存在两个索引的最左列完全一样,估计这里就是产生问题的根源。
:s7Q&r6b#ThC'TGW"Q051Testing软件测试网(dC6h]&K7` 因此kill掉Session 150之后,Drop了那个键少的索引。问题解决!51Testing软件测试网's+r(wu0Sd
收藏
举报
TAG: