2012-02-01 4 views
1

У меня есть файл управления, loader.ctl, в C:\oracle\product\10.2.0\oradata\orcl.данные не заполняются из sql-загрузчика

Содержание loader.ctl файла

load data 
infile 'd:\mydata\test.csv' 
into table emp1 
fields terminated by "," optionally enclosed by '"'   
(empno, ename,job,mgr,hiredate,sal,comm,deptno) 

emp1 таблица уже присутствует в базе данных, и есть 9 записей в test.csv

я выполнил loader.ctl из SQLLDR:

enter image description here

Теперь, когда я проверяю свою базу данных, я не нахожу записей в emp1 ... почему это так? После фиксации почему данные не заполняются в таблице?

+0

ли SQL * Loader указать, что он загружен 9 строки? Если бы это было так, я бы сделал ставку на то, что вы запрашиваете другую таблицу, чем SQL * Loader загрузил данные (например, в другую базу данных или другую схему в одной базе данных) –

+0

@Justin: Как вы видите на рисунке , достигнута точка фиксации достигнута .... и я вхожу в систему через scott/tiger и как я могу найти свою текущую схему –

+0

Я не вижу изображение. Но это может быть проблема межсетевого экрана. Если вы входите в систему с использованием пользователя SCOTT, ваша схема будет представлять собой схему SCOTT, если вы явно не измените ее с помощью «ALTER SESSION SET current_schema» после входа в систему. Вы уверены, что подключаетесь к той же базе данных, SQL * Loader загружает данные в? –

ответ

7

Во-первых, вы не указали файл журнала, что означает, что он, вероятно, находится там же, что и ваш файл ctl, но он также может быть в каталоге, который вы назвали SQL * Loader, или в каталоге, в котором находятся данные, - как в стороне, это хорошая идея, чтобы вызвать SQL * Loader из того же места, где вы храните файл ctl, чтобы избежать путаницы. Ищите его и связанный с ним плохой файл.

Я бы всегда явно указывал местоположение журнала и файл плохого - и удалял файл, если это необходимо, либо в командной строке, либо в файле ctl. Я предпочитаю командную строку, поэтому вы можете поместить их в разные папки, чтобы они не перезаписывали друг друга. Поэтому вам не нужно менять файл ctl каждый раз, когда вы загружаете что-то, вы также можете поместить файл данных (и почти все остальное) в командной строке. Что-то вроде этого:

call sqlldr scott/[email protected] my_ctl.ctl data=d:\20110201\my_file.csv log=d:\20110201\my_log.log bad=d:\20110201\my_bad.bad 

Возможны две причины для вашей проблемы.

  1. Как @JustinCave предложил вам просто выбрать неправильную таблицу. На этот раз мы отложим это.

  2. Вы отметили, что достигли точки фиксации, поэтому в таблице должны быть данные. Это совсем не так. Вы достигли точки фиксации, но, согласно вашему опубликованному файлу ctl, вы не указали количество допустимых ошибок. Это означает, что SQL * Loader использует значение по умолчанию - . Можно достичь точки фиксации, где все загружено до того, как это будет ошибкой; т. е. вы ничего не совершаете.

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

Есть немало причин для второй произойти так вот список вещей, которые могут пойти не так с SQL * Loader:

  1. Ваши CTL столбцы и столбцы таблицы не наречено точно те же имена.
  2. Ваш файл не существует.
  3. Ваш стол не существует.
  4. У вас есть разделитель в конце вашего файла, что означает, что вам нужно добавить опцию TRAILING NULLCOLS.
  5. У вас есть новая линия в середине линии - у вас большие проблемы. Вам нужно будет задать другой вопрос с полным описанием ctl и таблицы вместе с образцами данных.
  6. Один из столбцов в таблице - тип данных даты. Поскольку каждый фрагмент данных в csv по определению является строкой SQL * Loader не может превратить это в дату. Я собираюсь предположить, что это hiredate, который станет hiredate "to_date(:hiredate,'yyyy/mm/dd')" в файле ctl, где yyyy/mm/dd изменен на любой формат даты, который вам нужен. См. here за хороший список. Конечно, вы всегда можете изменить этот столбец на символ и покончить с преобразованием позже.
  7. Один из столбцов в таблице - это тип данных числа, и вы пытаетесь загрузить в него не число. Извините, в этом случае вам нужно изменить тип данных вашего столбца на символ.
  8. Один из столбцов в таблице - это номер, и вы пытаетесь вставить в него форматированные числа. Помните, что запятые и десятичные точки не являются числом, и в этом случае вы можете использовать функцию to_number: sal "to_number(:sal,'999.99')". Как и в случае с датами, вы всегда можете изменить этот столбец на символ и покончить с преобразованием позже.
  9. У вас есть новая строка в конце каждой строки вашего csv, которая занимает длину столбца по максимуму. Изменить deptno на deptno terminated by whitespace.
  10. Поля в вашем столе не достаточно велики.
  11. Вы загружаете многобайтовые данные, например. UTF-8 в байтовую семантическую таблицу, означающую, что количество символов одинаково, но количество байтов слишком мало. Измените это на семантический символ.
  12. Число, у которого есть пробел в конце, предположим, что это тоже sal, вы должны изменить это на sal integer external, в котором явным образом говорит SQL * Loader это число.
  13. Ваш файл называется csv, но на самом деле это не так. Кто-то переименовал текстовый файл с разделителем на канал в виде csv (это всего лишь один пример из почти сотен примеров, которые я могу дать - .txt - .exe кому-нибудь?)
  14. Простейшей причиной, которая, вероятно, должна быть наверху, является то, что данные в вашем csv не имеют отношения к спецификации вашей таблицы.
  15. Символ в вашем файле csv отличается от характера вашей базы данных, и у Oracle возникают проблемы с ее переводом. Используйте опцию characterset.

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

Теперь совет. Укажите. Это так просто. Если вы не пользуетесь чрезвычайно сильной природой SQL * Loader и множеством опций, которые она предоставляет, вы столкнетесь с такими проблемами. Мало того, что когда поставщик что-то изменяет, не сообщая вам, что вы вряд ли заметите изменения.

Я также очень рекомендую ALWAYS проверка файла журнала после загрузки. Обычно это один из только способов проверить, что ваш груз был успешным. SQL * Loader терпит неудачу на почти каждой строке ошибок ORA-01653 - недостаточно места и помещает всю информацию об этих ошибках в файл журнала. Вы не будете знать о них, если не будете проверять.

Файл типичный CTL обычно выглядит примерно так:

OPTIONS (skip=1, errors=10, rows=10000, direct=True) 
LOAD DATA 
INFILE 'd:\mydata.csv' 
TRUNCATE 
INTO TABLE emp1 
FIELDS TERMINATED BY "," 
OPTIONALLY ENLCOSED BY '"' 
TRAILING NULLCOLS 
( empno 
    , ename 
    , job 
    , mgr 
    , hiredate "to_date(:hiredate,'dd/mm/yy')" 
    , sal integer external 
    , comm 
    , deptno terminated by whitespace 
) 

Все эти вещи, бар имена столбцов и имя таблицы не являются обязательными.

Те, что я добавил являются:

  • skip - Количество строк в верхней части, чтобы пропустить.
  • errors - Максимальное количество ошибок перед остановкой.
  • rows - Количество строк для загрузки перед совершением.
  • direct - Использовать прямую загрузку.
  • TRUNCATE - усечение таблицы перед загрузкой
  • TRAILING NULLCOLS - Есть нулевые столбцы в конце файла.
  • "to_date(..." - Укажите функцию Oracle для вызова при загрузке колонок
  • integer external - Форс этого столбца в числовом тип данных.
  • terminated by whitespace - Удалить пробел в конце строки или столбца.

Есть еще грузы.

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

http://docs.oracle.com/cd/B19306_01/server.102/b14215/ldr_params.htm
http://www.orafaq.com/wiki/SQL*Loader_FAQ
http://www.oracleutilities.com/OSUtil/sqlldr.html

Смежные вопросы