오라클 저장 프로시저 실행 시간이 실행 방식에 따라 크게 증가하는 이유는 무엇입니까?

오라클 저장 프로시저 실행 시간이 실행 방식에 따라 크게 증가하는 이유는 무엇입니까?

이것은 제 문제입니다. 우리는 다음과 같은 저장 프로시저를 가지고 있습니다.HEAVY_SP실행 방법에 따라 실행 시간이 크게 늘어납니다.

(1)호실행

Oracle SQL Developer IDE에서 직접 실행

CALL HEAVY_SP(0, 'F', 5, ...)

15초가 소요됩니다(현재 솔루션).

(2)재생 버튼 사용

Oracle SQL Developer를 사용하여 프로시저 열기 및 "play" 버튼 실행:

15초걸립니다.

(3)dbms_job : 예약 모드

15초걸립니다.

(4)dbms_job : 인스턴트 실행 모드

1시간 이상 걸립니다.

데이터 처리 방법을 검토해 보면 각 반복이 매우 느리다는 것을 알 수 있습니다.

(5)SQL_PLUS(리눅스)의 출처

1시간 이상 소요됨, 반복이 매우 느림

(6)자바(JAVA)에서

1시간 이상 소요됨, 반복이 매우 느림

(7)From TOAD

1시간 이상 소요됨, 반복이 매우 느림

조사.

우리는 다음과 같은 구글 페이지를 많이 먹어왔습니다.

왜 query에서 slower에서 stored에서 procedure에서 query에서-

oracle-pl-sql-procedure-runs-slower-than-sql

Oracle-insert-in-stored-procedure-매우 느린-삽입-compared-실행-

보관-proc-러닝-30-slower스루-java-versus-러닝-directly-온-온-

그래서 제 질문은 다음과 같습니다.

• Oracle은 왜 이러한 방식으로 작동합니까?
• 모든 시나리오(같은 파라미터)에서 빠르게 동작해야 하는 것 아닌가요?
• 저장 프로시저를 수정해야 합니까?
• 쿼리 계획, 추적 파일 또는 통계가 다른 동작을 나타내는 경우 저장 프로시저를 수정해야 합니까?
• 쿼리 창에서 실행 속도가 빠른 이유는 무엇입니까?

미리 감사드립니다.

---

댓글 정보

팁 #1

통계에 관한 @BobJarvis의 권장사항을 따릅니다.

결과 : 우리의 통계는 최신입니다.심지어 사형까지 당했습니다.EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SOME_USER', tabname=>'SOME_TABLE', cascade => TRUE);모든 문제의 표에서 결과는 같습니다.

---

팁 #2

@KonstantinSorokin의 권고를 따름

세션 설정의 차이로 인해 실행 계획이 다를 수 있다고 생각합니다.비교를 고려합니다.v$ses_optimizer_env

결과 : (1) 시나리오와 (4) 시나리오에 대해 v$ses_optimizer_env를 비교한 결과 v$ses_optimizer_env가 같습니다.

---

팁 #3

다음 쿼리 사용:

select s.sid,s.serial#,s.username, s.machine,replace(q.SQL_FULLTEXT,chr(0)) sql_text, s.program, s.logon_time, s.status, s.OSUSER
from v$session s, v$sql q
where 
s.status='ACTIVE'
and s.username is not null 
and s.sql_hash_value = q.hash_value
order by s.LOGON_TIME, s.username;

테스트에 따라 기계, 프로그램 및 사용자가 바뀌는 것을 확인했습니다.

FAST MODE(쿼리 창)

machine             | program           | ouser
--------------------|------------------ | -------
my laptop username  | SQL DEVELOPER     | User

LAG MODE(백그라운드 실행)

machine             | program           | ouser
--------------------|------------------ | -------
ip-10-6-7-1         | oracle@ip-10-6-7-1| rdsdb

---

팁 #4

@KonstantinSorokin의 흔적 관련 권고사항을 따릅니다.

결과: 한 임시 DBA가 조사를 해보니 일부 sql_id의 실행 계획이 서로 다르다고 합니다.그의 조언은 힌트를 사용하라는 것이었습니다.

이것이 해결책이 될 수도 있지만, SQL ID마다 실행 계획이 다른 이유는 무엇입니까?

---

[해결]

@IsaacMejia 덕분에 NLS_COMP= linguISTIC이 느리게 실행되는 이유가 되었습니다.그래서 자바가 문제의 원인이 아니었습니다.오라클의 잘못된 구성이 문제의 원인이었습니다.

인스턴스 레벨에서 NLS_COMP= binary에 대해 솔루션이 올바른 값으로 설정되어야 합니다.

하지만 제 경우에는 이 값으로 잘 작동하는 애플리케이션이 여러 개 있습니다.따라서 애플리케이션의 주문 및 비교 문제를 방지하기 위해 인스턴스 NLS 설정을 무시할 수 없습니다.

임시 솔루션은 저장 프로시저를 시작할 때 실행됩니다.

execute immediate 'alter session set NLS_COMP=''BINARY''';

완료 시 이전 값으로 돌아갑니다.

execute immediate 'alter session set NLS_COMP=''LINGUISTIC''';

이제 저장 프로시저를 쿼리 창(ORACLE SQL Developer)에서 직접 실행만큼 빠르게 실행할 수 있습니다.

nls 매개 변수를 다른 경우(ides 또는 Java 프로그램)에서 가져오십시오. 매개 변수는 서로 달라야 합니다.

select * from NLS_SESSION_PARAMETERS

그런 다음 저장 절차 내부에서 변수를 가장 빠른 경우와 같게 설정합니다.

  execute immediate 'alter session set NLS_SORT=''SPANISH''';

SP가 모든 nns 파라미터를 갖게 되면,빨리 달릴 것입니다.

나는 최근에 Alter 세션에서 비슷한 경우가 Hibernate를 통해 쿼리 속도를 늦추는 것을 발견했습니다. 그러나 그들의 경우 매개 변수를 변경한 다음 느려졌습니다.

조사한 결과, NLS_COMPY NLS_SORT 매개변수가 오라클이 문자열에 실행 계획을 사용하는 방식에 영향을 줄 수 있음을 발견했습니다(비교 또는 주문 시).

NLS_COMP가 LINGUGISTIC으로 정의되면 NLS_SORT의 언어 정의를 사용합니다.

예를 들어, NLS_COMP = LINGUISTIC 및 NLS_SORT = BINARI_인 경우AI 당신의 문의는

select * from table where string_column like 'HI%'

내부적으로는 그렇게 될 것입니다.

select * from table where  
NLSSORT(string_column,'BINARI_AI') >= HEXTORAW('324242432')
NLSSORT(string_column,'BINARI_AI') >= HEXTORAW('675757576')

NLSSORT(열)에 대한 인덱스가 없는 경우'비나리_AI') 매우 느릴 것입니다.

NLS_SORT= binary_를 알고 있음AI는 당신의 주문과 비교를 악센트에 민감하지 않고 대소문자에 민감하지 않게 만들 것입니다.

언급URL : https://stackoverflow.com/questions/41841491/why-oracle-stored-procedure-execution-time-is-greatly-increased-depending-on-how