2009-09-28 4 views
1

Java 서버 응용 프로그램에서 일반적으로 몇 밀리 초가 걸리는 데이터베이스 작업이 산발적으로 완료되기까지 훨씬 오래 걸리는 이상한 동작이 발생합니다. SQL 업데이트 및 select 문 모두에서 지연이 발생 했으므로 특정 쿼리와 분리되지 않습니다. 또한 모든 select 문은 NOLOCK 옵션을 사용하므로 가능한 잠금 경합을 배제했습니다.SQL Server/JDBC 연결 문제

마지막으로 지연 시간을 보았을 때 JConsole에서 다음 스택 추적을 캡처 할 수있었습니다. 문제의 업데이트는 일반적으로 5ms가 걸리지 만이 스택 추적은 최소한 10-20 초 동안 액세스 할 수있었습니다. 그 흔적은 저에게 그 진술이 실행되었음을 시사합니다. 그러나 내가 틀릴 수도 있지만 그 결과를 얻는 데 약간의 지연이 있습니까? 분명히 이것이 업데이트 진술 이었기 때문에 내가 기대할 수있는 유일한 결과는 행 수 (데이터의 큰 결과 집합이 아님) 일 것입니다.

SQL Server Management Studio에서 지연 될 때마다 "전송 수준 오류"가 발생했습니다.

내가 가진 한 가지 제안은 이러한 문제가 SQL Server 리소스가 고갈 됨으로 인한 것입니다. 아무도 비슷한 것을 보았습니까? 누구든지이 문제에 관해 밝힐 수 있습니까? 사전에

감사합니다.

스택 추적 : ". ... 데이터베이스 작업이 은 일반적으로 몇 밀리 초 산발적으로 더 이상 (30 대 - 170s)이 을 복용 걸릴 것으로 이에 완료하기 위해"

Name: MessageRouterImplThread-2 
State: RUNNABLE 
Total blocked: 0 Total waited: 224 

Stack trace: 
java.net.SocketInputStream.socketRead0(Native Method) 
java.net.SocketInputStream.read(SocketInputStream.java:129) 
com.microsoft.util.UtilSocketDataProvider.getArrayOfBytes(Unknown Source) 
com.microsoft.util.UtilBufferedDataProvider.cacheNextBlock(Unknown Source) 
com.microsoft.util.UtilBufferedDataProvider.getArrayOfBytes(Unknown Source) 
com.microsoft.jdbc.sqlserver.SQLServerDepacketizingDataProvider.signalStartOfPacket(Unknown Source) 
com.microsoft.util.UtilDepacketizingDataProvider.getByte(Unknown Source) 
com.microsoft.util.UtilByteOrderedDataReader.readInt8(Unknown Source) 
com.microsoft.jdbc.sqlserver.tds.TDSRequest.getTokenType(Unknown Source) 
com.microsoft.jdbc.sqlserver.tds.TDSRequest.processReply(Unknown Source) 
com.microsoft.jdbc.sqlserver.SQLServerImplStatement.getNextResultType(Unknown Source) 
com.microsoft.jdbc.base.BaseStatement.commonTransitionToState(Unknown Source) 
com.microsoft.jdbc.base.BaseStatement.postImplExecute(Unknown Source) 
com.microsoft.jdbc.base.BasePreparedStatement.postImplExecute(Unknown Source) 
com.microsoft.jdbc.base.BaseStatement.commonExecute(Unknown Source) 
com.microsoft.jdbc.base.BaseStatement.executeUpdateInternal(Unknown Source) 
com.microsoft.jdbc.base.BasePreparedStatement.executeUpdate(Unknown Source) 
    - locked [email protected] 
org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:101) 
org.springframework.jdbc.core.JdbcTemplate$2.doInPreparedStatement(JdbcTemplate.java:798) 
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:591) 
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:792) 
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:850) 
org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:858) 
org.springframework.jdbc.core.simple.SimpleJdbcTemplate.update(SimpleJdbcTemplate.java:237) 

답변

1

당신이 기한 통계 (및/또는 재건을 필요로 인덱스)의 출력에, 잘못 캐시 된 쿼리 계획 같은 소리를 묘사하거나 잘못된 매개 변수 스니핑. 서버가 기본 연결 시간 초과보다 오래 걸리므로 시간 초과가 발생할 수 있습니다.

DBA와 먼저 통계를 업데이트하고 쿼리가 작동하지 않으면 쿼리에 포함 된 테이블의 인덱스가 다시 작성됩니다.

실행하여 데이터베이스에 (당신의 관리자/DBA에게 알리지 않고 생산에 runninhg하고, 자신의 위험 등 실행되지 대한 일반적인주의로)이 : 또는

EXEC sp_updatestats 

EXEC sp_refreshview 

EXEC sp_msForEachTable 'EXEC sp_recompile ''?''' 

, 당신은 하루의 시간을 언급 요인이되고있다. 그 당시 백업 또는 예약 된 작업이 발생 했습니까?

업데이트 : 프로파일 러 추적을 실행할 수 있습니다 (MS SQL Server 2008 - How Can I Log and Find the Most Expensive Queries?). 그러나 DB에 제한하지 마십시오. 그러한 추적은 SSMS에서 해당 게시물 당 시작되는 한 비교적 영향이 적습니다 (3 ~ 5 % ish).

+0

Mitch, 현재 테이블 크기가 너무 작아서 잘못된 쿼리 (테이블 스캔)조차도 무시할 수 있습니다. 따라서 백업 작업 (또는 다른 작업)이 서버 리소스를 고갈시킬 수 있다고 생각하는 경향이 있습니다. 불행하게도이 서버는 공유 된 프로덕션 서버이므로 모든 범인을 추적하기가 어려울 수 있습니다. – Adamski

+0

@Adamski : 아마도 추적을 실행할 수 있습니다. 내 대답을 세부 정보로 업데이트하겠다. –

1

"전송 수준 오류"는 connectivity problems을 나타내는 것 같습니다. 별도의 컴퓨터에 데이터베이스가 있습니까?

+2

"데이터베이스가 별도의 컴퓨터에 있습니까?" - 그들은 보통! :) –

+0

네, 별개의 컴퓨터에 있습니다. 과거에는 Management Studio의 "전송 수준 오류"가 사라지지 않았습니다 (예 : IDE에서 쿼리를 다시 실행 한 경우). 네트워크 문제를 나타냅니다. 그러나이 오류가 사라질 때 같은 쿼리를 다시 실행하면이 문제가 리소스 문제에 더 많은 것인지 궁금해집니다. – Adamski