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

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

*

*