Оптимізація продуктивності ЦП SQL Server, Інші СУБД, Бази даних, статті

Усунення проблем продуктивності системи бази даних може бути непереборної завданням. Важливо знати, в чому полягає проблема, але ще більш важливо розуміти механізм реагування системи на певний запит. На продуктивність ЦП сервера бази даних може вплинути ряд факторів: компіляція і перекомпіляція інструкцій SQL, відсутні індекси, багатопотокові операції, проблеми продуктивності дисків, вузькі місця з боку пам’яті, процедури обслуговування, дії з вилучення, перетворення і завантаження та інші фактори. Використання ЦП само по собі не є проблемою – процесор призначений для виконання роботи. Ключем до оптимального використання процесора є забезпечення того, що процесор виконує необхідну роботу, а не витрачає час через погано оптимізованого коду або обладнання з низькою продуктивністю.



Два шляхи, що ведуть в одне місце

Якщо розглядати в цілому, існує два шляхи визначення проблем продуктивності процесора. Перший полягає в аналізі продуктивності устаткування системи, що допомагає визначити місця для пошуку проблеми при переході до другого шляху, оцінці ефективності виконання сервером запитів. Другий шлях зазвичай більш ефективний для визначення проблем продуктивності SQL Server ™. Проте якщо причини проблем продуктивності запитів точно не відомі, завжди слід починати з аналізу продуктивності системи В кінцевому рахунку, зазвичай ви опиняєтеся на обох шляхах. Давайте розглянемо деякі основні моменти, щоб можна було перейти до розгляду обох шляхів.

Технологія гіперпоточності

На технології гіперпоточності варто зупинитися через те, як вона впливає на SQL Server. Технологія гіперпоточності фактично надає операційній системі для одного фізичного процесора два логічних процесора. По суті, технологія гіперпоточності орендує час фізичних процесорів для повного використання можливостей кожного процесора. На веб-сайті Intel (intel.com / technology / platform-technology / hyper-threading / index.htm) представлено набагато більш докладний опис роботи технології гіперпоточності.


В системах SQL Server DBMS фактично обробляє власні надзвичайно ефективні черги і потоки для операційної системи, тому в системах з вже існуючою високою завантаженням процесорів технологія гіперпоточності тільки ще більше перевантажує фізичні ЦП. Коли SQL Server здійснює постановку в чергу декількох запитів для роботи з декількома планувальниками, операційній системі доводиться перемикати контекст потоків команд для забезпечення відповідності виконуваних запитам, навіть якщо два логічних процесора належать одній фізичній процесору. Якщо показник “Контекстні перемикань / сек” перевищує 5000 для одного фізичного процесора, слід серйозно розглянути питання про відключення гіперпоточності в системі та повторному тестуванні продуктивності.


Тільки в дуже рідких випадках додатки з високою завантаженням процесора в SQL Server можуть ефективно використовувати гіперпоточность. Перед реалізацією змін до робочих системах необхідно завжди перевіряти додатки в SQL Server із включеною і вимкненою гіперпоточностью.



Основні моменти

Продуктивність потужного двоядерного процесора завжди буде перевершувати продуктивність ОЗУ комп’ютера, швидкість якого в свою чергу буде більше швидкості підключеного пристрою, що запам’ятовує. Пропускна здатність хорошого процесора приблизно в шість разів перевершує пропускну здатність кращої сучасної пам’яті DDR2 і приблизно в два рази перевершує пропускну здатність кращої пам’яті DDR3. Пропускна здатність звичайної пам’яті більш ніж в 10 разів перевищує пропускну здатність найшвидших оптоволоконних приводів. У свою чергу, жорсткі диски можуть виконувати тільки обмежений число операцій введення / виводу в секунду (IOPS), це значення цілком залежить від кількості операцій пошуку в секунду, що може виконувати привід. Справедливості заради треба сказати, що для задоволення всіх потреб в зберіганні систем баз даних підприємств звичайно використовується декілька пристроїв зберігання. Сьогодні в більшості установок використовуються мережі сховищ даних (SAN) на серверах баз даних підприємств або групи RAID більшого розміру, які можуть мінімізувати або усунути проблему процесора дискового вводу-виводу. Важливо пам’ятати, що незалежно від особливостей установки системи вузькі місця з боку дисків і пам’яті можуть вплинути на продуктивність процесорів.

Через відмінності в швидкості введення-виведення отримання даних з диска набагато дорожче, ніж отримання даних з пам’яті. Розмір сторінки даних в SQL Server – 8 КБ. Блок в SQL Server складається з восьми сторінок розміром 8 КБ кожна і відповідно має розмір 64 КБ. Це важливо розуміти, оскільки коли SQL Server запитує певну сторінку даних з диска, виконується отримання всього блоку, в який входить сторінка даних, а не тільки цієї певної сторінки. Існує ряд причин, які роблять це найбільш ефективним для SQL Server, але в цій статті я не розглядатимуть це питання докладно. Отримання сторінки даних, уже кешированной з буферного пула, з максимальною продуктивністю виконується протягом половини мілісекунди, отримання одного блоку з диска в оптимальному середовищі займає від 2 до 4 мілісекунд. Зазвичай читання добре працює справної дискової підсистеми займає від 4 до 10 мс. Отримання сторінки даних з пам’яті зазвичай виконується від 4 до 20 разів швидше, ніж отримання сторінки даних з диска.

Коли SQL Server запитує сторінку даних, він виконує пошук в буферному кеші в пам’яті, а потім у дискової підсистеми. Знайшовши сторінку даних в буферному пулі, процесор отримає дані і виконає необхідні операції. Це називається помилкою сторінки ОЗУ. Помилки сторінок ОЗУ ідеальні для SQL Server, оскільки для використання даних, отриманих в якості частини запиту, вони повинні перебувати в буферному кеші. Сторінка даних, не знайдена в буферному кеші, повинна бути отримана з дискової підсистеми сервера. Необхідність отримання операційною системою сторінки даних диска називається помилкою сторінки фізичної пам’яті.

При узгодженні продуктивності пам’яті, дисків і ЦП об’єктивно оцінити всі компоненти допомагає загальний знаменник: пропускна здатність. Говорячи ненауково, пропускна здатність – це максимальний обсяг даних, що може передавати кінцевий канал.



Шлях 1. Продуктивність системи

Існує всього декілька способів визначення наявності вузьких місць ЦП на сервері і не дуже багато можливих причин високого завантаження процесора. Деякі з цих проблем можна відстежити за допомогою системного монітора або подібного засоби спостереження за системою, інші ж проблеми можна відстежити за допомогою Профілювальники SQL або схожих засобів. Інший спосіб полягає у використанні команд SQL в Query Analyzer або SQL Server Management Studio (SSMS).

При оцінці продуктивності системи я використовую підхід “Почніть широко, потім аналізуйте докладно”. Очевидно, дослідження проблемних місць можливе тільки після їх визначення. Після оцінки загального використання ЦП за допомогою спеціальної програми, наприклад системного монітора, її можна використовувати для перегляду кількох дуже простих і зрозумілих лічильників продуктивності.

Одним з найвідоміших лічильників продуктивності є лічильник “% завантаженості процесора”; під час роботи системного монітора цей лічильник виділяється після відкриття вікна “Add Counter” (Додавання лічильника). Лічильник “% завантаженості процесора” відображає час, протягом якого процесори залишаються зайнятими при виконанні операцій. Як правило, завантаженість процесорів вважається високою, коли це значення становить 80 або більше відсотків протягом більшої частини часу роботи з максимальним завантаженням. Іноді значення може раптово підвищуватися до 100 відсотків, навіть якщо сервер працює із завантаженням менше 80 відсотків, але це не свідчить про несправність.

Іншим лічильником, який необхідно використовувати, є “Довжина черги процесора”, який знаходиться в об’єкті “Система” системного монітора. Лічильник “Довжина черги процесора” показує кількість потоків, які очікують виконання на процесорі. Управління роботою SQL Server здійснюється за допомогою планувальників в механізмі СУБД, де сервер поміщає в чергу і обробляє власні запити. Оскільки робота SQL Server управляє ним самим, він використовує тільки один потік ЦП для кожного логічного процесора. Це означає, що в черзі процесора системи, призначеної для SQL Server, має перебувати мінімальна кількість потоків. Зазвичай кількість потоків на виділеному сервері SQL Server в п’ять разів менше кількості фізичних процесорів, але я вважаю, що якщо кількість потоків в два рази перевищує кількість фізичних процесорів, це вже є проблемою. На серверах, де крім СУБД використовуються і інші програми, цей лічильник необхідно використовувати разом з лічильниками продуктивності “% Завантаженості процесора” і “контекстних перемикань / сек” (перемикання контексту будуть розглянуті пізніше) для визначення необхідності переміщення СУБД або додатків на інший сервер.

При виникненні черги процесора і високою завантаженні ЦП я використовую лічильники “Compilations / sec” (компіляція / с) і “Re-Compilations/sec” (Повторних компіляцій / с) об’єкта продуктивності “SQL Server: статистика SQL “(див. рис. 1). Компіляція і повторна компіляція планів запитів впливає на завантаження ЦП системи. Значення повторних компіляцій повинні бути близько нуля, але необхідно перевірити потоки системи, щоб визначити звичайну поведінку сервера і допустима кількість компіляцій. Не завжди вдається уникнути повторних компіляцій, але можна оптимізувати запити і збережені процедури, щоб звести до мінімуму кількість повторних компіляцій і використань планів запитів. Порівняйте ці значення з фактичними надходять в систему інструкціями SQL за допомогою лічильника “Пакетних запитів / с”, який також знаходиться в об’єкті “SQL Server: статистика SQL”. Якщо компіляції і повторні компіляції становлять значний відсоток вступників в систему запитів пакетів, це місце необхідно перевірити. Іноді розробники SQL можуть не розуміти, як і чому їх код може впливати на ці типи проблем системних ресурсів. Далі в цій статті я приведу посилання, які допоможуть звести до мінімуму дії такого типу.


Рис. 1 Вибір лічильників для відстеження

У системному моніторі знайдіть лічильник продуктивності “Контекстні перемикань / сек” (див. рис. 2).

Рис. 2 Використовувані лічильники продуктивності































































Лічильник продуктивності  Об’єкт лічильника  Граничне значення  Примітки 
“% Використовуваного часу процесора” Процесор > 80% Можливі причини включають недолік пам’яті, рідкісне повторне використання плану запиту, неоптимізовані запити.
“Контекстні перемикань / сек” Система > 5000 x (число процесорів) Можливі причини включають інші додатки на сервері, кілька екземплярів SQL Server на одне сервері, включення технології hyper-threading.
“Довжина черги процесора” Система > 5 x (число процесорів) Можливі причини включають інші додатки на сервері, велика кількість компіляцій або перекомпіляції, кілька екземплярів SQL Server на одне сервері.
“Compilations / sec” (компіляція / с) SQLServer: статистика SQL Тенденція Порівняння з лічильником “Запитів пакетів / с”
“Re-Compilations/sec” (Перекомпіляція / с) SQLServer: статистика SQL Тенденція Порівняння з лічильником “Запитів пакетів / с”
“Запитів пакетів / с” SQLServer: статистика SQL Тенденція Порівняння з кількістю компіляцій і перекомпіляції в секунду.
“Очікуваний термін життя сторінки” SQLServer: диспетчер буферів < 300 Можлива брак пам’яті.
“Відкладених записів / с” SQLServer: диспетчер буферів Тенденція Можливий скидання великого кеша даних або брак пам’яті.
“Checkpoints / sec” (Контрольних точок / с) SQLServer: диспетчер буферів Тенденція Оцінка контрольних точок за допомогою лічильників “Очікуваний термін життя сторінки” і “Відкладених записів / с”.
Коефіцієнт попадання в кеш: плани SQL SQLServer: кеш планів < 70% Вказує на рідкісне повторне використання плану.
Коефіцієнт попадання в буферний кеш SQLServer: диспетчер буферів < 97% Можлива брак пам’яті.

Цей лічильник вказує кількість отримань потоків з планувальників операційної системи (не з планувальників SQL) для виконання операцій для інших потоків у стані очікування. Часто перемикання контексту відбуваються значно частіше в системах база даних, що використовуються спільно з іншими програмами, такими як IIS або компонентами сервера додатків сторонніх виробників. Для лічильника “контекстних перемикань / сек “я використовую порогове значення приблизно в 5000 разів більше кількості процесорів в сервері. Це значення також може бути високим в системах з включеною гіперпоточностью і невисокою завантаженням ЦП. Якщо порогові значення завантаження ЦП і перемикань контексту регулярно перевищуються, це говорить про наявність вузького місця, пов’язаного з ЦП. Якщо такі ситуації виникають регулярно, і ваша система застаріла, необхідно запланувати придбання додаткових або більш швидких процесорів. Додаткові відомості наведено на бічній панелі “Гіперпоточность”.

