Ранее мне приходилось выполнять перенос данных из 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.

Оставьте комментарий: