iBase.ru Forum

Факу почитал, доку изучил, список багов просмотрел - ничего нету...

Краткое изложение :
Нарисовалась тут небольшая такая базка - 2400000 страниц по 8к.
Жила она под ИБ 6.0 +NT, потом на 7.0+XP.

Полсотни мелких таблиц\справочников, десяток развязочных таблиц и одна (НО ОЧЕНЬ ЗДОРОВАЯ) собственно основная таблица (~25млн записей, 200+ полей всех сортов)
Регулярный обмен данными между отделениями конторы(вставка,упдате,делете).
Время от времени происходит перетаскивание базы между серверами, падения и проч.радости.

Вот счас сижу на последствиями очередного переезда (сказя рэйд, 2проца по3х, 4гб памати - шоколадка прям...в обертке из наираспоследнейшего линуха).
Понадобилось перетащить кусочек данных (ок 3млн записей) из прежнего экземляра.(прежний подло и тихо умер - отдельная история)
Выдирать в скрипт - нереально.
Либо выходит файлик на....короче,никак нереальный .
Либо ручное выдирание в отдельные - выйдет их тыщи три.
В ЛОМММ!!!!

И вот черти меня дернули -

create external table main_table_ext ...... ;
insert into main_table_ext select * from main_table where (sourcer=123456);
commit;

Файлик на 3+ гб.

Копирнул на новый сервер, и там

create external table main_table_ext ...... ;
insert into main_table select * from main_table_ext;

Там - в ехтернал вылил, тут из ехтернал в основную залил

IBExpert часики кажет, файлики визуально пухнут - оставил на ночь.
А утром -
System error
Device not responding
I\O Error for file ext_table.ibd

Место под своп и базу - примерно в 20ть раз больше вообще всего занятого на дисках обьема.

И при бэкапэ не виснет...IB сервер молча ПАДАЕТ.
gfix клинит....


Вопросы :

1)Есть каие-то ограничения на размер файла\кол-во записей\кол-во полей для EXTERNAL TABLE? - чутье подсказыввает, что переступил некую запретную черту.

2) возможные мероприятия по реанимации базы?
Изза размеров каждый бэкап чуть ли не директор санкционировал - ибо стояли около суток
прогонять сейчас данные за месяц как-то не хочется, да и бардак там начнется невероятный.


3)А вообще - кто нибудь использовал external table для переброски данных?

Жила она под ИБ 6.0 +NT, потом на 7.0+XP.

как бы, надо IB 7.1 SP2, а не 7.0, и уж тем более не 6.0.

Выдирать в скрипт - нереально.
Либо выходит файлик на....короче,никак нереальный .
Либо ручное выдирание в отдельные - выйдет их тыщи три.

можно еще в ibsql.pas найти классы для импорта-экспорта данных. там и формат external table поддерживается, и csv.

и - чего-то странно, что база в 18 гиг у тебя сутками бэкапится. раз "факу" и "доку" изучал, то с ключом -g бэкап должен намного быстрее происходить, и без напряжения.

по поводу больших файлов - вполне может быть что серверу не понравился размер ext table больше 2-х гиг. хотя непонятно, как он его тогда создал. Но залить трехгиговый файл в одной транзакции - это, конечно, не для слабонервных. Лично я бы не решился.

И при бэкапэ не виснет...IB сервер молча ПАДАЕТ.
gfix клинит....

а по человечески можно объяснить, без "пальцов"?

3)А вообще - кто нибудь использовал external table для переброски данных?

натюрлих!

Внешние таблицы размером более 2 гиг сервером не прочитаются.

Предлагаю использовать несколько внешних таблиц...

можно еще в ibsql.pas найти классы для импорта-экспорта данных. там и формат external table поддерживается, и csv.

Thanks.

и - чего-то странно, что база в 18 гиг у тебя сутками бэкапится. раз "факу" и "доку" изучал, то с ключом -g бэкап должен намного быстрее происходить, и без напряжения.

Не сутками, последний раз - около 6 часов.Сутки вылазиют из организационных сложностей.
А нафига он мне с -g ? у меня мусора набирается за месяц от 50 000 страниц.Много желающих пописать, да и сделаны некоторые вещи не самым оптимальнйешим образом.Например, рисование некоторых отчетов идет через складывание данных во временную таблицу с обязательным ROLLBACK опосля.Делают это несколько десятков юзверей и частенько.
Иногда эта радость конечно отваливется.

по поводу больших файлов - вполне может быть что серверу не понравился размер ext table больше 2-х гиг. хотя непонятно, как он его тогда создал.

- больше (?)мб .
select count(*) from ext_table ; - файл 340мб
дает тот же результат . Девица не отвечает, типа, взаимностью.

Но залить трехгиговый файл в одной транзакции - это, конечно, не для слабонервных. Лично я бы не решился.

- а че такого? данные от некоторых филиалов валятся раз в месяц.В иное первое число до гига набегает.
Вначале мелкими ложками по 5-10тыс вливается в таблицу приемник, опосля процедурой неторопясь раскаладывается - но уже одной пачкой.Ни разу не потухло.

И при бэкапэ не виснет...IB сервер молча ПАДАЕТ.
gfix клинит....
а по человечески можно объяснить, без "пальцов"?

gbak ...... - через пару минут ibserver исчезает из списка процессов ни слова не сказав в лог.GBK файлы 0 байт.
gfix ... - ну проторчал он часа три ни слова ни сказав.
Да и вопрос с ресторе вообще снят - уже поднял февральский бэкап и прокачал все изменения.Вот если бы архив пополняшек не уцелел - тады ОЙ.

dimitr писал(а):Внешние таблицы размером более 2 гиг сервером не прочитаются.

Однако успешно пишутся.
3+мб, визуально FARom - что в начале, что в конце, что в середине все выглядит как самая обычная ехт-табля
Неужто глюк нащупал??:)

Будь скромнее. Этому багу сто лет уже.

А нафига он мне с -g ? у меня мусора набирается за месяц от 50 000 страниц.Много желающих пописать, да и сделаны некоторые вещи не самым оптимальнйешим образом.Например, рисование некоторых отчетов идет через складывание данных во временную таблицу с обязательным ROLLBACK опосля.Делают это несколько десятков юзверей и частенько.

эээ... тогда при чем тут сборка мусора бэкапом? делай gbak -b -g, а следом - gfix -sweep. Без свипа твой бэкап со сборкой мусора не даст эффекта sweep.

Всем спасибо!!!!
вопросы закрыты...


Эх, знали бы вы что это за база