SQLClub

SQL Server и ETW. Ч.4

alexejs — Mon, 07 Sep 2009 09:08:00 GMT

Для полноты картины стоит коснуться потребителя ETW-событий. Потребитель - это приложение, которое читает логи, созданные в ходе ETW-сессии, или цепляется к ней напрямую и потребляет генерируемые ей события в реальном времени. Консьюмить залоггированую трассу неинтересно. Не буду отвлекать на увлекательный рассказ про парсинг csv или xml или еще какого-нибудь формата. Какие-то потуги в этом направлении предпринимались во второй серии, Скрипты 1-3. Примером потребителя реального времени явлется всем хорошо известный Windows Event Viewer. Подобных приложений можно написать сколько угодно, каждое для своей области. Скажем, Performance Profiling Tools for WPF.

Рис.1

Real-time провайдером может выступать утилита tracerpt, которую мы использовали для преобразования etl в читабельные форматы (см. первая серия, Рис.8, 9). Стартуем сессию сбора событий из SQL Trace (вторая серия, Скрипт 7), направив вывод не в etl-файл, а в real-time (ключ -rt):

logman start SqlDataCollector -ets -rt -p "MSSQLServer Trace" 0 0

Рис.2

Видим среди запущенных ETW-сессий сессию по имени SqlDataCollector, которая стримит свои рез-ты в real-time. Tracerpt может подключиться к этой сессии, улавливать ее выходной стрим и направить его непосредственно в какой-либо читабельный формат:

tracerpt -rt SqlDataCollector -o c:\Temp\SqlDataCollector.xml -of XML

Рис.3

Образуется файл c:\Temp\SqlDataCollector.xml, который будет прирастать по мере поступления событий. Все время сбора он будет занят, открыть и прочесть его удастся по остановке (logman stop) сессии SqlDataCollector.

Написание собственного потребителя реального времени находится не слишком в струе светлых идей популяризации и продвижения .NET. Если провайдера ETW худо-бедно можно изобразить .NET-средствами, как мы видели в предыдущем посте, до потребителя managed world еще, увы, не добрался. Например, вот примерный пример примеривания потребителя применительно к событиям IIS.

Разумеется, со временем нашлись добрые люди, написавшие .NET-обертку вокруг native API и Сшных вызовов, чтобы потреблять события ETWшной сессии из VB.NET и С#. Образцы народного творчества можно найти в блогах и на кодплексе. Словом, интеграция ETW c .NET здесь на том же уровне, что и при создании провайдера на основе манифеста. Наверное, в .NET когда-нибудь появится нормальная поддержка ETW, поскольку это актуальная перспективная технология integrated throughout Windows, offering higher performance, flexibility, zero-config tracing and a lot of other advantages.

SQL Server и ETW. Ч.3

alexejs — Sun, 06 Sep 2009 06:28:00 GMT

В конце первой серии говорилось, что, начиная с Висты, в ETW поддерживается мультиплексирование. Это очень позитивное нововведение, которым мы сейчас конкретно займемся. Еще в посте про SQL Profiler я говорил о ценности консолидированной картины мира, когда мы сводили воедино профайлерную трассу с графиками Performance Monitor. Продолжу развивать эту мысль. Ясно, что настройка и отладка сложного многокомпонентного приложения - процесс нетривиальный. Он становится еще нетривиальней, если каждая компонента пишет информацию о ходе своей работы в собственный журнал, и эти журналы затем приходится состыковывать, чтобы понять последовательность действий в общем масштабе приложения: чем занималась компонента А, вызвавшая компоненту Б, и компонента Б, вызвавшая компоненту В, прежде чем в компоненте В вылезла какая-нибудь бякость. В особенности если учесть, что А, Б, В могли быть разработаны независимо. Йа нопешу афегительно сложное преложенее, которое обращается к SQL Server, и сведу события от них обоих в единую трассу. В сценарии будут участвовать два ETW-провайдера: штатный SQL Serverный MSSQLServer Trace, который мы посмотрели во второй серии, и самопальный, задачей которого является трассировка кастомного клиентского приложения. Благодаря возможности мультиплексирования они будут шарить одну ETWшную сессию. Для начала стоит изобразить кастомный провайдер.

Программирование контроллера, провайдера и потребителя описывается в документации MSDN. Как говорилось в одном посте, those whose curiosity has been piqued can jump into the MSDN documentation, which is not very good IMO but better than nothing.

Там описываются примеры с использованием native API. Как говорилось в другом посте, The ETW API has been around for a number of years, so it’s implemented in unmanaged code. As I write this, there are no shipping managed libraries to make working with it simpler. Internally, various groups here are looking at the best way to make ETW a first class citizen in the managed world. Это писалось 5 лет назад, и сейчас в графе .NET-поддержка можно ставить галочку. Не слишком жирную, though. Написание своего провайдера обрисовано в посте .NET Event Tracing for Windows от апреля нынешнего года. В нем предлагается следующая последовательность действий. Во-первых, надлежит создать манифест провайдера в виде XML-документа. Апологеты инволюции к иерархическим БД под названием XML в качестве одного из преимуществ приводят его наглядность по сравнению с проприетарными бинарными форматами и самоописательность. Прекрасно, значит, поглядев примеры в %MSSDK%\Samples\WinBase\Eventing, свой манифест они смогут составить самостоятельно. Для всех остальных в %MSSDK%\bin существует тула ecmangen.exe, способная генерить этот манифест. Не зная, что допускается в узлах по правилам игры, от наглядности XML мало прока. С таким же успехом генератор, в который это знание заложено, мог бы производить манифест в бинарном формате. Без разницы, как воплощать это знание: в виде элементов и атрибутов или побайтно отсчитывая с такой-то позиции по такую-то. Хотя нет, XML занимает больше места.

Во-вторых, на основе манифеста при помощи тулы mc.exe (Message Compiler, также входит в SDK) приготовляется 4 файла (временный, .bin, .h, .rc), из которых существенным в данном случае является ресурсный. В-третьих, берется rc.exe (Resource Compiler, также должен лежать в C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin), при помощи которого из .rc файла делается ресурс .res. Ресурс затем вставляется в Project Properties вижуал студийного проекта, что образует класс с именем манифеста, используя который в коде, можно инициализировать и отправлять события. Все просто, если не считать, что .NET здесь несколько притянут за уши. Искреннее отношение человека к данному процессу можно почитать здесь.

Сергей Мелещук в своем блоге (How to do ETW logging from .NET application) приводит другой способ генерации событий из .NET. Он не рассматривает задачи создать произвольный собственный ETW-провайдер с нуля при помощи манифеста и класса System.Diagnostics.Eventing.EventProvider. В System.Diagnostics имеется класс TraceSource, который позволяет писать из приложения сообщения трассировки в разные места. Место определяется абстрактным классом TraceListener, который в .NET 2.0 воплощался в ConsoleTraceListener - вывод отладочных сообщений в консоль, TextWriterTraceListener - в текстовый файл, XmlWriterTraceListener - в XML, EventLogTraceListener - в журнал Windows. В 3.5 к ним добавился EventProviderTraceListener, направляющий отладочные сообщения в ETW. Добавление такого слушателя автоматически создает новый ETW-провайдер, хотя и не позволяет такой полноты контроля над его обликом, как в первом случае. Я взял за основу пример Сергея и немного его модифицировал применительно к нашему сценарию.

