2011-11-16 8 views
1

이것은 바보 같은 질문 일 수 있지만 SQL Server에서 데이터를 검색 할 때 처리되는 내용을 이해하려고합니다. 모호성을 제거하기 위해 인덱싱 된 뷰에서 데이터를 선택한다고 가정 해 보겠습니다.데이터가 SQL Server에서 반환되는 방법

제 생각에 쿼리 최적화 프로그램은 이것을 테이블과 동일하게 취급합니다. 좋아,하지만 호출되는 뷰와 클라이언트로 반환되는 실제 데이터간에 발생하는 단계는 무엇입니까? 데이터는 SQL Sever의 실제 파일 구조에서 검색되며 호출 클라이언트에 반환 될 때 일종의 스트리밍이 발생한다고 가정합니다. 그 중간 단계는 무엇입니까?

이제이보기를 서버에서 직접 호출하는 경우와 일부 원격 클라이언트를 직접 호출하는 경우를 비교해 보겠습니다. 데이터는 어떻게 원격 클라이언트에 반환됩니까? 이것이 ODBC를 통한 것이라고 가정하되, SQL Server 자체는 전송과 상관없이 동일한 방식으로 데이터를 반환합니까? 그러면 결과를 검색 한 다음 클라이언트에 전달하거나 전송 메커니즘을 통해 결과를 다시 스트리밍할까요?

나는 이것이 의미가 있기를 바랍니다. 모든 계발에 미리 감사드립니다! :-)

+1

귀하의 질문에 많은 부분이 포함되어 있습니다. 주로 데이터가 클라이언트로 되돌아가는 방식은 사용하려고 선택한 커서에 따라 다르지만 전송 메커니즘을 기반으로 변경할 수도 있습니다. 나는이 분야의 전문가는 아니지만, 나는 양쪽 모두가 상당히 잘 알고 있지만, 중간에는 그렇지 않다. 나는 그것이 효과가 있다는 것을 알고있다. :) –

+0

미리 컴파일 된 뷰 구조를로드하기 위해 인덱스를 작성하고 분석 한 이후로 적절한 데이터를 제공하기 위해 엔진에 많은 작업을 수행했습니다. 귀하의 질문은 일부 네트워크 enginner에서 좋은 대답을 가질 수 있습니다, 그것은 데이터가 전송되는 방법을 설명 할 수 로컬, 원격, 프로토콜, 레이어 및 모델. 정말 흥미 롭지 만 여러 영역이 혼합되어 있기 때문에 조금 복잡합니다. – Hamikzo

+0

"모호성을 제거하기 위해 인덱싱 된 뷰에서 데이터 선택"나는 인덱싱 된 뷰가 자신이 수행하고 있다고 생각하는 것을 수행하지 않는 것으로 의심합니다. – Hogan

답변

0

예 ....

설명하기 위해 ODBC를 사용합니다. 기본적으로 '인터페이스'입니다. 당신은 ODBC 드라이버를 통해 SQL 서버와 이야기하고, ODBC를 SQL 서버와 SQL 서버로 ODBC로 변환하고, SQL 서버는 전혀 다른 작업을 수행하지 않습니다.

마찬가지로 TCP/IP 또는 트리거를 통해 클라이언트 PC에서 데이터를 요청해도 쿼리 최적화 프로그램이 수행 할 작업이나 기본 데이터를 디스크에서 읽는 방법을 파악하는 방법은 변경되지 않습니다.

좋은 소프트웨어 설계의 핵심 부분은 모듈화입니다. 이 비트는 디스크 시스템과 통신하며,이 비트는 최적화되어이 비트는 데이터를 소켓으로 보낸다.

디스크 드라이브의이 비트가이 모니터의 픽셀처럼 어떻게 끝나지 않았는지, 어렵지 않다는 점을 제외하고는 문제 해결 방법으로 프로그래밍을 무효화합니다.

+0

답장을 보내 주셔서 감사합니다. 네트워크를 통해 데이터를 반환하는 것과 직접 네트워크를 통해 데이터를 반환하는 것의 성능 차이를 파악하려고합니다. 대기 시간이 가장 길고 영향이 많은 곳. 보기가 수천 개의 레코드를 반환한다고 가정하면 네트워크에 대기 시간이 있기 전에 서버에서 버퍼링을 시작하여 비용을 무시할 수 있습니까? 그냥 몇 가지 방법을 계량하려고. –

