Зона особливої ​​уваги – опція Maximum Degree of Parallelism. Налаштування параметра конфігурації сервера max degree of parallelism Налаштування параметра конфігурації сервера max degree of parallelism

• Tutorial

Ця інструкція призначена для новачків, які шукають простий посібник російською мовою для встановлення англійської версії SQL Server 2012, яка буде використовуватися далі для SharePoint 2013.
Ця стаття задля професіоналів.

Вся робота розділена на 3 етапи:

• Встановлення SQL Server 2012
• Налаштування параметра конфігурації сервера max degree of parallelism
• Налаштування прав облікового запису, призначеного для інсталяції SharePoint 2013

Увага: під катом багато картинок!

Встановлення SQL Server 2012

2. Запуститься майстер установки. Він виконає перевірку. Можна натиснути на кнопку «Show details» і переглянути детальний звіт:

3. Детальний звіт. Натискаємо кнопку «ОК»:

4. Вводимо ключ продукту та натискаємо кнопку «Next»:

5. Погоджуємося з умовами ліцензійної угоди.
Для цього ставимо галочку. I accept the license terms

6. На кроці "Setup Role" вибираємо перший пункт " SQL Server Feature Installation". Натискаємо кнопку "Next":

7. На кроці "Feature Selection" відзначаємо " Database Engine Services", "Management Tools – Basic"і" Management Tools – Complete". Потім натискаємо кнопку "Next":

8. Потім установник виконає ще одну перевірку. Можна натиснути на кнопку «Show details» і переглянути детальний звіт:

9. Детальний звіт. (На даному етапі у мене виникла помилка у правилі "Microsoft .NET Framework 3.5 is installed...". Про це нижче). Натискаємо кнопку «Next»:

10. На кроці "Instance Configuration" необхідно налаштувати екземпляр служби SQL-сервера.
Повторюся, що ця стаття призначена для новачків. Тому припустимо, що на вашому сервері до цього не встановлювався SQL Server, а значить залишимо всі налаштування за замовчуванням. Натискаємо кнопку «Next»:

11. На цьому кроці майстер установки відобразить вимоги до дискового простору. Натискаємо кнопку «Next»:

12. На кроці "Server Configuration" необхідно вказати доменний обліковий запис для служби " SQL Server Database EngineПісля заповнення полів «Account Name» та «Password» натискаємо кнопку «Next»:

13. На кроці Database Engine Configuration достатньо додати поточного користувача в адміністратори SQL-сервера. Для цього натисніть кнопку "Add Current User", потім натисніть кнопку "Next":

14. На наступному кроці натискаємо кнопку «Next»:

15. Далі майстер установки знову виконає перевірку та відобразить її результати. Натискаємо кнопку «Next»:

16. На кроці «Ready to Install» майстер відобразить зведену інформацію. Тут необхідно натиснути кнопку "Install":

17. Після завершення встановлення з'явиться інформація про здійснені операції:

18. Вкрай рекомендую на цьому етапі перезавантажити комп'ютер. У деяких випадках (наприклад, при інсталяції Microsoft .NET Framework 3.5) майстер установки сам відобразить вікно із пропозицією перезавантажити комп'ютер. Чи не відмовляйтеся.

Налаштування параметра конфігурації сервера max degree of parallelism

1. Запустіть Microsoft SQL Server Management Studio(Пуск - Усі програми - Microsoft SQL Server 2012 - SQL Server Management Studio).

2. На екрані підключення до сервера натисніть кнопку "Connect".

3. Клацніть правою клавішею миші на вашому сервері у вікні " Object Explorer" і виберіть пункт " Properties":

4. У вікні властивостей сервера в лівому меню виберіть сторінку " Advanced" та промотайте список властивостей у самий низ екрана. Встановіть значення параметра " Max Degree of Parallelism" 1 та натисніть кнопку «ОК»:

5. Не закривайте SQL Server Management Studio, вона нам ще знадобиться.

