Торможение базы

Тема в разделе "1C и всё что с ней связано", создана пользователем Aero, 6 мар 2008.

Статус темы:
Закрыта.
  1. Aero

    Aero Гость

    Привет.
    Имеется база (1.5 Гб, ДБФ, в день забивают около 1200 документов), находится на сервере (Ксеон 2-х процессорный по 4 ядра, 6 Гб ОЗУ,

    Рейд массив). База более менне работает при 5 пользователях, которые усердно забиват заявки, накладные и прочие документы. Когда

    начинают входить еще пользователи, то база начинает ТОРМОЗИТЬ, и некоторые пользователи начинают ВЫЛИТАТЬ с документов (при

    открытии, проведении и т.д.). В журнале регистраций пишется, пример:

    УстановитьНовыйНомер("А-"); : {Документ.СчетФактураВыданный.Форма.Модуль(449)}: Таблица: 1SJOURN Ошибка обращения к данным при

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

    притом все работаю со своими документами.
    НО НО НО, если в данной ИБ работают скажем 5 пользователей, и пару человек заходят в другие ИБ (не большие), начинаются такие же

    глюки.

    Пробовал переводить на SQL, знаю, что она не кретична к пользователям, НО раз в неделю делается восстановление последовательности,

    на SQL она делается в 2 раза дольше, и за выходные обработка может не успеть выполниться.

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

    при проведении (основные тормоза при проведении документа - расчет временных итогов) - использовать ТЗ или ДБФ файл для хранения

    итогово (увеличение производительности при массовом проведении в РАЗЫ)???
     
  2. kaa

    kaa Гость

    Может стоит всетаки обрезать базу до приемлемых размеров, семерка начинает гнать после 1Гб, кстати возможны глюки с итогами
     
  3. vitfil

    vitfil IT-интегратор

    Регистрация:
    2 апр 2004
    Сообщения:
    2.070
    Симпатии:
    0
    "В головах разруха..." (с) Булгаков.
    А для чего, позвольте вас спросить, у вас проводится расчет временных итогов? Работайте постоянно с актуальными итогами и все. Про специфику даже и слышать не желаю!
     
  4. Aero

    Aero Гость

    1) База обрезалась в конце сентября, итого 5 мес. назад, так что обрезка не катит
    2) Расчет временных итогов - типовой механизм, используемый при проведении документов:

    ВремРегистры = СоздатьОбъект("Регистры");
    ...
    Если ИтогиАктуальны() = 0 Тогда
    ВремРегистры.Актуальность(1);
    ВремРегистры.РассчитатьРегистрыНа(ТекущийДокумент());
    КонецЕсли;

    Стоит

    3) Есть предложение: все-таки переводить на SQL и оптимизировать восстановление последовательности
    Какие предложения есть по оптимизации восстановления последовательности и оптимизации вообщем
     
  5. jj_mail

    jj_mail Гость

    При похожих условиях перешли на SQL и избавились от проблем, связанных с dbf-ной базой, начиная с постоянных вылетов пользователей из базы и заканчивая бесконечными реиндексациями базы, восстановлениями последовательностей документов и т.д.
     
  6. vitfil

    vitfil IT-интегратор

    Регистрация:
    2 апр 2004
    Сообщения:
    2.070
    Симпатии:
    0
    "2) Расчет временных итогов - типовой механизм, используемый при проведении документов:"
    Я понимаю, что это типовой механизм. Вы уверены, что он вам нужен? действо сие есть наиглупейшая глупость.
     
  7. Superchumba

    Superchumba Гость

    to vitifill
    Можно поподробнее, в чем тут есть наиглупейшая глупость.Я так понимаю вы за то чтобы просто вырезать его из кода конфигурации?
     
  8. vitfil

    vitfil IT-интегратор

    Регистрация:
    2 апр 2004
    Сообщения:
    2.070
    Симпатии:
    0
    Постоянные расчеты не нужны. Все должно проводиться, работая с актуальными итогами.
     
Загрузка...
Статус темы:
Закрыта.

Поделиться этой страницей