Есть сервер HP DL 380 G6 (2 четырехядерных Xeon-а, 24 гига памяти).
Задача - сервер баз данных MS SQL 2008.
Базы УПП - 50 гигов
    УТ  - 15 гигов
    БП  - 4 гига
100-120 активных пользователя
Сервер 1С - отдельный HP DL 365 G5 (2 четырехядерных Xeon-а, 12 гиг памяти)  
Диски SAS 15000 rpm
  2 Raid1 - система (Server 2008 Standart x64)
  2 Raid1 - файлы бд
  2 Raid0 - TempDB
  2 Raid1 - файлы журналов транзакций
Модель восстановления Full
Реиндексация и прочее обслуживание выполняется

Вопрос. Есть ли возможность ускорить работу сервера баз данных?
Например: будет ли прирост производительности если я сделаю для файлов бд и журналов Raid10 на 4 дисках?

Заранее спасибо за дельные советы.

модель восстановления full у скульных баз?

(1) да

ну так убери - это на диски дофига нагрузки... или откан на определенное время, а не на точку бекапа часто юзаете? ;)

*откат

(1) А что не так ???
Вот вопрос .. А разностная копия  норм работать будет ?

(5) + Имею ввиду у simple

(5) должна. просто пишет на иск он дофига, если логи в full

(3) не юзали пока, тьфу, тьфу. Но если чо то будет возможность. С simple, соответственно, нет. Я не представляю как буду объяснять 100 юзверям, оставайтесь на ночь, сегодняшняя работа накрылась унитазом, вот и перестраховываюсь

(3) Модель восстановления практически не влияет на то, ЧТО пишется в журнал. Она, большей частью, определяет КАК ДОЛГО там будут оставаться записи.
http://www.cyberguru.ru/database/sqlserver/log-recovery-page4.html
Те операции, которые в моделях восстановления bulk-logged и simple записываются частично выполняются редко (ну за исключением, мб ALTER INDEX .. REBUILD), а уж 1С, вообще, наверное никогда не используются. Список здесь: http://msdn.microsoft.com/ru-ru/library/ms191244.aspx

(8) Гы мы похерили день ... диски полетели причем вечером ... нечего уже восстановилось... вот я теперь тоже подумываю одно из 3:
1) Simple и аждые 2 часа делать FULL BACKUP
2) Simple и делать полный Backup ночью и разностный каждые 30 минут
3) FULL   и полный backup ночью

очередь к дискам смотрел?
я бы вынес УПП - 50 гигов на отдельный диск
размеры ldf и mdf в каком соотношении?

(10) э, а что за разностный бэкап для симпла?

(0) Возможно стоит задуматься о новой дисковой подсистеме? Держать mdf и ldf на одном диске не кошерно..
(12) А в чем проблема?

(12) По идеи это изменения от полного бекапа до текущего момента времени(разностного бекапа) ... только вот я не пробовал пока что.

(13) просто не в курсе

(15) Пишут что делается Бекап и Усечение лога... так как СИМПЛ...
Тоесть при FULL ты можиш откатиться в любую секунду (Имея лог)! то при SIMPLE  и
полный backup + разностный1 + разностный2 + разностный3 + разностный4 ты сможиш откатиться только по контрольным точкам backup,разностный1,разностный2, разностный3, При этом без полного backup разностный не имеет смысла.!

Только я это ещё не испытывал... вот хочу узнать кто знает ?

(16) Имея не лог, а бэкап лога.. Просто с логом вы никуда не откатитесь.. Причем "откат" - это восстановление всей цепочки - начиная с первого full-бэкапа и заканчивая последним нужным trl-бэкапом. Если не будете делать бэкап журнала транзакций с моделью восстановления full - журнал не будет усекаться, следовательно, будет безостановочно расти.

(11) а вот некуда больше диски пихать.
Внешний дисковый массив пока отпадает, кризис

(18) если ldf маленькие, то их можно вместе с mdf на одном диске хранить, а под самую тормознутую базу лучше отдельный диск
---
просто сравни какая очередь к диску с mdf и какая очередь к диску с ldf

а несколько серверов 1С запустить не предлагали ?

(20) если про службы сервера 1с, тогда их запущено 8

а если привязку к процу и ядру сделать
на один "тормозную", на второй остальные ?

(22) сейчас вроде динамически распределеятся.
Подумываю над тем чтобы сделать 8 файлов mdf. Пока не решился. Много времени займет, вроде как

а ты померял очередь к дискам, кстати? может оно у тебя в сеть между серваками упирается...

да, что-то пока никакой инфы по загрузке процов / оперативки / очереди к жестким

(23) Вы зачем такое думаете??? Разбивать один mdf на несколько имеет смысл только для разгрузки дисковой подсистемы - т.е. одна файловая группа на один диск. И совершенно правильно Вас спрашивают про счетчики - не ясно что именно является узким местом..

(24) сеть между серваками гигабитная

(27) на некоторых серверных интеловских матерях есть возможность сделать 2 гигабита (типа параллельно 2 проводами по мегабиту - bond у соединений)

(28)+ в линухе - делал, в винде - тоже должно быть

(29) на заметку возьму, спасибо

(30) угу, особенно поможет при нагрузке сети в 1,5% ))))
---
партизан что ля, хде показатели нагрузки?

(31)ссаными тряпками не кидайте, как Вам посчитать?

(32) в скуле есть монитор активности и прочее
в системе есть Производительность

в диспетчере задач есть сетевая нагрузка

У компании софтпоинт были акции ПО perfexpert
1) в аренду
2) бестлатно, но не всем , а потенциальным клиентам.

как вариант, это самый быстрый способ выявить узкие места (1с сервер, сеть , sql serv ). Время-деньги

Я так понимаю нужны не моментные даныые счетчиков, а средние за период. Поставлю накапливать. Сам считаю узким местом систему ввода-вывода. Поэтому спросил:
будет ли прирост производительности если я сделаю для файлов бд и журналов Raid10 на 4 дисках?

то (36)
Не известно. тк  дисковая система + память для Вашей задачи вроде удовлетворительны.

Нужно вывлять "узкие" места системы.
Из неявных узких мест может быть не правильный collation sql server.
или дефрагментация файлов бд,сетевые каллизии.
но основное узкое место - не оптимальный код языка 1с из-за противоречия  функционального и системного подхода.

ММмммм
(всего 1 диск на сервере)
Создал "Полный БЕКАП" = 20 гиг = 12мин
СРАЗУ
Создал "Разностный БЕКАП" = 0 гиг = 0мин
Запустил ТИИ ... и делалось оно часа 2 (ушёл на обед мне перезапустили агент 1с)
Создал "Разностный БЕКАП" = 19 гиг = 11мин

в чём смысл?

+
Создал "Полный БЕКАП" = 20 гиг = 12мин
Поставил ГРАНИЦУ последовательности на 2008 ноябрь
Запустил восстановление партионного учета и провел 3 месяца
Создал "Разностный БЕКАП" = 10 мб = 1сек

Очередная серия: Бери сервера да ПОБОЛЬШЕ, ПОБОЛЬШЕ.
не узнав текущую загрузку, настроки конфигураций и тд

(37) дефрагментация файлов по расписанию
Вообщем быстрее если и будет то на 1-2%.

(40) 300-400 отчетов производства за смену
50 - 100 требований накладных
постоянное перепроведение документов резервирование товаров - 100 штук
50 новых заказов ежедневно по 100 - 500 строк
отгрузки соответственно
три передела в производстве
два направления производв
1200-1300 сотрудников

что еще сообщить?

(42) Конфу ЦУП видел хоть раз?

(42) Ты даже не знаешь где твои узкие места, а у же просишь советов как рейд выбрать

как всегда советую начать с анализа где именно затык http://www.infostart.ru/public/16681/

(43)"Конфу ЦУП видел хоть раз?"
Центр Управление Полетами.... вот как 1с уже и туда добралась?

(46) Юморист? ))

(43) ЦУП сам сильно систему грузит, что влияет на результат

***total***    180040317.0    100.0
LAZYWRITER_SLEEP    35869084.0    19.9
DISPATCHER_QUEUE_SEMAPHORE    18826118.0    10.5
SQLTRACE_BUFFER_FLUSH    17917188.0    10.0
XE_TIMER_EVENT    17970428.0    10.0
LOGMGR_QUEUE    17924556.0    10.0
REQUEST_FOR_DEADLOCK_SEARCH    17954160.0    10.0
CHECKPOINT_QUEUE    17519308.0    9.7
SLEEP_TASK    9132234.0    5.1
BROKER_TO_FLUSH    8976741.0    5.0
CXPACKET    8204163.0    4.6
XE_DISPATCHER_WAIT    5610133.0    3.1
LCK_M_IS    1670491.0    0.9
PAGEIOLATCH_SH    543435.0    0.3
SLEEP_BPOOL_FLUSH    410300.0    0.2
LCK_M_IX    288506.0    0.2
LATCH_EX    322721.0    0.2
PAGEIOLATCH_EX    111589.0    0.1
LCK_M_RS_S    110726.0    0.1
LCK_M_RS_U    171716.0    0.1
IO_COMPLETION    202899.0    0.1
ASYNC_NETWORK_IO    93348.0    0.1

Дело было не в бобине?

(49) ночью мерил, когда никого в базе не было? )))

(50) с 15 30 5 часов. Активная работа у нас до 22 00

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


SQLTRACE_BUFFER_FLUSH - средства отладки отключи

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

DISPATCHER_QUEUE_SEMAPHORE
Имеет место, когда поток из пула диспетчеров ожидает поступления дополнительной работы. Время ожидания данного типа ожидания увеличится, если диспетчер находится в состоянии простоя.

LOGMGR_QUEUE
Имеет место, когда задача записи в журнал ожидает рабочих запросов.
---------------------------------------------

(52) разве что REQUEST_FOR_DEADLOCK_SEARCH - мне не очень нравится, посмотри повнимательнее что у тебя по дедлокам, возможно это будет ключем

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