Налаштування прав облікового запису, призначеного для інсталяції SharePoint 2013

• dbcreator
• securityadmin
• public

2. У полі «Login name» введіть доменне ім'я облікового запису, з якого ви плануєте встановити і налаштувати SharePoint 2013.

3. У лівому меню виберіть " Server Roles" і позначте ролі "dbcreator" і "securityadmin", а також переконайтеся, що роль "public" вже відзначена. Потім натисніть кнопку "ОК":

Тепер SQL-сервер готовий до інсталяції SharePoint 2013.

Установка Microsoft .NET Framework 3.5 у середовищі MS Windows Server 2012 R2 Standart

1. Необхідно відкрити консоль " Server Manager".

2. У лівому меню вибираємо пункт "Dashboard".

3. У центрі вікна клацаємо по пункту "Add roles and features".

4. У майстрі, що відкрився, пропускаємо крок «Before You Begin».

5. На кроці "Installation Type" вибираємо пункт " Role-based або feature-based installation". Натискаємо кнопку "Next".

6. На наступному кроці залишаємо все за замовчуванням та натискаємо кнопку «Next».

7. Пропускаємо крок Server Roles, натиснувши кнопку Next.

8. На кроці "Features" відзначаємо галочку ".NET Framework 3.5 Features". Натискаємо кнопку "Next".

9. Після завершення процесу встановлення можна закрити майстер "Add Roles and Features Wizard".

10. Готово!

Всім добра та мирного неба над головою!

P.S. З наступаючим Днем космонавтики!

Не секрет, що обмірковуючи проблеми конфігурування SQL сервера, пов'язані зі збільшенням продуктивності, IT-фахівці переважно роблять вибір на користь збільшення апаратних засобів. Але чи завжди це виправдано? Чи всі методи налаштування сервера при цьому вже використані? Відомо, що з параметрами конфігурації та зміна їх значень за умовчанням, здатна поліпшити продуктивність та інші характеристики даної системи. Серед цих опцій конфігурації SQL є одна опція, з якою пов'язано багато питань, це опція – Max degree of parallelism (DOP) – ось про неї і поговоримо.

Опція Maximum Degree of Parallelism (DOP) визначає кількість потоків, на які SQL Server може розпаралелити запит і означає кількість використовуваних процесорів сервера. Параметр цього умовчання має значення 0 – максимальний ступінь паралелізму. Наприклад, якщо ви маєте 24 ядра – тоді значення 'max degree of parallelism' дорівнюватиме 24 і оптимізатор, якщо він вважатиме за потрібне, може задіяти всі процесори на виконання однієї інструкції, тобто запит буде розпаралелений на 24 потоки. Для більшості випадків це добре, але не всім. Також, далеко не завжди добре, використання значення цього параметра за промовчанням. Конфігурування цього параметра може бути потрібне, наприклад, у наступній ситуації: припустимо, у нас є додаток, в який всі співробітники вносять інформацію про щоденні операції, і, у певний проміжок часу кожен з користувачів виконує запит, який звітує про всі операції користувача за деякий проміжок часу. Звичайно, якщо проміжок часу великий, цей запит буде виконуватися довго і, при установці DOP за замовчуванням, займе всі доступні процесори, що, природно, позначиться на роботі інших користувачів. Отже, змінюючи значення DOP, ми можемо без зміни запиту підвищити час відгуку SQL сервера в інших користувачів.
MS рекомендує встановлювати значення так:

Встановлення параметра на TSQL повністю для сервера:

EXEC sp_configure "max degree of parallelism", 4; reconfigure

Також ви можете встановити це значення для конкретного TSQL запиту:

USE AdventureWorks2008R2; GO SELECT ProductID, OrderQty, SUM(LineTotal) AS TotalFROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00 GROUP BY ProductID, OrderQty ORDER BY ProductID, OrderQty OPTION (MAXDOP 2); GO

У цьому прикладі «хінт» maxdop змінює значення за умовчанням max degree of parallelism на 2. Подивитися поточне налаштування можна так:

