Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru)
| Информационный Канал Subscribe.Ru |
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 42 (2 июля 2005 г.)
 |
Новым посетителям сайтаСайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 59-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. |
Новости сайта
§ Опять заменил 112-ю задачу, теперь в редакции VIG. Замена связана с тем, что решение можно было получить за считанные секунды, воспользовавшись некоторыми решениями опубликованными на форуме другой задачи.
§ Еще раз обновил скрипт базы данных "Корабли". Изменения коснулись размера полей для имен классов и кораблей. Теперь все они имеют одинаковый размер - varchar(50). Свежую версию можно взять отсюда.
§ Число подписчиков - 2197Число участников рейтинга - 3477
Число участников второго этапа - 332
Лучшие результаты (ТОР 20)
| No | Person | Number of Sel_ex |
Last_Sel | Number of DML_ex |
Scores | Days | Days_2 | LastSolved | LastVisit |
| 1 | Гонтовой В.А. (noname) | 137 | 112 | 20 | 312 | 105 | 9.808 | 29 Jun 2005 | 01 Jul 2005 |
| 2 | Леденев С.А. (Shurgenz) | 137 | 112 | 20 | 312 | 313 | 9.900 | 27 Jun 2005 | 01 Jul 2005 |
| 3 | Валуев Д.И. (Fiolent) | 137 | 112 | 20 | 312 | 662 | 26.627 | 27 Jun 2005 | 01 Jul 2005 |
| 4 | >Галиаскаров Э.Г. (Galogen) | 137 | 112 | 20 | 312 | 221 | 61.437 | 01 Jul 2005 | 01 Jul 2005 |
| 5 | Кувалкин К.С. (Cyrilus) | 136 | 137 | 20 | 310 | 212 | 5.020 | 24 Jun 2005 | 01 Jul 2005 |
| 6 | Мельникова И.А. (Iris_m) | 135 | 137 | 20 | 308 | 380 | 89.865 | 27 May 2005 | 14 Jun 2005 |
| 7 | Зверев Д.Л. (dimzv) | 135 | 136 | 20 | 306 | 580 | 2.471 | 06 Jun 2005 | 15 Jun 2005 |
| 8 | Колосов А.С. (KAS) | 134 | 137 | 20 | 306 | 25 | 3.398 | 11 Mar 2005 | 14 Jun 2005 |
| 9 | Сныткин В.Л. (Ded I) | 134 | 136 | 20 | 304 | 252 | 7.456 | 12 May 2005 | 01 Jul 2005 |
| 10 | Рахманов И.Е. (bloom) | 134 | 136 | 20 | 304 | 148 | 14.171 | 11 May 2005 | 15 Jun 2005 |
| 11 | Hakobyan H.H. (hamlet) | 134 | 136 | 20 | 304 | 220 | 37.869 | 07 May 2005 | 03 Jun 2005 |
| 12 | Шипунов И. (IAS) | 134 | 136 | 20 | 304 | 334 | 82.080 | 13 May 2005 | 26 May 2005 |
| 13 | Иткин И.Л. (joseph_itkin) | 132 | 136 | 20 | 299 | 375 | 2.849 | 07 Mar 2005 | 13 Apr 2005 |
| 14 | Spirin (spirin) | 131 | 136 | 19 | 296 | 158 | 13.461 | 21 Jan 2005 | 24 Jan 2005 |
| 15 | Михайлов В.Г. (mslava) | 132 | 136 | 17 | 293 | 648 | 10.504 | 25 Mar 2005 | 25 Mar 2005 |
| 16 | Пятница О.А. (Robin) | 125 | 128 | 20 | 287 | 754 | 74.630 | 19 Mar 2005 | 30 Jun 2005 |
| 17 | Митронин А.А. (mitronin) | 123 | 124 | 20 | 283 | 701 | 27.541 | 31 May 2005 | 01 Jun 2005 |
| 18 | Gershovich (VIG) | 123 | 112 | 20 | 282 | 837 | 10.663 | 26 Jun 2005 | 01 Jul 2005 |
| 19 | >Бураков С.Г. (burakov58) | 120 | 120 | 20 | 275 | 153 | 8.216 | 01 Jul 2005 | 30 Jun 2005 |
| 20 | Булаев В.В. (Kvix) | 119 | 121 | 20 | 274 | 266 | 24.671 | 18 May 2005 | 18 May 2005 |
Лучшие результаты за неделю
| No | surname | n_sel | sel_all | sel_scores | dml_scores | scores | rating | last_visit |
| 1 | Есентемиров Ж.К. (Capitan_Jack) | 57 | 57 | 103 | 23 | 126 | 365 | 01 Jul 2005 |
| 2 | >Сергеева О. (strangeress) | 58 | 58 | 105 | 19 | 124 | 300 | 01 Jul 2005 |
| 3 | >Nisengoltsev O. (Mr-Oleg) | 54 | 54 | 94 | 23 | 117 | 418 | 01 Jul 2005 |
| 4 | Мартьянов А.Н. (Styx) | 53 | 53 | 90 | 17 | 107 | 443 | 30 Jun 2005 |
| 5 | >chiabishvili A.G. (alika1982) | 42 | 54 | 82 | 23 | 105 | 419 | 01 Jul 2005 |
| 6 | Левандовский А.Н. (levalex) | 40 | 40 | 72 | 23 | 95 | 618 | 01 Jul 2005 |
| 7 | >oleg_d O. (oleg_dov) | 51 | 51 | 88 | 0 | 88 | 459 | 01 Jul 2005 |
| 8 | Кузнецов В.А. (str) | 35 | 59 | 70 | 17 | 87 | 264 | 01 Jul 2005 |
| 9 | >Выскребенцев В.В. (Vint) | 49 | 49 | 83 | 0 | 83 | 502 | 01 Jul 2005 |
| 10 | >Качалина Ю. (Trer) | 38 | 38 | 56 | 19 | 75 | 832 | 01 Jul 2005 |
| 11 | >Скударь А. (ASkudar) | 40 | 40 | 72 | 0 | 72 | 616 | 01 Jul 2005 |
| 12 | >Корягин А.В. (Akr) | 43 | 43 | 69 | 3 | 72 | 643 | 01 Jul 2005 |
| 13 | >Бойцун Р.В. (BRV) | 29 | 59 | 52 | 16 | 68 | 267 | 01 Jul 2005 |
| 14 | >Tsvetkov V. (Victor Tsvetkov) | 39 | 39 | 66 | 0 | 66 | 671 | 30 Jun 2005 |
| 15 | >Baldin O.B. (Weed) | 38 | 38 | 57 | 9 | 66 | 821 | 01 Jul 2005 |
| 16 | garg S. (saurabh) | 32 | 32 | 55 | 9 | 64 | 841 | 01 Jul 2005 |
| 17 | >Agarwal S. (Sachin) | 36 | 36 | 60 | 3 | 63 | 768 | 01 Jul 2005 |
| 18 | Холин К.В. (f.nietzsche) | 32 | 37 | 61 | 0 | 61 | 673 | 24 Jun 2005 |
| 19 | Салов А. (Sanders) | 29 | 29 | 52 | 0 | 52 | 878 | 29 Jun 2005 |
| 20 | >Kostochko D. (dimak) | 36 | 36 | 48 | 3 | 51 | 971 | 01 Jul 2005 |
| 21 | >Стройнов Д.С. (Voland3D) | 24 | 94 | 50 | 0 | 50 | 71 | 30 Jun 2005 |
| 22 | >Бураков С.Г. (burakov58) | 18 | 120 | 46 | 0 | 46 | 23 | 30 Jun 2005 |
| 23 | >LAST L. (LERG) | 22 | 22 | 31 | 9 | 40 | 1377 | 01 Jul 2005 |
Изучаем SQL
Общий план оптимизации и настройки запросов
Randy Dyess (оригинал)
Перевод Моисеенко С.И.
Во время недавнего собеседования, которое я проходил, чтобы найти новую работу прежде, чем закончится мой текущий контракт, мне задали вопрос, который захватил меня врасплох. Интервьюер просто спросил меня, какие шаги я бы предпринял, чтобы выяснить, какие хранимые процедуры нуждаются в оптимизации, и что я обычно делаю для оптимизации запросов. Меня застал врасплох не сам вопрос; а осознание того, что я не имел "формального" плана действий для определения того, какие хранимые процедуры нуждаются в оптимизации, или плана для их фактической оптимизации. После собеседования я решил формализовать основные действия, которые имел обыкновение предпринимать для нахождения хранимых процедур, нуждающихся в оптимизации и действий, которые необходимы в случае, если запрос требует оптимизации. После записи некоторых заметок, я решил, что следует сделать из этого "плана" статью, чтобы и другие знали, какие основные шаги необходимы для оптимизации запроса.
Как вы уже догадались, первый шаг, который следует сделать, заключается в идентификации запросов, нуждающихся в настройке. По существу имеется два типа запросов в инсталляции SQL Server: запросы до внедрения и после внедрения. Само собой разумеется, что все новые (до внедрения) запросы должны быть полностью оптимизированы даже прежде, чем вы соберетесь их внедрять. Однако запросы, которые были уже внедрены, даже те, которые вы уже оптимизировали, должны пересматриваться при изменении состояния базы данных, чтобы узнать, не создают ли они новых проблем.
Большинство компаний обычно работают только с запросами после внедрения, когда они создают проблему и помещаются в список "багов" некоторого типа. Да, вы можете обнаружить проблемные запросы таким способом, но если вы будете дожидаться, пока они не появятся в списке "багов", вы попадете в цейтнот, "фиксируя" проблему, делая резервную копию приложения и запуская его. Если повезет, то вам хватит времени, чтобы применить новые знания по настройке производительности, которые вы приобрели за время, прошедшее с момента, когда в последний раз работали над запросом при решении новой проблемы. Этот способ настройки запросов по факту может позволить, а может и не позволить вам идентифицировать и исправить ключевой момент потери производительности ваших хранимых процедур, поскольку он имеет дело с теми запросами, которые настолько плохи, что привлекают к себе основное внимание. Лучший план позволил бы вам не только работать над проблемными запросами по мере их появления, но и получить списки запросов, которые демонстрируют проблемную производительность до того, как они попадают в список "багов". Тогда эти запросы могут оптимизироваться, когда у вас есть на это время или когда вы адаптируете их к новой версии приложения. Использование мощности SQL Profiler и выполнение простой трассировки для определения производительности ваших хранимых процедур может облегчить получение этих новых списков запросов. Такую трассировку просто создать, и, в зависимости от установки, запускать в моменты максимальной и минимальной загрузки в течение нескольких дней, чтобы получить хорошую выборку данных.
Создание списка запросов с помощью трассировки SQL Profiler
Чтобы получить списки запросов, вам потребуется создать и выполнить трассировку, фиксирующую все события хранимой процедуры, а также следующие столбцы данных:
● EventClass● EventSubClass
● TextData
● CPU
● Reads
● Writes
● Duration
● SPID
● StartTime
● EndTime
● NestLevel
● ObjectID
● ObjectName
● ObjectType
Такая трассировка может породить большое количество данных, поэтому может оказаться проще сделать так, чтобы информация помещалась в таблицу, из которой вы сможете извлекать ее с помощью запроса. Если можно найти способ фильтровать трассу, чтобы ограничить вывод данных, я предложил бы вам это сделать. Я обычно использую для имен моих хранимых процедур префикс 'spXXXX', поэтому я могу выполнить фильтрацию по имени объекта. Но поскольку вы работаете с уже имеющейся ситуацией, приходится что-то придумать, чтобы, допуская фильтрацию некоторых ненужных данных, получить необходимые данные и уменьшить трассу.
Теперь, когда вы сохранили ваши данные в таблице, создайте хранимые процедуры, которые выдадут самые плохие по производительности процедуры, учитывая длительность (длительность выводится в миллисекундах), SP:CacheMiss (отсутствие в кэше), SP:Recompile (перекомпиляция), Reads (чтения) и Write (записи). Создайте списки с наибольшими длительностями, наибольшим числом чтений, наибольшим числом записей и хранимыми процедурами, которые включают события SP:CacheMiss и SP:Recompile. Возможно, вам потребуется несколько попыток, чтобы понять, какое число операций чтения и записи считается чрезмерным в вашей базе данных, но если вы видите хранимую процедуру, которая превышает среднее значение этих показателей, с нее можно начать. Остальные списки проще для определения проблемных запросов, на которые можно воздействовать сразу.
Теперь, когда вы получили свои списки запросов, подлежащих переработке, - долго выполняющиеся запросы, запросы с чрезмерным числом чтений и записей, запросы, которые перекомпилируются, - что нужно делать, чтобы оптимизировать их?
Долго выполняющиеся и новые запросы
Первое, что нужно сделать для длительно выполняющихся запросов и запросов, которые вы только что создали, это получить их план выполнения. Используя план выполнения, вы должны:
● Найти то, что окрашено красным цветом. Анализатор запросов (Query Analyzer) окрасит значки красным, если определит, что там есть определенные проблемы. Обычно красный цвет означает, что статистические данные индексов, используемых данной частью запроса, устарели, однако, это может означать и другие вещи. Обращайте внимание на любые значки, которые имеют красный цвет, и думайте, как устранить проблемы.● Разобраться, как вы получаете данные из таблиц. Выполняет ли запрос сканирование таблицы (Table Scan)? Можете ли вы сделать что-нибудь, чтобы заменить сканирование индекса или кластеризованного индекса (Index Scans или Clustered Index Scans) на поиск в индексе или поиск в кластерном индексе (Index Seeks или Clustered Index Seeks)? Можете ли вы переделать запрос, чтобы использовать кластеризованный индекс вместо некластеризованного индекса? Простое перемещение поиска базовых данных от сканирования таблицы на поиск в индексе или кластеризованном индексе, как правило, решает проблему медленно выполняющего запроса. В результате вы получаете очень быстрый способ улучшить работу большинства проблемных запросов.
● Обратите внимание на стоимость (Cost) каждого сегмента запроса. Следует знать, что стоимость каждого сегмента примерно соответствует процентной доле времени, которое потребуется для его выполнения. Выделите наибольшие процентные доли и подумайте, можете ли вы оптимизировать этот сегмент кода каким-либо способом. Это не означает, что вам нужно сделать так, чтобы максимальная стоимость перестала быть таковой; цель состоит в том, чтобы оптимизация сегмента просто сделала выполнение этого сегмента более быстрым, чем раньше.
(окончание следует...)
Полезная информация
Конкурс
§ Мы выставили наш сайт на конкурс Интернить 2005. Победитель определяется числом поданых голосов. Просьба проголосовать. (рекомендуемая оценка 3 :-)).
Контакты
По всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте.
| Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.db.sqlex |
Отписаться
Вспомнить пароль |
| В избранное | ||
