SSAS 서버에 여러 큐브가 있고 10GB 이상인 큐브는 거의 없습니다. .NET 앱 중 하나는 OPENQUERY를 통해 상대적으로 작은 큐브 <1GB 큐브에 액세스하고 있습니다.
큰 큐브 중 하나가 기본 시간 초과 (30 초)가 있기 때문에 .NET 애플리케이션 시간 초과를 처리 할 때 시간 초과를 늘릴 수 있지만 사용자는 쿼리가 완료 될 때까지 1 ~ 5 분을 기다려야합니다. 동일한 MDX 쿼리 (SSMS 또는 ADOMD)를 직접 실행하면 동일한 환경에서 1 초 미만의 결과를 얻었습니다.
MSOLAP 공급자에는 Allow InProcess = true가 있습니다. ADOMD를 사용하도록 앱을 변경하는 것은 너무 많은 리소스를 필요로하기 때문에 실행 가능한 옵션이 아닙니다.
나는 Resource Governor를 사용하고 앱 쿼리 및 기타 요청과 별도의 처리를 시도했습니다. 문제를 부분적으로 완화하고 이제는 모든 쿼리 시간 초과가 아닌 대부분의 문제를 완화했습니다.
SQL Server와 SSAS가 잘 지낼 수 있도록 제가 할 수있는 다른 일이 있습니까?
추신. 서버에서 어떤 일이 발생하는지 살펴 보는 동안 SQL Server에서 많은 ODBC (및 관련) 대기를 발견했습니다. 나에게는 큐브가 SQL Server에서 데이터를 처리하고 액세스하는 동안 OLEDB / ODBC 공급자를 통해 큐브에 대한 OPENQUERY 요청을 "차단"하는 것처럼 보입니다. .NET 앱 요청을 처리하기에 충분한 여유 CPU와 메모리가 있는지 Resource Governor를 통해 확인하더라도 서버 사용량이 적어 보이기 때문에이 결론에 도달했습니다 (CPU / 메모리 사용량 감소).
편집하다:
각 .NET 응용 프로그램 호출은 SSAS에 대해 실행되는 MDX 쿼리를 거의 실행하지 않습니다. 모든 쿼리는 100 개 이상의 행을 반환하지 않습니다. 이 모든 것은 임시 테이블에서 최종 결과로 결합됩니다. 이제 코드를 시작하고 최적화하는 것이 논리적이라는 것을 알고 있지만 코드는 우리가 변경하고 싶은 마지막 부분입니다. 잘 테스트되고 그렇지 않으면 잘 수행됩니다.
구성 및 인프라 아이디어를 찾고 있습니다.
OPENQUERY
저장 프로 시저에서 mdx에 대해를 사용할 때 매우 유사한 차단 및 시간 초과 문제가 발생했습니다 .
약 2 년 전에 오픈 소스 CLR
솔루션으로 전환했습니다. 이제 OPENQUERY와 비슷한 방식으로 이러한 저장 프로 시저를 사용하지만 문제는 없습니다 !!
현재 여기에서 사용할 수 있습니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다