О рулезности ODBC

Старый, зато надежный

Оно конечно, статья эта более была бы уместна году эдак в 1993-96. Ныне в наш век повсеместного управляемого кода все и забыли что есть код неуправляемый, который работает на порядок-два быстрей. Так что если что-то надо сделать быстро, выбираем неуправляемый код. Если что-то хотите сделать быстро с базой, например – вызов большого количества хранимых процедур, то лучше ODBC вам не найти.

Кто же добрую скотину гонит со двора

В MS SQL, например, появилась новая клиентская либа – MS Native Client. К ней идет и полнофункциональный, самый современный вариант старого доброго ODBC. Так вот. Помимо прочих достоинств он офигительно, непредставимо быстр. OleDb и .Net провайдеры просто отдыхают по сравнению со связкой Win32-NativeClient- ODBC

Преимущества ODBC

1. Он прост, хоть и кажется сложным. Честное слово, по сравнению с OLEDB – сама простота.
2. Он аккуратно написан, в отличие от современного софта. Вы можете сами в этом убедиться, запустив программу, использующую ODBC из-под BoundsChecker’а.
3. Он очень быстр. Загрузка курсора на борт раз эдак в пять быстрей, чем в ADO.
4. Он поддерживается в самых современных версиях СУБД (хоть бы тот же MS SQL)
5. Он переносим на LInux (Unix ODBC)  – я пробовал, все замечательно.
6. Есть специфические фичи – например, пакетирование вызова процедур. Предствавьте, что Вам надо дернуть хранимую процу 1500 раз с разными параметрами. ADO потратит на это 1500 round – trip’ов. ODBC в режиме пакетирования (Column Wise or Row -wize) – только один. Разница по времени офигенная.

Недостатки ODBC

1. Вызовы громозкие. Данных типа Variant (object) нет. Въезжать по началу сложно.
2. Чувствителен к последовательности вызовов, как что не по нему – кричит
3. Обработка ошибок несколько витиевата.

В общем, потратьте немного времени на изучение этого старого надежного интерфейса – пригодиться.

Ускоряем базу – 4

Общее

Это статья из цикла “Укорение работы баз данных под управлением СУБД MS SQL“.  Сегодня я расскажу про оптимизацию собственно базы.

Размер базы данных

Для достижения наибольшего быстродействия лучше всего, если Вы будете представлять, каков суточный (часовой, минутный) прирост базы ожидается и соответственно настроить размер базы заранее. Совсем хорошо, если размер не будет превышать определенной установленной величины – например, данные будут периодически архивироваться. В этом случае можно заранее настроить базу на нужный размер. Ни в кем случае нельзя оставлять значения по умолчанию – т.е. автоувеличение на один мегабайт. Для баз данных с интенсивной вставкой (особенно блобов) это может оказаться в буквальном смысле смертельным – дисковая подсистема перегреется от нагрузки и выгорит (имеется прецедент). Ставьте прирост 30-50%. Ставьте большое начальное значение размера. В общем и целом – представляйте свою базу. Не поленитесь провести измерения. Чем реже база будет автоувеличивать свой размер, тем лучше для быстродействия и нагрузки на физические носители.

Дефрагментация

Сначала поговорим про дефрагментацию файловой системы. Последовательность действий примерно такая:

1. поставить OS и MS SQL.
2. дефрагментировать диск
3. создать нужные базы, растянув их, если возможно, на максимальный размер
4. дефрагментировать диск

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

 

Журналы

Для баз с интенсивными изменениями данных (OLTP) обязательно выносите лог на отдельный физический диск, (дисковый массив). Разумеется, требования по быстройдействию к такому диску поменьше, но все равно он должен быть заточен под быструю последовательную вставку. В порядке предпочтения устройства для хранения лога:

