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

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

После процедуры с truncate table, проводки не пострадают/исчезнут ?
6. user1203706 13 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 13 01.02.22 18:42 Сейчас в теме
(8) свёртка к производительности никакого отношения не имеет в правильно спроектированной бд, где нет не закрытых регистров/итогов по счетам.
10. uk09 01.02.22 18:48 Сейчас в теме
(9) т.е. Вы считаете, что изначально БД 7.7 спроектирована правильно ? Не буду агитировать за Советскую власть.)))
И , если считаете, что запрос к 100 миллионам записей выполняется за одинаковое время чем запрос к 1 миллиону записей, то желаю и дальше верить в волшебную силу связки 1С 7.7+SQL
11. user1203706 13 01.02.22 19:07 Сейчас в теме
(10) изначально, да. А вот учет в ней можно вести через жпо, или, влезть туду кривыми ручонками, добавив незакрывающуюся аналитику.
12. user1203706 13 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 13 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 13 01.02.22 19:43 Сейчас в теме
(17) Для просвещения, 7.7 - это клюшки, 8.* - это снеговик
19. muskul 02.02.22 01:20 Сейчас в теме
Да и вообще где и как в 2022 году можно выкопать Бухгалтерию семерку.
20. vitalbasl 90 19.04.22 08:36 Сейчас в теме
У нас база 77 на 180Гб, несколько раз свертывали, потом бросили. полет нормальный
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот