[gl00mie]

В моем случае конвертировалась база 3.0 размером чуть больше 600 Гб, происходило все на Оракле. Отличие от конвертации базы 4.0 тут в том, что для 2009-й создается новая база, в которую переливаются данные с одновременной конвертацией в Unicode, а уже потом по этой новой базе работают скрипты конвертации. Опять же, в моем случае под 2009-ю был разведен новый комплекс СУБД (хранилище данных и сервера БД), поэтому одним из этапов конвертации было создание "слепка" базы 3.0 на этом новом комплексе: оказалось быстрее сперва перелить данные по сети средствами СУБД и потом уже в рамках одного физического хранилища переливать данные из этого слепка в базу 2009-й, нежели напрямую из старого комплекса переливать их в базу 2009-й по сети. Ниже приводится хронология событий, восстановленная по информации, которую я публиковал для заинтересованных лиц по ходу конвертации.

• 31.12.10 00:00 начало создания "слепка" рабочей базы на новом комплексе (копирование данных средствами СУБД)
• 31.12.10 02:52 запуск скриптов переливки данных из слепка базы 3.0 в базу AX 2009
• 31.12.10 07:15 (приблизительно - по данным об активности СУБД) завершение скриптов переливки данных из слепка - этот момент я это благополучно проспал
• 31.12.10 09:02 запуск контрольного списка обновления в AX 2009
• 31.12.10 09:23 запуск скриптов перед синхронизацией БД
• 31.12.10 09:23 запуск синхронизации БД
• 31.12.10 09:40 начало реальной активности (AX 2009 сперва собирает сведения и показывает, что будет делать при синхронизации, а уже потом собственно приступает к работе). За счет распараллеливания создания индексов, которые были удалены перед заливкой данных из 3.0, СУБД очень неплохо нагружается, см., скажем, http://i56.tinypic.com/2vht750.png
• 31.12.10 11:42 оракловая нода, к которой подключен AOS, на создании индексов по SalesTable объелась памяти, ушла в своп и начала отстреливать активные сессии. AOS попал под обстрел и свалился
• 31.12.10 11:56 как раз в тот момент, когда я перезапустил AOS и хотел было продолжить синхронизацию, у меня пропало соединение с тырнетом (где-то на полчаса, как оказалось). Надо было подумать о резервном канале
• 31.12.10 12:07 связался с коллегой, он возобновил синхронизацию
• 31.12.10 15.30 синхронизация завершилась, но с ошибками на создании нескольких индексов. Для прохождения контрольного списка нужно, чтобы ошибок не было, - пришлось разбираться
• 31.12.10 17:01 запущены пакетные обработки после синхронизации
• 31.12.10 23:53 скрипты конвертации данных завершили свою работу. на все про все ушло 6:51:53 "календарного" времени и порядка 76:31:22 времени БД (т.е. скрипты неплохо распараллелились). За счет тонкой настройки СУБД удалось ускориться по сравнению с последней тестовой конвертацией (82:25:15 времени БД). Я не ожидал, что скрипты конвертации отработают так быстро, поэтому заметил, что все закончилось, лишь полтора часа спустя
• 01.01.11 01:20 отключены конфигурационные ключи SysDeletedObjects40 и SysDeletedObjects41 и запущена повторная синхронизация (в принципе, это можно было отложить на потом).
• 01.01.11 08:40 вылезла ошибка с сообщением о том, что после удаления ненужных полей один из индексов стал индексировать ровно те же поля, что и другой индекс, а для СУБД это неприемлемо. Из-за того, что я не удалил точки останова на выводе ошибок, вылез отладчик, и синхронизация на этом застопорилась. Это событие я тоже проспал
• 01.01.11 10:15 я вырубил отладчик, и синхронизация продолжилась
• 01.01.11 13:28 синхронизация после обновления закончилась, начаты кое-какие дополнительные настройки, в основном касающиеся пользователей
• 01.01.11 16:10 список обновления выполнен полностью, начата выгрузка данных в кубы, чтобы сверить основные транзакционные таблицы "до и после".