Знімки бази даних SQL Server для тестування інтеграції

Я намагаюся визначити спосіб роботи з тестовою базою даних (на SQL Server) для нашого інтеграційного тестування.

Моя ідея полягала в тому, щоб зробити наступні кроки при запуску збірки тестових інтеграцій:

• створити абсолютно порожню базу даних
• запустіть сценарій "створити об'єкти бази даних", щоб створити всі відповідні об'єкти бази даних (таблиця, представлення, послідовності тощо)
• заповнити "базові дані" (значення пошуку тощо)
• зробіть знімок бази даних, який називається (db)_Basis"базовою лінією" для майбутніх тестів на інтеграцію

Тепер перед кожним тестовим класом (що містить 1-n тестів) я планував просто зробити "відновлення з огляду", щоб повернутися до чітко визначеного, більш-менш "порожнього" стану бази даних. Поки що працює як шарм.

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

• відновити базу даних зі (db)_Basisзнімка
• вставити ці 50 000 + рядків даних у базу даних
• створити ще один знімок (db)_With_Testdataзнімка

а потім для кожного тесту перевстановіть базу даних до чітко визначеної (db)_With_Testdataверсії знімка, запустіть тести, перевірте результат тощо.

Проблема полягає в тому, що я не можу одночасно мати два db-знімки - як тільки я це зробити, я не можу відновити свою базу даних ні для одного з них .... Я постійно отримую цю помилку:

Повідомлення 3137, рівень 16, стан 4, рядок 9
не можна повернути. Або основні, або імена знімків неправильно вказані, всі інші знімки не були скинуті або відсутні файли.

Повідомлення 3013, рівень 16, стан 1, рядок 9
ПОНЯТТЯ ДАТАБАЗА закінчується аномально.

Це справді, як працюють знімки бази даних SQL Server ?? Здається, жахливо обмежує ..... Я б зрозумів, якби я не міг повернутися безпосередньо до оригінального знімка "(db) _Basis" - але тільки тому, що зараз у мене є два знімки, я не можу навіть повернутися до останнього ?!?!?

На жаль, це за дизайном.

Зі сторінки зі сторінки BOL " Повернення бази даних до знімка бази даних ":

Обмеження та обмеження

Повернення не підтримується за таких умов:

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

Як альтернативу, ви можете скинути перший знімок (db)_Basis. Я можу зрозуміти, що це здається дуже обмежуючим, але дивіться на це таким чином: знімки - це розріджені файли, засновані на оригінальних файлах даних, тому повернення до конкретного знімка в будь-якому разі знецінить усі знімки (в основному файли даних будуть змінені операцією відновлення) . Обмеження може дратувати, але не виглядає необгрунтованим.

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

Крім того, лише вставляючи 50K рядків, база даних не буде такою великою. Якщо ви використовуєте стиснення, розмір резервного копіювання також буде меншим.

Ви можете мати завдання TSQL Agent або просто сценарії (можливо, ви можете створити збережену процедуру та просто викликати її після тестів на основі отриманого результату).

• Резервне копіювання бази - (db)_Basis
• З резервним копією тестових даних - (db)_With_Testdata

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

Я вважаю, що метод резервного копіювання / відновлення є дуже елегантним у вашому сценарії, оскільки ви впливаєте на обмеження знімків даних бази даних . Також Пол Рандал веде блог про неприємну помилку у всіх версіях до та включаючи SQL Server 2012 (не впевнений, що вона виправлена ​​в більш пізньому МС)

Коли ви повертаєтесь до знімка бази даних, файл журналу транзакцій вихідної бази даних видобувається та замінюється файлом журналу 0,5 МБ з двома VLF 0,25 МБ.