17.01.2007 16:01
vdm
 
OlegON:За наглое нежелание пользоваться поиском и пост не по теме - предупреждение с занесением.

СМ обновлен с версии 1024 sp7 до 1024.6 sp2
Оракл 8.
Последний optimizer прошел нормально за исключением:

OLEGON-WARNING: Не удалось выполнить alter table supermag."SMTIMESPANSALE" move storage (initial 1073741824 next 1073741824 FREELISTS 2 FREELIST GROUPS 1):ORA-01658: unable to create INITIAL extent for segment in tablespace USERS
OLEGON-WARNING: Не удалось выполнить alter table supermag."SMSPEC" move storage (initial 1073741824 next 1073741824 FREELISTS 2 FREELIST GROUPS 1):ORA-01652: unable to extend temp segment by 131072 in tablespace USERS
OLEGON-WARNING: Не удалось выполнить alter table supermag."FFMAPREP_" move storage (initial 1073741824 next 1073741824 FREELISTS 2 FREELIST GROUPS 1):ORA-01652: unable to extend temp segment by 131072 in tablespace USERS
OLEGON-WARNING: Не удалось выполнить alter table supermag."SMCASHCHECKITEMS" move storage (initial 1073741824 next 1073741824 FREELISTS 2 FREELIST GROUPS 1):ORA-01658: unable to create INITIAL extent for segment in tablespace USERS
[/quote]

Первый расчет ТД прошел нормально.
Параметры базы после него не менялись.
На следующий день - никак.
Пользователь supermag или админ - без разницы.

При полной очистке аналитики и расчете с переносом:
Цитата:
2007.01.17 (среда) 15:06:44
Версия 1.024.6
>>> Запись 1
Источник: Административный модуль
HRESULT=80004005 custom=12 SQLState=<none>
Ошибка при сохранении результатов в базу данных.
>>> Запись 2
Источник: Microsoft OLE DB Provider for Oracle
HRESULT=80004005 custom=1502 SQLState=<none>
ORA-01502: index 'SUPERMAG.FFMAPININ_INCOMES' or partition of such index is in unusable state

>>> Запись 3
Источник: Microsoft OLE DB Provider for Oracle
HRESULT=80004005 custom=0 SQLState=<none>
Неопознанная ошибка
>>> Запись 4
Источник: SmLibaryBase trace
HRESULT=80004005 custom=0 SQLState=<none>
select count(*) from supermag.FFMapInIn
Плюс трейс в udump (sqlldr).

Индекс этот VALID и rebuild не помогает.

При очистке только расчетов:
Цитата:

2007.01.17 (среда) 15:14:09
Версия 1.024.6
>>> Запись 1
Источник: Административный модуль
HRESULT=80004005 custom=12 SQLState=<none>
Ошибка при сохранении результатов в базу данных.
>>> Запись 2
Источник: Административный модуль
HRESULT=80004005 custom=0 SQLState=<none>
Ошибка загрузки результатов в базу данных. См. журнал загрузки: 'C:\Temp\1\PathFinder_FFMapInIn1.LOG'.
Цитата:
SQL*Loader: Release 8.1.6.3.0 - Production on Wed Jan 17 15:12:37 2007

(c) Copyright 1999 Oracle Corporation. All rights reserved.

Control File: C:\Temp\1\PathFinder_FFMapInIn1.CTL
Data File: C:\Temp\1\PathFinder_FFMapInIn1.DAT
File processing option string: "fix 119"
Bad File: C:\Temp\1\PathFinder_FFMapInIn1.bad
Discard File: none specified

(Allow all discards)

Number to load: ALL
Number to skip: 0
Errors allowed: 0
Continuation: none specified
Path used: Direct
Silent options: FEEDBACK, ERRORS and DISCARDS

Table SUPERMAG.FFMAPININ, loaded from every logical record.
Insert option in effect for this table: INSERT

