Документація

Огляд

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

Заснований на завданнях

AutosyncDB заснований на завданнях. Будь-які маніпуляції з базою даних можуть виконуватись тільки в рамках завдання. Саме ж завдання є декомпозицію задачі оновлення бази даних, де кожен крок можна налаштовувати. У застосунку документ типу Завдання представлений у вигляді дерева налаштувань. На малюнках нижче показані функціональна схема завдання і дерево налаштувань завдання.

SQL Server порівняння і синхронізація схем баз даних. Функціональна схема  MS SQL порівняння і синхронізація схем баз даних. Завдання

Проектно-орієнтований

AutosyncDB має нестандартну проектну архітектуру, в якій завдання виконують роль проекту. Самий же файл проекту містить значення налаштувань завдання за замовчуванням. Ви можете створити кілька завдань для проекту і зберегти будь-яке з них як цей проект або як новий. У кожного завдання є своя копія налаштувань проекту. Вони не перетинаються, але всі посилаються на одну і ту саму теку проекту. Ще в проекті передбачена тека виведення з вкладеними теками для результатів. Кожна така під-тека називається ім'ям свого завдання, тому вони також не перетинаються, але імена завдань повинні бути унікальними в рамках проекту.

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

На малюнках нижче показаний приклад двох проектів в одній теці Project1 з п'ятьма відкритими завданнями і теками результатів, два для Project1-config1 і три для Project1-config2.

Приклад структури тек проекту AutosyncDB  Приклад панелі подання проектів в AutosyncDB

Порівняння і синхронізація схем баз даних

Порівняння і синхронізація налаштовуються шляхом зазначення дій, таких як Створювати, Змінювати, Перестворювати, Видаляти, які дозволено виконувати з об'єктами певної категорії, а також інших параметрів. Ці налаштування використовуються алгоритмом порівняння для порівняння схем баз даних і побудови протоколу синхронізації разом з моделлю відмінностей. Якщо для усунення відмінностей над об'єктом потрібно виконати якусь дію, і ця дія дозволена для категорії об'єкта, – то вона буде йому встановлена. AutosyncDB повідомляє про відмінності для кожного об'єкта в контексті цих дій, разом з результатом порівняння і причиною для першої дії.

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

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

На основі протоколу синхронізації і моделі відмінностей AutosyncDB будує звіти: дерево відмінностей, як складений список об'єктів обох баз даних в контексті дій і результатів їх порівняння; звіт в форматі Excel, що представляє собою протокол синхронізації; SQL-скрипт синхронізації для цільової бази даних як свого роду звіт, заснований на протоколі синхронізації та даних про залежності об'єктів.

На малюнках нижче показані дві панелі Відмінностей. Перша для завдання, налаштованого на синхронізацію схем баз даних, а друга – на порівняння. Завдання синхронізації передбачало видалення об'єктів відсутніх в шаблонній базі даних, але дозволяло вирішувати залежності та конфлікти. Замість цього в завданні порівняння були дозволені всі дії, окрім групових (Перестворити Всі, Видаляти дублікати), але залежності і конфлікти не вирішувалися.

Панелі Відмінностей для завдань синхронізації та порівняння
SQL Server синхронізувати структури даних. Панель Відмінностей завдання синхронізації  SQL Server порівняти структури даних. Панель Відмінностей завдання порівняння

Як видно з малюнків, завдання синхронізації не встановило жодних дій для таблиць і збережених процедур, відсутніх в цільовій базі даних, але встановило дію Перестворити для деяких ідентичних ключів, обмежень та індексів таблиць, а також тригерів подань, батьківські об'єкти яких повинні бути перестворені. Замість цього завдання порівняння просто повідомило про всі відмінності. Дія Створити говорить нам, що об'єкт відсутній в цільової базі даних, дія Видалити, – що в шаблонній, дії Змінити або Перестворити вказують на те, що об'єкти відрізняються, а знак рівності, – що вони ідентичні.

