Област на специално внимание – опция за максимална степен на паралелизъм. Конфигуриране на параметъра за конфигурация на сървъра за максимална степен на паралелизъм Конфигуриране на параметъра за конфигурация на сървъра за максимална степен на паралелизъм

• Урок

Тази инструкция е предназначена за начинаещи, които търсят просто ръководство на руски език за инсталиране на английската версия на SQL Server 2012, която след това ще се използва за SharePoint 2013.
Тази статия не е за професионалисти.

Цялата работа е разделена на 3 етапа:

• Инсталиране на SQL Server 2012
• Задаване на параметъра за конфигурация на сървъра максимална степен на паралелизъм
• Конфигурирайте правата на акаунта, който е предназначен за инсталиране на SharePoint 2013

Внимание: има много снимки под разреза!

Инсталиране на SQL Server 2012

2. Ще се стартира съветникът за инсталиране. Той ще провери. Можете да кликнете върху бутона „Покажи подробности“ и да видите подробен отчет:

3. Подробен отчет. Щракнете върху бутона „OK“:

4. Въведете продуктовия ключ и щракнете върху бутона „Напред“:

5. Съгласни сме с условията на лицензионното споразумение.
За да направите това, поставете отметка в квадратчето " Приемам условията на лиценза

6. В стъпка „Настройка на роля“ изберете първия елемент " Инсталиране на функции на SQL Server". Щракнете върху бутона "Напред":

7. На стъпката „Избор на функция“ маркирайте „ Database Engine Services", "Инструменти за управление – основни" И " Инструменти за управление – завършениСлед това щракнете върху бутона „Напред“:

8. След това инсталаторът ще извърши друга проверка. Можете да кликнете върху бутона „Покажи подробности“ и да видите подробен отчет:

9. Подробен отчет. (На този етап имах грешка в правилото „Microsoft .NET Framework 3.5 е инсталиран...“. Повече за това по-долу). Щракнете върху бутона „Напред“:

10. На стъпката „Конфигуриране на екземпляр“ трябва да конфигурирате екземпляра на услугата SQL Server.
Повтарям, че тази статия е предназначена за начинаещи. Следователно ще направим предположението, че SQL Server не е бил инсталиран на вашия сървър преди, което означава, че ще оставим всички настройки по подразбиране. Щракнете върху бутона „Напред“:

11. На тази стъпка съветникът за инсталиране ще покаже изискванията за дисково пространство. Щракнете върху бутона „Напред“:

12. На стъпката „Конфигурация на сървъра“ трябва да посочите домейн акаунт за услугата „ SQL Server Database EngineСлед като попълните полетата „Име на акаунта“ и „Парола“, щракнете върху бутона „Напред“:

13. На стъпката „Конфигурация на двигателя на базата данни“ просто добавете текущия потребител към администраторите на SQL сървъра. За да направите това, щракнете върху бутона „Добавяне на текущия потребител“, след което щракнете върху бутона „Напред“:

14. В следващата стъпка щракнете върху бутона „Напред“:

15. След това съветникът за инсталиране ще извърши теста отново и ще покаже резултатите от него. Щракнете върху бутона „Напред“:

16. На стъпката „Готов за инсталиране“ съветникът ще покаже обобщена информация. Тук трябва да кликнете върху бутона „Инсталиране“:

17. След като инсталацията приключи, ще се покаже информация за извършените операции:

18. Силно препоръчвам да рестартирате компютъра си на този етап. В някои случаи (например при инсталиране на Microsoft .NET Framework 3.5), самият съветник за инсталиране ще покаже прозорец с молба да рестартирате компютъра. Не отказвайте.

Задаване на параметъра за конфигурация на сървъра максимална степен на паралелизъм

1. Стартиране Microsoft SQL Server Management Studio(Старт - Всички програми - Microsoft SQL Server 2012 - SQL Server Management Studio).

2. На екрана за връзка със сървъра щракнете върху бутона „Свързване“.

3. Щракнете с десния бутон върху вашия сървър в " Object Explorer" и изберете " Имоти":

4. В прозореца със свойства на сървъра, който се отваря, в лявото меню изберете страницата " Разширено" и превъртете списъка със свойства до най-долната част на екрана. Задайте стойността на параметъра " Максимална степен на паралелизъм" В 1 и щракнете върху OK:

5. Не затваряйте SQL Server Management Studio, ще ни трябва по-късно.