Модуль відкладеного запису SQL Server (як він називається в SQL Server 2000) або монітор ресурсів (як він називається в SQL Server 2005) – це інша область для спостереження за високої завантаженні ЦП. Скидання буфера і кеші процедур можуть збільшувати процесорний час через потік ресурсів, званий монітором ресурсів. Монітор ресурсів – це процес SQL Server, що визначає сторінки для збереження та сторінки для записи з буферного пула на диск. Всім сторінкам в буфері і кешах процедур спочатку присвоєні вартості, що представляють ресурси, що споживаються при приміщенні цієї сторінки в кеш. Ці значення вартостей зменшуються при кожній перевірці монітором ресурсів. При необхідності для запиту простору в кеші сторінки видаляються з пам’яті на основі привласнених для всіх сторінок витрат; сторінки з найнижчими значеннями будуть видалятися в першу чергу. Операції монітора ресурсів можна відстежити за допомогою лічильника продуктивності “Відкладених записів / с” об’єкта “SQL Server: диспетчер буферів” системного монітора. Необхідно відстежити зміну цього значення, щоб визначити звичайне для вашої системи порогове значення. Зазвичай цей лічильник використовується разом з лічильниками “Очікуваний термін життя сторінки” і “Checkpoints / sec” (Контрольних точок / с) для визначення наявності нестачі пам’яті.

Лічильник “Очікуваний термін життя сторінки” допомагає визначити наявність браку пам’яті. Лічильник “Очікуваний термін життя сторінки” показує тривалість перебування сторінки даних в буферному кеші. Загальноприйняте в галузі порогове значення для цього лічильника – 300 секунд. Значення нижче середнього значення в 300 секунд, що зберігається протягом тривалого часу, свідчить про те, що сторінки даних видаляються з пам’яті занадто часто. Це збільшує обсяг роботи монітора ресурсів, що в свою чергу призводить до збільшення завантаження процесорів. Показання лічильника “Очікуваний термін життя сторінки” повинні оцінюватися разом з показаннями лічильника “Сторінок контрольних точок / с”. При виникненні в системі контрольної точки “брудні” сторінки даних в буферному кеші записуються на диск, викликаючи зменшення значення лічильника “Очікуваний термін життя сторінки”. Процес “Монітор ресурсів” – це механізм, фактично записуючий ці сторінки на диск, тому при виникненні контрольних точок також збільшується значення лічильника “Відкладених записів / с”. Якщо значення лічильника “Очікуваний термін життя сторінки” збільшується відразу після виконання контрольної точки, на це тимчасове явище можна не звертати увагу. З іншого боку, при виявленні того, що значення лічильника “Очікуваний термін життя сторінки” регулярно знаходиться нижче порогового значення, велика ймовірність, що збільшення обсягу пам’яті призведе до усунення проблем і звільненню частини ресурсів для ЦП. Всі ці лічильники знаходяться в об’єкті продуктивності “SQL Server: диспетчер буферів”.

Відстеження SP

При трасуванні додатка SQL Server є сенс ознайомитися з використовуваними для трасування збереженими процедурами. Використання для трасування графічного інтерфейсу (SQL Server Profiler) може збільшити навантаження на систему на 15 – 25 відсотків. Використання для трасування збережених процедур може знизити відсоток збільшення навантаження приблизно наполовину.


Якщо мені відомо про наявність в системі вузьких місць і необхідно визначити поточні інструкції SQL, що є причинами проблем на сервері, я виконую наведений нижче запит. Цей запит допомагає отримати уявлення про окремі інструкціях і використовуються ними на даний момент ресурсах, а також про інструкції, які необхідно вивчити для підвищення продуктивності. Додаткові відомості про трасування SQL приведені на веб-сторінці msdn2.microsoft.com/ms191006.aspx.

SELECT
substring(text,qs.statement_start_offset/2
,(CASE
WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2
ELSE qs.statement_end_offset
END – qs.statement_start_offset)/2)
,qs.plan_generation_num as recompiles
,qs.execution_count as execution_count
,qs.total_elapsed_time – qs.total_worker_time as total_wait_time
,qs.total_worker_time as cpu_time
,qs.total_logical_reads as reads
,qs.total_logical_writes as writes
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
LEFT JOIN sys.dm_exec_requests r
ON qs.sql_handle = r.sql_handle
ORDER BY 3 DESC