На відміну від алгоритму порівняння, оболонка застосунку розпізнає типи завдань, але робить це для того, щоб показати, чи налаштоване завдання для зміни цільової бази даних, чи ні, і якщо так, то як саме. AutosyncDB позначає завдання як завдання синхронізації, якщо кінцевий скрипт синхронізації налаштований на виконання в кінці завдання. Якщо підготовчий скрипт налаштований на виконання перед порівнянням, а кінцевий скрипт синхронізації не налаштований, то завдання розглядається як завдання оновлення. В іншому випадку – це завдання порівняння. Ви можете знайти відповідну підказку для поточного завдання в рядку стану.

Можливості з порівняння та синхронізації схем баз даних

AutosyncDB працює з базами даних онлайн та файлами. Він використовує подання каталогу sys. для завантаження і кешування структури баз даних при кожному запуску завдання.

AutosyncDB крос-серверний і крос-версійний. Наприклад, ви можете синхронізувати структуру бази даних на SQL Server 2005 зі структурою бази даних на SQL Server 2022 або навпаки. Звичайно, якщо ви використовуєте якийсь новий функціонал, який не підтримується в 2005-му, то отримаєте відповідні помилки від ядра SQL під час виконання скрипта.

AutosyncDB завжди порівнює імена сутностей бази даних відповідно до COLLATION, а ось порівняння тіла об'єктів і обчислюваних виразів можна доналаштовувати. Якщо встановлена опція Змінювати COLLATION бази даних, то алгоритм порівняння буде використовувати параметри порівняння шаблонної бази даних, в іншому випадку – цільової.

Застосунок забезпечує підтримку порівняння і синхронізації не тільки об'єктів бази даних, але і їх різних параметрів, таких як наприклад ANSI_NULLS, ANSI_PADDING, DATA_COMPRESSION, ONLINE, PAD_INDEX, IGNORE_DUP_KEY, STATISTICS_INCREMENTAL, ALLOW_ROW_LOCKS, ALLOW_PAGE_LOCKS, BUCKET_COUNT та багатьох інших. Залежно від конфігурації завдання, їх значення можуть бути як успадковані від значень в цільовій базі даних, так і змінені на значення з шаблонної. У багатьох випадках необхідність такої зміни може навіть привести до необхідності перестворення самих об'єктів, з чим застосунок також успішно справляється.

Зверніться до інструкції по дереву налаштувань завдання в меню сторінки, щоб дізнатися більше про наявні можливості порівняння і синхронізації баз даних.

Показати відмінності об'єктів між двома схемами

AutosyncDB має вбудовану підтримку візуалізації відмінностей об'єктів після порівняння. Вона доступна по кожному об'єкту через панель Відмінності. Також через неї можна переглянути і скрипт синхронізації об'єкта, якщо такий був потрібен.

На малюнку нижче показані відмінності між схемами таблиць dbo.SYS2. Цей результат був узятий з наведеного вище прикладу з двома завданнями, а саме для завдання синхронізації. Алгоритм порівняння з'ясував, що таблиця була змінена, і дія Перестворити необхідна для приведення у відповідність порядку слідування стовпця IdExt. Також потрібно додати стовпець PasswordHash. Примітно, що якби для завдання не було встановлено опцію Таблиці \ Послідовність стовпців, то таблицю можна було б змінити, просто використовуючи оператор ALTER, без необхідності в перестворенні.

Приклад документа Відмінностей об'єктів
Показати відмінності об'єктів між двома схемами SQL Server

Перенести дані

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

Застосунок використовує XML-файл певного формату для перерахування таких таблиць і опису правил по ним. На основі цих правил кожен раз при виконанні завдання створюється скрипт злиття даних. AutosyncDB дозволяє працювати з усім набором або тільки з підмножиною даних в таблиці, виключати певні стовпці, визначати умови для вибірки даних, порівняння, додавання, зміни і видалення, переносити або не переносити значення IDENTITY, відключати тригери і обмеження зовнішнього ключа, відображати статистику.

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

