[ОТВЕТИТЬ]
17.08.2010 19:53
GENDALF
 
При расчете ТД, вернее при записи в базу ошибка.Лог ниже.
Полазил по форуму...
Сделал переиндексацию оптимайзером.
Результат не изменился.

Хелп ми, френдс., .

...Ошибка при сохранении результатов в базу данных.

PathFinder_FFMapRep4.LOG

Цитата:
SQL*Loader: Release 9.2.0.8.0 - Production on Втн Авг 17 19:30:19 2010

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Управляющий файл: C:\WINDOWS\Temp\PathFinder_FFMapRep4.CTL
Файл данных: C:\WINDOWS\Temp\PathFinder_FFMapRep4.DAT
Строка опций обработки файла: "fix 355"
Файл плохих записей: C:\WINDOWS\Temp\PathFinder_FFMapRep4.bad
Файл удаленных записей: ничего не задано

(Разрешить удалять все записи)

Количество записей для загрузки: ALL
Количество записей для пропуска: 0
Допускается ошибок: 0
Продолжение: ничего не задано
Использован маршрут: Прямой
Бесшумные режимы: FEEDBACK, ERRORS и DISCARDS

Таблица SUPERMAG.FFMAPREP, загружен из каждой логической записи.
Режим вставки действует для этой таблицы: INSERT

Имя столбца Позиция Дл. Огр. Вкл Тип данных
------------------------------ ---------- ----- ---- ---- ---------------------
RECTYPE FIRST 4 INTEGER
ARTICLE NEXT 50 CHARACTER
SALELOCATIONFROM NEXT 4 INTEGER
SALELOCATIONTO NEXT 4 INTEGER
SALEDATE NEXT 8 DATE YYYYMMDD
SALEID NEXT 50 CHARACTER
SALETYPE NEXT 2 CHARACTER
SALEOP NEXT 4 INTEGER
SALEUSEROP NEXT 4 INTEGER
SALESPECITEM NEXT 4 INTEGER
SALEPAYCASH NEXT 1 CHARACTER
SALECLIENTINDEX NEXT 4 INTEGER
SALEVATRATE NEXT 10 PACKED DECIMAL (19, 4)
INCOMEID NEXT 50 CHARACTER
INCOMETYPE NEXT 2 CHARACTER
INCOMESPECITEM NEXT 4 INTEGER
INCOMECLIENTINDEX NEXT 4 INTEGER
GOODSOWNER NEXT 4 INTEGER
FORCEDMAPPING NEXT 1 CHARACTER
QUANTITY NEXT 8 DOUBLE
SALEQ NEXT 8 DOUBLE
SALESUM NEXT 10 PACKED DECIMAL (19, 4)
SALENOVAT NEXT 10 PACKED DECIMAL (19, 4)
SALENOTAX NEXT 10 PACKED DECIMAL (19, 4)
SALECURTYPE NEXT 4 INTEGER
SALESUMCUR NEXT 10 PACKED DECIMAL (19, 4)
INCOMEQ NEXT 8 DOUBLE
INCOMESUM NEXT 10 PACKED DECIMAL (19, 4)
INCOMENOVAT NEXT 10 PACKED DECIMAL (19, 4)
INCOMEVATRATE NEXT 10 PACKED DECIMAL (19, 4)
INCOMESUMCUR NEXT 10 PACKED DECIMAL (19, 4)
INCOMECURTYPE NEXT 4 INTEGER
PRIMECOST NEXT 10 PACKED DECIMAL (19, 4)
PRIMECOSTNOVAT NEXT 10 PACKED DECIMAL (19, 4)
PRIMECOSTFORCED NEXT 1 CHARACTER
INCOMEDATE NEXT 8 DATE YYYYMMDD

Запись 8: Забракована - Ошибка в таблице SUPERMAG.FFMAPREP.
ORA-14400: вставленный ключ секции не соответствует ни одной секции