Шлях 2. Продуктивність запитів

Плани запитів аналізуються, оптимізуються, компілюються і поміщаються в кеш процедур при відправці на SQL Server нового запиту. При кожній відправці серверу запиту виконується перевірка кешу процедур для спроби зіставлення плану запиту із запитом. При відсутності плану запиту SQL Server створює новий план для запиту, що може бути дорогою операцією.

Нижче наведені деякі важливі моменти, що стосуються оптимізації ЦП для T-SQL.

Розглянемо ці моменти. Зазвичай SQL Server отримує дані з пам’яті і з диска; робота тільки з однією сторінкою даних зустрічається досить рідко. Набагато чаші кілька частин програми працюють із записом, виконують кілька невеликих запитів або об’єднують таблиці для створення загального подання відповідних даних. У середовищах OLAP додатки можуть отримувати мільйони рядків з однієї або двох таблиць, роблячи можливими консолідацію, накопичення і підсумовування даних для регіональних відповідей про продажі. У подібних випадках повернення даних може вимірюватися в мілісекундах, якщо дані знаходяться в пам’яті, а отримання цих же даних з диска може тривати кілька хвилин.

Перший приклад – це ситуація з великою кількістю транзакцій, в якій повторне використання плану залежить від програми. Рідкісне повторне використання плану обумовлює велике число компіляцій інструкцій SQL, для чого потрібно значний обсяг процесорної обробки. У другому прикладі високе завантаження ресурсів може призвести до надмірної активності системного ЦП, оскільки потрібне постійне видалення існуючих даних з буферного кешу для звільнення простору для нових сторінок даних великого обсягу.

Розглянемо систему з високою інтенсивністю транзакцій, в якій інструкція SQL, подібна показаної нижче, виконується 2000 разів протягом 15 хвилин для отримання інформації про транспортну упаковці. Гіпотетично, без повторного використання плану запиту час виконання однієї інструкції складає близько 450 мс. При використанні цього ж плану запиту після першого виконання час виконання наступного запиту може становити близько 2 мс, а загальний час виконання – близько 5 секунд.

USE SHIPPING_DIST01;
SELECT
Container_ID
,Carton_ID
,Product_ID
,ProductCount
,ModifiedDate
FROM Container.Carton
WHERE Carton_ID = 982350144;

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

Корисним джерелом великих відомостей є динамічні адміністративні подання (DMV). При високому завантаженні ЦП я використовую кілька DMV для визначення правильності використання ЦП.

Одним з використовуваних DMV є sys.dm_os_wait_stats, за допомогою якого адміністраторам баз даних можна надати кошти визначення всіх використовуваних сервером SQL функцій і типів ресурсів, а також визначити час очікування системи, пов’язане з цим ресурсом. Лічильники в цьому DMV є накопичувальними. Це означає, що для отримання чіткого уявлення про ресурси, які можуть впливати на різні області системи, після перевірки даних на предмет наявності невирішених проблем перш за все необхідно виконати команду DBCC SQLPERF (“sys.dm_os_wait_stats”, CLEAR). Динамічне адміністративне подання sys.dm_os_wait_stats є еквівалентом команди перевірки узгодженості бази даних DBCC SQLPERF (WAITSTATS) в SQL Server 2000. Додаткові відомості про різні типи очікування наведені в електронній документації по SQL Server на веб-сайті msdn2.microsoft.com / ms179984.aspx.

Важливо розуміти, що зазвичай очікування присутні навіть при оптимальній роботі системи. Необхідно лише визначити, чи впливають на очікування обмеження з боку ЦП. Час очікування сигналів щодо загального часу очікування повинно бути якомога менше. Час очікування ресурсу процесора певним ресурсом може бути визначено простим відніманням часу очікування сигналу із загального часу очікування; це значення не має перевищувати приблизно 20 відсотків загального часу очікування.

Динамічне адміністративне уявлення sys.dm_exec_sessions показує всі відкриті сеанси на сервері SQL Server. Це DMV надає узагальнене уявлення продуктивності всіх сеансів і всіх дій, виконаних в кожному сеансі з моменту відкриття. Сюди ходить загальний час очікування сеансу, загальна завантаження ЦП, використання пам’яті і кількість операцій читання і запису. DMV також надає відомості про вхід, часу входу, локальному комп’ютері і часу останнього запиту сеансом сервера SQL Server.

