Esta semana, realizei o import de um database contendo três esquemas, totalizando aproximadamente 8 TB.
O maior esquema possuía duas tabelas que, juntas, somavam cerca de 3,5 TB.
Durante a execução do Oracle Data Pump, o processo tornou-se extremamente lento justamente na importação dessas duas tabelas. O comportamento chamou a minha atenção, pois o import estava sendo executado com paralelismo 20 em um ambiente Exadata, que não apresentava qualquer limitação de performance.
Ao analisar os eventos de espera, identifiquei que as sessões do import estavam majoritariamente aguardando pelo evento enq: SQ – contention.
Esse evento ocorre quando múltiplas sessões paralelas (no caso, os 20 workers do Data Pump) tentam obter simultaneamente o próximo valor de uma Identity Column ou Sequence, porém o cache configurado é insuficiente, gerando contenção e impactando diretamente a performance.Para corrigir o problema, realizei os passos abaixo:
1 – Verifiquei os eventos de espera do import:
SELECT inst_id,
sid,
serial#,
event,
p1text,
p1 AS "file_id/nfs_fh",
p2text,
p2 AS "block_id/offset",
wait_time_micro/1000 "ms_waiting",
state
FROM gv$session
WHERE module = 'Data Pump Worker'
AND status = 'ACTIVE'
AND event NOT LIKE '%idle%';2 – Verifiquei o cache das sequences, criei um script para aumentar o cache e guardar o valor anterior para backup:
SELECT sequence_owner,
sequence_name,
cache_size,
last_number,
'ALTER SEQUENCE '||'"'||sequence_owner||'"'||'.'||'"'||sequence_name||'" CACHE'||cache_size||';' ALTER_ORIGEM,
'ALTER SEQUENCE '||'"'||sequence_owner||'"'||'.'||'"'||sequence_name||'" CACHE 5000;' ALTER_ALTERAR
FROM dba_sequences
WHERE sequence_owner IN ('ADMSPED','ADMOIE')
AND cache_size <5000
ORDER BY cache_size ASC, sequence_owner;
3 – Após realizar o ajuste do cache das sequences, não houve melhora na performance; o processo continuou apresentando baixa performance.
Ao reavaliar os eventos de espera, constatei que a contenção ainda persistia.
Considerando que o ambiente utilizava a versão Oracle 12c, realizei então a verificação do cache das colunas com Identity por meio da view DBA_TAB_IDENTITY_COLS, com o objetivo de validar a configuração e identificar possíveis limitações relacionadas ao uso de Identity Columns durante o processo de importação.
Nessa análise, identifiquei que o cache configurado estava definido como 20, valor insuficiente para um cenário de importação com alto grau de paralelismo.
Após o aumento do cache de identity, o processo de importação passou a executar de forma significativamente mais rápida, eliminando a contenção observada anteriormente.
Eu interrompi o job de importação, alterei as configurações de cache das duas tabelas e, em seguida, iniciei o job novamente.
impdp \"/ as sysdba\" ATTACH=SYS_IMPORT_SCHEMA_01
Import> STOP_JOB=IMMEDIATEO script abaixo foi utilizado para gerar o backup da configuração atual e o respectivo comando ALTER SEQUENCE para aumentar o valor do cache. Fiz o ajuste do cache do identity das duas tabelas:
SELECT s.cache_size as cache_atual,
'ALTER TABLE ' ||'"'|| a.owner ||'"'|| '.' ||'"'|| a.table_name ||'"'||' MODIFY (' || a.column_name || ' GENERATED AS IDENTITY (CACHE ' || s.cache_size || '));' as script_backup,
'ALTER TABLE ' ||'"'|| a.owner ||'"'|| '.' ||'"'|| a.table_name ||'"'||' MODIFY (' || a.column_name || ' GENERATED AS IDENTITY (CACHE 5000));' as SEQ_IDENTITY_CACHE_MOD
FROM dba_tab_identity_cols a
JOIN dba_sequences s ON (a.sequence_name = s.sequence_name AND a.owner = s.sequence_owner)
WHERE a.owner IN ('ADMSPED', 'ADMOIE')
AND s.cache_size < 1000
ORDER BY s.cache_size ASC;
SYS@oragbl AS SYSDBA> ALTER TABLE "ADMSPED"."SPED_REG_C100" MODIFY (ID GENERATED AS IDENTITY (CACHE 50000));
SYS@oragbl AS SYSDBA> ALTER TABLE "ADMSPED"."SPED_REG_C190" MODIFY (ID GENERATED AS IDENTITY (CACHE 50000));
Iniciei o job de import:
impdp \"/ as sysdba\" ATTACH=SYS_IMPORT_SCHEMA_01
Import> START_JOB