Корректность работы функций проверки КБУ и КОУ

[sim]

Насколько корректно работают сервисные функции КБУ и КОУ? Действительно ли (и всегда ли) они восстанавливают именно то, что нужно, и удаляют то, что не нужно? Просто наши админы относятся к этим функциям с определенной опаской, и запускают их избирательно и очень редко, из-за того, что когда-то давно эти функции якобы чего-то им там нарушили.
Действительно ли такое возможно? Есть ли у кого негативный опыт использования этих функций?
P.S. База на mssql, и очень большая.

[Den]

В любом случае на баке рабочей БД сначала нужно попробовать запустить эту функцию и посмотреть что она наделает.

[Алексей]

А как вы увидите что она действительно не задела то, что Вам нужно? Всплыть может через месяц.

[LaaLaa]

А какую цель вы желаете достичь применив эти функции?

1) Полечить БД, точнее полечить в БД какую то конкретную известную вам аномальную ситуацию. То тогда лучше сначала пытаться эту аномальную ситуацию полечь отдельно. Исходя и тех сведений которыми вы обладаете. Разработать или подобрать под эту ситуацию специальное средство. Это будет более эффективно. Ваши Амины вы этом случае будут правы. Зачем модифицировать все если вам нужно аккуратно выправить только конкретный участок.

2) Продиагностировать БД и конкретные аномалии вам не известны. Т.е. Вы надеетесь что эти утилиты сами все найдут и полечат. В этом случае имеет смысл сначала применить эти утилиты на копии тестовой БД. В внимательно проанализировать текст протокол проверки. Также желательно проанализировать журнал изменений (предварительно включив его перед проверкой). Протестовать основные процессы после проверки копии БД.
Т.е. сначала надо оценить потенциал возможных последствий именно для вашего экземпляра БД, а только потом применять на боевой БД.

PS: К сожалению из своего опыта хочу констатировать факт корректного ответа на вопрос "восстанавливают именно то, что нужно, и удаляют то, что не нужно?" не существует в принципе. Т.к. мнения "что нужно и что не нужно" у разработчиков Галактики и пользователей довольно часто не совпадают.

[LaaLaa]

А так, из опыта, в большинстве практически значимых случаев эти функции проверки КБУ и КОУ отрабатывают корректно. Но вероятность, что пойдет что не так все-же есть. Проверка на копии БД позволит снизить эту вероятность.

[sim]

... корректного ответа на вопрос "восстанавливают именно то, что нужно, и удаляют то, что не нужно?" не существует в принципе. Т.к. мнения "что нужно и что не нужно" у разработчиков Галактики и пользователей довольно часто не совпадают.

Здесь я имел в виду "то, что нужно и что не нужно" - с точки зрения целостности данных, логики работы системы, определенных разработчиками жестких схем связи документов и т.д.
Например, ситуация 1: из платежного документа есть ссылка на дополнительное соглашение к договору, а на сам договор ссылки нет. Это недопустимо в принципе. То есть сервисная функция должна восстановить связь с договором. Это пример того, "что нужно" (т.е. нужные связи). Причем, подчеркну, нужные в первую очередь с точки зрения системы, а затем уже с точки зрения пользователя.
Пример 2: болтаются не привязанные ни к какой накладной позиции спецификации накладной. И если установить соответствующую галочку, то сервисная функция должна их удалить. Это пример того, "что не нужно" (т.е. не нужные данные) с точки зрения и системы, и пользователя.
И вообще. Ведь разработчики вкладывали какой-то смысл при реализации данных сервисных функций. Опираясь при этом, как я уже сказал выше, на элементарную логику работы системы, поддержание целостности и т.д. Соответственно при этом они (разработчики) должны были соблюсти определенную корректность их работы.
И вопрос мой изначальный в том - насколько можно этому доверять?

[LaaLaa]

Утилиты проверки КБУ и КОУ соответствуют основным представлениям о целостности данных.

Но например если у вас в БД окажется ситуация из второго примера. Не факт что ее нужно лечить путем удаления спецификаций. Нужно понять почему так получилось. Может это нужно лечить путем воссоздания утраченных шапок документов. Если просто удалить, а потом у вас разойдутся остатки накладе. Админы будут винить эти утилиты?

В случае обнаружения сбоев всегда лучше сначала диангоз поставить а только потом пилюлю выписывать.

[sim]

Второй пример я неудачный привел.
А первый - прямо из практики.

[LaaLaa]

надо тестировать

[sim]

Все-таки запустили сервисные функции. Итог - проблема осталась. Т.е. платежное поручение так и осталось привязано к дополнительному соглашению, а к договору - нет. В результате этого невозможно сформировать внутренний акт сверки по договору, т.к. платеж не вяжется к акту (даже вручную), и как следствие - невозможно закрыть договор.
Таким образом, сервисная функция оказалась бесполезной.
Решилась проблема только ручной отвязкой - привязкой платежа к ДО (и договору).