На главную
Обо мне
Меня зовут: Николай Воронков
Я живу в: Твери, Россия
Email: job@voronkov.org
Skype: nik-voronkov
Мое резюме:в формате RTF
Работаю: Freelancer
Мое портфолио (по категориям)
MS SQL / Oracle / mySQL
ASP.NET / Silverlight
C# / PHP
Adobe InDesign (client/server)
SSRS / SSAS
Wordpress

Перенос данных для ЕШКО-Россия

Заказчик: Компания ЕШКО – Россия
Тип проекта: Внутренний проект для замены старой CRM-системы
Моя позиция в проекте:
  • Архитектор баз данных
  • DBA
  • Программист
  • Операционные системы: Windows 2008 Server
    Базы данных: Oracle, DBF
    Языки: PL/SQL, Oracle SQL, HTML, JavaScript
    Технологии: Oracle database, Oracle heterogeneous services (gateways)
    Язык интерфейса: Русский

    [+]
    Более подробно о моем участии в проекте для российских работодателей …

    Проект по переносу данных из старой CRM-системы компании (Clipper-DBF) в новую (Oracle, HTML, JavaScript).

  • Объем данных: 30Gb
  • Объем результирующей базы (с индексами): 65Gb
  • Количество результирующих таблиц: 60
  • Максимальное количество записей в таблице: 90 миллионов
  • Таблиц с количеством записей более миллиона: 25
  • Длительность процесса переноса: более суток
  • Возможность перезапуска с середины процесса в случае ошибки: предусмотрено
  • Останов процесса трансформации из интерфейса: предусмотрен
  • Количество шагов процесса: 9
  • Пропуск шагов при трансформации в настройках интерфейса: предусмотрен
  • Сервер Oracle: 11G 64bit
  • Механизм переноса данных: Oracle heterogeneous services (MS Access DBF driver)

    Ранее мне приходилось выполнять перенос данных из DBF-файлов для 32 битных экземпляров баз данных Oracle и проблем с драйверами не возникало. Для 64 битной версии все оказалось сложнее. Microsoft прекратил поддержку DBF-форматов. После изучения форумов оказалось, что все еще можно использовать DBF-драйвер для MS Access.
    Процесс загрузки управлялся через простой веб-интерфейс. В качестве веб-сервера использовался Oracle Apache Server, который работал с базой напрямую через моуль mod_plsql. Бизнес ЕШКО для четырех стран СНГ достаточно унифицирован, но между филиалами все равно есть различия, поэтому настройку некторых констант переноса данных я реализовал через интерфейс реестра.
    Мой опыт показывал, что напрямую работать с большими таблицами в формате DBF через гетерогенный сервис практически невозможно из-за потери производительности, поэтому на первом шаге я переносил данные во временную схему Oracle. Кроме этого, для DBF-файлов существует ограничение по размерам (2 GB), поэтому некоторые большие таблицы были разбиты на части. При загрузке во временную схему я делал слияние таблиц, построение индексов и небольшие улучшающие преобразования. Процесс загрузки таблиц удалось распараллелить, одновременно могли работать четыре процесса, их количество постоянно проверялось на серверной части программой-супервизором и при уменьшении производился запуск процесса загрузки очередной таблицы.
    Процесс переноса запускался из интерфейса. При этом стартовала программа-супервизор, как процесс Oracle. Она с интервалом в 10 секунд проверяла состояние задач и журнал ошибок. Все задачи запускались этой программой, для определения их принадлежности к проекту использовались поля [MODULE] и [CLIENT_INFO] таблицы сессий Oracle. При необходимости, процесс переноса можно было прекратить, это делалось с помощью [KILL SESSION]. Пока не был завершен старый процесс, новый запустить было нельзя.
    Процесс переноса был разбит на 9 шагов, в соответствии с цельными логическими блоками. Иногда бывали случаи, когда некоторые шаги не было смысла повторять, поэтому в интерфейсе можно было задать сценарий выполнения, исключив некоторые шаги.
    Процесс загрузки данных подробно фиксировался с помощью журнала. Каждый шаг имел несколько пунктов, данные о выполнении которых записывались. Из интерфейса можно было просмотреть все шаги с указанием времени их начала и завершения.
    Сведения о прошлых загрузках также хранились и были доступны для просмотра.
    В случае ошибки, при условии ее исправления, процесс можно было запустить с начала текущего шага.
    На первом шаге процесса вся база данных сбрасывалась. Чтобы ускорить процесс я выключал все CONSTRAINTS в базе с помощью скрипта и делал нужным таблицам TRUNCATE, затем снова включал CONSTRAINTS.
    После завершения переноса заново вычислялись SEQUENCES для первичных ключей загруженных таблиц и по всей схеме собиралась статистика.

    Главная трудность, с которой пришлось столкнуться в этом проекте: отладка запросов. Проблема заключалась в том, что в начале загрузки таблицы были пустые, потом они заполнялись и могли стать большими, но Oracle CBO продолжал считать их маленькими и всегда строил планы запроса на основе FULL SCAN, поэтому в проекте нет практически ни одного запроса без HINTS.