Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Страшные блокировки, прошу помощи.  [new]
Ablok
Member

Откуда:
Сообщений: 10
Доброго времени суток.
Сразу оговорюсь, что в Sql не много понимаю.
Имеется sql 2008 R2, и на нем крутятся базы для 1с. Сервер sql отдельно от сервера 1с.
Решили сделать переиндексацию и сжатие базы, плюс дефрагментацию.
После данных действий в одной из баз при работе в 1с, наблюдается следующая картина.
Когда кто-то проводит внутренний заказ который опрашивает склады на наличие товара и резервы для него, и соответственно устанавливает резервы. Любые документы связанные с остатками товаров не проводятся по причине блокировки.
При этом некоторые внутренние заказы проводятся быстро, а некоторые очень долго минут по 7. При том что и там и там количество товара одинаково.
При этом при помощи скрипта выяснил, что блокируются две таблицы большого объема по 700 мб.
Может подскажите, что можно будет сделать с такими блокировками. Я могу на копии попробовать их реализовать.
Может как-то таблицы разбить или еще что-то.
Заранее спасибо.
12 мар 14, 17:35    [15712270]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Попробуйте выполнить sp_updatestats в нерабочее время, это может занять относительно длительное время.
12 мар 14, 18:06    [15712519]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Speshuric
Member

Откуда: г. Москва
Сообщений: 129
Ablok
Доброго времени суток.
Сразу оговорюсь, что в Sql не много понимаю.
...
Заранее спасибо.



Эту задачу нужно решать со стороны 1С, тут слишком много "если": версия платформы, режим совсестимости конфигурации, какая конфигурация, автоматические или управляемые транзакционные блокировки, используется ли read committed snapshot и т.д. и т.п. Самый простой вариант, учитывая "Сразу оговорюсь, что в Sql не много понимаю": пригласить специалиста.
Более сложный, но бюджетный: например, прочитать недавно вышедшую книгу "Настольная книга 1С:Эксперта по технологическим вопросам", судя по содержанию - достаточно полное руководство по самолечению. Правда, судя по обсуждению там уже нашли кучку достаточно обидных опечаток, но это решаемо.
12 мар 14, 18:31    [15712647]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Ablok
Member

Откуда:
Сообщений: 10
Обновление статистики я делал.
Не помогло.
Там если посмотреть по процессам на SQL сервере, присутствует такой момент, что к этой базе даже обращений нет, работает только темп лог и все. А база все равно висит заблокированной, потом опять появляется в процессах и завершает проведение.
12 мар 14, 20:06    [15713170]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34621
[i][/i]Ablok,

Принудительно заставь всех выйти из 1c и зайти обратно. Убей все сессии в бд. В крайнем случае перегрузи сервер бд.
12 мар 14, 20:10    [15713193]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Ablok
Member

Откуда:
Сообщений: 10
Не помогло
12 мар 14, 22:55    [15713982]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Ablok,

Опишите процесс исследования и результаты (а не их интерпретацию), благодаря которым вы точно выяснили, что причиной являются блокировки.

Просто странно, что блокировки появились после определенных действий, когда: код не менялся, логика не менялась, структура не менялась, нагрузка не менялась, и вообще это стандартное приложение 1С. Если это действительно блокировки, то почему их не было раньше.

В крайнем случае, если это правда блокировки, может быть протестировать вариант с включением read committed snapshot. Но имхо, нужно начать с анализа что изменилось, почему подобного не было раньше, понять причину.
12 мар 14, 23:05    [15714030]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Ablok
Member

Откуда:
Сообщений: 10
Были проведены следующие операции. Перестроение индекса, реорганизация индекса, обновление статистики и сжатие бд.
Кстати сжатие толку не дало.
Сама база весит 50 гб находится на SSD рейде 10. 1с сервер 4 ядра проц, и 8 гб оперативы, вся занята не бывает.
SQL сервер 2008 R2 2 проца xeon по 12 ядер, 48гб оперативы.
Для обнаружения блокировок таблиц использовал с сайта Гилева конфу и скрипт, и там и там в принципе результаты ссылаются постоянно на одни те же таблицы.
Поэтому и сделано предположение, что дело в таблицах. Ранее заполненость страниц была 64-65% и фрагментация на том же уровне и все прекрасно работало. В данный момент заполненость страниц стала 99% и фрагментация почти 0%.
Но как то страно ведет себя сам процесс. Так некоторые документы проводятся достаточно оперативно, а некоторые могут висеть минут по семь, при этом на сервере реально практически ничего не происходит, т.е. ресурсы вообще не задействуются.
Такое ощущение, что запрос просто засыпает.
12 мар 14, 23:31    [15714160]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Ablok, а не включено ли для этой базы случаем Auto Close?
13 мар 14, 06:46    [15714716]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Ablok
Member