+0

가치가 있지만 실제로 SQL Server와 관련이 없으며 네트워크가 얼마나 바쁜지에 크게 의존합니다. 당신이 할 수있는 모든 것이 얼마나 많은 데이터/얼마나 자주 그리고 어떤 방향으로 가는가하는 것은 네트워크가 어떻게 설정되었는지에 달려 있습니다. 클라이언트 서버의 규칙 하나는 서버에서 수행 할 수있는 경우입니다. 만약 당신이 그것을 최대한 활용하고 클라이언트에게 위임을하고 싶다면 어쨌든 시간이 중요하지 않을 것입니다. –

0

일부 데이터를 검색하기 위해 SQL을 호출 할 때 데이터를 검색하는 영역을 포함하기 위해 SQL은 먼저 데이터 페이지가 메모리에 있는지 확인하여 전달 속도를 향상시킵니다 데이터. 그렇지 않은 경우 디스크의 데이터 파일에서이 데이터를 검색하여 다시 메모리로 읽어들입니다. 여기에서 데이터가 클라이언트에 다시 표시됩니다. 뷰의 경우이 뷰를 빌드하는 밑줄 SQL 문만있는 오브젝트입니다. 따라서이 명령문은 뷰를 빌드하기 위해 실행될 것이고 뷰에 전달 된 어떤 조건이 평가되어 클라이언트로 전달 될 것입니다.

데이터가 클라이언트에 전달되는 방법은 서버가 TCP/IP (가장 일반적인 방법), 명명 된 파이프, 공유 메모리를 통해 수신하는지 여부에 따라 다릅니다. ODBC의 관점에서 볼 때 SQL은 데이터를 ODBC 드라이버에 전달하고 데이터를 TCP/IP 패킷으로 캡슐화하고 연결되어있는 포트 (SQL 기본값은 1433)에 클라이언트에 전달합니다.

희망이 도움이됩니다.

2

쿼리를 실행하면 결과가 한 번에 하나씩 생성되기 시작합니다. 테이블의 쿼리, 인덱싱 된 뷰의 쿼리, 테이블 생성자 식의 쿼리 등은 중요하지 않습니다. 결국 결과 행을 준비하고 클라이언트에 전송해야 할 단계에 도달하게됩니다. Tabular Datastream Protocol specifications은 정확히 '전송'이 발생하는 형식을 설명합니다. 사용 된 프로토콜 (소켓, 네트 파이프, 공유 메모리)은 중요하지 않습니다. 형식은 모든 프로토콜에서 동일합니다.클라이언트 측 드라이버는 모두 TDS 스트림의 구문 분석을 구현 한 다음 TDS 형식의 데이터를 클라이언트 API의 적절한 형식으로 변환합니다. ODBC 인 경우 SQLBindCol이 호출 될 때 데이터가 열 바인딩에 지정된 버퍼로 이동됩니다. OleDB 클라이언트는 DBBINDING 구조체를 통해 메모리 영역을 지정합니다. Managed SqlClient 앱은 관리되는 메모리 관리가 다르므로 포인터를 피하는 대신 바인딩을 지정하지 않지만 SqlClient 자체는 데이터를 SqlDataReader.GetValue이 호출 될 때 반환되는 개체에 복사합니다. 클라이언트가 행 값을 검사하면 API가 'no more rows'를 반환 할 때까지 NextRow (IRowset::GetNextRows, SQLFetch, SqlDataReader.Read 등)의 API 버전을 호출합니다.

서버에서 클라이언트로 마샬링하는 작업은 모든 행이 생성되어 다시 전송 될 때까지 계속됩니다. 클라이언트가 오랫동안 처리를 지연하면 (PAI의 풍미를 NextRow이라고하지 않음) 결국 transport flow control이 실행되고 서버는 ASYNC_NETWORK_IO 대기 유형으로 차단됩니다. 클라이언트는 클라이언트가 결과 및 전송 흐름 제어를 차단 해제합니다. 어떻게 든 관련 토론은 Speeding up the rate that IIS/.NET/LINQ retrieves data from the Network Buffers입니다.

관련 문제