>source

결과 집합을 검색하기 위해 SQL Server 데이터베이스에 연결하는 레거시 SOAP ASP.NET 웹 서비스가 있습니다. 다음은 연결 문자열입니다.

connectionString="server=ServerName;database=UserDBName;user id=UserNameRef;Password=myPassword;

명령 제한 시간을 5 분으로 설정했습니다. 우리가 보는 것은 연결 풀링을 사용하는 SQL Server 2012 데이터베이스에 대해 자주 시간 초과 문제가 발생한다는 것입니다. 서버에서 진행되는 주요 활동이나 발생하는 차단 문제가 없습니다.

PFB 스냅 샷 sp_whoisactive 트레이싱. 보시면 세션 52는 5 분 후에 시간이 초과됩니다. 이 세션에서는 어떤 명령도 실행하지 않습니다. 왜 갑자기 시간이 초과되는지 모르겠습니다.

이러한 시간 초과 오류를 수정하는 방법은 무엇입니까?


+---------+------------+-----------+----------+---------------------------+-------------+---------------------+-------------+------------+------------+-----------------+
| status  | session_id | wait_info | sql_text |        sql_command        | login_name  | blocking_session_id |  host_name  | start_time | login_time | collection_time |
+---------+------------+-----------+----------+---------------------------+-------------+---------------------+-------------+------------+------------+-----------------+
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:00 AM | 2:39:00 AM | 2:39:00 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:06 AM | 2:39:00 AM | 2:39:16 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:39:31 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:39:46 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:40:01 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:40:16 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:40:31 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:40:46 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:41:01 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:41:16 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:41:31 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:41:46 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:42:01 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:42:16 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:42:31 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:42:46 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:43:01 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:43:16 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:43:30 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:43:46 AM      |
| dormant |         52 | NULL      |          | sys.sp_reset_connection;1 | UserNameRef | NULL                | HostNameRef | 2:39:21 AM | 2:39:00 AM | 2:44:01 AM      | <== Post this timeout occurs
+---------+------------+-----------+----------+---------------------------+-------------+---------------------+-------------+------------+------------+-----------------+

  • 답변 # 1

    폐기되지 않은 자원 냄새가납니다. "작업 실행 직후에 연결 및 명령을 폐기합니까?"라고 물어볼 수 있습니까? 나는 using 다음과 같이 블록 끝에서 폐기를 보장하는 블록 :

    string sqlConnectionString = "...(put the connection string here)...";
    string commandText = "...(put the SQL command here)...";
    using (var connection = new SqlConnection(sqlConnectionString))
    {
        using (var command = new SqlCommand(commandText, connection))
        {
            return command.ExecuteNonQuery();
        }
    }
    
    

    풀링의 이점을 얻으려면 연결 문자열 값이 매우 중요 함을 나타내는 연결 풀링 알고리즘과 관련된 다른 문제가있을 수 있습니다.

    Only connections with the same configuration can be pooled. ADO.NET keeps several pools at the same time, one for each configuration. Connections are separated into pools by connection string, and by Windows identity when integrated security is used. Connections are also pooled based on whether they are enlisted in a transaction.

    이미 읽었을 수도 있지만 이것은 문서에 대한 링크입니다. SQL Server 연결 풀링 (ADO.NET)

    어떻게되는지 알려주세요!

  • 답변 # 2

    (요청에 따라 첫 번째 답변의 끝으로 이동)

  • 답변 # 3

    질문의 추적은 시간 초과 문제와 관련이 없습니다. 혼란을 드려 죄송합니다.이 ASP.NET 웹 서비스가 다른 장기 실행 SQL 에이전트 작업이 완료 될 때까지 기다리는 차단 문제로 인해 시간 초과 문제가 발생했습니다.

    As command time out was set as 5 minutes, the SQL agent job was writing to the background table and was blocking this ASP.NET webservice call. After being blocked for 5 minutes, the ASP.NET webservice times out, due to command time out of 5 minutes.

    적용된 수정 사항 :
    장기 실행 병목 백그라운드 작업의 실행 계획을 분석 한 후 기존 비 클러스터형 인덱스를 두 개의 백그라운드 테이블에서 클러스터형 인덱스로 변경하여이 시간 초과 문제를 해결하여 데이터 검색 속도를 높이고 차단 발생을 줄였습니다. 이제 시간 초과 문제가 해결되었습니다.

관련 자료

  • 이전 Javascript 수익률이 올바르게 작동하지 않습니다
  • 다음 python - 최대 인덱스에 도달했을 때 처음부터 목록을 반복하는 방법