Přejít na obsah

Recommended Posts

Odesláno

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

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

 

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

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

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

 

  • Odpovědi 176
  • Created
  • Poslední odpověď

Top Posters In This Topic

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

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

 

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

Odesláno

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

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

Odesláno

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

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

  • 2 months later...
Odesláno

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

Вот есть у меня такая хрень вызываемая ис 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

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

Odesláno
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.

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

Solaris

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

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

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

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

 

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

Odesláno

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

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

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

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

 

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

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

 

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

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

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

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

Odesláno

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

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

Pokud chcete odpovídat, musíte se přihlásit nebo si vytvořit účet.

Pouze registrovaní uživatelé mohou odpovídat

Vytvořit účet

Vytvořte si nový účet. Je to snadné!

Vytvořit nový účet

Přihlásit se

Máte již účet? Zde se přihlašte.

Přihlásit se



  • Kdo si právě prohlíží tuto stránku

    • Žádný registrovaný uživatel si neprohlíží tuto stránku
×
×
  • Vytvořit...