Откуда:
Сообщений: 10
Нет, Auto close выключена.
13 мар 14, 08:50    [15714856]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Ablok
Для обнаружения блокировок таблиц использовал с сайта Гилева конфу и скрипт, и там и там в принципе результаты ссылаются постоянно на одни те же таблицы.

Скажу честно, я не знаю что это за скрипты, может быть у вас действительно дело в блокировках. Но это можно проверить, посмотрите статистику ожиданий. Сделайте слепок статистики ожиданий из sys.dm_os_wait_stats, подождите какое-то время пока пройдут тормозные операции, сделайте второй слепок, сравните два. Если сервер в основном ждет на блокировках, вы это увидите. Будут ожидания типа LCK_... Вообще, помониторить ожидания хорошая отправная точка, особенно раз вы пишете:
автор
Так некоторые документы проводятся достаточно оперативно, а некоторые могут висеть минут по семь, при этом на сервере реально практически ничего не происходит, т.е. ресурсы вообще не задействуются.

Собственно, узнаете чего ждет сервер.

Пока больше похоже, что если что раз вы поборолись с фрагментацией, то возможно дело в Page Split-ах. Попробуйте помониторить в PerfMon-е счетчик Page Splits/sec, посмотрите график, как он ведет себя в течение дня, сопоставьте с временами тормозов. Также можно достать значения счетчика из "select * from sys.dm_os_performance_counters where counter_name like 'Page Splits/sec%'", но интересно динамику увидеть. По ожиданиям в этот момент можно увидеть много ожиданий PAGELATCH_EX, PAGELATCH_SH (не перепутайте с PAGEIOLATCH_...). Если дело в этом, перестройте ваши индексы еще раз, на этот раз указав fillfactor, скажем процентов 80 (лучше, конечно, сами примерно посчитайте исходя из нагрузки).
13 мар 14, 09:20    [15714969]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Ablok
Member

Откуда:
Сообщений: 10
Сейчас поставил в 1с на тестовой базе проверку логической целостности и она как раз дошла до регистров накоплений.Внутренние заказы и так же как при проведение данного вида документов, ощущение, что тупо спит.
Указано, что данная таблица заблокированна с ключем блокировки стабильности схемы и вот текст запроса.
(@P1 numeric(10),@P2 varbinary(16),@P3 varbinary(4),@P4 varbinary(16),@P5 varbinary(4),@P6 varbinary(4))SELECT TOP 256 _AccumRg4439._Period AS _Period, _AccumRg4439._RecorderTRef AS _RecorderTRef, _AccumRg4439._RecorderRRef AS _RecorderRRef, _AccumRg4439._LineNo AS _LineNo, _AccumRg4439._Active AS _Active, _AccumRg4439._RecordKind AS _RecordKind, _AccumRg4439._Fld4440_TYPE AS _Fld4440_TYPE, _AccumRg4439._Fld4440_RTRef AS _Fld4440_RTRef, _AccumRg4439._Fld4440_RRRef AS _Fld4440_RRRef, _AccumRg4439._Fld4441RRef AS _Fld4441RRef, _AccumRg4439._Fld4442RRef AS _Fld4442RRef, _AccumRg4439._Fld4443RRef AS _Fld4443RRef, _AccumRg4439._Fld4444RRef AS _Fld4444RRef, _AccumRg4439._Fld4445 AS _Fld4445 FROM _AccumRg4439 WITH(NOLOCK) WHERE _AccumRg4439._LineNo > CAST(@P1 AS NUMERIC(3,0)) AND _AccumRg4439._RecorderRRef = @P2 AND _AccumRg4439._RecorderTRef = @P3 OR _AccumRg4439._RecorderRRef > @P4 AND _AccumRg4439._RecorderTRef = @P5 OR _AccumRg4439._RecorderTRef > @P6 ORDER BY _AccumRg4439._RecorderTRef, _AccumRg4439._RecorderRRef, _AccumRg4439._LineNo
13 мар 14, 09:26    [15715016]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Ablok
Member

