• Web-клиент, выполняющий запрос к порталу SSRS.
• SQL Server Reporting Service (SSRS) базы которого размещены на SQL Server.
• И собственно SQL Server.

• Контроллер домена (DC).
• Служба разрешения доменных имен (DNS).

1. Установите SPN-ы (как показано на рисунке ниже) для пользователя от которого функционирует Reporting Service.

1. Проверим, что в свойствах учетной записи, от которой стартован Reporting Service, не установлено свойство "Account is sensitive and cannot be delegated"
2. В свойствах компьютерного объекта, на котором функционирует Reporting Service, в закладке Delegation устновите "Trust this computer for delegation to any service (Kerberos only)"
3. В свойствах пользователя, от которого функционирует Reporting Service, в закладке Delegation устновите "Trust this user for delegation to any service (Kerberos only)" Примечание: Если у пользователя нет такой закладки, то это значит, что не установлен ни один SPN.

Далее мы обратим свое внимание на сетевые проблемы, как наиболее часто встречающиеся при первоначальном развертывании и при эксплуатации системы.

Какие виды ошибок сетевого доступа, чаше всего возникают при эксплуатации сервис-брокера

1. Общие сетевые проблемы характерные для любой установки SQL Server. 

2. Отсутствие точек подключения (Endpoint).

3. Точки подключения переведены в режим останова (STOPPED) или неправильно настроены.

4. Доступ к точкам подключения закрыт межсетевым экраном.

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

1. Убедиться в доступности удаленного хоста командой ping host_name, а если ping host_name не проходит, то выполнить ping по IP-адресу, и далее разбираться с системой разрешения имен.  

2. Убедиться в доступности удаленного SQL Server с помощью команды SQLCMD -E -Sserver. Если это подключение невозможно, то необходимо разбираться с сетевыми соединениями на SQL Server, доступностью портов и работой SQL Browser.

После решения общих сетевых проблем (если это не привело к положительному результату и сервис-брокер по прежнему не работает) можно переключиться на решение специфических проблем сервис-брокера.

Отсутствие точек подключения (Endpoint)

 Необходимо убедиться, что точки подключения для Service Broker-а созданы, для этого необходимо выполнить команды.

use InstInitiatorDB;
GO
select * from sys.service_broker_endpoints;
GO
select * from sys.endpoints where name = 'InstInitiatorEndpoint';

Обратите внимание, что первая команда выполняется в контексте базы, на которой настроен сервис брокер.

Точки подключения переведены в режим останова (STOPPED) или неправильно настроены 

Если одна из точек остановлена (или некорректно настроена), то при попытке соединения с ней возникнет ошибка как показано ниже.

Такая же ошибка отображается и в трассах SQL Profiler. Как видно из трасс, SQL Server (не смотря на наличие ошибки) продолжает свои попытки установить соединение на точку подключения удаленного сервера.

При наличии подобной ошибки рекомендуется убедиться в доступности порта удаленной точки подключения. Как видно в данном случае соединение к порту не возможно.

После этого можно проверить"слушает" ли удаленный сервер порт номер 4022 (в данном случае это номер порта для Service Broker-а). Здесь  показано как мы выгружаем в файл ports.txt данные о том, какой из процессов "слушает" какой порт.

После решения данной сетевой проблемы и восстановления соединения, сообщения будут переданы автоматически  (См. последние 5 строк трассы).

Справедливости ради необходимо сказать, что с помощью утилиты ssbdiagnose.exe мы бы добились того же результата значительно быстрее.

 Доступ к точкам подключения закрыт межсетевым экраном.

Еще одной наиболее вероятной проблемой может быть закрытие портов межсетевыми экранами. Это более чем возможно, и потому еще, что для сервис-брокера могут использоваться нестандартные номера портов. 

Последовательность решения здесь принципиально не отличается от вышеописанной, и, более того, как и в предыдущем случае, утилита ssbdiagnose.exe оказывается на высоте, давая нужный результат сразу.

В следующих статьях мы продолжим рассмотрение возможных причин некорректной работы SQL Server Service Broker.

Александр Каленик, Senior Premier Field Engineer (PFE), MSFT (Russia)  

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

Впервые эта полезная вещь появилась в SQL Server 2005, и с тех пор не сильно изменилась. Точнее сказать она приросла некоторыми новыми возможностями, но принципы, заложенные в те годы, так и остались неизменными.

Итак.

