Опять ДБ трабл.

[alp 0]

Если взять сферическую базу, то...

На скорость записи, кроме железа, будут влиять всяческие ограничения целостности, индексы, логгирование и т.д. Поэтому на целевой базе (той, куда пишем) отключить все что только можно - оставить голую таблицу. В общем случае, построить индексы позже - быстрее, чем делать это одновременно с миграцией данных. Ну и выгнать всех с сервера, естесвенно - конкуренция за диск тоже не нужна, понятное дело.

 

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

Поскольку таблица большая, то запихнуть все одним куском не получится. Нужно читать таблицу кусками. Размер куска нужно подобрать, что может быть не совсем тривиальным. Например если куски слишком большие, то каждый из них будет провоцировать последовательное чтение таблицы. Соответсвенно, разбив миграцию на 10 больших шагов, ты последовательно просканируешь таблицу 10 раз. Это не есть эффективно.

Мне видится полезным разбить таблицу на более мелкие куски и сканировать их по индексу.

 

[Archer 1636]

Соответсвенно, разбив миграцию на 10 больших шагов, ты последовательно просканируешь таблицу 10 раз. Это не есть эффективно.

Мне видится полезным разбить таблицу на более мелкие куски и сканировать их по индексу.

 

Так чтобы разбить - разве всё равно 10 раз сканировать не придётся (в исходной ДБ)?

[alp 0]

А это уже зависит от магии исходных данных.

Если есть равномерно распределенный ключ, то можно приступать к миграции по индексу ключа частями по N% от общего количества записей.

(Число N зависит от реализации БД, какое количество записей она считает целесообразным сканировать по индексу, может варьироваться от 1 до 20%, если грубо)

 

Я имею ввиду, что выгрузка может быть произведена примерно таким псевдокодом:

for i in 1..10 loop
  select * from table
     where key > (i-1)*i and key <= i*X
end loop

Здесь X - это собственно размер одной части.

[alp 0]

Еще одна мысль - не использовать sql, а поискать средства прямой выгрузки/загрузки данных.

Смотрю у transbase есть нейкая утилита tbtar. Если удастся получить что-нить типа csv, то загрузить сие в mysql проблемы возникнуть не должно.

[AgentXXX 1]

Дядьки ораклоиды, нужна ваша подсказка.

Вот есть у меня такая хрень вызываемая ис SQL+.

-----------------------------
CONNECT &1

SET HEADING OFF
SET PAGESIZE 0
SET FEEDBACK OFF
SET TRIMSPOOL ON
SET LINESIZE 32000
SET ARRAYSIZE 1000
SET COLSEP "|"
ALTER SESSION SET NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS';
SPOOL "&2.&3._V_&4..DAT"
ALTER SESSION FORCE PARALLEL QUERY PARALLEL 4;
SET FLUSH OFF
SET TERM OFF

@&5.V_&6._XKAI.SQL

SPOOL OFF
EXIT

 

5 i 6 paramс файл где самый обычнызапрос но с использованием разделителя.

Больше никаких настроек.

SELECT AMND_STATE||'|'||TO_CHAR( AMND_DATE, 'YYYY-MM-DD HH24:MI:SS' )||'|'||AMND_OFFICER||'|'||AMND_PREV
etc

 

Сволочь ораклоидная матерится в спуле:

SP2-0734: неизвестное начало команды "SELECT A..." - оставшаяся часть строки игнорируется.

 

Мне почему-то кажется, что по этому поводу была какая-то хрень с передачей параметра.Но вспомнить не могу.

А, ну то, что прямо записанный запрос внутри файла работает прекрасно я не говорю.Это само собой.

 

@&5.V_&6._XKAI.SQL

Т.е. в этом месте если прямо селектятину всуну - оно песТни поёт и у меня полный хэппи.

[Archer 1636]

5 i 6 paramс файл где самый обычнызапрос но с использованием разделителя.

Больше никаких настроек.

SELECT AMND_STATE||'|'||TO_CHAR( AMND_DATE, 'YYYY-MM-DD HH24:MI:SS' )||'|'||AMND_OFFICER||'|'||AMND_PREV
etc

 

Ищи пустые строки в файле. А если выполнение идёт на юниксе, то ищи ещё и связку "CR LF", он же злополучный "^M" в vi.

[AgentXXX 1]

выполнение идёт на юниксе

Solaris

Ищи пустые строки в файле.

ещё и связку "CR LF",

В курсе, нЫма.

[AgentXXX 1]

ГЫ!

Не сохраняйте файл в UTF8 формате и всё будет намана.

[Archer 1636]

Не сохраняйте файл в UTF8 формате и всё будет намана.

 

А теперь расскажи, чем ты на солярке (в консоли) проверял содержимое файла на лишние строки, что ничего "странного" не заметил

[AgentXXX 1]

На солярке запускали дядьки ЭТЛщики из среды САСовской и у них не было саще.

Пока меня не надоумила высшая сила посмотреть на файлы внематочно.

[Yevgen35 0]

od -bc

[Archer 1636]

На солярке запускали дядьки ЭТЛщики из среды САСовской и у них не было саще.

Пока меня не надоумила высшая сила посмотреть на файлы внематочно.

 

Вооот... пока своими глазами файлы не увидишь, не отвечай "В курсе, нЫма. "

Никому нельзя доверять, даже себе

 

[AgentXXX 1]

Вооот... пока своими глазами файлы не увидишь, не отвечай "В курсе, нЫма. "

Так я пробелы и прочее сразу пересмотрел, просто мысль, что на рус.кампухтере могут сохранять в UTF8 формате пришла чуть позже.

[serj_nv 2554]

Пока меня не надоумила высшая сила посмотреть на файлы внематочно.

Новое слово и технологии в синтаксическом разборе SQL

[Yevgen35 0]

И чего только эти ребята, юзающие продукты MS, не напридумывают

чтобы только не использовать простые Unix-ые команды.