Header RSS-подписка на обновления сайта eMail-подписка на обновления сайта

Теоретические основы конкурентного доступа к данным. Часть 2/2.













  • Другие части статьи:
  • 1
  • 2
  • вперед »




Уровни изоляций транзакций против артефактов конкурентного доступа.

Итак, мы готовы посмотреть как вся та теория что излагалась на протяжении первой части статьи работает на практике. Да и работает ли она вообще? Надо бы убедиться самолично...

Кратко вспомним что у на есть «на руках». На руках мы имеем группу артефактов:

  • потерянное обновление (в вариантах A и B)
  • «грязное» чтение
  • неповторяющееся чтение
  • фантомное чтение
  • и двойное/пропущенное чтение

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

Читать полностью...

Теоретические основы конкурентного доступа к данным. Часть 1/2.









Добрый день, уважаемые читатели блога! Месяца полтора назад статьей To NULL or NOT to NULL? автор начал эксперимент по переводу своего персонального «SQL-FAQ» написанного в основном в стиле «заметки на полях», в аккуратные и полновесные статьи блога. Судя по вашим комментариям и письмам данная инициатива пришлась вам по душе, и заслуживает быть продолженной. Сегодняшней статьей автор начинает «причесывание» довольно многочисленных и весьма разрозненных заметок упомянутого «SQL-FAQ» объединенных общей темой «транзакции и параллелизм». Под параллелизмом, определимся сразу, понимается ситуация когда за доступ к одной и той же строке (набору строк) одной и той же таблицы «сражаются» два (и более) пользователя. Нет, понятно, что никаких выхватываний шпаг, срывания плащей и прочей мушкетерской романтики такое «сражение» не предполагает. :lol: Просто сталкиваются две (и более) транзакции, запущенные этими пользователями, и происходит решение вопроса кто будет первым, а кто — подождет. То есть случается процесс который известен большинству под кодовым названием «конкурентный доступ к данным».

Читать полностью...

Параметризация запросов. Ваш злейший враг? Часть 2/2.









  • Другие части статьи:
  • 1
  • 2
  • вперед »




Способы противодействия параметризации.

Итак, как вы уже поняли, сейчас нам предстоит изучить несколько «контр-параметризационных» методик. Обратите внимание, что на них можно смотреть и с обратной стороны — если целевая колонка фильтрации имеет хорошее и равномерное распределение данных, и, как следствие, вы ни разу не против параметризации а очень даже за нее, то вам следует всеми силами избегать упоминаемых далее приемов. Ведь они «рубят» параметризацию не задаваясь вопросом о ее уместности в данных и конкретных обстоятельствах. Так что все как обычно: решение принимаем мы, движок сервера его послушно исполняет.

Применение локальных переменных для передачи значения параметра.

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

Читать полностью...

Параметризация запросов. Ваш злейший враг? Часть 1/2.









Итак, блог sqlCMD.ru продолжает цикл публикаций посвященный такой непростой теме, как параметризация запросов. В статье открывающей данный цикл, Параметризация запросов. Ваш лучший друг? мы выяснили что грамотно и к месту примененный данный механизм способен дать выигрыш в итоговой производительности решения столь значительный, что даже подтвержденный сухими цифрами «до» и «после» он все-равно продолжает выглядеть сказочно-невероятным. Были указали и причины такой «сказочности»: анализ запроса, построение нескольких альтернативных планов исполнения для него, выбор из этих возможных кандидатов «лучшего из лучших» — все это чрезвычайно ресурсоемкие задачи, и даже для современных серверов с их мультипроцессорными «фишками». А поэтому пропуск этих задач целиком дает такой прирост в скорости выполнения запроса, какой невозможно обеспечить никаким наращиванием железа (мы, разумеется, говорим о потенциальном увеличении числа/качества CPU сервера; вложения в, допустим, апгрейд дисковой подсистемы помочь именно в вопросах быстрейшей оптимизации запросов не могут никак просто по определению). Так вот чем покупать коробку новых/дополнительных CPU и загружать их работой, выгоднее (с любой точки зрения) не покупать ничего, а воспользоваться работой уже готовой, в смысле результатами такой предварительной работы. Именно так и поступает параметризация, значительно повышая наши (и наших пользователей) шансы взять «готовую работу» из кэша планов (plan cache), вместо осуществления полной и очень трудоемкой цепочки, где первым звеном является запрос на языке T-SQL, а звеном финальным — идеальный (или близкий к таковому) план исполнения, помещаемый, к слову сказать, опять же в тот же самый кэш планов.

Читать полностью...

To NULL or NOT to NULL? К вопросу о троичной логике. Часть 2/2.









  • Другие части статьи:
  • 1
  • 2
  • вперед »




UNKNOWN и различные конструкции языка T-SQL.

Итак, в основном разделе статьи мы рассмотрим вопрос: как различные элементы языка T-SQL «выкручиваются» обходя этот «неудобный» результат UNKNOWN и подменяя его то FALSE, то TRUE, а то и оставляя его «как есть». Делают они это подчас способами столь изощренными, что просто диву даешься. Ну а про то, что многообразие этих способов вносит ту самую «свежую струю» в жизнь SQL-специалистов мы уже говорили, давайте ближе к конкретике.

Для всех практических примеров данного раздела базовый скрипт один и тот же:

Читать полностью...

To NULL or NOT to NULL? К вопросу о троичной логике. Часть 1/2.









Здравствуйте уважаемые читатели блога sqlCMD.ru, постоянные и новые — автор блога рад новой встрече с вами. Наступивший сентябрь вызвал традиционный всплеск активности посетителей блога — писем и комментариев стало больше в разы. По всему видно — вновь наступила пора работы/учебы. :) Как обычно, вся эта активность служит автору отличным индикатором интереса и подсказывает ему какую тему следует осветить в первую очередь. Однако конкретно в данном случае ваш автор решился на довольно смелый эксперимент.

