Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 57


Информационный Канал Subscribe.Ru

Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 57 (15 октября 2005 г.)

http://www.sql-ex.ru

Новым посетителям сайта

Сайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.

Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 59-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений.

Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов.

Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий.


Новости сайта

§ Поступило первое нарекание (Developer) на английскую формулировку задачи #5. Исправил.

§ Устранил замеченный aaz огрех в проверке упражнения 17DML.

§ Готовлю добавление (замену) новых задач на сайте. Вероятно, что изменение коснется всех рейтинговых этапов, т.е. будет по одной новой задаче до 65 упражнения, до 121 и после. Просроченнные заказы будут аннулированы.

§ Число подписчиков - 2592

Число участников рейтинга - 3610

Число участников второго этапа - 402

Сертифицировано на сайте - 34

Лучшие результаты (ТОР 20)

No Person Number of
Sel_ex
Last_Sel Number of
DML_ex
Scores Days Days_2 LastSolved LastVisit
1 Духин А. (Shark) 137 137 20 312 30 2.635 10 Aug 2005 13 Oct 2005
2 Зверев Д.Л. (dimzv) 137 137 20 312 643 2.900 08 Aug 2005 01 Sep 2005
3 Кувалкин К.С. (Cyrilus) 137 137 20 312 224 5.129 06 Jul 2005 14 Oct 2005
4 Голубин Р.С. (Roman S. Golubin) 137 137 20 312 48 6.480 05 Oct 2005 14 Oct 2005
5 Носков Н.В. (niko2) 137 137 20 312 47 7.855 22 Aug 2005 19 Sep 2005
6 Гонтовой В.А. (noname) 137 137 20 312 105 9.808 29 Jun 2005 04 Oct 2005
7 Леденев С.А. (Shurgenz) 137 137 20 312 313 9.900 27 Jun 2005 11 Oct 2005
8 Бураков С.Г. (burakov58) 137 137 20 312 164 12.100 12 Jul 2005 09 Sep 2005
9 Валуев Д.И. (Fiolent) 137 137 20 312 662 26.627 27 Jun 2005 14 Oct 2005
10 Галиаскаров Э.Г. (Galogen) 137 137 20 312 221 61.437 01 Jul 2005 21 Sep 2005
11 Мельникова И.А. (Iris_m) 137 137 20 312 478 91.764 02 Sep 2005 10 Oct 2005
12 Gershovich (VIG) 136 136 20 308 895 13.954 23 Aug 2005 14 Oct 2005
13 Колосов А.С. (KAS) 134 137 20 306 25 3.398 11 Mar 2005 14 Oct 2005
14 Алалыкин В.М. (BOBAH) 135 135 20 305 101 28.244 01 Sep 2005 13 Oct 2005
15 Сныткин В.Л. (Ded I) 134 136 20 304 252 7.456 12 May 2005 09 Sep 2005
16 Рахманов И.Е. (bloom) 134 136 20 304 148 14.171 11 May 2005 09 Oct 2005
17 Hakobyan H.H. (hamlet) 134 136 20 304 220 37.869 07 May 2005 03 Jun 2005
18 Шипунов И. (IAS) 134 136 20 304 334 82.080 13 May 2005 26 May 2005
19 Иткин И.Л. (joseph_itkin) 132 136 20 299 375 2.849 07 Mar 2005 13 Apr 2005
20 Spirin (spirin) 131 136 19 296 158 13.461 21 Jan 2005 25 Aug 2005

Лучшие результаты за неделю

No surname n_sel sel_all sel_scores dml_scores scores rating last_visit
1 >Чучалин А.В. (Чучалин А.В.) 52 52 88 28 116 344 14 Oct 2005
2 Rodin E. (er1) 59 59 107 3 110 391 12 Oct 2005
3 >Мелихов (Aristokl) 48 48 80 13 93 562 14 Oct 2005
4 Игошев Л.А. (Organism) 25 59 48 28 76 243 14 Oct 2005
5 Батталова (Nad_n00) 47 48 74 0 74 725 12 Oct 2005
6 Antonov D.E. (Dimon) 42 42 62 9 71 818 14 Oct 2005
7 Kuleshov (Plastilin) 18 64 37 32 69 177 14 Oct 2005
8 Krivko A. (Hunta) 30 30 55 11 66 878 14 Oct 2005
9 >Rusanov A.M. (Arus) 39 39 59 0 59 1015 14 Oct 2005
10 >Русских О.М. (junior) 32 33 55 0 55 1073 14 Oct 2005
11 Лоновенко Н.А. (NickLong) 38 38 54 0 54 1107 12 Oct 2005
12 Кшиштыняк В.Ю. (Turbin) 34 34 48 3 51 1155 14 Oct 2005
13 >Ананьев А.С. (Mureno.ais) 31 31 42 0 42 1349 14 Oct 2005
14 Vadim (ArbeitMachtFrei) 23 23 34 4 38 1444 08 Oct 2005
15 Балдин О.Б. (Weed) 18 96 37 0 37 79 14 Oct 2005
16 Васильев В.О. (vovan) 24 24 37 0 37 1483 13 Oct 2005
17 >Степанов А.Ю. (nnm2005-ps) 17 36 33 0 33 1043 14 Oct 2005
18 Кошляков А.А. (Кошляков) 13 30 33 0 33 1088 12 Oct 2005
19 >Lans D.Y. (trueDan) 23 23 32 0 32 1702 14 Oct 2005
20 >Kudryashov P.B. (cenobito) 22 22 31 0 31 1762 14 Oct 2005
21 >Петров С.А. (iGrey) 18 18 31 0 31 1771 14 Oct 2005
22 Долгова Л.Н. (Lessie) 12 78 27 3 30 158 13 Oct 2005
23 >Романович Т.М. (Tanetchka) 21 21 30 0 30 1816 14 Oct 2005

