Особливості безконфліктного гетерогенного тиражування між SQL Server 7.0 і Access 2000

При проектуванні розподіленої бази даних для роботи в
гетерогенному середовищі розробнику завжди доводиться вирішувати ряд важливих
завдань. Одна з них полягає в тому, щоб забезпечити мінімум
конфліктів при тиражуванні даних. При цьому, як правило,
табличну структуру серверної частини, а саме її шар посилальної
цілісності, завжди доводиться змінювати і доповнювати, щоб запис в
таблиці загальної бази даних можна було ідентифікувати однозначно.
Такі зміни в табличній структурі, як, наприклад, штучне
посилення первинних ключів, пізніше необхідно враховувати в
SQL-запити клієнтських додатків, що не завжди виправдано і, крім
того, несприятливо позначається на продуктивності і зручності
роботи з такою базою даних.

У той же час деякі системи баз даних, зокрема SQL
Server 7.0 і Access 2000, дозволяють за рахунок застосування полів типу
ROWGUIDCOL в якості первинних ключів однозначно ідентифікувати
будь-який запис в таблиці бази даних. Причому, що важливо,
незалежно від того, де були зроблені ці записи, тобто в межах
локальної мережі або віддаленими клієнтами.


Це природне посилення первинних ключів полями GUID
забезпечує безконфліктний тиражування розподіленої бази
даних.


Розглянемо на прикладі докладний рішення для SQL Server 7.0 і
Access 2000.


Припустимо, потрібно створити таку інформаційну систему, в
якої існує центральна загальна база даних, а її клієнтами
є філії, віддалені підрозділи або мобільні
користувачі. У першу чергу необхідно визначитися з клієнтською
платформою бази даних. З урахуванням простоти і зручності виберемо для
цієї мети Access 2000, оскільки процесор бази даних Jet ще
досить довго буде використовуватися в якості простого, зручного
і невибагливого клієнтського кошти, і тому репликационной
рішення на його базі актуально. Врахуємо, що в цьому випадку нам доведеться
задіяти гетерогенне тиражування даних.


Кількість клієнтів розподіленої бази даних, як правило,
необмежено, і, крім того, вони повинні діяти незалежно один
від одного, отже, ми будемо використовувати тиражування
злиттям (Merge) з підтримкою анонімних клієнтів центральної бази
даних.


Створивши табличну структуру свого рішення, підготуємо її для
застосування в розподіленому середовищі SQL Server 7.0.


Необхідно уточнити, як використовуються поля типу Currency в
табличних структурах баз даних, призначених для
тиражування.


Оскільки процес тиражування на клієнті відбувається з
застосуванням ODBC, клієнтські значення Currency полів можуть викликати
помилки тиражування, якщо на рівні операційної системи клієнта в
Як роздільник дробової частини використовується інше значення, ніж
«.» (Крапка). Це пов'язано з методом приведення типів в ODBC. Для
забезпечення цілісності відповідних полів таблиць бази даних
можна задіяти, наприклад, тип Float. Також при виборі довжини
символьних полів необхідно пам'ятати про те, що в Access 2000 вона
обмежена, і обов'язково враховувати це в табличній структурі
центральної БД.


Крім того, краще уникати застосування в табличній структурі
альтернативних ключів (Unique Indexes), так як вони можуть стати
явним джерелом конфліктів при конвергенції даних на сервері. Це
не відноситься до таблиць довідкового характеру, так як для
користувачів вони в нашому випадку все одно будуть доступні тільки для
читання. При явної необхідності задіяти альтернативні ключі
можна, наприклад, створювати ці ключі вручну на машині клієнта,
таким чином вони будуть існувати тільки у клієнтів, а не в загальній
базі даних сервера, і в межах кожного віддаленого підрозділу
повністю виконувати своє завдання.

Створення публікації

Отже, сформувавши на сервері табличну структуру бази даних,
приступаємо до створення публікації для неї. Перш за все, необхідно
дозволити тиражування для сервера і уточнити деякі
параметри.


По-перше, у властивостях видавця (Publisher) необхідно вказати
повний мережевий шлях для папки копій (Snapshot folder), наприклад
\ \ SERVER \ ReplData, замість зазначеного шляху за замовчуванням. ReplData –
це той каталог на жорсткому диску, з якого всі клієнти будуть
черпати інформацію для створення у себе реплік центральної бази
даних. Права доступу на використання цього каталогу встановлюють
таким чином, що група Administrators має повні права, а всі
інші – тільки на читання.


Крім того, в розділі Distributor при налаштуванні тиражування на
сервері в розділі Merge у властивостях Agent Profiles потрібно вибрати
пункт Slow link agent profile, так як підрозділи можуть бути
підключені через модем. І на завершення слід уточнити режим
ліцензування для SQL Server 7.0. У розглянутому прикладі це
буде Per Seat. Режим можна визначити, вибравши на сервері в панелі
управління значок Licensing.


