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

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

Подписаться Бесплатная «Серебряная» новостная рассылка . Подписчиков 2.594 RSS
←   Август 2006   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


За последние 60 дней ни разу не выходила


Сайт рассылки: http://www.sql-ex.ru
Открыта: 15-09-2004

Автор
Serge I

Статистика

2.594 подписчиков
0 за неделю
←   Все выпуски   →

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


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

http://www.sql-ex.ru

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

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

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

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

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

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

§ Дошли руки до кнопочки вставки скрипта решения в текст сообщения на форуме. Раньше она не отличалась от кнопки форматирования, и обе назывались "CODE". Теперь кнопочка называется "Query". Заодно заменили и другие кнопочки.
Если вы не видите этой (этих) кнопок, значит старые файлы остались в локальном кэше вашего компьютера (временные файлы Интернет). Так что удалите их из кэша или подождите обновления.

§ Обновилась и страница с графиками результатов. Основные изменения таковы:
- неавторизованный доступ;
- добавлен график оценки стоимости запроса;
- присутствует кривая средних значений, которую можно отключить.
Относительно графика стоимости запросов следует сказать следующее:
1. Эта информация не формируется автоматически дабы не увеличивать нагрузку на сервер во время решения упражнений. Оценку по любой решенной задаче второго этапа можно получить на странице оценки эффективности. Я надеюсь, что заинтересованные лица наверняка уже оценили свои задачи, так что графики пустыми не будут :-).
2. Пока график строится по первому решению при условии, что оно остается верным при текущем состоянии проверочной базы данных.
Поэтому если вы не видите на графике какой-либо задачи-точки то причины может быть две: не посчитана ее оценка или она в данный момент не принимается системой проверки.

§ Решив замененные задачи, на третье место поднялся Testo (задач 138, время 7.180), а на восьмое Fiolent (138, 54.545).

§ Вернулся в сотню Родион1976 (103, .925), наиболее реальный претендент на то, чтобы поколебать позиции лидеров.

§ Сохранили шансы попасть в ТОР 10:
Ded I (126, 7.326)
SolYUtor (124, 10.582)
loki (120, 8.559)
PS_Sergey (110, 5.972)

§ Продолжили свое восхождение к вершине:
Robin (122, 135.010)
Ocean (117, 42.379)
imsh (113, 38.430)

§ На этой неделе сертифицированы:
Иван (A06008983) [BK] (г. Тула, Россия)
Rai (A06010196) [BK] (г. Москва, Россия)

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

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

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

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

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

No Person Number of
Sel_ex		 Last_Sel Number of
DML_ex		 Scores Days Days_2 LastSolved LastVisit
1 Войнов П.Е. (pаparome) 138 47 20 323 348 2.680 07 Aug 2006 25 Aug 2006
2 Юлдашев М.Р. (Snowbear) 138 47 20 323 383 4.055 05 Aug 2006 25 Aug 2006
3 >Slobodcicov A.N. (Testo) 138 92 20 323 337 7.180 25 Aug 2006 25 Aug 2006
4 Мурашкин И.В. (lepton) 138 47 20 323 136 10.134 06 Aug 2006 25 Aug 2006
5 Иванов А.Н. (Goapsy) 138 47 20 323 270 18.919 07 Aug 2006 07 Aug 2006
6 Голубин Р.С. (Roman S. Golubin) 138 47 20 323 353 21.138 06 Aug 2006 25 Aug 2006
7 Карасёва Н.В. (vlksm) 138 47 20 323 92 24.922 06 Aug 2006 25 Aug 2006
8 Валуев Д.И. (Fiolent) 138 47 20 323 1085 54.545 24 Aug 2006 25 Aug 2006
9 Кувалкин К.С. (Cyrilus) 137 47 20 321 623 9.768 09 Aug 2006 25 Aug 2006
10 Абашин П.И. (Dizil) 137 47 20 319 348 3.903 07 Aug 2006 11 Aug 2006
11 Самохвалов В. (ValdemarES) 137 47 20 319 273 7.850 17 Aug 2006 25 Aug 2006
12 Тарасов Д.Б. (Gavrila) 136 47 20 318 346 19.382 07 Aug 2006 25 Aug 2006
13 Kamaev V.M. (Heromantor) 135 138 20 316 128 9.044 14 Mar 2006 25 Mar 2006
14 Бураков С.Г. (burakov58) 135 138 20 316 419 17.381 24 Mar 2006 07 Apr 2006
15 frenkental (a2010) 135 137 20 315 110 15.332 19 Jul 2006 26 Jul 2006
16 Крижевич С.А. (yaff) 135 47 20 314 407 14.792 11 Aug 2006 23 Aug 2006
17 Зырин В.Е. (Vezyr) 135 47 20 314 204 20.590 05 Aug 2006 12 Aug 2006
18 Страшников А.С. (EffEct) 135 47 20 314 452 59.948 10 Aug 2006 10 Aug 2006
19 Зверев Д.Л. (dimzv) 134 137 20 312 869 3.272 22 Mar 2006 08 Jul 2006
20 Носков Н.В. (niko2) 134 137 20 312 274 8.452 06 Apr 2006 16 May 2006

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