Specify SKIP=8 when continuing the load.
Были обработаны следующие индексы таблицы SUPERMAG.FFMAPREP:
индекс SUPERMAG.FFMAPREP_ARTICLE загружено успешно с 7 ключами
индекс SUPERMAG.FFMAPREP_DOC загружено успешно с 7 ключами
индекс SUPERMAG.FFMAPREP_LOCTO секция FF2_2009_CR загружена успешно с 1 ключами
индекс SUPERMAG.FFMAPREP_LOCTO секция FF3_2009_CR загружена успешно с 2 ключами
индекс SUPERMAG.FFMAPREP_LOCTO секция FF3_2009_CS загружена успешно с 1 ключами
индекс SUPERMAG.FFMAPREP_LOCTO секция FF4_2009_CR загружена успешно с 2 ключами
индекс SUPERMAG.FFMAPREP_LOCTO секция FF4_2010_CR загружена успешно с 1 ключами
индекс SUPERMAG.FFMAPREP_SALEDATE секция FF2_2009_CR загружена успешно с 1 ключами
индекс SUPERMAG.FFMAPREP_SALEDATE секция FF3_2009_CR загружена успешно с 2 ключами
индекс SUPERMAG.FFMAPREP_SALEDATE секция FF3_2009_CS загружена успешно с 1 ключами
индекс SUPERMAG.FFMAPREP_SALEDATE секция FF4_2009_CR загружена успешно с 2 ключами
индекс SUPERMAG.FFMAPREP_SALEDATE секция FF4_2010_CR загружена успешно с 1 ключами
индекс SUPERMAG.FFMAPREP_SUPPLIER секция FF2_2009_CR загружена успешно с 1 ключами
индекс SUPERMAG.FFMAPREP_SUPPLIER секция FF3_2009_CR загружена успешно с 2 ключами
индекс SUPERMAG.FFMAPREP_SUPPLIER секция FF3_2009_CS загружена успешно с 1 ключами
индекс SUPERMAG.FFMAPREP_SUPPLIER секция FF4_2009_CR загружена успешно с 2 ключами
индекс SUPERMAG.FFMAPREP_SUPPLIER секция FF4_2010_CR загружена успешно с 1 ключами

ПРЕВЫШЕНО МАКСИМАЛЬНОЕ КОЛИЧЕСТВО ОШИБОК - В приведенной выше статистике отражен частичный прогон.

Таблица SUPERMAG.FFMAPREP:
7 Строки успешно загружено.
1 Строка не загружены из-за ошибки в данных.
0 Строки не загружены из-за сбоев во всех фразах WHEN.
0 Строки не загружены из-за того, что все поля были пусты.

Размер поля привязки не используется в прямом маршруте.
Строк массива столбцов : 5000
Байтов буфера потока: 256000
Байтов буфера чтения: 1048576

Всего пропущено логических записей: 0
Всего забраковано логических записей: 1
Всего удалено логических записей: 0
Общее число буферов потока, загруженных главным процессом SQL*Loader: 0
Общее число буферов потока, загруженных процессом загрузки SQL*Loader: 1

Run began on Втн Авг 17 19:30:19 2010
Run ended on Втн Авг 17 19:30:47 2010

Общее время: 00:00:28.85
Процессорное время: 00:00:00.06
17.08.2010 20:52
OlegON
 
Прогони оптимизатор с -c=o в MaintenanceTime и скинь ссылку на лог или имя базы скажи, если не поможет. Должно помочь.
18.08.2010 13:40
Propil
 
Да, скорее всего в секционированной табличке FFMAPREP нету секции за август..
22.08.2010 18:37
GENDALF
 
База освободилась.Вот лог оптимайзера.

Скачать лог
22.08.2010 19:44
OlegON
 
У меня не качается. Сделал все, как сказали и не помогло? Положи в хранилище.
23.08.2010 15:55
GENDALF
 