Дело в том, что достаточно давно, если и не на самой заре своей IT-карьеры то определенно где-то в тех числах, :) автор принялся вести этакий «внутренний SQL Server FAQ», а проще говоря текстовый файл, куда он записывал непонятные ему вопросы, мысли, идеи имеющие отношение к SQL Server. Потом непонятные вопросы дополнялись понятными ответами, и вот так составился довольно внушительный FAQ имеющий в настоящее время объем в несколько мегабайт, притом что его формат как был так и остался чисто текстовым, без единой иллюстрации. Так вот смелый эксперимент заключается в том, что, как подумалось автору, куски этого FAQ можно без проблем «конвертировать» в статьи блога. Ведь если тот или иной вопрос был интересен лично мне, и/или был в свое время до конца мне непонятен, то, с большой степенью вероятности можно предположить, что в той же ситуации оказались/окажутся несколько (десятков? сотен? — кто знает...) читателей блога. Которые с радостью прочтут готовый ответ на этот самый мучающий их вопрос. Поэтому автор и решил вырезать наиболее интересные места своего персонального FAQ, «причесывать» их, существенно дополнять поясняющим текстом/иллюстрациями/кодом T-SQL и в таком переработанном виде выкладывать на сайт. Что из того получится покажет время и, конечно же, ваши отзывы. Разумеется, статьи «по письмам читателей» так же будут продолжать создаваться, и более того, одна из них уже готова в черновике. Переложение FAQ просто станет еще одним и, как видится автору, довольно многообещающим способом поделиться накопленными знаниями/опытом со своими читателями.

Читать полностью...

Параметризация запросов. Ваш лучший друг? Часть 3/3.









  • Другие части статьи:
  • 1
  • 2
  • 3
  • вперед »




Параметризация ручная, с помощью sp_executesql.

Теперь давайте рассмотрим принципиально иной подход к параметризации, а именно ее ручную разновидность. Существует три пути реализовать такой подход и мы рассмотрим их последовательно, каждый в своем собственном разделе. Если ваша тестовая база продолжает находится в режиме принудительной параметризации переведите ее вновь в простой режим:

1
ALTER DATABASE [~DB~] SET PARAMETERIZATION SIMPLE

Заодно проверьте, что индекс iT1 находится во включенном состоянии:

1
ALTER INDEX iT1 ON T1 REBUILD
Читать полностью...

Параметризация запросов. Ваш лучший друг? Часть 2/3.













Параметризация автоматическая, простая.

Собственно, как было отмечено во вступлении, не менее 90% реальных систем (а более технически корректно будет сказать — баз данных, ибо данная опция устанавливается именно на уровне БД) счастливо пребывают именно в этом состоянии — простой авто-параметризации. Наша тестовая база [~DB~] благодаря строке

1
ALTER DATABASE [~DB~] SET PARAMETERIZATION SIMPLE

в скрипте ее создания так же в данный момент относится к указанной и многочисленной когорте. Как работает процесс параметризации при такой опции мы, по сути, уже видели в вводной части статьи — при наличии возможности литеральная часть текста запроса заменяется параметрами, создается план для этой «переоформленной» версии запроса, а сами литералы (то есть их конкретные значения) остаются только в shell-планах. Характерной же особенностью работы авто-параметризации в этом режиме является тот факт, что с точки зрения оптимизатора обстоятельства благоприятные для ее включения (то есть для реального выполнения процесса параметризации) складываются редко, если не сказать чрезвычайно редко. То есть, если запрос, потенциально могущий быть параметризированным, содержит в своем тексте:

Читать полностью...

Параметризация запросов. Ваш лучший друг? Часть 1/3.









Добрый день, уважаемые читатели блога sqlCMD.ru. Читая ваши вопросы и отзывы, приходящие в изрядном количестве после каждой новой публикации, автор получает богатый материал по поиску тех SQL-вопросов, которые вполне заслуживают отдельной статьи, если не цикла. Если просьба «описать тему X» повторяется регулярно, и если по ней же систематически задают вопросы слушатели SQL-курсов читаемых тем же автором, сомнений нет — «тема животрепещет», как выражается один из заезженных журналистских штампов. Одну из таких «горячих», с точки зрения автора, тем мы с вами сегодня и разберем. Ну, то есть как — разберем, но ровно наполовину. А все потому, что вопрос параметризации запросов (а речь, как вы уже догадались, пойдет именно о ней) зело обширен, многогранен и полон внутренних противоречий. Сложная в общем тема, чего уж там скрывать. А потому, для лучшего и постепенного восприятия материала будет разумно выбрать формат именно цикла статей, и в начальной стадии (то есть в рамках статьи текущей) рассмотреть «светлые стороны» указанного непростого процесса. Стороны же отрицательные, как и борьба с оными, остаются для будущих статей цикла.

Читать полностью...

Нужен ли нам сервис SQL Server Browser? Часть 3/3.









  • Другие части статьи:
  • 1
  • 2
  • 3
  • вперед »




SQL Browser и именованный экземпляр.

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

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

Вновь начнем с того, что отключим изучаемый нами сервис SQL Browser, а сервис именованного экземпляра (напомню, что на машине автора его имя MSSQL2) напротив — включим. Настройка тест-клиента очевидна:

1
2
3
const string instName="MSSQL2";
const string ipNum="192.168.81.3";
const int portNum=0;

Запускаем, читаем ожидаемое:

Читать полностью...