Ошибка расчетов товародвижения : Супермаг Плюс (Супермаг 2000)

Оперативка 2Гб.
db_files = 1024
open_cursors = 100
max_enabled_roles = 30

db_file_multiblock_read_count = 16
dbwr_io_slaves=2
db_writer_processes=2
db_block_lru_latches=2
db_file_direct_io_count=128

db_block_buffers = 64000

shared_pool_size = 524288000

large_pool_size = 209715200
java_pool_size = 52428800

log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800

processes = 150

parallel_max_servers = 5

log_buffer = 32768

Попробуй кнопку "Параметры" в расчете ТД нажать и выбрать там 1 поток и 1 буфер. А заодно можно поубирать с сервера все то, что к его обязанностям не относится. Банально кончилась память.

Последние два раза перенос документов стал вылетать с ошибкой:

2011.03.14 (понедельник) 02:08:09
Версия 1.026.3
>>> Запись 1
Источник: База данных
HRESULT=80004005 custom=20268 SQLState=<none>
Внутренняя ошибка при попытке повторного переноса измененного документа
>>> Запись 2
Источник: Microsoft OLE DB Provider for Oracle
HRESULT=80004005 custom=20268 SQLState=<none>
ORA-20268: Внутренняя ошибка при попытке повторного переноса измененного документа
ORA-06512: на "SUPERMAG.CORE", line 265
ORA-06512: на "SUPERMAG.FIFOTRANSFER", line 764
ORA-00001: нарушено ограничение уникальности (SUPERMAG.FFPRODDOCUMENTS_PK)
ORA-06512: на "SUPERMAG.FIFOTRANSFER", line 815
ORA-06512: на "SUPERMAG.FIFOTRANSFER", line 832
ORA-06512: на "SUPERMAG.FIFOTRANSFER", line 855
ORA-06512: на "SUPERMAG.SMRUNTRANSFER", line 6
ORA-06512: на line 1

>>> Запись 3
Источник: SmLibaryBase trace
HRESULT=80004005 custom=0 SQLState=<none>
{ call Supermag.SMRunTransfer(?, ?) }
Params:
{0} (null)[0](0,0): vt=7 value=14.03.2011 0:03:20
{1} (null)[0](0,0): vt=7 value=14.03.2011 0:03:00

помогает только если удалить все переносы и перенести всё заново, при следующем переносе история повторяется.
подскажите как вылечить?

Обновить Супермаг?

1. Проверить структуру БД
2. Прогнать оптимизатор или проверить самостоятельно все констрейнты на включенность с novalidate
3. Возможно, что действительно надо обновиться, хотя я такой ошибки не помню.

Про обновить супермаг можно забыть :(
Оптимизатор работает регулярно, инвалидов и выключенных констрейнтов нету
Структуру проверял, все в норме
Констрейнт:
ALTER TABLE supermag.ffproddocuments
ADD CONSTRAINT ffproddocuments_pk PRIMARY KEY (ndoc)
кто нить знает как формируется это поле и почему оно может становится не уникальным?

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

Отключение и удаление этого констейнта не помогает, ошибка остается неизменной :(
только не понятно, откуда он знает об этом констейнте если я его дропнул?

Проблема в итоге решилась (сама собой), как я уже писал, что констрейнт дропнул, после того как пересоздал его и вычистил ff-ки перенос начал работать без сбоев :)))