подскажите какие могут возникнуть при этом сложности-трудности?

-
Чудеса случаются. Это Вам любой программист скажет.

AHDP,

сцук =(
выход какой-нибудь есть, кроме "проверить-перенести"?

AHDPНет. :( Если только скрипт писать.
да я о скрипте для агента и писал. можно, в принципе, написать скрипт, который будет проверять лежит ли таблица в другой группе и туда это будет запихивать ежели нет.

AHDPСколько дисков? А то может игра свечь не стоит? В любом случае, кратное приращение вряд ли получите.
дисков 8. темпы, логи разбросаны, а mdf - один и лежит на диске G.
судя по статистике, дисковая очередь: средняя - 58, в пиках до 200 пунктов. при том, что по остальным дискам очередь - 0 (ноль).
один диск свободен, потому хочу часть данных вынести на него.

AHDPДисковая очередь 50-200 - весьма значительна, при условии что только на файл данных.
только. это в часы активной работы (8:00-20:00) ночью меньше.

AHDPА что смежные счётчики говорят? Огласите что её создаёт.
какие?

AHDPА если в сторону памяти сервера посмотреть? При нонешнем всплеске цены на диски - может оказаться сильно конкурентно.
В вашем случае 10 под данные наверное получше будет.
памяти там уже не мало. если честно ) только под сервер выделено ~262ГБ + темпдб вынесли на рамдиск (~100ГБ)

AHDPТак что такую нагрузку создаёт? Складывается впечатление, что она на запись, но в это слабо верится.
много операций чтения/записи и пользователей (в пике уже видели 1800)

AHDPОпераций чтения, записи, % активности диска.
чтение (сегодня, день)
среднее - 329 оп/сек
максимум - 1106

запись
среднее - 518 оп/сек
максимум - 1745 оп/сек

AHDPЧто стало предпосылкой выноса темпдб в рам!? Ну ещё можно в рам её лог засунуть..., но mdf-то зачем?
мм... ну как зачем? дофига операций с темпдб - временные таблицы. раньше очередь была ещё на темпдб, разбивали на несколько файлов. недавно добавили память на сервер, появилась возможность откусить кусочек для темпа. разве это неправильно?

AHDPТак что такую нагрузку создаёт?
постоянно создаются документы + промежуточные данные (сканирование месторасположения, прохождения груза)

AHDPПри этом сравнимая нагрузка на LDF отсутствует!?
вот не знаю, не замерял как-то отдельно.

AHDPТемпДБ в основном использует МДФ когда ей не хватает оперативки. Хотя с тенденцией к мегазапросам и временным таблицам в восьмёрке её потребность в дисковых ИО могла подрасти.
ну оперативки определённо нехватает. 6-8 тыс. запросов в секунду к бд происходит. очень многие с использованием временных таблиц (1с)

BestProgrammist1) Добавьте две новые файловые группы например с именами Data, Index.
2) Data - установить группой но умолчанию
3) Перенести в дата все прикладные таблицы и кластерные индексы , в дальнейшем т.к это группа по умолчанию, то 1С все операции DML будет проводить в ней.
4) В группу Index перенести все некластерные индексы прикладных таблиц.
5) Периодически регламентом проверять пункт. 4.
6) Итого базовая структура Primary - Data - Index.

а зачем группа Primary? почему нельзя её оставить и создать только Index, перенеся туда индексы?

тут ещё интересное происходит, но это больше вопрос к 1С.

в 15:24 (почти каждый день в плюс/минус это время) сервер 1С сбрасывает самостоятельно кеш и отваливаются пользователи, которые в этот момент что-то пишут-читают.
вот хочется понять, что есть причина всплеска подключений к 1с?

AHDPОК, вы знаете как распределить данные для возможности паралельного доступа.
ок, будем дробить

AHDPЕсли нагрузки на LDF нет, надо внимательно посмотреть на Кластеные и обычные индексы. Может их можно упростить? Ведь без них нагрузка на лог и данные при записи сопоставима.
хз как смотреть. =( может и упростить, но игры с индексами приводили к таким тормозам, что просто перестали их трогать. что разработчики настроили, то и используем. ещё усложняется всё тем, что при обновлении конфигурации (а это происходит еженедельно) все добавленные/убранные индексы восстают из пепла ... или уходят туда. =(

AHDPНу количество запросов на потребность в оперативке влияет опосредовано... А вот если если памяти не хватае, то зачем её надо было забирать под рам диск?
потому что была дисковая очередь и очень много операци I/O с темпдб.

AHDPrphost'ы перезапускаются?
да

BestProgrammistнаутилус,

Это вопрос вкуса(архитектуры?), Primary - только эта группа хранит первичный файл(mdf), содержащий системные данные (таблицы, схемы, настройки...) для текущей базы, т.е все что важно SQL Server, а не приложению. Стандартная рекомендация, разделять системные и пользовательские данные. Собственно приведенная схема Primary-Data-Index-FileImage это базовый шаблон(один из) развертывания базы данных SQL Server в реальных условиях.
В случае 1С удобнее конечно сначала подготовить структуру БД, а затем развернуть в группу Data чистую конфу или выгрузку.
да, я почитал про Primary, понял про системные таблицы.
подготовить-создать вряд ли получится =( придётся делать это в технологические перерывы. хочу на этих выходных вынести (для начала) пока только одну таблицу в отдельную файловую группу. она самая "проблемная" на счёт записи и чтения.

AHDPНаутилус, а эта табличка случаем не лочится при работе с другими таблицами? Может посмотреть в сторону номенклатуры/контрагентов?

да в том и проблема, что лочится. эта таблица - "история сканирования штрихкодов". по ней определяется текущее местоположение груза и туда же пишется информация о новых событиях. можете себе представить блокировки её.
пишут и читают из неё. была идея выносить данные регламентом из неё в другую базу, оттуда читать состояние, но на сколько я общался с разработчиком этой подсистемы, бизнесспроцес на этой стадии настолько быстро происходит, что даже 3-5 секундная задержка - это много и непозволительно. (логистика, на терминале происходит компоновка, перераспределение, загрузка-выгрузка)
потому от идеи держать где-то зеркало пока отказались. точнее не придумали реализации.

AHDP,
так а что с перезагрузкой rphost? можно бороться?