Галактика в вопросах и ответах

Уважаемые!
Прошу поделиться опытом перехода MS SQL2000 SP4(WinServer 2003)-->MS SQL 2008 (WinServer 2008 R2) (Если конечно такой или подобный опыт имеется!).
Дело в том что, простой перенос бэкапа Галки в новую инстанцию (на новый сервер) НЕ РАБОТАЕТ из-за нескольких новых ХП, а также User Functions.
При входе в Галку с админским логином и с отключенным protection NapServer генерит ошибку:
Error code (1814)
exec CreateAtlUser @login=?,@asadm=1 (такой ХП и еще нескольких просто не было на старых серверах 2000, 2005)
Пробовал тупо скопировать новые ХП из созданной с нуля БД Russia в свою БД. Не канает. ТП рекомендует выполнить проверку chkmssql.exe с включенными опциями для проверки триггеров и ХП. Опять не проходит. Замкнутый круг. Чтобы запустить эту утилиту необходим пользовательский логин. Чтобы создать логин требуется войти в Галактику. Круг замкнулся. В итоге ТП рекомендовала выгрузку в дбфы и загрузку из них. Однозначно не проходит из-за проблем со временем конвертации - слишком большой размер данных и мало времени.
Есть ли опыт конвертации посредством, например, встроенных в SQL Data Transformation Services или других средств? Пробные эксперименты показали огромный выигрыш во времени. Однако, со слов ТП они не рекомендуют данный подход по каким-то причинам.

интересно много это сколько? 80 гигов перекачиваются за 2 суток, при условии организации нескольких процессов, удаления индексов и т.д. Можно конечно восстановить куда нибудь в другую базу и выполнить Data Transformation в созданную инсталятором. Основная проблема - это пользователи SQL. При импорте X$users через сапорт или vip они будут созданы в автомате. Поэтому может имеет смысл сначала создать их, а потом уже делать Data Transformation. Лучше тогда в протекте сделать сохранить - восстановить настройки. Вот потом сюду и напишите что получилось .

Прежде чем создать этот топик я создал конвертор с распараллеливанием многих процессов экспорта и импорта на самые ресурсоемкие таблицы, так что запускалось одновременно 30 батников-випов. И все же БД в 90 гигов импортируется нестерпимо долго (здесь я не отключал создание индексов). И вот с целью принципиального решения проблемы с учетом будущего экспоненциального роста объема БД и ее участников (сейчас их около 600, а будет возможно до 1000)и был выбран вариант с DTS. К тому же после гипотетически успешного перехода нужно делать пересчет прав пользователей, что делается крайне медленно. В сухом остатке фактор времени для нашей организации критический.
Что касается юзверей, так я так и намерен поступить: импортнуть x$users, tablerights и пр. с помощью ступорта на нулевую БД. Здесь для меня не ясна позиция ТП, утверждающая что данных подход чреват различного рода опасностями, не тестируемыми разработчиками. Официальный ответ ТП:

ТП:Разработчиками не рассматривался вопрос апгрейда по такой технологии, а так же работоспособности системы на СУБД одной версии с БД другой ТП:версии (т.к. после восстановления бэкапа 2k на 2k8, БД будет работать в режиме совместимости),
ТП:Разработчиками не рассматривался вопрос перевода БД из режима совместимости в версию СУБД.

Что бы это значило?

Мне хватало 4-6 . Иначе смысла нет. 2 на экспорт (большие файлы нарезаны на куски - иначе импорт тормозит),2-4 на импорт. Может быть имеет смысл последовательно запускать, поскольку после какого-то времени импорт начинает тормозить.
30 перебор - вы наоборот мешаете SQL создавать индексы. Индексы нужно сбрасывать(в список добавить еще таблы, ориентироваться нужно в основном на кол-во записей, а не на размер)
В моем случае это сократило время на импорт в 2 раза. Индексы потом создались за полчаса.
После нескольких часов что успело выгрузится, перенес на вкачку. И периодически подкладывал.
Лучше права перенести протектом - так гарантировано будет нормально. Потом уже миграцию запускать - порядок тут важен, иначе после миграции уже в базюку 100% не попадете. А да - может еще до миграции следует отключить протект в обоих базах.

Другими словами кроме порядка выполнения загрузки данных иных подводных камней не предвидится?

А как реагировать на ответ ТП по поводу режима совместимости БД?

я не пробовал. Наверное не надо импортировать роли и т.д - вы их создадите протектом. Только данные. Наверное не надо таблы до 900(в общем только на T). Наверное после импорта нужен рестарт SQL - чтобы naps обновил данные по суррогатным ключам или выполнить скрипт из i_sql. Потренируйтесь на тестовой базюке.

А еще сразу по возможности разнесите лог, журнал, индексы и данные на разные физические диски. В идеале на 3.

Спасибо за участие. Косвенно вы подтвердили мой сценарий перехода. Именно так я и планировал. Некоторый дискомфорт был от непоняток с ответом ТП о совместимости, типа такой переход принципиально не возможен из-за внутренних причин SQL 2008 неизвестных мне или другой способ хранения системных данных. После возможной успешной конвертации обещаю известить галактическое сообщество о всех плюсах и минусах перехода с помощью DTS, так что может быть и ТП возьмут его на вооружение для БД > 1Тб, где самым существенным ограничением является фактор времени (не более 3 суток).

Подскажите есть ли у вас проблема с аппаратным ключом ? Он установлен на сервере?

Хвала небесам, эта проблема нас не затрагивает. HardWare Key установлен на старом сервере и все работает нормально.

Eugene1966 писал(а):Хвала небесам, эта проблема нас не затрагивает. HardWare Key установлен на старом сервере и все работает нормально.

А мы попытались установить аппаратный ключ под Win2008, работает с большими тормозами. Хотелось бы знать, толко у нас так?

Как дела с переходом???
Если еще испытываете проблемы то велкам в личку.
В свое время перешел первым в Украине вначале на Win 2003 x-64 + SQL 2005 x64, а теперь на Win 2008R2 x-64 + SQL 2008 x64
Особых проблем не испытывал. Проблему с нехваткой ряда хранимок решил простым добавлением их из вновь созданой базы на сервере SQL 2008 и chkmssql.

Переходили с mssql 2000 на mssql 2008. Пришлось немного повозиться с конвертером, а в остальном все нормально прошло.
Опытным путем разделили все таблицы на 4 примерно равнозначные кучки, плюс сбросили индексы, плюс включили пакетную вставку.
Некоторые таблицы были большие, но как выяснилось, дольше всего импорт идет не по ним, а по таблицам с мемо-полями.
Итог: база 120 Гб, экспорт - менее суток, импорт - примерно сутки.

А кто-нибудь уже пробовал Галактику на MS SQL Server 2008R2?
Понимаю, что вопрос несколько наивен и официальной поддержки этой версии MS SQL нет и непонятно как скоро будет.
Но все же, вдруг уже кто-то пробовал работать? Есть ли косяки кроме красного окошка после запуска Галактики ?