Проверка базы данных 1C на целостность и исправление ошибок MS SQL

При использовании IBM DB2 префиксы псевдонимов таблиц начинаются не с символа подчеркивания, а сразу с буквенной части.

Количество этих таблиц зависит от функциональности конфигурации и может быть достаточно большим. В штатном режиме 1С:Предприятие не выполняет проверку их наличия, а также целостности и непротиворечивости содержащихся в них данных. Поэтому важно, чтобы база данных, в которой размещена информационная база 1С:Предприятия 8.1, была защищена от несанкционированного доступа и ее модификация выполнялась только средствами 1С:Предприятия. Для проверки необходимо использовать функцию «Администрирование — Тестирование и исправление», встроенную в конфигуратор.

Важно также, чтобы резервное копирование и восстановление базы данных, хранящей информационную базу, выполнялось только целиком. С этой целью рекомендуется использование средств резервного копирования баз данных, встроенных в в используемую СУБД. Резервное сохранение файлового варианта информационной базы может быть выполнено копированием файла 1Cv8.1CD.

В конфигураторе есть специальная функция: Администрирование — Выгрузить информационную базу. С ее помощью можно выгрузить в указанный файл (файл выгрузки) все данные, относящиеся к информационной базе, и больше никакие. Обратная ей функция «Загрузить информационную базу» позволяет в текущую информационную базу вместо существующих загрузить все данные из файла выгрузки. Эти функции также можно использовать для резервного копирования данных информационной базы как в файловом так и в клиент-серверном варианте.

Как просмотреть структуру таблиц информационной базы?

Источник

Accrgat что за таблица

вот я в какой-то делал так
https://www.sql.ru/forum/actualthread.aspx?tid=880664&pg=1&mid=11279639#11279639
(суть вкратце — они пихают массу записей в транзакции в стационарные таблички, а статистику внутри транзакции не пересобирают , а ПЖ-сам по себе тут туп как пробко — не собирает он сам статистику в транзакциях, если специально не просить
— переписываем то же чсерез честные темповухи (который 1С умеет таки даже и ANALYZE) — и имеем профит)

потом они немного обновили структуры и процедуру — начиная с 1.3.17.1 у нас надобность в самопале отпала. (тестирование дало неплохие результаты без переписывания стандартных процедур через времянки)

как общий рецепт предлагают установить одну из констант в 1:

платформа тут не важна.
какая версия конфы? (в конфах процедура менялась где-то к 1.3.17-й)

если не ниже 1.3.17. — раскидайте сами руками запросы 1с в процедуре на времянки
если ниже — могу покопаться — есть где то текст. Это общий модуль «КорректировкаСтоимостиБлаБлаБла» — процедуру найдёте отладчиком.

/* я там выше не дописал: — идет вставка в таблички нескольких (десятков) тысяч записей, а потом к ним же идёт и обращение в следующем SELECT-е той же транзакции, ПЖ, по статистике, ожидает 0 записей, а получает несколько (десятков) тысяч. уровень вложенности циклов nested loops доходит до 4-5, т.ч. без времянок всё становится дико скучно */

посмотрите, включен ли у вас режим РАУЗ (если нет — то ф-я скорее всего другая).
тестовый вариант этого модуля для 1.3.17.1 от 1С — прислан их поддержкой на тестирование (с ошибкой, как без этого) у меня есть. написан через времянки.

PPS
включите логирование длинных запросов постгресом.
я делал примерно так:

— после этого гасим все процессы (rphost) 1с (из оснастки 1с), поднимаем по новой (чтобы в новом соединении работали все альтернутые константы) — запускаем процедуру и смотрим, какие именно запросы и сколько именно висят, и как именно исполняются

Хотя если вы найдете дырочку в синтаксисе 1С8-SQL, годную для SQL-инжекции — буду вам признателен. тогда можно будет самопально сетить внутри сеанса.

если вы из писателей библиотеки работы 1С с постгресом — могли бы шепнуть на ушко

5 минут
Postgress этот же документ с этими же данными отмена проведения около

там вы действительно увидите, кто «основной тормоз», а где — не основной.

далее вы правильно понимаете, что проблемы — в построении неверного плана, на основе неверной статистики.

из чего один вывод —
либо запинать планировщик на другой план (константами в conf).
либо переписать процедуру 1С таким образом, чтобы (после трансляции 1С-кода в SQL) перед планировщиком не возникала проблема построения выборки по таблицам с неверной статистикой.

