Переполнении памяти

Alexey123
Дата: 02.12.2009 13:14:08
Доброго всем дня, если он добрый.. Бьюсь головой об стенку. Вызываю хранимую процедуру, выполняется успешно. Делаю commit. Повторяю операции снова. Во время коммита резка растёт память у процесса oracle.exe после чего начинает расти память у процесса svhost.exe и оба срубаются. После перезагрузки повторяю операции, результат аналогичен. Включаю трассировку - всё работает. Выключаю - опять при коммите оракл падает.. Подскажите хоть куда смотреть? Большое спасибо за любую информацию.

Oracle11g version 11.1.0.6.0
Window Server 2003 R2
zhmur
Дата: 02.12.2009 13:58:11
Как минимум необходимо посмотреть информацию, которая пишется в alert.log при падении. Тектовое представление alert.log находиться: <DISK NAME>:\app\<USER>\diag\rdbms\<SID>\<SID>\trace\alert_<SID>.log .
Alexey123
Дата: 02.12.2009 14:14:21
14:09 запустил Oracle
14:11 процесс срубился, но в логе это незафиксировано

Wed Dec 02 14:09:21 2009
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_1 parameter default value as c:\oracle11\product\11.1.0\db_1\RDBMS
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 11.1.0.6.0.
Using parameter settings in server-side spfile C:\ORACLE11\PRODUCT\11.1.0\DB_1\DATABASE\SPFILEORACLE11.ORA
System parameters with non-default values:
  processes                = 150
  memory_target            = 2G
  memory_max_target        = 2G
  control_files            = "C:\ORACLE11\ORADATA\ORACLE11\CONTROL01.CTL"
  control_files            = "C:\ORACLE11\ORADATA\ORACLE11\CONTROL02.CTL"
  control_files            = "C:\ORACLE11\ORADATA\ORACLE11\CONTROL03.CTL"
  db_block_size            = 8192
  compatible               = "11.1.0.0.0"
  db_recovery_file_dest    = "c:\oracle11\flash_recovery_area"
  db_recovery_file_dest_size= 2G
  undo_tablespace          = "UNDO"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=oracle11XDB)"
  audit_file_dest          = "C:\ORACLE11\ADMIN\ORACLE11\ADUMP"
  audit_trail              = "DB"
  db_name                  = "oracle11"
  open_cursors             = 300
  diagnostic_dest          = "C:\ORACLE11"
Wed Dec 02 14:09:21 2009
PMON started with pid=2, OS id=3196 
Wed Dec 02 14:09:21 2009
VKTM started with pid=3, OS id=5704 at elevated priority
VKTM running at (20)ms precision
Wed Dec 02 14:09:21 2009
DIAG started with pid=4, OS id=4308 
Wed Dec 02 14:09:22 2009
DBRM started with pid=5, OS id=5444 
Wed Dec 02 14:09:22 2009
PSP0 started with pid=6, OS id=5892 
Wed Dec 02 14:09:22 2009
DSKM started with pid=7, OS id=3072 
Wed Dec 02 14:09:22 2009
DIA0 started with pid=8, OS id=6060 
Wed Dec 02 14:09:22 2009
MMAN started with pid=9, OS id=4508 
Wed Dec 02 14:09:22 2009
DBW0 started with pid=7, OS id=2084 
Wed Dec 02 14:09:22 2009
LGWR started with pid=10, OS id=2916 
Wed Dec 02 14:09:22 2009
CKPT started with pid=11, OS id=1820 
Wed Dec 02 14:09:22 2009
SMON started with pid=12, OS id=4676 
Wed Dec 02 14:09:22 2009
RECO started with pid=13, OS id=4344 
Wed Dec 02 14:09:22 2009
MMON started with pid=14, OS id=4044 
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Wed Dec 02 14:09:22 2009
MMNL started with pid=15, OS id=4632 
starting up 1 shared server(s) ...
ORACLE_BASE from environment = c:\oracle11
Wed Dec 02 14:09:22 2009
alter database mount exclusive
Setting recovery target incarnation to 2
Successful mount of redo thread 1, with mount id 2397785941
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: alter database mount exclusive
alter database open
Beginning crash recovery of 1 threads
 parallel recovery started with 2 processes
Started redo scan
Completed redo scan
 8967 redo blocks read, 449 data blocks need recovery
Started redo application at
 Thread 1: logseq 980, block 23117
Recovery of Online Redo Log: Thread 1 Group 2 Seq 980 Reading mem 0
  Mem# 0: C:\ORACLE11\ORADATA\ORACLE11\REDO02.LOG