Як вже говорилося вище, в процесі створення публікації був
вибрали тип Merge. Тип абонентів – Microsoft Access. Далі вибираємо
статті передплати (таблиці), залишаючи без зміни всі їхні властивості.
Призначивши ім'я публікації, переходимо до визначення фільтрів
тиражування, вказуючи можливість динамічної фільтрації. Для
автоматичної побудови необхідних у цьому випадку зв'язків можна
вибрати в якості базової таблицю з іменами всіх наших
підрозділів. У такій таблиці необхідно в запису поряд з полем з
ім'ям підрозділи мати і поле, в якому відображено ім'я комп'ютера
(Host Name), який буде підключений до центральної бази даних
сервера з боку клієнта. Також потрібно відзначити, що таблиця, по
якої «розшаровується» наша база даних, повинна бути як би
вершиною піраміди табличної структури і всі зв'язки від неї і до самих
нижніх таблиць в цій ієрархії повинні бути обов'язковими (атрибут для
Foreign Key полів NOT NULL). Припустимо, що ця таблиця називається
DIVISION, тоді критерієм для динамічної фільтрації буде:
DivHOSTNAME = HOST_NAME().


Після завершення процесу автоматичної побудови необхідних
для «розшарування» бази даних табличних зв'язків необхідно належним
чином скорегувати їх.


Але спершу потрібно переконатися, що тільки необхідні для
однозначного «розшарування» табличні відносини включені до списку
задіяних зв'язків (JOIN filter clause), і не більше того. Так,
наприклад, немає сенсу включати в цей список відносини від більшості
довідкових таблиць, так як вони не є визначальними при
логічному «розшаруванні» нашої центральної БД, тим більше, що їх
дані будуть потрібні для всіх підрозділів цілком і повністю.
Далі, вказавши можливість доступу до цієї публікації анонімних
клієнтів, завершимо процес створення публікації для центральної бази
даних. Щоб можна було використовувати створену публікацію в
Надалі, потрібно зберегти її у вигляді файлу сценарію, відкривши
властивості публікації на закладці Scripts.


При роботі з розподіленою базою даних всі наші підрозділи
будуть підключатися через один обліковий запис на сервері. Ця облікова
запис створюється з аутентифікацією на рівні SQL Server. Базою по
замовчуванням для неї стане тільки що сформована база даних, а
Server Role потрібно визначити як System Administrators. Базою, до
якої можна можна підключатися, буде та ж база даних, але з
роллю db_owner. Тепер, відкривши властивості створеної публікації,
слід переконатися, що з цим обліковим записом можна отримати доступ
до неї, переглянувши властивості в розділі Publication Access List.


Для продовження роботи потрібно перевести Snapshot Agent створеної
публікації в ручний режим. Для цього, відкривши властивості публікації,
звернемося до закладці Status і до властивостей самого агента, з яких
в розділі Schedules видалимо призначену до виконання завдання, так як
ми будемо завжди самостійно створювати робочий знімок (Snapshot)
для бази даних, і, значить, цим завданням можна знехтувати.


Тепер слід запустити вручну агента тиражування знімка
(Snapshot Agent) для створеної публікації. Після завершення роботи
агента потрібно звернутися до каталогу ReplData, в якому будуть
сформовані всі необхідні сценарії для створення клієнтських реплік
нашої бази даних.


Вся складність гетерогенного тиражування в SQL Server 7.0 при
використання полів ROWGUIDCOL в якості первинних ключів
полягає в тому, що, оперуючи тільки SQL-сценаріями, на клієнтах
неможливо створити репліку структури бази даних. Так, якщо в
Як клієнтська платформа використовується Access 2000, необхідно
безпосередньо встановлювати відповідні властивості полів
первинних ключів, наприклад за допомогою DAO (Jet)-викликів.


Для того щоб це завдання виконувала Access 2000, необхідно
виконати ряд дій. Для цього необхідно в каталозі ReplData
знайти всі файли *. SCH, що відповідають нашим таблиць, і скопіювати
їх до себе в робочий каталог на жорсткому диску. Потім потрібно відкрити
sysmergeschemachange з центральної бази даних і, звернувшись до
останній колонці schematext, подивитися, яка таблиця перших
з'являється серед DRI файлів (нехай це буде таблиця Assets). Тоді,
повертаючись до каталогу ReplData і знайшовши там файл Assets.DRI, копіюємо
його до себе на жорсткий диск до решти SCH-файлів. Тепер необхідно
з кожного SCH-файлу вирізати частину, яка створює первинний ключ, і
перенести її у вигляді закінченого SQL-вирази в Assets.DRI,
доповнюючи цей файл з початку, наприклад:

  ALTER TABLE [Sheriff] ADD
PRIMARY KEY NONCLUSTERED
(
[SheID]
)
GO

– Далі власний текст Assets.dri

Тепер ми маємо належним чином скориговані сценарії для
прозорого створення на клієнтських місцях таблиць з полями ROWGUIDCOL
в якості первинних ключів. Всі змінені SCH файли і Assets.DRI
можна переписати у каталог ReplData на сервері поверх оригіналів,
так як вони нам у своєму колишньому вигляді більше не потрібні. Якщо
знадобиться, їх завжди можна створити заново, запустивши в будь-який час
Snapshot Agent вручну для публікації.


