| ← Декабрь 2008 → | ||||||
|
1
|
2
|
3
|
4
|
5
|
7
|
|
|---|---|---|---|---|---|---|
|
8
|
9
|
10
|
11
|
12
|
14
|
|
|
15
|
16
|
17
|
18
|
19
|
21
|
|
|
22
|
23
|
24
|
25
|
26
|
28
|
|
|
29
|
30
|
31
|
||||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 221
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)"Выпуск 221 от 20 декабря 2008 г.Новым посетителям сайта Сайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения
состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.
Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 50-й задачи первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов, которые пригодятся на третьем рейтинговом этапе, который начинается после 138 задачи.Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. Новости сайта§ Сделали, наконец, крупные картинки эскизов сертификатов: § На странице движения лидеров теперь выводится и время, которое прошло на текущий момент еще нерешенной, но начатой задачи. § К третьему этапу подошел: § Изменения среди лидеров (решенные за неделю задачи третьего этапа): § Продвинулись в рейтинге: § Новые лица в ТОР 100 и вернувшиеся туда: § Продвижение ближайших претендентов на попадание в ТОР 100: § На этой неделе сертифицированы: § Число подписчиков - 3825 Число участников рейтинга - 20245 Число участников второго этапа - 1636 Число участников третьего этапа - 44 Сертифицировано на сайте - 345 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQLМассивы и списки в SQL Server 2005 (начало в вып.217-220)Erland Sommarskog (оригинал: Arrays and Lists in SQL Server 2005 )Перевод: Моисеенко С.И. На основании вышесказанного может показаться, что встраиваемый (inline) SQL является наиболее предпочтительным, поскольку нет никаких промежуточных таблиц, и оптимизатор имеет полную информацию. К сожалению, последнее не вполне верно. Чтобы оценить лучший способ доступа к другим таблицам в запросе, оптимизатор должен знать: 1) сколько строк будет генерировать входная строка 2) распределение значений. Но оптимизатор не в состоянии сделать это с рассмотренными в этой статье однострочными функциями, поскольку информация спрятана слишком глубоко в логике этих функций. (Имеется одно исключение: динамический SQL, который имеет собственный набор проблем, делает это менее приемлемым способом.) Таким образом, на практике оптимизатор будет применять слепые предположения независимо от того, используете ли Вы встраиваемую однооператорную, непрозрачную однооператорную, многооператорную функцию, или табличную переменную. Так что же тогда не имеет значения, какой способ использовать? О, нет. Слепые предположения различаются для различных однооператорных методов, а если функция использует вспомогательную таблицу чисел, то размер этой таблицы повлияет на слепые предположения. (Поскольку оптимизатор имеет информацию об этой таблице, он в состоянии использовать ее.) И слепые предположения для функций CLR и XML отличаются друг от друга и от встроенных функций T-SQL. Предположения относительно многооператорных функций и табличных переменных, видимо, подобны, но отличаются от методов однооператорных функций. Может оказаться, что слепое предположение для одного метода, уводящее оптимизатор от эффективного плана, будет лучше работать с другим методом. В целом, можно сказать, что встроенные функции T-SQL потенциально дают "более интересные" планы выполнения запросов. Ниже приведена цитата из письма, которое я получил в ответ на мою старую статью для SQL 2000: После чтения вашей статьи 'Arrays and list in SQL server' я пробовал использовать в своем приложении метод Массива Элементов Фиксированной Длины. Все работало прекрасное, пока я не переместил код из пакета клиента в хранимую процедуру. Когда я посмотрел план выполнения запроса, то увидел, что число строк, выбираемых из таблицы Numbers, превышало 61 миллион! Вместо того, чтобы начать с соединения таблицы Numbers с исходной таблицей для фильтрации 500 строк, входящих в массив, план демонстрировал обработку предложения GROUP BY для всей таблицы (121000 строк), а затем использовал метод вложенных циклов (nested loop ) для поиска соответствий с каждой строкой в таблице Number. Со всеми другими методами, кроме встраиваемого T-SQL, оптимизатор действительно зачастую не имеет другого выбора, чем сначала вычислить таблицу по входному списку, но некоторые однооператорные функции T-SQL открывают возможность обратной стратегии - которая вряд ли будет успешной. В этом частном случае, я предложил ему попытаться вместо этого использовать многооператорную функцию, что и решило его проблему. Но "интересный" не всегда означает плохой. Ниже я приведу случаи, где встроенный T-SQL дает неожиданно хорошую производительность на многопроцессорных машинах, поскольку оптимизатор находит параллельный план выполнения. А что насчет временных таблиц? Первоначально, когда оптимизатор компилирует хранимую процедуру, он делает слепое предположение о временной таблице. Но если во временную таблицу будет вставлено достаточное количество данных, то это вызовет срабатывание автостатистики, что, в свою очередь, вызовет перекомпиляцию операторов, которые ссылаются на временную таблицу. Эта повторная компиляция является и благом, и проклятием. Благом, потому что она дает оптимизатору второй шанс найти лучший план. Но если оптимизатор приходит в результате к тому же самому плану, который имел место до перекомпиляции, то это будет означать впустую потраченное процессорное время. В SQL 2000, где вся процедура должна была проходить повторную компиляцию, это могло обходиться действительно дорого. SQL 2005 имеет операторную перекомпиляцию, поэтому отрицательный эффект, возможно, не будет таким драматическим. Здесь читатель может почувствовать себя некомфортно из-за всех этих осложнений. На практике же не все так плохо. Часто эти слепые предположения работают достаточно хорошо, особенно если ваши входные списки невелики. Так что выбирайте любой метод, который вам больше подходит, и не мучайтесь с выбором, пока не столкнетесь с проблемами. Когда же Вы столкнетесь с плохой производительностью, вернитесь и прочитайте этот раздел снова, чтобы получить идею относительно альтернатив решения. Имеется одно испытанное правило - чем больше входной список, тем больше причин у Вас рассмотреть вариант использования временных таблиц. Ниже приведен краткий обзор возможного выбора метода для той или иной стратегии: Встраиваемый Непрозрачное Многооператорные Табличные Временные T-SQL встраивание функции функции функции Итерационный метод No No Yes Yes Yes CLR No Yes No Yes Yes XML No Yes No Yes Yes Таблица чисел Yes No Yes Yes Yes Фиксированная длина Yes No Yes Yes Yes Рекурсивный CTE Yes No Yes Yes Yes Список в SELECT No No No Yes Yes Динамический SQL Yes No No No No Действительно медленно Yes No No No No Проблема кэширования встроенного SQLРассмотрим такую процедуру: CREATE PROCEDURE test_sp @str nvarchar(MAX) AS SELECT t.col1, t.col2 FROM testtbl t JOIN inline_split_me(@str) c ON t.id = c.Value Как можно догадаться по имени, inline_split_me - однооператорная (встраиваемая) функция. Тони Роджерсон, SQL Server MVP, обнаружил здесь одну проблему: план выполнения для этой процедуры не помещается в кэш, как это должно быть. Это означает, что процедура компилируется при каждом выполнении. Это плохо не только из-за затрат на ненужные компиляции: при многочисленных одновременных вызовах этой процедуры эти вызовы будут сериализованы (упорядочены), поскольку если процесс (пере)компилирует процедуру, никакой другой процесс не может ее выполнять из-за наложенных блокировок до конца компиляции. Нет никакого повода для такого поведения; и разработчики SQL Server подтвердили мне, что это - просто баг в SQL 2005 и ничто иное. Эта проблема проявляется только с встраиваемыми функциями T-SQL, но не с многооператорными функциями. И только тогда, когда входная переменная имеет тип данных MAX. (Или связанные типы text, ntext или image.) Если входная переменная является обычной nvarchar (4000), проблемы не возникает. Решить проблему можно копированием входного параметра в локальную переменную: CREATE PROCEDURE test_sp @str nvarchar(MAX) AS DECLARE @copy nvarchar(MAX) SELECT @copy = @str SELECT t.col1, t.col2 FROM testtbl t JOIN inline_split_me(@copy) c ON t.id = c.Value Попутно оказалось, оказалось, что перебрасывание данных во временную таблицу или табличную переменную здесь не помогает. Проблемы не возникает со всеми встраиваемыми функциями в этой статье, а лишь с функциями на базе таблицы чисел и рекурсивного CTE, но не для фиксированной длины. Возможно, мне просто повезло, поэтому я призываю вас поработать с SQL Profiler, чтобы убедиться в том, что ваша процедура не подвержена этому багу. Разрешите все события для хранимых процедур. Если все в порядке, Вы должны увидеть событие CacheInsert при первом запуске вашей хранимой процедуры, а при последующих вызовах Вы должны видеть событие CacheHit. Если Вы видите CacheMiss всякий раз и ни разу CacheInsert, значит Вы столкнулись с этим багом. (Продолжение следует...) Полезная информация§ Приглашаем вас посетить новый проект - Интерактивный учебник по SQL. § Онлайновый выпуск рассылки можно почитать на сайте. § Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § Хотите поддержать проект? Вот инструкция по применению. :-) КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77[@]yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
| В избранное | ||