Удалим для чистоты эксперимента созданный в первой серии SqlDataCollector:

Рис.1

Создадим каким-либо способом новый гуид. В моем случае это получился {4E7F098A-3E72-4D5B-9EA3-1B41A83527B0}.

Рис.2

Создадим текстовый файл c:\Temp\SqlDataCollector.cfg, куда напишем следующие две строчки:

"MSSQLServer Trace" 6 0

{4E7F098A-3E72-4D5B-9EA3-1B41A83527B0}

Рис.3

где вторая есть свежесозданный гуид.

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

logman create trace AppDataCollector -o c:\Temp\SqlDataCollector.etl -pf c:\Temp\SqlDataCollector.cfg -ow --v

Скрипт 1

Logman create trace создает новый коллектор данных на основе одного или нескольких провайдеров данных. По условию задачи у нас должно быть два провайдера: MSSQLServer Trace и самопальный, пишущих в один файл. Если создавать два коллектора

logman create trace Коллектор1 -o c:\Temp\SqlDataCollector.etl -р Провайдер1

logman start Коллектор1

logman create trace Коллектор2 -o c:\Temp\SqlDataCollector.etl -р Провайдер2

logman start Коллектор2

при старте второго возникнет ошибка, что файл занят, следовательно, нужно их сводить в один коллектор. Ключ -р, как можно посмотреть в logman create trace /?, позволяет задать только одного провайдера - A single Event Trace provider to enable. В случае нескольких их нужно прописывать в отдельном файле, который передается в ключе -pf. В нашем случае это c:\Temp\SqlDataCollector.cfg (Рис.3). Первая строчка инициализирует провайдер MSSQLServer Trace. Мы ее уже видели во второй серии (Скрипт 7). Вторая соответствует самопальному провайдеру. С ним дело обстоит чуть хитрее. В примере Сергея используется класс EventProviderTraceListener. Как говорится в документации, конструктор EventProviderTraceListener инициализирует новый экземпляр класса с помощью указанного идентификатора поставщика. Где ж его взять, коли поставщик еще не создан? Команда logman create trace ... -р Провайдер будет ругаться, если ей указать имя несуществующего провайдера. К счастью, если вместо имени подсунуть гуид, она поверит взаймы, что такой есть. Это может быть совершенно произвольный гуид. На рис.3 он передается во второй строчке. Ключ -ow говорит перезаписывать файл c:\Temp\SqlDataCollector.etl, ежели таковой уже имеется. Ключ --v отменяет действие ключа -v, чтобы файл выхлопа был один. Иначе он будет создавать SqlDataCollector_000001.etl, SqlDataCollector_000002.etl и т.д. Пускаем сессию сбора данных для свежесозданного коллектора

logman start AppDataCollector

Скрипт 2

и выполняем следующее консольное приложение.

using System;

using System.Diagnostics;

using System.Diagnostics.Eventing;

using System.Data.SqlClient;

class Program

{

private static Guid etwProviderId = new Guid("{4E7F098A-3E72-4D5B-9EA3-1B41A83527B0}");

private static string etwProviderName = "AppDataCollector";

static void Main(string[] args)

{

EventProviderTraceListener etwListener = new EventProviderTraceListener(etwProviderId.ToString(), etwProviderName);

TraceSource ts = new TraceSource(etwProviderName, SourceLevels.All);

ts.Listeners.Clear();

ts.Listeners.Add(etwListener);

ts.TraceEvent(TraceEventType.Information | TraceEventType.Start, 0, "Поехали");

ts.TraceData(TraceEventType.Verbose, 0, String.Format("Здравствуйте. Я - приложение {0}", System.Reflection.Assembly.GetEntryAssembly().Location));

SqlConnection cnn = new SqlConnection("server=localhost;database=TestFS;trusted_connection=true"); cnn.Open();

SqlCommand cmd = new SqlCommand("exec sp_trace_generateevent @eventid = 82, @userinfo = N'Пользовательское событие №0', @userdata = 0x12345", cnn);

ts.TraceData(TraceEventType.Verbose, 0, String.Format("Отправляю на SQL Server команду {0}", cmd.CommandText));

cmd.ExecuteNonQuery();

ts.TraceInformation("И смотрю, что из этого получилось");

cnn.Close(); ts.Close();

}

Скрипт 3

Это одновременно будет обращающийся к SQL Server клиент и сам себе режиссер, то есть ETW-провайдер. Все свои действия он протоколирует, посылая их в TraceSource. К любому TraceSource по умолчанию подстегивается консольный слушатель, нам он неинтересен, отсюда ts.Listeners.Clear(). Вместо него добавляется EventProviderTraceListener, отсылающий трассировку ETW-провайдеру, которого он сам же и создает. Единственно, мы говорим, чтобы он создал его с определенным гуидом, тем самым, который нам поверил в долг логман. Обращаю внимание, что это может быть совершенно произвольный гуид, потому что некоторые упорно выбирают {E13C0D23-CCBC-4E12-931B-D9CC2EEE27E4} (провайдер .NET Common Language Runtime). Не буду отвлекаться на рассказ про методы TraceEvent, TraceData и TraceInformation. Можно посмотреть в документации или в совершенно замечательном .NET Instrumentation Workshop. TraceSource отправляет информацию с этих методов привязанным к нему слушателям, то есть в данном случае ETW-провайдеру с гуидом {4E7F098A-3E72-4D5B-9EA3-1B41A83527B0}. Затем на SQL Server отправляется запрос. Это Скрипт 8 из предыдущей серии. Как и в прошлый раз, SQL Server на него реагирует, отправляя событие своему провайдеру MSSQLServer Trace. Оба провайдера: и MSSQLServer Trace, и самопальный {4E7F098A-3E72-4D5B-9EA3-1B41A83527B0}, - завязаны в данном случае на одну сессию:

Рис.4

которая кидает сообщения в c:\Temp\SqlDataCollector.etl (см. Скрипт 1). Туда же после реакции SQL Server падает заключительное TraceInformation от приложения. В итоге имеем объединенный трейс-лог, что и требовалось продемонстрировать. Останавливаем сессию, конвертируем etl и смотрим:

logman stop AppDataCollector

tracerpt C:\Temp\SqlDataCollector.etl -lr -o C:\Temp\SqlDataCollector.xml

Скрипт 4

Рис.5

Рис.6

SQL Server и ETW. Ч.2

alexejs — Fri, 04 Sep 2009 23:05:00 GMT

В предыдущем посте мы разбирали структуру ETW-события и выяснили, что даже в более или менее стандартном по структуре заголовке имеется лишь несколько полей, заполняющихся автоматически, и несколько наборов предопределенных значений для некоторых других полей. Все остальное отдано на откуп провайдерам, в результате чего творится полный бардак. Четких правил, регламентирующих категоризацию событий, в природе нет, и каждый провайдер изгаляется, кто во что горазд. Один может определить одно родовое событие, которое он дальше дробит на таски, опкоды и прочие ключевые слова, повышая уровень детализации события. Другой может не заморачиваться, а просто заводить на каждую деталь по событию. Также возможна масса промежуточных стадий помешательства. Глядя на " SQL Server и ETW. Ч.1"\Рис.9, можно видеть, что ETW-провайдер MSSQLSERVER Trace является сторонником капитального сноса крыши. Загрузим представленный XML в SQL Server:

declare @x xml = (select BulkColumn from openrowset(bulk 'c:\Temp\SqlDataCollector.xml', SINGLE_CLOB) t)

;with xmlnamespaces('http://schemas.microsoft.com/win/2004/08/events/event' as e, 'http://schemas.microsoft.com/win/2004/08/events/trace' as t)

select

x.value('(e:System/e:Provider/@Guid)[1]', 'uniqueidentifier') as ProviderGuid,

x.value('(e:RenderingInfo/t:EventName)[1]', 'nvarchar(255)') as EventName,

x.value('(t:ExtendedTracingInfo/t:EventGuid)[1]', 'uniqueidentifier') as EventGuid

from @x.nodes('Events/e:Event') t(x)

Скрипт 1

Рис.1

чтобы выяснить, а) может ли одному профайлерному событию соответствовать несколько ETWшных и б) чем ProviderGuid отличается от EventGuid'a? Кстати, заодно пример совмещения with xmlnamespaces() и with cte (), которое иногда вызывает затруднения.

...

;with xmlnamespaces('http://schemas.microsoft.com/win/2004/08/events/event' as e, 'http://schemas.microsoft.com/win/2004/08/events/trace' as t),

cte as (

select

x.value('(e:System/e:Provider/@Guid)[1]', 'uniqueidentifier') as ProviderGuid,

x.value('(e:RenderingInfo/t:EventName)[1]', 'nvarchar(255)') as EventName,

x.value('(t:ExtendedTracingInfo/t:EventGuid)[1]', 'uniqueidentifier') as EventGuid

from @x.nodes('Events/e:Event') t(x)

)

select count(distinct ProviderGuid), count(distinct EventGuid), eventname from cte group by eventname

-------------------------

1 1 Audit Login

1 1 Audit Logout

1 1 EventTrace

1 1 RPC:Completed

1 1 SQL:BatchCompleted

Скрипт 2

Видим, что а) по-видимому, не может.

...

select * from cte where ProviderGuid <> EventGuid

----------------

ProviderGuid EventName EventGuid

9E814AAD-3204-11D2-9A82-006008A86939 EventTrace 68FDD900-4A3E-11D1-84F4-0000F80464E3

Скрипт 3

и б) практически, ничем.

Всякий раз специфика области, для которой писан провайдер, и его изрядная степень свободы приводят к тому, что автор провайдера должен добротно документировать изрекаемые им сообщения, иначе в них будет проблематично разобраться. Пример хорошо документированных провайдеров и форматов их сообщений можно, например, наблюдать здесь - .NET Framework 4 CLR ETW Events. В случае MSSQLSERVER Trace благодаря паре несложных запросов и знакомству с SQL Trace структура сообщения приобретает более-менее ясность. Все равно, глядя на Рис.9 в предыдущей серии, задаешься вопросом: какие именно профайлерные события собирает провайдер MSSQLSERVER Trace, неужто все? Какие колонки по каждому событию, тоже все автоматом? Можно ли ставить фильтры на события в зависимости от значения той или иной колонки, как в профайлере? В Books On-Line искать на них ответ, по обыкновению, бестолку. Лучше обратиться к блогу "Tips, Tricks, and Advice from the SQL Server Query Processing Team".

События, информацию по которым MSSQLSERVER Trace засылает в ETW, перечислены в файле %ProgramFiles%\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\etwcnf.xml в шаблонах:

Рис.2

Здесь <Event id=...> - это идентификаторы профайлерных событий. Понять, что какой значит, можно, обратившись к посту "Программно сгенерить трассу профайлера. Ч. 1, 2"\Скрипт 3.

По умолчанию она берет список событий из template c id = 0. Вот эти события:

select * from sys.trace_events where trace_event_id in (10, 12, 14, 15, 17)

----------------------------------

trace_event_id category_id name

10 11 RPC:Completed

12 13 SQL:BatchCompleted

14 8 Audit Login

15 8 Audit Logout

17 10 ExistingConnection

Скрипт 4

Что совпадает со списком событий Скрипт 2, когда трасса была запущена из Reliability and Performance Monitor.

Какие колонки брать по каждому ивенту, оговаривается в файле %ProgramFiles%\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\etwcls.mof:

Рис.3

Как в MSSQLSERVER Trace фильтровать события по типу "Программно сгенерить трассу профайлера. Ч. 1, 2"\(Рис.4 или Скрипт 4), я не нашел. Зато я знаю, как ему подсунуть произвольный шаблон из Рис.2. Создадим в etwcnf.xml еще один шаблон. Этот шаблон будет соостоять из всего одного профайлерного события UserConfigurable:0. UserConfigurable-события хороши тем, что с ними не нужно ждать милостей от природы. Можно их вызывать по своему усмотрению.

...

</Template>

</EventConfiguration>

Скрипт 5

Запускаем ETW-сессию вручную из-за того, что я не знаю, как ей подсунуть параметр -p (или -pf) в случае запуска из-под Reliability and Performance Monitor.

logman start SqlDataCollector -ets -o c:\Temp\SqlDataCollector.etl -p "MSSQLServer Trace" 6 0

Скрипт 7

Параметры логмана можно посмотреть на технете. -ets : создает и стартует сессию event trace session с опциями в командной строке. -о : выходной файл. Несмотря на то, что у коллектора по имени SqlDataCollector, созданного в Reliability and Performance Monitor, выходной файл был прописан - см. предыдущий пост\Рис.7, при ручном запуске она на него не обращает внимания и создает в той директории, откуда был запущен логман, если не указать явно. -p { GUID | provider [( flags [ ,flags ... ])] Level ] | -pf { FileName } : Specifies the providers (trace data collectors) to use for trace data collection... Use the -pf option to list multiple providers. The -pf option identifies the input file containing the provider names. The provider names are enclosed by quotation marks (""), or with GUIDs enclosed by braces, flag masks, and integers (enable level). The flags are either in hexadecimal (OXFFFF) or (flag, flag) format. "MSSQLServer Trace" - это название ETW-провайдера. 6 - id только что созданного темплейта в etwcnf.xml. 0 - запустить.

Если выглянуть из командной строки в Reliability and Performance Monitor, можно заметить, что SqlDataCollector в списке сессий (предыдущий пост\Рис.6) перешел из состояния Stopped в состояние Running.

Чтобы не открывать SSMS, оттуда же из командной строки инициируем событие 82, чтобы MSSQLSERVER Trace его поймал и заслал в ETW:

sqlcmd -S (local) -E -Q "exec sp_trace_generateevent @eventid = 82, @userinfo = N'Пользовательское событие №0', @userdata = 0x12345"

Скрипт 8

Стопим сессию:

logman stop SqlDataCollector -ets

Скрипт 9

Превращаем c:\Temp\SqlDataCollector.etl в читабельный формат - см. предыдущий пост\Рис.9.

Рис.4

Рис.5

Мы видим, что, помимо традиционной шапки в виде первого события EventTrace, теперь файл содержит только одно событие, и оно соответствует SQL Trace'ному событию №82. Это действительно результат Скрипта 8, в чем можно убедиться по элементам <EventData>\<TextData> и <BinaryData>.

В следующей серии мы напишем своего ETW-провайдера, которого попытаемся поженить с SQL Serverным. Stay tuned.

SQL Server и ETW. Ч.1

alexejs — Fri, 04 Sep 2009 20:17:00 GMT

Вначале небольшая вводная на тему ETW, чтобы не получилось, как здесь - http://bytes.com/topic/net/answers/405066-what-windows-event-trace-windows-event-tracing.

Классической статьей по ETW служит http://msdn.microsoft.com/ru-ru/magazine/cc163437.aspx.

Event Tracing for Windows (ETW) является базовым унифицированным механизмом трассировки событий в Windows. По сути, ETW - это однонаправленный пакетный ввод/вывод, предназначенный для журналирования. Под журналирование на уровне каждого процессора отводятся буфера, которые скидываются на диск в асинхронном режиме специальным потоком. Эти операции выполняются в режиме ядра, и оттого занимают копейки в сравнении с, допустим, fprintf(). Даже на древних пентиумах ETW с темпом 20 тыс. событий в секунду сажала процессор не более, чем на 5%. Механизм реализован на уровне ядра; использовать его, т.е. производить события и потреблять их могут как драйверы ядра, так и пользовательские приложения. Данные о событии могут иметь какую угодно структуру на усмотрение приложения, его производящего, т.е. это просто блок бинарщины. Однако к нему прикрепляется заголовок со служебной и идентифицирующей информацией, которую мы посмотрим ниже на примере Рис.9.

Провайдер событий - это dll или ехе, которая их производит, - потребитель, соответственно, тот, кто потребляет. Список зарегистрированных провайдеров можно посмотреть при помощи утилиты командной строки logman:

logman -query providers

Рис.1

Либо можно пойти в Administrative Tools \ Reliability and Performance Monitor (или вызвать в команде Run perfmon.msc) и создать новый пользовательский Data Collector Set

Рис.2

который будет собирать данные из ETW

Рис.3

следующим шагом будет предложено выбрать ETW-провайдера из списка доступных:

Рис.4

Справа высветился тот же список, что и на Рис.1. В списке провайдеров к SQL Server имеют отношение MSSQLSERVER Trace (в случае именованного экземпляра вместо MSSQLSERVER будет стоять имя инстанса - см. пост "Именованый экземпляр по умолчанию"), RsFx0102 Kernel Log (драйвер FileStream), XEvent Package 0 (расширенные события) и др. В данном посте нас будет интересовать первый товарищ. Он просто тупо шлет в ETW все, что происходит в SQL Trace.

Помимо провайдера и потребителя, есть еще контроллер, который управляет этим процессом. Контроллер обращается к ядру с просьбой начать трейс-сессию, создается хэндл (через callback в пользовательском режиме или прерывание в ядерном), контроллер идет к провайдеру и вручает ему этот хэндл. Это называется, он его заенейблил. Чтобы посмотреть активные трейс-сессии, можно написать собственное приложение, а можно это сделать из Reliability and Performance Monitor, выбрав слева Data Collector Sets \ Event Trace Sessions. Можно оттуда же запустить новую сессию. Кликнем правой кнопкой в Event Trace Sessions и выберем New -> Data Collector Set. Откроется диалог создания группы сборщиков податей Рис.2-4. Скажем ей, чтобы результаты своей жизнедеятельности она сохраняла в c:\Temp и чтобы стартовала без проволочек:

Рис.5

У нас появилась новая сессия:

Рис.6

Сразу по открытии сессии провайдер начинает слать события в этот хэндл, а ядро их принимает и рассовывает по буферам. Если буфера заполнились или таймаут проэкспайрился, буфера флушатся в файл .etl, который читает потребитель. Директория для файла задавалась на Рис.5, а имя оговаривается в параметрах трейс-сессии. Там же указываются количество буферов и таймаут. Кликнем два раза по сессии SqlDataCollector:

Рис.7

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

Ну ладно, давайте смотреть, что она насобирала. Остановим сессию SqlDataCollector, выбрав Stop из ее контекстного меню или кликнув на черный квадрат Малевича на Рис.6. Когда контроллер заканчивает сессию, провайдер извещается и прекращает производить события. Файл C:\Temp\SqlDataCollector.etl имеет неудобоваримый формат для чтения. Лучше превратить его во что-нибудь осмысленное, например, csv:

tracerpt -l C:\Temp\SqlDataCollector.etl -of CSV -o C:\Temp\SqlDataCollector.csv

Рис.8

или что-нибудь еще:

tracerpt C:\Temp\SqlDataCollector.etl -lr -o C:\Temp\SqlDataCollector.xml

Рис.9

В элементе <System> находится стандартный заголовок сообщения, структура которого одинакова что для провайдера MSSQLSERVER Trace, что для какого-нибудь еще. Level характеризует строгость и может принимать предопределенные значения 1 - критическое, 2 - ошибка, 3 - предупреждение, 4 - информационное и 5 - подробное. Также ETW-провайдер может определить свои собственные значения до 255. Task и Opcode - категоризация на уровне приложение/метод. Имена туда писать не получится, т.к. под Task выделено два байта, под Opcode - 1. Придется кодировать. Кодировка является усмотрением ETW-провайдера. Предопределенными считаются опкоды 1 - старт и 2 - стоп. Keywords позволяет дальше категоризировать события. Это 56 бит, что может, например, соответствовать маске из 56 категорий событий. В маске взводятся те биты, в какие соответствующие категории попадает событие. Опять-таки категоризация является прерогативой конкретного провайдера. TimeCreated - временная отметка момента происхождения события. Channel используется, в основном, если трасса предназначается для просмотра в Event Viewer; это Application, System и пр., что виднеется в дереве слева под Event Viewer. В элементе <EventData>/<Data> передается полезная нагрузка. Ее структура варьируется в зависимости от провайдера и типа сообщения. В данном случае в ней передается информация о событии SQL Trace. Каждый элемент <DataName> есть, по сути, колонка в профайлере. Само название профайлерного события присутствует в элементе <RenderingInfo>/<EventName>.

ETW существует в Windows, наверное, с версии 2000. Начиная с Висты, поддерживается мультиплексирование, т.е. отношение "многие-ко-многим" между провайдерами и сессиями. Например, этот вывод (Рис.9) можно замикшировать с результатами еще каких-нибудь ETW-провайдеров и получить согласованную по времени целостную картину мира в одном флаконе.

Давайте поправим DRI на parent-child

alexejs — Mon, 31 Aug 2009 12:53:00 GMT

Уважаемые коллеги.

