Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
ПалЪ СанычЪ
Member

Откуда:
Сообщений: 37
sntr,

[url=]http://sqlmag.com/sql-server/investigating-trace-flags[/url]

Но это не совсем, что вам нужно. Да и флаги недокументированые и старые(не факт, что работают для новых версий).
Пробуйте,сравнивайте :)
9 окт 15, 15:21    [18259175]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
sntr
Member

Откуда:
Сообщений: 18
Serg_77m
sntr
Но если из текста запроса на операциях JOIN удалить hint LOOP и удалить hint FORCE ORDER из OPTION, то запрос выполняется моментально.
А если к LOOP добавить FORCESEEK - какая скорость?

С процедурой sp_create_plan_guide не экспериментировали?


с FORCESEEK - также, также тормозит.

с sp_create_plan_guide - не экспериментировали, но смотрели в эту сторону, использовать ее будет крайне затруднительно, т.к. все данные в одной таблице AllUserData и ORM SP генерирует запросы кодом, и текст запроса, можно сказать всегда разный (от любого чиха, настроенный фильтр, или примененная группировка и еще с десяток условий, или запрос вывода таблицы, или запрос экспорта в excel, +/- поле в тексте запроса:- тексты всегда будут разные), т.е. под каждый случай написать план не реально.
ну и еще, я не эксперт в SQL, и тямы использовать sp_create_plan_guide не хватает.
9 окт 15, 16:42    [18259707]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
sntr
Member

Откуда:
Сообщений: 18
ПалЪ СанычЪ
sntr,

[url=]http://sqlmag.com/sql-server/investigating-trace-flags[/url]

Но это не совсем, что вам нужно. Да и флаги недокументированые и старые(не факт, что работают для новых версий).
Пробуйте,сравнивайте :)


пробовали, не помогает.
9 окт 15, 16:57    [18259779]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
sntr
Member

Откуда:
Сообщений: 18
МуМу,
а можно подробнее? как с Вами связаться?
9 окт 15, 17:00    [18259793]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
guest45
Guest
ну, вообще-то We strongly recommended limiting the size of content databases to 200 GB to help ensure system performance.
9 окт 15, 17:35    [18259959]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
sntr
Member

Откуда:
Сообщений: 18
guest45
ну, вообще-то We strongly recommended limiting the size of content databases to 200 GB to help ensure system performance.


у нас 33 ГБ, и не один лимит от МС не превышен!!!
9 окт 15, 17:53    [18260031]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
guest45
Guest
удалите все автоматически созданные статистики
select *
from sys.stats
where auto_created=1

обновите статистики с помощью proc_UpdateStatistics
10 окт 15, 03:20    [18261743]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
guest45
Guest
впрочем, не надо заморачиваться на удаление
proc_UpdateStatistics это сделает сама
10 окт 15, 04:00    [18261748]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Компания называется Softpoint.(softpoint.ru) Лучше написать на общий ящик. Продукт называется QProcessing. Ставится в виде дополнительного сервиса и выполняет роль прокси. Линейное замедление не более 2%. С помощью настроек имеется возможность менять запросы на лету. (ну тривиальные вещи , убрать хинты или добавить recompile. но можно и сложнее, поменять структуру запроса). Не вляет на остальную функциональность. Если его отключить - просто не будет подмены запросов. Впрочем менеджеры объяснят подробнее. Есть возможность пощупать руками на стенде.
10 окт 15, 12:38    [18262182]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
МуМу
Member

Откуда:
Сообщений: 1134
То sntr. Добавлю, во вторник будет семинар в Microsoft Technology Center (г. Москва, ул. Лесная д.5, БЦ «Белые Сады»). Я там буду читать один из докладов. Про это решение буду также рассказывать(правда не много). Можно будет на месте посмотреть. Насколько знаю еще есть места. Ссылка на регистрацию http://www.softpointplus.ru/novosti-it-system/conference-performance-optim.html
11 окт 15, 13:34    [18264119]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
sntr
Member

Откуда:
Сообщений: 18
guest45
удалите все автоматически созданные статистики
select *
from sys.stats
where auto_created=1

обновите статистики с помощью proc_UpdateStatistics


обновляли - не помогает.
12 окт 15, 16:18    [18268360]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
BrokenPot
Member

Откуда: Киев
Сообщений: 1405
Регулярная перестройка индексов средствами MaintenancePlan делается?
12 окт 15, 17:02    [18268718]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
BrokenPot
средствами MaintenancePlan делается?