EXEC sp_configure "Show Advanced", 1; RECONFIGURE; EXEC sp_configure "max degree of parallelism"

Тепер давай ті подивимося, як впливає це значення на швидкість виконання запиту. Для того щоб тестовий запит, написаний вище, виконувався більш тривалий час, додамо в нього ще один select. Запит набуде наступного вигляду:

< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty

На моїй тестовій машині значення max degree of parallelism виставлено в 0. MSSQL запущений на машині з 4-х ядерним процесором. Я провів серію експериментів із різними значеннями MAXDOP: рівним 1 – без розпаралелювання запиту; рівним 2 - з використанням лише 2 ядер; рівним 4 - з використанням всіх і без хінту для визначення варіанта, який використовує сіквел за замовчуванням. Для того, щоб отримати статистику виконання, потрібно включити в запит опцію SET STATISTICS TIME ON, а також включити кнопку відображення плану запиту в Management studio. Для усереднення отриманих результатів виконував кожен запит у циклі 3 рази. Результати можна побачити нижче:

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 1); SQL Server Execution Times: CPU time = 45942 ms, elapsed time = 46118 ms. SQL Server Execution Times: CPU time = 45926 ms, elapsed time = 46006 ms. SQL Server Execution Times: CPU time = 45506 ms, elapsed time = 45653 ms.

На плані запиту видно, що при установці хінту (MAXDOP 1) запит виконувався без розпаралелювання. Середній час виконання запиту 45925.66 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 2); SQL Server Execution Times: CPU time = 51684 ms, elapsed time = 28983 ms. SQL Server Execution Times: CPU time = 51060 ms, elapsed time = 26165 ms. SQL Server Execution Times: CPU time = 50903 ms, elapsed time = 26015 ms.

При встановленні хінта (MAXDOP 2) запит виконувався паралельно на 2 cpu, це можна побачити на Number of Execution у плані виконання запиту. Середній час виконання запиту 27054.33 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty OPTION (MAXDOP 4); SQL Server Execution Times: CPU time = 82275 ms, elapsed time = 23133 ms. SQL Server Execution Times: CPU time = 83788 ms, elapsed time = 23846 ms. SQL Server Execution Times: CPU time = 53571 ms, elapsed time = 27227 ms.

При встановленні хінту (MAXDOP 4) запит виконувався паралельно на 4 cpu. Середній час виконання запиту 24735.33 ms

SELECT dt.ProductID, dt.OrderQty, SUM(dt.LineTotal) AS Total FROM Sales.SalesOrderDetail dt, (SELECT * FROM Sales.SalesOrderDetail WHERE UnitPrice< $5.00) dt2 WHERE dt.UnitPrice < $5.00 GROUP BY dt.ProductID, dt.OrderQty ORDER BY dt.ProductID, dt.OrderQty SQL Server Execution Times: CPU time = 85816 ms, elapsed time = 23190 ms. SQL Server Execution Times: CPU time = 85800 ms, elapsed time = 23307 ms. SQL Server Execution Times: CPU time = 58515 ms, elapsed time = 26575 ms.

запит виконувався паралельно, також 4 cpu. Середній час виконання запиту 24357.33ms

links: http://support.microsoft.com/kb/2023536

Параметр "max degree of parallelism" визначає максимальну кількість потоків, на які SQL Server може розпаралелити запит. За промовчанням цей параметр дорівнює нулю, що означає використання числа процесорів сервера. Наприклад, якщо у вас 24 ядра - фактичне значення "max degree of parallelism" дорівнюватиме 24 і оптимізатор, якщо він вважатиме за потрібне, може розпаралелити запит на 24 потоки. Загалом це добре, але не завжди. Також далеко не завжди добре використання значення цього параметра за замовчуванням.

