Похоже, вы пока не сильно погрузились в задачу, либо недостаточно ее сформулировали 😉

ну простые базы наверное конвертит нормально та тула

так же в Workbench есть миграция

(но у меня не вышло)

Начни с реверс-инжиниринга.
Что представляет из себя бд?
Если в ней нет пользовательских процедур и функций, а лишь одни таблички и вьюшки - т.е. база используется как хранилище. Тут проще

Если в базе есть куча процедур, функций и на таблицах триггеры + ограничения - значит на уровне бд реализована логика. Это уже совсем другая задача

и еще зависит от приложения(программы), будет ли она поддерживать другую версию

и еще бывают их свои методы миграции баз

Привет - может кто подскажет, куда копать. Перенесли БД с сервера sql 2014 на sql 2017 и резко упала производительность при вставке данных в нее update'ами. Раз в 10. Играли с Legacy esimator, переключали  MAXDOP туда-сюда - ничего не помогает. В профайлере видно, что update'ы зависают одновременно и ждут друг друга. Чтения нет в этот момент. И там и там виртуалки, RAM поменьше на сервере с 2017, но должно быть больше чем нужно.

1. На время тестирования запустить perfmon - набор счетчиков для диагностирования производительности можно нагуглить в инете

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

3. Что по ожиданиям?

4. Вставка данных update'ами - данный процесс описать подробнее

потому что поменялись Execution plans, ведь Database Engine теперь другой, и он по другому решает как строить план, какие индексы (не)использовать. Нужно исследовать планы тех скриптов которые замедлились и провести рефакторинг кода под 2017. Изменений там много.

Спасибо. Индексов нет ни одного, код запроса закрытый (выполняется из внешней системы, Informatica, для тех, кто с ней знаком). Будем копать дальше.

Спасибо, будем смотреть на это всё.

а вы согласовывали миграцию с этим вендором на наличие совместимости программы с 2017 версией? Это достаточно новая версия и не считается еще стабильной, поэтому не очень распространена. По мне сам 2014 является самым лучшим решением на данный момент.
П.С. Индексы должны быть в любом случае - простое правило.

Да, они 2017 поддерживают,
Согласен, 2014 весьма хорош, но было желание на новый сервер ставить последнюю из одобренных, так и сделали,
Там нечастое чтение (больше как архив БД выступает), именно для ускорения скорости записи туда индексы не делали.
Возможно, что логика неправильная именно при update'ах. Но на 2014 работало отлично.

Значит они должны рассмотреть проблему.

А почему не решили использовать 2016?

Тикет открыт, но надежд мало, т.к. данные изначально берутся из Salesforce.com, и на стыке трёх систем они не особо хотят разбираться, в чем проблема

Потому что 2017 новее :) 2016 лучше?

не всегда лучшее то что новее. Лучше чем 2017, так как у него уже есть SP2, т.е. многое количество багов уже исправлено, а для 2017 апдейты приходят с багами, т.е. все еще ведется активная разработка.

я бы не стал его использовать если не хочу ставить на Линукс