1. отдельный RAID – массив
2. отдельный набор дисков на том же RAID _ массиве (хорошо бы назначить им отдельный SCSI ID,  а не просто LUN)
3. отдельный зазеркалированный диск (SAS  в случае сервера или на худой конец SATA)
4. просто отдельный диск
5. отдельный логический диск на том же RAID

 Логические диски не-RAID эффекта не дают, а вот на RAID, особенно с хорошим софтом, попробовать можно. RAID’ы всякую там статистику считают и пр. Хотя на RAID’е есть хороший софт, пусть будет отдельный логический RAID.

 Закон Мура

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

Распилка базы

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

Анализ и эксперименты

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

Ускоряем базу – 3

Общее

Это статья из цикла “Укорение работы баз данных под управлением СУБД MS SQL“. Предмет этой статьи – общая оптимизация SQL сервера. Самое главное – не используйте сервер для других нужд. Лишние службы и лишние привязки протокола желательно вообще отключить. Если физический сервер планируется заюзать как SQL, все, никаких расшаренных папок, никаких копирований файла. Файловый сервер – это отдельная роль, которая по-другому настраивается.

 

Кое-что в настройках OS

Во-первых, ставим другой режим распределения ресурсов для сети. Выбираем сетевое подключение, выбираем клиента для сетей MS, ставим галки как показано на рисунке:

 

На самом деле, может быть третья или четвертая галка. По теории, подтверждаемой практикой (чтоб там не говорили ребята из MS и их сертифицированные энги ( низшие существа. Если будете грешить в этой жизни, возродитесь как звери, или как MCSE) ) – четвертая галка, “Макс. пропускная способность для сетевых приложений“. В свойствах компьютера, в Advanced (дополнительно), выбираем быстродействие и ставим галки так:

 

Почему именно так, а не иначе? Во-первых, SQL и есть сетевое приложение. Во-вторых, файловый кеш ему не в кассу, у него этот кеш свой. 

Про сетевое оборудование

Если есть возможность, запаситесь гиговым свитчом и гиговыми же картами. В сети клиент – SQL лучше иметь некоторый запас по полосе. И пускать этот трафик как-нибудь отдельно, например – внутри VLAN. Лучше не допускать перерывов связи между клиентом и SQL. Немноги приложения умеют обрабатывать ошибки связи с SQL (мои – умеют), особенно какие-нибудь сервера. Оно и безопаснее…

Память

