Precisa descrever: a lógica da gaveta e do revisor do voucher não é transmitida para o flexfield no voucher através do campo elástico do submódulo e precisa ser penetrada no submódulo para obter, e a lógica de extração de cada submódulo ainda é é diferente. Atualmente, a escala de linhas de voucher e sub-razões é de dezenas de milhões. A eficiência da consulta conjunta de várias tabelas é um pouco baixa, porque o custo de reescrever o SQL é muito alto. Com a premissa de não alterar a lógica de negócios código tanto quanto possível, a estrutura do código é transformada e configuração de parâmetros para otimização.
Método experimentado: tentei os seguintes métodos sucessivamente
SQL TUNING
Usando o plano de execução SQL integrado da Oracle para reescrever, o plano de execução reescrito não obteve resultados muito bons
Reescrita de SQL
Reescrita de SQL: Mesclar vários SQLs de subcategorias em uma visão ampla, em vez de extraí-los segmentadamente em tabelas temporárias, o resultado é mais lento que o original e não é viável.
Dbms_Parallel_Execute
Dbms_Parallel_Execute, esse paralelismo é usado principalmente para tabelas de entidade, porque os dados não podem ser encontrados ao decompor tarefas com base em tabelas temporárias baseadas em sessão, o que não é viável.
função de pipeline
A função de pipeline geralmente não precisa materializar o grupo de resultados da consulta, semelhante à tecnologia de streaming de mídia, a consulta conjunta tradicional é materializar o conjunto de resultados e, em seguida, gerar o resultado, enquanto a função de pipeline pode retornar o resultado assim que ele é executado e pode ser aberto paralelamente.
Usando a tecnologia de função de pipeline, o OBJECT e o TYPE correspondentes à exibição em 1 são estabelecidos, mas o resultado não é tão ideal quanto antes da otimização.
função de cache
Para os mesmos parâmetros de entrada, a função de cache não precisa executar SQL para obter o resultado e armazena diretamente em cache o retorno.
Encapsule a lógica de obter o criador e verificar a pessoa em uma função de cache, mas para o parâmetro de entrada da credencial je_header_id + linha de credencial je_line_num, a taxa de reutilização não é alta, portanto, o efeito imediato não é óbvio.
visão materializada
A visualização materializada é equivalente à tabela de entidades e é usada principalmente para consultas conjuntas da interação DB_LINK, evitando o consumo de tempo causado pela espera da rede e usando espaço para tempo.
CREATE MATERIALIZED VIEW xxxx_MV
REFRESH FORCE ON DEMAND
START WITH TO_DATE('23-06-2021 11:04:22', 'DD-MM-YYYY HH24:MI:SS') NEXT SYSDATE+5/(24*60) --每五分钟刷新一次
AS
--select 逻辑
Ao usar visualizações materializadas, você precisa prestar atenção a dois métodos de atualização, um é a atualização completa, que não depende da tabela de log da visualização materializada, e o outro é a atualização incremental, que precisa criar uma tabela de log para cada entidade tabela projetada para a visualização materializada. Ambos os métodos têm um impacto no desempenho do banco de dados. Isso tem um certo efeito, mas os dados em tempo real são atrasados e o tempo de atraso depende do tempo de atualização da visualização materializada.
uso final
Visualização materializada + cache de funções + regravação de SQL + (comparação de mesclagem)
Encapsule toda a lógica de consulta de contas subcategorizadas em uma visualização materializada e atualize totalmente a visualização materializada por tempo de trabalho.
Para os dados gerados durante o intervalo de atualização, os novos dados são complementados usando o método de comparação de mesclagem.
Depois de usar esses dois métodos, o tempo foi bastante aprimorado e a solicitação original de mais de uma hora pode ser reduzida para cerca de dez minutos. Por meio da análise hierárquica do código por meio do DBMS_HPROF, verifica-se que a função de função padrão (via CCID) chamado em SELECT é obtido. A função descrita em chinês na seção COA é demorada, então fiz uma função personalizada para esta parte, e sua essência é fazer um shell com uma função de cache, para que para o mesmo CCID, não há necessidade de executar consulta sql, e é diretamente do cache Economiza muito tempo para retornar os dados. Depois de alterar o sql que demorou 12 minutos para usar uma função shell com uma função de cache, pode ser melhorado para dentro de 2 minutos, economizando 10 minutos de tempo.
Após a transformação abrangente, o SQL que costumava levar mais de uma hora agora pode ser executado por dois minutos para produzir resultados
Resumir
Antes de entrevistar candidatos para desenvolvimento de dados ETL, eles às vezes perguntavam como otimizar.A maioria dos candidatos tinha duas respostas: veja o plano de execução SQL + transformação de índice.
A otimização do desempenho do SQL não é um processo único. Ele precisa ser combinado de forma abrangente com a transformação do negócio, como se o SQL pode ser reescrito, quanto paralelismo o desempenho atual do hardware pode suportar e se o espaço pode ser trocado por tempo, etc.