Откуда:
Сообщений: 10
Кстати данный запрос в мониторе активности висит как самый ресурсоемкий.
И второй запрос к этой базе вот такой висит уже 8 минут.
SELECT
i.name AS [Index_Name],
CAST(i.index_id AS int) AS [Index_ID],
fi.index_depth AS [Depth],
fi.page_count AS [Pages],
fi.record_count AS [Rows],
fi.min_record_size_in_bytes AS [MinimumRecordSize],
fi.max_record_size_in_bytes AS [MaximumRecordSize],
fi.avg_record_size_in_bytes AS [AverageRecordSize],
fi.forwarded_record_count AS [ForwardedRecords],
fi.avg_page_space_used_in_percent AS [AveragePageDensity],
fi.index_type_desc AS [IndexType],
fi.partition_number AS [PartitionNumber],
fi.ghost_record_count AS [GhostRows],
fi.version_ghost_record_count AS [VersionGhostRows],
fi.avg_fragmentation_in_percent AS [AverageFragmentation]
FROM
sys.tables AS tbl
INNER JOIN sys.indexes AS i ON (i.index_id > @_msparam_0 and i.is_hypothetical = @_msparam_1) AND (i.object_id=tbl.object_id)
INNER JOIN sys.dm_db_index_physical_stats(@database_id, NULL, NULL, NULL, 'SAMPLED') AS fi ON fi.object_id=CAST(i.object_id AS int) AND fi.index_id=CAST(i.index_id AS int)
WHERE
(i.name=@_msparam_2)and((tbl.name=@_msparam_3 and SCHEMA_NAME(tbl.schema_id)=@_msparam_4))
ORDER BY
[Index_Name] ASC
13 мар 14, 10:11    [15715231]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Ablok,

Все еще висит? Если да, то что вернет для висящего запроса такой скрипт:
+
SELECT tl.resource_type
    , database_name = DB_NAME(tl.resource_database_id)
    , assoc_entity_id = tl.resource_associated_entity_id
    , lock_req = tl.request_mode
    , waiter_sid = tl.request_session_id
    , wait_duration = wt.wait_duration_ms
    , wt.wait_type
    , waiter_batch = wait_st.text
    , waiter_stmt = substring(wait_st.text,er.statement_start_offset/2 + 1,
                abs(case when er.statement_end_offset = -1
                then len(convert(nvarchar(max), wait_st.text)) * 2
                else er.statement_end_offset end - er.statement_start_offset)/2 + 1)
    , waiter_host = es.host_name
    , waiter_user = es.login_name
    , blocker_sid = wt.blocking_session_id
    , blocker_stmt = block_st.text 
    , blocker_host = block_es.host_name
    , blocker_user = block_es.login_name
FROM sys.dm_tran_locks tl (nolock)
    INNER JOIN sys.dm_os_waiting_tasks wt (nolock) ON tl.lock_owner_address = wt.resource_address
    INNER JOIN sys.dm_os_tasks ot (nolock) ON tl.request_session_id = ot.session_id AND tl.request_request_id = ot.request_id AND tl.request_exec_context_id = ot.exec_context_id
    INNER JOIN sys.dm_exec_requests er (nolock) ON tl.request_session_id = er.session_id AND tl.request_request_id = er.request_id
    INNER JOIN sys.dm_exec_sessions es (nolock) ON tl.request_session_id = es.session_id
    LEFT JOIN sys.dm_exec_requests block_er (nolock) ON wt.blocking_session_id = block_er.session_id
    LEFT JOIN sys.dm_exec_sessions block_es (nolock) ON wt.blocking_session_id = block_es.session_id 
    CROSS APPLY sys.dm_exec_sql_text(er.sql_handle) wait_st
    OUTER APPLY sys.dm_exec_sql_text(block_er.sql_handle) block_st
13 мар 14, 10:20    [15715288]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Speshuric
Member

Откуда: г. Москва
Сообщений: 129
Ablok
Сейчас поставил в 1с на тестовой базе проверку логической целостности и она как раз дошла до регистров накоплений.Внутренние заказы и так же как при проведение данного вида документов, ощущение, что тупо спит.
Указано, что данная таблица заблокированна с ключем блокировки стабильности схемы и вот текст запроса.
(@P1 numeric(10),@P2 varbinary(16),@P3 varbinary(4),@P4 varbinary(16),@P5 varbinary(4),@P6 varbinary(4))SELECT TOP 256 _AccumRg4439._Period AS _Period, _AccumRg4439._RecorderTRef AS _RecorderTRef, _AccumRg4439._RecorderRRef AS _RecorderRRef, _AccumRg4439._LineNo AS _LineNo, _AccumRg4439._Active AS _Active, _AccumRg4439._RecordKind AS _RecordKind, _AccumRg4439._Fld4440_TYPE AS _Fld4440_TYPE, _AccumRg4439._Fld4440_RTRef AS _Fld4440_RTRef, _AccumRg4439._Fld4440_RRRef AS _Fld4440_RRRef, _AccumRg4439._Fld4441RRef AS _Fld4441RRef, _AccumRg4439._Fld4442RRef AS _Fld4442RRef, _AccumRg4439._Fld4443RRef AS _Fld4443RRef, _AccumRg4439._Fld4444RRef AS _Fld4444RRef, _AccumRg4439._Fld4445 AS _Fld4445 FROM _AccumRg4439 WITH(NOLOCK) WHERE _AccumRg4439._LineNo > CAST(@P1 AS NUMERIC(3,0)) AND _AccumRg4439._RecorderRRef = @P2 AND _AccumRg4439._RecorderTRef = @P3 OR _AccumRg4439._RecorderRRef > @P4 AND _AccumRg4439._RecorderTRef = @P5 OR _AccumRg4439._RecorderTRef > @P6 ORDER BY _AccumRg4439._RecorderTRef, _AccumRg4439._RecorderRRef, _AccumRg4439._LineNo