Динамічне адміністративне уявлення the sys.dm_exec_sessions дозволяє визначати тільки активні сеанси, тому це одне з перших місць для пошуку при високому завантаженні ЦП. Спочатку необхідно виконувати перевірку сеансів з великим числом ЦП. Визначте додаток і користувача, який виконує роботу, потім перейдіть до поглибленого аналізу. Використання sys.dm_exec_sessions разом з sys.dm_exec_requests може надати велику кількість інформації, доступної через збережені процедури sp_who і sp_who2. При об’єднанні даних з функцією динамічного управління sys.exec_sql_text в стовпці sql_handle можна отримати поточний виконується запит сеансу. У фрагменті коду на рис. 3 продемонстровано об’єднання цих даних для отримання відомостей про те, що відбувається на сервері.

Рис. 3 Визначення активності сервера

SELECT es.session_id
,es.program_name
,es.login_name
,es.nt_user_name
,es.login_time
,es.host_name
,es.cpu_time
,es.total_scheduled_time
,es.total_elapsed_time
,es.memory_usage
,es.logical_reads
,es.reads
,es.writes
,st.text
FROM sys.dm_exec_sessions es
LEFT JOIN sys.dm_exec_connections ec
ON es.session_id = ec.session_id
LEFT JOIN sys.dm_exec_requests er
ON es.session_id = er.session_id
OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st
WHERE es.session_id > 50 — < 50 system sessions
ORDER BY es.cpu_time DESC

Я вважаю, що цей оператор дозволяє визначити програми, яким необхідно приділити особливу увагу. Коли я порівнюю ЦП, пам’ять, логічні зчитування, операції читання і запису всіх сеансів програми і визначаю, що завантаження ресурсів ЦП набагато вище завантаження інших ресурсів, я акцентую увагу на цих операторах SQL.

Для відстеження інструкцій SQL по журналу для програми я використовую траси SQL Server. Для цього можна використовувати засіб SQL Server Profiler або системні збережені процедури трасування, щоб оцінити відбувається. (Додаткові відомості з цієї теми наведено на бічній панелі “Трасування SP”.) У програмі Profiler необхідно перевірити оператори з високою завантаженням ЦП, попередження хешування і сортування, промахи в кеші і інші червоні прапори. Це дозволяє звузити об’єкти перевірки до певних операторів SQL або періоду часу з високою завантаженням ресурсів. Програма Profiler дозволяє відстежувати текст інструкцій SQ, плани виконання, завантаженість ЦП, використання пам’яті, логічні зчитування, запис, кешування планів запитів, перекомпіляції, вилучення планів запитів з кешу, промахи в кеші, перегляди таблиць і індексів, відсутність статистики і безліч інших подій.

Після збору даних за допомогою збережених процедур sp_trace або засоби SQL Server Profiler я зазвичай використовую базу даних, заповнену вже отриманими даними трасування або даними, які будуть отримані після установки для трасування записи в базу даних. Заповнення бази даних вже отриманими даними може бути виконано за допомогою системної функції SQL Server з назвою fn_trace_getinfo. Перевага цього підходу полягає в можливості запиту і сортування даних декількома способами для визначення інструкцій SQL, що використовують велику частину часу ЦП або мають більшу кількість операцій читання, визначення кількість перекомпіляції і пр. Ось приклад використання цієї функції для завантаження таблиці з файлом трасування Profile. За замовчуванням всі файли для цієї трасування будуть завантажені в порядку їх створення:

SELECT * INTO trc_20070401
FROM fn_trace_gettable(“S:MountpointsTRC_20070401_1.trc”, default);
GO


Висновок

Як показано вище, високе завантаження ЦП не обов’язково свідчить про наявність вузького місця, пов’язаного з процесором. Висока завантаження ЦП може також приховувати ряд інших вузьких місць, пов’язаних з додатками або обладнанням. Після визначення високого завантаження ЦП, незважаючи на допустимі свідчення інших лічильників, можна почати пошук причини в системі і знайти рішення (будь то придбання додаткових процесорів або оптимізація коду SQL). Що б ви не робили, не здавайтеся! Наведені в даній статті поради, а також трохи практичних матеріалів і досліджень роблять оптимізацію завантаження ЦП в SQL Server досяжною завданням.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*