Column Name Position Len Term Encl Datatype
------------------------------ ---------- ----- ---- ---- ---------------------
INCOMEDOC FIRST 4 INTEGER
INCOMEITEM NEXT 4 INTEGER
RETDOC NEXT 4 INTEGER
RETITEM NEXT 4 INTEGER
QUANTITY NEXT 8 DOUBLE
ARTICLE NEXT 50 CHARACTER
RETOP NEXT 2 SMALL INTEGER
INCOMEOP NEXT 2 SMALL INTEGER
RETDATE NEXT 8 DATE YYYYMMDD
INCOMEDATE NEXT 8 DATE YYYYMMDD
FORCEDMAPPING NEXT 1 CHARACTER
INCOMEQ NEXT 8 DOUBLE
INCOMETOTALSUM NEXT 8 DOUBLE
INCOMETOTALNOVAT NEXT 8 DOUBLE


The following index(es) on table SUPERMAG.FFMAPININ were processed:
index SUPERMAG.FFCMAPININ_PK loaded successfully with 11093 keys
index SUPERMAG.FFMAPININ_INCOMES loaded successfully with 11093 keys

Table SUPERMAG.FFMAPININ:
11093 Rows successfully loaded.
0 Rows not loaded due to data errors.
0 Rows not loaded because all WHEN clauses were failed.
0 Rows not loaded because all fields were null.

Bind array size not used in direct path.
Space allocated for memory besides bind array: 0 bytes

Total logical records skipped: 0
Total logical records read: 11093
Total logical records rejected: 0
Total logical records discarded: 0

Run began on Wed Jan 17 15:12:37 2007
Run ended on Wed Jan 17 15:12:39 2007

Elapsed time was: 00:00:02.46
CPU time was: 00:00:00.04
Чтот не вижу тут обещанной ошибки

Помогите, ааааа!!! *18
17.01.2007 16:07
sevushka
 
Честно скажу, не специалист в этом, но примерно такая фигня была. Вылечилось добавлением 1 гига в users (хоть там свободное место и так было) и прогоном оптимайзера снова. Попробуй, может и у тебя то же самое.
17.01.2007 16:29
Propil
 
добавь файл в USERS, к примеру на 2 гигабайта
Ну, и требуется поправка индексов - или оптимайзером или в админ модуле задание Полное пересоздание индексов
17.01.2007 17:14
bob
 
Угу. Сколько раз здесь говорилось (не далее, как вчера-позавчера) - не жалейте своб. места в Users и INDX.
17.01.2007 18:52
vdm
 
Уря, расчиталось.
Свободного было 30% в индексах и 40% в users
Нне ожидал, что объем свободного необходимо будет примерно равным занятому...
А ORA-01658 - виноват, не обратил внимания.
17.01.2007 20:36
OlegON
 
Для уменьшения фрагментации я выставляю следующий экстент равным текущему занятому месту, но не более гига. Экстент - непрерывная последовательность блоков. Пример:
FFMAPREP ~ 1Гб, свободное место 1Гб, казалось бы, чуть больше половины занято, НО. Для следующего расширения FFMAPREP требуется сразу гиг, причем свободного, непрерывного места. На практике свободное место, которое показывается в DBA Studio, никогда не бывает непрерывным. В нем валяются кусочки других таблиц, особенно, если это первый запуск оптимайзера за долгое время. И даже если крохотный экстент другой таблицы валяется посреди этого свободного гига, то он уже не будет непрерывным. И потребуется еще один гиг. Это только на FFMAPREP. А там еще есть другие большие таблички и индексы.
17.01.2007 23:31
vdm
 
Это все так.
Я все-же не улавливаю прямой связи между этим и падением sqlldr при расчете ТД. Ему тоже нужен был большой непрерывный кусок?
Просто добавил места, все индексы в базе valid - безрезультатно.
Сделал оптимайзером /chkindx - в его логе все чисто, но расчет прошел.
Почему? *16
17.01.2007 23:44
OlegON
 
Конечно, а ты как думал, куда лодер заливает? Сверху намазывает? Он так же заливает в таблицы, которые так же раздуваются, как обычно. Добавил места, хватило, куда раздуться. Вот и весь секрет.
02.04.2010 10:27
mitnick
 
Друзья, я не спец по Супермагу-2000, поэтому прошу простить за глупый вопрос: где и как увеличить свобободное место в Users и INDX?
Часовой пояс GMT +3, время: 06:07.

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