01.03.2005, 11:41 | #1 |
Участник
|
"Глючит" импорт данных
Возникла необходимость периодически переносить 1-2 компании с одного сервера на другой, планировали использовать аксаптовый механизм экспорта/импорта компании. Наши разработчики утверждают что этот механизм сильно глючит и использовать его не стоит, надо говорят всю базу тащить средствами оракла.
Глюки заключались в том, что бывают случаи когда импорт завершается без ошибок, а в таблицах нехватает строк, т.е. таблица импортируется, но не полностью и так себя вели несколько таблиц или даже десятков. Причем на соседний компьютер тот же самый файл нормально импортился. Скажите, сталкивался ли кто-нибудь еще с такой проблемой или с другими? Вылечивали ли эти глюки? Можно ли использовать штатный механизм экспорта/импорта? |
|
01.03.2005, 11:51 | #2 |
Участник
|
Мое ИМХО
Переносить стоит средствами СУБД, ибо это будет как минимум быстрее. Я не смог дождаться окончания импорта средствами Аксапты. Экспорт прошел быстро. База была небольшая (меньше 10 Гб).
|
|
01.03.2005, 11:57 | #3 |
Участник
|
В данном случае речь идет о маленьких базах, скорость некритична
|
|
01.03.2005, 11:59 | #4 |
Участник
|
К сожалению, добавить ничеего не смогу, т.к. единственный раз дождаться окончания импорта не смог и впоследствии для копирования пользовался средствами SQL-сервера.
|
|
01.03.2005, 12:19 | #5 |
Модератор
|
Она не просто так такая медленная. Допустим, если поле было унаследованно от RecId (например, RefRecId), то пересчитываются все связанные RefRecId после вставки данных. Т.о. срабатывает и внутренняя логика системы... Так, что, если надо перебросить несколько таблиц, то тогда желательно воспользоваться именно этим механизмом. Если же Все данные - то тогда можно средствами бэкапа БД. Если же только несколько компаний, то надо проследить, чтобы не пересекались табличные коллекции и таблицы, не имеюющие разделения на компании. Остальные данные в компаниях разведены по dataareaid + recid. Рекомендую обратить внимание на данный момент.
С Уважением, Георгий. |
|
01.03.2005, 15:24 | #6 |
Участник
|
1. Несколько раз пытылся сделать экспорт бызы размером около 7 Гб, ставил на ночь - утром аксапта отваливалась с ошибками
2. Несколько раз сталкивался с "отъездами" некоторых таблиц - как правило терялись строки и при этом не было ошибок и часто было так что при импорте система утверждала что "такая запись существует" хотя при этом импорт делался в только что созданную компанию Вывод: доверия к Импорту Экспорту в аксапте как то нет Действительно удобно использовать когда нужно перенести несколько таблиц. Согласен с YellowSubmarine и George Nordic единственный и правильный путь - средствами самой CуБД. |
|
01.03.2005, 20:11 | #7 |
Модератор
|
Цитата:
Изначально опубликовано if_maks
1. Несколько раз пытылся сделать экспорт бызы размером около 7 Гб |
|
01.03.2005, 22:39 | #8 |
Member
|
Цитата:
Изначально опубликовано if_maks
... Несколько раз сталкивался с "отъездами" некоторых таблиц - как правило терялись строки и при этом не было ошибок и часто было так что при импорте система утверждала что "такая запись существует" хотя при этом импорт делался в только что созданную компанию Вывод: доверия к Импорту Экспорту в аксапте как то нет ... Самое большое, что выгружал — перекрестные ссылки (порядка 4,000,000 записей в общей сложности). Проблем с экспортом никогда не наблюдал. Импорт на среднестатистической рабочей станции производится примерно со скоростью 200-400 записей в секунду. Можете посчитать, сколько вам нужно времени для импорта. Возвращаясь к проблеме переноса данных. В общем случае лучше использовать средства экспорта-импорта Аксапты. Отказываться от них имеет смысл только в том случае, если время импорта слишком велико для вас. Также желательно от него не отказываться, если вы преносите не всю компанию, а только некоторые таблицы. Если вы переносите компанию целиком, то можно попробовать воспользоваться backup базы. В Аксапте есть функция для поднятия из backup определенной компании (Администрирование\Компании, кнопка Восстановление). Мне этой функцией пользоваться не приходилось, но читал, что она работает. Думаю, что быстрее штатного импорта должно быть. Если у вас есть виртуальные компании, то в общем случае задача не решается. Если есть желание — опишите конфигурацию и что и куда нужно переносить. Тогда вам могут что-то посоветовать на этом форуме.
__________________
С уважением, glibs® |
|
01.03.2005, 22:45 | #9 |
Member
|
Да, и еще. Я думаю, что штатную процедуру импорта также можно оптимизировать.
У меня есть подозрение, что если между таблицами нет ссылок по RecId, то их можно вынести в отдельную группу определения (имеет смысл это сделать для больших таблиц). Тогда импорт можно будет запустить параллельно (с одного или нескольких клиентов). В таком случае скорость импорта с высокой вероятностью может возрасти. Слишком большие таблицы также можно попробовать побить на части с помошью критериев отбора (при экспорте). Правда, не знаю как их импортировать, чтобы не было проблем с блокировками.
__________________
С уважением, glibs® |
|
02.03.2005, 13:25 | #10 |
Злыдни
|
Выгружал базу размером 12Gb. Все работает. Возможно дело в железе на клиенте.
|
|
03.03.2005, 00:50 | #11 |
Аксакал в отставке
|
имхо, опять проблема в механизме контроля целостности данных системы.
Может не все связанные таблицы включены в правило экспорта-импорта?
__________________
Девочка, никогда не произноси слова только за то, что они такие длинные и красивые; говори только то, что знаешь. (Л.Кэрролл "Алиса в стране чудес"). |
|