Recentemente precisei realizar o import de um dump em um banco de dados 12.1.0.2 e o processo do impdp sempre congelava ao começar criar as functions.
Ao procurar pela sessão do impdp no banco de dados, a mesma estava com evento “wait for unread message on broadcast channel” e sempre no mesmo SQL.
Para identificar a sessão do Datapump, utilizei essa query:
set lines 300
select s.sid, s.module, s.state,
substr(s.event, 1, 21) as event,
s.seconds_in_wait as secs,
substr(sql.sql_text, 1, 30) as sql_text
from v$session s
join v$sql sql on sql.sql_id = s.sql_id
where s.module like 'Data Pump%'
order by s.module, s.sid;
A confirmação de que a sessão estava congelada veio quando consultei a view DBA_RESUMABLE:
SQL> SELECT NAME, SQL_TEXT FROM DBA_RESUMABLE;
NAME SQL_TEXT
----------------- ------------------------------------------------------
SYSTEM.IMPORT11 BEGIN :1 := sys.kupc$que_int.receive(:2); END;
A view DBA_RESUMABLE faz parte da feature Resumable Space Allocation, que tem como objetivo colocar uma sessão em espera ao invés de interromper o processo quando um evento de erro ocorre no banco de dados. Os principais cenários são relacionados a utilização de tablespace e a condição de erro pode ser identificada nas colunas ERROR_NUMBER ou ERROR_MSG, mas essas colunas estavam vazias.
Para tentar obter mais informações sobre o problema, fiz uma nova tentativa de import colocando a sessão em modo debug, utilizando o parâmetro TRACE com valor 480300 e o parâmetro METRICS com valor “yes”. O parâmetro TRACE controla o nível de informações gravadas nos trace files das sessões do Datapump (aqueles gerados no diretório do alert log) e o parâmetro METRICS apenas adiciona a quantidade de objetos afetados e o tempo de processamento de cada etapa no arquivo de log do import ou export.
O trace com valor 480300 gera trace adicional para os dois principais processos do Datapump, o Master Control Process (MCP) e do Worker Process. A nota Export/Import DataPump Parameter TRACE – How to Diagnose Oracle Data Pump (Doc ID 286496.1) possui instruções detalhada sobre as opções possíveis.
impdp system/dibiei@orcl directory=dir_local dumpfile=expdpdev.dmp logfile=imp11.log schemas=DIBIEI trace=480300 metrics=yes
Após reiniciar o job e verificar que o mesmo havia travado novamente, procurei os arquivos de trace no diretório do alert log.
Para encontrar os arquivos de trace do Master Control Process:
$ pwd /u01/app/oracle/diag/rdbms/cdb1_gru1nw/CDB1/trace $ ls -lrt *dm00* -rw-r----- 1 oracle asmadmin 2692 May 19 13:20 CDB1_dm00_11004.trm -rw-r----- 1 oracle asmadmin 46330 May 19 13:20 CDB1_dm00_11004.trc -rw-r----- 1 oracle asmadmin 757 May 19 13:35 CDB1_dm00_49083.trm -rw-r----- 1 oracle asmadmin 16362 May 19 13:35 CDB1_dm00_49083.trc -rw-r----- 1 oracle asmadmin 17290 May 19 19:19 CDB1_dm00_64241.trm -rw-r----- 1 oracle asmadmin 2966236 May 19 19:19 CDB1_dm00_64241.trc
Para encontrar os arquivos de trace do Worker Process:
$ pwd /u01/app/oracle/diag/rdbms/cdb1_gru1nw/CDB1/trace $ ls -lrt *dw00* -rw-r----- 1 oracle asmadmin 7913187 May 19 11:36 CDB1_dw00_7226.trm -rw-r----- 1 oracle asmadmin 393751163 May 19 11:36 CDB1_dw00_7226.trc -rw-r----- 1 oracle asmadmin 1462 May 19 13:18 CDB1_dw00_11108.trm -rw-r----- 1 oracle asmadmin 51588 May 19 13:18 CDB1_dw00_11108.trc -rw-r----- 1 oracle asmadmin 882 May 19 13:28 CDB1_dw00_49177.trm -rw-r----- 1 oracle asmadmin 32986 May 19 13:28 CDB1_dw00_49177.trc -rw-r----- 1 oracle asmadmin 3689484 May 19 19:19 CDB1_dw00_65578.trm -rw-r----- 1 oracle asmadmin 162363264 May 19 19:19 CDB1_dw00_65578.trc
Encontrei a causa raíz no arquivo de trace do Worker Process, aqui o erro que estava travando o job de import: Limite de PGA.
Process has gone over pga_aggregate_limit Just allocated 65536 bytes PGA LIMIT: pid 7226 has 0 MB tunable, 13797 MB untunable, and 0 MB freeable Dumping short stack ----- Abridged Call Stack Trace ----- ksedsts()+244<-ksm_pga_limit_short_stack()+1016<-ksm_check_over_limit()+924<-ksmarfg()+600<-kghgex()+1389<-kghfnd()+375<-kghalo()+4485<-kghprmalo()+1166<-kghalp()+1242<-kghssgai()+673<-kxsmbb()+461<-kxsBindBufferSetUp()+130<-kxsxsi()+1034<-opiexe()+5462<-opiall0()+1535 <-opikpr()+567<-opiodr()+1165<-rpidrus()+206<-skgmstack()+144<-rpiswu2()+769<-kprball()+1163<-kqlr_mark_dv_obsolete()+468<-kqlidp0_int()+3174<-kqlidp0()+217<-kkpalt()+5597<-opiexe()+15789<-opiosq0()+7792<-opipls()+11917<-opiodr()+1165<-rpidrus()+206<-skgmstack()+144 <-rpiswu2()+769<-rpidrv()+1507<-psddr0()+478<-psdnal()+636<-pevm_EXIM()+260<-pfrinstr_EXIM()+52<-pfrrun_no_tool()+60<-pfrrun()+818<-plsql_run()+712<-peicnt()+287<-kkxexe()+1200<-opiexe()+13318<-kpoal8()+2876<-opiodr()+1165<-kpoodr()+1230<-upirtrc()+2410<-kpurcsc()+102 <-kpuexec()+10934<-OCIStmtExecute()+41<-kupprwp()+7399<-ksvrdp()+1909<-opirip()+679<-opidrv()+616<-sou2o()+145<-opimai_real()+270<-ssthrdmain()+412<-main()+236<-__libc_start_main()+245 ----- End of Abridged Call Stack Trace -----
E também haviam mais mensagens relacioandas:
******************************************************
PRIVATE HEAP SUMMARY DUMP
15 GB total:
15 GB commented, 845 KB permanent
6171 KB free (0 KB in empty extents),
15 GB, 4 heaps: "callheap " 5 KB free held
*** 2021-05-19 10:30:59.856
------------------------------------------------------
Summary of subheaps at depth 1
14 GB total:
95 MB commented, 14 GB permanent
11 MB free (0 KB in empty extents),
A partir da versão 12cR1, o Oracle Database impõe um limite máximo de PGA que é controlado pelo parâmetro pga_aggregate_limit. Quando o uso de PGA pela instância chega nesse limite, o processo da sessão responsável por fazer o uso de memória chegar nesse limite é abortado pela instância.
O comum seria a sessão receber o erro ORA-04036: PGA Memory Used By The Instance Exceeds PGA_AGGREGATE_LIMIT, mas o Datapump abre a sessão no banco de dados habilitando o recurso de Resumable Space Allocation a nível de sessão, fazendo com que o processo fique em uma fila de espera até que o problema seja resolvido ou alcançar o timeout configurado na sessão. Nesse caso específico, parecia mais um loop infinito, pois a condição de erro nunca era resolvida.
Eu tenho um post aqui falando sobre Oracle Resumable.
Solução:
Temporariamente eu zerei o valor do parâmetro pga_aggregate_limit, permitindo a instância alocar memória para PGA o quanto possível, sem import limites, assim como ocorre na versão 11gR2. Também aumentei o valor do parâmetro pga_aggregate_target para um valor maior ao que estava como pga_aggregate_limit anteriormente.
Apenas para demonstração, o efeito do parâmetro METRICS=YES, a quantidade de objetos afetados e o tempo decorrido em cada tarefa é gravado no arquivo de log do Datapump:
Completed 12603 REF_CONSTRAINT objects in 1189 seconds
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/STATISTICS/TABLE_STATISTICS
Completed 7175 TABLE_STATISTICS objects in 1 seconds
Processing object type DATABASE_EXPORT/STATISTICS/MARKER