Хранение некоторых данных SQL Server Offline

Question

Я начинаю разрабатывать новую систему управления данными лабораторных испытаний со многими (около 30) тестовыми станциями.

Система должна иметь возможность собирать данные в автономном режиме в случае сбоя сети.

Каждая станция будет хранить обновленную копию только для чтения тестовых структур (спецификации, типы объектов, бизнес-правила/рабочие процессы и т. Д.), Но не тестовые данные. Фактические данные теста будут храниться локально, если сервер не может быть найден.

Для подготовки к сбою в сети может потребоваться какая-то синхронизация. Синхронизация приведет к обновлению тестовых структур. Другая синхронизация будет вызывать несохраненные тестовые данные.

Как вы рекомендуете мне это достичь? Какие-либо оговорки?

Идеи/Мысли:

1. Установка сервера SQL на каждом компьютере и писать сценарии для синхронизации сервера и клиентов (кажется дорогим и излишним).
2. Сохраните локальную копию данных в определенных файлах необработанных данных приложения с помощью сценариев синхронизации.
3. Есть ли что-нибудь встроенное в SQL Server, чтобы клиенты могли собирать данные в автономном режиме?
4. Сохраните все данные локально, затем нажмите кнопку «Передача», чтобы отправить данные в сеть.

среда: MS SQL Server работает на Windows Server 2008

Answer 1

Используйте локальные экземпляры SQL Express и введите данные через Service Broker. См. High Volume Contiguos Real Time Audit and ETL для объяснения, почему это лучше, чем репликация с нескольких точек зрения, включая цену, производительность и надежность.

С репликацией вам потребуется более высокая лицензия, чем SQL Express, на всех периферийных узлах (поскольку Express может быть только подписчиком в топологии репликации). Использование SSB для push-данных позволяет экземплярам SQL Express на периферии и требует только центрального не-экспресс-лицензированного сервера. Это означает, что вы можете легко развернуть решение на десятках рабочих станций, не опасаясь затрат на лицензирование SQL Server.

Другим преимуществом является производительность и пропускная способность. SSB был разработан для обработки сотен и тысяч сверстников в коммуникациях и был разработан с использованием сложного иерархического управления потоком, который способен обрабатывать повторные попытки для тысяч пунктов назначения при наличии сбоев сети (я знаю все это, потому что я был членом SSB команда). Репликация путем сравнения использует протокол TDS для обмена данными, он опирается на задания агента SQL и упрощает работу с отключением сети, что может привести к тому, что многие циклы будут сжигаться при повторных попытках, что ухудшит ситуацию, когда они уже плохие. В целом, SSB может обрабатывать большие развертывания (я знаю о развертываниях серверов +1500, а MySpace опубликовал их deployment of +500 servers, которые полагаются на SSB для обмена данными. В целом, в больших масштабах SSB превосходит репликацию по любой мере.

Я также хотел бы утверждать, что решение, основанное на обмене сообщениями, а не на копировании строк таблицы, более подходит для описания проблемы: нажмите результаты на центральный сервер.

Одна обратная сторона (и не является второстепенной) - это крутая кривая обучения, необходимая для развертывания SSB изначально. Ноу-хау есть, но найти сложно, и SSB не хватает отполированных инструментов, таких как Replication Monitor, которые делают развертывание простой топологии репликации прямолинейной. С другой стороны, SSB имеет большое преимущество при обновлении развертываний, как 2005/2008/2008R2 versions are perfectly compatible.

Answer 2

Моя первая мысль была бы merge replication с местными (SQL Server Compact) копии базы данных.

Answer 3

Похоже, репликация SQL Server - это решение, которое вы хотите проверить. Репликация слияния позволит местным тестовым станциям получать копию данных с сервера и отправлять обратно данные, собранные во время сбоев сети.