| ← Октябрь 2005 → | ||||||
|
2
|
||||||
|---|---|---|---|---|---|---|
|
3
|
4
|
5
|
6
|
8
|
9
|
|
|
10
|
11
|
12
|
13
|
14
|
16
|
|
|
17
|
18
|
19
|
20
|
21
|
23
|
|
|
24
|
25
|
26
|
27
|
28
|
30
|
|
|
31
|
||||||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru)
| Информационный Канал Subscribe.Ru |
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 55 (1 октября 2005 г.)
 |
Новым посетителям сайтаСайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 59-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. |
Новости сайта
§ Все обнаруженные проблемы, связанные с переездом на новый сервер, решены. Просьба писать мне или на форуме сайта, если обнаружится еще что-либо.
§ Новый сервер стал помощнее, поэтому оценка стоимости запросов должна измениться в лучшую сторону. Поскольку пересчет не выполняется автоматически, заинтересованных лиц предупреждаю о необходимости пощелкать GO на странице сравнительной оценки стоимости.
§ Провел чистку базы участников. Удалил более 700 учетных записей. Использовал следующие критерии (AND):
1. В сумме решено менее 15 задач.
2. Отсутствие на сайте более года.
3. Не было опубликовано ни одного решения на форуме.
Я считаю, что это случайные посетители, тем более, что на повторную регистрацию и решение первых 14 задач много времени не потребуется.
Однако, если я кого обидел, пишите; восстановим из заботливо приготовленного перед операцией удаления
бэкапа.
Число участников рейтинга - 3484
Число участников второго этапа - 394
Сертифицировано на сайте - 32
Лучшие результаты (ТОР 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 | 23 Sep 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 | 01 Oct 2005 |
| 4 | Носков Н.В. (niko2) | 137 | 137 | 20 | 312 | 47 | 7.855 | 22 Aug 2005 | 19 Sep 2005 |
| 5 | Гонтовой В.А. (noname) | 137 | 137 | 20 | 312 | 105 | 9.808 | 29 Jun 2005 | 30 Sep 2005 |
| 6 | Леденев С.А. (Shurgenz) | 137 | 137 | 20 | 312 | 313 | 9.900 | 27 Jun 2005 | 30 Sep 2005 |
| 7 | Бураков С.Г. (burakov58) | 137 | 137 | 20 | 312 | 164 | 12.100 | 12 Jul 2005 | 09 Sep 2005 |
| 8 | Валуев Д.И. (Fiolent) | 137 | 137 | 20 | 312 | 662 | 26.627 | 27 Jun 2005 | 30 Sep 2005 |
| 9 | Галиаскаров Э.Г. (Galogen) | 137 | 137 | 20 | 312 | 221 | 61.437 | 01 Jul 2005 | 21 Sep 2005 |
| 10 | Мельникова И.А. (Iris_m) | 137 | 137 | 20 | 312 | 478 | 91.764 | 02 Sep 2005 | 22 Sep 2005 |
| 11 | Gershovich (VIG) | 136 | 136 | 20 | 308 | 895 | 13.954 | 23 Aug 2005 | 28 Sep 2005 |
| 12 | Колосов А.С. (KAS) | 134 | 137 | 20 | 306 | 25 | 3.398 | 11 Mar 2005 | 18 Sep 2005 |
| 13 | Алалыкин В.М. (BOBAH) | 135 | 135 | 20 | 305 | 101 | 28.244 | 01 Sep 2005 | 25 Sep 2005 |
| 14 | Сныткин В.Л. (Ded I) | 134 | 136 | 20 | 304 | 252 | 7.456 | 12 May 2005 | 09 Sep 2005 |
| 15 | Рахманов И.Е. (bloom) | 134 | 136 | 20 | 304 | 148 | 14.171 | 11 May 2005 | 15 Jun 2005 |
| 16 | Hakobyan H.H. (hamlet) | 134 | 136 | 20 | 304 | 220 | 37.869 | 07 May 2005 | 03 Jun 2005 |
| 17 | Шипунов И. (IAS) | 134 | 136 | 20 | 304 | 334 | 82.080 | 13 May 2005 | 26 May 2005 |
| 18 | Иткин И.Л. (joseph_itkin) | 132 | 136 | 20 | 299 | 375 | 2.849 | 07 Mar 2005 | 13 Apr 2005 |
| 19 | Spirin (spirin) | 131 | 136 | 19 | 296 | 158 | 13.461 | 21 Jan 2005 | 25 Aug 2005 |
| 20 | Михайлов В.Г. (mslava) | 132 | 136 | 17 | 293 | 648 | 10.504 | 25 Mar 2005 | 25 Mar 2005 |
Лучшие результаты за неделю
| No | surname | n_sel | sel_all | sel_scores | dml_scores | scores | rating | last_visit |
| 1 | >Гайковой М.Ю. (Gaikin™) | 61 | 61 | 109 | 32 | 141 | 191 | 01 Oct 2005 |
| 2 | Сергеев Д.А. (sda) | 32 | 52 | 62 | 23 | 85 | 358 | 01 Oct 2005 |
| 3 | Белякова Е. (Just) | 36 | 36 | 64 | 0 | 64 | 877 | 30 Sep 2005 |
| 4 | Богомолова О.В. (Цзеху) | 35 | 35 | 62 | 0 | 62 | 921 | 27 Sep 2005 |
| 5 | >Khudyakov A.A. (empacher) | 25 | 55 | 57 | 3 | 60 | 498 | 01 Oct 2005 |
| 6 | Ovchinnikova L. (konovalova) | 41 | 41 | 60 | 0 | 60 | 960 | 29 Sep 2005 |
| 7 | Шакиров (Cadet) | 34 | 34 | 55 | 1 | 56 | 1038 | 30 Sep 2005 |
| 8 | >Prokopenko (Prok) | 34 | 41 | 55 | 0 | 55 | 935 | 01 Oct 2005 |
| 9 | Faderov A. (Alexandr_F) | 32 | 32 | 52 | 0 | 52 | 1103 | 29 Sep 2005 |
| 10 | Кора В.В. (lovko) | 27 | 33 | 48 | 0 | 48 | 1024 | 01 Oct 2005 |
| 11 | >choudhary S. (sumit) | 32 | 32 | 44 | 0 | 44 | 1271 | 01 Oct 2005 |
| 12 | Сучков (andrews2) | 26 | 26 | 43 | 0 | 43 | 1285 | 29 Sep 2005 |
| 13 | RKM К.М. (Konstantin_dnepr) | 26 | 26 | 43 | 0 | 43 | 1286 | 27 Sep 2005 |
| 14 | Москальков Е.В. (Belarus) | 26 | 26 | 43 | 0 | 43 | 1292 | 30 Sep 2005 |
| 15 | Захаров А.В. (ZAV) | 24 | 24 | 37 | 0 | 37 | 1432 | 27 Sep 2005 |
| 16 | Пушкарева А. (E_L) | 23 | 23 | 35 | 0 | 35 | 1523 | 30 Sep 2005 |
| 17 | >Mcl (olia) | 25 | 25 | 35 | 0 | 35 | 1536 | 01 Oct 2005 |
| 18 | Kochneva E. (Katya) | 22 | 22 | 30 | 4 | 34 | 1566 | 28 Sep 2005 |
| 19 | Ландышев (О.) | 18 | 25 | 33 | 0 | 33 | 1391 | 30 Sep 2005 |
| 20 | Тарасов Д.Б. (Gavrila) | 13 | 110 | 32 | 0 | 32 | 50 | 30 Sep 2005 |
| 21 | Глущенко М. (Adamant) | 19 | 24 | 32 | 0 | 32 | 1477 | 29 Sep 2005 |
| 22 | Глазко А.Ф. (андрей_ф) | 15 | 58 | 31 | 0 | 31 | 468 | 30 Sep 2005 |
| 23 | O Donovan J.D. (kiddie) | 22 | 22 | 31 | 0 | 31 | 1720 | 28 Sep 2005 |
| 24 | >Власенко Н.М. (kolya) | 9 | 52 | 21 | 9 | 30 | 504 | 01 Oct 2005 |
| 25 | Амяго М. (multifighter) | 21 | 26 | 30 | 0 | 30 | 1545 | 28 Sep 2005 |
Изучаем SQL
Характерные ошибки в кодах Transact-SQL, вызывающие падение производительности
Randy Dyess (оригинал: Common Transact-SQL Performance Coding Errors )Перевод Моисеенко С.И.
Одним из вопросов, все чаще обсуждаемых мной в последние дни с клиентами или администраторами/разработчиками баз данных, является создание такой политики компании, которая бы описывала ряд стандартов, которым должны следовать при создании хранимых процедур для SQL server. С одной стороны, политика стандартов уровня компании или подразделения не должна быть столь ограничительной или "высеченной на камне", чтобы душить всякий творческий потенциал, который часто необходим для решения требований бизнеса, стоящих перед разработчиками. С другой стороны, она должна обеспечить такие рекомендации, которые ограничивали стиль кодирования таким образом, чтобы он не создавал проблем безопасности, падения производительности или проблем обслуживании в будущем.
Хотя всесторонняя политика является слишком большой, чтобы быть описанной в этой статье, Вы могли бы сделать небольшую электронную книгу только по стандартам Transact-SQL, а я бы с удовольствием обсудил те вопросы, относящиеся к стилю, которые чаще всего вызывают падение производительности на сайтах моих клиентов.
Непосредственно передаваемый запрос по сравнению с хранимыми процедурами
Обычные дебаты в мире разработки связаны с использованием хранимых процедур по сравнению с запросами, непосредственно содержащимися в коде приложения. Хотя эти дебаты ведутся с тех пор, когда появились хранимые процедуры и вероятно будут продолжаться и после того, как я уйду, я считаю, что во многих больших средах с тысячами пользователей и терабайтами данных хранимые процедуры действительно дают выигрыш в производительности по сравнению с запросами.
SQL Server компилирует все операторы хранимой процедуры в единый план выполнения. Это лучше выполняется при обработке непосредственно запроса, но возможности повторного использования и перекомпиляции все же, как мне кажется, немного лучше для хранимых процедур, чем для запросов. Другое большое преимущество хранимых процедур состоит в том, что хранимые процедуры обрабатываются на сервере, предотвращая большие и повторяющиеся передачи данных туда и обратно по сети между клиентами и сервером при решении сложных проблем. Я также полагаю, что хранимая процедура обеспечивает лучший уровень безопасности между приложением или пользователем и таблицами или представлениями, к которым они адресуются. В прошлом, работая с большими системами, я обнаружил, что проще реализовать безопасность, основанную на разрешениях на выполнение хранимых процедур, присвоенных ролям базы данных, чем предоставление разрешений на выборку данных из всех моих таблиц. Наконец, я принадлежу к лагерю, который полагает, что хранимые процедуры обеспечивают буфер обслуживания между приложением и таблицами. Этот буфер дает возможность производить изменения схемы, не требуя непосредственного изменения в приложении, "скрывая" эти изменения в хранимых процедурах. Как показывает опыт, зачастую проще написать скрипт, который будет выполнять поиск и замену имени столбца в тысяче хранимых процедур, чем выполнить поиск во множестве модулей кода, внесения изменений, и необходимости повторной компиляции и переустановки новых модулей.
Использование табличных переменных, временных таблиц и постоянных рабочих таблиц
Использование временных рабочих пространств в SQL Server, прежде всего, достигается четырьмя различными способами: курсорами, табличными переменными, временными таблицами, и постоянными рабочими таблицами. В то время как разработчики должны стремиться уменьшить использование этих временных рабочих пространств, используя способность Сервера SQL выполнять операции над множествами записей вместо построчной обработки с помощью курсоров, зачастую временные рабочие пространства используются по другим причинам в процессе выполнения запроса. Когда дело обстоит именно так, от разработчика требуется понимание назначения курсоров, табличных переменных, временных таблиц и постоянных рабочих таблиц, и только тогда применять их, если такие варианты использования памяти нельзя заменить производной таблицей, коррелирующим подзапросом или оператором UNION.
Использование табличных переменных является новой функциональностью в SQL Server 2000 и обещает уменьшать число операций ввода/вывода, связанных с использованием временных таблиц. Вообще говоря, табличные переменные не всегда предотвращают дисковые операции ввода-вывода, поскольку табличная переменная при увеличении ее размеров все же может использовать базу данных tempdb. Табличные переменные действительно создают проблемы производительности при больших наборах данных и должны использоваться только в тех случаях, когда табличная переменная содержит менее 3000 строк данных. Это ограничение на производительность зачастую уменьшает эффективность табличных переменных в больших системах.
Временные таблицы - полезный и часто используемый инструмент, используемый для создания табличной структуры и при необходимости сохранения данных в памяти. Имена локальных временных таблиц, доступных только в текущем подключении или текущему пользователю, должны начинаться с символа #. Локальные временные таблицы удаляются при отключении пользователя от компьютеров, на которых запущен Microsoft SQL Server, или когда завершается выполнение хранимой процедуры, создавшей эти таблицы.
Имена глобальных временных таблиц, доступных любым подключением или пользователем, должны начинаться с двойного символа # (##). Глобальные временные таблицы видимы любому пользователю после их создания; и они удаляются тогда, когда завершаются все процессы, ссылающиеся на такую таблицу. Рекомендуется, чтобы разработчики следовали некоторым важным рекомендациям при использовании временных таблиц.
· Создать временную таблицу непосредственно перед тем, как это необходимо, и выполнять любые операции с таблицей в непосредственной близости к тому моменту, в который она была создана. Это поможет избежать ненужной перекомпиляции.
· Всегда удаляйте (DROP) локальную временную таблицу, когда она уже не нужна. Рекомендуется удалять таблицу сразу после завершения ее использования или, по крайней мере, в конце хранимой процедуры, что является хорошим стилем программирования, связанным с уборкой мусора. Отказ от удаления временных таблиц может привести к утечке ресурсов памяти, что оказывает отрицательное влияние на производительность системы в целом.
· Включайте в таблицу только те столбцы и строки, в которых Вы фактически нуждаетесь, но не более.
Временные таблицы могут постоянно находиться в основной памяти, что обеспечивает более быстрый доступ к хранящимся в них данным по сравнению с извлечением той же самой информации с диска. Эта способность временных таблиц храниться в памяти зависит от объема данных, находящихся в таблице. По мере роста размеров временных таблиц и поскольку на использование памяти сервера оказывает давление множественность выполняемых процессов и т.д., способность SQL Server хранить всю временную таблицу в памяти уменьшается. Это заставляет SQL Server больше обращаться к tempdb для сохранения данных, что может увеличить размер tempdb и вызвать конфликты в этой базе данных.
Временные таблицы долго ассоциировались с плохим выполнением запросов. Хотя это и обычно для временных таблиц, что обусловлено наличием дисковых операций ввода/вывода при работе с временными объектами и конфликтов за ресурсы tempdb, вызываемых многочисленными временными объектами, они, как и курсоры, могут оказаться выгодными при определенных обстоятельствах. Не стоит принижать роль использования временных таблиц. Они оказываются предпочтительными для больших наборов данных по сравнению с табличными переменными. Однако это справедливо только в том случае, когда постоянные рабочие таблицы не могут использоваться из-за конфликтов с данными (когда многочисленные пользователи пытаются использовать одну и ту же постоянную таблицу для работы с различными данными) или когда количество данных, помещаемых во временную таблицу, достигает сотен или тысяч строк.
Когда большие наборы данных требуется где-то временно сохранять, вместо временной таблицы часто лучше использовать постоянную рабочую таблицу.
Постоянные рабочие таблицы являются хорошей альтернативой табличным переменным и временным таблицам для процессов, которые не должны использовать рабочую таблицу совместно с другими процессами. Эти постоянные рабочие таблицы следует создавать с помощью оператора SELECT…INTO, чтобы избежать журнализации, которая выполняется при использовании оператора INSERT.
См. BOL: Temporary Tables, and CREATE TABLE.
(продолжение следует...)
Контакты
По всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте.
| Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.db.sqlex Архив рассылки |
Отписаться
Вспомнить пароль |
| В избранное | ||
