Доступно с лицензией Standard или Advanced.
Для синхронизации реплик в отключенной среде, вы должны осуществить обмен сообщениями вручную. Это можно произвести путем экспорта сообщения из одной реплики в определенный файл, а затем с помощью импорта этого сообщения из данного файла в связанную реплику. В автономных системах файлы могут быть перенесены на таких носителях, как CD или DVD, и отправлены посредством службы доставки, например, при помощи частного курьера, почтовой службы и т.д.
В любое время реплика может быть отправителем данных, либо получателем данных. Система отправки данных экспортирует сообщения с изменениями данных в дельта-файлы, содержащие изменения данных, которые должны быть внесены в связанную реплику. Система приема данных экспортирует сообщения, подтверждающие получение данных, в файлы подтверждения приема данных для подтверждения того, какие данные были получены. Вы можете определить, является ли реплика отправителем или получателем данных, посредством проверки статуса реплики в Менеджере реплик (Replica Manager) в ArcMap. Для информации по Менеджеру реплик (Replica Manager) Краткий обзор средств управления репликами.
Для реплики, производящей получение данных, очень важно экспортировать сообщения подтверждения приема данных как можно чаще. Если подтверждающих сообщений не будет получено, то отправитель данных, по умолчанию, отошлет изменения повторно и будет хранить информацию, необходимую для повторной отправки изменений, пока не получит подтверждения о приеме этих изменений. В результате база геоданных отправителя данных может стать очень большой, и соответствующие сообщения об изменении данных также могут стать очень большими.
В идеале, хотя это и не требуется, для отправителя данных лучше всего отправлять сообщение подтверждения приема после получения каждого сообщения изменений данных. Важно также заметить, что одно сообщение подтверждения приема может подтвердить прием всех сообщений изменений данных. Например, если реплика получит три сообщения изменений данных и произведет импорт каждой из них, то она сможет отослать одно сообщение подтверждения, чтобы подтвердить прием всех трех сообщений.
Ниже изображено то, как родительская реплика отсылает изменения дочерней реплике, а затем получает сообщение подтверждения приема от дочерней реплики. В данном случае родительская реплика является отправителем данных, а дочерняя – получателем данных.
В двунаправленных репликах, отправитель и получатель данных могут меняться ролями. Смена ролей осуществляется отправителем данных, когда он отсылает последнее сообщение изменений данных, которое включает в себя инструкции по смене ролей. Как только сообщение будет импортировано получателем данных, роли будут сменены, и система будет готова для отправки данных в противоположном направлении.
На расположенной ниже схеме показана родительская реплика, которая отсылает сообщение об изменении данных с инструкциями по переключению ролей. Когда родительская реплика произведет экспорт этого сообщения, она станет получателем данных. Когда дочерняя реплика получит это сообщение, она станет отправителем данных. После этого дочерняя реплика начнет отправление сообщений изменения данных родительской реплике.
Как отмечено ранее, двунаправленные реплики используют обмен данными и подтверждающими сообщениями, и могут меняться ролями. При однонаправленных репликах вы не можете переключить роли. Для однонаправленных, от родительской к дочерней, репликах, родительская реплика всегда является отправителем данных. Для однонаправленных, от дочерней к родительской, репликах, дочерняя реплика всегда является отправителем данных. В обоих случаях, для получателя данных важно послать подтверждающее сообщение. При работе с открепленными репликами дочерняя реплика всегда является отправителем данных, и производить отправку сообщений подтверждений не нужно. Для получения более подробной информации о типах реплик см. Типы репликации.
До сих пор, в этом разделе описывались простые процессы обмена сообщениями, в которых сообщения пересылаются в две стороны между родительской и дочерней репликами. Если вы продолжите работу по такой же схеме, то система будет функционировать нормально и даже будет сама устранять ошибки, если сообщения будут потеряны. Однако вам может потребоваться рассмотреть следующие специфические схемы обмена сообщениями.
Повторная отправка подтверждающего сообщения
Система также позволяет репликам отправлять неподтвержденные изменения данных повторно. Вам может понадобиться сделать это, когда вы будучи отправителем данных, будете знать или предполагать, что отосланное ранее сообщение изменений данных было утеряно и нуждается в повторном отправлении. Как альтернатива, вы можете ожидать момента следующей отправки изменений данных, поскольку по умолчанию это последующее сообщение будет включать в себя новые изменения данных и изменения данных всех неподтвержденных сообщений.
На следующей диаграмме изображен случай, в котором вам необходимо отослать неподтвержденное сообщение об изменении данных повторно. Родительская реплика отсылает сообщение изменений данных и переходит в режим получения данных. Сообщение, однако, было потеряно, и родительская и дочерняя реплики остались в состоянии получателей данных. Для разрешения этой проблемы для отправителя данных, который только что сменил роль, доступна опция повторного экспорта неподтвержденных сообщений. В этом случае родительская реплика может повторно отправить дочерней реплике сообщение для смены роли.
Изменения после переключения ролей
После смены ролей в двунаправленных репликах, для отправителя данных будет доступна опция экспорта сообщения о подтверждении приема. Эту опцию можно использовать для подтверждения приема сообщения, которое производит смену ролей. Другой опцией является отправка сообщения изменения данных, поскольку она в скрытой форме произведет подтверждение приема этого сообщения. Даже если вы не планируете отправку сообщения об изменении данных в ближайшем будущем, вы должны отправить подтверждающее сообщение.
На следующей диаграмме, родительская реплика отсылает сообщение об изменении данных, которое производит смену ролей. Когда дочерняя реплика получит это сообщение, она станет отправителем данным, но поскольку она только что переключилась, система все еще позволит ей отправить сообщение о подтверждении приема.
Переключение ролей без отправки изменений данных
Вы можете отправить сообщение изменений данных с инструкциями по смене ролей, которое не будет содержать изменений данных. Вам может понадобиться сделать так, что будучи получателем данных вам будет необходимо получить изменения от отправителя данных, но отправить свои изменения данных вы еще не готовы. Более подробную информацию об отправке сообщений для переключения ролей без отправки данных см. в разделе Экспорт сообщения об изменении данных.
Обход файла подтверждающих сообщений
При отправке изменений данных по умолчанию отсылаются все новые изменения в данных и все неподтвержденные изменения данных. Новыми изменениями считаются вставки, обновления и удаления, произведенные для версии реплики с момента последнего экспорта сообщения изменений данных. Неподтвержденные изменения данных включают в себя экспортированные ранее изменения, для которых вы не получили сообщение о подтверждении приема. Если вы отправите несколько сообщений об изменении данных, для которых вы не получили подтверждающего сообщения о приеме, то файлы изменений данных могут стать очень большими.
Лучше всего будет, если получатель данных отправит файл подтверждающего сообщение. Однако, в зависимости от системы связи, сделать это может оказаться возможно не всегда. Например, если реплики будут отключены и для отправки подтверждающего файла требуются средства доставки массовой информации для обмена файлами, вы можете предпочесть отправить письмо лицу, управляющему репликой-отправителем данных, о том, что вы получили и импортировали данные изменения.
Имейте в виду, однако, что в обход файла подтверждающего сообщения усложняет синхронизацию управления.
- Импорт сообщений подтверждений является для системы единственным способом удалить системные версии, которые необходимы для повторной отправки изменений для реплики. Эти системные версии могут со временем начать препятствовать выполнению полного сжатия и, потенциально, снизить производительность базы геоданных. По этой причине, все равно очень важно по крайней мере периодически использовать подтверждающие сообщения.
- Обход файла подтверждающего сообщения приводит к необходимости ручного вмешательства со стороны как лица, управляющего репликой-отправителем данных, так и лица, управляющего репликой-получателем данных.
Также можете использовать менеджер реплики для определения того, какие изменения были отправлены и получены репликой. Чтобы не отправлять без необходимости большие сообщения об изменении данных, отправитель должен выключить опцию Include unacknowledged data changes в следующий раз, когда он или она отправляет изменения данных.
- Когда вы обходите использование файла подтверждающих сообщений, ваш рабочий процесс синхронизации оказывается более склонным к ошибке.
Новые изменения могут быть импортированы получателем данных только в том случае, если предыдущие изменения были действительно импортированы. Если система обнаружит, что отосланные ранее изменения не были импортированы, то возвращается ошибка и текущий набор изменений не может быть импортирован. Если несколько сообщений изменений данных будут отосланы одновременно, то они должны быть импортированы в правильном порядке. Система вернет ошибку, если вы попытаетесь импортировать сообщения в неправильном порядке.
При возникновении ошибок выводятся сообщения об ошибках. Однако при использовании автоматизированной системы вы можете не увидеть этих ошибок. В этом случае вы можете воспользоваться журналом реплик, чтобы выявить наличие ошибок, возникших в ходе синхронизации. В журнале также имеются инструкции по восстановлению данных, когда это возможно.