Почему именно MaintenancePlan ?
Я вот не люблю этот инструмент.
12 окт 15, 17:10    [18268765]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
BrokenPot
Member

Откуда: Киев
Сообщений: 1405
Я - тоже.

Но количество БД и внезапное возникновение новых вынудило меня прибегнуть к этому средству.

А какими средствами делается?
12 окт 15, 17:29    [18268881]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
BrokenPot
Я - тоже.

Но количество БД и внезапное возникновение новых вынудило меня прибегнуть к этому средству.

А какими средствами делается?


"Внезапно" на продуктиве база не может, по хорошему, появится. Как минимум контур разработки и uat это должно предшествовать.

Использую скрипты, выполняемые SQL Server агентом.
12 окт 15, 17:39    [18268949]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
sntr
Member

Откуда:
Сообщений: 18
BrokenPot
Регулярная перестройка индексов средствами MaintenancePlan делается?


Регулярное не делаем. Но, на тестовом сервере, делали перестройку индексов, либо толку ноль, либо еще хуже становилось.

Коллеги, причина в том, что анализатор запросов ошибается, а ошибается он из-за подсказок LOOP JOIN и ORDER FORCE. вот если бы он не ошибался, то тут и статистика и индексы бы помогли. (могу ошибаться)
13 окт 15, 16:29    [18273655]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
росгосстатбезприврат
Guest
sntr
либо еще хуже становилось.

а статистика обновляется?
13 окт 15, 16:53    [18273877]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7869
sntr,

не исключено, что хинты были эффективны для другой версии SQL сервера.
13 окт 15, 16:56    [18273901]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
Ozerov
Member

Откуда: Москва
Сообщений: 3650
Владислав Колосов
sntr,

не исключено, что хинты были эффективны для другой версии SQL сервера.


Как вариант...
Можно попробовать понизить уровень совместимости.
13 окт 15, 17:03    [18273956]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
МуМу
Member

Откуда:
Сообщений: 1134
По своему опыту могу дать лишь один совет. Пересчет статистики с Full scan. Попробуйте, может помочь.(правда там другой вопрос после этого станет)
13 окт 15, 19:02    [18274467]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
МуМу
По своему опыту могу дать лишь один совет. Пересчет статистики с Full scan. Попробуйте, может помочь.(правда там другой вопрос после этого станет)
Если там понатыкано LOOP JOIN и FORCE ORDER, то на статистику оптимизатору уже пофигу. Точнее, он на нее конечно посмотрит, но сделать ничего уже не сможет.
14 окт 15, 01:29    [18275523]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
MSSQLBug
Guest
o-o
ну а вдруг уже придумали *позапросное* отцепление хинтов, просто мы не в курсе дел?
прицепление же есть -- plan guides

С помощью plan guides можно и отцепить:

https://msdn.microsoft.com/en-us/library/hh213001(v=sql.110).aspx

When a plan guide matches a query, the OPTION clause specified in the hints
clause of a plan guide is added to the query before it compiles and optimizes.
If a query that is matched to a plan guide already has an OPTION clause,
the query hints specified in the plan guide replace those in the query.


https://msdn.microsoft.com/en-us/library/ms179880.aspx

sp_create_plan_guide

[@hints = ] { N'OPTION ( query_hint [ ,...n ] )' | N'XML_showplan' | NULL }

NULL
Indicates that any existing hint specified in the OPTION clause
of the query is not applied to the query.


Я лично использовал только последнее (@hints = NULL). И JOIN HINTS так, вроде, не отцепишь.

Но с учётом вот этого:
sntr
с sp_create_plan_guide - не экспериментировали, но смотрели в эту сторону, использовать ее будет крайне затруднительно, т.к. все данные в одной таблице AllUserData и ORM SP генерирует запросы кодом, и текст запроса, можно сказать всегда разный (от любого чиха, настроенный фильтр, или примененная группировка и еще с десяток условий, или запрос вывода таблицы, или запрос экспорта в excel, +/- поле в тексте запроса:- тексты всегда будут разные), т.е. под каждый случай написать план не реально.


