На жаль, я не знаю прямого способу зменшити рівень БД з формату 2008 року до 2005 року.
Так, як я це робив у минулому (насправді зі старими версіями SQL-сервера, але процес буде таким же):
- Відновіть БД на екземплярі SQL2008, якщо цього ще не зроблено
- Створіть порожній БД з правильними структурами (таблиці, індекси, обмеження, представлення даних, програми, тригери, ...) на екземплярі SQL2005. Сподіваємось, ви можете це зробити з вашої існуючої процедури збирання та / або вихідного коду, але якщо ні, ви можете використовувати диспетчер SQL Server для створення сценаріїв для всього в БД 2005 року та запускати результат на порожньому в екземплярі 2008 року.
- Переконайтесь, що два екземпляри можуть бачити один одного (тобто немає брандмауерів, що блокують з'єднання, якщо екземпляри знаходяться на різних машинах) та зв’язувати їх за допомогою sp_addlinkedserver .
- Скопіюйте всі дані з однієї БД в іншу. Якщо в тригерах немає жодних обмежень для сторонніх ключів та подібних проблем, можна просто зв’язати БД разом із курсором через список таблиць (вибравши їх із sys.objects) та запустивши
INSERT destinationserver.destinationdb.schema.table SELECT * FROM sourcedb.schema.table
(або INSERT schema.table SELECT * FROM sourceserver.sourcedb.schema.tableякщо ви зв'язали екземпляри навпаки )
для кожної таблиці. Якщо у вас є обмеження та тригери, що забезпечують узгодженість між таблицями, вам, звичайно, потрібно бути трохи розумнішими щодо впорядкування цих операцій, особливо якщо у вас є циклічні обмеження, як таблиця з обмеженням, заснованим на собі (одна ієрархія тримання дані, як можливий приклад).
Можливо, буде ефективніше просто скопіювати дані спочатку та додати всю іншу структуру (індекси, прокси, тригери, ...) після кроку 3. Це дозволяє уникнути проблем упорядкування рядків, що виникають через обмеження та тригери, та побудови індексів у Кінець теоретично повинен бути швидшим, ніж збирати їх, оскільки всі дані додаються - хоча якщо у вас є кластеризовані індекси на ваших таблицях, створіть їх перед додаванням даних, оскільки їх було б не швидше створити після факту.
Звичайно, все це передбачає, що жоден з ваших об'єктів не використовує специфічні функції SQL 2008 - якщо вони є, ви, сподіваємось, з’ясуєте та виправите такі речі, коли помилки під час відновлення схеми. Якщо будь-який ваш код покладається на офіційно не визначену поведінку, яка, можливо, варіюється між версіями SQL Server, у вас можуть з’явитися деякі набагато більш тонкі і невловимі помилки, щоб пізніше відшукати і випрасувати.