2013-02-26 2 views
4

Прежде всего, извинения, если этот вопрос кажется стеной текста, я не могу придумать способ его форматирования.Извлечение данных из ОЧЕНЬ старой машины Unix

У меня есть машина с ценными данными (около 1995 года), на компьютере работает unix (SCO OpenServer 6) с какой-то базой данных, хранящейся на нем.

Данные обычно доступны через программный пакет, срок действия которого истек, и разработчики больше не торгуют.

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

Я могу получить доступ к машине через драйвер ODBC (SeaODBC.dll) по сети, так я планировал извлечь данные, но до сих пор я забирал 300 000 строк всего за 24 часа, в общей сложности оцениваю там будет около 50 000 000 рядов, поэтому при текущей скорости это займет 6 месяцев!

Мне нужен либо быстрый способ извлечения данных с устройства через ODBC, либо способ извлечения всей БД локально на компьютере на внешний диск/сетевой диск или другой внешний источник.

Я играл с интерфейсом unix, и только большие файлы, которые я могу найти, находятся в массивной матрице односимвольной папки (например, A \ G \ data.dat, A \ H \ Data.dat).

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

Редактировать

Копает по файловой системе я нашел папку под root > L, которая содержит множество отдельных литерных папок, каждую отдельная литерную папка содержит несколько отдельных папок письма.

Есть также файлы, которые названы после того, как таблицу мне нужно (например, «ooi.r»), которые имеют следующий формат:

<Id> 
[] 
    l for ooi_lno, lc for ooi_lcno, s for ooi_invno, id for ooi_indate 
    require l="AB" 
    require ls="SO" 
    require id=25/04/1998 
    {<id>} is s 
    sort increasing Id 
+0

может быть лучше подходит для http://unix.stackexchange.com/ – amphibient

+0

интересный вопрос, также можно попробовать http://dba.stackexchange.com – jamesTheProgrammer

+3

Как первый разрез, я бы запускал соединение odbc локально на машины и извлеките его локально. Узкое место производительности может быть связано с сетью. Кроме того, я предполагаю, что запрос представляет собой простой запрос типа «select *», предпочтительно из базовой таблицы, а не из представления. –

ответ

0

Я, наконец, решил проблему, выполнив запрос с использованием другого инструмента (а не через MS Access или MS Excel), работал массово быстрее, закончил с использованием DaFT (Database Fishing Tool) до SELECT INTO текстовым файлом. Обработал все 50 миллионов строк за несколько часов.

Кажется, драйвер dll, который я использовал, не работает с любыми продуктами MS.

1

Я не признаю эти виды имен файлов A\G\data.dat и так далее (имена файлов с обратной косой чертой в них ???), и это, вероятно, будет проприетарным форматом, поэтому я не ожидал бы многого от этой проспекта. Вы можете попробовать запустить file, чтобы узнать, находятся ли они в любом распознанном формате, просто чтобы увидеть ...

Я бы предложил улучшить скорость извлечения данных через ODBC путем виртуализации системы. Современный компьютер будет иметь более быструю память, более быстрые диски и более быстрый процессор и может извлечь данные намного быстрее. Вам придется извлечь образ диска из старой системы, чтобы виртуализировать его, но, надеюсь, один последовательный проход при чтении всего с его диска не будет слишком медленным.

Я не знаю, что такое архитектура этой системы, но я думаю, что это x86, что означает, что ее виртуализация может быть не слишком сложной (в зависимости от того, насколько OS OS OpenServer 6 согласуется с виртуализацией). Вам придется использовать гипервизор, который поддерживает полную виртуализацию (а не паравиртуализацию).

+0

Чтение дисков может быть сложным, он запускает массив scsi из 4-х дисков, и у меня нет никакого оборудования scsi для его подключения к :( – bendataclear

+0

Вытягивание образа диска виртуального массива с 'dd' из самой машины и потоковой передачи сеть в другое место просто может оказаться приемлемо быстрой ... если узким местом производительности на самом деле является сеть, как предполагает [Gordon Linoff] (http://stackoverflow.com/users/1144035/gordon-linoff). В любом случае , это просто идея. Удачи. – Celada