1С 7.7 Бух на SQL начало сильно тормозить
1С:Бухгалтерия 7.7
Платформа 1С v7.7
Бухгалтерский учет 7.7
MS SQL
1С
Бухгалтерский учет
Программист
Системный администратор
Конфигурация (md, cf)
База знаний
Журнал
Добрый всем день !
Прошу откликнутся тем кто может помочь. Ситуация токова:
(1) 1С 7.7 Бух на SQLServer 2008 R2. В базе хранится информация за последние 7 лет. Особенно после нового года когда сделал перерасчет бух. итогов (сразу же позвонили операторы которые выписывают накладные и пожаловались что) база начало сильно тормозить. Документы по отгруске открываются (ранее созданный) примерно за 10 сек. а проведение данного документа, за 25 сек. Работоспособность колектива сильно снизалось.
(2) Поднял Бэкап с 25.12.2021 - то же самое
(3) Выгрузка-загрузка не помогла
(4) C машиной, админ говорит что все в порядке + эту же БД поставили на другом сервере (правдо чуть по слабее) ничего не изменилось (то есть этим мы исключили продлемы с машиной), нааборот время проведения данного документа увеличелось до 32 сек.
(5) Сделал архивирование журнала регистрации (был достаточно большим) то есть файл 1cv7.mlg сейчас маленького размера - эфект нулевой.
(6) Иногда, бухгатрера говорят что не тормозит но в остольное время все жалуютсяю Операторы говорят что особенно ночью невозможно работать (проводить документы).
(7) Заметил что если 1С Предприятие открыто и меняю хоть на 1 Кб минимальный объем памяти для запроса в SQL (смотрите прикрепленный файл), тормежение исчезает до закрытие 1С пользователем.
(8) Посмотрел таблици в БД SQL, есть 2 достаточно обьемные ниже-следующие таблици:
1SACCSEL - 7,5 Гб (cодержит вхождения проводок в отборы по бухгалтерским счетам) и
1SENTRY - 8.5 Гб (cодержит бухгалтерские проводки)
(9) На сколько я понемаю проблема в числе бух. проводок
Вопрос: есть какой-то способ решить данную проблему без свертки БД ?
Прошу откликнутся тем кто может помочь. Ситуация токова:
(1) 1С 7.7 Бух на SQLServer 2008 R2. В базе хранится информация за последние 7 лет. Особенно после нового года когда сделал перерасчет бух. итогов (сразу же позвонили операторы которые выписывают накладные и пожаловались что) база начало сильно тормозить. Документы по отгруске открываются (ранее созданный) примерно за 10 сек. а проведение данного документа, за 25 сек. Работоспособность колектива сильно снизалось.
(2) Поднял Бэкап с 25.12.2021 - то же самое
(3) Выгрузка-загрузка не помогла
(4) C машиной, админ говорит что все в порядке + эту же БД поставили на другом сервере (правдо чуть по слабее) ничего не изменилось (то есть этим мы исключили продлемы с машиной), нааборот время проведения данного документа увеличелось до 32 сек.
(5) Сделал архивирование журнала регистрации (был достаточно большим) то есть файл 1cv7.mlg сейчас маленького размера - эфект нулевой.
(6) Иногда, бухгатрера говорят что не тормозит но в остольное время все жалуютсяю Операторы говорят что особенно ночью невозможно работать (проводить документы).
(7) Заметил что если 1С Предприятие открыто и меняю хоть на 1 Кб минимальный объем памяти для запроса в SQL (смотрите прикрепленный файл), тормежение исчезает до закрытие 1С пользователем.
(8) Посмотрел таблици в БД SQL, есть 2 достаточно обьемные ниже-следующие таблици:
1SACCSEL - 7,5 Гб (cодержит вхождения проводок в отборы по бухгалтерским счетам) и
1SENTRY - 8.5 Гб (cодержит бухгалтерские проводки)
(9) На сколько я понемаю проблема в числе бух. проводок
Вопрос: есть какой-то способ решить данную проблему без свертки БД ?
Прикрепленные файлы:
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) что именно не ясно ? Прибейте руками таблички итогов, их там 2 штуки через truncate table , далее монопольно выполните операции - полный пересчет бух итогов.
У нужного(или всех) пользователя в папке каталога пользователя найдите файл *.cfg и удалите его. Или, вычистите лишний мусор обработкой Маляева, взятой с этого сайта.
У нужного(или всех) пользователя в папке каталога пользователя найдите файл *.cfg и удалите его. Или, вычистите лишний мусор обработкой Маляева, взятой с этого сайта.
Главный вопрос:
почему обязательное условие - без свертки БД ? Поймите правильно, есть определенный объем информации, который движком 7.7 обрабатывается с приемлемой скоростью. Затем, всё остальное приращение будет тормозить работу с данными.
Можно пытаться переиндексировать данные, загрузкой-выгрузкой избавиться от битых записей и т.д., но это поможет ненадолго. Очередное приращение данных сведет всю эту работу к 0. Нужно создавать долгосрочный запас по производительности, а тут нужно грамотно выполнить свертку данных
почему обязательное условие - без свертки БД ? Поймите правильно, есть определенный объем информации, который движком 7.7 обрабатывается с приемлемой скоростью. Затем, всё остальное приращение будет тормозить работу с данными.
Можно пытаться переиндексировать данные, загрузкой-выгрузкой избавиться от битых записей и т.д., но это поможет ненадолго. Очередное приращение данных сведет всю эту работу к 0. Нужно создавать долгосрочный запас по производительности, а тут нужно грамотно выполнить свертку данных
(9) т.е. Вы считаете, что изначально БД 7.7 спроектирована правильно ? Не буду агитировать за Советскую власть.)))
И , если считаете, что запрос к 100 миллионам записей выполняется за одинаковое время чем запрос к 1 миллиону записей, то желаю и дальше верить в волшебную силу связки 1С 7.7+SQL
И , если считаете, что запрос к 100 миллионам записей выполняется за одинаковое время чем запрос к 1 миллиону записей, то желаю и дальше верить в волшебную силу связки 1С 7.7+SQL
Стояли Вы или нет, про то - история умалчивает. Я же не Вашей лептой интересуюсь..
Еще раз поясняю свою точку зрения : 1С 7.7 имеет ряд эксплуатационных ограничений, которые попробовали исправить в проекте 1С++. Сама корпорация 1С не стала вкладываться в доработку устаревшей платформы , а вложилась в разработку 8-й версии. Хотя я знаю несколько очень крупных торговых сетей, которые работают на 1С++ и ныне.
А вот широкого примера применения Снеговика увидеть - не пришлось. После выхода 8.3. и стабилизации работы тонкого клиента переход на продукт 1С стал массовым.
По времени запроса есть классическая расчетная формула - это log2(n), соответственно с 10000 записями будет работать в 1,5 раза быстрее чем с миллионом (при прочих равных)
Еще раз поясняю свою точку зрения : 1С 7.7 имеет ряд эксплуатационных ограничений, которые попробовали исправить в проекте 1С++. Сама корпорация 1С не стала вкладываться в доработку устаревшей платформы , а вложилась в разработку 8-й версии. Хотя я знаю несколько очень крупных торговых сетей, которые работают на 1С++ и ныне.
А вот широкого примера применения Снеговика увидеть - не пришлось. После выхода 8.3. и стабилизации работы тонкого клиента переход на продукт 1С стал массовым.
По времени запроса есть классическая расчетная формула - это log2(n), соответственно с 10000 записями будет работать в 1,5 раза быстрее чем с миллионом (при прочих равных)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот