| ← Февраль 2006 → | ||||||
|
1
|
2
|
3
|
5
|
|||
|---|---|---|---|---|---|---|
|
6
|
7
|
8
|
9
|
10
|
12
|
|
|
13
|
14
|
15
|
16
|
17
|
19
|
|
|
20
|
21
|
22
|
23
|
24
|
26
|
|
|
27
|
28
|
|||||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 73
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 73 (4 февраля 2006 г.)
|
Новым посетителям сайтаСайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 58-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов.Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. |
Новости сайта
§ На странице с упражнениями SELECT при решении задач второго этапа теперь будет появляться информация о самой лучшей и худшей оценках стоимости имеющихся на данный момент решений данной задачи. Эти оценки будут возникать при повторном решении задачи с целью улучшить план выполнения запроса. Таким образом, одновременно можно будет увидеть оценку предыдущего и нового решений, а также лучший и худший показатели по данной задаче.
§ Произошло прогнозируемое появление dimzv на третьей стартовой позиции перед финишным рывком (задач 137, время 3.135). Теперь будем ждать, когда он примется за 138 задачу, присоединившись к решающим ее уже шести участникам. Самураев было семь :-).
§ Приблизились к десятке:
MadVet (124, 8.749)
Snowbear (120, 2.735)
§ Продолжили свое восхождение к вершине:
User_Name (126, 22.293) f.nietzsche (97, 11.809) Lady (97, 12.189)
Vezyr (A06008123) [BK]
horr (A06007742) [BK]
§ Число подписчиков - 2880
Число участников рейтинга - 4691
Число участников второго этапа - 479
Сертифицировано на сайте - 50, 51
Лучшие результаты (ТОР 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 | 03 Feb 2006 |
| 2 | Войнов П.Е. (pаparome) | 137 | 137 | 20 | 312 | 117 | 1.745 | 19 Dec 2005 | 03 Feb 2006 |
| 3 | Зверев Д.Л. (dimzv) | 137 | 96 | 20 | 312 | 819 | 3.135 | 31 Jan 2006 | 31 Jan 2006 |
| 4 | Абашин П.И. (Dizil) | 137 | 137 | 20 | 312 | 117 | 3.689 | 19 Dec 2005 | 31 Jan 2006 |
| 5 | Голубин Р.С. (Roman S. Golubin) | 137 | 137 | 20 | 312 | 117 | 6.572 | 13 Dec 2005 | 03 Feb 2006 |
| 6 | Самохвалов В. (ValdemarES) | 137 | 137 | 20 | 312 | 40 | 7.530 | 27 Dec 2005 | 03 Feb 2006 |
| 7 | Тарасов Д.Б. (Gavrila) | 137 | 137 | 20 | 312 | 109 | 10.968 | 13 Dec 2005 | 03 Feb 2006 |
| 8 | Крижевич С.А. (yaff) | 137 | 137 | 20 | 312 | 176 | 14.676 | 23 Dec 2005 | 28 Jan 2006 |
| 9 | Иванов А.Н. (Goapsy) | 137 | 137 | 20 | 312 | 60 | 15.958 | 09 Jan 2006 | 02 Feb 2006 |
| 10 | Валуев Д.И. (Fiolent) | 137 | 137 | 20 | 312 | 843 | 28.607 | 25 Dec 2005 | 03 Feb 2006 |
| 11 | Страшников А.С. (EffEct) | 137 | 137 | 20 | 312 | 226 | 58.048 | 27 Dec 2005 | 03 Feb 2006 |
| 12 | Галиаскаров Э.Г. (Galogen) | 137 | 137 | 20 | 312 | 392 | 72.253 | 19 Dec 2005 | 24 Jan 2006 |
| 13 | Мельникова И.А. (Iris_m) | 137 | 137 | 20 | 312 | 622 | 96.852 | 24 Jan 2006 | 30 Jan 2006 |
| 14 | Духин А. (Shark) | 136 | 137 | 20 | 310 | 148 | 2.746 | 06 Dec 2005 | 15 Dec 2005 |
| 15 | Леденев С.А. (Shurgenz) | 136 | 137 | 20 | 310 | 497 | 11.597 | 28 Dec 2005 | 28 Dec 2005 |
| 16 | Носков Н.В. (niko2) | 135 | 137 | 20 | 308 | 163 | 8.002 | 16 Dec 2005 | 16 Dec 2005 |
| 17 | Konyshev (Phohack) | 136 | 136 | 20 | 308 | 266 | 92.956 | 28 Dec 2005 | 29 Dec 2005 |
| 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 | 136 | 20 | 306 | 1031 | 13.914 | 06 Jan 2006 | 03 Feb 2006 |
Лучшие результаты за неделю
| No | surname | n_sel | sel_all | sel_scores | dml_scores | scores | rating | last_visit |
| 1 | Петров (vp) | 45 | 51 | 82 | 23 | 105 | 470 | 03 Feb 2006 |
| 2 | >Isaev (IKV) | 58 | 58 | 105 | 0 | 105 | 551 | 03 Feb 2006 |
| 3 | >Зайка В. (VZaya) | 48 | 48 | 79 | 9 | 88 | 775 | 03 Feb 2006 |
| 4 | >Садникова С.А. (SSvetlana_1) | 44 | 44 | 70 | 9 | 79 | 893 | 03 Feb 2006 |
| 5 | Kuchmai J. (Loona) | 37 | 37 | 52 | 0 | 52 | 1437 | 31 Jan 2006 |
| 6 | >Кабаченко Д.В. (voodoo) | 10 | 64 | 18 | 32 | 50 | 208 | 03 Feb 2006 |
| 7 | >Щукин А.С. (Faust) | 20 | 51 | 49 | 0 | 49 | 718 | 03 Feb 2006 |
| 8 | >Коренко (FanOfBeer) | 33 | 33 | 42 | 3 | 45 | 1635 | 03 Feb 2006 |
| 9 | >Арыков М.С. (arm) | 26 | 26 | 44 | 0 | 44 | 1649 | 03 Feb 2006 |
| 10 | >Тарасов Д.А. (Di_ma) | 26 | 26 | 43 | 0 | 43 | 1682 | 03 Feb 2006 |
| 11 | z N.V. (Nadia) | 27 | 34 | 40 | 0 | 40 | 1587 | 01 Feb 2006 |
| 12 | >Халанский Д.В. (junix12) | 25 | 25 | 40 | 0 | 40 | 1782 | 03 Feb 2006 |
| 13 | >Шкаредный (Gosha) | 18 | 77 | 39 | 0 | 39 | 150 | 03 Feb 2006 |
| 14 | Нестеренко И.А. (IgorN) | 19 | 41 | 39 | 0 | 39 | 983 | 31 Jan 2006 |
| 15 | >Аверина Т.А. (Tasya) | 27 | 27 | 38 | 1 | 39 | 1815 | 03 Feb 2006 |
| 16 | >Павлов А.В. (Антон) | 8 | 66 | 15 | 23 | 38 | 186 | 03 Feb 2006 |
| 17 | Ким А.Ф. (Ким_Александр) | 17 | 34 | 38 | 0 | 38 | 1285 | 02 Feb 2006 |
| 18 | Jensen (George056) | 21 | 33 | 30 | 8 | 38 | 1471 | 01 Feb 2006 |
| 19 | Замураев А. (zamuraev) | 13 | 37 | 28 | 9 | 37 | 980 | 03 Feb 2006 |
| 20 | Bogadnov (Rainbow) | 24 | 24 | 37 | 0 | 37 | 1869 | 30 Jan 2006 |
| 21 | Глушков Р.А. (Glushkoff) | 24 | 24 | 37 | 0 | 37 | 1880 | 31 Jan 2006 |
| 22 | >Москвитин Е. (Eugeny M) | 24 | 24 | 37 | 0 | 37 | 1898 | 03 Feb 2006 |
| 23 | Скворцов В.А. (V_Sk) | 14 | 54 | 33 | 0 | 33 | 677 | 31 Jan 2006 |
| 24 | Pupkin (User11) | 18 | 18 | 25 | 8 | 33 | 2062 | 02 Feb 2006 |
| 25 | Шумский А.С. (alex3d) | 17 | 22 | 31 | 0 | 31 | 1969 | 28 Jan 2006 |
| 26 | >Evdokimov P.V. (Pascal) | 22 | 22 | 31 | 0 | 31 | 2206 | 03 Feb 2006 |
| 27 | >Зырин В.Е. (Vezyr) | 15 | 86 | 30 | 0 | 30 | 121 | 03 Feb 2006 |
Изучаем SQL
Контрольный список вопросов оценки производительности аппаратных средств SQL Server (продолжение, начало в вып.72)
Brad M. McGehee (оригинал: SQL Server Hardware Performance Checklist )Перевод Моисеенко С.И.
Скорость центрального процессора
Как и число центральных процессоров, также трудно оценить необходимую скорость приобретаемых центральных процессоров. Вообще говоря, как и в случае с числом центральных процессоров вашего SQL Server, имеет смысл покупать самые скоростные центральные процессоры, которые Вы себе можете позволить. Лучше купить систему, которая превышает ваши потребности, чем ту, мощность которой окажется недостаточной.
Кэш L2 центрального процессора
Один из самых часто задаваемых мне вопросов: "Купить ли менее дорогой центральный процессор с небольшим кэшем L2, или предпочесть дорогой центральный процессор XEON с большим кэшем L2?" Усложняет решение тот факт, что Вы можете купить при меньшем кэше L2 более быстрые чипы, чем чипы, которые имеют большой кэш L2. Мое эмпирическое правило таково:
· Если Вы будете использовать только 1 или 2 центральных процессора, приобретайте с самые быстрые центральные процессоры, которые Вам доступны, рассматривая вопрос о размере кэша L2 как вторичный. Если у вас есть возможность выбора размера кэша L2, всегда приобретайте максимально возможный.
· Но если Вы будете использовать 4 или более центральных процессора, тогда первичным является вопрос наибольшего кэша L2, даже при том, что скорость таких процессоров, возможно, не столь высока. Причина такого решения состоит в том, что для оптимальной работы SQL Server на серверах с четырьмя и более центральными процессорами, кэш L2 должен быть намного большим, в противном случае Вы будете тратить впустую большую часть мощности дополнительных центральных процессоров.
Контрольный список вопросов аудита центрального процессора
Так как данная статья посвящена аудиту имеющихся возможностей центрального процессора для вашего SQL Server, внимание должно быть сфокусировано на определении узких мест центрального процессора имеющихся серверов. Как уже обсуждалось в разделе, посвященном монитору производительности, вы можете использовать его для идентификации узких мест аппаратных средств.
Если у вас нет проблем с центральным процессором, то Вы можете перейти к следующему разделу, посвященному памяти. Но если ваш сервер критичен относительно центрального процессора, и это настолько очевидно, чтобы являться главным источником проблем производительности, тогда рассмотрите варианты устранения этого слабого места:
· Уменьшите нагрузку на ваш сервер. Этого можно достичь уменьшением числа пользователей, оптимизацией запросов, настройкой индексов, а также удалением любых необязательных приложений, выполняющихся на данном сервере. Один из вариантов заключается в перемещении приложений, занимающихся генерацией отчетов, с вашего промышленного сервера на SQL Server, выделенный исключительно под отчеты.
· Добавьте памяти, т.к. проблемы центрального процессора могут быть вызваны нехваткой памяти на сервере, что обычно имеет место.
· Поставьте дополнительные центральные процессоры, если Ваш сервер это позволяет.
· Установите более быстрые центральные процессоры на вашем сервере, если это возможно.
· Купите новый сервер с большим числом процессоров, а также и более быстрых.
К сожалению, ни один из этих вариантов, относящихся к устранению проблем с центральным процессором, будет не очень просто осуществить, если ваша компания ограничена в средствах. Как администратору базы данных, отвечающему за SQL Server, который имеет слабым звеном центральный процессор, Вам предстоит решить много трудных проблем и выполнить много работы, особенно если вашим единственным вариантом из-за нехватки денег остается "уменьшить нагрузку на ваш сервер."
Память
Хотя память сервера рассматривается здесь после обсуждения центрального процессора, не думайте, что память менее важное звено, чем центральный процессор вашего сервера. Фактически, память, вероятно, самый важный компонент аппаратных средств для любого SQL Server, который влияет на его работу больше, чем любые другие аппаратные средства.
Когда мы говорим о памяти, то имеем в виду физическую оперативную память - RAM. Часто слово память (в мире Windows Server) относят к физической оперативной памяти и виртуальной памяти (файл подкачки). Это определение не вполне хорошо для SQL Server, потому что SQL Server действительно не спроектирован на использование виртуальной памяти, хотя и может, если она имеется.
Вместо того, чтобы использовать комбинируемую операционной системой физическую оперативную память и память виртуальную, SQL Server предпочитает оставаться в рамках физической оперативной памяти столько, сколько сможет. Причиной этого является скорость. Доступ к данным в оперативной памяти выполняется намного быстрее, чем извлечение их с диска.
Когда SQL Server не может сохранить все данные, которыми он манипулирует, в оперативной памяти (кэш буфера SQL Server), происходит обращение к диску, аналогично тому, как операционная система управляет виртуальной памятью. Но "кэширующий" механизм SQL Server более сложен и быстрее чем тот, который обеспечивает виртуальная память операционной системы.
Самый быстрый способ узнать, имеет ли ваш SQL Server адекватное количество оперативной памяти, состоит в том, чтобы проверить счетчик SQL Server: Buffer Cache Hit Ratio (коэффициент удачного обращения в кэш буфера), который обсуждался в предыдущей статье. Если этот счетчик показывает 99 % или выше, то наиболее вероятно, что Вы имеете достаточно физической оперативной памяти на вашем SQL Server. Если показания этого счетчика находятся в интервале между 90 % и 99 %, и если Вы удовлетворены производительностью вашего SQL Server, то Вы вероятно имеете достаточно физической оперативной памяти на вашем SQL Server. Но если Вас не устраивает производительность сервера, тогда следует добавить оперативной памяти.
Если счетчик показывает меньше 90 %, это показатель того, что производительность вашего SQL Server является неприемлемой (если Вы выполняете OLAP-приложения, то менее 90 % это вообще-то в порядке вещей), и Вам следует добавить оперативной памяти на сервер.
Идеально, количество физической оперативной памяти в SQL Server должно превышать размер наибольшей базы данных из имеющихся на сервере. Это не всегда возможно, так как зачастую базы данных являются очень большими. Если Вы размещаете новый SQL Server и полагаете, что ваш бюджет является достаточно большим, попробуйте заказать такой SQL Server, который бы имел в своем распоряжении такой объем RAM, чтобы в ней могла разместиться вся проектируемая база данных. Если ваша база данных не превышает 4Гб, это обычно не вызывает проблем. Но если ваша база данных больше (или ожидается, что она станет больше 4Гб), тогда Вам, возможно, не удастся легко получить более 4Гб оперативной памяти. В то время как SQL Server 2000 Enterprise Edition поддерживает до 64Гб оперативной памяти, не слишком много имеется доступных серверов, которые поддерживают такой объем RAM.
Даже если вся ваша база данных не может вписаться в кэш буфера SQL Server, то SQL Server может все еще быть очень быстрым, когда наступает время извлекать данные. При 99%-ом отношении удачного обращения в кэш буфера в 99 % времени данные, которые необходимы SQL Server, уже находятся в кэше, и производительность будет очень высока. Например, я управляю одной базой данных, которая имеет размер 30Гб, но сервер при этом имеет только 4Гб оперативной памяти. Отношение удачного обращения в кэш буфера для этого сервера всегда более, чем 99.6 %. Это означает, что в большинстве случаев пользователи обращаются не ко всем данным в базе данных в одно и то же время, а только к некоторой их части, в результате чего SQL Server имеет возможность сохранять наиболее часто используемые данные в кэше постоянно. В этом специфическом случае, 99 % всех запросов выполняются быстро, даже при том, что сервер имеет намного меньше физической оперативной памяти чем объем данных в базе данных.
Что из этого следует? Если в вашем случае отношение удачных обращений в кэш буфера менее 90 %, то следует серьезно отнестись к увеличению количества оперативной памяти.
(Продолжение следует...)
Контакты
По всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте.
| Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.db.sqlex Архив рассылки |
Отписаться
Вебом
Почтой
Вспомнить пароль |
| В избранное | ||