No surname n_sel sel_all sel_scores dml_scores scores rating last_visit
1 Завьялов Ю.С. (Distort) 62 62 112 32 144 318 25 Aug 2006
2 >Мягчев М.И. (Mikhail Myagchev) 48 48 83 13 96 929 25 Aug 2006
3 Горшков Д.А. (-=DiM@n=-) 45 45 76 11 87 1064 25 Aug 2006
4 >ivanov (vo) 44 44 76 9 85 1099 25 Aug 2006
5 Агапов В. (KERBEROS) 40 40 73 9 82 1156 25 Aug 2006
6 Калинин О.Б. (Serga-ent) 37 37 62 17 79 1207 23 Aug 2006
7 Petrovsky V.A. (ValzoID) 42 42 75 0 75 1318 25 Aug 2006
8 >Быков Д.Е. (Deniss) 41 41 74 0 74 1345 25 Aug 2006
9 >Kaminsky A. (Kamin) 39 39 71 0 71 1438 25 Aug 2006
10 >Гребёнкин Ю.И. (ury1) 26 26 43 23 66 1541 25 Aug 2006
11 Sharovarov A. (ash) 12 60 24 32 56 332 24 Aug 2006
12 Креславский И.М. (Kreslav) 32 39 54 0 54 1663 23 Aug 2006
13 Гильдебрант А.А. (Зембельдович) 15 42 30 22 52 893 23 Aug 2006
14 >Kugushev V. (SlavaFinist) 29 29 52 0 52 2012 25 Aug 2006
15 >Modin A.V. (Tema) 26 31 51 0 51 1883 25 Aug 2006
16 Zhadovecs S. (DarkTower) 22 39 48 0 48 1458 23 Aug 2006
17 >Козлов Е.Н. (Ken_Great) 25 27 44 3 47 2154 25 Aug 2006
18 Б С.А. (БСергей) 20 43 37 9 46 1204 25 Aug 2006
19 >Стукало А.А. (Pixar) 16 40 36 8 44 1181 25 Aug 2006
20 KR (Reks) 14 28 34 9 43 1803 23 Aug 2006
21 Воробьев А.В. (vorrobei) 27 27 42 1 43 2370 23 Aug 2006
22 lbr__ (lbr) 21 57 41 0 41 719 24 Aug 2006
23 >Bukin V. (VladB) 18 42 38 3 41 1243 25 Aug 2006
24 Vitaliy L.N. (LeoM89) 25 25 40 0 40 2491 23 Aug 2006

Изучаем SQL

Настройка операторов SQL на Microsoft SQL Server 2000 (продолжение, начало в вып.99)

Kevin Kline, Claudia Fernandez, Quest Software, Inc. (оригинал: Tuning SQL Statements on Microsoft SQL Server 2000)
Перевод Живенко Н.

Чтение плана выполнения запроса

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

Давайте начнем с нескольких простых примеров, которые помогут нам понять, как следует читать план выполнения запроса, который выдается либо при вызове команды SET SHOWPLAN_TEXT ON, либо при установке опции с аналогичным именем в конфигурационных свойствах SQL Query Analyzer.

