Вопросы Теги

Конкуренция TempDB на sysmultiobjrefs SQL 2005

Поддерживать окна памяти больше чем на 4 ГБ использует Расширение физического адреса (PAE). Это использует таблицы пейджинга для отображения памяти, больше, чем 4 ГБ. Путем выполнения этого размер физического адреса увеличен до 36 битов или 64 ГБ. PAE используется в 64-разрядном OS'es также; в этом случае максимальный размер удвоен до 128 ГБ.

Этот метод действительно означает, что каждый процесс все еще ограничен максимумом 4 ГБ памяти.

3
задан 30 July 2009 в 20:13
5 ответов

Вы проверили, чтобы удостовериться, что Вы только получаете мертвые блокировки от транзакций, ступающих на работу друг друга? Вы имеете проверенный, выполнять/блокировать SQL-запросы, когда блокировка происходит?

1
ответ дан 3 December 2019 в 05:10
  • 1
    Не абсолютно уверенный... it' s очищают слюну, которая блокируется, от команд, прибывающих из нашего приложения другим spid из нашего приложения..., но зависание spid всегда ожидает на ресурсе ожидания 2:1:103, который вернулся к sysmultirefobjects... I' m пытающийся уменьшить давление ведущего блокировщика, который кажется быть заблокированным некоторым SQL низкого уровня процесс ОС. –  Rob 30 July 2009 в 20:10

У Вас есть много операторов SELECT INTO в Вашем коде SQL? Это вызовет соединяющий нескольких tempdb системных объектов, пока оператор SELECT INTO не завершился.

2
ответ дан 3 December 2019 в 05:10
  • 1
    Существует Выбор intos в нашем приложении, но не очень многих. Заблокированные операторы (или делающий блокирование) были сохранены вызовы proc с выборами в них. –  Rob 30 July 2009 в 20:12
  • 2
    С T1118 включил Вам, должен получить точные команды в журналах, которые работают на каждой стороне мертвой блокировки. Что делают те команды? –  mrdenny 31 July 2009 в 03:26

Вы попытались включить флаг T1118 трассировки?

Статья KB от MS

Кавычка от статьи:

Обратите внимание, что флаг Trace-T1118 также доступен и поддерживается в Microsoft SQL Server 2005 и SQL Server 2008. Однако при выполнении SQL Server 2005 или SQL Server 2008 Вы не должны применять текущие исправления.

Увеличьте число tempdb файлов данных, чтобы быть, по крайней мере, равными количеству процессоров. Кроме того, создайте файлы с равной калибровкой. Для получения дополнительной информации посмотрите раздел "More Information". ¨

Раньше была проблема производительности с traceflag T1118 в SP2, но г-жа выпустила текущие исправления, и это должно быть зафиксировано в SP3, как в Вашем случае.

Я соглашаюсь с mrdenny о том, как временные таблицы составлены, Вы никогда не должны создавать поддающееся соблазну с ВЫБОРОМ * В #x ОТ TableA, если у Вас нет оператора Where как это:

ГДЕ 1=2

Но моя рекомендация состоит в том, чтобы использовать CREATE TABLE #x синтаксис. Почему? SQL поместит, много из привязывает системные таблицы, пока Ваш запрос пытается выбрать Ваши данные для вставки во временную таблицу. Если Вы будете использовать, куда пункт, настолько очевидный, не возвратит строк или создать синтаксиса таблицы, блокировки будут сохранены в течение короткого промежутка времени.

/Håkan Winther

1
ответ дан 3 December 2019 в 05:10
  • 1
    У нас было T1118, включенный, и мы все еще видели проблему. Использование временных таблиц не очень широко распространено для нашего приложения, но действительно существовать. Где созданного, тем не менее, it' s с создают оператор таблицы. –  Rob 30 July 2009 в 20:07

Ограбьте,

В нашей среде мы имели дело с его 2:1:103 проблема приблизительно в течение месяца. Один из способов предотвратить эту проблему состоял в том, чтобы периодически перезапускать Сервис SQL, если это - опция. Не было никакого четкого ответа на многих форумах для этой конкретной проблемы. Флаг T1118 не назвали эффективным при аргументах, выдвинутых Linci Shea (MVP) и несколько других в их блогах.

Один производственный сценарий, где я лично видел, что проблема произошла и ушла, был, когда SQL-сервер получил возможность увеличить память с 24 Гбит до 27 ГБ. На уровне 24 ГБ было приблизительно 40 процессов, державшихся 2:1:103, в то время как несвязанное задание задачи работало на сервере дб. Я уничтожил ту задачу, и SQL начал брать больше памяти от доступных 30 ГБ, конкуренция Tempdb постепенно исчезала на уровне 27 ГБ приблизительно за минуту или поэтому после того, как это получило 27 ГБ. Это - одна область, можно попытаться протестировать ее сами. Уменьшите места других сервисов на сервер БД и увеличьте максимальную доступную память для SQL.

Сообщите мне, находите ли Вы какое-либо другое решение для того же.

Singh.

2
ответ дан 3 December 2019 в 05:10

Я понимаю, что опаздываю на вечеринку, но на этой неделе моя команда проиграла со счетом 2: 1: 103. По сути, конфликт за этот ресурс указывает на конфликт с операциями DDL в базе данных tempdb и вызван созданием / уничтожением слишком большого количества временных таблиц или переменных временных таблиц. Я написал об этом в блоге http://www.mattwrock.com/post/2011/09/10/Latch-waits-on-21103-You-are-probably-creating-too-many-temp-tables- in-Sql-Server.aspx Разногласия здесь не будут устранены с помощью флага трассировки T1118 или добавления файлов в tempDb. Ключ состоит в том, чтобы либо уменьшить использование временных таблиц и переменных временных таблиц, либо оценить контекст их использования, чтобы увидеть, кэшируются ли они. См. http://technet.microsoft.com/en-us/library/cc966545.aspx для подробностей здесь.

2
ответ дан 3 December 2019 в 05:10

Теги

Похожие вопросы