CftClub.ru
Клуб специалистов ЦФТ-Банк

Веселый формат - Long Raw :?

 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA
Предыдущая тема :: Следующая тема  
Автор Сообщение
Denis Scar
Участник со стажем


Вступление в Клуб: 28.09.2007
СообщениеСр Ноя 28, 2007 11:39   Веселый формат - Long Raw :? Ответить с цитатой
Полезность: Нет оценки
Есть такой "веселый" формат данных в ИБСО, хотя в любой базе он есть.
Суть проблемы - крайне долго экспортируется и импортируется данный тип данных (прочувствовал когда делал export из Oracle 8 и import в Oracle9 ).
Вопросы:
1. Кто-нибудь решал эту проблему и как (в рамках данных версий Oracle) ?
2. Если ли опыт export-import в Oracle 10g и какой он ?

С меня, если что, пиво за полезную инфу Smile, в рамках Новосибирска доставка - бесплатно. Остальные места за счет отвечающего Wink
_________________
shutdown abort;
shutdowning database in progress ...
AlexV
Гуру


Вступление в Клуб: 29.06.2007
СообщениеСр Ноя 28, 2007 12:01   Re: Веселый формат - Long Raw :? Ответить с цитатой
Полезность: Нет оценки
BUFFER=100...00
_________________
IT-Команда предлагает свои услуги:
http://www.cftclub.ru/viewtopic.php?t=909
Denis Scar
Участник со стажем


Вступление в Клуб: 28.09.2007
СообщениеСр Ноя 28, 2007 12:08   Re: Веселый формат - Long Raw :? Ответить с цитатой
Полезность: Нет оценки
AlexV пишет:
BUFFER=100...00


А поподробнее можно ?
Выставлял 10 MB и 100 MB - Примерно одна и та же скорость.
При этом небольшая нагрузка на винт, дает очень большой отрицательный эффект.
_________________
shutdown abort;
shutdowning database in progress ...
AlexV
Гуру


Вступление в Клуб: 29.06.2007
СообщениеСр Ноя 28, 2007 12:24   Re: Веселый формат - Long Raw :? Ответить с цитатой
Полезность: Нет оценки
Я экспортирую по сети с SUN на WINDOWS, потом импортирую локально на WINDOWS. BUFFER=200 000 000
Это значение получено экспериментально: от демонстрационного ЦФТ-ного (банальным добавлением ноликов). За сутки - успеваю поднять дамп на другой платформе:

В 03:00 запускается экспорт с SUN-а, к 08:00 он заканчивает.
Следом за ним стартует импорт и где-то чуть за полночь (00:00) финиширует (локально на WINDOWS)

Пока не добавлял нолики к BUFFER - не успевал.

ТТХ: База = 60Г, Дамп = 16Г.
_________________
IT-Команда предлагает свои услуги:
http://www.cftclub.ru/viewtopic.php?t=909
Denis Scar
Участник со стажем


Вступление в Клуб: 28.09.2007
СообщениеСр Ноя 28, 2007 12:39    Ответить с цитатой
Полезность: Нет оценки
Это немного не то Sad
Вы в целом тюнили Экспорт-Импорт базы.
Дополню свой вопрос инфой.
У нас стоит СПЭД (Банк-Клиент) от ЦФТ, как часть функционала.
Там почти все в Long Raw, если расматривать ГБ, то это порядка 20 гигов (набор таблиц).
Export - 20 минут
Import - 9 часов
Конфигурация - 32 процессора Alpha, Eva (запись в пике - 80 метров в секунду, чтение в пике -190 метров в секунду).
При этом процесс export-import был запущен на сервере где никто не работал !!!!!

Main_Docum (27 гигов на тот момент) для сравнения
Export - 1 час, 10 минут
Import - 4 часа
При этом хочется сказать, что когда экспортилась-импортилась Main_Docum работало еще порядка 20 процессов export-import и порядка 200 процессов создания индексов, дисковая система та же самая.


Видно я тут один с таким объемами маюсЯ Sad
_________________
shutdown abort;
shutdowning database in progress ...
AlexV
Гуру


