Переход на SQL - вариант?
 

День добрый!
Есть терминальный сервер win2008r2 с базой УТ 9.2 файловой. В базе существенно добавилось пользователей и регулярно висит "ожидание транзакции ...". Как вариант решения проблемы предложили переход на SQL (SQL 2008). Поскольку без замены файлов (чем очень не хочется заниматься) оно не взлетит есть вариант поставить SQL 2005 на соседний сервак с win2003. Какой вариант предпочтительнее?

В описываемой ситуации [терминальный и SQL на одной машине VS терминальный и SQL на разных машинах] на порядок более существенно чем [SQL2008 VS SQL2005]

[quote=roma n;46706509] В описываемой ситуации [терминальный и SQL на одной машине VS терминальный и SQL на разных машинах] на порядок более существенно чем [SQL2008 VS SQL2005] [/quote]

Ну тут уже вопрос конфигурации сервера, хотя конечно смешивать не стоит. Это понятно! Вопрос не раскрыт - Будет ли работать связка 2 компов - терминального w2008r2 и например w2003 с sql200 на 1000 линке.

[quote=Minipuh63;46706846]Ну тут уже вопрос конфигурации сервера, хотя конечно смешивать не стоит. Это понятно! Вопрос не раскрыт - Будет ли работать связка 2 компов - терминального w2008r2 и например w2003 с sql200 на 1000 линке. [/quote]
А чего бы ей не работать.

Диски какие? памяти скока? мала данных...
В моей практике 100% таких вопросов решалось переносом базы, временных файлов на ССД и добавлением памяти на сервер.
Кеш на сервере посмотрите и размер сюда выложите.
Куш должен быть больше, чем размер базы - как минимум.
Тогда и разговор о транзакциях отпадает.
Скуль нужен только при больших размерах файлов. Больше в 7-ке он ни от чего не спасает :(

(0) минимизируйте проведение документов задним числом. заднее число - это даже всего один документ перед последним. Основную нагрузку дает временный расчет итогов. а я готов на шоколадку что манагеры у вас правят заявки задним числом - этого делать не надо (есть другие варианты).
уберите всякие развешанные там и сям масовые расчеты всяких цен-количество и прочего в списках форм. Отчегото из списков начинают делать отчеты - так тоже не надо (есть другие варианты). Закройте незакрытые регистры партий, взаиморасчетов, комиссионеров. И прочие обычнеы действия по нормализации обычной работы в базе.
Отказ от проведений задним числом снимет текущие проблемы на 90%.

Как перейти с паленого мс скуля на постгри с минимумом накладных расходов.

Правильно говорит Че - как железо ни накачивай, сколько в него денег не вбухивай - при увеличении количества пользователей (или документов) рано или поздно придется заняться трассировкой и оптимизацией узких мест.

То что написал Че-это хорошо и правильно, это азбука, но не всегда просто реализуемо в одной отдельно взятой конторе. Можно всю жизнь положить на борьбу с вредителями правильного учета.

Ога, ога...
Еще в 99 году внедряли 1с 7.5 на одном заводе, где до этого работали на СМ-4. Закупили супер пупер оборудование, все летало по тем временам.
И вдруг почти каждый день система стала виснуть не по детски...
Оказалось, что к 1С подключили контролера из службы безопасности, и он пытался каждый раз сделать карточки счета за год!!! Так как там за год было почти миллион операций, он ни фига в этих карточках не видел, и долбился снова и снова. О том, что есть сортировки и отборы внушить ему так и не удалось.
Волевым решением администрации безопасник был отключен от базы :)

8-USSR > смотря кто это реализует. там где я работал - там я это реализовывал. и всегда успешно. если конечно не быть простым hовнокодером. и не поддаваться на нытье всяких псевдоменеджеров и псевдопродаванов типа ну мы никак не можем только так как раньше было. держать себя жестче (если считаешь себя специалистом) - и все будет ок. в той же ТиС 9.2 (которую обозвали УТ 9.2) - не так уж много узких мест, влияющих на ОПЕРАТИВНУЮ работу. и многие из этих узких мест до определенного уровня можно "оптимизировать" штатными или минимальнвми доработками.