Этот пример использует pubs..big_sales, точную копию таблицы pubs..sales, только содержащую 80,000 записей, в качестве главного источника примеров простых планов выполнения.

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

SELECT *
FROM big_sales
SELECT ord_date
FROM big_sales
StmtText
------------------------------------------------------------------------------
|--Clustered Index Scan(OBJECT:([pubs].[dbo].[big_sales].[UPKCL_big_sales]))

Запросы, показанные выше, возвращают сильно различающиеся по количеству наборы данных, поэтому запрос, который вернет меньше данных (ord_date) выполнится быстрее, чем другой запрос просто потому, что потребует намного меньше операций ввода-вывода. Однако, планы выполнения запросов фактически идентичны.

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

SELECT title_id
FROM big_sales
StmtText
---------------------------------------------------------------------
|--Index Scan(OBJECT:([pubs].[dbo].[big_sales].[ndx_sales_ttlID]))

Этот запрос выполняется быстрее, чем запрос SELECT *, т.к. он может полностью получить необходимый ответ из некластеризованного индекса. Этот тип запроса называется "покрывающим запросом", т.к. весь результирующий набор входит в некластеризованный индекс.

Сравнение SEEK и SCAN

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

Не сложное, но очень полезное эмпирическое правило гласит, что операции SEEK хороши, операции SCAN - не очень, если не сказать плохи. Поиск напрямую, или, по крайней мере, очень быстро, обращается к нужным записям, тогда как сканирование считывает весь объект (таблицу, кластеризованный индекс или некластеризованный индекс). Таким образом, сканирование обычно потребляет больше ресурсов, чем поиск.

Если план выполнения запроса показывает только сканирование, то необходимо подумать о настройке запроса.

Предложение WHERE может значительно изменить производительность запроса, что показано ниже.

SELECT *
FROM big_sales
WHERE stor_id = '6380'
StmtText
-----------------------------------------------------------------------------
|--Clustered Index Seek(OBJECT:([pubs].[dbo].[big_sales].[UPKCL_big_sales]),
SEEK:([big_sales].[stor_id]=[@1]) ORDERED FORWARD)

Представленный выше запрос теперь может использовать операцию SEEK, а не SCAN на кластеризованном индексе. SHOWPLAN явно демонстрирует нам, что операция поиска основана на (stor_id), и что результаты УПОРЯДОЧЕНЫ в соответствии с их текущим размещением в указанном индексе. Начиная с SQL Server 2000, поддерживается как прямое, так и обратное направление обхода индексов с одинаковой эффективностью, и вы можете увидеть в плане выполнения запроса ORDERED FORWARD или ORDERED BACKWARD. Именно это сообщает вам, в каком направлении происходило чтение таблицы или индекса. Вы даже можете управлять направлением обхода при помощи служебных слов ASC и DESC в предложении ORDER BY.

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

SELECT *
FROM big_sales
WHERE stor_id >= '7131'
StmtText
------------------------------------------------------------------------------
|--Clustered Index Seek(OBJECT:([pubs].[dbo].[big_sales].[UPKCL_big_sales]),
SEEK:([big_sales].[stor_id] >= '7131') ORDERED FORWARD)

Вышеприведенный запрос выглядит почти также как и предыдущий, однако, предикат SEEK несколько другой.

SELECT *
FROM big_sales
WHERE stor_id BETWEEN '7066' AND '7131'
StmtText
-----------------------------------------------------------------------------
|--Clustered Index Seek(OBJECT:([pubs].[dbo].[big_sales].[UPKCL_big_sales]),
SEEK:([big_sales].[stor_id] >= '7066' AND [big_sales].[stor_id] <= '7131')
ORDERED FORWARD)

Этот запрос выглядит примерно так же, однако предикат SEEK изменился. Поскольку SEEK является очень быстрой операцией, то данный запрос достаточно хороший.

Операции SEEK и SCAN могут включать предикат предложения WHERE. В этом случае предикат скажет вам, какие записи из результирующего набора отфильтрует предложение WHERE. Поскольку предикат WHERE является компонентом операции SEEK или SCAN, то он сам по себе зачастую ни улучшает, ни ухудшает производительность этих операций. Однако предложение WHERE помогает оптимизатору запросов найти наилучшим образом подходящие индексы для обработки запроса.

Важная часть настройки запроса - выяснение, выполняется ли операция SEEK с использованием каких-либо индексов, и если да, то какие из этих индексов являются наилучшими. Большую часть времени оптимизатор запросов будет тратить на поиск существующих индексов. Однако с индексами связаны три общих проблемы:

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

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

SELECT ord_num
FROM sales
WHERE ord_date IS NOT NULL
AND ord_date > 'Jan 01, 2002 12:00:00 AM'
StmtText
------------------------------------------------------------------------------
|--Clustered Index Scan(OBJECT:([pubs].[dbo].[sales].[UPKCL_sales]),
WHERE:([sales].[ord_date]>'Jan 1 2002 12:00AM'))

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

StmtText
-----------------------------------------------------------------------------
|--Index Seek(OBJECT:([pubs].[dbo].[sales].[sales_ord_date]),
SEEK:([sales].[ord_date] > 'Jan 1 2002 12:00AM') ORDERED FORWARD)

Теперь запрос использует операцию INDEX SEEK (поиск по индексу) для созданного нами индекса sales_ord_date.

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

Полезная информация

§ Издана книга коллектива авторов SQL.RU: Microsoft SQL Server. Полезные алгоритмы от SQL.RU (+CD)

Составитель - Кошкин Сергей. Авторы и переводчики: Брылёв Вячеслав, Гавриленко Сергей, Гладченко Александр, Денисенко Александр, Денищенко Николай, Кривонос Наталья, Наумова Ирина, Рахманов Мартин, Уфимцев Глеб
ISBN: 5-469-01405-3; Штрих-код: 9785469014058; Объем: 272 с.; Формат: 60х90/16; Переплет: Обл Ц; Тираж: 3000; Тираж в продаже: 05.09.06;

В книге собраны статьи, написанные активными участниками сформировавшегося вокруг сайта SQL.RU сообщества. В первой части книги собраны полезные алгоритмы, которые заслужили признание у многих разработчиков приложений баз данных. Во второй части книги представлены статьи, посвященные вопросам безопасности MS SQL Server и работающих с ним пользовательских приложений. На прилагаемом компакт-диске находятся примеры из книги, а также дополнительные авторские презентации в формате PowerPoint.

Краткое содержание

Введение.

ЧАСТЬ I. ПОЛЕЗНЫЕ АЛГОРИТМЫ

Древовидные структуры в базах данных, соответствующих стандартам SQL.
Эффективный метод постраничной выборки.
Метод быстрой сортировки натуральных чисел.
Протоколирование изменений структуры БД и данных.
Триггер на событие соединения.
Управление одновременным редактированием данных несколькими пользователями.
Определение недоступности линкедсервера.
Расслоение таблиц в базах данных.
Служба событий в MS SQL Server.
Методика выбора плана исполнения запроса в SQL Server 2000.

ЧАСТЬ II. БЕЗОПАСНОСТЬ

Безопасность Microsoft SQL Server 2000 с позиции разработчика.
Общая система безопасности приложений на предприятии.
Защита хранимых процедур от дешифрования

ЧАСТЬ III. АДМИНИСТРИРОВАНИЕ И АРХИТЕКТУРА SQL SERVER

Утечка кода.
Жертвы режима волокон.
Планировщик непривилегированного режима в SQL Server 2000.
Нежелательность сжатия файлов данных и журналов SQL Server.
Журнал транзакций SQL Server 2000.
Описание механизма доставки журналов в SQL Server 2000.
Резервное копирование баз данных SQL Server 2000.

 

§ Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL.

§ Поступила в продажу книга SQL. Задачи и решения, посвященная анализу ошибок, допускаемых при решении задач первого этапа. На сайте издательства Питер можно сделать заказ и познакомиться с содержанием.

Контакты

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