Задать вопрос
  • Как удалить базу из 1с кластера?

    @Dementor
    программист, архитектор, аналитик
    Суть проблемы при работе в консоли 1с (mmc), она начинает виснуть и закрываться.

    Ситуация странная. Консоль должна просто считывать и показывать данные из подключенных серверов. С подобным еще не сталкивался - бывало только, что консоль выдавал ошибку и не хотела работать - это лечилось перерегистрацией консоли (radmin.dll)

    Если не получается отредактировать список баз с помощью консоли, то это можно сделать еще тремя путями:

    1) явным редактированием настроечных файлов кластера (как написано в вопросе)

    2) по COM-соединению через "V83.COMConnector" можно получить агент нужного кластера и програмно отредактировать список баз (https://its.1c.ru/db/v8325doc/bookmark/cs/TI000000256)

    3) установить сервер RAS и далее три подварианта:
    3.1) подключится к нему с помощью утилиты RAC и отредактировать список из командной строки
    3.2) подключится с помощью библиотеки irac из oscript
    3.3) подключится из кода 1С с помощью объекта АдминистрированиеСервера

    реестр хранить еще в системных база SQL

    В системных базах SQL хранятся записи о базах этого сервера и это абсолютно независимая от кластера 1С информацию. Удалять базы физически не обязательно, если вы планируете к ним подключатся с другого кластера или с помощью автономного сервера.
    Ответ написан
    1 комментарий
  • MsSQL ошибка при создание лога транзакций?

    @mvv-rus
    Настоящий админ AD и ненастоящий программист
    Возможно проблема в чистке журнала транзакций (база переводится в simple, shkrink ну и обратно в full), но на другом сервере проблем не наблюдаю с этим.

    Да, это как раз может вызывать вашу ошибку: если после полного резервного копирования происходит изменение модели восстановления базы (full->simple->full), и в момент, когда БД находится в simple, происходит усечение журнала транзакций, то цепочка записей транзакций после полного копирования оказывается нарушенной. А если усечения не происходит, как на другом сервере, - то вам везет. Поэтому так, как вы делаете, делать не надо.
    Вы сжимаете именно журнал транзакций, а не саму БД, я правильно понял? В таком случае посмотрите, а надо ли это вам. Потому что резервное компирование журнала транзакций очищает занятое место в его файле. И это место в дальнейшем (через некоторый промедуток времени - после переключения на другой логический журнал) может использоваться повторно. В результате в стационарном случае - при примерно одинакой частоте трназакций - файл журнала расти перестает.
    Если же вам действительно потребуется сжать журнал - например, после массовй операции типа загрузки большого объема данных - то это можно сделать, не меняя модель восстановления БД. Делается это последовательностью операций "резервное копирование журнала"->"повторное резервное копирование журнала"(лучше после паузы, чтобы преключение на следующий пустой логический журнал, который будет в начале файла, точно произошло)->"усечение журнала с конца"(truncate). Иногда, правда, эту последовательность может потребоваться повторить (если переключения на пустой логиченский журнал в начале файла не произошло).
    А усечение журнала трназакций с конца - это очень быстрая операция (потому что никакие записи журнала никуда не перемещаются), так что ее можно делать обычно даже в период номинальной нагрузки, днем.
    Ответ написан
    1 комментарий