채우기 (DataTable) 테스트에 성공했으며 응답이 없습니다.

Question

SqlDataAdapter.Fill (DataTable)을 사용하여 테이블에서 간단한 SELECT를 수행하는 프로세스가 포함 된 콘솔 일괄 처리 응용 프로그램이 있습니다.

private DataTable getMyTable(string conStr) 
    { 
     DataTable tb = new DataTable(); 
     StringBuilder bSql = new StringBuilder(); 
     bSql.AppendLine("SELECT * FROM MyDB.dbo.MyTable"); 
     bSql.AppendLine("WHERE LEN(IdString) > 0");     
     try 
     { 
      string connStr = ConfigurationManager.ConnectionStrings[conStr].ConnectionString; 
      using (SqlConnection conn = new SqlConnection(connStr)) 
      { 
       conn.Open(); 
       using (SqlDataAdapter adpt = new SqlDataAdapter(bSql.ToString(), conn)) 
       { 
        adpt.Fill(tb); 
       } 

      } 
      return tb; 
     }   
     catch (SqlException sx) 
     { 
      throw sx; 
     } 
     catch (Exception ex) 
     { 
      throw ex; 
     } 
    } 

이 방법은 동 기적으로 실행되고, 테스트의 많은 개월 동안 여러 테스트 환경에서 성공적으로 실행 된 - 모두 명령 줄에서 시작 또는 AutoSys 작업의 제어하에 시작했을 때.

그러나 프로덕션 환경으로 이동하면 프로세스가 멈추었습니다. Fill 메서드를 사용하면 거의 알 수 있습니다. 더욱이 시간이 초과되는 대신 새로운 요청 스레드가 생성되기 시작했으며 몇 시간 만 지나면 응용 프로그램 서버에서 5GB 이상의 메모리가 소모되었습니다. 이것은 다른 활성 응용 프로그램에 영향을 미치므로 매우 인기가 없었습니다. 예외가 발생하지 않았습니다.

연결 문자열은 마치 평범한 바닐라처럼 보입니다.

"data source=SERVER\INSTANCE;initial catalog=MyDB;integrated security=True;" 

사과는 내가 (이 아래 AutoSys 작업이 실행 된)는 SQL DBA 아래보고 있지만, 우리는 SQL 서버에 넣어 추적을했을 때, 그것은 응용 프로그램 ID를 보였다 무엇에 대한 잘못된 용어를 사용하는 경우 받아 들여지고 유효한 로그인으로. 그런 다음 서버는 SELECT 쿼리를 처리하는 것으로 보입니다. 그러나 결코 응답을 반환하지 않았습니다. 대신, 그것은 "명령 대기 중"상태가되었습니다. 요청 스레드가 몇 분 동안 열린 상태로 유지 된 다음 사라졌습니다.

DBA에 따르면 교착 상태의 징후는 보이지 않지만 차단 여부를 실시간으로 모니터링해야합니다.

프로덕션 환경에서만 발생합니다. 테스트 환경에서 SQL Server는 항상 1 초 이내에 응답했습니다.

AutoSys Application ID는 새로운 것이 아닙니다. 다른 SQL Server와 수년간 사용되어 왔으며 아무런 문제가 없었습니다. DBA는 해당 ID로 로그인 한 프로덕션 SQL 서버에서 SELECT 쿼리를 수동으로 실행하여 정상적으로 응답했습니다.

프로덕션 환경이 아닌 환경에서 문제를 재현 할 수 없으며 서버 관리자가 대기 상태가 아닌 프로덕션 환경에서 프로세스를 종료하기를 주저합니다. 우리의 보안 요구 사항은 서버 로그 및 프로세스를 볼 수있는 나의 액세스를 제한하며, 보통 나를 위해 다른 전문가를 고용해야합니다.

조만간이 문제를 해결해야합니다. 현재보고있는 데이터의 양은 단지 몇 줄에 불과하지만 향후 몇 개월 동안 증가 할 것입니다. 무슨 일이 일어나고 있는지, 응용 프로그램 서버와 SQL 서버 사이의 통신 및/또는 보안이 관련되어 있다는 것이 가장 좋습니다.

추가 아이디어 나 조사 할 항목을 환영합니다. 모두에게 감사드립니다.

Answer 1

일부 이상한 사용 권한/ADO가 원인 일 수 있지만그것을 또는 적어도를 하드 중 - 쿼리를 DBA가 수동으로 실행하고 응용 프로그램에서 실행되는 동일한 지 확인

1. : @user1895086에서 언급 한 바와 같이 NET 문제는, 나는 그럼에도 불구하고 몇 가지를 한 번 더 다시 확인하는 것이 좋습니다 것 실행하기 바로 전에 기록하십시오. 미안보다 안전 해하는 것이 낫습니다.
2. 몇 줄만 선택하십시오.이를 피할 수 있으면 전체 표를 선택하지 않는 것이 좋습니다. 우리의 경우 SELECT TOP 1 (또는 100) 질의는 이러한 문제를 나타내지 않을 수 있습니다. 아마 당신이 생각하는 것보다 훨씬 더 많은 데이터가 있고 ADO.Net은 모든 행을로드하려고합니다. 아니면 그렇지 않을 수도 있습니다.
3. SqlDataAdapter가 문제를 일으키지 않도록하려면 SqlDataReader을 시도하십시오. 예, 동일한 DataAdapter internally을 사용하지만 최소한 추가 작업을 용의자 목록에서 제외합니다.
4. 5GB의 메모리 - analyzing memory dumps으로 덤프에 손을 넣으려고 시도하는 것은 쉬운 일이 아니지만 그 엄청난 양의 메모리를 먹는 것을 이해하는 것은 그리 어렵지 않을 것입니다. 왜냐하면 나는 ADO.NET이 아무 이유없이 많은 추가 객체를 생성 할 것이라는 것을 어떻게 든 의심하기 때문입니다.

Answer 2

이것은 사용 권한과 관련이있을 수 있습니다. SQL Server는 때로는 적절한 오류 메시지를주는 대신 이상한 일을합니다.

내 제안, 그리고 어쨌든 성능을 향상시킬 수있는 선택을 실행하는 서버 쪽 저장 프로 시저를 작성하고 저장 프로 시저를 호출하는 것입니다. 이렇게하면 DBA는 테이블에 직접 액세스하지 않고도 스토어드 프로 시저에 대한 적절한 액세스를 보장 할 수 있습니다. 이유는 무엇인가가 차단되어 있고 약간의 성능 향상이 있어야합니다.