Эм... (NOLOCK) и блокировки стабильности схемы говорят о том, что этот запрос НЕ БЛОКИРУЕТ содержимое таблиц. Проверка логической целостности вообще монопольный процесс, при котором говорить о блокировках бессмысленно (потому-то там и NOLOCK).
13 мар 14, 10:41    [15715468]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Автоматическое сжатие базы выключено?
13 мар 14, 11:36    [15715846]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 773
SomewhereSomehow
Сделайте слепок статистики ожиданий из sys.dm_os_wait_stats,


ТС, попробуйте выполнить следующий код -
SELECT TOP 10
[Wait type] = wait_type,
[Wait time (s)] = wait_time_ms / 1000,
[% waiting] = CONVERT(DECIMAL(12,2), wait_time_ms * 100.0 
               / SUM(wait_time_ms) OVER())
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%' 
ORDER BY wait_time_ms DESC;


и по самым верхним строкам те ожидания, что самые "процентные" - либо в Гугле поищите конкретно по ним, либо там же найдите вордовский документ "SQL Server 2005 WhitePaper Perfomance" (или по 2008 версии, не суть важно)

Отправная точка для меня лично, даже каунтеры обычно начиная после этого уже смотреть
13 мар 14, 11:53    [15716000]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
PsyMisha
Member

Откуда: другая столица
Сообщений: 773
Кстати - и еще насчет связки 1С-сиквел - часто очень проблемы происходят из-за распараллеливания запросов, что по-умолчанию выставлено в 5 секунд. Скрипт выше должен показать высокий процент по "Cxpacket"
в официальном документе Microsoft - "SQL Server 2005 Waits and Queues" это более подробно расписано
13 мар 14, 12:00    [15716087]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Ablok
Member

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

Да сжатие выключено.
13 мар 14, 14:07    [15717476]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Ablok
Member

Откуда:
Сообщений: 10
Смотрите чего интересного нарыл. Развернул базу старую, и при выполнение аналогичной операции в плане запроса можно найти вот такую информацию.
Плюс в отличие от текущей базы в этой запрос выполняется с параллелизмом, а в текущей я этого не видел, как будто он выполняется последовательно?
/*
Отсутствуют сведения об индексе из ExecutionPlan3.sqlplan
Обработчик запросов считает, что реализация следующего индекса может сократить стоимость запроса на 60.581%.
*/

/*
USE [UTCOPY4]
GO
CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [dbo].[_AccumRgT5034] ([_Period],[_Fld5029RRef])
INCLUDE ([_Fld5027RRef],[_Fld5028_TYPE],[_Fld5028_RTRef],[_Fld5028_RRRef],[_Fld5030RRef],[_Fld5031])
GO
*/

Может кто подскажет как заставить выполняться с параллелизмом?
14 мар 14, 00:58    [15721153]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Speshuric
Member

Откуда: г. Москва
Сообщений: 129
Ablok
Может кто подскажет как заставить выполняться с параллелизмом?

Вот уж чего в OLTP обычно не нужно делать, так это "заставлять выполняться с параллелизмом". Скорее наоборот - в OLTP большое количество запросов с параллельными планами говорит о кривой системе.

Мой совет: начните всё-таки с поиска того, что мешает произволительности: трассировкой, технологическим журналом 1С, счетчиками производительности найдите "самые блокирующие" запросы и "самые ресурсоёмкие" (по процу и диску). С блокировками убедитесь, что нет эскалаций, убедитесь, что нет избыточных блокировок, если версия 1С 8.3, то перейдите на уровень изоляции read committed snapshot, убедитесь, что вы учли управляемые блокировки (транзакционный механизм блокировки сервера 1С). С ресурсоёмкими запросами всё еще проще: нужно понять, является ли такой запрос тормозом производительности, и, если является, проанализировать план запроса на предмет того, как поменять запрос или какие добавить индексы. Вот вы же сами приводите пример: нужно создать индекс по таблице итогов регистра накопления _AccumRgT5034 по полям _Period и _Fld5029RRef с включенными полями _Fld5027RRef,_Fld5028_TYPE,_Fld5028_RTRef,_Fld5028_RRRef,_Fld5030RRef,_Fld5031. 1С не умеет создавать индексы с включенными полями, но скорее всего измерение, соответсующее полю _Fld5029RRef, не индексировано. Если его индексировать, то получится как раз очень похожий и подходящий индекс (он не будет включать поле _Fld5031, но тут уж ничего не поделать). Или может быть правильным будет поставить измерение, соответсующее полю _Fld5029RRef, первым в спсике, тогда этому условию станет удовлетворять кластеризованный индекс. Но тут, понятно, есть риск, что запросы, которые сейчас мгновенно выполняются станут долгими. И эти манипуляции имеют смысл только если запрос действительно влияет на производительность проведения/записи.
14 мар 14, 08:34    [15721629]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Ablok
Member

Откуда:
Сообщений: 10
Я просто тогда не могу понять. Почему один и тот же запрос в разных версиях базы, выполняется с разницей в семь минут.
В не переиндексированной базе секунд семь и судя по плану запроса, параллеля все что возможно. А в другой, которая переиндексированна, минут семь и ничего не параллелит? Т.е. получается что обработчик запросов считает, что так все хорошо должно выполнятся, что и параллелить нечего?
14 мар 14, 08:50    [15721664]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Ablok,

Параллелизм это функция от стоимости и возможности его применить. Есть вещи которые предотвращают его в принципе, типа скалярных функций или явного ограничения степени параллелизма и много чего еще. Если никаких ограничений, то в игру вступает стоимость. Есть такой параметр:
exec sp_configure 'cost threshold for parallelism'

По умолчанию, он равен 5, если стоимость вашего запроса (в условных единицах, не в процентах само собой) меньше значения в 'cost threshold for parallelism', то параллельный план даже не будет рассматриваться. Если стоимость выше, то будет сравниваться стоимость параллельного плана со стоимостью последовательного, выбирается то что дешевле.

Стоимость в свою очередь зависит также от многих факторов, например, стоимость сканирования зависит от числа занимаемых таблицей страниц. Уменьшили число страниц, уменьшили стоимость, возможно сервер решил, что теперь достаточно будет последовательного плана. Может зависеть и от числа доступных ядер, даже при полностью одинаковой БД на одной машине (допустим с 8 ядрами) может получиться последовательный план, а на другой (скажем в 16) параллельный.

Я вот другое не понимаю. Почему вы продолжаете стрелять наугад, почему не хотите посмотреть, что присходит. То вы грешили на блокировки, теперь нашли какое-то отличие в планах, какие-то отсутствующие индексы. И я так понимаю медленный план выполняется медленно всегда у вас, а то вы писали:
Ablok
При этом некоторые внутренние заказы проводятся быстро, а некоторые очень долго минут по 7.

Что я понял как то, что проблема воспроизводится не постоянно.
В общем, запутываете следствие =)

Угадывать проблему можно долго, и можно даже в итоге угадать, и выйти победителем. Но мне, например, в угадайку играть не интересно, так что выключаюсь. Удачи вам в поисках!
14 мар 14, 09:35    [15721849]     Ответить | Цитировать Сообщить модератору
 Re: Страшные блокировки, прошу помощи.  [new]
Speshuric
Member

Откуда: г. Москва
Сообщений: 129
Ablok
Я просто тогда не могу понять. Почему один и тот же запрос в разных версиях базы, выполняется с разницей в семь минут.
В не переиндексированной базе секунд семь и судя по плану запроса, параллеля все что возможно. А в другой, которая переиндексированна, минут семь и ничего не параллелит? Т.е. получается что обработчик запросов считает, что так все хорошо должно выполнятся, что и параллелить нечего?

Где запрос? Где структура таблиц? Где планы выполнения "медленный" и "быстрый"? Есть ли какая-то разница в окружении, кроме перестроения индексов? Сохраняется ли эта разница, если запустить alter index rebuild только по индексам, участвующим в данном запросе? Сохраняется ли разница после dbcc freeproccache?
14 мар 14, 10:37    [15722231]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить