Поставили 1.026.1 сп3. Оракл сатл грузить проц на 100% : Супермаг Плюс (Супермаг 2000)

и вылетать по 4030. Какая может быть взаимосвязь ? Оракл 8.1.7 , настроен был под PAE, PAE убрал, оставив 3 GB, все тоже самое...

Если грузит на 100%...
перестрой индексы...
Собери статистику...
Что в алерте? есьть что интересное?
что делают пользователи в момент загрузки...
длинных сортировок в базе нет?

вот трейс

*** 2008-10-13 12:59:09.302
*** SESSION ID:(22.105) 2008-10-13 12:59:09.286
FATAL ERROR IN TWO-TASK SERVER: error = 12571
*** 2008-10-13 12:59:09.302
ksedmp: internal or fatal error
Current SQL statement for this session:
begin Supermag.SMDocCardAssort(:V00001,:V00002,:V00003,:V00004,:V00005,:V00006); end;
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------

вот алерт:
Dump file D:\ORACLE\ORA81\ADMIN\skont08\bdump\skont08ALRT.LOG
Mon Oct 13 12:59:27 2008
ORACLE V8.1.6.3.0 - Production vsnsta=0
vsnsql=e vsnxtr=3
Windows 2000 Version 5.2 Service Pack 2, CPU type 586
Starting up ORACLE RDBMS Version: 8.1.6.3.0.
System parameters with non-default values:
processes = 360
shared_pool_size = 224288000
large_pool_size = 28672000
java_pool_size = 25536000
pre_page_sga = TRUE
db_file_direct_io_count = 128
control_files = D:\ORACLE\ORADATA\skont08\control01.ctl, D:\ORACLE\ORADATA\skont08\control02.ctl, D:\ORACLE\ORADATA\skont08\control03.ctl
db_block_buffers = 82144
db_block_size = 8192
db_block_lru_latches = 6
buffer_pool_keep = 1024
compatible = 8.1.6
log_buffer = 20480000
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
db_file_multiblock_read_count= 32
max_rollback_segments = 99
max_enabled_roles = 30
remote_login_passwordfile= EXCLUSIVE
global_names = TRUE
distributed_transactions = 10
instance_name = skont08
service_names = skont08
db_name = skont08
open_cursors = 150
os_authent_prefix =
optimizer_mode = choose
always_anti_join = HASH
star_transformation_enabled= TRUE
always_semi_join = HASH
utl_file_dir = D:\tmp
job_queue_processes = 3
job_queue_interval = 60
parallel_max_servers = 5
background_dump_dest = D:\ORACLE\ORA81\ADMIN\skont08\bdump
user_dump_dest = D:\ORACLE\ORA81\ADMIN\skont08\udump
max_dump_file_size = 10240
oracle_trace_collection_name=
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
SNP0 started with pid=8
SNP1 started with pid=9
SNP2 started with pid=10
Mon Oct 13 12:59:31 2008
alter database mount exclusive
Mon Oct 13 12:59:35 2008
Successful mount of redo thread 1, with mount id 1904054839.
Mon Oct 13 12:59:35 2008
Database mounted in Exclusive Mode.
Completed: alter database mount exclusive
Mon Oct 13 12:59:35 2008
alter database open
Beginning crash recovery of 1 threads
Mon Oct 13 12:59:35 2008
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 Group 1 Seq 217833 Reading mem 0
Mem# 0 errs 0: D:\ORACLE\ORADATA\SKONT08\REDO01.LOG
Mon Oct 13 12:59:38 2008
Thread recovery: finish rolling forward thread 1
Thread recovery: 801 data blocks read, 473 data blocks written, 5749 redo blocks read
Crash recovery completed successfully
Mon Oct 13 12:59:39 2008
Thread 1 advanced to log sequence 217834
Thread 1 opened at log sequence 217834
Current log# 3 seq# 217834 mem# 0: D:\ORACLE\ORADATA\SKONT08\REDO03.LOG
Successful open of redo thread 1.
Mon Oct 13 12:59:39 2008
SMON: enabling cache recovery
SMON: enabling tx recovery
Mon Oct 13 12:59:49 2008
Completed: alter database open
Mon Oct 13 13:21:30 2008
ALTER SYSTEM SET timed_statistics=TRUE;

Память кушает кушает, как откушает 3 гб (смотрю по perfmon) таки падает....
а все работало до обновления ((

Предложение - перестроить все индексы. И более разумное - перейти на 9ку.

ок. на 9-ку понятно, жду нового сервера...

а Supermag.SMDocCardAssort валидный?
а то я ещеб все фнкции перекомпилил...

вот где грабли:

SELECT
dh.ID AS ID, dh.createdat, dh.LOCATION, dh.basedoctypeandid,
dh.docstate, dh.pricetype, dh.execdate, dh.labelsprinted, dh.execif
FROM supermag.svdocumentsac dh
WHERE dh.doctype = 'AC'
AND dh.createdat = TO_DATE ('20081013', 'YYYYMMDD')
AND dh.docstate = 2
AND dh.LOCATION = 12
AND (dh.LOCATION IN (SELECT ID
FROM supermag.svgrantedviewdocslocs))

если убрать
dh.LOCATION IN (SELECT ID
FROM supermag.svgrantedviewdocslocs))

никаких фулсканов...