Сделал. На свободной базе прогнал оптимайзером с-о...
Результат не изменился.

На фтп не получается залить... FW не дает.

Выложил сюда.
optimizer_g.zip.html
23.08.2010 15:57
Dim
 
в хранилище можно и по http закачать
23.08.2010 16:21
OlegON
 
Цитата:
GENDALF Сделал. На свободной базе прогнал оптимайзером с-о...
Результат не изменился.
На фтп не получается залить... FW не дает.
Не вижу картинки, чтобы скачать. Отключи FW и залей. И в MaintenanceTime прогонял?
23.08.2010 16:34
Propil
 
Посмотрел:

22.08.10 18:31:44 -- Maintenance interval : 23:00,8
22.08.10 18:31:44 -- Not maintenance time...
Оптимайзер тебе ничего и не сделает, раз ты ему не даешь возможности

И еще - мыло-то на свое поменяй..
22.08.10 18:32:29 -- Supermag : 1.027.4 SP2 OS : Windows 2003 Java : 1.6.0_18 Jabbers :
27.08.2010 12:58
GENDALF
 
Спасибо! все заработало.тему можно закрыть.
Еще раз спасибо!
11.10.2010 15:11
Armanion
 
А можно подробнее расписать что сделали! У меня такая же проблемма! Оптимизатором прогнал -с=i и -с=о расширял темповое пространство также индексы и юзерсы расширил везде по 50% свободного пространства еще есть!
11.10.2010 15:22
Propil
 
надо оптимизатор запустить с ключом -c=o в период, когда ему разрешена нормальная работа с базой
(Maintenance interval : 23:00,8) к примеру
12.10.2010 00:58
GENDALF
 
MaintenanceTime - время, когда программа расчитывает находиться без пользователей и будет заниматься общей оптимизацией базы. До запятой - время начала, после - продолжительность в часах.

чтобы изменить параметр под себя...в sql+ под пользователем "sys" пишем:

update olegon_params set value='23:00,8' where name='MaintenanceTime';
commit;
время и кол-во повкусу :)
остальное написал Propil.
08.10.2011 06:33
DIMAJBL
 
Доброго времени суток. столкнулся с этой бедой ошибка ora 14400 вставленный ключ секции не соответствует ни одной секции, раньше все решалось запуском оптимайзера в этот раз ошибка не исправляется в чем может быть косяк лог оптимайзера прилогаю

08.10.2011 07:53
akonev
 
действительно, в ffmaprep последняя секция за сентябрь.

DontUseFFMAPREP проверь в параметрах оптимизатора.
08.10.2011 14:01
DIMAJBL
 
было DontUseFFMAPREP =no поменял на yes та же самая байда ошибка записи.
08.10.2011 14:49
akonev
 
Цитата:
DIMAJBL было DontUseFFMAPREP =no поменял на yes...
Вот это зря!!! Вчитайся, у него же обратная логика. Верни как было :) , прогони еще раз оптимизатора, выложи еще раз лог. Там как раз сегодня Олег приделал вывод параметров в логи.
08.10.2011 16:20
whitewizard
 
update olegon_params set value='23:00,8' where name='MaintenanceTime';
commit;

Причём время московское
10.10.2011 14:37
DIMAJBL
 
вот запустил еще раз вот лог

10.10.2011 15:53
akonev
 
ни один из запусков, что есть в логе, не попал в maintenance time

новые секции создаются в мэйнтенэнс

так что делаем, как выше белый волшебник сказал:
1) вычисляем во сколько по московскому времени оптимизатору можно курочить базу; пользователей в это время в ней быть не должно; кто попытается работать - будет выкинут без сожаления.
2) выставляем в параметрах это время и через запятую - сколько часов можно над базой издеваться
3) обеспечиваем чтобы оптимизатор в этот интервал времени запустился хотя бы один раз.
10.10.2011 15:57
whitewizard
 