Конфигурирайте правата на акаунта, който е предназначен за инсталиране на SharePoint 2013

• dbcreator
• сигурност администратор
• публичен

2. В полето „Име за влизане“ въведете името на домейна на акаунта, под който планирате да инсталирате и конфигурирате SharePoint 2013.

3. В лявото меню изберете страницата " Сървърни роли" и проверете ролите "dbcreator" и "securityadmin", а също така се уверете, че ролята "public" вече е маркирана. След това щракнете върху бутона "OK":

Сега SQL сървърът е готов за инсталиране на SharePoint 2013.

Инсталиране на Microsoft .NET Framework 3.5 в MS Windows Server 2012 R2 Standart

1. Трябва да отворите конзолата" Мениджър на сървъра".

2. В лявото меню изберете елемента „Табло за управление“.

3. В центъра на прозореца щракнете върху елемента „Добавяне на роли и функции“.

4. В съветника, който се отваря, пропуснете стъпката „Преди да започнете“.

5. В стъпката „Тип инсталация“ изберете елемента „ Инсталиране, базирано на роли или функции". Щракнете върху бутона "Напред".

6. В следващата стъпка оставете всичко по подразбиране и щракнете върху бутона „Напред“.

7. Пропуснете стъпката „Сървърни роли“, като щракнете върху бутона „Напред“.

8. В стъпка „Функции“ поставете отметка в квадратчето „.NET Framework 3.5 Features“. Щракнете върху бутона "Напред".

9. След като инсталационният процес приключи, можете да затворите съветника за добавяне на роли и функции.

10. Готово!

Успех на всички и мирно небе над главите!

P.S. Честит предстоящ Ден на космонавтиката!

Не е тайна, че когато разглеждат проблемите на конфигурирането на SQL сървър, свързани с увеличаване на производителността, повечето ИТ специалисти избират увеличаване на хардуера. Но това винаги ли е оправдано? Използвани ли са вече всички методи за конфигуриране на сървъра? Известно е, че работата с конфигурационни параметри и промяната на техните стойности по подразбиране може да подобри производителността и други характеристики на дадена система. Сред тези опции за конфигурация на SQL има една опция, която има много въпроси, свързани с нея, тази опция е Максимална степен на паралелизъм (DOP) - така че ще говорим за нея.

Опцията Максимална степен на паралелизъм (DOP) определя броя на нишките, на които SQL Server може да паралелизира заявка, и посочва броя на използваните сървърни процесори. Този параметър има стойност по подразбиране 0 – максималната степен на паралелност. Например, ако имате 24 ядра, тогава стойността на "максимална степен на паралелизъм" ще бъде равна на 24 и оптимизаторът, ако сметне за необходимо, може да използва всички процесори за изпълнение на една инструкция, тоест заявката ще бъде паралелизирани в 24 нишки. Това е добре за повечето случаи, но не за всички. Освен това не винаги е добре да използвате стойността по подразбиране на този параметър. Конфигурирането на този параметър може да е необходимо, например, в следната ситуация: да кажем, че имаме приложение, в което всички служители въвеждат информация за ежедневни транзакции и в определен период от време всеки от потребителите изпълнява заявка, която изгражда отчет за всички транзакции на потребителя за определен период от време. Естествено, ако периодът от време е дълъг, тази заявка ще отнеме много време за изпълнение и при инсталиран DOP по подразбиране ще заеме всички налични процесори, което естествено ще се отрази на работата на другите потребители. Следователно, чрез промяна на стойността на DOP, можем да увеличим времето за отговор на SQL сървъра за други потребители, без да променяме самата заявка.
MS препоръчва да зададете стойността, както следва:

Задаване на параметъра изцяло на TSQL за сървъра:

EXEC sp_configure "максимална степен на паралелизъм", 4; преконфигурирайте

Можете също да зададете тази стойност за конкретна TSQL заявка:

ИЗПОЛЗВАЙТЕ AdventureWorks2008R2 ; ИЗБЕРЕТЕ 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 променя стойността по подразбиране на параметъра за максимална степен на паралелизъм на 2. Можете да видите текущата настройка по следния начин:

EXEC sp_configure "Показване на разширени",1; ПРЕКОНФИГУРИРАНЕ; EXEC sp_configure "максимална степен на паралелизъм"

