_
O primeiro passo na investigação é verificar os limites definidos no sistema operacional. Para isso é necessário logar com o usuário dono dos binários do Oracle (geralmente é o usuário "oracle") e executar o comando "ulimit -a". Os valores destacados em vermelho devem estar "unilimited" segundo a documentação (Linux 64 bits). Na realidade, este "unilimited" significa 4GB na maioria das plataformas.
_
[oracle@dbserver17 ~]$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 139264
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 139264
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
_
Se os parâmetros estiverem corretos, é necessário extrair um trace específico para o processo que apresenta o problema. Este trace pode ser obtido com o código abaixo. Insira a chamada do processo conforme indicado (entre "Begin call" e "End call"). Após a execução, procure no diretório de traces um arquivo contendo no nome a string "ERRO_4030". Este arquivo contém detalhes sobre a execução e ajudará a identificar a origem do problema.
_
select name, value from v$parameter where name = 'user_dump_dest';
alter session set tracefile_identifier='ERRO_4030';
_
alter session set events '4030 trace name heapdump level 536870917 ; name errorstack level 3';
_
-- Begin call
-- End call
_
alter session set events '4030 trace name heapdump off ; name errorstack off';
