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

1. Памяти у вас очень мало. Для SQL с такой базой надо минимум 64 Гб для приемлемой производительности. Особенно если у вас еще планы обмена летают.
2. Для ускорения проведения надо процессор на стороне сервера приложений с максимальной производительностью ЯДРА, потому что проведение - линейный алгоритм и распараллелить его не получится.

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

Про все остальное скажу так.
1. Дисковая подсистема, скорей всего, не справляется. Очереди смотрели? Что за зеркала сейчас на данные и логи?
2. Еще раз - памяти для такой базы мало.
3. 12 часов для загрузки из .dt - либо производительность ядра на сервере 1С фиговая, либо дисковая подсистема на сервере СУБД хромает, либо и то и другое вместе взятое.

На текущем железе может помочь DB2 (хотя не факт). Если что - могу подсказать как настроить. Но лучше все-таки посмотреть на загрузку железа вначале.

Db2 express С- про производительность не факт :-(
База вливается дольше... на порядок чем MS SQL.

При 64 гигах озу в ней будет вообще вся база, но блокировки на "необдуманных проетках убьют базу"

svcoderVolochkovaПрограммист 1сОбрезать. Там где нужны отчеты - обращаться к копии.

А случайно файлы не прикрепляете к базе?

А что за база то? Что в ней?

Достаточно ввести сегментирование и резать ничего не надо..
Вот бы еще 8,1 научить не каждый месяц хранить промежуточные итоги была бы вообще песня..
Проводите все документы оперативно (как в западных учетных системах) и вам будет накласть на существование итогов за прошлые периоды

Ага.. и запросы за прошлые периоды НЕ СМЕТЬ запускать! Жить текущим месяцем и все! и баста!!!

vitkhvVolochkova

svcoder
Проводите все документы оперативно (как в западных учетных системах) и вам будет накласть на существование итогов за прошлые периоды

Ага.. и запросы за прошлые периоды НЕ СМЕТЬ запускать! Жить текущим месяцем и все! и баста!!!



Проведение документов задним числом не равно запуску запросов за "прошлые периоды".

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

Угу.. годами перепроводится... конечно...
а вот отчеты ждущие годами - это каждый день и по 50 пользаков :-)
и все в дауне :-)

AHDPVolochkova,

Ну так и разбирайтесь с этими отчётами/пользователями. Добавьте в свою базу хранилище сформированных отчётов за прошлые периоды и выдавайте их пользователям. Только формирование отчётов с обсуждаемыми проблеммам не связано.

Вы сейчас об чем?

vitkhvVolochkova
Угу.. годами перепроводится... конечно...
а вот отчеты ждущие годами - это каждый день и по 50 пользаков :-)
и все в дауне :-)

Не понятна ваша логика, причем здесь отчеты которые делаются годами и проведение документов в прошедшем периоде?
А Ваше тем более.. Секционирование помогает не только для перепроведения задним числом.. ( а именно это увидели как корень зла в 1с и проблему ее производительности)

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

vitkhvVolochkova,
Вы пытаетесь меня убедить, что секционирование увеличить производительность при работе с БД?
Если так, то право, не стоит я и без вас в этом убежден. Хотя пересмотр апаратной архитектуры хранения данных, имеется в виду организация RAID, может принести большую пользу.

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

Касаемо отчетов - каким они здесь боком? Автор вроде не жалуется на скорость их выполнения, у автора есть 2 конкретных проблемы:

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

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

Вы потрудитесь сделать тоже самое.
Перепроведение задним числом - это как правило текущий год. Как этого не делать во вчерашних или в фактурах прошлого месяца я хз.
Так вот.
Секция - выделение текущего года всех регистров в отдельный файл дает ощутимый прирост именно в перепроведении. А выделение на отдельный райд табличек отвечающих за изменения объектов тоже хорошо прибавляет в скорости. А про тормоза - отчеты. Вот к чему. Если у ТС никто не будет запускать отчеты, то автообмен и перепроведение вздохнет спокойнее. По сколько 1с хранит промежуточные итоги, то волшебно было бы заставить ее хранить эти итого раз в год. Это была бы фантастика. А так партицию на регистры натравили / справочники на отдельный винтик вынесли и поскакали. MS SQL становится гораздо легче справляться с запросами 1с.

Самое обидное - если косяк в архитектуре. И для перепроведения или даже просто проведения нужно в регистры втыкать столько данных, что просто индексы MS SQL пухнут. Например на 100 метров данных - 200 метров индексов. Это уже вопрос к архитектуре. Это править только методами 1с.