чтобы понять, какой код 1С отвечает за конкретный висячий запрос PostgreSQL можно воспользоваться готовой внешней обработкой (которая делает внутри себя что-то типа раскрутки возврата метода «ПолучитьСтруктуруХранения» (естественно вру, но такого типа метод ага. вот ПолучитьСтруктуруХраненияБазыДанных (GetDBStorageStructureInfo) https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=348199&msg=3820914 , но есть и готовая обработка в сети. под рукой нет, на работке ). После замены имен на 1С синонимы вы примерно увидите, что было исходно в 1с-коде, и сможете поискать в конфигурации (мне проще всего оказалось найти по условиям джойна регистров).

я у себя даже не анализировал алгоритм. я выдрал записи из только что пополненной таблицы во времянку, проиндексировал(1с тут анализирует времянки), и запрос сделал к ней, а не к стационарной табличке. т.е. у меня всё свелось к переписыванию 1-го запроса 1С.
(грубо — была выборка по (двойному) джойну только что обновленному регистра с другим регистром (в 2-х экземплярах), с условиями (id-регистратора), — я сначала выдрал кусок из только что обновленного по id регистратора во времянку — а (двойной) джойн уже делал на неё. — требуется минимальное вхождение в суть — делая тождественные преобразования запроса только следить за строгостью этих преобразований )

Тип: Массив.
Массив имен объектов метаданных или массив объектов метаданных, для которых требуется получить структуру таблиц базы данных.
(необязательный)

Тип: Булево.
Определяет, в каких терминах выдается информация о структуре хранения.
Истина — в терминах СУБД
Ложь — в терминах модели базы данных 1С:Предприятия.
Значение по умолчанию: Ложь
Возвращаемое значение:

Уважаемый «основной тормоз», у меня к Вам два вопроса:
1. Как вы думаете откуда я взял приведенный в первом посте текст запроса?
2. Как вы думаете на основании какой информации я утверждаю что _AccRgAT21278 таблица остатков по регистру бухгалтерии?

Мне очень интересен Ваш опыт по оптимизации запросов 1С для постгреса, но у меня совершенно другая проблема катастрофически медленная запись в регистры. Сейчас я анализирую две строчки кода 1С:

Объект = Документы.РасчетСебестоимостиВыпуска.НайтиПоНомеру(«000000001»).ПолучитьОбъект() ;
Объект.Записать(РежимЗаписидокумента.ОтменаПроведения) ;

Я уже писал выше, но видимо не столь подробно, попробую максимально просто изложить суть вопроса, для тех кто не знаком с 1С.
Есть такой объект Регистр, совсем упрощенно он представляется двумя таблицами, одна таблица движение и вторая таблица остатков по периодам.
Например
Таблица оборотов, назовем ее TAB1, co следующей структурой:
Period
Field1
Field2
Value
Таблица остатков, назовем ее TAB2
Period
Field1
Field2
Value

спрашивали — отвечаем :

1. поскольку ваш первый запрос обрывается на

(т.е. с т.з. SQL не закончен) — то очевидно, вы взяли его не из лога.
если бы из лога — то вам пришло бы в голову привести в т.ч. и строчку с duration, с тем , чтобы мы могли убедиться, что это реально долго выполняющийся запрос, а не ваше очередное блаблабла.
такие дела

2. совершенно не понятно, на основе чего вы это заявляете, ибо сделать копипасту в виде РегистрБух.Блаблабла было бы и содержательнее и убедительнее. Стало быть копипасту вам взять неоткуда.
как-то-так.

хотя если вы всё таки имеете тормоза на реально простейшем запросе с UPDATE одной таблицы данными из второй таблицы, не отягощённый никакими джойнами и кореллированными подзапросами — то проблема видимо где то в другом месте, а не в планировщике.

и вам, видимо, надо что-то делать с настройками PG. типа shared_buffers и work_mem приподнять. И т.п. параметры работы с памятью. (1С имеет примерно 2 соединения на процесс rphost 1С-а, т.е. сеансов=процессов postgres у вас очень мало, если вы не имеете 100-ню ядер и не запускаете соответственно около 50 rphost-ов, т.ч. work_mem можно поставить довольно большим).

Вряд ли тут можно помочь настройкой базы.
сколько записей у вас находится в _AccRgAT21278
и (хотябы приблизительно как вам кажется) получается в tt14?

Далее попробуйтей включить в настройках базы
log_lock_waits=1
log_temp_files=1
и посмотреть не пишется ли чего между
2012-04-04 17:00:08 MSK LOG: duration: 14.999 ms statement: ANALYZE tt14
и
2012-04-04 17:01:57 MSK LOG: duration: 109092.000 ms statement: UPDATE.
и сразу после update

Какие индексы есть на _AccRgAT21278?

Update по связи _AccRgAT21278 с tt14 он 1 к 1 идет (т.е. не может ли быть ситуации что у вас 1 запись в t114 вызывает сильно больше 1 update на _AccRgAT21278 )?

Cколько у вас стоит work_mem ?

далее — перед аналайз не вижу создания никакого индекса по t4. поэтому одна из первых идей — найти то место, которое отвечает за этот INSERT INTO в 1С и приписать в конце 1С- кляузы «ИНДЕКСИРОВАТЬ» (см 1С-скл). индексировать времянку надо бы примерно по (_EDCount,_Period, _Fld1254RRef [ссылка некоего ссылочного типа])

я думаю если _AccRgAT21278 — это т.н. «регистрБух хозрасчетный», при этом tt14 делается для первого документа списания остатков (вообще первого — в первый раз считаем себестоимость выпуска) , и регистраторов там (в tt14) — 90 000 (см. ТС выше) — то в регистре хозрасчетном _AccRgAT21278 как минимум в разы больше записей (это все проводки 1С по счетам БУ). а вероятнее всего — больше как минимум на порядок-другой.

по крайней мере там (MSSQL) проблемы 1с-никами решаются на порядок быстрее.

а там и нету 8часового плана.
там как я понял очень большая пачка запросов вида
2012-04-04 17:01:57 MSK LOG: duration: 109092.000 ms statement: UPDATE _AccRgAT21278 SET
в транзакции
и надо понять почему они так тормозят.
вообще индексы на tt14 тут по логике не помогут.

кстати еще (вряд ли но вдруг) сделать руками analyze _AccRgAT21278;

Источник

Проверка базы данных 1C на целостность и исправление ошибок MS SQL.

Делимся опытом, как исправить ошибки в логической целостности в базе 1С, размещенной на Microsoft SQL Server.

Поступила жалоба от бухгалтера о проблемах с проведением документов в 1С.

Из скриншота выяснилось, что 1С «ругается» на проблемы с согласованностью «внутри» базы данных и предлагает провести проверку на согласованность.

Переходим в SQL Server Management Studio и, сделав, на всякий случай, бэкап текущего состояния, выполняем проверку:

Для начала переводим нужную нам БД в однопользовательский режим

Запускаем Окно запросов (CTRL+N). Выбираем Новый запрос и вводим запрос Transact-SQL (T-SQL) в этом окне:

ALTER DATABASE KA
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE

Далее, вводим запрос на сканирование базы данных:

USE [ka]
GO
DBCC CHECKDB(N’ka’) WITH NO_INFOMSGS
GO

Проверка продлилась около 15 минут, после чего выдала следующее:

CHECKDB обнаружил 0 ошибок размещения и 766 ошибок согласованности, не связанных ни с одним объектом.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице «sys.sysdbfiles» (идентификатор объекта 20).
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице «sys.sysxmlcomponent» (идентификатор объекта 91).
CHECKDB обнаружил 0 ошибок размещения и 49 ошибок согласованности в таблице «_AccRg1025» (идентификатор объекта 1778313595).
CHECKDB обнаружил 0 ошибок размещения и 3 ошибок согласованности в таблице «_AccRgAT21046» (идентификатор объекта 1826313766).
CHECKDB обнаружил 0 ошибок размещения и 1783 ошибок согласованности в таблице «_AccRg1051» (идентификатор объекта 1906314051).
CHECKDB обнаружил 0 ошибок размещения и 2603 ошибок согласованности в базе данных «KA».

Вариант решения №1: восстановление из бэкапа выявило накопительный характер ошибки: чем раньше сделан бэкап – тем меньше в базе ошибок, вплоть до самого «дальнего» (14 дней). Примерно на третьем бэкапе количество ошибок перестало уменьшаться – стало ясно, что этим путём мы придём только к потере актуальности базы и проблему не решить

Вариант решения №2 : В справочной информации описаны три возможных варианта исправления этих ошибок, рассмотрим каждый:

REPAIR_FAST

Синтаксис поддерживается только для обеспечения обратной совместимости. Действия по восстановлению не выполняются.

REPAIR_REBUILD

Выполняет действия по восстановлению данных, которые можно выполнить без риска их потери. Это может быть быстрое восстановление (например, восстановление отсутствующих строк в некластеризованных индексах) или более ресурсоемкие операции (например, перестроение индекса).

REPAIR_ALLOW_DATA_LOSS

Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.

Аргумент REPAIR_FAST нам не подходит, REPAIR_ALLOW_DATA_LOSS оставим на крайний случай — пробуем REPAIR_REBUILD:

DBCC CHECKDB(N’ka’, REPAIR_REBUILD) WITH NO_INFOMSGS

CHECKDB обнаружил 0 ошибок размещения и 766 ошибок согласованности, не связанных ни с одним объектом.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице «sys.sysdbfiles» (идентификатор объекта 20).
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице «sys.sysxmlcomponent» (идентификатор объекта 91).
CHECKDB обнаружил 0 ошибок размещения и 49 ошибок согласованности в таблице «_AccRg1025» (идентификатор объекта 1778313595).
CHECKDB обнаружил 0 ошибок размещения и 3 ошибок согласованности в таблице «_AccRgAT21046» (идентификатор объекта 1826313766).
CHECKDB обнаружил 0 ошибок размещения и 1783 ошибок согласованности в таблице «_AccRg1051» (идентификатор объекта 1906314051).
CHECKDB обнаружил 0 ошибок размещения и 2603 ошибок согласованности в базе данных «KA».

Не помогло, переводим базу данных обратно в многопользовательский режим:

ALTER DATABASE KA
SET MULTI_USER

На всякий случай, я попробовал провести обслуживание базы данных и перепроверил – результат тот же.

Решил провести тестирование и исправление информационной базы средствами 1С, на что получил ошибку

Источник

Сколько должно быть антител к коронавирусу: тесты и норма антител

Кадр видео; скриншот helix.ru

Сколько нужно антител?

Многих волнует вопрос, сколько нужно антител, чтобы чувствовать себя защищённым от коронавируса. Хочется получить конкретный ответ – такое-то число или от стольки до стольки.
Но для этого нужно знать как минимум три вещи:

• какие именно антитела мы считаем;
• на какой тест-системе;
• в каких единицах выдали результат.

Кроме того, медики, учёные и сами лаборатории честно предупреждают: пока что нет никаких стандартов или порогов, чтобы говорить о «достаточном» уровне антител. Погоня за антителами – это просто способ самоуспокоения.
Но понимая, как это может быть важно, учёный-биолог с мировым именем, профессор Школы системной биологии Университета Джорджа Мейсона Анча Баранова дала следующие ориентиры.

Самый показательный тест на антитела к коронавирусу

По словам Барановой, для оценки защиты от вируса один из самых показательных на настоящий момент – это тест на антитела к RBD-домену S-белка коронавируса. Он подходит для измерения антител после прививок вакцинами «Спутник V» и «КовиВак» (после «ЭпиВакКороны» – не подходит; для неё «Вектор» создал свой тест на антитела).

В российских лабораториях этот тест проводят наборами реагентов от разных компаний. Но Анча Баранова пояснила, как оценивать результаты, только для теста компании Abbott под названием Quant. Вот он, к примеру, на сайте лаборатории «Гемотест».
«У него шкала от 50 до 40 000. Если показатель выше 1 300 – иммунитет хороший, если от 500 до 1 300 – есть риск заболеть, если меньше 500 – нужно вакцинироваться или ревакцинироваться», — заявила доктор биологических наук.

Но обратите ВНИМАНИЕ на единицы измерения! Учёный озвучила результаты в единицах производителя AU/ml (или ОЕ/мл, как неверно, но почти повсеместно переводят на русский). Однако лаборатории сегодня чаще выдают результаты в международных единицах стандарта ВОЗ – BAU/ml. Обычно на странице конкретного теста указана формула, по которой можно сделать пересчёт. Именно для этого теста формула такая: BAU/ml = [AU/ml] x 0,142.
Таким образом, если вам выдали результат в единицах AU/ml, то вот ваши ориентиры:

• больше 1 300 – хорошо;
• от 500 до 1 300 – недостаточно хорошо, есть риск заболеть;
• меньше 500 – нужно вакцинироваться или ревакцинироваться.

Если же вам выдали результат в единицах BAU/ml, то расклад будет такой:

• 185 и выше – хорошо;
• 71–184 – есть риск заболеть;
• меньше 71 – мало.

Самый распространённый тест на антитела к коронавирусу

До появления теста Abbott к RBD-домену чаще всего проводили тест на антитела к спайковому (S) белку – это тест LIAISON от компании DiaSorin. Его по-прежнему предлагают практически во всех лабораториях, хотя, по словам Анчи Барановой, он уже не считается самым точным и уходит в прошлое.
Вот, к примеру, этот тест на сайте лаборатории «Хеликс». (Он также подходит для измерения антител после прививок вакцинами «Спутник V» и «КовиВак», но не подходит для «ЭпиВакКороны», у которой свой отдельный тест).

Шкала этого теста в единицах производителя AU/ml (или, по-русски, ОЕ/мл) идёт до 400.
«Хорошим результатом считается уровень в 200–300. Тогда можно считать, что у человека хороший иммунитет от коронавируса», – сказала профессор.
На скриншоте ниже – пример результата теста в единицах OE/мл с очень высоким уровнем антител после «Спутника» – больше 400.

Другой пример: антител достаточно, чтобы тест считался положительным, но недостаточно, чтобы говорить о хорошей защите, – 18,1 ОЕ/мл.

Опять же, обращайте ВНИМАНИЕ на единицы измерения в результатах вашего теста! «Хеликс», например, указывает для этого теста следующую формулу пересчёта в единицы стандарта ВОЗ: BAU/мл = 2,6 x единицы измерения производителя.

Другие тесты на антитела. Норма антител

Самые популярные сетевые лаборатории предлагают множество других видов тестов на антитела. Например, в «Инвитро» делают российский количественный тест на антитела к S-белку. (Подходит после вакцинации «Спутником» и «КовиВаком», кроме «ЭпиВакКороны»).
Он измеряется в единицах BAU/мл по стандарту:

• меньше 10 – антител нет;
• больше или равно 10 – антитела есть.

Но учитывая, что «потолок» шкалы этого теста – 500 BAU/мл, производитель дал пояснение, как точнее оценивать результаты:

• 150 и выше – достаточный уровень защиты;
• 80–149 – вероятность, что вы защищены от вируса, составляет только 50%;
• меньше 79 – низкая защита, нужна вакцинация или ревакцинация.

В «Гемотесте» делают тест к RBD-домену S-белка на швейцарской системе Roche. (Подходит после вакцинации «Спутником» и «КовиВаком», кроме «ЭпиВакКороны»).
Он тоже измеряется в единицах BAU/мл, но у системы другой предел чувствительности и другая интерпретация результатов: от 15 и выше – достаточный уровень защиты с прогнозом эффективности против вируса в 99,10%

После вакцины антител нет или мало. Что делать?

Помните, что тест можно проводить не ранее чем через 21 день после введения второго компонента вакцины.
Если после прививки антитела не определяются или их мало, то Минздрав рекомендует следующее:

• вакцинироваться повторно через шесть месяцев (с возможной заменой вакцинного препарата при его наличии);
• если после повторной вакцинации антитела также не определяются, детально обследоваться на наличие иммунодефицита.

Медики, со своей стороны, напоминают, что иммунитет определяется не только этими антителами. Даже при их отсутствии у человека может выработаться клеточный иммунитет к коронавирусу, так что гоняться за антителами бессмысленно.
Существуют тесты именно на клеточный иммунитет, но они сложные и очень дорогие (от 10–15 тыс. рублей в Москве). Кроме того, нет достоверных данных, по которым можно чётко интерпретировать результаты.
Читайте также: Делать ли прививку от коронавируса переболевшим? Нужна ли им вакцина?

Источник

1С: Предприятие, восстановление индексов СУБД

Занимаюсь разработкой конфигураций на основе платформы 1С: Предприятие. При разворачивании копии базы сформированной средствами 1С: Предприятие регулярно появлялась ошибка:

Так как копии разворачивались только в целях внесения изменений в конфигурацию и тестирования, этой ошибке не предавали особого значения, пока не понадобилось добавить предопределенный счет. При обновлении конфигурации происходила реструктуризация регистра бухгалтерии и вываливалась данная не приглядная ошибка. Дальнейшее обновление прекращалось. Гугление данного вопроса результатов не дало. пришлось разбираться самим.

Выяснение имени таблицы 1С связанной с объектом определяется функцией ПолучитьСтруктуруХраненияБазыДанных, там же можно поглядеть и состав индексов.

Как оказалось данные индексы в таблице SQL «_AccRg2024» отсутствовали физически. При дальнейшем анализе данных уже средствами SQL выяснилось, что не уникальными были номера записей в разрезе Периода — [_Period], регистратора — [_RecorderRRef] и номер записи [_LineNo], из за чего и не происходила реструктуризация таблицы. Кто и как умудрился удалить эти индексы история умалчивает, данный факт восстановлению не подлежит.

Вылечилась данная ситуация следующим запросом:

Изначально определяются неуникальные записи, выбираются регистраторы и в цикле происходит пере нумерация строк.

После этого, уже средствами 1С, выполнилось тестирование базы с режимом «Реструктуризация таблиц информационной базы», данная процедура пересоздала индексы в таблице, и дальнейшие манипуляции, при работе с метаданными конфигурации, стали происходить без каких либо ошибок.

Источник