Оскільки з центральною базою буде працювати кілька
підрозділів, потрібно забезпечити їм можливість одночасної роботи.
Для цього необхідно виправити неточність в алгоритмі однією з
збережених процедур на сервері, а саме
sp_MSadd_merge_anonymous_agent. Її можна знайти в Distribution базі
даних сервера.


У цьому місці відбувається перевірка на відповідність вже створеного
агента злиття Merge Agent клієнту, який підключається при
черговому сеансі. Здійснюється в цьому випадку SELECT не зможе
відрізнити нового анонімного клієнта від того, яким був
спочатку створений поточний агент, і в результаті замість додавання
нового агента Merge Agent, відповідного конкретному клієнтові,
користувач завжди буде отримувати повідомлення: «Another merge agent
for the subscription(s) is running».


Для коригування цієї неточності в алгоритмі роботи зберігається
процедури потрібно додати ще один критерій для даного SELECT, а
саме subscriber_name = @ subscriber_name, тобто якраз той
параметр, за яким власне і відрізняються один від одного всі
анонімні клієнти в режимі MERGE.


Тепер можна не сумніватися, що кожному клієнту системою буде
призначений свій агент злиття Merge Agent, і всі підрозділи зможуть
працювати паралельно, незалежно один від одного.


Після такого коригування дана системна збережена процедура
буде мати тип User. Для повернення їй типу System слід
виконати:

  exec dbo.sp_MS_marksystemobject
sp_MSadd_merge_anonymous_agent.

Довідкові таблиці

У структурі бази даних, як правило, присутні довідкові
таблиці, і необхідно подбати про захист їх даних від
несанкціонованих змін на клієнтських місцях. Для цього потрібно
скористатися властивістю баз даних Access, що дозволяє працювати
різним користувачам з однією базою даних.


Нам необхідно створити файл робочої групи, в якому
був би присутній користувач із групи Admins (в Access 2000), з
такими ж атрибутами (ім'я і пароль), які були задані для облікового
запису на сервері для роботи з розподіленою базою даних наших
підрозділів. Для цього слід сформувати нову порожню базу
даних Access 2000. Відкриємо її і за допомогою майстра захисту створимо
файл робочої групи. Тепер потрібно пройти всі кроки майстра до «…
додавання користувачів … »без внесення змін, а на цьому етапі
додати ім'я і пароль нашого спеціального користувача з такими ж
атрибутами, як і в облікового запису на сервері центральної бази
даних. Пройшовши всі інші кроки без зміни, завершимо процес
створення файлу робочої групи. Отриманий файл робочої групи
Secured.mdw необхідно перейменувати на system.mdb, для подальшого
програмного використання. Крім того, на етапі створення клієнтської
репліки центральної бази даних цей файл повинен розташовуватися в тому
ж каталозі, що і сама база даних клієнта. Маючи такий файл на
етапі початкового створення репліки загальної бази даних, можна
буде програмно встановити необхідні права для всіх довідкових
таблиць. Так як стандартний користувач Admin в базах даних Access
включено до групи Users, при звичайному відкритті нашої клієнтської
репліки загальної бази даних будуть доступні тільки ті операції з базою
і таблицями, які ми надалі визначимо програмно. Тепер
неможливо буде що-небудь несанкціоновано змінити: ні в
структурі бази, ні в довідкових таблицях, ні в правах доступу, так
як база буде повністю належати тільки користувачеві з нашою
обліковим записом. Звичайний клієнт зможе проводити операції вставки,
зміни, видалення тільки з певними таблицями, які будуть
задані програмним способом.


На закінчення слід додати, що після установки пакету
виправлень Service Pack 2 для SQL Server 7.0, щоб уникнути помилок
при створенні первинних клієнтських реплік центральної бази
даних (неповному копіюванні даних з сервера), для клієнтської
сторони варто залишати файли від попередньої версії, від Service
Pack 1, а саме:

  SQLMERGX.DLL
REPLPROV.DLL
REPLREC.DLL
REPLRES.DLL
MSRPJT40.DLL

Це ніяк не вплине на зміни, зроблені на сервері після
установки Service Pack 2, і логіку його роботи в процесі
тиражування даних, але дасть можливість нормально ініціалізувати
локальні бази даних клієнтів. Заміну файлів можна застосовувати тільки
для початкового створення клієнтських реплік центральної бази
даних, а в подальшому при завантаженні і вивантаженні даних можна
використовувати оригінальні файли від Service Pack 2.


Крім того, в тому випадку, якщо необхідно мати доступ до
центральній базі не тільки з боку віддалених клієнтів, а й
локально, наприклад з відділів центрального офісу, то слід
утриматися від вчинення прямих транзакцій з опублікованою для
тиражування центральною базою даних. У такому випадку має сенс
представити центральний офіс як клієнта опублікованій бази. Це
буде вже підписка в режимі оповіщення (Push subscription)
однотипної бази SQL Server 7.0.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*