Вступление в Клуб: 29.06.2007
СообщениеСр Ноя 28, 2007 16:13    Ответить с цитатой
Полезность: 1
Ну, вообщем, вот:

BUFFER
Default: operating system-dependent. See your Oracle operating system-specific
documentation to determine the default value for this parameter.
Specifies the size, in bytes, of the buffer used to fetch rows. As a result, this
parameter determines the maximum number of rows in an array fetched by Export.
Use the following formula to calculate the buffer size:

buffer_size = rows_in_array * maximum_row_size

If you specify zero, the Export utility fetches only one row at a time.
Tables with LONG, LOB, BFILE, REF, ROWID, LOGICAL ROWID, DATE, or type
columns are fetched one row at a time.


Note: The BUFFER parameter applies only to conventional path Export. It has
no effect on a direct path Export.

PS: "буфера никогда не бывает много" Wink
_________________
IT-Команда предлагает свои услуги:
http://www.cftclub.ru/viewtopic.php?t=909
Denis Scar
Участник со стажем


Вступление в Клуб: 28.09.2007
СообщениеСр Ноя 28, 2007 20:15    Ответить с цитатой
Полезность: Нет оценки
Ах, да забыл сказать Smile
У меня был direct.

Как видно из этой статьи данным форматам по барабану на твой буфер.
Да и потом считается, если память не подводит, директ быстрее работает, так как идет напрямую чтение, без дополнительных расходов, когда по-другому.
ВотЪ.

А по строчке, которая черти знает какого размера, импорт по кусочкам вставляет, а не целым куском, так как поле динамического размера. Поэтому и тормоза при вставке, да и когда экспорт тянет данные.

Проблема все еще актуальна Wink


Кажется так, надо будет проштудировать металинк.
_________________
shutdown abort;
shutdowning database in progress ...
Denis Scar
Участник со стажем


Вступление в Клуб: 28.09.2007
СообщениеЧт Ноя 29, 2007 06:29    Ответить с цитатой
Полезность: Нет оценки
https://metalink.oracle.com/metalink/plsql/f?p=130:14:5578622386700605665::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,155477.1,1,1,1,helvetica

1.2. Conventional path Export.
Conventional path Export uses the SQL SELECT statement to extract data from tables. Data is read from disk into the buffer cache, and rows are transferred to the evaluating buffer. The data, after passing expression evaluation, is transferred to the Export client, which then writes the data into the export file.

1.3. Direct path Export.
When using a Direct path Export, the data is read from disk directly into the export session's program global area (PGA): the rows are transferred directly to the Export session's private buffer. This also means that the SQL command-processing layer (evaluation buffer) can be bypassed, because the data is already in the format that Export expects. As a result, unnecessary data conversion is avoided. The data is transferred to the Export client, which then writes the data into the export file.

2.1. Direct path Export can be much faster than Conventional path Export because the SQL command-processing layer is bypassed.
_________________
shutdown abort;
shutdowning database in progress ...
Denis Scar
Участник со стажем


Вступление в Клуб: 28.09.2007
СообщениеЧт Ноя 29, 2007 06:34    Ответить с цитатой
Полезность: Нет оценки
Видно не судьба
https://metalink.oracle.com/metalink/plsql/f?p=130:14:5578622386700605665::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,93763.1,1,1,1,helvetica
Статья хорошая, но

Large Imports of LONG Data:
---------------------------

Importing a table with a LONG column may cause a higher rate of I/O and disk
utilization than importing a table without a LONG column.

There are no parameters available within IMP to help optimize the import of these
data types.
_________________
shutdown abort;
shutdowning database in progress ...
Denis Scar
Участник со стажем


Вступление в Клуб: 28.09.2007
СообщениеЧт Ноя 29, 2007 06:37    Ответить с цитатой
Полезность: Нет оценки
Так что, в заключение, можно сказать - По возможности избавляться от данного формата, если предстоит переезд на другую версию или платформу. Ибо тормознет вас не по детски Wink
_________________
shutdown abort;
shutdowning database in progress ...
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Oracle DBA Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Рейтинг@Mail.ru