Сега нека видим как тази стойност влияе върху скоростта на изпълнение на заявката. За да може тестовата заявка, написана по-горе, да се изпълнява по-дълго време, ще добавим още един select към нея. Искането ще приеме следната форма:

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

На моята тестова машина стойността за „максимална степен на паралелизъм“ е зададена на 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 процесора, това може да се види в броя на изпълнението в плана за изпълнение на заявката. Средно време за изпълнение на заявка 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 процесора. Средно време за изпълнение на заявка 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 процесора. Средно време за изпълнение на заявка 24357.33ms

връзки: http://support.microsoft.com/kb/2023536

Параметърът "максимална степен на паралелизъм" указва максималния брой нишки, към които SQL Server може да паралелизира дадена заявка. По подразбиране този параметър е нула, което означава, че се използва броят процесори на сървъра. Например, ако имате 24 ядра, действителната стойност на "максимална степен на паралелност" ще бъде 24 и оптимизаторът, ако сметне за необходимо, може да паралелизира заявката в 24 нишки. Като цяло това е добре, но не винаги. Освен това не винаги е добре да използвате стойността по подразбиране на този параметър.

Сега нека да видим защо това не е добре. Ще дам един пример от моята практика. Има заявка, която на теория трябва да използва определен индекс и в началото това се случва. Стартира се заявка, която търси в индекса и връща необходимите данни. Всичко е наред. След това, когато базата данни расте, все повече и повече записи се добавят към таблицата и в определен момент оптимизаторът осъзнава, че е възможно да изпълни заявката по-бързо: „Защо трябва да извършвам търсене в индекс, ако имам 24 ядра? Това означава, че мога да сканирам клъстерирания индекс в 24 нишки и да получа данните, от които се нуждая, по-бързо!“ За тази конкретна заявка това е добре - работи по-бързо. Но това е лошо за всички останали, защото... те са принудени да чакат ресурсите на процесора да им бъдат разпределени. И в системи с голям брой едновременно изпълняващи се заявки, такова паралелизиране е по-вероятно да бъде лошо, отколкото добро. И вместо да подобри производителността, тя само се влошава. Доскоро решавах този проблем, като задавах подсказката MAXDOP в хранилища, които не харесвах. Но сега намерих конкретна препоръка на Microsoft и я приложих към моите сървъри. Препоръките за избор на оптимална стойност за "максимална степен на паралелност" са тук:Препоръки и насоки за конфигурационна опция "максимална степен на паралелизъм". . Цитирам тази препоръка:

За сървъри SQL Server 2008 R2, SQL Server 2008 и SQL Server 2005 използвайте следните указания: a. За сървъри, които имат осем или по-малко процесори, използвайте следната конфигурация, където N е равно на броя на процесорите: максимална степен на паралелизъм = 0 до N. b. За сървъри, които използват повече от осем процесора, използвайте следната конфигурация: максимална степен на паралелизъм = 8. c. За сървъри, които имат конфигуриран NUMA, максималната степен на паралелизъм не трябва да надвишава броя CPU, които са присвоени на всеки NUMA възел с максимална стойност, ограничена до 8. Това ще увеличи вероятността всички паралелни нишки на заявка да бъдат разположени в NUMA Node и избягвайте скъпоструващи търсения на данни от отдалечен възел. д. За сървъри, които имат активирана хипер-нишка, стойността на максималната степен на паралелизъм не трябва да надвишава броя на физическите процесори.

От това следва, че за системи с повече от 8 процесора се препоръчва да се зададе „максимална степен на паралелизъм“ = 8. Това е последвано от друго обяснение, което гласи, че 8 е обща препоръка. И в системи, където броят на едновременно изпълняваните заявки е малък, има смисъл да се зададе по-голяма стойност, а в системи с голям брой конкуриращи се заявки има смисъл да се зададе по-малка стойност. И когато избирате конкретен параметър, трябва да разгледате неговото въздействие върху системата и да го тествате при конкретни заявки.

ОБХВАТ НА ТАЗИ СТАТИЯ: SQL Server (от 2008 г.) Azure SQL база данни Azure SQL Data Warehouse Паралелно хранилище на данни

