Comments 10
Здравствуйте!
Подскажите, пожалуйста, а насколько применимы вышеописанные оптимизации к Azure SQL Server?
Мы на работе используем CI и клонируем базу с продакшена для прогонки интеграционных тестов. Возможен ли выигрыш в скорости, если вместо клонирования мы будем копировать туда данные?
Я сам не очень разбираюсь в SQL, так что прошу прощения если вопрос глупый
применимы вышеописанные оптимизации к Azure SQL Server?

Azure SQL Database поддерживает возможность включения Delayed Durability (хотя SSMS в свойствах базы соответствующей опции не показывает)

если вместо клонирования мы будем копировать туда данные?

Сложно ответить на Ваш вопрос не зная специфики проекта и то как разворачивается тестовое окружение. Если уточните вопрос, то буду рад помочь.
Мне тесты достались тоже с кучей DELETE. После каждого TestCase данные удалялись «вручную». от этого все тесты рано или поздно ломались, если кто-то не все удалял за собой. Потому я переделал все на rollback до save point-а, до которого создавались таблички и минимальные данные.

А после того как поменял у себя в проекте DB2 на HSQLDB — юниттесты работающие с базой (в проекте каша с доступом к базе) ускорились с пары часов до 3 минут. Создание базы и наполнение данными происходит за секунду. Пришлось конечно SQL запросы, которые использовали DB2 фишки переписать на стандартный SQL понятный HSQLDB. Что не получилось переписать, я правлю в своем JDBC драйвере (к примеру заменяю «for update rs lock» на просто " for update").

Зато теперь юниттесты можно прогнать перед коммитом и убедиться, что ничего не поломалось. А не через пару часов после коммита, когда уже другими делами занялся.
По первой части — а не проще было сделать снапшот БД и после прогона тестов откатываться к снапшоту вместо ручной зачистки и сброса IDENTITY? Вроде бы снапшот для таких целей и был создан. Правда, у него есть существенный недостаток — требует Enterprise Edition, ну или Developer Edition, что в данном кейсе должно подойти — насколько я понял, тесты запускаются на машинах разработчиков.
Такой вариант уже рассматривали. К слову он лучше на порядок, но сейчас все на Express работает и этого вполне хватает. В планах миграция, когда пользователей TMetric больше станет.
Можно уже сейчас реализовать с проверкой доступности фичи — если доступна — использовать ее, если нет — старый способ :)
Хммм, я думал SSD на компах разработчиков это уже несколько лет как стандарт индустрии.
тупо переход на SSD ускорит WRITELOG примерно в 2 раза, так как характер записи последовательный. А автор ускорил тесты в 4 раза.
Может кому прингодится.

Я у себя реализовал тестирование для MSSQL варианта след. образом:

* На тестовых Агентах стоит RAM Drive от ImDisk (2GB).
* Используется вариант LOCALDB, просто создается база на RAM драйве и заливаются исходные данные.
* Перед каждым тестом стартует транзакция (наш слой доступа к DB при етом не позволит сделать в теле теста Commit или Rollback)
* После теста делается Rollback.
Only those users with full accounts are able to leave comments. Log in, please.