Как данные возвращаются с SQL Server - PullRequest
1 голос
/ 16 ноября 2011

Это может быть глупый вопрос, но я пытаюсь понять, что происходит под прикрытием, когда вы извлекаете данные из SQL Server.Давайте предположим, что мы выбираем данные из индексированного представления, чтобы устранить неоднозначность.

Итак, насколько я понимаю, оптимизатор запросов будет воспринимать это так же, как таблицу.Хорошо, но какие шаги происходят между вызываемым представлением и фактическими данными, возвращаемыми клиенту?Данные извлекаются из физической файловой структуры в SQL Sever, и я предполагаю, что происходит некоторая потоковая передача, когда она возвращается вызывающему клиенту?Какие промежуточные шаги?

Давайте теперь сравним вызов этого представления непосредственно на сервере с каким-нибудь удаленным клиентом где-нибудь.Как данные возвращаются на удаленный клиент?Давайте предположим, что это через ODBC, но сам ли SQL Server возвращает данные одинаково, независимо от транспорта?Итак, получит ли он результаты, а затем передаст их клиенту, или он каким-то образом направит эти результаты обратно через механизм транспорта?Заранее спасибо за любое просвещение!: -)

Ответы [ 3 ]

2 голосов
/ 17 ноября 2011

Когда запрос запускается в исполнение, он в конечном итоге начинает давать результаты, по одной строке за раз. Неважно, является ли это запрос из таблицы, из индексированного представления, из выражения конструктора таблицы или чего-либо еще. В конце концов он достигнет стадии, на которой у него будет готов ряд результатов, и его нужно будет отправить клиенту. Спецификации табличного протокола потока данных описывают, в каком именно формате происходит отправка. Неважно, какой протокол используется (сокеты, сетевые каналы, общая память), формат одинаков для всех протоколов. Все драйверы на стороне клиента осуществляют синтаксический анализ потока TDS, а затем преобразуют данные в формате TDS в соответствующий формат клиентского API. Если это ODBC, то данные перемещаются в буферы, указанные в привязке столбца, когда SQLBindCol был вызван. Клиент OleDB определяет область памяти через структуры DBBINDING. Управляемые приложения SqlClient не определяют привязки, поскольку управление управляемой памятью отличается и избегает указателей, но вместо этого сам SqlClient копирует данные в объекты, которые затем возвращаются при вызове SqlDataReader.GetValue . Поскольку клиенты удовлетворены проверкой значений строк, они вызывают версию API NextRow (IRowset::GetNextRows, SQLFetch, SqlDataReader.Read и т. Д.) До API возвращает «больше никаких строк».

Это маршалинг от сервера обратно к клиенту продолжается до тех пор, пока все строки не будут созданы и отправлены обратно. Если клиент задерживает обработку на длительное время (застревает в обработке значения и не вызывает аромат PAI NextRow), то в конечном итоге включается управление транспортным потоком , и сервер блокирует ASYNC_NETWORK_IO тип ожидания, пока клиент не возобновит итерацию результата и не разблокирует управление транспортным потоком. Обсуждение, связанное с какой-то проблемой: Ускорение скорости, с которой IIS / .NET / LINQ получает данные из сетевых буферов .

.
0 голосов
/ 16 ноября 2011

Чтобы охватить область извлечения данных, при вызове SQL для извлечения некоторых данных SQL сначала проверит, находятся ли искомые страницы данных в памяти, чтобы ускорить доставку данных. , Если нет, то он извлекает эти данные из файлов данных на диске и считывает их обратно в память. Оттуда ваши данные представляются клиенту. В случае представления это объект, который просто имеет подчеркивающий оператор SQL, который строит это представление. Таким образом, этот оператор будет выполнен для построения представления, тогда все предикаты, которые вы передали представлению, будут оценены и переданы клиенту.

От способа доставки данных клиенту зависит, будет ли ваш сервер прослушивать TCP / IP (это наиболее распространенный вариант), именованные каналы, общая память. С точки зрения ODBC, SQL будет доставлять данные в драйвер ODBC, инкапсулировать данные в пакет TCP / IP и доставлять их клиенту через любой порт, к которому вы подключены (по умолчанию SQL - 1433).

Надеюсь, это поможет.

0 голосов
/ 16 ноября 2011

Да ....

Я буду использовать ODBC для иллюстрации. Это в основном «интерфейс». Вы общаетесь с сервером SQL через драйвер ODBC, он переводит ODBC на сервер SQL и сервер SQL на ODBC, сервер SQL не делает ничего другого.

Равный запрос ваших данных на клиентском ПК через TCP / IP или внутри триггера не меняет того, как оптимизатор запросов выясняет, что делать, или как базовые данные считываются с диска.

Ключевой частью хорошего проектирования программного обеспечения является модульность. Этот бит говорит с дисковой системой, этот бит оптимизирует, этот бит отправляет данные по сокету.

Не пытайтесь объяснить, как эти биты на этом жестком диске оказались как пиксели на этом мониторе, помимо того, что это чертовски сложно, это сводит на нет программирование как подход к решению проблем.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...