Този раздел описва как да конфигурирате конфигурационния параметър на сървъра максимална степен на паралелизъм (MAXDOP)в SQL Server 2016 с помощта на SQL Server Management Studio или Transact-SQL. Когато екземпляр на SQL Server работи на многопроцесорен компютър, той определя оптималната степен на паралелизъм, тоест броя на процесорите, използвани за изпълнение на един оператор, за всеки от неговите паралелни планове за изпълнение. За да ограничите броя на процесорите в план за паралелно изпълнение, може да се използва параметърът максимална степен на паралелизъм. SQL Server разглежда паралелни планове за изпълнение на заявки, DDL операции върху индекси, паралелни вмъквания, онлайн модификации на колони, паралелно събиране на статистически данни и популация от статични и управлявани от ключове курсори.

Ограничения

• Ако параметърът на маската на афинитета е зададен на стойност, различна от тази по подразбиране, той може да ограничи броя на процесорите, достъпни за SQL Server на симетрични мултипроцесорни (SMP) системи.

Тази настройка не е задължителна и трябва да се променя само от опитни администратори на бази данни или сертифицирани техници на SQL Server.

За да позволите на сървъра да определи максималната степен на паралелизъм, задайте този параметър на 0, което е стойността по подразбиране. Задаването на максимална степен на паралелизъм на 0 позволява на SQL Server да използва всички налични процесори (до 64 процесора). За да деактивирате създаването на паралелни планове, задайте параметъра максимална степен на паралелизъмстойност 1. Задайте параметъра на стойност между 1 и 32 767, за да посочите максималния брой процесорни ядра, които могат да се използват за изпълнение на една заявка. Ако е зададена стойност, по-голяма от броя на наличните процесори, се използва действителният брой налични процесори. Ако компютърът има само един процесор, тогава стойността на параметъра максимална степен на паралелизъмняма да бъдат взети предвид.

Стойността на параметъра за максимална степен на паралелизъм може да бъде заменена чрез указване на заявка MAXDOP в оператора. За повече информация вижте.

Операциите по създаване и повторно изграждане на индекси, както и изтриване на клъстерен индекс, могат да бъдат доста ресурсоемки. Стойността на параметъра за максимална степен на паралелизъм за операции с индекси може да бъде заменена чрез указване на параметъра за индекс MAXDOP в оператора. Стойността MAXDOP се прилага към израза по време на изпълнение и не се съхранява в метаданните на индекса. За повече информация вижте статията.

В допълнение към операциите за заявка и индекс, този параметър също контролира степента на паралелизъм при изпълнение на операторите DBCC CHECKTABLE, DBCC CHECKDB и DBCC CHECKFILEGROUP. Плановете за паралелност за тези инструкции могат да бъдат деактивирани с помощта на флаг за проследяване 2528. За повече информация вижте .

Безопасност

Разрешения

Разрешения за изпълнение на съхранена процедура sp_configureбез параметри или само с първия параметър се предоставят на всички потребители по подразбиране. За извършване на процедурата sp_configureи с двете опции трябва да имате разрешение ALTER SETTINGS на ниво сървър, за да промените конфигурационна настройка или да изпълните команда RECONFIGURE. Разрешението ALTER SETTINGS се предоставя имплицитно на фиксирани сървърни роли системен администраторИ сървър администратор .

IN Object Explorerщракнете с десния бутон върху сървъра и изберете Имоти.

Щракнете върху възел Допълнително .

В полето Максимална степен на паралелизъмПосочете максималния брой процесори, които могат да се използват в плана за паралелно изпълнение.

Конфигуриране на параметъра Максимална степен на паралелизъм

Установете връзка с Database Engine.

В стандартния панел щракнете върху Създайте заявка.

Копирайте следния пример в прозореца за заявка и щракнете върху бутона Изпълни. Този пример описва как да използвате процедура за задаване на параметъра за максимална степен на паралелизъм на 8.

ИЗПОЛЗВАЙТЕ AdventureWorks2012; GO EXEC sp_configure "покажи разширени опции", 1; ПРЕКОНФИГУРИРАЙТЕ С ОТМЕНЯНЕ; GO EXEC sp_configure "максимална степен на паралелизъм", 8; ПРЕКОНФИГУРИРАЙТЕ С ОТМЕНЯНЕ; ОТИВАМ

За повече информация вижте статията