Тепер давайте розберемо, чому це не добре. Наведу один приклад із власної практики. Є запит, який, за ідеєю, повинен використовувати певний індекс, і спочатку так і відбувається. Запускається запит, який виконує пошук за індексом і повертає необхідні дані. Все відмінно. Потім у міру зростання бази даних до таблиці додаються нові та нові записи і в певний момент оптимізатор розуміє, що є можливість виконати запит швидше: “Навіщо мені шукати індекс, якщо у мене є 24 ядра? Значить, я можу в 24 потоки просканувати кластерний індекс і отримати необхідні мені дані швидше!”. Для цього конкретного запиту це добре – він виконується швидше. Але погано решті, т.к. вони змушені чекати на виділення їм процесорних ресурсів. І в системах з великою кількістю запитів, що одночасно виконуються, таке розпаралелювання швидше погано, ніж добре. І замість підвищення продуктивності вона лише погіршується. Донедавна я вирішував цю проблему виставлянням хінту MAXDOP у неугодних мені сховках. Але зараз знайшов конкретну рекомендацію Майкрософт і застосував її на своїх серверах. Рекомендації щодо вибору оптимального значення "max degree of parallelism" знаходяться тут:Recommendations and Guidelines for "max degree of parallelism" configuration option . Цитую цю рекомендацію:

Для SQL Server 2008 R2, SQL Server 2008 і SQL Server 2005 Servers, використовуйте наступні Guideline: a. Для серверів, що мають вісім або найменших процесорів, використовуйте наступне налаштування, де N еквівалентів числа процесорів: max degree parallelism = 0 to N. b. Для серверів, які використовують більше ніж вісім процесорів, використовують наступні параметри: max degree of parallelism = 8. c. Для серверів, які мають NUMA configured, максимальний рівень parallelism повинен не exceed number of CPUs, що є визначеним до всіх NUMA node з максимальною величиною capped to 8. NUMA Node and avoid повністю remote node data look ups. d. Для серверів, що мають hyper-threading enabled, максимальна величина parallelism value не повинна перевищувати число фізичних процесорів.

Звідси випливає, що для систем, в яких більше 8 процесорів рекомендується ставити "max degree of parallelism" = 8. Далі слідує ще одне пояснення, в якому говориться, що 8 - загальна рекомендація. І в системах, де число запитів, що одночасно виконуються, невелико має сенс ставити більше значення, а в системах з великою кількістю конкурентних запитів навпаки менше. І, вибираючи конкретний параметр, необхідно дивитися з його впливом геть систему і тестувати на конкретних запитах.

ОБЛАСТЬ ЗАСТОСУВАННЯ ЦЕЙ СТАТТІ: SQL Server (починаючи з 2008) База даних SQL AzureСховище даних SQL AzureParallel Data Warehouse

У цьому розділі описуються способи налаштування параметра конфігурації сервера max degree of parallelism (MAXDOP)у SQL Server 2016 за допомогою середовища SQL Server Management Studio або Transact-SQL. Якщо екземпляр SQL Server працює на багатопроцесорному комп'ютері, він визначає оптимальний рівень паралелізму, тобто кількість процесорів, задіяних для виконання однієї інструкції, для кожного з планів паралельного виконання. Для обмеження кількості процесорів у плані паралельного виконання може бути використаний параметр max degree of parallelism. SQL Server враховує плани паралельного виконання для запитів, операцій DDL з індексами, паралельної вставки, зміни стовпця в режимі "в мережі", паралельного збору статистики та заповнення статичних курсорів та курсорів, керованих набором ключів.

Обмеження

• Якщо параметр affinity mask має значення, відмінне від значення за промовчанням, може обмежувати кількість процесорів, доступних для SQL Server в симетричних багатопроцесорних системах (SMP).

Цей параметр є додатковим і його слід змінювати лише досвідченим адміністраторам баз даних або сертифікованим технічним спеціалістам SQL Server.