Если используете AWE, ограничьте ее некоторой разумной величиной. Иначе SQL сожрет ее всю, ничего не оставив OS. OS обидиться и затормозит:( А вообще, не парьтесь, если процы поддерживают – ставьте 64-х разрядную версию всего софта (OS & SQL) и забывайте про проблемы с памятью. SQL 64 – и правда быстрее, особенно на крупных системах. Кроме того, он лучше реагиует на нагрузку – меньше грузит процы. Если 32-х разрядная система уменьшает производительность скачкообразно при превышении некоторой критической нагрузки, то 64-разрядная версия делает это плавно-плавно. Мы проводили эксперимент – на машине было два комплекта OS & SQL, натравленные на один набор дисков. Вставляли, помниться, блобы в конкурентном режиме при блокировке SERIALIZABLE, в общем, тяжелый режим и все такое. 32-х разрядный комплект загнулся, а 64-выжил.

TempDb

Напихать туда файлов на все доступные диски(физические диски). Сделав так, сильно ускорите быстродействие административных средств, запросов с сортировкой, баз с режимом версионинга и пр.

Посторонний софт

Лучше отключить ненужные службы. Конечно, при современных мощностях десяток служб не пойнт, но вот например шаринг файлов лучше отключить, и не использовать SQL для хранения файлов. Лишние привязки(балансеры, сетевые фильтры) тоже лучше срубить.

Полезные и очень полезные ссылки

http://www.sql-server-performance.com/

http://www.sql.ru

http://www.microsoft.com/sqlserver

 Интересная дискуссия на эту тему :

http://www.sql.ru/forum/actualthread.aspx?bid=1&tid=231471&pg=-1

 

Ускоряем базу – 2

Общее

Это статья из цикла “Укорение работы баз данных под управлением СУБД MS SQL“. Сегодня мы рассмотрим дисковые полки и их применение для размещения баз данных.

Что такое дисковая полка

Дисковая полка – это внешний программно – аппаратный RAID-массив (с множеством полезных дополнительных функций), подключенный к хост – машине через высокоскоростную магистраль передачи данных – через SCSI U320 Мбит / сек или оптический интерфейс (Будете выбирать – выбирайте оптику, с проводным кабелем могут выйти проблемы. Разъем не тот, контроллер не тот, терминатор не той системы и не там стоит, шланг длинный слишком и пр. Идут ошибки по магистрали, а откуда?) . Дисковая полка при грамотном планировании может обеспечить Вам  готовность 24×7. Вот только грамотное планирование и администрирование такого аппарата – отнюдь не простая задача. Завидую ребятам на mainframe – там есть отдельная группа администраторов внешних устройств, например дисковых, и у Вас голова совершенно не болит об этом деле. Ладно. Полок масса типов. Выбирайте фирменные – HP например. Выбирайте полку с как можно большим количеством дисков. Для небольших контор рекомендую не менее чем 24-х дисковые полки. Почему – объясню далее. Как правило, в полке есть своя встроенная батарея на случай падения питания, и свой интерфейс для управления UPS (и всегда непонятно, как его сопрячь с тем УБП, от которого питается компутер).

Некоторые термины

1. Физический диск (physical drive) - это, собственно, винчестер, с интефейсом SCSI, SAS или SATA, в общем, что побыстрей.
2. Логический диск (logical drive) – это уже результат объединения физических дисков в RAID, так сказать внешняя точка зрения на RAID. BIOS и OS видят RAID именно как логический диск
3. Логический том (Logical volume) – результат объединения нескольких логических или физических дисков в одно целое.
4. Раздел (Partition) - фрагмент логического тома (логического диска, физического диска), имеющий отдельный номер в системе (для SCSI – SCSI-ID\LUN)
5. Диск горячей замены (Hot Spare) – специально выделенный в полке диск, который подключается в случае выхода из строя одного из штатных дисков текущего массива.

Строго говоря, все вышеперечисленные сущности  могут иметь отдельный номер.  Если с физическими и логическими дисками всем интуитивно все ясно, с логическим томом ясно не всем и не все. Ну это до первого креша. Как только креш случился, сразу понимаешь, зачем нужен логический том…В простых словах: RAID-5, например, переносит падение только одного диска. Если есть резервный диск (Stand-by, Hot Spare) , RAID молча восстановиться и мы ничего не заметим. Но это – при отказе одного диска. Отстой заключается в том, что полку и винты покупают махом, и винты идут все одной серии. Разумеется, они махом и в одно и тоже время и выгорают!!! Сгорает сразу минимум два накопителя. Это – фатальный отказ. Посему делаем RAID-6 (посмотрите сами, что за RAID-6, ну лениво мне писать) или бацаем логический том. Логический том – это два RAID’а, два логических диска, объедиенных в один накопитель большей емкости. Пусть сгорают два винта. Вероятность, что они сгорят в одном месте, вдвое меньше. Конечно, нужно постараться разнести эти диски в разные стороны, под разные шины, источники питания, даже под разные вентиляторы. Вы уж постарайтесь.

 Преимущества полок перед накопителями других типов

1. Полка работает очень быстро. Даже проводная магистраль обеспечивает 360 мегабит в секунду. SCSI-винчестеры тоже очень быстрые.
2. Полка содержит большой объем данных. Одна полка несет от одного до N терабайт памяти. Полки можно объединять в цепочку.
3. На полке можно создать не один, а несколько массивов с разными характеристиками и оптимизировать их по-разному.
4. Диски все можно менять “на ходу” – корзина предусматривает горячую замену. Если массив сконфигурирован соотв. образом и имеет диск Hot-Spare, диск замениться без вашего участия;
5. Полка в высшей степени конфигурируема. Можете создавать разделы, логические диски, логические тома, назначать им разные адреса, в общем, есть где развернуться.
6. К полке прилагается внушающий доверие софт для конфигурирования, поддержки, измерения и прочее. Ведется подробный журнал операций, выписываются ошибки, даются рекомендации.
7. К полкам идет хорошая поддержка со стороны производителя.
8. Если хост-компьютер рухнет, на полке это никак не отразиться
9. Полку можно использовать для создания кластера.

 Недостатки полок

Разумеется, есть и недостатки. Куда ж без них…

1. Полку надо поддерживать. Смотреть в лог, настраивать отсылку предупреждений, следить за статистикой. Кроме того, надо регулярно менять сгоревшие винты.
2. Полка тяжело настроить, особенно без подготовки в первый раз. Я, помниться, очень затруднялся. Руководства достаточно убогие. Предполагается, что админ в совершенстве знает, что такое SCSI, LUN, Host mode, разбирается в скоростях, типах, разъемах, терминаторах…(Вообще-то должен)
3. Полке лучше обеспечить бесперебойное питание. Это не так просто, особенно в разрезе синхронизации с компьютером.
4. Сразу настроить полку на максимальное быстродействие не получиться – необходимо поэкспериментировать с разными конфигурациями, причем лучше в условиях, близких к боевым…
5. Полка здорово греется, учитывайте это.
6. Полка чувствительна к электромагнитным возмущениям, поэтому не стоит пихать ее в стойку сразу над ИБП (ибо есть печальные прецеденты. Один мой знакомый перец никак не мог въехать, почему у него в полке выгорает нижний ряд винтов все время. Я ему объяснил, бедняге.)

Полки и SQL – сервер

Слава Богу, добрались до сути дела.  Первым делом припоминаем идеальную конфигурацию базы – система (1й диск), данные (2й диск), логи(3й диск). Про оптимальное расположение базы по файлам – см. мою статью про файловые группы. Скажу сразу, парни – даже при такой простой раскладке результат получается отличный. Соображения по поводу выбора RAID’а:

1. Данные надо писать быстро – выбираем RAID 01.
2. Данные надо читать быстро – любой RAID хорошо, RAID 0 лучше всего. RAID 01 – чуть чуть похуже. Проблема с RAID 0 такая, что он не избыточный.
3. Логи – просто зеркалируем, там особого быстродейстия не требуется – RAID1(RAID01). В такой раскладке можно включить в базе Recovery Model в Full. Лог нужно сохранить по-любому.
4. Для остального барахла, временных баз и прочего – RAID5.

По поводу RAID5 – массив хороший, можно сколько хочешь дисков туда напихать,  но если накроются два диска сразу – все, привет.   Поэтому делаем RAID 01 или RAID6. Последний – просто бетонный. Сверхнадежный, но требует большого расхода дисков. Помимо вышеприведенных соображений, надо еще иметь ввиду, какого рода доступ преимущественно имеет место в базе – последовательный, запись за записью или случайный. RAID’ы ведут себя по-разному. Логи пишутся последовательно;данные могут писаться и читаться в произвольном порядке. В общем, есть поле для экпериментов.

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

 

Ускоряем базу – 1

Общее

Это статья из цикла “Укорение работы баз данных под управлением СУБД MS SQL“. Сегодня мы рассмотрим файловые группы базы данных.

Зачем нужны файловые группы SQL

Оставлять большую базу данных в виде двух сегенерированных по умолчанию файлов – наихудшая практика. Оставить базу в таком положении можно лишь для разработки и очень небольших баз. В остальных случаях следует разбить базу данных по группам и файлам. Ниже мы рассмотрим разбиение базы данных по файловым группам. Итак, файловые группы нужны нам для:

1. обеспечения работы секционирования (partitioning) больших таблиц
2. для ускорения работы базы путем разнесения таблиц с существенно различными характеристиками доступа по разным файлам и дискам
3. для поддержки многопроцессорных платформ
4. отделения индексов от таблиц и вынесения колонок типа BLOB в отдельные файлы (группы)
5. обеспечения работы базы в условиях нехватки дискового пространства
6. для организации раздельных backup’ов.

 

 Рассмотрим каждое из применений. Обеспечение секционирования базы таблицы (индекса). Довольно часто встречается ситуация, когда нужно хранить данные в одной большой таблице. Всякие там истории транзакций, архивы операций, журналы и прочее. И нет никакой возможности куда-либо это слить из базы. Со временем такая таблица разрастается, занимает много места на томе, все больше и больше времени уходит на поиск  в ней и ее дефрагментацию. Поэтому все нормальные СУБД (с версии 2005 – и MS SQL, наконец-то) предлагают таблицы секционировать, разбить на разделы – partitions, по какому-либо признаку, скажем, по месяцам. Каждый фрагмент такой таблицы будет помещен в свой файл (группу файлов). СУБД в случае секционированной таблицы не тратит время, чтобы лопатить весь файл базы, а ориентируется по индексу и читает\пишет данные сразу в/из нужного файла. Таким образом мы экономим на времени и, что немаловажно, на блокировках. Кроме того, каждую файловую группу можно забэекапить отдельно.

Разнесение разных таблиц по файловым группам. Нетривиальная база содержит десятки, если не сотни таблиц. Доступ к этим данным совершенно отчетливо разный – одни используются редко, вторые – часто. В одни больше пишем, вторые читаем. Скажем, редко используемые справочники мы поместим в отдельную файловую группу и переведем на медленный диск. А оперативные данные – на самый быстрый. Архив – тоже на медленный, но на большой. С целом быстродействие системы, время ее отклика повыситься, так как разные по характеру запросы перестанут отнимать друг у друга диск (файл, группу файлов). Бессмысленно смотреть в профайлер, пытаясь понять, почему запросы тормозят. Нужно посмотреть в другое место (анализ базы и счетчики- в отдельной статье). 

Поддержка многопроцессорных систем. В то время как однопроцессорная система только делает вид, что умеет выполнять несколько процессов одновременно, многопроцессорные системы реально выполняют задачи в параллель. В том числе – и задачи записи и чтения данных на диск. Можно позволить SQL – серверу использовать несколько процессоров для одновременной записи данных на диск, создав в базе несколько , так сказать, “беговых дорожек”. Гипертрединг лучше отключить, все равно SQL не понимает, что это такое. Следует поэкспериментровать с этим. У меня получались наилучшие результаты при числе файлов, равном удвоенному числу процессоров, без учета гипертрединга (гипертредный процесссор считается за единицу).

Отделение индексов и блобов. Тут то же соображение, что и во втором пункте – индекса и сами данные суть различающиеся по активности единицы. БЛОБы вообще храняться в базе отдельно. Посему в активно используемой базе индекса сдедует хранить отдельно, особенно учитывая возможность их отключения (потенцальную возможность), а также необходимость их регулярного перестроения. Лучше перестроить один маленький файлик, чем базу на 2000 Гигабайт, а? Кластерные индексы не в счет, они все равно представляют в конечном счете сами данные. Так что с кластерными не получиться. БЛОБЫ вообще отдельный вопрос. Если две таблицы имеют два блобовых поля, храните эти блобы по разным группам.

Нехватка дискового пространства. Тут все просто. Представим, что мы слегка просчитались, и база вот-вот заполнит диск. Места там уже нет, том не расширяемый. Что делать? Добавить в базу файл на другом диске, лучше – отдельной группой. 

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