Тази публикация ще се фокусира само върху MS SQL Server. Ако планирате да „опитате късмета си“ в използването на 1C с Oracle, DB2, Postrgre, тази информация ще бъде безполезна за вас. Но трябва да разберете, че в 1C има преди всичко специалисти по MS SQL сървър. Благодарение на усилията на IBM се появяват и специалисти по DB2. Можете да спорите дълго време дали тази СУБД е добра или лоша, едно нещо е важно, 1C работи най-„гладко“ с MS SQL сървър. Съдейки по последните доклади от „отпред“, работата с DB2 стана повече или по-малко прилична. Въпреки че лично имах опит в настройката на 1C за работа с DB2 във версия 8.1, всичко някак не беше много добро. Във всеки случай изборът на друга СУБД трябва да бъде ясно обоснован - или от възможности, които не са налични в MS SQL (клъстер с балансиране на натоварването, Grid и др.), или от финанси (Oracle вече е закупен), или от платформа (всичко е на Linux).

И така, по ред, какво трябва да се направи с MS SQL Server:

1) Задайте минималния и максималния размер на паметта. Минимумът е половината от системната памет. Максимум - системна памет без 2GB. Това става чрез Management Studio - в свойствата на сървъра:

2) Ако приоритетът не е зададен в раздела „Процесори“, трябва да зададете

3) Задайте максималната степен на паралелизъм на 1.

4) Включете SQL Server Agent, конфигурирайте Database Mail - там няма нищо трудно, няма да го описвам подробно.

5) Създаване на планове за обслужване:
Често срещани са:
а) Актуализация на статистиката - на всеки 2 часа
б) DBCC FREEPROCCACHE - на всеки 2 часа
За всяка база:
а) Пълно архивиране
b) Диференциално резервно копие
в) Дефрагментиране на индекси - всеки ден
г) Възстановяване на индексите - през нощта през почивните дни
д) Проверка на целостта на базата данни – веднъж месечно през нощта през почивните дни

6) Препоръчвам да зададете модела за възстановяване като Simple за всяка база данни (в свойствата). Ако нямате 24/7 система и по-малко от 1000 потребители на база, няма failover cluster и не сте подписали SLA, в което се задължавате да възстановите данните с точност до секунда (а не от времето на последното архивиране) в случай на повреда на някое оборудване. тази препоръка би била разумна. В противен случай много скоро ще мислите дълго и трескаво какво да правите с обраслия регистър на транзакциите

7) Премахнете базата данни tempdb от обикновените бази данни на друг диск - дори ако това означава преконфигуриране на RAID масива и намаляване на неговата производителност. В противен случай 1 потребител ще може да парализира работата на всички останали. Ако имате Hardware Accelereator вместо твърд диск, тогава разбира се не можете да го отделите и да поставите tempdb върху него, но това е само ако имате такъв

8) инсталирайте някакъв инструмент за наблюдение - например харесвам spotlight http://www.quest.com/spotlight-on-sql-server-enterprise/

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

Сега накратко защо направихме всичко това:

1) Памет. Минималната стойност просто ще ви предпази от „бъгове“, когато SQL сървърът по някаква причина, известна само на него, не използва цялата налична памет. Трябва да се изяде всичко! Максималната стойност ще ви предпази от суап, ако същият оптимизатор за използване на паметта на SQL сървър реши, че не може да направи нищо друго....

3) Много важен момент - IHMO трябва да бъде зададен на 1 във всички транзакционни системи. Първо, това предотвратява известно блокиране между различни процеси, опитващи се да изпълнят 1 заявка, и съответно ни предпазва от някои „странни“ грешки. Второ... 1 заявка „killer” може да поеме всички ресурси на сървъра, което е малко несправедливо по отношение на останалите потребители на системата Самият параметър определя колко процесорни ядра могат да обработят 1 заявка.

5) Статистиката и изчистването на процедурния кеш са добре известни, но често забравяме за преиндексирането. Междувременно тази процедура е доста важна, особено с нарастването на обема на базата данни, нейното значение нараства. Понякога до 60% от производителността се губи поради фрагментация на индекса.

7) Ако имате хардуерен ускорител или само 2 диска с различни скорости на достъп, бих препоръчал също да помислите за разпределяне на файлови групи в базите данни и разделяне на отделни таблици в различни дискови масиви с различно време за достъп. В крайна сметка трябва да признаете, че RN „стоки в складове“ и директорията „Съхранение на допълнителна информация“ са 2 обекта, чиито изисквания за съхранение са коренно различни. Не е необходимо да съхранявате всички файлове и снимки в базата данни на бърз масив - можете да го отделите в отделен, който не е толкова бърз, но където има много място (и тогава не се страхувайте да качите куп файлове в базата данни, между другото).