Использовать задолбаешься. :( Тысячи их создавать, что ли (кстати, интересно, как это повлияет на производительность обработки запросов в целом)?
14 окт 15, 12:03    [18276920]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
o-o
Guest
MSSQLBug,

чего-то никак не соображу,
чем же это можно *заменить* FORCE ORDER.
вижу там только ATTACH и REPLACE, ни вижу DETACH, простите
14 окт 15, 12:08    [18276950]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
MSSQLBug
Guest
o-o
MSSQLBug,
чего-то никак не соображу,
чем же это можно *заменить* FORCE ORDER.
вижу там только ATTACH и REPLACE, ни вижу DETACH, простите

Да NULL-ом же. ;)

Я вот про это:
CREATE TABLE TestTbl1(A INT PRIMARY KEY, B INT);
INSERT INTO TestTbl1 VALUES (1,1), (2,2), (3,3);

CREATE TABLE TestTbl2(A INT, B INT PRIMARY KEY);
INSERT INTO TestTbl2 VALUES (1,1), (2,2), (3,3), (4,4), (5,5);

CREATE TABLE TestTbl3(A INT, B INT);
CREATE UNIQUE CLUSTERED INDEX i ON TestTbl3(A, B);
INSERT INTO TestTbl3 VALUES (1,1), (3,3), (5,5);
-------
-- Ну и запрос:
SELECT * 
  FROM TestTbl1 AS t1
 INNER JOIN TestTbl2 AS t2
    ON t1.A = t2.A
 INNER JOIN TestTbl3 AS t3
    ON t3.A = t2.A
OPTION (FORCE ORDER)

-- План такой:
  |--Nested Loops(Inner Join, OUTER REFERENCES:([t2].[A]))
       |--Hash Match(Inner Join, HASH:([t1].[A])=([t2].[A]), RESIDUAL:([ReportServer].[dbo].[TestTbl2].[A] as [t2].[A]=[ReportServer].[dbo].[TestTbl1].[A] as [t1].[A]))
       |    |--Clustered Index Scan(OBJECT:([ReportServer].[dbo].[TestTbl1].[PK__TestTbl1__3BD019AEE9699913] AS [t1]))
       |    |--Clustered Index Scan(OBJECT:([ReportServer].[dbo].[TestTbl2].[PK__TestTbl2__3BD019AF0F57582F] AS [t2]))
       |--Clustered Index Seek(OBJECT:([ReportServer].[dbo].[TestTbl3].[i] AS [t3]), SEEK:([t3].[A]=[ReportServer].[dbo].[TestTbl2].[A] as [t2].[A]) ORDERED FORWARD)

-- А после:
EXEC sp_create_plan_guide 
    @name = N'Guide1_for_plan', 
    @stmt = 'SELECT * 
  FROM TestTbl1 AS t1
 INNER JOIN TestTbl2 AS t2
    ON t1.A = t2.A
 INNER JOIN TestTbl3 AS t3
    ON t3.A = t2.A
OPTION (FORCE ORDER)', 
    @type = N'SQL',
    @module_or_batch = NULL, 
    @params = NULL, 
    @hints = NULL;

-- Получается такой (такой же, как и без FORCE ORDER):
  |--Hash Match(Inner Join, HASH:([t3].[A])=([t2].[A]), RESIDUAL:([ReportServer].[dbo].[TestTbl3].[A] as [t3].[A]=[ReportServer].[dbo].[TestTbl2].[A] as [t2].[A]))
       |--Nested Loops(Inner Join, OUTER REFERENCES:([t1].[A]))
       |    |--Clustered Index Scan(OBJECT:([ReportServer].[dbo].[TestTbl1].[PK__TestTbl1__3BD019AEE9699913] AS [t1]))
       |    |--Clustered Index Seek(OBJECT:([ReportServer].[dbo].[TestTbl3].[i] AS [t3]), SEEK:([t3].[A]=[ReportServer].[dbo].[TestTbl1].[A] as [t1].[A]) ORDERED FORWARD)
       |--Clustered Index Scan(OBJECT:([ReportServer].[dbo].[TestTbl2].[PK__TestTbl2__3BD019AF0F57582F] AS [t2]))
14 окт 15, 12:59    [18277251]     Ответить | Цитировать Сообщить модератору
 Re: Деградация производительности SharePoint (медленное выполнение запросов SQL)  [new]
o-o
Guest
MSSQLBug
Получается такой (такой же, как и без FORCE ORDER):

на смешные данные и план смешной.
вот хотя бы так:

К сообщению приложен файл. Размер - 126Kb
14 окт 15, 13:23    [18277437]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить