Временные SQL таблички в ax2009

[fed]

Цитата:

Сообщение от Raven Melancholic

А есть какое-либо техническое объяснение такому поведению? На первый взгляд, не совсем понятное поведение.

В LedgerBalancesTransDelta есть нормальный кластерный индекс, в котором в самом начале стоит SessionId. Соответственно, если этот индекс используется, то конфликтов между сессиями не возникает, поскольку все поиски идут с указанием сессии, и, соответственно, SQL Server вешает блокировки на разные ключи и страницы. (Вероятно может все-таки блокировка случаться, если несколько разных сессий в одну страницу попало, но это не очень часто случается). Проблема в том, что авторы фичи добавили еще и индекс по RecId (который реально использоваться не должен). Почему добавили - не знаю. Может машинально, может долбоархитекторы заставили. Проблема в том, что табличка эта - часто обновляется и основной кластерный индекс становится очень фрагментированым. В этой ситуации, SQL Server время от времени решает что надо использовать индекс по RecIc, но только для того, чтобы отобрать записи по условию dataaareaid. В итоге - вешаются блокировки на заметную часть этого самого индекса, поскольку записи с одинаковым SessionId могут там попасть в совсем разные страницы.
А когда мы индекс по RecId удаляем, системе не остается ничего другого кроме как использовать единственный кластерный индекс. А при этом блокировки случаются эдак на 2-3 порядка реже чем при использовании индекса по RecId.
Ну то есть - решение Романа, вероятно, еще более универсально, поскольку вероятность блокировок доводит до нуля, но отрубить индекс по RecId не долго, а результат дает почти такой же, как и использование временной таблицы....

[Raven Melancholic]

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

[fed]

Цитата:

Сообщение от Raven Melancholic

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

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

[Raven Melancholic]

Цитата:

Сообщение от fed

Сформулируем это так: неудачный индекс не только увеличивает время обновления, но и вызывает повышенный риск блокировок.

Конечно, воскресенье не показатель, но сейчас у меня в базе в таблице LedgerBalancesTransDelta всего меньше десятка записей. На мой взгляд, это для SQL настолько ничто, то нет разницы что там оптимизируется.
С другой стороны, размер места для таблицы несколько десятков мегабайт, то есть еженочная оптимизация и перестройка индексов не затронула кластерный индекс этой таблицы (при его перестройке место освобождается). Стоит задуматься над тем, что там у нас ночью происходит или над тем, что в течение дня было, что так увеличился размер, если ночью он был высвобожден. Не исключено, что именно перевод в TempDB поможет.