PowerShell'овский провайдер для SQL Server
Под провайдером в PowerShell понимается такая хрень, которая позволяет работать с объектами некоторого семейства, как с файловой системой. Имеется в виду возможность выполнять навигацию по путям вида диск:\директория1\...\директорияN\файл, а также встроенные командлеты и соответствующие им команды типа cd, copy, del и т.д. против объектов этого семейства.
PowerShell'овский провайдер подключается как .NETовская dll, внутри которой реализуются методы PSDriveInfo NewDrive(PSDriveInfo drive), PSDriveInfo RemoveDrive(PSDriveInfo drive), void GetItem(string path), void SetItem(string path, object values), void GetChildItems(string path, bool recurse), void NewItem(string path, string type, object newItemValue), void CopyItem(string path, string copyPath, bool recurse) и др., в которых прописывается, что на самом деле нужно делать при попытке создания/удаления диска, копировании и т.д. в зависимости от характеристик объекта и природы семейства. Примеры на создание собственного PowerShellьного провайдера можно посмотреть на MSDN: https://msdn.microsoft.com/en-us/library/bb648630(VS.85).aspx, https://msdn.microsoft.com/en-us/library/ms714605(VS.85).aspx#defineproviderbasic. Более подробно ссылки на ресурсы по изучению PowerShell и возможности его расширения за счет создания собственных провайдеров, командлетов и хостящих приложений приводятся в BOL: https://msdn.microsoft.com/ru-ru/library/cc281945.aspx.
В составе SQL Server 2008 устанавливается оболочка под названием sqlps (C:\Program Files\Microsoft SQL Server\100\Tools\Binn\sqlps.exe), про которую написано, что это не есть честный PowerShell, а некий minishell. Из блога команды разработки SQL Server (https://weblogs.sqlteam.com/dmauri/archive/2008/06/18/60631.aspx) можно почерпнуть, что они взяли исходники PowerShell, добавили туда функционал по взаимодействию с SQL Server, что-то выкинули, заново компильнули и вот теперь эта пересобранная сборка PowerShellа называется sqlps. Ее можно вызвать непосредственно из SQL Server Management Studio:
Из добавленной функциональности в ней, в частности, присутствует PowerShell'овский провайдер для SQL Server.
"Диск" SQLSERVER позволяет управлять объектами
1) Database Engine (базы и содержащиеся в них объекты);
2) Policy Management (декларативные политики, фасеты, условия, подписки на применение политик и т.д.;
3) Registration (группы серверов, сгруппированных в группы для нужд администрирования, как они видятся в SQL Management Studio -> View -> Registered Servers;
4) Data Collection (сбор данных по производительности.
Традиционно наиболее часто используется 1-е направление, хотя, конечно, зависит от задач. Перечисление экземпляров SQL Server, установленных на машине VistaX86SQL2008:
dir SQLSERVER:\SQL\VistaX86SQL2008.
Для экземпляра доступны традиционные объекты уровня сервера, как они видятся в иерархическом дереве Object Explorer в SSMS (см.рис.7)
dir SQLSERVER:\SQL\VISTAX86SQL2008\Default
Список всех баз
dir SQLSERVER:\SQL\VISTAX86SQL2008\Default\databases
Список объектов внутри базы, как он видится в Object Explorer в SSMS
dir SQLSERVER:\SQL\VISTAX86SQL2008\Default\databases\Northwind
В частности, вот таблицы:
dir SQLSERVER:\SQL\VISTAX86SQL2008\Default\databases\Northwind\Tables
Аналогично, для таблицы
dir SQLSERVER:\SQL\VISTAX86SQL2008\Default\databases\Northwind\Tables\dbo.Customers
и т.д. Вытаскивать подобным образом записи из таблицы на стадии СТР-тестирования было можно, потом, видимо, одумались. Администратор, на которого в первую очередь рассчитан данный инструмент, при всем уважении, не является разработчиком, т.к. имеет перед собой несколько иной круг задач, и с него станется с голубых глаз написать dir таблица из какой-нибудь здоровой таблицы с миллиардом строк. А ведь dir таблица это даже не select, это намного хуже. По аналогии с dir SQLSERVER:\SQL\VISTAX86SQL2008\Default\databases\Northwind\Tables | Get-Member, из которого видно, что таблица является объектом класса Microsoft.SqlServer.Management.Smo.Table мы бы получили миллиард каких-нибудь System.Data.Row, точнее, у нас бы память кончилась раньше, чем мы их получили. Вообще администраторы – это программеры, чье развитие затормозилось в самом начале на командных файлах, и все, что выходит за границы del, cd, dir, тыр, пыр, они не воспринимают. Поэтому они очень любят PowerShell за то, что он им позволяет почувствовать себя разработчиком, и при этом Visual Studio открывать не надо. Примеры на использование провайдера для SQL Server, можно посмотреть здесь - https://msdn.microsoft.com/ru-ru/library/cc281947.aspx.
Из отнятой функциональности – невозможность добавлять другие провайдеры и командлеты, как в обычный PowerShell. Таким образом, эта оболочка не является полноценным PowerShell'ом. Если на той же машине открыть полноценный PowerShell, можно видеть, что он по-прежнему не догадывается о существовании провайдера для SQL Server. Как добавить провайдера SQL Server в обычный PowerShell, разбирается в BOL (https://msdn.microsoft.com/ru-ru/library/cc281962.aspx). Я предлагаю рассмотреть чуточку более практический сценарий – как установить PowerShellьный провайдер для SQL Server на машину, где нет вообще ничего от SQL Server. Предположим, есть выделенная машина, с которой периодически запускаются административные скрипты по различным серверам в организации – по SQL Serverам, Exchang'ам, IISам, SharePointам и т.д. Что теперь на нее их всех устанавливать?