8.3.5.1068, настроена односторонняя синхронизация УТ 10.3 -> БП 3.0

Админ создал копию базы УТ 10.3 копированием SQL- файлов (параметры доступа к базе в настройках синхронизации уже поправили). Волнует другой вопрос: по логике 1с не обязательно все хранить в SQL, есть и вспомогательные файлы...

Что может отвалиться?

что такое "SQL- файлы" ?

(0) Приложенные файлы например.

(1) mdf, ldf

(2) подробнее можно?

Журнал регистрации хранится отдельно от базы

(5) ну ЖР и при выгрузке/загрузке не сохраняется..

вспомогательные файлы только - бд полнотекстового поиска
но её можно перестроить.

ну и жр.

(6) Вот именно.. криво как-то с ними сделали(

(4) Что подробнее?
В базе можно хранить приложенные файлы. Они могут храниться не в базе, а на диске.
Всё.

(9) капитан очевидность :)

(10) Не, оно конечно, понятно, что бекап SQL деалется штатными средствами, но можно и файлы скопировать, если detach сделать. Не очень понятно, ты с чем сравниваешь бекап, и как его надо было сделать?

(11) + Выгрузка из 1с - это нифига не бекап.

(11) я сравниваю со стандартным инструментом от 1с: в конфигураторе выгрузить/загрузить

Ведь сервер 1с- более высокоуровневая логика, там могут какие-то дополнительные телодвижения делаться при выгрузке/загрузке.

(12) А что это?

(13) Это инструмент выгрузить/загрузить. Не более того.

(14) Вполне себе бэкап.. не умничайте.. вероятность получить архив с кривыми данными при этом есть, но она очень небольшая.. Бэкап средствами sql тоже кривым бывает, особенно в случае постгреса.

(15) таки мы про sql или про постгреее? ))

(16) ms sql

(16) постгрес SQL ?

(18) Постргрееееееееееееееееееееее....
Студенческая под(д)елка....
(17) Как уже сказали, за исключением ЖР и внешних присоединённых файлов - ничего не будет.

(0) Ничего, кроме ЖР

(19) Вот кстати непонятно, почему 1с поддерживает постгрес, но не поддерживает файрберд. Нормальная же СУБД, со своими тараканами конечно, но зато на порядок стабильнее, чем постгрес.

+(21) Проектирование: 1С на Firebird

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

(23) Главные тормоза у файрберда из-за "кооперативной уборки мусора". Соответственно, хорошим тоном для баз файрберда является такая парадигма, когда МАССОВОЕ удаление данных минимизировано. А если уж удалять - то "убрать за собой", выполнив select таблицы, из которой удаляли.