Приклад файлу, що описує перенесення даних
<?xml version="1.0" encoding="utf-8"?>
<root>

	<!-- Просто додати рядки, яких немає в шаблоні -->
	<merge schema="dbo" name="UserAuthMethods" />

	<!-- Зробити дані однаковими, не переносити значення IDENTITY, відключати тригери, порівнювати по CatId -->
	<merge schema="SalesDept" name="PropertyCategories" upd="1" del="1" tgoff="1" iioff="1" mcond="t.CatId = s.CatId" />

	<!-- Синхронізувати об'єкти застосунку, але тільки зазначені стовпці, не чіпати об'єкти, що визначені користувачем,
		змінювати все без розбору (не порівнювати значення всіх змінюваних стовпців в умові інструкції update) -->
	<merge schema="app" name="main_factory_objects" upd="1" del="1"
		cols="[path], is_app_shipped, [class], name, [content]"
		scond="ISNULL(is_app_shipped,0) = 1"
		dcond="ISNULL(t.is_app_shipped,0) = 1"
		ucond="--"
	/>

</root>

Технологія підтримує всі вбудовані типи даних, а також типи даних, визначені користувачем, включно з CLR. Вміє обробляти деякі баги з типом даних xml, вміє застосовувати OPENQUERY для роботи з таблицями в пам'яті і пов'язаними серверами.

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

Експорт структури бази даних в файл

AutosyncDB реалізує власний стислий формат файлу .audbs для зберігання структури бази даних і даних для перенесення. Немає ніякої різниці між експортом цільової або шаблонної бази даних. Сам експорт виконується як завдання по команді.

Всі об'єкти і сутності бази даних експортуються в файл незалежно від налаштувань завдання, за винятком налаштувань Безпека і Дозволи, а також Перенести данні. AutosyncDB експортує тільки вибрані об'єкти безпеки і дозволів. Якщо перенесення даних налаштовано, то вони також будуть експортовані разом з файлом опису перенесення даних. Цей файл буде використовуватися замість файлу опису в завданні, якщо експортований файл структури бази даних використовувати в якості шаблонної бази даних. Це пов'язано з тим, що самі експортовані дані та їх склад тісно пов'язані з правилами їх злиття, тому ні дані, ні правила не можна змінювати після експорту.

Не використовуйте файли структури бази даних і файли пакетів в якості єдиної копії структури і даних для перенесення в архіві версій. Завжди майте резервну копію самої бази даних і/або SQL-скрипти (DDL) для її створення.

Створення пакета оновлення бази даних

Будь-яке завдання можна експортувати в файл пакета, який AutosyncDB може запускати в режимі Майстра пакетів або в фоновому режимі. Крім того, файл пакета можна експортувати назад як проект. Для цих цілей AutosyncDB реалізує формат файлу .audbp, який є розширеною версією .audbs. Сама ж збірка пакета виконується як завдання по команді.

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

Дерево налаштувань завдання має вузол Інформація про пакет з добре відомими назвами полів для опису створюваного пакета. Їх значення будуть показані в формі майстра при відкритті пакета.

Коли AutosyncDB отримує запит на відкриття файлу пакета, він спочатку розпаковує його в тимчасову теку, а потім відкриває звідти як проект. Як видно з малюнка нижче, кінцевий користувач може швидко змінити найбільш важливі для нього налаштування завдання, не вдаючись при цьому в деталі.

Приклад Майстра пакетів оновлення бази даних
Майстер розгортання змін бази даних SQL Server

Затвердження цільової бази даних

Основна мета даного налаштування – це запобігти виконанню завдання на помилковій базі даних, яка, наприклад, належить іншому продукту, або має іншу конфігурацію, версію, не відповідає деяким внутрішнім вимогам і т.п. В основному воно використовується в пакетах оновлень для перевірки цільової бази даних, вибраної користувачем. Перевірка виконується спеціальним скриптом, який повідомляє результат в таблицю #autosyncdb_target_approval. Цей скрипт також додається на початку скрипта синхронізації.

