Да, я знаю. Существование действующей копии SQL Server 6.5в 2008 году абсурдно.
Это предусмотрено, что это лучший способ перейти от 6.5к 2005? Есть ли прямой путь? Большая часть документации, которую я нашел, касается обновления 6.5до 7.
Должен ли я забыть о собственных SQL Serverутилитах обновления, написать сценарий для всех объектов и данных и попытаться воссоздать заново?
Я собирался попробовать обновление в эти выходные, но проблемы с сервером отодвинули его до следующего. Таким образом, любые идеи будут приветствоваться в течение недели.
Обновить. Вот как я это сделал:
- Резервное копирование базы данных и мастер на
6.5. - Execute
SQL Server 2000'sinstcat.sqlпротив6.5хозяина. Это позволяетSQL Server 2000поставщику OLEDB подключаться к6.5. - Используйте
SQL Server 2000автономно"Import and Export Data"для создания пакета DTS, используяOLEDBдля подключения к 6.5. Это успешно скопировало все6.5таблицы в новую2005базу данных (также используяOLEDB). - Используйте
6.5Enterprise Manager, чтобы записать все индексы базы данных и триггеры в файл .sql. - Запустите этот файл .sql для новой копии базы данных в Management Studio 2005.
- Используйте 6.5 Enterprise Manager для создания сценариев всех хранимых процедур.
- Запустите этот
.sqlфайл для2005базы данных. У нескольких десятков спроков были проблемы, делающие их несовместимыми2005. В основномnon-ANSI joinsиquoted identifier issues. - Исправил все эти проблемы и заново запустил
.sqlфайл. - Воссоздал входы в
6.5систему2005и дал им соответствующие разрешения.
При исправлении хранимых процедур было немного промыть / повторить (их было сотни), но в противном случае обновление прошло отлично.
Будучи в состоянии использовать Management Studio вместо Query Analyzerи Enterprise Manager 6.5такое удивительное различие. Несколько запросов отчета, которые занимали 20-30 секунд 6.5 database, теперь выполняются за 1-2 секунды, без каких-либо изменений, новых индексов или чего-либо еще. Я не ожидал такого немедленного улучшения.
Эй, я все еще застрял в этом лагере. Стороннее приложение, которое мы должны поддерживать, НАКОНЕЦ, перейдет на 2K5, так что мы почти ушли. Но я чувствую твою боль 8 ^ D
Тем не менее, из всего, что я услышал от нашего администратора баз данных, ключ заключается в том, чтобы сначала преобразовать базу данных в формат 8.0, а затем перейти к 2005 году. Я считаю, что для этого они использовали встроенные инструменты миграции / обновления. Есть некоторые большие шаги между 6,5 и 8,0, которые лучше решаются там, чем переход от 6,5 до 2005 напрямую.
Ваша САМАЯ БОЛЬШАЯ боль, если вы еще не знали, - это то, что DTS больше не поддерживает SSIS. Существует модуль типа оболочки, который будет запускать ваши существующие пакеты DTS, но вы захотите вручную воссоздать их все в SSIS. Простота этого будет зависеть от сложности самих пакетов, но я уже сделал несколько в работе, и они были довольно гладкими.
Вы можете обновить 6.5 до SQL Server 2000. Возможно, вам будет проще освоить SQL Server или версию MSDE 2000. У Microsoft есть страница с переходом с 6,5 на 2000 . Если у вас есть база данных в формате 2000, у SQL Server 2005 не возникнет проблем с ее обновлением до формата 2005.
Если у вас нет SQL Server 2000, вы можете загрузить версию MSDE 2000 непосредственно от Microsoft.
Я ни в коем случае не авторитет, но я считаю, что единственный поддерживаемый путь - от 6,5 до 7. Конечно, это был бы самый вменяемый маршрут, тогда я считаю, что вы можете перейти с 7 прямо на 2005 довольно безболезненно.
Что касается написания сценариев для всех объектов - я бы посоветовал против этого, поскольку вы неизбежно что-то упустите (если ваша база данных действительно тривиальна).
Если вы можете найти профессиональную или какую-либо другую версию Visual Studio 6.0 для сверхпредпринимателей - она поставляется с копией MSDE (в основном предшественник SQL Express). Я полагаю, что MSDE 2000 по-прежнему доступен для бесплатной загрузки от Microsoft, но я не знаю, можно ли перейти непосредственно с 6.5 на 2000.
Я думаю, что в концепции вы вряд ли столкнетесь с какой-либо опасностью. Однако годы практики говорят мне, что вы всегда будете пропускать какой-либо объект, разрешение или другой элемент базы данных, который не проявится немедленно. Если вы можете написать весь дамп, лучше. Поскольку у вас будет меньше шансов что-то пропустить - и если вы что-то пропустите, это можно легко добавить в сценарий и исправить. Я бы избегал любых ручных действий (кроме однократного нажатия клавиши ввода), таких как чума.