Боб Блэкберн, старший архитектор платформ данных в Capax Global

Моим первым ИТ-проектом была конвертация данных для Fashion Bug. С тех пор я участвовал во многих преобразованиях как штатный разработчик, так и консультант. Последние несколько преобразований были связаны с переносом баз данных Oracle на SQL Server. Вот 10 способов устранения ошибок, от технологических до технических, которые представлены в основном в хронологическом порядке.

1. Недооценка масштабов

Все мы знаем, что это большие сложные проекты. Вам нужно будет задокументировать, что нужно преобразовать. База данных, исходные данные, последующие приложения, инструменты отчетности и т. Д. Они также требуют значительного количества времени для контроля качества. Помощник по миграции Microsoft SQL Server может помочь с преобразованием схемы и кода. Поскольку для преобразования вам также потребуются дополнительные ресурсы, сейчас идеальное время для сотрудничества с фирмой, имеющей опыт преобразования баз данных. Это поможет вам начать в правильном направлении.

Большинство, если не все компании, проводят преобразование базы данных, чтобы сэкономить деньги. Первоначальные затраты и усилия могут показаться устрашающими; но окупаемость инвестиций обычно того стоит. Хотя у некоторых компаний есть сторонние приложения или другие требования, которые приводят к превышению желаемой стоимости или продолжительности объема. Просмотрите это сравнение лицензий, и у вас будет место, с которого можно начать анализ затрат и выгод. У всех должно быть согласие, потому что вы захотите следить за целью во время проекта конверсии.

2. Принимая самую низкую ставку

«Если вы думаете, что нанять профессионала для этой работы - дорогое удовольствие, подождите, пока вы не наймете любителя». Красный Адэр

Скорее всего, это база данных, которая поддерживает ваш основной бизнес. Задержки, ошибки и низкая производительность повлияют на ваш бизнес в краткосрочной и долгосрочной перспективе. При переводе следует переводить на свой родной язык. Точно так же иметь специалистов по SQL Server, которые знают Oracle, намного лучше, чем разработчиков Oracle, которые немного разбираются в преобразовании T-SQL в ваше основное приложение. Убедитесь, что вы знакомы с методологией компании, а также с ее техническим опытом.

3. Ограниченная доступность для МСП

Вы эксперт в предметной области. И технические, и бизнес-знания. Вы пытаетесь поддерживать работу компании, пока продолжается этот проект; но на конверсионный проект также потребуется значительная часть вашего времени. Менеджеры проектов часто выделяют 30–50% времени МСП на проект; но мы часто видим 10–20% во время проекта. Убедитесь, что держатели пакетов заранее знают требования своих сотрудников. Задержки в доступе к МСП замедлят разработку и приведут к доработке, включая время, чтобы обновить понимание разработчиками требований.

4. Отсутствие централизованной документации.

Проект такого масштаба приведет к созданию большого количества документации. Это должно быть централизовано, чтобы можно было поддерживать и отслеживать единую версию истины. Некоторые из типов документации, которую необходимо поддерживать, - это списки и статусы преобразования объектов, вопросы и ответы SME, системная документация (до и после преобразования), шаблоны кода, отслеживание ошибок и т. Д. Если вам задают вопрос и вы отвечаете, позвольте мне проверить свою электронную почту, подумайте о создании артефакта проекта.

5. Плохая точность вычислений, т.е. деление.

Скорее всего, это произойдет во время проверки качества. Ваше представление может быть простым, и SSMA преобразовал его без ошибок; но вы все равно получаете неправильный ответ. У вас может быть вычисление, которое усекает десятичные разряды, но они есть в исходной системе. Т.е. SQL select 12/10 вернет 1; но Oracle возвращает 1.2. Вам придется заставить SQL вычислить желаемую точность.

6. Отказ от автоматизации обновления материализованного представления.

Материализованные представления отлично подходят для производительности. Они также имеют тенденцию усложняться со временем. Вам нужно будет смоделировать их с помощью представлений и таблиц SQL. Я также предлагаю вам настроить контрольную таблицу для отслеживания порядка обновления и облегчения пакетного обновления или обновления по запросу. Вот небольшой запрос Oracle, чтобы показать первые три уровня MV.

выберите dr.mview_name, dr.DetailOBJ_name, dr2.DetailOBJ_name как SecondLevelView, dr3.DetailOBJ_name как ThirdLevelView
из ALL_MVIEW_DETAIL_RELATIONS dr
оставил присоединиться к ALL_MVIEW_DETAIL_RELATIONS_dr2 / > покинул присоединиться к ALL_MVIEW_DETAIL_RELATIONS dr3
на dr2.DetailOBJ_name = dr3.Mview_name

7. Использование UDF SSMA для функций Oracle

SSMA будет генерировать функции SQL для имитации функций Oracle. Это поможет вам быстро приступить к работе. Однако вы платите за производительность. У меня было представление, в котором, среди прочего, использовались функции Greatest и Least над большой таблицей (75+ миллионов строк). Просмотр длился 55 минут. После того, как я преобразовал его для использования операторов CASE, он работал за 24 секунды. Выделите время на преобразование UDF SSMA в собственные операторы SQL для повышения производительности.

8. Принятие ошибки SSMA в качестве окончательного ответа

SSMA поможет вам автоматизировать большую часть конверсии. Но при этом все равно будут возникать ошибки преобразования. SQL Server продолжает добавлять функции и возможности, реализация которых может занять некоторое время. Иногда есть простые решения. Вы разработаете список (и поместите его в централизованное хранилище документов), специфичный для вашей базы данных. Несколько примеров:

  • XMLAGG в STRING_AGG
  • «Преобразование предложения факторизации подзапроса не поддерживается» для переформатирования CTE в синтаксисе SQL.
  • Константы в GROUP BY могут быть удалены в SQL
  • LAG OVER PARTITION поддерживается в SQL

9. Не использовать инструмент сравнения данных.

Простой подсчет строк и пересечение некоторых сумм - хорошая проверка данных во время ночного пакета. Однако вам нужно будет сравнить миллиарды точек данных во время преобразования. Существуют инструменты для сравнения схемы и данных. Кроме того, компании, предлагающие преобразование данных, могут предоставить свой собственный инструмент с необходимыми знаниями. Это должно быть настроено с самого начала проекта. Контроль качества - это очень итеративный процесс, и для создания профилей и скриптов, необходимых для тестирования, потребуется время.

10. Не запускать ежедневные партии как можно скорее.

Исходя из методологии Agile, вы хотите, чтобы цикл обратной связи был как можно короче. Создавайте пакетные задания после того, как будут разработаны несколько каналов. Постоянно добавляйте задания в пакет по мере их разработки (Непрерывная интеграция). Это не только проверит ваши данные; но поможет вам установить тесты безопасности и производительности. Вам может быть отказано в снятии с производства по соображениям производительности. Вы всегда можете использовать резервную копию и запустить ее на день позже.

Заключение

Проекты миграции данных - это не повседневное занятие. Имея опытную команду и заранее минимизируя риски, у вас будет гораздо более плавный проект.

Сообщите нам свои проблемы и ключи к успеху.