Изучаем SQL

Характерные ошибки в кодах Transact-SQL, вызывающие падение производительности (продолжение, начало в вып.55, 56)

Randy Dyess (оригинал: Common Transact-SQL Performance Coding Errors )
Перевод Моисеенко С.И.

Использование полностью квалифицированных имен

В SQL Server 7.0 и 2000 только одна копия любого конкретного плана хранимой процедуры обычно находится в кэше в данный момент времени. Осуществление этого требует преобразования в последовательную форму (сериализации) некоторых частей процесса компиляции, и эта синхронизация достигается, в частности, посредством блокировок компиляции. Если одновременно на многих подключениях запускается одна и та же хранимая процедура, и всякий раз, когда она запускается, должна быть затребована блокировка компиляции на эту хранимую процедуру, то возможно, что идентификаторы системного процесса (SPIDs) могут начать блокировать друг друга, поскольку каждый из них пытается затребовать наложение эксклюзивной блокировки компиляции на данный объект.

Перекомпиляция хранимой процедуры является одним из объяснений блокировок компиляции, накладываеых на хранимую процедуру или триггер. Еще одной причиной возникновения блокировок компиляции является выполнение следующих условий:

· Пользователь, который выполняет хранимую процедуру, не является ее владельцем.
· Имя хранимой процедуры не является полностью квалифицированным с указанием имени владельца объекта.

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

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

Согласование столбцов в запросе с индексами

Как и при согласовании столбцов индекса с наиболее часто используемыми столбцами в предложении WHERE, разработчики должны стремиться сопоставлять столбцы поиска в запросе с крайними слева столбцами в индексе, когда это возможно. Индексы бесполезны, если крайний левый столбец в предложении WHERE является крайним правым столбцом индекса. Создание индекса и разработка предложения WHERE должны быть согласованы в процессе создания кода, а не рассматриваться как два независимых этапа работы.

См. BOL: Designing an Index.

Предложение DISTINCT

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

См. BOL: Eliminating Duplicates with DISTINCT, and Using DISTINCT.

UNION против UNION ALL

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

См. BOL: Combining Results with UNION, Guidelines when Using UNION, UNION Operator, and Using UNION with Other Transact-SQL Statements.

Предикат IN

Если запрос содержит предикат IN, который представляет собой список постоянных значений, упорядочивайте значения на основе частоты их появления во внешнем запросе. Так как вычисление предиката будет прекращаться, как только найдется совпадение с любым из списка значений, перемещая те из них, которые появляются чаще в наборе данных, вы будете ускорять выполнение запроса и возможно уменьшите количество ЧТЕНИЙ, выполняемых при выполнении запроса.

См. BOL: Subqueries with IN, IN, List Search Conditions, and Subquery Fundamentals.

Избегайте неявных преобразований типов данных

При использовании переменных для фильтрации данных в предложении WHERE, следует избегать сравнений на двух различных типах данных, которые вынудят SQL Server выполнять неявное преобразование типа данных. Если возможно, опишите переменную с типом данных, соответствующим типу данных столбца, по которому выполняется фильтрация. Отрицательным примером может служить установка для столбца типа данных INTEGER, а затем его использование для фильтрации по типу данных float или decimal. Неявное преобразование дорого обходится и может вызвать значительную нагрузку при больших наборах данных.

См. BOL: Data Type Conversion, CAST and CONVERT, and Conversion Functions.

(продолжение следует...)

Контакты

По всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте.

Подписка Subscribe.Ru
Новости сайта "Упражнения по SQL"

Subscribe.Ru
Поддержка подписчиков
Другие рассылки этой тематики
Другие рассылки этого автора
Подписан адрес:
Код этой рассылки: comp.soft.db.sqlex
Архив рассылки
Отписаться
Вспомнить пароль

В избранное