У тебя везде оптимайзер не работает
(Not maintenance time...)

выставь 'MaintenanceTime' в olegon_params значение, например '15:00,8'
15+6=21 час (время в Чите)

то есть зайди в sqlplus в базу и напиши

update olegon_params set value='15:00,8' where name='MaintenanceTime';
commit;
10.10.2011 16:49
DIMAJBL
 
Время когда оптимайзер может издеваться над базой именно в этом случае стоял гдето часов 5,сегодня все параметры в оптимайзере поставил как советовали, увеличил время издева над БД по максимуму с 17часов по москве протяженностью 8 часов а в сегодняшних логах получается что опримайзер не попал в этот интервал.Завтра утром выложу ночной лог, если не поможет. Что касается других баз везде включено MaintenanceTime только время разное.
11.10.2011 11:46
DIMAJBL
 
Вопрос решился видимо ему просто не хватало времени.
14.03.2012 13:05
GENDALF
 
Как решать эту проблему если оптимизатор не хочет работать?

Как в ручную сделать?
14.03.2012 14:21
OlegON
 
Цитата:
GENDALF Как решать эту проблему если оптимизатор не хочет работать?
Работает... Под 200 баз на нем... Решать, как уже говорилось раньше, добавлением секции.
19.03.2012 18:22
GENDALF
 
Добавил секцию.... толку никакого... может неправильно довавил.

На счет оптимайзера...
Цитата:
Sorry, too much unregistered sessions. Please, change your schedule...
19.03.2012 20:03
OlegON
 
и какие выводы ты из этого сообщения делаешь? перевел хоть?
04.09.2012 18:16
alexunit
 
Цитата:
OlegON и какие выводы ты из этого сообщения делаешь? перевел хоть?
Как избавится от этого сообщения ?
04.09.2012 22:46
OlegON
 
Цитата:
alexunit Как избавится от этого сообщения ?
Вообще-то по оптимизатору есть отдельный раздел. А от сообщения можно избавиться, либо зарегистрировав программу, либо просто запуская ее тогда, когда кучи других пользователей не использует ее. Подсказка - в 00:00-00:15 запускает 90% пользователей и далее по полчаса интервал.
03.02.2016 14:55
TEHb2
 
У меня вот сейчас возникла такая же проблема
Управляющий файл: E:\USERPR~1\Temp\2\PathFinder_FFMapRep4.CTL
Файл данных: E:\USERPR~1\Temp\2\PathFinder_FFMapRep4.DAT
Строка опций обработки файла: "fix 355"
Файл плохих записей: E:\USERPR~1\Temp\2\PathFinder_FFMapRep4.bad
Файл удаленных записей: ничего не задано

(Разрешить удалять все записи)

Количество записей для загрузки: ALL
Количество записей для пропуска: 0
Допускается ошибок: 0
Продолжение: ничего не задано
Использован маршрут: Прямой
Бесшумные режимы: FEEDBACK, ERRORS и DISCARDS

Таблица SUPERMAG.FFMAPREP, загружен из каждой логической записи.
Режим вставки действует для этой таблицы: INSERT

