История одной миграции с SQL Server 2012 на SQL Server 2016+ в системе Microsoft Dynamics AX 2012

[4eS]

Но тут, о чудо!!!, мы случайно наткнулись на инфу о довольно радикальном изменении в механизме работы оптимизатора, начиная с версии SQL Server 2014. Речь шла о, так называемой, оценке кардинальности.

Я, конечно, прошу меня простить, но складывается ощущение, что к апгрейду вы совсем не готовились (по крайней мере со стороны СУБД), если даже не были в курсе про такое массивное изменение.
Получилось, что сначала обновили, не взлетело, и тогда уже пошли читать инструкцию (change log).

И дело не в продуктах MS и их неравномерном развитии. Ваши выводы, несомненно, верны, но касаются абсолютно любого апгрейда (как софтварного, так и хардварного).

[ITmarketDA]

С одной стороны, согласен. Стыд, позор и презрение. Но с другой стороны:
1. При нагрузочном тестировании эта фича никак не проявила себя. Она и после релиза не скзать, что прям сразу и стабильно проявлялась. Оптимизатор работал просто «странно» и иногда(!!!) выбирал абсолютно не адекватные индексы для построени планов.
2. В официальных требованиях от MS для Аксапты версии 2012, ничего не сказано об особенностях настройки БД в связке с SQL Server 2014+.
3. Принимая во внимание пункты 1 и 2, с чего бы нам было обратить внимание именно на эту фичу в списке изменений для новой версии?
Пост на самом деле адресован компаниям, проектам, кто внедряет Аксапту, и у кого нет в штате матерых DBA, которые наверное сходу вспомнили про эту фичу при апгрейде. Возможно кому-то в будущем это поможет не наступить на эти же грабли.