[ТЕМА ЗАКРЫТА]
12.03.2008 15:55
Таня Просто
 
Добрый день!
В карточке товара в закладке производство при привязке артикула ингредиент, при нажатии кнопки сохранить появляется такая ошибка:
Версия 1.025.1
>>> Запись 1
Источник: Microsoft OLE DB Provider for Oracle
HRESULT=80004005 custom=1000 SQLState=<none>
ORA-01000: количество открытых курсоров превысило допустимый максимум
ORA-06512: на "SUPERMAG.POST", line 367
ORA-06512: на "SUPERMAG.POST", line 383
ORA-06512: на line 1
ORA-06512: на "SUPERMAG.POST", line 690
ORA-06512: на "SUPERMAG.POST", line 308
ORA-06512: на "SUPERMAG.SMPOSTOBJECT", line 13
ORA-06512: на "SUPERMAG.POST", line 706
ORA-06512: на "SUPERMAG.POST", line 308
ORA-06512: на "SUPERMAG.SMPOSTOBJECT", line 13
ORA-06512: на "SUPERMAG.POST", line 697
ORA-06512: на "SUPERMAG.POST", line 308
ORA-06512: на "SUPERMAG.SMPOSTOBJECT", line 13
ORA-06512: на "SUPERMAG.POST", line 706
ORA-06512: на "SUPERMAG.POST", line 308
ORA-06512: на "SUPERMAG.SMPOSTOBJECT", line 13
ORA-06512: на "SUPERMAG.POST", line 697
ORA-06512: на "SUPERMAG.POST", line 308
ORA-06512: на "SUPERMAG.SMPOSTOBJECT", line 13
ORA-06512: на "SUPERMAG.POST", line 706
ORA-06512: на "SUPERMAG.POST", line 308
ORA-06512: на "SUPERMAG.SMPOSTOBJECT", line 13
ORA-06512: на "SUPERMAG.POST", line 697
ORA-06512: на "SUPERMAG.POST", line 308
ORA-06512: на "SUPERMAG.SMPOSTOBJECT", line 13
ORA-06512: на "SUPERMAG.POST", line 706
ORA-06512: на "SUPERMAG.POST", line 308
ORA-06512: на "SUPERMAG.SMPOSTOBJECT", line 13
ORA-06512: на "SUPERMAG.POST", line 697
ORA-06512: на "SUPERMAG.POST", line 308
ORA-06512: на "SUPERMAG.SMPOSTOBJECT", line 13
ORA-06512: на "SUPERMAG.POST", line 706

>>> Запись 2
Источник: SmLibaryBase trace
HRESULT=80004005 custom=0 SQLState=<none>
begin Supermag.SMAutoPostCard('007802',null); end;

В Oracle Enterprise Manager параметр "open_cursors" изменили до 1000 не помогает, та же ошибка.
Кто нибудь знает как это лечить?
12.03.2008 16:37
OlegON
 
И все же, меняем open_cursors на большее и перезапускаем базу..
12.03.2008 17:55
Таня Просто
 
Цитата:
OlegON И все же, меняем open_cursors на большее и перезапускаем базу..

Поменяли, перезапустили базу. Поменяли параметр и в SPFile результат тот же.*11 Может еще что то можно сделать?
12.03.2008 18:05
OlegON
 
Цитата:
SQL> show parameter cursors

NAME TYPE VALUE
------------------------------------ ----------- -------------
open_cursors integer 10000
у меня так... работает :)
13.03.2008 02:40
avl2007
 
версию оракла скажи и ОС.
13.03.2008 08:27
kadr
 
Цитата:
OlegON у меня так... работает :)
Цитата:
SQL> show parameter cursors

NAME TYPE VALUE
------------------------------------
open_cursors integer 500
А у меня так :)
13.03.2008 13:03
Mr_Vito
 
Цитата:
avl2007 версию оракла скажи и ОС.
oracle 9i Release 2 (9.2.0.8) Patch Set 7
ОС на сервере 2003R2 std на раб станции XP home Sp2
13.03.2008 13:13
OlegON
 
