1С Распределенная база данных

Что такое распределенная база данных?

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

Термин “распределенная база данных” применяется:

  1. К самой базе данных, работа с которой организована описанным выше образом.
  2. К программным механизмам, которые обеспечивают поддержу работы с такой базой данных.

Типичный пример: два офиса одного предприятия, не имеющие постоянного канала связи между собой (то есть не соединенные локальной компьютерной сетью или постоянным соединением через Internet), в БД головного офиса время от времени (например, раз в сутки) приходят данные из БД офиса-филиала.

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

В чем принципиальное отличие работы с распределенной базой данных программы 1С: Предприятие от работы с ней при помощи модема и терминального сервера или WEB-компоненты?

  1. Распределенная база данных использует каналы связи только на небольшое время при проведении синхронизации (обмена данными), более того, можно производить обмен данными посредством дискет, компакт-дисков и т.п., то есть вовсе без какой-либо компьютерной сети (без локальной сети, без Internet’а или т.п.). Большую часть времени работа ведется без использования канала связи. Для обеспечения такой работы в каждом из нескольких офисов (торговых точках и т.п) фирмы находится необходимая данному подразделению часть базы данных (или полностью вся база данных фирмы).
  2. При работе при помощи терминального сервера или WEB-компоненты используется одна единая база данных (обычно находящаяся в центральном офисе). При этом для работы с ней требуется задействовать какой-либо канал связи (локальную сеть, Internet и т.п.). Как только связь разрывается – работа с базой данных в удаленном офисе прекращается, так как база данных становится недоступна.

Что такое терминальный сервер? И зачем он используется для работы с программой 1С: Предприятие?

Что такое терминальный сервер и как его использовать с программой 1С: Предприятие описано в другом FAQ’е

При помощи чего можно организовать работу с распределенной базой данных?

  1. При помощи компоненты “Управление распределенными информационными базами” (УРИБ) от фирмы 1С.
  2. Можно создать собственный механизм, реализующий работу распределенной базы данных.

Что за компонента такая “УРИБ”?

УРИБ – “управление распределенными информационными базами” – это разработанный фирмой 1С и интегрированный в ядро платформы 1С: Предприятие 7.7 механизм, предназначенный для программной поддержки работы с несколькими изолированными базами данных как с единым целым (как с единой распределенной базой данных).

В общем схема работы механизма 1С: УРИБ такова:

  • УРИБ отслеживает изменения, производимые в базе данных.
  • Формирует файлы выгрузки, содержащие только измененные данные. Эти файлы должны быть переданы в другие части распределенной базы данных (по электронной почте или на дискете и т.п.).
  • Загружает файлы загрузки, которые содержат данные, измененные в других частях базы данных. Эти файлы должны быть каким-либо образом (электронная почта, дискеты и т.п.) получены из других частей распределенной базы данных.

Продается компонента УРИБ, обычно, как отдельный продукт и, обычно, требует отдельного ключа Hasp. Физически компонента представляет собой один-единственный файл – distrDB.dll – наличие которого требуется только в центральной части распределенной базы данных.

Можно ли организовать распределенную БД, используя возможности репликаций, имеющиеся в сервере MS-SQL

Нет. Пользуйтесь механизмами создания распределенных БД, созданным специально для программы 1C: Предприятие 7.7 фирмой 1Сили другими фирмами.

Это связано с нетривиальностью хранимых в БД данных программы 1С: Предприятие и с тем, что она (программа 1С: Предприятие) контролирует целостность структуры создаваемых ею таблиц, а при установлении Merge-репликации SQL-сервера в таблицы, хранящие данные программы 1С: Предприятие, добавляется дополнительное поле – внутренний идентификатор реплицированной строки. После опубликования таблицы на репликацию программа 1С: Предприятие будет считать что база данных разрушена и откажется работать. Но именно Merge-репликации пригодна для организации распределенных баз данных. Репликация в режиме SnapShot не нарушает работу программы 1С: Предприятие с опубликованной базой данных, но это однонаправленная, а не двусторонняя репликация, поэтому она не может быть использована для организации распределенной базы данных. Хотя, репликация в режиме SnapShot может быть пригодна для создания автоматически обновляемых копий базы данных для анализа данных (чтобы такой анализ можно было проводить в другом офисе или дому у владельца предприятия или в основном офисе просто для того, чтобы не перенапрягать основную рабочую систему сложными отчетами).

Будет ли работать компонента “Управление распределенными информационными базами” (УРИБ) от фирмы 1С, если в центральномофисе 1С: Предприятие работает с использованием SQL-сервера, а в филиалах – с использованием DBF-файлов?

Да, будет работать. Файлы, с помощью которых осуществляется обмен данным в УРИБ не зависят от вида БД 1C: Предприятие 7.7 – DBF она или SQL.

Для обмена данными с использованием УРИБ требуется запускать 1С: Предприятие монопольно?

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

Исключением являются чрезвычайно сильно перегруженные работой БД. В таких БД обмен данными, возможно, не удастся осущестить с первого раза. Или, даже, удастся произвести обмен только в монопольном режиме, выгнав всех пользователей.

Монопольный режим обязательно требуется только в периферийной БД, и только тогда, когда в центральной БД изменен MD файл. Монопольный режим нужен в таком случае, чтобы накатать на периферию новый MD. Ну а обмен данными попутно осуществляется.

При обмене данными с помощью УРИБ пишет предупреждение о недоступности каких-то режимов, но загрузку и выгрузку все равно производит.

Обмен данными можно производить как в монопольном, так и в разделенном режиме. Теоретически, при обмене данными в разделенном режиме могут возникнуть следующие проблемы, о чем на всякий случай и предупреждает программа 1С: Предприятие при выполнении обмена:

  1. Обмену данными могут помешать блокировки на используемых пользователями объектах, если эти объекты будут загружены при обмене
  2. Для периферийной (не для центральной) БД невозможно обновить конфигурацию. Однако если конфигурация не была изменена со времени предыдущего обмена данными, то это неважно
  3. Обмен данными будет прерван из-за слишком большой нагрузки на БД. Но его можно будет повторить спустя несколько минут

Если файл МД был изменен на центральной базе, то как сделать так чтобы переферийная это поняла? Распаковать пришедший МД и заменить новый на старый? Если он сильно изменен? Только МД нужно поменять или что ещё?

Штатный (нормальный) режим работы:

  1. Конфигурация (MD-файл) настраивается только в центральной базе.
  2. Как только конфигурация изменена, она автоматически едет во все периферийные базы
  3. Т.е. zip-файл, который создается при обмене данными, будет содержать, как обычно, сами данные, уезжающие на периферию и, дополнительно, MD-файл. Это делает сама 1С. Ничего вручную дополнительно делать не надо.
  4. Этот zip-файл, как обычно, загружается в периферийную базу. Если попытаться загрузить его не в монопольном режиме, то 1С сруганется при загрузке, и загрузку следует повторить (уже в монопольном режиме).
  5. Строго говоря, в монопольный режим “1С: Конфигуратор” входит не при своем запуске, как это делает “1С: Предприятие”, а именно при обмене данными.
  6. Если MD-файл не добрался до периферии, то получить оттуда данные после изменения конфигурации в центральной базе – не удастся.
  7. Центральная база будет при каждом обмене данными внутри zip-файла посылать измененный MD-файл, до тех пор, пока он не попадет в периферийную базу. Точнее, до тех пор, пока периферийная база не пришлет подтверждение, что MD-файл накатан.

Hикак не могy заставить pаботать 1С: Предприятие. Hе yстановлена, говоpит, компонента УРИБ.

В центральной БД для всех клиентов должна быть доступна компонента УРИБ (доступна – значит должен быть в наличие в каталоге, где лежит exe-файл 1С, файл distrDB.DLL и специальный Hasp к нему или Sable).

В УРБД пpи пpопуске хотя-бы одного пакета обновления базы дальше не обновляются?

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

Как сделать распределенную базу нераспределенной?
В частности это бывает нужно для отцепления периферийной базы от центральной.

Для Базы данных в формате DBF достаточно удалить из каталога базы данных следующие файлы: 1SDBSET.DBF, 1SDBSET.CDX, 1SDWNLDS.DBF, 1SDWNLDS.CDX, 1SUPDTS.DBF, 1SUPDTS.CDX, 1SSYSTEM.DBF (не обязательно). После чего желательно войти в Конфигуратор и сделать полный контроль. И это все. При желании, можно восстановить обратно – достаточно эти файлы восстановить. Для базы данных в формате SQL – аналогично, только удалять нужно таблицы из SQL-базы: _1SDBSET, _1SDWNLDS, _1SUPDTS, _1SSYSTEM (не обязательно).