|
превышениe макс. количества открытых курсоров
|
|||
---|---|---|---|
#18+
При больших объемах обрабатывемых данных получаю после нескольких (раз 10) выполнений моей хранимой процедуры сообшение о превышении макс. количества открытых курсоров ( ) ! Все курсоры у меня явные, и все чЭсно закрываю ! Методом научного тыка выявленна виновность след. функции (которая многократно вызывается из общей хр.процедуры, и используется для команд (update-ов) динамического SQL, ) В чем я не прав ?: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2002, 18:32 |
|
превышениe макс. количества открытых курсоров
|
|||
---|---|---|---|
#18+
А ты не мог бы перед RETURN курсор все-таки закрывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2002, 18:40 |
|
превышениe макс. количества открытых курсоров
|
|||
---|---|---|---|
#18+
В идеале вообще бы стоит перестраховаться: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2002, 10:36 |
|
превышениe макс. количества открытых курсоров
|
|||
---|---|---|---|
#18+
Об этом я тоже подумал... но не написал. С эксепшанами мне тоже пришлось столкнуться, особенно когда эти открытые курсоры держали записи. :( ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2002, 11:32 |
|
превышениe макс. количества открытых курсоров
|
|||
---|---|---|---|
#18+
А вот интересно, могу ли я все-таки закрыть чужой курсор? Всякое бывает: столкнулся на рабочей базе с maximum of opened cursors exceeded, полез в v$open_cursor, и хочу уменьшить их количество. А по каким-то соображениям рестарт экземпляра Oracle неприемлем. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2002, 11:43 |
|
превышениe макс. количества открытых курсоров
|
|||
---|---|---|---|
#18+
Ну можно это попробовать. Но первая задача это получить хендлер курсора, а уж потом соорудить ему CLOSE ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2002, 13:11 |
|
превышениe макс. количества открытых курсоров
|
|||
---|---|---|---|
#18+
Ага, а потом ловить сессии, чьё поведение непрогнозируемо после получения "fetch out of sequence" (или что-то около того, когда пытаются достать данные из закрытого курсора). Уж лучше уж их "отстреливать", чтобы не мучались. Кстати, тут столкнулся с проблемой, что неявные курсоры (в том числе и для INSERT INTO ... VALUES ...; DELETE FROM ...) не закрывались из-за опций прекомпилятора (вполне разумно выставленных в hold...=yes; release...=no). А всё из-за того, что если этот самый INSERT одна и та же сессия делает по 20 раз в секунду, то закрывать-открывать курсор не есть разумно. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2002, 20:17 |
|
|
start [/forum/topic.php?fid=52&fpage=2841&tid=1993084]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
48ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
2ms |
others: | 262ms |
total: | 394ms |
0 / 0 |