По сабжу - в инете много инфы.

В большинстве случаев (по 1с77) всё сводится к 2м вещам:
- оптимизация индексов и статистики
- управление блокировками

Но у всех этих методов есть существуенный недостаток:
- сложно поддерживать для случая когда выполнена реорганизация (реструктуризауия) БД средставми 1с-ки...

Предлагаю посмотреть собственно на средства сервера SQL
и оптимизировать скорость только там, не вмешиваясь в технологии от 1С.

Имеем 8шт 1С77 баз + 3 штуки 1С8, одна из которых УПП
Все разного размера и интенсивности.

Как угодить всем?
Вот к чему я пришел:

железо (минимум, для моего объема)
* 2xCPU, 48Gb RAM, RAID-10 SAS 8x300Gb
* сеть: 1Гбит
* сервер = виртуализация (proxmox), на котором
 - MS Терминал (4-8 ядер, RAM из расчета 128-512Мб на юзверя)
 - MS SQL 2008r2 (16 ядер, 24Гб RAM)
 - остальные VM: в этом топике - не важно

По настройкам SQL:
1) для винды читаем здесь: www.sql.ru/blogs/gladchenko/332
2) настройки сиквеля (у меня такие - методом проб и экспериментов, для этого железа):
         backup compression default      1
         default trace enabled      0
         lightweight pooling      0
         priority boost      1
         max worker threads      8192
         network packet size (B)      8192
         max degree of parallelism      64 (заставляем принудительно SQL использовать все ядра, что имеются)
         cost threshold for parallelism      1 (если запрос долше 1сек - параллелим его)
         locks      50000 (не будем считать проблемой количество блокировок вплоть до этого значения)
         max server memory (MB)      22528 (22 = 24Гб - 2Гб под ОС)
         min memory per query (KB)      1024
         min server memory (MB)      0
         query wait (s)      2147483647 (ждем пока любой пришедший запрос не будет отработан - до конца)
         recovery interval (min)      60 (уменьшаем количество чекпоинтов = 1 раз/час)
         remote query timeout (s)      600
3) выносим tempdb - на RAM-диск (я пользуюсь imDisk-ом, не подводил, GPL)
4) все базы
   * simple
   * autocreate stat / autoupdate stat = off
   * асинхронное обновление статистики = да (на всякий случай)
   * page verify = torn page detection (надежность вряд ли пострадает, скорость выше)
   * если более 1 (физического) массива дисков - разностим MDF/LDF (иначе не обращаем внимания)
   * путь к файлам MDF/LDF - должен быть без длинных путей
      (т.е. переностим все MDF/LDF файлы в корень диска/ков)
   * еже-ночные: (а) _1sp_dbreindex (б) full backup

В СЛУЧАЕ МОНОПОЛЬНОГО ПЕРЕПОВЕДЕНИЯ БАЗЫ 1С77:
делаем финт ушами:
- средставим тогоже imDisk создаем RAM диск размером 20Гб
- переносим туда БД (backup/restore в новое место)
- выставляем: autocreate stat / autoupdate stat = ON
- запускаем _1sp_DbReindex + sp_updatestats
- проводим базу
- выставляем: autocreate stat / autoupdate stat = OFF
- опять backup и restore на диск, на старое место...

Все остальные извращения (индексы и прочее)
- именно в случае вмешательсва в стандартные структуры и процедуры от 1С-ки
- дают выигрыш в производительности максимум 10-15%
- при этом затрат на обслуживание (времени) уходит просто тьма.

А с учетом того что память и диски сегодня стоят ....
Проше наростить мощь сервера и выносить (когда нужно) базу в память...

Я пошел экстенсивным путем.

Топик: к обсуждению  
 

память 1-2 гб надо под ос оставить а иначе sql все возьмет
а потом операционная система будет под себя отбирать память через swap

Ну у меня таких возможностей к сожалению нет.
Я пошел путем оптимизации запросов.
А насчет отказоустойчивости
основные базы использую FULL причем утром полный бекап, а в течении рабочего дня раз в 10 мин журнала транзакций.
Это пользователям не мешает так как дневные проходят максиму 10-15 сек.
Зато есть возможность подняться при падении базы на 10мин до падения.