1С 7.7 Бух на SQL начало сильно тормозить

1. Bumerang17 29.01.22 18:23 Сейчас в теме
Добрый всем день !

Прошу откликнутся тем кто может помочь. Ситуация токова:

(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) На сколько я понемаю проблема в числе бух. проводок
Вопрос: есть какой-то способ решить данную проблему без свертки БД ?
Прикрепленные файлы:
По теме из базы знаний
Ответы
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
2. user1203706 12 29.01.22 18:59 Сейчас в теме
(1) прибить таблички итогов через truncate table и сделать еще раз полный пересчет бух итогов.
У ноющих пользователей прибить файл cfg в папке пользователя.
3. Bumerang17 29.01.22 19:09 Сейчас в теме
(2) user1203706, Извените, не совсем поням вашу мысль. Можете по подробнее ?
4. user1203706 12 29.01.22 19:13 Сейчас в теме
(3) что именно не ясно ? Прибейте руками таблички итогов, их там 2 штуки через truncate table , далее монопольно выполните операции - полный пересчет бух итогов.

У нужного(или всех) пользователя в папке каталога пользователя найдите файл *.cfg и удалите его. Или, вычистите лишний мусор обработкой Маляева, взятой с этого сайта.
5. Bumerang17 29.01.22 19:21 Сейчас в теме
(4) user1203706б никогда это не делал и с обслуживанием SQL мало работал, по этому и уточняю ...

После процедуры с truncate table, проводки не пострадают/исчезнут ?
6. user1203706 12 29.01.22 19:24 Сейчас в теме
(5) ёёёё.... с таким уровнем вопросов, вам лучше ничего не делать.
Я уже молчу про настройки и обслуживание самого сиквела.
Куда делся предыдущий прог, кто бухню в скуль закинул ?
7. Bumerang17 29.01.22 19:54 Сейчас в теме
(6) да Вы правы.
Есть админ но мало работал с SQL (он и поставил 1С на SQL). Я только в 7ку пишу и то не каждый день.
Спасибо что направление обозначели .... прочтем
8. uk09 01.02.22 18:11 Сейчас в теме
Главный вопрос:
почему обязательное условие - без свертки БД ? Поймите правильно, есть определенный объем информации, который движком 7.7 обрабатывается с приемлемой скоростью. Затем, всё остальное приращение будет тормозить работу с данными.
Можно пытаться переиндексировать данные, загрузкой-выгрузкой избавиться от битых записей и т.д., но это поможет ненадолго. Очередное приращение данных сведет всю эту работу к 0. Нужно создавать долгосрочный запас по производительности, а тут нужно грамотно выполнить свертку данных
9. user1203706 12 01.02.22 18:42 Сейчас в теме
(8) свёртка к производительности никакого отношения не имеет в правильно спроектированной бд, где нет не закрытых регистров/итогов по счетам.
10. uk09 01.02.22 18:48 Сейчас в теме
(9) т.е. Вы считаете, что изначально БД 7.7 спроектирована правильно ? Не буду агитировать за Советскую власть.)))
И , если считаете, что запрос к 100 миллионам записей выполняется за одинаковое время чем запрос к 1 миллиону записей, то желаю и дальше верить в волшебную силу связки 1С 7.7+SQL
11. user1203706 12 01.02.22 19:07 Сейчас в теме
(10) изначально, да. А вот учет в ней можно вести через жпо, или, влезть туду кривыми ручонками, добавив незакрывающуюся аналитику.
12. user1203706 12 01.02.22 19:08 Сейчас в теме
(10) И вы не поверите, что 100мл, что 1млн никакой разницы в производительности в скуле не имеет.
15. uk09 01.02.22 19:15 Сейчас в теме
(12) Можете открыть Studio и выполнить запрос к двум базам . Прямо тут же увидите временную оценку исполнения. Увы, но это MS SQL, а не Oracle. Разница будет..
13. uk09 01.02.22 19:10 Сейчас в теме
думаю, что Вы в курсе про известный проект 1С++. Как Вы думаете, если бы изначально, в 7.7 всё было решено грамотно, этот проект получил бы дальнейшее развитие ?
14. uk09 01.02.22 19:12 Сейчас в теме
Ну и про альтернативные индексы SQL , наверняка, тоже что-то слышали. Так вот всё это , существует только как альтернатива решения для 7.7. Для 1С 8.X - нет ничего подобного
16. user1203706 12 01.02.22 19:21 Сейчас в теме
(13) Стоял у истоков, а что ?
(14)
Для 1С 8.X - нет ничего подобного

Спасибо, посмеялся.
В снеговике сплошь и рядом можно и нужно делать свои индексы, на тяжелых запросах, желательно покрывающие.
(15) Не вижу разницы в простом селекте с отбором по нужному индексу.
17. uk09 01.02.22 19:35 Сейчас в теме
Стояли Вы или нет, про то - история умалчивает. Я же не Вашей лептой интересуюсь..
Еще раз поясняю свою точку зрения : 1С 7.7 имеет ряд эксплуатационных ограничений, которые попробовали исправить в проекте 1С++. Сама корпорация 1С не стала вкладываться в доработку устаревшей платформы , а вложилась в разработку 8-й версии. Хотя я знаю несколько очень крупных торговых сетей, которые работают на 1С++ и ныне.
А вот широкого примера применения Снеговика увидеть - не пришлось. После выхода 8.3. и стабилизации работы тонкого клиента переход на продукт 1С стал массовым.
По времени запроса есть классическая расчетная формула - это log2(n), соответственно с 10000 записями будет работать в 1,5 раза быстрее чем с миллионом (при прочих равных)
18. user1203706 12 01.02.22 19:43 Сейчас в теме
(17) Для просвещения, 7.7 - это клюшки, 8.* - это снеговик
19. muskul 02.02.22 01:20 Сейчас в теме
Да и вообще где и как в 2022 году можно выкопать Бухгалтерию семерку.
20. vitalbasl 89 19.04.22 08:36 Сейчас в теме
У нас база 77 на 180Гб, несколько раз свертывали, потом бросили. полет нормальный
Оставьте свое сообщение
Вакансии
Программист 1С
Москва
зарплата от 180 000 руб. до 220 000 руб.
Полный день

Аналитик 1С / Бизнес-аналитик
Нижний Новгород
зарплата от 100 000 руб. до 250 000 руб.
Временный (на проект)

Программист 1С
Москва
зарплата от 250 000 руб.
Полный день

Программист 1C
Волгоград
зарплата от 200 000 руб.
Полный день

Аналитик
Санкт-Петербург
зарплата от 200 000 руб. до 250 000 руб.
Полный день