Перенос баз на новый сервер средствами SQL или DT #637441

Собственно собрался перевести 1С на новый сервер. На старом SQL 2005 Standart на новом SQL 2008 R2. Варианта 2: бекап / рестор средствами SQL или выгрузка в DT средствами 1с

ок, держите всех в курсе...

а как насчет того, чтобы завести блошек в свитере?

имхо, в данном случае лучше DT. так мне подсказывает сердце.

тоже склоняюсь к DT ибо с РИБом можно накосячить

и тут нарисовался риб.

Дт однозначно

ЭЭЭ... А размер базы какой ? :) - это в данном случае ключевой вопрос

Если размер большой, то выгрузить CF с одного сервера, загрузить в чистую базу на другом, потом через XML перекинуть данные

Если размер ln не большой и время ее выгрузки и загрузки не критично для бизнеса то ДТ. А вот про скульный переход я ни разу не слышал...

одинэсник он такой - если про что-то не слышал, значит этого нет.

нафига?

Бэкап с 2005-го можно будет развернуть на 2008, только помните, что бэкап с 2008-го на 2005 не подойдёт. Преимущество варианта с бэкапом SQL в том, что простой может составить 5-10 минут.

+ выгонять никого не надо. Хотя, может, это и минус :)

SQL сервера разный, только

2 ой.. правда, да? и что же?

версия второго сервера "выше", это не проблема

более того по умолчанию база развернутся на 2008 в формате 2005-го скуля.... но это 1сники, для них имеет значение что версия ПО разная.

У меня такая же задача, можно поподробней что за DT ?))

чо вы тут гоните? Какой дт? Только скуль... Забудьте вы про эту кривую выгрузку, которая может помочь только при переходе с файла на сервер и обратно... А уж на верхнюю версию скуля с нижней - тут и думать нечего... ЗЫ. Я, конечно, понимаю, что тяпница и всё такое... Но гнать такую пургу... Это выше моего понимания...

Даже 1С рекомдует делать архивы средствами SQL. А тут практически просто восстановление из архива

2 а как же РИБ? вот риб беспокоит... какими аргументами ты уймешь его страхи?

Традиционными аргументами. Стакан водки и вперёд. Причём тут риб? С какого похмелу он должен слететь?

dt ни чего не гарантирует

Однозначно скуль. хотя бы то что журнал регистрации не слетит доставляет

ну, ещё при переходе между разными СУБД (MS SQL/Postgre, например)

"А вдруг?" Я бы еще посоветовал в бубен постучать, чтобы духи РИБа не беспокоились.

dt зло вобще

а с какой версии журнал регистрации в базе хранится?

+100500

2 каким же это волщебным образом не слетит?

погодите, а скуяли он слететь то должен? если сервер 1с оставить старый то не слетит при ресторе на SQL, Дт - потрёт. Кстати правильно

Пятница, простительно :) И риб вспомнили, и журнал регистрации помянули. Всё лишь бы им поговорить :)

я понял так, что сервер 1С тоже будет новый. Плюс, если он создаст новую базу на старом сервере 1С, тоже слетит. ЖР проще руками заранее скопировать и тогда что с dt, что с бэкапом проблем не будет.

Дт при загрузке потрёт, после этого надо прицеплять, а со скулем - можно сразу

>>если он создаст новую базу на старом сервере 1С в том то и дело что не надо новую создавать, изменить путь к серверу SQL только

Есть СКЛ, который сделает все быстрее, нафига ДТ. А еще можно ведь и не бэкап делать, а просто попробовать взять два файлика, в которых лежит база СКЛ и примонтировать их на новом сервере ...

версии разные, имхо так просто детач-атач не сделать

можно, но время простоя увеличится. ещё раз - я понял так, что сервер 1С будет новый,соответственно, ЖР в любом случае не будет, если его руками не переносить.

Да х.з. надо попробовать - ведь ничего не мешает

С чего это время простоя будет больше чем при ДТ?

чем при бэкапе/ресторе

А вот и фиг. Монтирование значительно быстрее рестора, + бэкап делать не нужно

а иного мнения почему нет? копируй ldf,mdf и натравливай созданную базу на них

Рукалицо

Никаких бэкапов SQL - только DT! Переносили как-то SQL бекапом  базу - в итоге возникли косяки. После этого переношу только только через DT. Гарантия что с базой будет все ОК.

Что за косяки? Может руки?

ДТ ничего не гарантирует, официальное заявление Нуралиева и Ко.

Рукалицо = руки

Сейчас уже не вспомню точно что было. А что там сложного? Через бекап и рестор. Любой школьник справится.

.

1. Выставляешь БД полную модель восстановления (если стоит другая). 2. Делаешь полный бэкап при работающих пользователях. 3. Восстанавливаешь этот полный бэкап с параметром NO_RECOVERY 4. Выгоняешь всех из базы. Когда все вышли делаешь бэкап журнала транзакций. 5. Восстанавливаешь созданный бэкап ЖТ с параметром RECOVERY, одновременно прописываешь новый сервер в кластере серверов 1С (если сервер 1С старый) или создаешь новую базу (если новый). 6. Пускаешь всех в базу, возвращашь первоначальную модель восстановления. Пункты 4-5 займут от силы 5 минут. Естественно, если база мелкая, и за 5-10 минут все файлы скопируются на новый сервер, можно не заморачиваться.

но dt все же сделай

Нуну.... А где вариант детач/атач? :)

с 2000 на 2005 делали, просто подключили  файлы от 2000 к серверу 2005 и вроде без проблем.

>

>

Там ни слова про детач. А без этого базу не скопируешь. Ну, или службу останавливать придется. :)

ок, уговорили, совместимость есть

а почему нельзя скопировать mdf/ldf?

бггг :)

2 да, точно, подумал что и сервер 1С новый будет.

это все равно что сказать - когда я пришел первый раз в метро, я не знал что там турникеты. попытался пройти, они меня больно стукнули по коленка, да так что я обоссался... Теперь я знаю что нужно кидать жетон, и турникет меня не бъёт, но я все равно продолжаю ссаться при входе в метро... По этой причине предпочитаю ездить на троллейбусах. Пофиг что с 3-мя пересадками и дольше в 2 раза.

(620 Как мило )

По объективным причинам.

мда... Сколько же бреда в головах у некоторых...

Новое поколение вступает в жихнь.

Что за кривая клава? жихнь = жизнь.

Так вернее будет.

в чем проблемы ?