Completed redo application
Completed crash recovery at
 Thread 1: logseq 980, block 32084, scn 14683887
 449 data blocks read, 449 data blocks written, 8967 redo blocks read
Thread 1 advanced to log sequence 981
Thread 1 opened at log sequence 981
  Current log# 3 seq# 981 mem# 0: C:\ORACLE11\ORADATA\ORACLE11\REDO03.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 8.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is CL8MSWIN1251
SMON: Restarting fast_start parallel rollback
SMON: Parallel transaction recovery tried
Opening with internal Resource Manager plan
Starting background process FBDA
Starting background process SMCO
Wed Dec 02 14:09:32 2009
SMCO started with pid=24, OS id=4372 
Wed Dec 02 14:09:32 2009
replication_dependency_tracking turned off (no async multimaster replication found)
Wed Dec 02 14:09:32 2009
FBDA started with pid=23, OS id=4980 
Starting background process QMNC
Wed Dec 02 14:09:33 2009
QMNC started with pid=25, OS id=4896 
Wed Dec 02 14:09:38 2009
db_recovery_file_dest_size of 2048 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Wed Dec 02 14:09:43 2009
Completed: alter database open
zhmur
Дата: 02.12.2009 14:52:35
Посмотрите не создаётся ли crash дампов в момент сбоя, проверьте системный журнал, категория Application. Если есть возможность, предоставьте тестовый пакет (тестовые данные, скрипт создания схемы...), что бы воспроизвести проблему.
Alexey123
Дата: 02.12.2009 15:19:40
Что значит "crash дампов" ? Я к сожалению не администратор..

В системном журнале в разделе "Система" во время сбоя:
Служба "OracleServiceORACLE11" неожиданно прервана. Это произошло (раз): 53.

В разделе "Приложение" только во время старта оракла уведомления:

Не найдено описание для события с кодом ( 34 ) в источнике ( Oracle.oracle11 ). 
Возможно, на локальном компьютере нет нужных данных в реестре или файлов DLL сообщений для 
отображения сообщений удаленного компьютера. Попробуйте использовать ключ /AUXSOURCE= 
для получения этого описания, - дополнительные сведения об этом содержатся в справке. В 
записи события содержится следующая информация: ACTION : 'CONNECT' DATABASE USER: '/' 
PRIVILEGE : SYSDBA CLIENT USER: NT AUTHORITY\SYSTEM CLIENT TERMINAL: ORLAND2 STATUS: 0 .

Не найдено описание для события с кодом ( 4 ) в источнике ( Oracle.oracle11 ). 
Возможно, на локальном компьютере нет нужных данных в реестре или файлов DLL сообщений для 
отображения сообщений удаленного компьютера. Попробуйте использовать ключ /AUXSOURCE= 
для получения этого описания, - дополнительные сведения об этом содержатся в справке. В 
записи события содержится следующая информация: oracle11.

Не найдено описание для события с кодом ( 5 ) в источнике ( Oracle.oracle11 ). 
Возможно, на локальном компьютере нет нужных данных в реестре или файлов DLL сообщений для
 отображения сообщений удаленного компьютера. Попробуйте использовать ключ /AUXSOURCE= 
для получения этого описания, - дополнительные сведения об этом содержатся в справке. В 
записи события содержится следующая информация: PMON; oracle11.

И т.д.
zhmur
Дата: 02.12.2009 16:34:47
Опубликуйте, пожалуйста, код, который вызывает ошибку. И тестовый набор данных.
Alexey123
Дата: 03.02.2010 15:50:48
Опубликовать код немогу, так как используется несколько пакетов и набор пользовательских типов (классов Oracle). Дамп этой бд, поднятой на другом сервере, работает без ошибок. Подскажите хоть примерно возможные причины такого поведения.
env
Дата: 03.02.2010 16:08:35
Alexey123,

При включенной трассировке память не растёт и коммит проходит успешно, если я правильно понимаю.
1. нелепый вариант - отключение дисков в настройках энергосохранения не выставлено, случаем?
2. если есть возможность - перенесите таблицы по которым идут изменения и их индексы в тейблспейс на другом диске (желательно, под управлением другого raid-котроллера)
3. если поднят EM, то посмотрите по ASH/AWR отчётам, что творилось до момента падения и как оно же выглядит при включённой трассировке.

В целом создаётся впечатление, что у вас оракл теряет возможность записать что-либо на диск, кстати поэтому и умирает без записи в алерте.