Цитата:
Mr_Vito oracle 9i Release 2 (9.2.0.8) Patch Set 7
теперь смотрим, как я выводил параметр и делаем тоже самое... Не факт, что вы меняете параметр там, где надо.
14.03.2008 08:52
Mr_Vito
 
Цитата:
OlegON теперь смотрим, как я выводил параметр и делаем тоже самое... Не факт, что вы меняете параметр там, где надо.
выдала - open_cursors - 10000
session_cached_cursors - 30
14.03.2008 09:34
OlegON
 
А техподдержке базу не пробовали отдать? Если 10000 не хватает, то, думаю, косяк программы. То бишь СМ.
14.03.2008 14:14
Mr_Vito
 
самое интересное, что данная фигня оказывается происходит на некоторых карточках :( , а на некоторых все нормально. Но вот два отличия пока найти не могу :( , буду дальше смотреть может че нить нарою
14.03.2008 14:51
kadr
 
Тогда не плохо было бы смотреть логи, снять трейс в момент отбора таких проблемных карточек.
Проверить структуру базы, проверить валидность ограничений целостности
13.07.2009 10:50
Pyatak
 
Столкнулся с такой же ошибкой, пока не могу победить.
Цитата:
ORA-01000: количество открытых курсоров превысило допустимый максимум
Errors in file d:\oracle\admin\dbpyatak\udump\dbpyatak_ora_3528.trc:
ORA-06512: на "SUPERMAG.CARDS", line 2700
ORA-06512: на "SUPERMAG.SMASSORTMATRIXARTADD", line 5
ORA-06512: на line 1
Эта ошибка возникает при добавлении товаров в ассортимент.
А еще такая же возникает при "инициализации подчиненной базы данных", когда уже счетчик поставленных в очередь артикулов дошел до конца.
dbpyatak_ora_3528.trc
dbpyatak_ora_3528.rar
Help!
13.07.2009 11:05
Pyatak
 
Код:
SQL> select count(*) from v$open_cursor;

  COUNT(*)
----------
      3158

SQL> show parameter open_cursors

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------
open_cursors                         integer     10000
13.07.2009 11:17
Pyatak
 
Не увидел кнопки "правка" в сообщении, чтоб дописать версию СМ и БД.
СМ: 1.024.5 SP6
БД: 9.2.0.7.0
14.07.2009 10:40
Pyatak
 
Удалось выявить следующее:
Код:
alter table SUPERMAG.SMSPECRLBASES enable validate constraint SMCSPECRLBASES_BASE
ORA-02298: cannot validate (SUPERMAG.SMCSPECRLBASES_BASE) - parent keys not found
Причины найдены, устранены, констрейн включился, но на превышении открытых курсоров это не повлияло при добавлении карточки в ассортимент.
Выяснилось также, что ошибка возникает при добавлении одной конкретной карточки, когда она присутствует в списке добавляемых или когда добавляют ее одну. Причем возникает такое ощущение, что где-то в своих недрах процедура SMASSORTMATRIXARTADD натыкается на ошибку, связанною с получением/установкой информации по данному артикулу, но в ней не предусмотрена корректная ее обработка и она зацикливается, причем в цикле каждый раз открывает новый курсор и так продолжается до тех пор, пока их кол-во не превысит максимум.
Такая же ошибка возникает где-то в недрах SMPostObject, если эту карточку помещать в очередь на рассылку.
Протрассировал сессию, в которой производилось добавление карточки в номенклатуру, сейчас пытаюсь разобраться, но там мнооого чего написано.
Что еще можно посмотреть в связи с этим?
14.07.2009 12:15
Pyatak
 
Уфф, разобрался.
Оказывается на этой карточке проводили эксперимент, в ее состав (см. вкладку "состав") добавили другой артикул. Это и вызывало такую проблему. После очистки состава карточки, всё стало вновь работать как часы.
Спасибо всем за участие в данной дискуссии :)
Опции темы


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

 

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