Вот... свершилось чудо: запустил subj.
А теперь - по порядку.
Не сомневаюсь, что мои последовали уже приобрели corporate лицензию для Windows server 2003 R2. Так вот, грабли номер один: не следует вбивать корпоративный ключик в первый попавшийся дистрибутив WinServ2003x64. В отличие от ХР, в данном случае corporate отличается от enterprise десятком с лишним файлов дистрибутива. В преимуществах лицензионного софта нас убеждают все более весомыми аргументами...
...правда, остается ряд мелких граблей с поиском правильных x64 драйверов, но это уж совсем оффопик.
Далее, собственно SQL2005. Не прячте ваши денежки по банкам и углам©: лицензия на 1 процессор - 47 килобаксов; на 4 процессора - соответствено...
Как всегда, Developer Edition Rulezz: в отличие от привиредливого Enterprise, становящегося только сервера, Developer, как и раньше, спокойно встает на 32bit домашнюю систему в качестве полезной учебно-боевой копии рабочей системы. Каких-либо различий в пользу Enterprise пока не выявлено. Со старыми instancами SQL2000 новый SQL уживается прекрасно, что позволяет в оффлайне разрабатывать распределенные мультисерверные задачи. Только при использовании дефолтовых линкнутых имен типа ИмяСервера="mycomputer\WorkSrv2" не забывайте во фразе типа "left join "+ИмяСервера+"."+ИмяБазы+".dbo."+ИмяТаблицы добавлять скобочки - вот так: "left join ["+ИмяСервера+"]."+ИмяБазы+".dbo."+ИмяТаблицы, что не помешает в дальнейшем и при работе в боевых режимах
Ну, это я отвлекся.
После установки мы обнаруживаем полное отсутствие как Enterprise Manager, так и Query Analyser. Все это теперь интегрировано в SQL Server Management Studio. Впрочем, никто не мешает продолжать использовать и старые Enterprise Manager и Query Analyser. Правда, Enterprise Manager от SQL2000 с SQL2005 работать отказывается, но старому доброму Query Analyser все пофигу. Кстати, приывычный SQL Service Manager в трее также отсутствует: видимо, вместо него следует использовать навороченный SQL Server Configuration Manager. Но и SQL Service Manager из комплектации SQL2000 также справляется неплохо, не пугаясь непривычного нового софта.
Грабли номер раз. По дефолту при установке SQL2005 Developer Edition отключаются все протоколы кроме shared memory. Ну, когда об этом знаешь - включить IP не проблема. А вот когда не знаешь - есть шанс помучиться, разбираясь, почему нет коннекта с новым сервером. К счастью, я знал
Грабли номер два. Первое, что мы видим после установки SQL2005: к старым SQL2000 серверам он не линкуется. Ну... то есть, линкуется, и даже позволяет запустить на них что-нибудь типа OPENQUERY, но при полноценном распределеном запросе начинает материться на якобы не найденные таблицы. И это при всем при том, что SQL2000 линкуется к 2005 без всяких проблем.
Первое, что обнаруживается: по дефолту при линковании сервера отключены RPC. Включаем в свойствах линкнутого сервера. При совпадающих collation также ставим нужную птичку - так оно, наверное, шустрее будет. Не лишним будет также в свойствах security поставить using login's security context, которая почему-то по умолчанию не стоит.
После всего вышеперечисленного проблема, скорее всего, сохранится. Если SQL2000 c сериспаком младше третьего, то так и надо, и по-другому не будет: чаще надо апгрейдиться. Если же SP3 или SP4, то ищем среди файлов распакованного сервиспака instcat.sql - примерно вот здесь - \SQL2KSP4\install\instcat.sql запускаем Query Analyser, коннектимся к SQL2000 и запускаем на нем вышеупомянутый скрипт. Возможно, придется также рестартнуть потом пропатченный сервер.
Перенос 1С-овских баз с 2000-го сервера.
Процедура в принципе вполне рутинная: бэкапим базу со старого сервера и восстанавливаем в пустую базу, созданную на новом. Внимательно следим за правильностью полных имен физических файлов новой базы.
По идее, при этом база, восстановленная из 2000-го бэкапа, сразу получит уровень совместимости "80", но на всякий случай лучше проверить.
Теперь - мелкие грабельки:
1. После запуска новой базы в эксплуатацию обратный откат на 2000 по пути backup-restore уже невозможен. Формат хранения бэкапов 2005 не совместим с 2000, хотя хэдеры на 2000 все же читаются. Тем не менее, если вдруг через пару дней боевой эксплуатации окажется, что "все плохо", можно все же "вылить" базу обратно на 2000 через механизм репликации, что я на всякий случай предварительно проверил (Snapshot publication спасет отца русской демократии).
2. Если вы предпочитаете задавать для 1С-овской авторизации пользователя, отличного от sa, не забудьте вручить этому юзеру серверную роль processadmin.
Очередные грабли общеизвестны:
1С упорно не считает SQL2005 достойным для себя партнером. Подавай ему не ниже SQL6.5SP2 и всё тут.
Наиболее распространенное лекарство - патч bkend.dll
000D9C4A: 83 EB
000D9C4B: E8 15
000DB0B0: 83 EB
000DB0B1: E8 10
но я счел более изящным другой патч того же файла
Сравнение файлов BkEnd.dll.bak и BKEND.DLL.2005
000D9C4C: 06 07
000DB0B2: 06 07
Кроме того, возникает проблема отказа 1С от работы по причине нежелания работать из якобы разных каталогов. Ну, в моем случае это как раз понятно: при запущенной через transactional publication репликации в базу постоянно долбится агент. Но та же проблема, как сообщается, почемуто возникает и при отсутствии репликаций. Подозреваю, что проблема гарантированно возникнет и при попытке использовать mirroring и некоторых других вкусностей 2005-го.
Страницы: [1] 
Sql2005 x64 на 4х ядрах.10дней-полет нормальный (число прочтений - 18453 )