Активный участник нашего SQL Serverного сообщества Александр Григорьевич Бондарь зафайлил на коннекте пожелание исправить поведение декларативной ссылочной целостности в случае, когда таблица связана сама на себя.

Скрипт воспроизведения приводится на https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=470632&wa=wsignin1.0, он не бог весть, какой хитрый, тем не менее я прокомментирую, что называется, на пальцах.

Когда две таблицы связаны отношением первичный-внешний ключ и мы хотим, например, грохнуть какой-нибудь РК из родительской таблицы, возможны, как известно, три поведения: NO ACTION - не пущать, если в дочерней таблице есть записи, ссылающиеся на эту родительскую, CASCADE - удалить ссылающиеся дочерние записи из таблицы внешнего ключа (и далее по каскаду, если у нее, в свою очередь, есть дочерние таблицы), SET NULL/SET DEFAULT - поставить в дочерних записях поле внешнего ключа в NULL или значение по умолчанию, елико сие возможно. Аналогично для обновления.

Все хорошо за исключением случая, когда РК-FK отношение определено на одной таблице. Типичный пример - реализация иерархии, как, допустим, делается в измерении parent-child. Здесь она предлагает ставить только NO ACTION, т.к. боится зацикливания. Какое зацикливание? Что плохого, если, допустим, при удалении родительской записи ставить NULL у нее непосредственных детей, что будет означать, что они осиротели? Я считаю, нам надо поддержать Александра Григорьевича и проголосовать за то, чтобы эту фичу поправили. Никого не собираюсь с пеной у рта агитировать, но если вы считаете так же, просто обращаю внимание, что риквест имеет место быть и можно зайти по вышеприведенной ссылке и кликнуть на правую звездочку, чтобы поднять его рейтинг. Также можно кликнуть рядом на Validation: View or Add и отметить Yes, I am able to validate that this issue occurs, потому что действительно такое поведение наблюдается в том числе в 2008-м; скрипт там имеется, можете проверить.

Сделаем SQL Server лучше.

SMO. CaptureSQL

alexejs — Mon, 31 Aug 2009 09:19:00 GMT

Коль скоро речь зашла о о скриптовании в SMO, стоит отметить еще одну возможность на эту тему под названием CaptureSQL.

Однажды я нарвался на ошибку при создании в SMO CLRной табличной функции. Это приблизительно функция Dir из поста "Как перелOжить файловую папку в базу"\Скрипт 6.

Рис.1

Обычно Inner Exception вносит ясность, информативно сообщая об истинных причинах недовольства. В данном случае UDF просит установить ей свойство TableVariableName. Я, помнится, еще удивился. Табличная переменная имеет смысл для T-SQLной табличной функции:

create function tvf() returns @t table (fld int) as begin insert @t values (1), (2), (3) return end

Здесь мы явно указываем, что функция будет CLRной: f.ImplementationType = Microsoft.SqlServer.Management.Smo.ImplementationType.SqlClr; а CLRной она, вроде как, без надобности. Ну ладно, раз просит, ей виднее. Недолго думая, забабахал ей строчку

f.TableVariableName = "@t";

Скрипт 1

На, подавись ты. Она и подавилась:

Рис.2

Причем, пребывая в состоянии подавленности, она перестала выдавать осмысленные сообщения об ошибках даже в Inner Exception. Наиболее разумные вещи - это An exception occurred while executing a Transact-SQL statement or batch и Incorrect syntax near the keyword 'EXTERNAL'. Хотелось бы понять, что именно в синтаксисе ей не по нутру.

Читатели, которые рискнули потратить время, пролистав пост "Программно сгенерить трассу профайлера. Ч. 1, 2", естественно, воспользуются для этой цели профайлером. Событие User Error Message выводит, по сути, закладку Messages в SSMS. Событие Exception показывает стандартную информацию о номере и строгости ошибки. Событие SQL:BatchStarting содержит вызвавший ее T-SQLный скрипт:

Рис.3

Однако существует увидеть образовавшийся в результате SQLный скрипт средствами SMO, не выходя за пределы Visual Studio. Для этого в код на Рис.2 достаточно добавить две строчки: в начале

srv.ConnectionContext.SqlExecutionModes = Microsoft.SqlServer.Management.Common.SqlExecutionModes.CaptureSql;

Скрипт 2

которая означает, что все SQL-команды, которые SMO будет генерить в результате наших над ним измывательств, он не будет отправлять на сервер, а будет собирать их у себя в виде коллекции строк, которые затем можно посмотреть:

foreach (string s in srv.ConnectionContext.CapturedSql.Text) Debug.WriteLine(s);

Скрипт 3

Рис.4

В случае длинного SQL-скрипта его можно перенести в SSMS и там пройти построчно дебаггером. В данном случае очевидно, что ошибка синтаксиса происходит из-за пресловутой табличной переменной @t, которую все-таки не надо было указывать в случае CLRной функции. Стоит заменить в Скрипте 1 "@t" на пустую строку, все начинает прекрасно работать:

using System;

using System.Collections;

using System.Diagnostics;

using SMO = Microsoft.SqlServer.Management.Smo; //C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SqlServer.Smo.dll

//Также требует references на

//C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SqlServer.ConnectionInfo.dll

//C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SqlServer.Management.Sdk.Sfc.dll

using System.IO;

using System.Data;

class Program

{

static void Main(string[] args)

{

CreateFunctionDir();

}

public static void CreateFunctionDir()

{

SMO.Server srv = new Microsoft.SqlServer.Management.Smo.Server();

srv.ConnectionContext.SqlExecutionModes = Microsoft.SqlServer.Management.Common.SqlExecutionModes.ExecuteAndCaptureSql;

SMO.Database db = srv.Databases["TestFS"];

SMO.SqlAssembly asm = db.Assemblies["MyAssembly"];

SMO.UserDefinedFunction f = new Microsoft.SqlServer.Management.Smo.UserDefinedFunction();

f.Parent = db; f.Name = "Dir";

f.TextMode = false;

f.ImplementationType = Microsoft.SqlServer.Management.Smo.ImplementationType.SqlClr;

f.AssemblyName = asm.Name;

f.ClassName = "FileSystem";

f.MethodName = "Dir_InitMethod";

SMO.UserDefinedFunctionParameter p1 = new Microsoft.SqlServer.Management.Smo.UserDefinedFunctionParameter(f, "@folder", SMO.DataType.NVarChar(266));

f.Parameters.Add(p1);

p1 = new Microsoft.SqlServer.Management.Smo.UserDefinedFunctionParameter(f, "@shallowTraversal", SMO.DataType.Bit);

f.Parameters.Add(p1);

f.FunctionType = Microsoft.SqlServer.Management.Smo.UserDefinedFunctionType.Table;

SMO.Column c = new Microsoft.SqlServer.Management.Smo.Column(f, "ID", SMO.DataType.HierarchyId);

f.Columns.Add(c);

c = new Microsoft.SqlServer.Management.Smo.Column(f, "FullName", SMO.DataType.NVarChar(266));

f.Columns.Add(c);

c = new Microsoft.SqlServer.Management.Smo.Column(f, "DateCreated", SMO.DataType.DateTime2(3));

f.Columns.Add(c);

c = new Microsoft.SqlServer.Management.Smo.Column(f, "DateModified", SMO.DataType.DateTime2(3));

f.Columns.Add(c);

c = new Microsoft.SqlServer.Management.Smo.Column(f, "LastAccessed", SMO.DataType.DateTime2(3));

f.Columns.Add(c);

c = new Microsoft.SqlServer.Management.Smo.Column(f, "Properties", SMO.DataType.Xml(""));

f.Columns.Add(c);

c = new Microsoft.SqlServer.Management.Smo.Column(f, "Size", SMO.DataType.BigInt);

f.Columns.Add(c);

c = new Microsoft.SqlServer.Management.Smo.Column(f, "IsDir", SMO.DataType.Bit);

f.Columns.Add(c);

f.TableVariableName = "";

f.Create();

foreach (string s in srv.ConnectionContext.CapturedSql.Text) Debug.WriteLine(s);

}

Скрипт 4

Это была краткая иллюстрация возможности SMO по захвату SQL. Я пытался измыслить практические сценарии ее использования и не преуспел. Профайлер, как мы видели, позволяет делать все то же самое, плюс он обладает более широким спектром возможностей, т.к. не ограничен одной текущей сессией и T-SQLными событиями. Можно представить ситуацию, когда на предприятии нет выделенного DBA, и администратору приходится отвечать за все: за сервера баз данных, за почтовые сервера, за AD и т.д. Он использует PowerShell как универсальный рабочий инструмент автоматизации своих действий, из которого обращается к каждому из серверов в соответствии с его объектной моделью или WMI и иными административными интерфейсами. Например, SMO в случае SQL Server. Даже если предположить, что ему вдруг понадобилось превратить SMOшный скрипт в SQL, почему не использовать профайлер для перехвата действий, которые вызывает SMO на стороне сервера? Права ALTER TRACE у него по-любому должны иметься. Может быть, отталкиваться от обратной ситуации, когда разработчик не обладает сколь-либо серьезными административными привилегиями на SQL Server, и ему требуется проконтролировать, как в действительности отзовется код, написанный им с помощью SMO, на стороне сервера. С другой стороны, SMO, скорее, административный интерфейс, нежели доступ к данным общего назначения, так что разработчик будет, вероятно, использовать ADO.NET. Словом, если уважаемые читатели располагают убедительным примером, когда профайлер неприменим, а CaptureSQL выручает, давайте обсудим в комментариях.

В SMO имеется возможность скриптования, полезность которой очевидна. Она реализована в классе Microsoft.SqlServer.Management.Smo.Scripter, бегло рассмотренном в предыдущем посте. Речь идет не о захвате того, что происходит на лету, что позволяет делать и профайлер, а об автоматизации кнопки Generate SQL Script, т.е. генерации скриптов ранее созданных объектов. Совершенно замечательной возможностью скриптера является построение дерева зависимостей между объектами. Выполнение этой операции вручную довольно затруднительно.

Sys.sql_expression_dependencies (она же sql_dependencies, она же sysdepends, а также sp_depends, которая лазит по последней) не является исчерпывающим справочником отношений между объектами, т.к. отслеживает весьма ограниченное число типов зависимостей - см. BOL, http://msdn.microsoft.com/ru-ru/library/ms345449.aspx. Кстати, статья примечательна по двум причинам. Во-первых, творческий подход переводчика, переведшего вьюшку как просмотр. Действительно, традиционный перевод как представление уже прискучил. Единственно, ему нужно было определиться и остановиться на каком-нибудь одном варианте, а не терзаться творческими муками в пределах одной статьи. Во-вторых, DMV не отслеживает важных в данном примере зависимостей foreign key и принадлежностей CLRных модулей сборкам:

select object_name(referencing_id), referencing_class_desc, c1.name, referenced_entity_name, c2.name from sys.sql_expression_dependencies d

left join sys.columns c1 on d.referencing_id = c1.object_id and d.referencing_minor_id = c1.column_id

left join sys.columns c2 on d.referenced_id = c2.object_id and d.referenced_minor_id = c2.column_id

(No column name)	referencing_class_desc	name	referenced_entity_name	name
TestFTS	OBJECT_OR_COLUMN	type	GetFileExtension	NULL
TestFTS	OBJECT_OR_COLUMN	type	TestFTS	FullName

Скрипт 5

Показывается зависимость колонки type в таблице TestFTS, которая имеет дефолтное значение dbo.GetFileExtension(FullName) от функции GetFileExtension и от колонки FullName. В то же время не показывается зависимость для таблицы ttt от таблицы TestFTS

create table ttt (id int, fk HierarchyID references TestFTS(id))

которая не даст просто так удалить таблицу TestFTS:

drop table TestFTS

Msg 3726, Level 16, State 1, Line 1

Could not drop object 'TestFTS' because it is referenced by a FOREIGN KEY constraint.

Скрипт 6

Эти зависимости нужно искать в sys.foreign_keys:

select name, object_name(parent_object_id), object_name(referenced_object_id) from sys.foreign_keys

name	(No column name)	(No column name)
FK__ttt__fk__43F60EC8	ttt	TestFTS

Скрипт 7

В sys.sql_expression_dependencies не отражается также зависимость функции GetFileExtension() от сборки MyAssembly. Ее нужно смотреть в sys.assembly_modules:

select a.name, o.name, o.type_desc, am.assembly_class, am.assembly_method from sys.assembly_modules am join sys.assemblies a on am.assembly_id = a.assembly_id join sys.objects o on am.object_id = o.object_id

name	name	type_desc	assembly_class	assembly_method
MyAssembly	Dir	CLR_TABLE_VALUED_FUNCTION	FileSystem	Dir_InitMethod
MyAssembly	SplitPath	CLR_TABLE_VALUED_FUNCTION	FileSystem	SplitPath_InitMethod
MyAssembly	LoadDir	CLR_STORED_PROCEDURE	FileSystem	LoadDirWithFileContent
MyAssembly	GetFileExtension	CLR_SCALAR_FUNCTION	FileSystem	GetFileExtension
MyAssembly1	Main	CLR_STORED_PROCEDURE	Class1	Main

Скрипт 8

Из-за того, что зависимости невозможно получить из единого справочника, а приходится собирать по разным местам, самостоятельное построение дерева зависимостей превращается в нетривиальную задачу. Далее, предположим, это как-то удастся сделать, но это будут голые object_id без скриптов. В зависимости от типа объекта придется сочинять drop table или drop proc или drop function и т.д. В T-SQL нет команды drop object <object_id> (а, наверное, зря). Аналогично, в SMO нету общей коллекции объектов базы, есть по отдельности db.Tables, db.StoredProcedures, db.UserDefinedFunctions и т.д. В зависимости от типа объекта придется ветвить, из какой коллекции мы хотим его дропнуть. К тому же сборки, хоть и создаются внутри базы данных, не имеют object_id и не входят в sys.objects. Object_id имеют процедуры и функции, созданные на основе ее модулей. С использованием возможности SMO CaptureSQL можно получить SQLный скрипт манипуляций над объектами SQL Server, когда последовательность действий над ними известна, то есть известны как сами объекты, так и зависимости между ними. Нижеприведенный скрипт выполняет передеплоймент сборки в явном виде: он удаляет таблицу TestFTS, зависимую от функции GetFileExtension, т.к. использует ее для дефолтного значения одного из своих полей, удаляет саму эту функцию, а также функцию Dir и процедуру LoadDir, удаляет сборку MyAssembly, откуда они берутся, а затем пересоздает их в обратной последовательности и получает SQLный скрипт всего этого безобразия. Я не стал приводить создание таблиц, поскольку пример на таблицы имеется в документации.

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") | Out-Null

cls

$srv = new-object -TypeName "Microsoft.SqlServer.Management.Smo.Server" -ArgumentList ""

$srv.ConnectionContext.SqlExecutionModes = [Microsoft.SqlServer.Management.Common.SqlExecutionModes]::ExecuteAndCaptureSql

$db = $srv.Databases["TestFS"]

#Удаление объектов

$o = $db.Tables["ttt", "dbo"][0]; if ($o -ne $null) { $o.Drop() } #при необходимости можно уточнить схему, но тогда возвращается не единичный объект, а коллекция

$o = $db.Tables["TestFTS"]; if ($o -ne $null) { $o.Drop() }

$o = $db.StoredProcedures["LoadDir"]; if ($o -ne $null) { $o.Drop() }

$o = $db.UserDefinedFunctions["Dir", "dbo"][0]; if ($o -ne $null) { $o.Drop() } #коллекция UserDefinedFunctions содержит все ф-ции - CLR, SQL, скалярные, табличные, ...

$o = $db.UserDefinedFunctions["GetFileExtension"]; if ($o -ne $null) { $o.Drop() }

$o = $db.UserDefinedFunctions["SplitPath"]; if ($o -ne $null) { $o.Drop() }

$o = $db.Assemblies["MyAssembly"]; if ($o -ne $null) { $o.Drop() }

#Создание сборки

$asm = new-object -TypeName "Microsoft.SqlServer.Management.Smo.SqlAssembly"

$asm.Name = "MyAssembly"

$asm.Parent = $db #иначе на след.строчке Exception setting "AssemblySecurityLevel": "You must set Parent property."

$asm.AssemblySecurityLevel = [Microsoft.SqlServer.Management.Smo.AssemblySecurityLevel]::Unrestricted #лежит в microsoft.sqlserver.sqlenum.dll

$asm.Create("C:\Temp\LoadFolderToSQL\bin\Debug\ClassLibrary1.dll")

#Currently, only one file per assembly is supported - http://msdn.microsoft.com/ru-ru/library/microsoft.sqlserver.management.smo.sqlassembly.sqlassemblyfiles.aspx

#Создание CLRной хранимой процедуры

$sp = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.StoredProcedure" -ArgumentList $db, "LoadDir" #аргументы - БД, название процедуры; можно еще указать схему

$sp.TextMode = $false

$sp.ImplementationType = [Microsoft.SqlServer.Management.Smo.ImplementationType]::SqlClr

$sp.AssemblyName = $asm.Name

$sp.ClassName = "FileSystem" #public partial class ... в dll

$sp.MethodName = "LoadDirWithFileContent" #метод, как он называется в библиотеке классов

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.StoredProcedureParameter" -ArgumentList $sp, "@folder", $([Microsoft.SqlServer.Management.Smo.DataType]::NVarChar(255))

$sp.Parameters.Add($o)

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.StoredProcedureParameter" -ArgumentList $sp, "@shallowTraversal", $([Microsoft.SqlServer.Management.Smo.DataType]::Bit)

$sp.Parameters.Add($o)

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.StoredProcedureParameter" -ArgumentList $sp, "@tblName", $([Microsoft.SqlServer.Management.Smo.DataType]::SysName)

$sp.Parameters.Add($o)

$sp.Create()

#Создание CLRной скалярной функции

$f = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.UserDefinedFunction"

$f.Parent = $db; $f.Name = "GetFileExtension"

$f.TextMode = $false

$f.ImplementationType = [Microsoft.SqlServer.Management.Smo.ImplementationType]::SqlClr

$f.AssemblyName = $asm.Name

$f.ClassName = "FileSystem"

$f.MethodName = "GetFileExtension"

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.UserDefinedFunctionParameter"

$o.Name = "@fileName"; $o.Parent = $f; #без этого не даст присвоить DataType параметру

$o.DataType = [Microsoft.SqlServer.Management.Smo.DataType]::NVarChar(266)

$f.Parameters.Add($o)

$f.FunctionType = [Microsoft.SqlServer.Management.Smo.UserDefinedFunctionType]::Scalar

$f.DataType = [Microsoft.SqlServer.Management.Smo.DataType]::NVarChar(5)

$f.Create()

#Создание CLRной TVF

$f = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.UserDefinedFunction" -ArgumentList $db, "Dir"

$f.TextMode = $false

$f.ImplementationType = [Microsoft.SqlServer.Management.Smo.ImplementationType]::SqlClr

$f.AssemblyName = $asm.Name

$f.ClassName = "FileSystem"

$f.MethodName = "Dir_InitMethod"

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.UserDefinedFunctionParameter" -ArgumentList $f, "@folder", $([Microsoft.SqlServer.Management.Smo.DataType]::NVarChar(266))

$f.Parameters.Add($o)

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.UserDefinedFunctionParameter" -ArgumentList $f, "@shallowTraversal", $([Microsoft.SqlServer.Management.Smo.DataType]::Bit)

$f.Parameters.Add($o)

$f.FunctionType = [Microsoft.SqlServer.Management.Smo.UserDefinedFunctionType]::Table

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.Column" -ArgumentList $f, "ID", $([Microsoft.SqlServer.Management.Smo.DataType]::HierarchyId)

$f.Columns.Add($o)

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.Column" -ArgumentList $f, "FullName", $([Microsoft.SqlServer.Management.Smo.DataType]::NVarChar(266))

$f.Columns.Add($o)

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.Column" -ArgumentList $f, "DateCreated", $([Microsoft.SqlServer.Management.Smo.DataType]::DateTime2(3))

$f.Columns.Add($o)

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.Column" -ArgumentList $f, "DateModified", $([Microsoft.SqlServer.Management.Smo.DataType]::DateTime2(3))

$f.Columns.Add($o)

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.Column" -ArgumentList $f, "LastAccessed", $([Microsoft.SqlServer.Management.Smo.DataType]::DateTime2(3))

$f.Columns.Add($o)

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.Column" -ArgumentList $f, "Properties", $([Microsoft.SqlServer.Management.Smo.DataType]::Xml(""))

$f.Columns.Add($o)

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.Column" -ArgumentList $f, "Size", $([Microsoft.SqlServer.Management.Smo.DataType]::BigInt)

$f.Columns.Add($o)

$o = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.Column" -ArgumentList $f, "IsDir", $([Microsoft.SqlServer.Management.Smo.DataType]::Bit)

$f.Columns.Add($o)

$f.TableVariableName = ""

$f.Create()

$srv.ConnectionContext.CapturedSql.Text | %{ Write-Host $_}

Скрипт 9

Рис.5

В случае, когда дерево зависимостей от объекта априорно неизвестно, следует прибегнуть к Microsoft.SqlServer.Management.Smo.DependencyТree, DependencyCollection и кодогенерации DDL средствами скриптера, как показывалось в предыдущем посте.

Автоматический редеплоймент сборки. PS1

alexejs — Wed, 26 Aug 2009 11:14:00 GMT

Я ожидал, что в комментах к предыдущему посту какая-нибудь добрая душа выложит Powershellьный вариант кода, и я с радостью им воспользуюсь, чтобы всякий раз не открывать Visual Studio. Нет, никто не сподобился. Пассивная масса.

Пришлось самому на старости лет засучать рукава и, кряхтя, осваивать PowerShell. Какой забавный язык! (с) граф типа отец Боярского в "Собаке на сене".

Ну, не взыщите. Приведенный ниже скрипт на PowerShell является аналогом сишарпейного кода "Автоматический редеплоймент сборки"\Скрипт 4.

Имеется dll, из которой на SQL Server по имени $srvName в базе $dbName сделана сборка по имени $asmName, а из нее разные процедуры и функции. В dll чего-нибудь поменяли, и сборку нужно передеплоить: убить все ее процедуры и функции, саму сборку, создать ее заново, пересоздать существовавшие на ее основе процедуры и функции. Если от ее процедур и функций успели стать зависимыми еще какие-нибудь объекты, цепочка, соответственно, удлиняется с двух сторон.

Если изменение в dll означало, что из нее удалились или добавились какие-нибудь методы, на основе которых существовали или предстоит создать SQLные модули, $scriptToCreate надо сохранить в файл, сделать возможность его откорректировать и уже потом выполнять.

[reflection.assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo") | Out-Null

function Main()

{

cls

$srvName = ""; $dbName = "TestFS"; $asmName = "MyAssembly"

$srv = new-object -TypeName "Microsoft.SqlServer.Management.Smo.Server" -ArgumentList $srvName

$db = $srv.Databases[$dbName]

$asm = $db.Assemblies[$asmName];

$scr = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.Scripter" -ArgumentList $srv

$scr.Options.SchemaQualify = $true #чтобы объекты скриптовались со своими схемами (dbo, ...)

$scr.Options.IncludeIfNotExists = $true #предваряются оператором if exists при удалении и if not exists при создании

$scr.Options.ScriptDrops = $true #создается скрипт на удаление

$scr.Options.WithDependencies = $true #при генерации скрипта на удаление означает, что в скрипт также включаются referencing objects, т.е. которые зависят от данного

$scr.Options.DriUniqueKeys = $true #таблице TestFTS требуется ограничение unique на rowguidcol, его также нужно заскриптовать

$sb = New-Object -TypeName "System.Text.StringBuilder"

$scr.Script(@($asm)) | ForEach-Object -Process { [Void] $sb.Append($_ + "`n`n") } #[void], чтобы избежать uncaptured output в ф-ции, к-й будет относиться к ее рез-там

$scriptToDrop = $sb.ToString(); $sb.Length = 0

$scr.Options.ScriptDrops = $false #генерируется скрипт на создание

$dt = $scr.DiscoverDependencies(@($asm), $false) #parent = false означает, что под связанными объектами понимаются не родительские, а дочерние, т.е. referencing

$dc = $scr.WalkDependencies($dt) #скрипт получается в порядке от дочерних объектов к родительским, что неправильно, т.к. сначала должен создаваться родительский объект, а уже потом дочерние на его основе

$dc1 = New-Object -TypeName "Microsoft.SqlServer.Management.Smo.DependencyCollection"

for ($i = $dc.Count; $i -gt 0; $i--) { [Void] $dc1.Add($dc[$i - 1]) } #переставляем в обратном порядке

$scr.ScriptWithList($dc1) | ForEach-Object -Process { [void] $sb.Append($_ + "`n`n") } #генерим скрипты от явно построенной коллекции связанных объектов

$scriptToCreate = $sb.ToString();

$scriptToCreate = ReplaceAssemblyBytesToFilePath $scriptToCreate $asm.SqlAssemblyFiles

Write-Host "Вы согласны с тем, что будут выполнены следующие скрипты:`n"

$scriptToDrop

$scriptToCreate

Write-Host "[Y/N]?"

[char] $key = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown").Character

if ($key.ToString().ToUpper() -eq "Y") { $db.ExecuteNonQuery($scriptToDrop); $db.ExecuteNonQuery($scriptToCreate) }

}

#<summary>

#Процедура производит замену в скрипте создания сборки

#create assembly ... from 0x4D5A900003000 ... with permission_set = ...

#бинарщины на пути к файлам этой сборки:

#create assembly ... from 'C:\...\bin\Debug\ClassLibrary1.dll' with permission_set ...

#</summary>

#<param name="scriptToCreate">

#Сгенеренный скрипт создания сборки и, возможно, других объектов.

#Однако предполагается, что в этом скрипте оператор create assembly один.

#В противном случае каждую сборку надо скриптовать отдельно.

#</param>

#<param name="files">Файлы из SqlAssembly.SqlAssemblyFiles</param>

#<returns></returns>

function ReplaceAssemblyBytesToFilePath($scriptToCreate, $files)

{

$pattern = new-object -TypeName "Text.RegularExpressions.Regex" -ArgumentList "create assembly \[\w+\]\r\nauthorization \[\w+\]\r\nfrom ", $([Text.RegularExpressions.RegExOptions]::IgnoreCase)

$match = $pattern.Match($scriptToCreate)

$sb = new-object -TypeName "System.Text.StringBuilder" -ArgumentList $scriptToCreate.Substring(0, $match.Index + $match.Length);

$files | ForEach-Object -Process { [Void] $sb.Append("'"); [Void] $sb.Append($_.Name); [Void] $sb.Append("', "); }

[Void] $sb.Remove($sb.Length - 2, 1) #убираем последнюю запятую (пробел оставляем)

$pattern = new-object -TypeName "Text.RegularExpressions.Regex" -ArgumentList "with permission_set", $([Text.RegularExpressions.RegexOptions]::IgnoreCase)

$match = $pattern.Match($scriptToCreate, $match.Index)

[Void] $sb.Append($scriptToCreate.Substring($match.Index))

return $sb.ToString()

}

Main

Лицензирование SQL Server 2008 х86/х64 и Rus/Eng

alexejs — Tue, 25 Aug 2009 09:46:00 GMT

Коллега обратился с вопросом от партнера. У человека есть лицензия на коммерческую редакцию русского SQL Server 2008 32-бит. Вправе ли он в рамках этой лицензии установить вместо него английский SQL Server 2008 x64 той же редакции?

Я предположил, что да, поскольку:

· Лицензии на SQL Server 2008 не имеют битности в названии.

· Стоимости английской и русской версии равны.

но на всякий случай решил прояснить этот вопрос, обратившись в Licensing Group.

Подтвердили.