Чемберлен vasilisТ.о. получается (а других идей у меня пока нет), что при создании ссылок на блоб-ы, которых то и нет на самом деле, идет жуткое торможение (как минимум на порядок) загрузки данных в таблицу.
Проверить загрузку той же таблицы без блоба я не смог - и так потеряли пару дней, да и софт надо проверить, как он без него будет обходится...
Какие у кого еще идеи ? Может, кто то сталкивался с похожими симптомами или грузил такие табблицы с пустыми блобами ?
А с какой скоростью логические журналы при этом заполнялись? Они реально копировались или фиктивно? Сколько места оказалось занято в blobspace (по onstat -d update)?
Так как загрузка шла dbexport то, естественно, логирования на базе не было.
В любом случае, все лог.журналы идут "в сад", т.е. nul.
В последнем варианте, где я замерил время загрузки, блобы уже грузились в собственное табличное пространство, а не в блобспейс.
Вот размеры занятого табличного пространства, но надо учитывать, что в таблицу продолжается загрузка и сейчас там уже 11 576 261 строка и размер строки (rowsize из tabinfo) =157 байт.
ЧемберленИ что там вставлялось в столбец? Просто || в .unl-файле?
Хочу проверить идею, что по странице (4Кб) на каждое значение блоба таки выделялось...
Просто || в .unl-файле.
У меня была такая мысль, но, вроде, не подтверждается, т.к. только на эти пустые зарезервированные страницы ушло бы 11 милл.страниц, а их всего там 350 тыс.

ЧемберленА что показывает статистика по пространствам:
onstat -D
и
onstat -g iof
onstat -g iov
Понятно, что целиком страницы может и не меняются, но могут резервироваться отдельно, что может сильно нагружать логические журналы (независимо от режима журнализации базы)...
Та статистика (для конкретного случая) уже "канула в лету".
А вот о нагрузке на логи мысль интересная. Надо бы помоделировать, да где же это время взять... :)

Журавлев ДенисЭто точно dbimport. Проверил на 5 млн, 6 мин. dbimport -- 1 мин load.
А проверь теперь простую таблицу того же размера, но без Блоба.
Я подозреваю, что время будет примерно таким же.
Т.е. меня не интересует разница между dbimport и load. Интересует - есть ли разница в работе dbimport при загрузке таблиц с блобами и без них, т.к. в моем случае эта разница была просто огромной (хотя, возможно, причина и в другом...).

Журавлев ДенисЯ менял прямо в .sql от экспорта byte на integer, время сокращалось (в шесть раз) до нормального -- 1 мин.
О-о, вот это уже интереснее. Но все же разница (в шесть раз) не такая уж и значительная. Я могу ее хоть как то объяснить. Но в моем случае, эта разница просто огромная (15 минут и 8 часов)...
Журавлев ДенисБаг виндового dbimport -- зуб даю.
Очень на это похоже, тем более, что и версия IDS довольно старая (9.30.ТС2), да и глюков в этой версии тоже прилично...
Спасибо за помощь!

А почему "заменить" лучше, чем "исправить" ? Тем, что "исправить" может подразумевать "удалить" упоминание ДБ-пространства ?
А если у него все таки других пространств нет - мы ведь говорим о случае, когда надо создать копию для тестирования да еще и на другом сервере, возможно уменьшенную.
А на ошибку "142 ISAM error: overflow of tblspace page" я никогда не наталкивался. Это что, часто бывает ?
Короче, если настаиваешь на исправлении данного FAQ, то я исправлю :)

АнатоЛойДругих пространств возможно и нет - но раз пространство было ЯВНО прописано в старой схеме - лучше ЯВНО написать имя хотя бы того же пространства, в которое грузится БД (оно же есть - значит есть что написать :). Это приведёт к созданию detached индекса
detached индексы создаются по умолчанию во всех версиях, начиная с 9.3 (если не ошибаюсь). Неужели ваше замечание актуально и для этих версий ?

АнатоЛой
поля: около 50 integer , пару DATE, пару DATETIME, 8 FLOAT
около 80 индексов: 30 по одному полю, 2 по двум, 16 по трём и 24 по 4-ём...

Мда, а я то ругал наших проектировщиков и девелоперов :))
Такого я даже на наших монстровидных структурах с серверами приложений и объектным хранилищем не видел...
И большая часть индексов автоматические, из справочников ?
Это с какой же скоростью вставляются записи в такую табличку ?

АнатоЛой vasilis
Короче, если настаиваешь на исправлении данного FAQ, то я исправлю :)
Хм... Да честно говоря, даже интересно стало...Ау, неужто никто больше не натыкался?
Пока молчат... Значит, пока не исправляю. :)

АнатоЛойМожет я чего не понимаю, но это типичная схема с таблицей фактов (типа "звезда" :), даже в доке по информиксу такое упоминается)... vasilis
Это с какой же скоростью вставляются записи в такую табличку ?

Штук 70 в сек... Средняя ("по больнице":) требуемая скорость вставки (исходя из объёмов):1 запись в 2 сек... Т.е., может и на пределе - надо замыслиться :)
Учти, что скорость будет падать нелинейно (в зависимости от кол-ва строк).
И вот когда она станет совсем плохой вы сначала будете усиливать железо, а уже потом задумаетесь о той самой "типичной схеме" ?
В хранилищах данных (OLAP, DSS) уже свои правила и типичные приемы работы и массовые индексы там больше мешают. И часто делается ДЕнормализация... И таблица может делиться по ширине на часто и редко используемые данные...
Разве вы, кроме вставки, больше ничего с этими данными не делаете ?
И вот для того, чтобы взять пару столбцов для обработки вы вынуждены тянуть с дисков всю длину строки... А апдейт строки сколько будет менять в многочисленных индексах...

АнатоЛой onstat-
Если на таблице построены индексы
create index ..... on table (filed1);
create index ..... on table (field1,field5);
create index ..... on table (field1,field5,field28);
можно смело отказаться всех кроме последнего.
Он полностью их заменит.

Это я понимаю... Также, насколько я понимаю, советом воспользоваться можно наполовину, поскольку
...нет возможности отказаться от
....
который построен для поддержки внешнего ключа
Если такие автоиндексы все же есть (как указал onstat-), то можно уменьшить их число - просто сначала надо самому (вручную) создать такой составной индекс, а уже потом включить связные ограничения. Сервер достаточно умный, чтобы определить, что нужный индекс для реализации внешнего ключа уже есть и строить новый нет необходимости.