Щоб дозволити серверу визначати максимальний рівень паралелізму, встановіть 0 як значення даного параметра, тобто значення за замовчуванням. Встановлення значення 0 як максимально паралелізму дозволяє SQL Server використовувати всі доступні процесори (до 64 процесорів). Щоб вимкнути створення паралельних планів, надайте параметру max degree of parallelismзначення 1. Вкажіть значення для параметра в діапазоні від 1 до 32 767, щоб вказати максимальну кількість процесорних ядер, які можуть бути використані під час виконання одного запиту. Якщо вказано значення, що перевищує кількість доступних процесорів, використовується дійсна кількість доступних процесорів. Якщо комп'ютер має лише один процесор, то значення параметра max degree of parallelismне враховуватиметься.

Значення параметра max degree of parallelism можна перевизначити, вказавши вказівку на запит MAXDOP. Щоб отримати додаткові відомості, див.

Операції зі створення та перебудови індексів, а також видалення кластеризованого індексу можуть виявитися досить ресурсомісткими. Значення параметра max degree of parallelism для операцій з індексами можна перевизначити, вказавши в інструкції параметр індексу MAXDOP. Значення MAXDOP застосовується до інструкції під час виконання та в метаданих індексах не зберігається. Для отримання додаткових відомостей див .

Крім запитів та операцій з індексами, цей параметр також керує ступенем паралелізму під час виконання інструкцій DBCC CHECKTABLE, DBCC CHECKDB та DBCC CHECKFILEGROUP. Плани паралельного виконання цих інструкцій можна вимкнути за допомогою прапора трасування 2528. Додаткові відомості див. у розділі .

Безпека

Дозволи

Дозволи на виконання процедури, що зберігається sp_configureбез параметрів або лише з першим параметром за промовчанням надаються всім користувачам. Для виконання процедури sp_configureз обома параметрами для зміни параметра конфігурації або запуску інструкції RECONFIGURE необхідно мати роздільну здатність ALTER SETTINGS на рівні сервера. Дозвіл ALTER SETTINGS неявним чином наданий зумовленим ролям сервера sysadminі serveradmin .

У оглядачі об'єктівклацніть правою кнопкою миші сервер і виберіть пункт Властивості.

Клацніть вузол Додатково .

В полі Максимальний ступінь паралелізмувкажіть максимальну кількість процесорів, яка може бути використана у плані паралельного виконання.

Налаштування параметра максимального ступеня паралелізму

Встановіть з'єднання з компонентом Компонент Database Engine.

На панелі «Стандартна» натисніть Створити запит.

Скопіюйте наступний приклад у вікно запиту та натисніть кнопку Виконати. У цьому прикладі описується використання процедури завдання значення параметра max degree of parallelism рівним 8 .

USE AdventureWorks2012; GO EXEC sp_configure "show advanced options", 1; GO RECONFIGURE WITH OVERRIDE; GO EXEC sp_configure "max degree of parallelism", 8; GO RECONFIGURE WITH OVERRIDE; GO

Для отримання додаткових відомостей див.

У даному пості йтиметься лише про MS SQL Server. Якщо ви зібралися "спробувати щастя" у використанні 1С з Oracle, DB2, Postrgre вам дана інформація буде марною. Але потрібно розуміти, що в 1С є насамперед фахівці з MS SQL серверу. Зусиллями з боку компанії IBM є ще й фахівці з DB2. Можна довго міркувати хороші чи погані це СУБД, важливо одне, найбільш "гладко" 1С працює з MS SQL сервером. Судячи з останніх повідомлень з "фронту" більш-менш пристойною стала робота з DB2. Хоча я особисто мав досвід налаштування 1С для роботи з DB2 ще у версії 8.1 – там все було якось не дуже. У будь-якому випадку вибір іншої СУБД повинен бути чітко аргументований - або можливостями, яких немає в MS SQL (кластер з балансуванням навантаження, Grid і т.п.), або фінансами (Oracle вже куплений), або платформою (все на linux).

Отже по порядку, що потрібно зробити з MS SQL Server:

1) Налаштувати мінімальний та максимальний обсяг пам'яті. Мінімальний – половина пам'яті системи. Максимальний – пам'ять системи без 2ГБ. Робиться це через Management Studio – у властивостях сервера:

2) Якщо пріоритет не встановлено на закладці "Процесори" – потрібно встановити

3) Максимальний ступінь паралелізму ставимо до 1.

4) Включаємо SQL Server Agent, налаштовуємо Database Mail – нічого там складного немає, докладно описувати не буду.

5) Налаштовуємо плани обслуговування:
Загальні:
а) Оновлення статистики – кожні 2 години
б) DBCC FREEPROCCACHE - кожні 2 години
Для кожної бази:
а) Повне резервне копіювання
б) Різнинне резервне копіювання
в) Дефрагментація індексів – щодня
г) Перебудова індексів – вночі у вихідні
д) Перевірка цілісності бази - раз на місяць уночі у вихідні

6) Рекомендую для кожної бази (в властивості) модель відновлення встановити як Simple. Якщо у вас не 24/7 система і менше 1000 користувачів на базу, немає відмовостійкого кластера і ви не підписували SLA в якому зобов'язуєтесь у разі виходу будь-якого обладнання з ладу відновити дані з точністю до секунди (а не з часу останньої резервної копії) ця рекомендація буде розумною. Інакше ви дуже скоро будете довго і судомно розмірковувати куди ж подіти Tranzaction Log, що розрісся

7) Заберіть базу tempdb від звичайних баз на інший диск - навіть якщо доведеться переконфігурувати RAID масив і знизити його продуктивність. Інакше 1 користувач зможе паралізувати роботу решти. Якщо у вас є Hardware Accelereator замість жорсткого диска, то звичайно можна не відокремлювати і покласти tempdb на нього, але це тільки у випадку якщо такий є

8) встановіть якийсь засіб моніторингу - мені, наприклад, подобається spotlight http://www.quest.com/spotlight-on-sql-server-enterprise/

9) Перевірте себе з best practice analizer від Microsoft - http://www.microsoft.com/download/en/details.aspx?id=15289 - чудовий інструмент, який допомагає не тільки з налаштуваннями, але й вирішенням багатьох проблем.

Тепер коротко для чого ми все це робили:

1) Пам'ять. Мінімальне значення просто убереже вас від "глюків", коли SQL сервер з якихось лише йому відомих причин не використовує всю доступну йому пам'ять. Мушу з'їсти всю! Максимальне значення убереже вас від свопу у випадку якщо той же оптимізатор використання пам'яті SQL сервер-а вирішить що йому ще не завадило б.

3) Дуже важливий пункт - ІХМО його потрібно ставити в 1 у всіх трансакційних системах. По-перше - це запобігає частині блокувань між різними процесами, які намагаються виконати 1 запит, відповідно уберігає нас від деяких "дивних" помилок. По-друге... 1 "вбивчий" запит зможе витягнути він всі ресурси сервера, що дещо не справедливо стосовно іншим користувачам системы.Власне параметр визначає - скільки ядрами процесорів може оброблятися 1 запрос.

5) Про статистику та очищення процедурного кешу - це "на слуху" а ось про реіндексацію часто забуваємо. А тим часом ця процедура досить важлива, особливо зі зростанням обсягу бази, важливість її збільшується. Іноді на фрагментації індексів втрачається до 60% продуктивності.

7) За наявності Hardware Accelerator або просто 2 дисків з різними швидкостями доступу я рекомендував би ще задуматися про виділення в базах файлових груп і поділ окремих таблиць на різні дискові масиви, з різним часом доступу. Адже погодьтеся, РН "товари на складах" та довідник "Сховище додаткової інформації" 2 об'єкти вимоги до зберігання яких докорінно відрізняються. Не обов'язково на швидкому масиві зберігати всі файли та картинки в базі – можна виділити його на окремий, не такий швидкий, але де місця багато (і не боятися потім у базу купу файлів завантажувати, до речі).