Приклад скрипта затвердження цільової бази даних
BEGIN TRY
	-- Схожа на нашу? Перевіримо деякі основні об'єкти
	IF OBJECT_ID(N'[dbo].[SYS2]', 'U') IS NULL OR OBJECT_ID(N'[dbo].[Schemas]', 'U') IS NULL OR OBJECT_ID(N'[dbo].[SYS_KernelVersion]', 'U') IS NULL
		INSERT INTO #autosyncdb_target_approval(result_code) SELECT 2;

	-- Це та конфігурація? Перевіримо деякі характерні для неї об'єкти
	ELSE IF OBJECT_ID(N'[dbo].[DOC310]', 'U') IS NULL
		INSERT INTO #autosyncdb_target_approval(result_code) SELECT 3;

	-- Версія має бути більшою або рівна 4.58
	ELSE IF CONVERT(hierarchyid, '/' + ISNULL((SELECT TOP 1 VersionString FROM [dbo].[SYS_KernelVersion] WITH(NOLOCK)), '') + '/') < CONVERT(hierarchyid, '/4.58/')
		INSERT INTO #autosyncdb_target_approval(result_code) SELECT 4;

	-- Версія має бути меншою за 4.61
	ELSE IF CONVERT(hierarchyid, '/' + ISNULL((SELECT TOP 1 VersionString FROM [dbo].[SYS_KernelVersion] WITH(NOLOCK)), '') + '/') >= CONVERT(hierarchyid, '/4.61/')
		INSERT INTO #autosyncdb_target_approval(result_code, result_code_desc) SELECT 5, 'The target database should be version 4.58 till 4.60 for this update.';

	-- Припустимо, що наявність стовпчика Name говорить нам про деякі скрипти, яким слід було бути виконаним раніше
	ELSE IF NOT EXISTS(SELECT TOP 1 1 FROM sys.columns WHERE object_id = OBJECT_ID(N'[dbo].[DOC310]', 'U') AND name = N'name')
		INSERT INTO #autosyncdb_target_approval(result_code) SELECT 6;

	-- Успішно, можемо виконувати завдання
	ELSE
		INSERT INTO #autosyncdb_target_approval(result_code) SELECT 0;

END TRY BEGIN CATCH
	-- Щось пішло не так
	INSERT INTO #autosyncdb_target_approval(result_code) SELECT 1;
END CATCH;

Сумісність

AutosyncDB сумісний з SQL Server 2005 по 2022 і підтримує всі найбільш часто використовувані функціональні можливості. Генерація коду спроектована таким чином, щоб кінцевий SQL-скрипт був сумісним з наймолодшою ​​підтримуваною версією – 2005. У деяких випадках генератор може перевіряти версію сервера цільової бази даних, для створення більш ефективного скрипта.

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

Зверніться до розділу налаштувань Тестувати на сумісність тут Порівняння схем двох баз даних SQL Server і тут Сумісність, щоб дізнатися більше.

Інтеграція

AutosyncDB забезпечує підтримку всіх типів завдань через інтерфейс командного рядка, причому як для проектів у теках, так і для пакетів оновлень. Це дозволяє автоматизувати не тільки порівняння і синхронізацію баз даних, але і процес збірки пакетів. AutosyncDB може бути запущений в звичайному режимі як додаток MDI, в діалоговому режимі як Майстер пакетів, або у фоновому режимі з або без взаємодії з користувачем. Діалоговий і фоновий режими – це однозадачні режими, в яких код, що повертається процесом в систему, повідомляє про результат виконання завдання. Для більш глибокої інтеграції також існує інтерфейс на основі віконної процедури, який реалізує міжпроцесну взаємодію між верхнім вікном клієнтського застосунку та процесом завдання.