(DBMS_RLS) Oracle RLS (Row Level Security)를 사용하면 성능에 미치는 영향이 있습니까?

Question

일부 레코드를 숨기기 위해 Oracle RLS (Row Level Security)를 사용하는 경우 - 성능에 영향이 있습니까? SQL 쿼리 속도가 느려 집니까? Oracle 패키지는 DBMS_RLS입니다.

IS_HISTORICAL = T/F를 일부 테이블에 추가 할 계획입니다. 그런 다음 RLS를 사용하여 IS_HISTORICAL = T 값을 갖는 레코드를 숨 깁니다.

우리는 응용 프로그램에서 사용하는 SQL 쿼리 등, 서브 쿼리,/외부 조인 내부 상관 서브 쿼리와 매우 복잡 200 개 홀수 테이블의

에 대한 그들의 (50)는 것이이 정책을 RLS (기록을 숨기려면 에 의해 IS_HISTORICAL = T) 적용됩니다. 150 개의 테이블 중 나머지는이 50 개의 테이블의 하위 테이블이므로 RLS가 내재적입니다.

라이센스 영향?

감사합니다.

Answer 1

는 "어떤 성능 관련이 있습니까 - 내 SQL 쿼리를 느리게합니까?"성능에 관련된 모든 질문과 마찬가지로

대답은 "이 달려있다"입니다. RLS는

select /*+ rls query */ * from ( 
    select /*+ your query */ ... from t23 
    where whatever = 42) 
where rls_policy.function_t23 = 'true' 

그래서 성능에 미치는 영향이 함수에서 어떤 일이 일어나는지에 완전히 휴식 ... WHERE 절로서 정책 기능을 적용 외부 쿼리에서 제어 쿼리를 포장하여 작동합니다.

이러한 작업을 수행하는 일반적인 방법은 컨텍스트 네임 스페이스를 사용하는 것입니다. SYS_CONTEXT() 함수를 통해 액세스되는 미리 정의 된 세션 메모리 영역입니다. 따라서 컨텍스트에서 저장된 값을 검색하는 비용은 무시할 수 있습니다. 그리고 일반적으로 세션 당 한 번 네임 스페이스를 채우는 것처럼 (예 : 로그온 후 트리거 또는 유사한 연결 고리로) 쿼리 당 전체 비용은 사소한 것입니다. 성능에 영향을 줄 수있는 네임 스페이스를 새로 고치는 방법에는 여러 가지가 있지만 사물의 전반적인 스키마에서 사소한 것입니다 (see this other answer).

성능에 미치는 영향은 함수가 실제로하는 일에 달려 있습니다. 실제 정책의 고려 우리에게 가져다 어떤 :

"이 RLS 정책 (IS_HISTORICAL = T에 의해 기록을 숨기기 위해)"

좋은 소식은 이러한 기능의 실행이된다 그 자체로 비용이 많이 드는 일은 없을 것이다. 나쁜 소식은 성능이 여전히 Teh Suck 일 수 있다는 것입니다! 어쨌든, 실제 기록과 역사 기록의 비율이 불리한 경우. 아마도 모든 레코드를 검색 한 다음 이전 레코드를 필터링하여 제거하게 될 것입니다. 옵티마이 저는 RLS 술어를 기본 쿼리로 밀어 넣을 수 있지만 RLS 작동 방식 때문에 가능성이 희박하다고 생각합니다. 일반 시선에 대한 정책 기준을 밝히지 않습니다 (RLS 작업 디버깅을 실제 PITN으로 만듭니다).

귀하의 사용자는 열악한 설계 결정의 대가를 지불해야합니다. 저널링 또는 기록 테이블을 사용하여 이전 레코드를 저장하고 실제 데이터 만 실제 테이블에 보관하는 것이 훨씬 좋습니다. 살아있는 것들과 함께 역사적인 기록을 유지하는 것은 거의 비늘있는 해결책이 아닙니다.

"라이센스 영향?"

DBMS_RLS에는 Enterprise Edition 라이센스가 필요합니다.