Доброе время суток!
Пару месяцев назад начали случаться задвоения IDDOC документов. Выглядит это так - записываешь документ и видишь, что у тебя поменялся его номер.У другого человека вообще поменялось содержимое документа. Причем движения по регистрам от одного документа, а содержимое документа от другого.
Раньше такие случаи происходили раз в год, может чуть чаще. Сейчас же участились до раза в неделю. Нагрузка и интенсивность ввода существенно не поменялись. От силы прибавилось 10%.
Имеем:
-Сервер Hyper-V 1 х E5-2630v2 (2.6 ГГц, 6 ядер + гипертрейдинг), 64 ГБ памяти, 6 х 3 ТБ Рейд5
на сервере работают две виртуалки - Терминальный сервер (6 ядер, 13 ГБ) и Сервер SQL 2008R2 Enterprise (4 ядра, 10 ГБ)
Нагрузка на проц небольшая - в пределах 5-10%
Размер базы - 15 ГБ, Совместимость 80 (SQL Server 2000)
На терминальном сервере установлен секретный релиз платформы v77.27.7. Приблуда от 100% процессора при транзакциях не используется, т.к. сразу начинаются приключения - не записались транзакции, задвоились ID справочников. Поэтому отключена.
Конфигурация самописная на 7.7 ОперУчет.
В базе работают около 100 человек. В день вводится около 5000 документов и до 100 000 элементов справочников (ведётся история изменений документов)
Проблем с производительностью нет. Документы проводятся не дольше 1 секунды.
Каких-то особых выёживаний в конфе нет - используется 1c++, FormEx, ПрямойЗапрос. Прямая запись почти не используется - только в обработках свертки.
Вопрос: кто-нибудь сталкивался с подобным? В интернете информацию об этом не нашел.
Пару месяцев назад начали случаться задвоения IDDOC документов. Выглядит это так - записываешь документ и видишь, что у тебя поменялся его номер.У другого человека вообще поменялось содержимое документа. Причем движения по регистрам от одного документа, а содержимое документа от другого.
Раньше такие случаи происходили раз в год, может чуть чаще. Сейчас же участились до раза в неделю. Нагрузка и интенсивность ввода существенно не поменялись. От силы прибавилось 10%.
Имеем:
-Сервер Hyper-V 1 х E5-2630v2 (2.6 ГГц, 6 ядер + гипертрейдинг), 64 ГБ памяти, 6 х 3 ТБ Рейд5
на сервере работают две виртуалки - Терминальный сервер (6 ядер, 13 ГБ) и Сервер SQL 2008R2 Enterprise (4 ядра, 10 ГБ)
Нагрузка на проц небольшая - в пределах 5-10%
Размер базы - 15 ГБ, Совместимость 80 (SQL Server 2000)
На терминальном сервере установлен секретный релиз платформы v77.27.7. Приблуда от 100% процессора при транзакциях не используется, т.к. сразу начинаются приключения - не записались транзакции, задвоились ID справочников. Поэтому отключена.
Конфигурация самописная на 7.7 ОперУчет.
В базе работают около 100 человек. В день вводится около 5000 документов и до 100 000 элементов справочников (ведётся история изменений документов)
Проблем с производительностью нет. Документы проводятся не дольше 1 секунды.
Каких-то особых выёживаний в конфе нет - используется 1c++, FormEx, ПрямойЗапрос. Прямая запись почти не используется - только в обработках свертки.
Вопрос: кто-нибудь сталкивался с подобным? В интернете информацию об этом не нашел.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
в таблице [_1SJOURN]
[IDDOC] индекс уникальный -
поэтому никак не может задваиваться,
похоже вы обманываете
или путаете номер документа с IDDOC
[IDDOC] индекс уникальный -
поэтому никак не может задваиваться,
похоже вы обманываете
или путаете номер документа с IDDOC
(2) В таблице _1SJOURN ничего не задваивается. Просто при записи 1С получает у двух пользователей один и тот же IDDOC. При записи в базу получается какая-то дикая мешанина - в таблице _1SJOURN данные документа1, шапка и табличная часть документа2, движения по регистрам документа1.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот