| ← Январь 2006 → | ||||||
|
1
|
||||||
|---|---|---|---|---|---|---|
|
2
|
3
|
4
|
5
|
6
|
8
|
|
|
9
|
10
|
11
|
12
|
13
|
15
|
|
|
16
|
17
|
18
|
19
|
20
|
22
|
|
|
23
|
24
|
25
|
26
|
27
|
29
|
|
|
30
|
31
|
|||||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 71
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 71 (21 января 2006 г.)
 |
Новым посетителям сайтаСайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 58-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов.Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. |
Новости сайта
§ Изменил стилистику формулировки задачи 84 в редакции f.nietzsche.
§ Некоторое затишье в сотне. Видимо происходит процесс количественного накопления перед качественным скачком :-).
В сотне появился ZDomen (задач 94, время 3.266)
Поборов 121 задачу, опять включился в соревнование MadVet, не потерявший шансов попасть в десятку.
MadVet (118, 7.773)
Snowbear (102, 2.444)
§ Продолжили свое восхождение к вершине:
Iris_m (136, 94.806)
Julia_M (121, 26.326)
§ На этой неделе сертифицированы:
User_Name (B06006929) [AR]
§ Число подписчиков - 2856
Число участников рейтинга - 4548
Число участников второго этапа - 470
Сертифицировано на сайте - 48
Лучшие результаты (ТОР 20)
| No | Person | Number of Sel_ex |
Last_Sel | Number of DML_ex |
Scores | Days | Days_2 | LastSolved | LastVisit |
| 1 | Кувалкин К.С. (Cyrilus) | 138 | 138 | 20 | 316 | 387 | 5.234 | 16 Dec 2005 | 20 Jan 2006 |
| 2 | Войнов П.Е. (pаparome) | 137 | 137 | 20 | 312 | 117 | 1.745 | 19 Dec 2005 | 20 Jan 2006 |
| 3 | Абашин П.И. (Dizil) | 137 | 137 | 20 | 312 | 117 | 3.689 | 19 Dec 2005 | 20 Jan 2006 |
| 4 | Голубин Р.С. (Roman S. Golubin) | 137 | 137 | 20 | 312 | 117 | 6.572 | 13 Dec 2005 | 20 Jan 2006 |
| 5 | Самохвалов В. (ValdemarES) | 137 | 137 | 20 | 312 | 40 | 7.530 | 27 Dec 2005 | 20 Jan 2006 |
| 6 | Тарасов Д.Б. (Gavrila) | 137 | 137 | 20 | 312 | 109 | 10.968 | 13 Dec 2005 | 20 Jan 2006 |
| 7 | Крижевич С.А. (yaff) | 137 | 137 | 20 | 312 | 176 | 14.676 | 23 Dec 2005 | 19 Jan 2006 |
| 8 | Иванов А.Н. (Goapsy) | 137 | 137 | 20 | 312 | 60 | 15.958 | 09 Jan 2006 | 16 Jan 2006 |
| 9 | Валуев Д.И. (Fiolent) | 137 | 96 | 20 | 312 | 843 | 28.607 | 25 Dec 2005 | 20 Jan 2006 |
| 10 | Страшников А.С. (EffEct) | 137 | 96 | 20 | 312 | 226 | 58.048 | 27 Dec 2005 | 20 Jan 2006 |
| 11 | Галиаскаров Э.Г. (Galogen) | 137 | 137 | 20 | 312 | 392 | 72.253 | 19 Dec 2005 | 20 Jan 2006 |
| 12 | Духин А. (Shark) | 136 | 137 | 20 | 310 | 148 | 2.746 | 06 Dec 2005 | 15 Dec 2005 |
| 13 | Леденев С.А. (Shurgenz) | 136 | 72 | 20 | 310 | 497 | 11.597 | 28 Dec 2005 | 28 Dec 2005 |
| 14 | Мельникова И.А. (Iris_m) | 136 | 72 | 20 | 310 | 617 | 94.806 | 19 Jan 2006 | 20 Jan 2006 |
| 15 | Носков Н.В. (niko2) | 135 | 137 | 20 | 308 | 163 | 8.002 | 16 Dec 2005 | 16 Dec 2005 |
| 16 | Konyshev (Phohack) | 136 | 136 | 20 | 308 | 266 | 92.956 | 28 Dec 2005 | 29 Dec 2005 |
| 17 | Зверев Д.Л. (dimzv) | 134 | 137 | 20 | 307 | 643 | 2.871 | 08 Aug 2005 | 10 Jan 2006 |
| 18 | Гонтовой В.А. (noname) | 134 | 137 | 20 | 307 | 105 | 9.793 | 29 Jun 2005 | 19 Dec 2005 |
| 19 | Бураков С.Г. (burakov58) | 134 | 137 | 20 | 307 | 164 | 12.079 | 12 Jul 2005 | 04 Dec 2005 |
| 20 | Gershovich V. (VIG) | 135 | 72 | 20 | 306 | 1031 | 13.914 | 06 Jan 2006 | 20 Jan 2006 |
Лучшие результаты за неделю
| No | surname | n_sel | sel_all | sel_scores | dml_scores | scores | rating | last_visit |
| 1 | >Сластихин И. (GoshaS_29) | 58 | 58 | 105 | 32 | 137 | 243 | 20 Jan 2006 |
| 2 | Зырин В.Е. (Vezyr) | 55 | 55 | 97 | 32 | 129 | 328 | 20 Jan 2006 |
| 3 | >Потапченко А.А. (xLightfore) | 57 | 57 | 103 | 19 | 122 | 375 | 20 Jan 2006 |
| 4 | Шкаредный (Gosha) | 42 | 42 | 75 | 17 | 92 | 724 | 20 Jan 2006 |
| 5 | >Зверев К.А. (kaz) | 40 | 40 | 63 | 3 | 66 | 1086 | 20 Jan 2006 |
| 6 | Syazantsev (Siasia) | 32 | 32 | 50 | 9 | 59 | 1248 | 16 Jan 2006 |
| 7 | Клячина К.Н. (Ксения) | 22 | 58 | 55 | 0 | 55 | 552 | 17 Jan 2006 |
| 8 | Бондаревский М.А. (JITter) | 16 | 58 | 36 | 17 | 53 | 374 | 16 Jan 2006 |
| 9 | >Melnyk Y. (YMel) | 27 | 50 | 50 | 3 | 53 | 764 | 20 Jan 2006 |
| 10 | >Suschenko A. (Andru) | 28 | 28 | 49 | 0 | 49 | 1493 | 20 Jan 2006 |
| 11 | >Верхотуров В. (v_vladimir) | 21 | 34 | 45 | 0 | 45 | 1240 | 20 Jan 2006 |
| 12 | m. S.A. (Byxalo) | 27 | 27 | 45 | 0 | 45 | 1599 | 18 Jan 2006 |
| 13 | >tt (Darushka) | 32 | 32 | 42 | 1 | 43 | 1645 | 20 Jan 2006 |
| 14 | Алексеева Е.А. (Gella) | 24 | 50 | 42 | 0 | 42 | 798 | 16 Jan 2006 |
| 15 | >Руппиев С.М. (Gray-Serg) | 21 | 45 | 41 | 0 | 41 | 923 | 20 Jan 2006 |
| 16 | Холин К.В. (f.nietzsche) | 2 | 90 | 6 | 32 | 38 | 111 | 19 Jan 2006 |
| 17 | Зимасов Р.И. (Rusla) | 14 | 58 | 37 | 0 | 37 | 486 | 20 Jan 2006 |
| 18 | >Volkov D.O. (volk) | 24 | 24 | 37 | 0 | 37 | 1857 | 20 Jan 2006 |
| 19 | Перминова Я. (Yaroslava) | 23 | 23 | 35 | 0 | 35 | 1938 | 17 Jan 2006 |
| 20 | >Kuak (SilentS) | 28 | 28 | 35 | 0 | 35 | 1944 | 20 Jan 2006 |
| 21 | >Сурков (lor) | 22 | 26 | 31 | 3 | 34 | 1798 | 20 Jan 2006 |
| 22 | >Пономарев (PonomarevMM) | 23 | 23 | 34 | 0 | 34 | 1996 | 20 Jan 2006 |
| 23 | >Косарев А. (qbert) | 23 | 23 | 34 | 0 | 34 | 2019 | 20 Jan 2006 |
| 24 | Kobelev I. (Kimmy) | 12 | 49 | 29 | 3 | 32 | 788 | 17 Jan 2006 |
Изучаем SQL
Использование монитора производительности для определения узких мест аппаратных средств, на которых запущен SQL Server (окончание, начало в вып.70)
Brad M. McGehee (оригинал: Using Performance Monitor to Identify SQL Server Hardware Bottlenecks)Перевод Моисеенко С.И.
Физический диск: Средняя длина очереди диска
Помимо наблюдения за значением счетчика "Физический Диск: Время работы диска", желательно также отслеживать значения счетчика средней длины очереди диска (Avg. Disk Queue Length). Если это значение превышает значение 2 для непрерывных периодов (свыше 10 минут в течение вашего 24 часового мониторинга) для каждого дисковода в массиве, то этот массив может оказаться узким местом производительности системы. Подобно счетчику времени работы диска, если это происходит изредка в течение 24 часов периода мониторинга, я не сильно бы волновался, но если это происходит часто, тогда я бы начал искать способы увеличить производительность системы ввода/вывода сервера, как это описано выше.
Вам придется вычислить этот показатель, поскольку Performance Monitor не знает, сколько физических дисков находится в вашем массиве. Например, если у вас имеется массив из 6 физических дисков, и средняя длина очереди равна 10 для этого массива, тогда фактическое среднее значение дисковой очереди для каждого диска составляет 1.66 (10/6=1.66), что хорошо укладывается в рекомендованный показатель 2 на один физический диск.
Перед использованием этого счетчика под NT 4.0, не забудьте вручную включить его, набрав на приглашение к вводу команд NT (Command Prompt) следующее: "diskperf-y" с последующей перезагрузка вашего сервера. Поэтому требуется включать дисковые счетчики сразу после установки Windows NT 4.0. Если Вы используете Windows 2000, то этот счетчик будет включен по умолчанию.
Используйте оба описанных выше счетчика, чтобы точно выяснить, испытывает ли ваш сервер проблемы с системой ввода/вывода. Например, если Вы видите много периодов времени, в течение которых время работы диска более 55 %, и когда среднее значение длины очереди диска составляет более 2 на один физический диск, Вы можете быть уверенными, что сервер имеет проблемы с системой ввода - вывода.
Процессор: Процессорное время %
Счетчик Processor Object: % Processor Time имеется для каждого центрального процессора и оценивает использование каждого отдельного центрального процессора. Аналогичный счетчик имеется также для всей совокупности центральных процессоров (общее количество). Это ключевой счетчик для слежения за использованием центрального процессора. Если общее время загрузки процессоров по этому счетчику превышает 80 % в течение непрерывных периодов (свыше 10 минут в течение 24 часового периода мониторинга), то Вы можете считать центральный процессор узким местом системы. Если эти периоды сильной загрузки происходят изредка, и Вы полагаете, что можете смириться с этим, то все в порядке. Но если они возникают часто, Вам следует рассмотреть такие варианты снижения загрузки сервера, как приобретение более быстрых центральных процессоров, установку большего количества центральных процессоров, или приобретение центральных процессоров, которые имеют больший встроенный кэш второго уровня (L2).
Система: Длина очереди процессора
Наряду со счетчиком процессорного времени, Вам следует также контролировать счетчик длины очереди процессора (Processor Queue Length). Если этот показатель превышает значение 2 на один центральный процессор в течение непрерывных периодов (свыше 10 минут в течение вашего 24 часового периода мониторинга), то вероятно это является узким звеном системы. Например, если на Вашем сервере имеется 4 центральных процессора, длина очереди процессора не должна превышать в общей сложности значение 8.
Если длина очереди процессора регулярно превышает рекомендованный максимум, но использование центрального процессора не настолько высоко (что является типичным случаем), то рассмотрите вариант уменьшения значения конфигурационного параметра SQL Server "max worker threads" (максимального числа нитей). Возможной причиной высокого значения длины очереди процессора является наличие избыточного числа рабочих нитей, дожидающихся своей очереди. Уменьшая их число, что Вы и делаете с помощью этого параметра, вынуждает задействовать пулинг нитей (если это еще не имеет место), или повысить его роль.
Используйте оба описанных счетчика совместно, чтобы точно определить, есть ли проблемы с центральным процессором. Если оба индикатора превышают рекомендованные значения в течение одних и тех же непрерывных периодов времени, Вы можете быть уверены, что центральный процессор является слабым местом системы.
Буфер SQL Server: Коэффициент удачного обращения в кэш буфера
Этот счетчик (SQL Server Buffer: Buffer Cache Hit Ratio) показывает, как часто SQL Server обращается к буферу, а не к жесткому диску, чтобы получить данные. В приложениях OLTP, этот коэффициент должен превышать 90 %, а в идеале быть выше 99 %. Если ваш коэффициент удачного обращения в буферный кэш ниже 90 %, Вам следует пойти и купить больше оперативной памяти уже сегодня. Если этот коэффициент лежит в диапазоне между 90 % и 99 %, то Вы должны серьезно рассмотреть вариант покупки дополнительной оперативной памяти, так как чем ближе Вы приближаетесь к 99 %, тем быстрее ваш SQL Server будет работать. В некоторых случаях, если ваша база данных является очень большой, Вам не удастся приблизиться к 99 %, даже если Вы поставите максимально допустимое количество оперативной памяти на вашем сервере. Тогда все, что Вы можете сделать, - это добавить память по максимуму и смириться с существующим положением вещей.
В приложениях OLAP, коэффициент может быть намного меньше из-за природы работы этого OLAP-приложения. В любом случае, увеличение оперативной памяти должно ускорить работу SQL Server.
SQL Server: Пользовательские подключения
Поскольку число пользователей Сервер SQL, влияет на его производительность, рекомендуется следить за счетчиком пользовательских подключений (SQL Server General Statistics Object: User Connections counter). Он показывает число пользовательских подключений, а не число пользователей, которые подключены к SQL Server в данный момент времени.
Если показания этого счетчика превышают 255, то Вам следует увеличить значение конфигурационного параметра "Maximum Worker Threads" (максимальное число рабочих нитей), значение по умолчанию которого равно 255. Если число подключений превышает имеющееся число рабочих нитей, то SQL Server начнет совместно использовать рабочие нити, что может отрицательно сказаться на производительности. Установка этого параметра должна быть выше, чем максимальное число подключений, которое может быть достигнуто на вашем сервере.
Что дальше
Хотя имеется значительно большее число счетчиков, чем те, которые мы рассмотрели, последние являются ключевыми для мониторинга, который выполняется в процессе аудита производительности. После завершения анализа монитора производительности, используйте приведенные рекомендации и далее в этой серии статей, чтобы внести необходимые изменения, которые заставят ваш SQL Server работать так, как он должен.
Контакты
По всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте.
| Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.db.sqlex Архив рассылки |
Отписаться
Вебом
Почтой
Вспомнить пароль |
| В избранное | ||
