[beltskyy]

ребята, такой вопрос, переводим сервер приложений 1С и БД SQL на новую площадку., все уже настроено и тестировалось, насколько это было возможно, похоже что скорее взлетит, чем нет. восстановление БД на новом сервере делал из ежедневного разностного бэкапа, созданного на старом. и вот настает час Ч и принято решение переезжать на новую площадку, появилось легкое мандраже))) и несколько вопросов, поэтому вопрошаю скорее совета, чем ответа, собираю, так сказать, мнения, чтобы развеять сомнения, как корректно перенести саму БД:

1. выскажите пжл свое мнение по поводу способа переезда БД на новый сервер, какой из вариантов считаете более корректным, а м.б. предложите какой-то новый вариант)) лично мне знакомо 3 варианта:

a. создание полной РК, восстановление на новой площадке из РК, расстановка прав (так считаю более корректно, и тестовую площадку поднимали неоднократно именно так)
b. простое отсоединение БД от сервера, копирование файла с данными и логом на новый сервер, там простое присоединение, опять-таки, расстановка прав и в бой (так делали несколько лет назад, вроде прокатило тогда успешно)
c. выгрузка в .dt, загрузка из .dt, по сути перенос средствами конфигуратора, но это самый долгий процесс, да и такую большую базу не с первого раза удавалось выгружать, то там места где-то не хватает, то памяти и пр.

2. всегда есть шанс, что что-то пойдет не так, в связи с этим моим неоконченным планом Б было поднять старую площадку и каким-то образом перенести нащелканные пользователями доки из новой БД в старую БД. почему план Б неоконченный? потому как я нге представляю, есть ли какой-то инструмент для реализации такой идеи, м.б. обработка пакетного переноса доков с такого-то числа и времени, либо какое-то сравнение регистров и зеркальная копия из содержимого, либо еще какие-то варианты

3. ТИИ, стоит ли делать на старой площадке перед выгрузкой, либо уже после загрузки на новую площадку, процесс длительный, ресурсоемкий, боюсь старая не потянет, да и времени особо нет. и вообще, стоит ли с ним заморачиваться по вашему мнению?

4. меня настораживает в опциях БД Compatibility level этой БД - SQL Server 2008 (100), в выпадающем списке опциональны уровни вплоть до SQL Server 2017 (140) на что он вообще влияет, этот уровень совместимости



исходные данные - режим восстановления БД - Simple
старый сервер SQL - Microsoft SQL Server 2014 - 12.0.2000.8 (X64) Feb 20 2014 20:04:26
новый сервер SQL - Microsoft SQL Server 2017 (RTM-CU15-GDR) (KB4505225) - 14.0.3192.2 (X64) Jun 15 2019 00:45:05
размер БД - 375 Гб, лог - 16 Гб
платформа 1С работает в режиме совместимости 8.2
старая платформа - 8.3.8.2137 (x86)
новая платформа - 8.3.13.1690 (x64)

!

Правила: 8

Сообщение отредактировал Vofka - 23.10.19, 11:22

[Vofka]

Мое мнение такое. Если есть возможность - лучше делать средствами 1С (выгрузить/загрузить дт), особенно учитывая, что переезд будет на разные версии платформы. Если средствами 1С сделать это не представляется возможным по тем или иным причинам, то я бы делал бэкап/восстановление базы с помощью SQL-я. Опять таки, если ещё и брать во внимание, что переезд выполняется на другую версию SQL-я, то я не уверен, что отсоединение/подсоединение сработает (но может и сработает). Но я бы все равно делал через бэкап. И если уже по каким-то причинам не получается через бэкап, уже тогда бы я пробовал через отсоединение/подключение файла базы.

Насчет Compatibility level - поставьте его в соответствии со старой версией SQL-я. Это как минимум должно вам дать возможность в случае чего перенести базу обратно на старый SQL сервер. Если же уровень совместимости у вас будет выше, то, возможно, перенести существующую базу с более нового SQL-я на прежний экземпляр у вас не получится. Когда система поработает на новом сервере какое-то время и будет ясно, что назад переезжать она не будет, можно поднять уровень совместимости до актуальной версии SQL-я.

Сообщение отредактировал Vofka - 23.10.19, 11:24