DaugavaКлюч -X по идее должен вывернуть в какой-то формат ASCII символы <32, в том числе и #13#10. Судя по ошибке проблема действительно в DOS2UNIX (кстати она описана в FAQ-е).

При выгрузке через pipe перед компрессией можно вставить и dos2unix.

Я не совсем понимаю как выгрузить с windows в pipe =\

zaietsЯ не совсем понял - а зачем выгружать на винде?
Ведь можно выгрузить сразу на Линукс.
Т.е. развернув на линуксе IDS и через тот же dbaccess или другую тулзню выгрузить данные.

Кстати вопрос - скорость унлоада данных на 1Г если
запустить локально на винде и удаленно с линукса какая?

а как быть с переносами строк внутри самих данных?
Основная засада в том, что внутри анлоадов попадаются переносы строк.
Анлоадом на Linux побеждаются концы срок.

victor16zaietsЯ не совсем понял - а зачем выгружать на винде?
Ведь можно выгрузить сразу на Линукс.
Т.е. развернув на линуксе IDS и через тот же dbaccess или другую тулзню выгрузить данные.

Кстати вопрос - скорость унлоада данных на 1Г если
запустить локально на винде и удаленно с линукса какая?
В таком случае - зачем вообще выгружать в файлы? Почему нельзя сразу вставить данные оператором INSERT INTO <local_server> SELECT FROM <remote_server>. Насколько я знаю, в информиксе такой оператор выполняется как bulk-вставка, а не по одной записи.

Это занимает слишком много времени.

А возможен ли экспорт в tape, размера больше чем 2 гб?

Кажется меня совсем проклинило, ключ -s 0 по идее меня спасет.

Нет, ключик -S не спасает =(

Смонтировал диски нового сервера на старом. Создал fifo файл.
mkfifo tape
dos2unix < tape > tape1
Начал экспорт из виндовой базы в fifo.

dbexport dbname -cqX -ss -t m:\tape -b 16 -s 0 -f m:\dbname.sql < i:\keys

И все бы хорошо, но экспорт падает с ошибкой "Write tape failed".

В чем засада может быть?
Не справляется fifo?

zaietsandjeoА возможен ли экспорт в tape, размера больше чем 2 гб?
А с чего вы взяли что для вашей версии IDS ограничение в 2Г?
с 9.4 уже этого ограничения не было

Это меня проклинило. Попробовал еще раз. С виндовой машины все нормально стало выгружаться.

Правильно ли я понимаю, что при записи на samba шару концы строк все равно будут виндовыми?

Вчера-сегодня прогнал dbimport. Результат не радует. На все ушло 22 часа.
Создание таблиц и загрузка данных примерно 14 часов. Создание индексов, процедур, констрейнтов- 8 часов.

Видимо надо явно тюнить новый сервер. Куда копать?

zaietsandjeoПоследовательная загрузка заняла около 22 часов и была мной остановлена, т.к. за это время даже не начали переноситься самые крупные таблицы (от 20 до 46 Гб)


С коллегой общался, вспомнил про вас.
Вы учтите, что дефолтный pagesize на ваших платформах разный и если таблица на 46Гб
это 1 partnum на 46Г "реальных" данных - то переносить нужно если без фрагментации как минимум в пространство с размером страницы 4К либо сразу же фрагментируйте (если лицензия позволяет)


Большие таблицы фрагментируются.

zaietsЯ задал вопрос. так как непонятно - что тормозит у вас вставку insert ... select
По идее, она на 100МБ даже не должна так тормозить как у вас при дефолтных настройках.
Если выгрузка в файл одинакова, значит что-то не так с вставкой
а это уже сужает поиск проблемы.
Можно еще локально и удаленно сравнить unload to <nul | /dev/null>

Сделаю в понедельник. Но кажется что тормозит все-таки Linux =\

ВыбегаллоandjeoВчера-сегодня прогнал dbimport. Результат не радует. На все ушло 22 часа.
Создание таблиц и загрузка данных примерно 14 часов. Создание индексов, процедур, констрейнтов- 8 часов.

Видимо надо явно тюнить новый сервер. Куда копать?

Делать загрузку из файлов, в параллели. Выгрузку тоже. Выгрузить предварительно часть данных.

У меня в подобной ситуации были:
- stage0 - предварительная выгрузка данных, которые уже не могут быть изменены (таблицы самопального аудита) - выполняется вне окна миграции.
- stage1 - параллельная выгрузка остальных данных, я написал скриптец для анализа размеров таблиц и разбросал выгрузку на 5 потоков примерно одинакового объема.
- stage2 - drop / create database, параллельная загрузка данных, параллельный index build, навеска PK, FK, создание view, sequences, SP, triggers
- stage3 - сравнение с контрольной базой на другом сервере (slave из репликации)

Ну там и по мелочам - подобрать новые размеры начальных экстентов, индексы строить с fillfactor 80, разрешить PDQ для их строительства.


То есть "Unload to <> Select * from" и "Load from <> insert into"?
Я изначально думал так делать, но в некоторых таблицах содержатся переводы строк, которые я не знаю как победить.

dbexport -X/dbimport -X от них избавил, но непонятно на какой фазе. На импорте или экспорте.
Внятного комментария о том как работает ключ -X я не нашел =\


Как можно избавиться от перевода строки в анлоад файле?

Журавлев ДенисandjeoКак можно избавиться от перевода строки в анлоад файле?В который раз читаю ваши стоны про конец строки, чувствую кто-то что не понимает. Опишите вашу проблему чуть подробнее типа:
1. на виндовом сервере выгружаю unload-м.
2. копирую на линукс по фтп (в режиме ascii), размер файла по понятным причинам уменьшается.
3. гружу load-м на линукс сервере.
4. вижу что концы строк исчезли/появились лишние? ААААААААААААА?!!!!

1. Делаю анлоад на винде.

2. Копирую на линукс,прогоняю через dos2unix,убирая концы строк.

3. Загружаю данные лоадом.
Данные не загружаются из-за того,что внутри данных есть переводы строки. Нажатия энтера в комментариях.