Прискорення роботи бази даних, peter - s blog

Розмір бази даних

Для досягнення найбільшого швидкодії найкраще, якщо Ви будете представляти, який добовий (часовий, хвилинний) приріст бази очікується і відповідно налаштувати розмір бази заздалегідь. Зовсім добре, якщо розмір не буде перевищувати певної встановленої величини - наприклад, дані будуть періодично архівувати. В цьому випадку можна заздалегідь налаштувати базу на потрібний розмір. Ні в ким разі не можна залишати значення за замовчуванням - тобто автоувеліченіе на один мегабайт. Для баз даних з інтенсивної вставкою (особливо Блоб) це може виявитися в буквальному сенсі смертельним - дискова підсистема перегріється від навантаження і вигорить (мається прецедент). Ставте приріст 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, ксати, рулить. Рекомендую.

Не забувайте розпилювати базу по файлах, групам, дискам. Детальніше я говорив про це в статті, присвяченій файловим групам. Зауважу одне - якщо є в базі запити, які стосуються абсолютно різних таблицях і різні за часом виконання - базу краще розпиляти.

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

Дещо в налаштуваннях 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-вижив.

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

Краще відключити непотрібні служби. Звичайно, при сучасних потужностях десяток служб не пойнт, але ось наприклад шаринг файлів краще відключити, і не використовувати 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. Полку треба підтримувати. Дивитися в лог, налаштовувати відсилання попереджень, стежити за статистикою. Крім того, треба регулярно міняти згорілі гвинти.
  2. Полку важко налаштувати, особливо без підготовки в перший раз. Я, пам'ятається, дуже було важко. Керівництва досить убогі. Передбачається, що адмін досконало знає, що таке SCSI, LUN, Host mode, розбирається в швидкостях, типах, роз'єми, термінаторів ... (Взагалі-то повинен)
  3. Полиці краще забезпечити безперебійне живлення. Це не так просто, особливо в розрізі синхронізації з комп'ютером.
  4. Відразу налаштувати полку на максимальну швидкодію не вийти - необхідно поекспериментувати з різними конфігураціями, причому краще в умовах, близьких до бойових ...
  5. Полку здорово гріється, враховуйте це.
  6. Полку чутлива до електромагнітних збурень, тому не варто пхати її в стійку відразу над ДБЖ (бо є сумні прецеденти. Один мій знайомий перець ніяк не міг в'їхати, чому у нього в полиці вигорає нижній ряд гвинтів весь час. Я йому пояснив, бідоласі.)

Полиці і SQL - сервер

Слава Богу, дісталися до суті справи. Насамперед пригадуємо ідеальну конфігурацію бази - система (1й диск), дані (2й диск), логи (3й диск). Про оптимальне розташування бази по файлах - см. Мою статтю про файлові групи. Скажу відразу, хлопці - навіть при такій простій розкладці результат виходить відмінний. Міркування з приводу вибору RAID'а:

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