Как следует из https://technet.microsoft.com/ru-ru/library/ms166049(v=sql.105).aspx, компонент Service Broker помогает создавать асинхронные слабосвязанные приложения, в которых независимые компоненты совместно выполняют ту или иную задачу. Эти компоненты обмениваются сообщениями, которые содержат данные, необходимые для выполнения задачи. В этом разделе описываются следующие аспекты компонента Service Broker:

• диалоги;
• упорядочение и координация сообщений;
• асинхронное программирование на основе транзакций;
• поддержка слабосвязанных приложений;
• составные части компонента Service Broker.

Основными строительными кирпичиками системы являются:

• Сообщения. Блоки информации, которыми обмениваются участники.
• Контракт. Сообщения собираются в контракт для того, что бы обмен сообщениями был более формализован.
• Очереди. Сообщения для отправки и при получении помещаются в специальные очереди, которые есть как у отправителя, так и у получателя.
• Сервис. Все вышеперечисленные компоненты соединяются сервисом, который и является единицей взаимодействия в системе.
• Маршруты. Для доставки сообщений на сервисы создаются маршруты доставки.
• Диалог. Программируемый способ отправки сообщения от инициатора к получателю и обратно.
• Транзакции. Вся обработка данных при передаче и получении производится по транзактному принципу, исключающему утрату данных.
  

Надо сказать, что инфраструктура Service Broker оказалась настолько успешной, что она широко используются в SQL Server для реализации других возможностей, таких как Query Notification, AlwaysOn Availability Group и некоторых других компонент SQL Server.

Давайте пошагово разберемся как происходит формирование и передача сообщений в системе Service Broker. Для целей демонстрации я использовал скрипты, очень похожие на те, что опубликованы здесь https://technet.microsoft.com/en-us/library/bb839483(v=sql.105).aspx.

Моя тестовая среда включает в себя:

• Два экземпляра SQL Server установленных на разных виртуальных машинах
• Контроллер домена.
• Точки доступа (Endpoints)  настроены для использования Windows аутентификации.
• На обоих серверах созданы пользователи без логинов, использующие сертификаты для взаимной аутентификации.
• Сертификаты скопированы на оба сервера с использованием backup.

 Как это все работает вместе. Ниже приведена упрощенная схема обмена сообщениями и ее описание.

1. При отправке с инициатора сообщение попадает во внутреннюю очередь передачи представляющую собой внутреннюю системную таблицу sys.sysxmitqueue, выполнив запрос к ней мы получим, то, что ожидали.

Для просмотра сообщений, находящихся в очереди, во вне "выставлено" динамическое представление  sys.transmission_queue, выполнив запрос к которому вы получите почти тот же результат. Однако в этом представлении есть очень полезный элемент, это столбец  transmission_status, содержащий информацию об ошибке, возникшей при передаче и обработке сообщения.

Например: "Connection attempt failed with error: '10061(No connection could be made because the target machine actively refused it.)'."

Также сообщение логируется в журнале транзакций, что обеспечивает его транзактную обработку.

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

2. После помещения сообщения в очередь передачи (sys.transmission_queue) выполняется его классифицирование. 

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

Мы можем увидеть выполнение этапа классификации с помощью трасс SQL Profiler, если выберем события относящиеся к Service Broker. Обращаю внимание, что часть событий относящихся к Service Broker размещены в разделе Security Audit.

 3. После выполнения классификации сообщения, устанавливается соединение с удаленной (как в данном случае) точкой соединения (Endpoint). В данном случае - это сервер использующий протокол TCP, с именем SQL2014-I1 и номером порта (Endpoint) 4022. Если при выполнении соединения возникнет ошибка, то она появится в трассе (как показано ниже) и в столбце transmission_status просмотра sys.transmission_queue.

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

В трассе на инициаторе и отправителе мы увидим подтверждение передачи.

 5. Поскольку сообщение доставлено до получателя, то оно должно появиться во входной очереди получателя.

По правде говоря, имя очереди получателя, к которой мы в данном случае сделали запрос, это виртуальный объект типа просмотр (View). Реально, данные на получателе сохраняются системной таблице, доступ к которой можно получить через DAC.

В данном случае это внутренняя таблица queue_messages_293576084. Выполнив запрос к которой мы получим почти те же данные, что и при обращении к очереди InstTargetQueue.

И так. Мы прошли по всей цепочке от момента формирования сообщения до получения его целевым сервисом.

Далее, целевой сервис должен прочитать сообщения из очереди (желательно по одному) и отправить подтверждение о получении инициатору диалога. Делается эта процедура с использованием специального синтаксиса, который есть в прилагаемых скриптах https://technet.microsoft.com/en-us/library/bb839483(v=sql.105).aspx.

По мере чтения данных из очереди она пустеет, а отправителю посылается подтверждающие сообщения (или не посылаются) форма, состав которых, а также посылаются они, или нет, зависит от разработчика сервиса.

Если по мере чтения очереди программируется отправка подтверждающих сообщений, то они проходят тот же путь, что и от получателя, только в обратном порядке.

В данном блоге мы достаточно подробно рассмотрели весь путь от отправителя до получателя и в следующем начнем рассмотрение вопросов связанных с решением проблем с Service Broker на каждом из этапов обработки и передачи.. 

Александр Каленик, Senior Premier Field Engineer (PFE), MSFT (Russia)  

Мы продолжаем разговор о использовании query_hash и query_plan_hash для оптимизации использования процедурного кэша и уменьшения нагрузки на процессор. В предыдущем блоге мы выполнили постановку задачи и вышли на использование этих свойств запроса (https://blogs.technet.com/b/sqlruteam/archive/2014/11/09/sql_5f00_server_5f00_query_5f00_hash_5f00_and_5f00_query_5f00_plan_5f00_hash_5f00_part_5f00_1.aspx).

Для более глубокого понимания описываемых свойств рассмотрим упрощенную архитектуру системы компиляции запросов (кода Transact-SQL).

Ниже приведена блок-схема. Для упрощения часть ее компонентов пропущена.

Последовательность превращения кода, написанного на Transact-SQL, в план выполнения следующая.

1. Текст запроса (функция, триггер, хранимая процедура) попадает на вход Parser-а. Задача которого проста - выполнить синтаксический контроль введенного текста и нормализацию текста (удалить ненужные пробелы и форматировать во внутренний (нормальный) формат. На этом этапе из кода запроса рассчитывается sql_handle (внутренний идентификатор однозначно идентифицирующий этот код).  sql_handle рассчитывается исходя из исходного (ненормализованного) текста запроса и поэтому такой же запрос, но с дополнительным символом "пробел" или оператором GO в одном и том же тексте, будет трактоваться как новый запрос, и для него будет рассчитан свой sql_handle, и создана еще одна запись в процедурном кэше.

Ниже приведены два абсолютно одинаковых запроса, отличающиеся наличием лишнего символа "пробел". Обратите внимание на то, что sql_handle у них разные, а вот query_hash и query_paln_hash одинаковы.

select *
from [Person].[Person] pp
inner join [Sales].[SalesPerson] ssp
on pp.BusinessEntityID=ssp.BusinessEntityID
where FirstName= 'Michael'

go

select *
from [Person].[Person]  pp
inner join [Sales].[SalesPerson] ssp
on pp.BusinessEntityID=ssp.BusinessEntityID
where FirstName= 'Michael'

2. Нормализованный текст запроса попадает на Algebrizer. Его задача - превратить все ваши "измышления" на языке T-SQL в дерево разбора (Bound Tree), описывающее алгоритм выполнения запроса (кстати для View на этом все и заканчивается и дальнейшая обработка (оптимизация) не производится). Также, на данном этапе производится извлечение из кода запроса литералов. Цель этой операции -  обеспечить возможность использования Auto Parameterization (Автопараметризации) для уменьшения количества планов выполнения. Ниже приведенные запросы будут иметь разные sql_handle (поскольку побайтово тексты запросов разные), но одинаковые query_hash и query_plan_hash поскольку дерево разбора и алгоритмы их выполнения одинаковы.

select *
from [Person].[Person] pp
inner join [Sales].[SalesPerson] ssp
on pp.BusinessEntityID=ssp.BusinessEntityID
where pp.BusinessEntityID = 274

go

select *
from [Person].[Person] pp
inner join [Sales].[SalesPerson] ssp
on pp.BusinessEntityID=ssp.BusinessEntityID
where pp.BusinessEntityID = 275

 3. На этапе оптимизации решаются более сложные задачи.

Первая из них - это отыскание тривиального плана. Часть запросов достаточно просты и нет необходимости их оптимизировать, например, простейшие операторы INSERT, UPDATE, DELETE, SELECT не использующие никаких условий (предикатов). Для таких запросов хранятся готовые планы выполнения.

Вторая задача - это стандартизация.  Это сложная задача по приведению разных конструкций, дающих один и тот же результат, к одной стандартной конструкции. На этом этапе сервер преобразует код T-SQL в некоторые стандартные (предварительно заготовленные разработчиками) формы деревьев, для того чтобы уменьшить возможное количество кандидатов на планы выполнения.  
Например: 
- соединение таблиц через оператор JOIN ... ON это одно и то же, что соединение через запятую и оператор WHERE,
- использование операторов WHERE ... BETWEEN ... AND ... дает тот же результат, что и операторы WHERE ...  >=... и ...<=,
- использование оператор WHERE ... IN(....) дает тот же результат, что и операторы WHERE ... OR ...
- и т.д.

select *
from [Person].[Person] pp
inner join [Sales].[SalesPerson] ssp
on pp.BusinessEntityID=ssp.BusinessEntityID
where FirstName= 'Michael'

go

select *
from [Person].[Person] pp, [Sales].[SalesPerson] ssp
where pp.BusinessEntityID=ssp.BusinessEntityID and FirstName= 'Michael'

Обратите внимание, что несмотря на то, что тексты запросов абсолютно разные, query_hash (структуры деревьев разбора) также разные, а query_plan_hash одинаковы, благодаря встроенному "интеллекту" оптимизатора, "понимающему", что (по алгоритму выполнения) это один и тот же запрос.

Еще пример с операторами DISTINCT и GROUP BY.

select distinct FirstName
from [Person].[Person] pp
inner join [Sales].[SalesPerson] ssp
on pp.BusinessEntityID=ssp.BusinessEntityID

go

select FirstName
from [Person].[Person] pp
inner join [Sales].[SalesPerson] ssp
on pp.BusinessEntityID=ssp.BusinessEntityID
group by FirstName

Есть еще ряд задач решаемых в ходе оптимизации, но для их описания необходима целая серия статей.

Итак мы рассмотрели принципы работы системы компиляции запросов и связь их с query_hash и query_plan_hash. В следующих статьях мы сформулируем ряд рекомендаций по оптимизации использования процедурного кэша на основе полученных знаний.

Александр Каленик, Senior Premier Field Engineer (PFE), MSFT (Russia) 

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

При анализе загруженности процессоров на сервере клиента я обнаружил, что средняя нагрузка на них составляет до 35…40%%, что в общем-то нормально. Странно, что такая нагрузка присутствует на 80-ти процессорной системе всего при 580 Batch Requests/sec.

Из моего предыдущего блога (https://blogs.technet.com/b/sqlruteam/archive/2014/01/12/server.aspx) известно, что основными источниками нагрузки на процессоры являются операции компиляции, сортировки и хеширования.

В данном случае причиной нагрузки на процессоры оказалось огромное количество компиляций, превышающее норму в пять раз. Т.е. на 580 Batch Requests/sec выполняется 339 компиляций, при норме не более 58.

Анализ содержимого процедурного кэша показал, что огромное количество одинаковых по коду запросов имеют записи в процедурном кэше. Как видно на рисунке ниже некоторые планы повторяются по 200 и более раз. Для получения этих данных я воспользовался этим "волшебным" числом "query_hash".

За счет многократного повторения запросов израсходовано дополнительно 62 ГБ оперативной памяти. Как видно из рисунка ниже если бы планы выполнения многократно не повторялись, то для их размещения понадобилось бы 20 ГБ вместо 82 ГБ.

Собственно таких "волшебных" числа два, это - query_hash и query_plan_hash. Появились эти числа в SQL Server 2008 и именно ими можно пользоваться для оптимизации использования процедурного кэша и уменьшения компиляции и нагрузки на процессор.

Как воспользоваться этими новыми возможностями мы рассмотрим в нашем следующем блоге.

Александр Каленик, Senior Premier Field Engineer (PFE), MSFT (Russia) 

В предыдущей статье мы рассказали о связи FILESTREAM с операционной системой. Далее мы продолжим разговор о скрытых (внутренних) механизмах работы FILESTREAM.

Создадим тестовую базу.

USE master;
GO
CREATE DATABASE FileStreamTest
ON PRIMARY (Name=FileStreamTest_data, FILENAME = 'C:\FileStream\FileStreamTest.mdf'),
FILEGROUP FSGroup CONTAINS FILESTREAM(Name=FSData, FILENAME = 'C:\FileStream\filestream1')
LOG ON (Name=FileStreamTest_log, FILENAME = 'C:\FileStream\FileStream.ldf');
GO

После создания базы в папке  "C:\FileStream" появилась папка "filestream1", а в ней папка "$FSLOG" и файл "filestream.hdr".

Папка  "$FSLOG" будет в дальнейшем содержать файлы, отслеживающие изменения производимые с файлами BLOB, подобно журналу транзакций SQL Server. Файл "filestream.hdr" содержит внутреннюю информацию для SQL Server. Он связывает BLOB-хранилище c реляционными таблицами базы данных. Этот файл не доступен для чтения, поскольку заблокирован SQL Server-ом.

Папка "filestream1" не может содержать данные второго FILESTREAM-хранилища,

Увидеть какая папка содержит какие данные можно с помощью запросов, приведенных ниже.

use FileStreamTest;
GO
select *
from sys.database_files df
join sys.data_spaces ds
on df.data_space_id = ds.data_space_id;
GO
SELECT *
FROM sys.filegroups fg
join sys.data_spaces ds
on fg.data_space_id = ds.data_space_id

Создаем таблицу для размещения filestream data

use FileStreamTest;
GO
CREATE TABLE dbo.FS_Records
(DocGUID UNIQUEIDENTIFIER ROWGUIDCOL NOT NULL UNIQUE DEFAULT NEWID(),
 DocId int NOT NULL UNIQUE IDENTITY (1,1),
 Document varbinary(max) FILESTREAM NULL);
GO

В таблице обязательно должен присутствовать столбец созданный подобным образом "UNIQUEIDENTIFIER ROWGUIDCOL NOT NULL UNIQUE DEFAULT NEWID()". Это необходимо для идентификации каждой отдельной строки. Можно не использовать значение DEFAUL типа "NEWID()", но тогда вам придется присваивать новое значение каждый раз при вставке строки. Вместо этой функции можно использовать другую, генерирующую GUID.

Вставим пустую строку

use FileStreamTest;
GO
INSERT INTO dbo.FS_Records (Document) VALUES (NULL);
GO

Посмотрим в \\localhost\SQL2014_FileStream там пусто, это нормально, там всегда будет пусто, поскольку это точка перенаправления для клиентов работающих через Win32 API, но появились папки в "C:\FileStream\filestream1, при этом папки с GUID в качестве имени - пустые, поскольку мы вставили пустую строку (пустой BLOB), а все остальные данные и определения строки хранятся в mdf (FileStreamTest_data).
Теперь вставим строку содержащую данные. 

INSERT INTO dbo.FS_Records (Document) VALUES (CAST('Yes, it''''s work fine' as varbinary(max)));
GO

Посмотрим в "\\localhost\SQL2014_FileStream" там (как и ранее) пусто, при этом одна из папок с GUID в качестве имени содержит файл. В моем случае это файл с именем 0000002a-00000150-0006. Откроем его с помощью Notepad.exe (в реальной жизни прямой доступ (через файловую систему) с FILESTREAM-файлами настоятельно не рекомендуется) и внутри вы увидите "Yes, it''s work fine", все же остальные данные этой строки храняться в mdf-файле (FileStreamTest_data).

Что представляет собой имя файла?
Для ответа на это вопрос давайте выполним запрос к недокументированной функции и укажем ей в качестве условия имя файла 0000002a-00000150-0006 слегка модифицировав его в формат 0000002a:00000150:0006.

SELECT [Current LSN], Operation, [Transaction ID]
FROM sys.fn_dblog(null,null)
WHERE [Current LSN] = '0000002a:00000150:0006'

Как мы видим этому имени соответствует операция (LOP_FS_DOWNLEVEL_OP) в журнале транзакций, т.е. в журнал записана операция создания файла и его имя соответствует LSN этой операции.

Выполним запрос к созданной таблице.

SELECT DocGUID, cast (Document as char(100) ) as [Document text], Document.PathName(0) as [Path name]
FROM dbo.FS_Records

В запросе есть столбец "Path name" который получен встроенной функцией PathName(0). Этот путь необходим для доступа к FILESTREAM-файлу через специальный Win32 API, для доступа через Transact-SQL он не нужен. 

Обратите внимание на то, что часть пути (помечено красным) соответствует DocGUID. Как было показано в предыдущей статье, при выполнении команды NET SHARE мы получим строку "SQL2014_FileStream\\?\GLOBALROOT\Device\RsFx0300\<localmachine>\SQL2014_FileStream", где присутствует имя общего ресурса "SQL2014_FileStream", а также имя минифильтра RsFx0300. Таким образом, когда клиенты Win32 API обращаются по пути полученному функцией PathName() их запрос через минифильтр перенаправляется на SQL Server и далее в файловую систему.

Как это работает?

• Запрос приходит на SQL Server.
• По значению DocGUID извлекается нужная физическая страница.
• Из страницы извлекается реальное имя файла (соответствующее LSN транзакции его создавшей) 

Для получения номера страницы и строки мы воспользуемся недокументированной функцией описанной в https://www.sqlskills.com/blogs/paul/sql-server-2008-new-undocumented-physical-row-locator-function.

use [FileStreamTest];
GO
SELECT DocGUID, cast (Document as char(100) ) as [Document text], sys.fn_PhysLocFormatter (%%physloc%%) AS [Physical RID]
FROM dbo.FS_Records
WHERE DocGUID = 'B16BC7B7-D337-4D52-A2CC-C4695C629362';

Как видно из результатов запроса искомая строка лежит в файле №1, странице 300 и номер строки равен 1.

Выполним запрос на получение данных хранящихся в странице, используя недокументированную функцию DBCC PAGE (); Найдем нужную нам строку (slot) по DocGUID (обозначено красным). 

DBCC TRACEON (3604);
DBCC PAGE ([FileStreamTest], 1,300,3);

Получим

Slot 1 Column 1 Offset 0x4 Length 16 Length (physical) 16
DocGUID = b16bc7b7-d337-4d52-a2cc-c4695c629362

Slot 1 Column 2 Offset 0x14 Length 4 Length (physical) 4
DocId = 2

Document = [Filestream column] Slot 1 Column 3 Offset 0x1f Length 48
ColType = 3 Version = 1 FileId = 65537
UpdateSeq = 1 CreateLSN = 0000002a:00000150:0006 (42:336:6)
TxFMiniVer = 0

Как видим в поле CreateLSN находится значение 0000002a:00000150:0006. Если в этой строке заменить двоеточие на дефисы, то получим  0000002a-00000150-0006, что и будет соответствовать имени файла размещенного в папке "C:\Filestream\filestream1\04e6a56a-9457-4dd3-8b1f-ac0f49a49b0a\38e656d7-2cfb-43c8-ae98-f489b57f6d7d".

Откуда пришло значение "C:\Filestream\filestream1\" мы знаем, поскольку мы сами его указали при создании базы, но откуда берутся еще два имени папок ("04e6a56a-9457-4dd3-8b1f-ac0f49a49b0a\38e656d7-2cfb-43c8-ae98-f489b57f6d7d")? Каким образом клиент может получить информацию по этим папкам, чтобы загрузить файл из этих папок?

Для ответа на этот вопрос нам необходимо обратиться к внутренним, системным таблицам SQL Server, доступ к которым возможен только с использованием Dedicated Administrative Connection (DAC).

Выполним запрос к базе данных, подключившись к ней через DAC.

use FileStreamTest;
go
SELECT o.name AS [Table], cp.name AS [Column], r.rsguid AS [Rowset GUID], rs.colguid AS [Column GUID]
FROM sys.sysrowsets r
CROSS APPLY sys.sysrscols rs
JOIN sys.partitions p ON rs.rsid = p.partition_id
JOIN sys.objects o ON o.object_id = p.object_id
JOIN sys.syscolpars cp ON cp.colid = rs.rscolid
WHERE rs.colguid IS NOT NULL AND o.object_id = cp.id AND r.rsguid IS NOT NULL AND r.rowsetid = rs.rsid AND o.name = 'FS_Records' and cp.name = 'Document';

Теперь, если произвести произвести побайтовую перестановку "Rowset GUID" и "Column GUID" (См. https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%80%D1%8F%D0%B4%D0%BE%D0%BA_%D0%B1%D0%B0%D0%B9%D1%82%D0%BE%D0%B2), то мы получим имена папок файловой системы.

Итог.

В данной статье мы разобрались с внутренними механизмами управления FILESTREAM, включая недокументированные и скрытые от глаз пользователей элементы системы. Мы надеемся, что данный материал позволит вам полнее понять работу с  FILESTREAM.
В следующих статьях мы рассмотрим доступ к данным FILESTREAM с использованием языка Transact-SQL и C#.

Александр Каленик, Senior Premier Field Engineer (PFE), MSFT (Russia)