Имя столбца Позиция Дл. Огр. Вкл Тип данных
------------------------------ ---------- ----- ---- ---- ---------------------
RECTYPE FIRST 4 INTEGER
ARTICLE NEXT 50 CHARACTER
SALELOCATIONFROM NEXT 4 INTEGER
SALELOCATIONTO NEXT 4 INTEGER
SALEDATE NEXT 8 DATE YYYYMMDD
SALEID NEXT 50 CHARACTER
SALETYPE NEXT 2 CHARACTER
SALEOP NEXT 4 INTEGER
SALEUSEROP NEXT 4 INTEGER
SALESPECITEM NEXT 4 INTEGER
SALEPAYCASH NEXT 1 CHARACTER
SALECLIENTINDEX NEXT 4 INTEGER
SALEVATRATE NEXT 10 PACKED DECIMAL (19, 4)
INCOMEID NEXT 50 CHARACTER
INCOMETYPE NEXT 2 CHARACTER
INCOMESPECITEM NEXT 4 INTEGER
INCOMECLIENTINDEX NEXT 4 INTEGER
GOODSOWNER NEXT 4 INTEGER
FORCEDMAPPING NEXT 1 CHARACTER
QUANTITY NEXT 8 DOUBLE
SALEQ NEXT 8 DOUBLE
SALESUM NEXT 10 PACKED DECIMAL (19, 4)
SALENOVAT NEXT 10 PACKED DECIMAL (19, 4)
SALENOTAX NEXT 10 PACKED DECIMAL (19, 4)
SALECURTYPE NEXT 4 INTEGER
SALESUMCUR NEXT 10 PACKED DECIMAL (19, 4)
INCOMEQ NEXT 8 DOUBLE
INCOMESUM NEXT 10 PACKED DECIMAL (19, 4)
INCOMENOVAT NEXT 10 PACKED DECIMAL (19, 4)
INCOMEVATRATE NEXT 10 PACKED DECIMAL (19, 4)
INCOMESUMCUR NEXT 10 PACKED DECIMAL (19, 4)
INCOMECURTYPE NEXT 4 INTEGER
PRIMECOST NEXT 10 PACKED DECIMAL (19, 4)
PRIMECOSTNOVAT NEXT 10 PACKED DECIMAL (19, 4)
PRIMECOSTFORCED NEXT 1 CHARACTER
INCOMEDATE NEXT 8 DATE YYYYMMDD

Запись 34571: Забракована - Ошибка в таблице SUPERMAG.FFMAPREP.
ORA-14400: вставленный ключ секции не соответствует ни одной секции

Задайте SKIP=34571, затем продолжайте загрузку.
Были обработаны следующие индексы таблицы SUPERMAG.FFMAPREP:
индекс SUPERMAG.FFMAPREP_DOC загружено успешно с 34570 ключами
индекс SUPERMAG.FFMAPREP_INCOMEDOC загружено успешно с 34570 ключами
индекс SUPERMAG.FFMAPREP_SALEDATE загружено успешно с 34570 ключами
индекс SUPERMAG.FFMAPREP_SUPPLIER загружено успешно с 34570 ключами

ПРЕВЫШЕНО МАКСИМАЛЬНОЕ КОЛИЧЕСТВО ОШИБОК - В приведенной выше статистике отражен частичный прогон.

Таблица SUPERMAG.FFMAPREP:
34570 Строки успешно загружено.
1 Строка не загружены из-за ошибки в данных.
0 Строки не загружены из-за сбоев во всех фразах WHEN.
0 Строки не загружены из-за того, что все поля были пусты.

Кэш дат:
Макс. размер: 1000
Записей : 559
Попаданий : 64407
Промахов : 0

Размер поля привязки не используется в прямом маршруте.
Строк массива столбцов : 5000
Байтов буфера потока: 256000
Байтов буфера чтения: 1048576

Всего пропущено логических записей: 0
Всего забраковано логических записей: 1
Всего удалено логических записей: 0
Общее число буферов потока, загруженных главным процессом SQL*Loader: 12
Общее число буферов потока, загруженных процессом загрузки SQL*Loader: 12

Прогон начался в Ср Фев 03 14:44:27 2016
Прогон кончился в Ср Фев 03 14:44:31 2016

Общее время: 00:00:03.43
Процессорное время: 00:00:00.25


Эта центральная база. А я не особо стараюсь лезть в неё. Опыта маловато.
Как бы поступить в такой ситуации?
Вот например задать SKIP=34571.
Посоветуйте, пожалуйста, правильный запрос.
Оптимайзера у меня нет.


Опции темы


Часовой пояс GMT +3, время: 19:02.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.