SQL 공유 및 재사용 (2)

1.2.1 소프트 파싱 vs 하드 파싱

• 생성된 내부 프로시저를 반복해서 재사용할 수 있도록 캐싱해 두는 메모리 공간은 '라이브러리 캐시(Library Caache)'라고 한다
  • 서버 프로세스와 백그라운드 프로세스가 공통으로 액세스하는 데이터와 제어 구조를 캐싱하는 메모리 공간

https://proudev.tistory.com/79

• SGA : 모든 사용자가 쓰는 공유 메모리
• Library Cache에서 찾는 방법 : 해시코드 or 문자열 찾기
• SQL을 캐시에서 찾아 곧바로 실행단계로 넘어가는 것을 '소프트 파싱(Soft Parsing)'
• 찾는 것을 실패해 최적화 및 로우 소스 생성 단계까지 모드 거치는 것을 '하드 파싱(Hard Parsing)'

 

소프트파싱 vs 하드파싱

• 하드 파싱은 CPU를 많이 소비하는 몇 안되는 작업 중 하나이다
  • 이런 어려운 작업을 거쳐 생성한 내부 프로시저를 한번 사용 후 버리는건 비효율이다
  • 이것이 라이브러리 캐시가 필요한 이유 (효율적으로 내부프로시저를 사용하기 위해서)

 

---

1.2.2 바인드 변수의 중요성

 

이름없는 SQL 문제

• SQL은 이름이 따로 없다 → 전체 SQL 텍스트가 이름 역할을 한다
• 텍스트 중 작은 부분이라도 수정되면 그 순간 다른 객체가 새로 탄생하는 구조이다
• SQL ID : SQL 전체 텍스트를 간략히 표현하려고 오라클이 내부 함수를 이용해 생성한 값
  • SQL ID : SQL 전체 텍스트 = 1:1
• 모든 SQL을 저장하려면 많은 공간이 필요하다 → SQL을 찾는 속도가 느려진다 → Oracle, SQL Server 같은 DBMS가 SQL을 영구 저장하지 않는 이유

공유 가능 SQL

SELECT * FROM emp WHERE empno = 7900;
select * from EMP where EMPNO = 7900;
select * from emp where empno = 7900;

• 라이브러리 캐시에서 SQL을 찾기 위해 사용하는 키 값이 'SQL 문 그 자체' 이므로 위는 모두 다른 SQL이다
• 의미적으로는 모두 같지만, 실행할 때 각각 최적화를 진행하고 라이브버리 캐시에서 별도 공간을 사용한다

---

SELECT * FROM CUSTOMER WHERE LOGIN_ID = '"+login_id+"'";
String SQLStmt "SELECT * FROM CUSTOMER WHERE LOGIN_ID = ?";

• 아래 : Prepared statement
  • 컴파일이 미리 되어있다
  • 위보다 성능이 좋다
  • 이 SQL에 대한 하드파싱은 최초 한번만 일어나고, 캐싱된 SQL을 공유하면서 재사용한다