strizhУ нас размер файла .mdf базы SQL2005 перевалил за 110 гиг.
Конфигурация - не типовая.
Сервер SQL - 8 ядер на 2.2 ГГц, 24 гига памяти, разные дисковые зеркала на систему, базы и лог.
Все нужные процедуры обслуживания SQL-базы делаются по расписанию.
Сервер приложений 1С - 8 ядер на 2.4 ГГц, 24 гига памяти, одно дисковое зеркало.

Железо у вас для такого количества пользователей и такого размера базы выше крыши в 4-5 раз. Вряд ли вы перед внедрением делали нагрузочное тестирование, поэтому для самописной конфы количество проблем может быть очень большим.
strizh
1. Перепроведение всех документов базы за период 1 неделя идет сутки. Соответственно, восстановление последовательности партионного учета, например - невозможно.

Возможно стоит использовать измерения последовательностей

strizh
2. Обмены с базами филиалов - размеры файлов XML получаются от 50 до 500 Мб (обмен с каждым филиалом - каждые 2 часа). Обмен читается в центральной базе от 1 до 10 минут, за это время юзеры, которые проводят документы, успевают получить кучу ошибок блокировки.

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

strizh
3. При необходимости выгрузки в .dt и загрузки из .dt операция длится более 12 часов.

Зачем вам это? Пользуйтесь бэкапом SQL

strizh
4. Операция проверки целостности базы длится более 4 суток.

Вы так часто делаете эту операцию, что время становится значимым? Откуда у вас возникают битые ссылки?

strizh
5. В центральной базе активно работают 30 человек. Даже когда нет обменов, проведение одного документа может длиться 1-2 минуты

Проблема в избыточных блокировках или что менее вероятно в неоптимальном алгоритме. Необходимо использовать управляемые блокировки.
strizh
Кто что посоветует для улучшения ситуации ?

В вашем городе есть франчи, в штате которых есть эксперты по технологическим вопросом, их список можно посмотреть на сайте 1С. Пригласите такого специалиста на 1-2 недели и получите список проблем с вариантами решения

strizh
у нас не самописная, у нас сильно доработанная типовая УПП

Вы в первом посте написали что конфигурация - не типовая. Соответвенно весь мой пост основывался на этом

strizh
Что значит - неоптимальная ? Какой должна быть целевая функция ? Какой алгоритм оптимизации
должен быть ?
Просто у нас сезон, и каждый филиал порождает в месяц примерно 400000 документов.

Какой вариант обмена вы используете (встроенные процедуры обмена или свои)? Мигрируют ли данные одного филиала в другой или только в центральную базу? Выгружаете ли вы в центральную базу все документы или только те которые делают финансовые движения (например нет смысла выгружать в центральную базу заказы покупателей)?

strizh
Мы и пользуемся, и идет он 20 минут. DT-шник нужен для лечения базы от битых ссылок, которые
пару раз массово рождались после краха сервера приложений 1С (первый раз по невыясненной
причине, второй раз из-за выхода из строя UPS-са в самый неподходящий момент). По пока
невыясненной причине в небольшом количестве битые ссылки появляются после загрузки особо
больших обменов (1.5 гига файл XML). А особо большие обмены рождаются после отсутствия в
особо отличившихся филиалах инета в течение недели.

какую версию платформы вы используете? За целостностью данных следит не сервер приложений, а sql сервер, поэтому непонятно как из-за сервера приложений образовались битые ссылки. Думаю причину нужно искать в механизме обмена, т.к. если используется не стандарная процедура обмена возможно не все данные записываются в одной транзакции, из-за этого битые ссылки.

strizh
Я уже писал выше: "Обмены идут на механизме БП, и мало где используется
авторегистрация документа к обмену (это уже было несколько попыток увеличить скорость
обменов - увеличили год назад втрое, но снова не хватает)."

Что значит механизм БП? Как я понимаю единственное изменение по сравнению со стандартной регистрацией - не выгружать изменения из центральной базы в филиалы, которые не создавали документ.
strizh
С этого места - подробнее. Как именно SQL-сервер следит за целостностью данных в БД 1С ?
Из средств контроля ссылочной целостности я видел только использование уникальных индексов
и использование типа полей UID. Но ни foreign key, ни триггеров, ни constaint - нет.

По понятным причинам приведенных вами механизмов 1С 8 не использует. Целостность данных обеспечивается на уровне транзакции. Например удаление документа влечет за собой удаление всех его движений

svcoder Думаю причину нужно искать в механизме обмена, т.к. если используется не
стандарная процедура обмена возможно не все данные записываются в одной транзакции, из-за
этого битые ссылки.
Скорее всего, Вы правы. У нас в планах переделать обмены и модули проведения самых больших
документов на управляемые блокировки. Тогда мы сможем контролировать, с какого места
начинать транзацию, где ее завершать или откатывать. Не смогли разобраться, как управлять из
1С режимом изоляции транзакций SQL-сервера. А возможно ли ? И нужно ли ?[/quot]
Управляемые блокировки никак не помогут вам контролировать транзакции. Режим изоляции транзакций разный для разных объектов, причем разный в автоматическом и управляемом режиме. Управлять этим нельзя

strizhsvcoderЧто значит механизм БП?
Значит, что программеры с помощью механизма 1С для описания бизнес-процессов нарисовали
БП обменов. Понятное дело, что внутри блоков БП процедуры очень похожие на стандартные
обмены УПП.

svcoderУправляемые блокировки никак не помогут вам контролировать транзакции. Режим
изоляции транзакций разный для разных объектов, причем разный в автоматическом и
управляемом режиме. Управлять этим нельзя
Тогда подробнее. Чем нам помогут управляемые блокировки ? И как нам контролировать
транзакции ?
Это достаточно объемная тема, все-таки вам стоит сначала почитать документацию, ИТС, форум разработчиков, а уже потом задать конкретный вопрос.