Мда, похоже, что даже на такую элементарную операцию нужно таки FAQ написать...

Попытавшись объединить обсуждавшиеся вопросы и используя личный опыт попытался написать FAQ, который превратился в небольшую статью :)
Она, конечно, немного больше вопроса переименования и создания копии БД, тем не менее, надеюсь, будет интересна всем, кто с такими проблемами изредка (или, к сожалению, часто) сталкивается.
Читайте, обсуждайте, предлагайте, критикуйте...
Как создать копию БД с новым именем?
Как выгрузить базу утилитой dbexport и загрузить с новым именем утилитой dbimport?
http://www.sql.ru/faq/faq_topic.aspx?fid=710

На днях наблюдал любопытную ситуацию при загрузке БД dbimport-ом на 4-х процессорный сервак с рейдом.
Три достаточно больших таблички при загрузке очень сильно отличались по времени, хотя их структура была почти одинаковой, за исключением одной детали (о ней ниже). Итак, таблицы:
1. назовем ее table1 для простоты, ее размер в выгруженном виде 900М и 8,5 мил.строк грузится 10-15 минут.
2. table2 - ее размер в выгруженном виде 420М и почти 16 мил.строк грузится 15-20 минут (она чуть уже)
3. table3 - ее размер в выгруженном виде всего 200М и 4,5 мил.строк грузится, внимание, 500 минут, т.е. более 8 часов.
На этой таблице срывали загрузку несколько раз, т.к. не могли понять такого замедления. Потом начали исследовать. Выключили первичные ключи, т.е. никаких индексов уже не строится (хотя для первых двух таблиц они, практически, и не мешали), нет логирования, установили большие размеры экстентов (первичные и вторичные). Единственное замеченное существенное отличие было в одном поле table3 - оно типа byte и направлено в blobspace. Казалось бы, вот оно - главная причина такого замедления, но, самое смешное, что НИ ОДНОГО блоба в таблицу не грузится, это поле просто забыли выкинуть, как обычно, из старого дизайна. Смена конкретного blobspace на tablespace ничего не дала.
Т.о. получается (а других идей у меня пока нет), что при создании ссылок на блоб-ы, которых то и нет на самом деле, идет жуткое торможение (как минимум на порядок) загрузки данных в таблицу.
Проверить загрузку той же таблицы без блоба я не смог - и так потеряли пару дней, да и софт надо проверить, как он без него будет обходится...
Какие у кого еще идеи ? Может, кто то сталкивался с похожими симптомами или грузил такие табблицы с пустыми блобами ?

vasilisПопытавшись объединить обсуждавшиеся вопросы и используя личный опыт попытался написать FAQ, который превратился в небольшую статью :)
Она, конечно, немного больше вопроса переименования и создания копии БД, тем не менее, надеюсь, будет интересна всем, кто с такими проблемами изредка (или, к сожалению, часто) сталкивается.
Читайте, обсуждайте, предлагайте, критикуйте...
Как создать копию БД с новым именем?
Как выгрузить базу утилитой dbexport и загрузить с новым именем утилитой dbimport?
http://www.sql.ru/faq/faq_topic.aspx?fid=710
А что, никто так и не почитал ? Вряд ли там совсем нет ошибок или неточностей :)

Чемберлен 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-), то можно уменьшить их число - просто сначала надо самому (вручную) создать такой составной индекс, а уже потом включить связные ограничения. Сервер достаточно умный, чтобы определить, что нужный индекс для реализации внешнего ключа уже есть и строить новый нет необходимости.