Какой по вашему мнению корректный перенос БД 1C SQL со старого сервера 2014 на новый 2017?

Question

[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)

Answer 1

[Константин]

c. выгрузка в .dt, загрузка из .dt, по сути перенос средствами конфигуратора, но это самый долгий процесс, да и такую большую базу не с первого раза удавалось выгружать, то там места где-то не хватает, то памяти и пр.

если возможно выгрузить, железо бетонноверный способ.

при вашем размере размер БД - 375 Гб, выгрузка будет около 1,5-2 гига. Делал тут недавно выгрузку 250гб скуль база БП, повремени выгрузка 10 минут,загрузка 20минут.

b. простое отсоединение БД от сервера,

тоже возможно но, хотя я н большой спец Microsoft SQL, но он долже поддерживать базы предыдущих версии.

3. ТИИ, стоит ли делать

необязательно, при загрузке, часть из этих функций запустится.

лог - 16 Гб

можно не нести, особо не нужен.

ps
выгрузку в dt лучше сделать.

Comments

[beltskyy]

спс, но у нас .dt не выгружается из-за нехватки свободного места на клиенте, на котором запускаем конфигуратор, хотя и свободно ~136 гектар. уже перенеслись через штатный бэкап, на старом сделали полный, на новом из него восстановились

пока вроде все на месте, но завтра утром юзеры расскажут наверняка))))

Answer 2

[beltskyy]

странно, по почте пришло уведомление, что кто-то ответил здесь, более того, даже текст ответа полностью, но тут не вижу вообще, дабы прокомментировать его

Comments

[davidnum95]

ответ удалили наверно

[beltskyy]

ааа, ну да, он там советовал потестировать все, но не увидел, что мы уже полгода тестировали до этого)))
вобщем по первому пункту решил переносить через бэкап, по 3 пункту ТИИ делать не буду пока, потом подниму тестовое зеркало и по ТИИ-каю, по 4 пункту тоже решил пока уровень совместимости не дергать лишний раз, на тестовом подергаю, ну и 2 пункт, вроде как подсказали ребята, что есть чудо-обработка выгрузки данных в базу с идентичной конфигурацией (нужно только знать список объектов к переносу)

[АртемЪ]

beltskyy, А почему не через dt? Долго или не упаковывает?

[beltskyy]

АртемЪ, долго и в конце пишет что места не хватает, хотя и пробуем в сетевую папку выгружать, на самом сервере терминальном, откуда конфигуратор запустили, видать места мало, хотя свободно было аж 136 Гб..

[АртемЪ]

beltskyy, А база какого размера? И зачем выгружать в сетевую папку? Это ж медленно, и нагрузка идет лишняя на сеть и на процессор. Ну и 123Гб - неужто нельзя для таких целей найти свободный диск на пару-тройку террабайт?

Answer 3

[Максим Ярошевич]

Однозначно через выгрузку в .dt и загрузку на новый сервер, правда, может быть довольно долго - но это зависит от конфигураций оборудования. Второй вариант быстрее - сделать полную резервную копию на старом сервере и развернуть на новом - из старого в новый отлично работает.