Есть потребность ускорить формирования запросов к бухгалтерскому регистру. Можно ли заставить ms sql сервер кешировать по нему данные в большем объеме нежели это делается стандартно?

В такой постановке - нет.
Что надо то?

текст запроса покажи

Есть очень большая таблица регистра бухгалтерии. К ней даже элементарные запросы выполняются довольно долго.
(2) как пример самый простой запрос вида (но тут дело не в запросе)
ВЫБРАТЬ
   Таблица.КорСчет.Ссылка КАК КорСчет,
   Таблица.КорСчет.Порядок КАК КорСчетПорядок,
   Таблица.КорСчет.Представление КАК КорСчетПредставление,
   Таблица.СуммаОборотДт КАК СуммаОборотДт,
   Таблица.СуммаОборотКт КАК СуммаОборотКт
ИЗ
   РегистрБухгалтерии.Хозрасчетный.Обороты(&ДатаНач, &ДатаКон, , Счет = &Счет, , Организация = &Организация, , ) КАК Таблица

УПОРЯДОЧИТЬ ПО
   КорСчетПорядок
ИТОГИ
   СУММА(СуммаОборотДт),
   СУММА(СуммаОборотКт)
ПО
   ОБЩИЕ,
   Таблица.Счет ИЕРАРХИЯ КАК Счет,
   КорСчет ИЕРАРХИЯ КАК КорСчет

Выполняется за 3 месяца по счету "товары на складе" выполняется около 20 секунд первый раз в консоле

(0) режим блокировок какой в конфигурации?

автоматический

(3) Данный запрос должен выполняться по таблице итогов, а не по основной таблице. С итогами все в порядке?

(5) переход на управляемые блокировки вам поможет однозначно

(7) С какого?

(8) С какого числа или что? кэш сиквела абсолютно не причем, дело в избыточных блокировках при запросах к регистру бухгалтерии

(7) При чем здесь блокировки? Запрос в консоли (отчетах) вообще без (несмотря на) блокировок читает

(8) С какого хрена "поможет однозначно"

select * from ...

а во 2 раз за сколько выполняется?

(9) Тут нет проведения документов, такие запросы выполняются с хинтом NOLOCK

(7) Я и не сомневаюсь что поможет в целом для параллельности работы. Но на запрос в (3) никак не повлияет. Да и это очень большой кусок работы

(14) да-да, я невнимательно прочитал (3)

(6) Вот я итоги и хотел кешировать.

(17) секционирование таблиц вам поможет

(18) Смотрели в эту сторону. Пока некоторые таблицы разнесли по файловым группам, со временем планируем и секционирование сделать

(17) Что, итоги тоже очень большие?
Я и спросил, все ли с ними в порядке. Может там нулевых записей много. Может, не посчитаны за какой-то период.

(18)
а при реструктуризации (пересоздании)
каждый раз секции заново создавать ?

(19)
тоже с фг

(18) Причем тут партионирование? Это все для записи помогает.
А автор хочет скорости ОЛАП для регистров бухии.

(22) Если вы ответите на вопрос почему секционирование уменьшает скорость записи, то вы тут же ответите на вопрос почему скорость чтения увеличивается

+(23)*увеличивает скорость записи

это все здорово, а план запроса автор смотрел

(23) Что-то я сумневанюсь. Вот из ОЛАП легко читать, но пишут туда данные очень долго и мучительно :)
Почему секционирование облегчает запись понятно. В 2 мешка что-то сложить что-то проще, чем плотно упаковать в один. Но ведь достать что из одного, что из 2х примерно одинаково :)

(26) Не просто достать, а найти.

(26) найти в одной (из  2х) кучек которая в 2 раза меньше чем большая кучка обычно гораздо быстрее ))

ладно с этим вопросом понятно, что особо повлиять на кеширование таблиц я не могу.
Тогда другой вопрос, коль уж тут собрался народ. Какими способами можно уменьшить время наложения блокировок. Так как запросы вне транзакций выполняются в 3-4 раза быстрее чем в транзакциях даже если я в базе сам?

(29) что значит сам? Один? Выполнять запросы вне транзакций, если конечно логика системы позволяет

(29) Да одни. Этим хотел подчеркнуть что, это не блокировки с другими пользователями. Эти запросы в обработке проведения.

(0)
А вы уверены, что кеширование вам поможет? Надо обосновать, а именно в момент выполнения запроса очередь к диску на чтение зашкаливает? Раньше до 2000 была команда PINTABLE как раз для этого, но она не так сильно эффективно, как кажется на первый взгляд.

(32) не особо большая очередь. в самых пиках до 60 бывает.

(0) Зачем секционирование, зачем кэш, зачем из пушки по воробьям?

Автор к тебе вопрос: Выполняются ли регламентные операции sql?
Если да, то план запроса в студию, без него дальнейшее обсуждение не имеет смысла.

все регламентные операции скл выполняются. В плане запроса много ветвлений и 90-99% операция index seek

(35) Возможно проблема связана с большим количеством нулевых строк в регистре.
Для проверки прочитай статью на инфостат
"Зачем в 1С нужно периодически пересчитывать итоги по регистрам?", там же приведено решение этой проблемы.

Если не поможет, тогда выкладывай план запроса, а не свои выводы.

Забыл ссылку на статью
http://infostart.ru/public/177171/