You've got to find what you love.

Oracle - 바인드 변수에 대하여(테스트)

(sunshiny) — Sun, 06 May 2012 10:42:11 +0900

# 바인드 변수를 사용하라

바인드 변수는 쿼리에 있어서 플레이스 홀더(역자 주_placeholder, 빠져 있는 것을 대신하는 기호)다.
예를 들어 직원 123을 조회하기 위해 다음과 같은 쿼리를 할 수 있다.

select * from emp where empno = 123 ;

다른 방식으로는 이렇게도 쿼리할 수 있다.

select * from emp where empno = :empno ;

일반적인 시스템에는 사원번호 123을 한 번 조회하고 끝나고, 다음으로 사원번호 456을 조회하고, 그 다음엔 789를 조회하는 식이다.(역자 주_ 세 개의 사원번호를 조회하기 위해 세 개의 서로 다른 Literal SQL을 실행한다)
아니면 위에 말한 SELECT 문장들처럼 인서트 문을 사용하는데, 바인드 변수를 사용하지 않으면 기본키 값(empno)이 문장 안에 하드 코딩될 것이다.
그리고 인서트 문장은 다시는 재사용될 수 없을 것이다.(역자 주_ 물론 누군가 세 개의 사원번호와 동일한 사원번호를 입력하여 조회한다면 재사용될 것이지만)
쿼리 안에 상수를 대입하여 사용하면, 데이터베이스는 모든 쿼리를 새로운 쿼리로 인식하여 파싱하고, 문법을 검사하고, 보안을 체크하고, 옵티마이징하는 등의 일을 할 것이다.
즉 모든 쿼리가 실행될 때마다 다시 컴파일되어야 한다는 말이다.

두 번째 쿼리는 :empno라는 바인드 변수를 사용했다.
:empno 값은 쿼리가 실행될 때마다 주어진다.
이 쿼리는 한 번 컴파일 된 후 shared pool(라이브러리 캐시)에 저장되며, 동일한 쿼리가 실행될 때 shared pool에서 가져와 재사용될 수 있다.
성능과 확장성의 관점에서 두 가지 방식의 차이는 극적일 정도로 엄청나다.

성능 관점에서 바인드 변수의 사용 여부가 결과에 얼마나 큰 차이를 가져올 수 있는지를 간단한 테스트를 통해 알아보자.

SCOTT@ora10g>create table t( x int );

Table created.

SCOTT@ora10g>create or replace procedure proc1
  2  as
  3  begin
  4      for i in 1 .. 10000
  5      loop
  6          execute immediate
  7          'insert into t values ( :x )' using i;
  8      end loop;
  9  end;
 10  /

Procedure created.

-- 두번째 프로시저는 입력되는 각 로우마다 각각 다른 SQL(하드파스)문이 실행되도록 하였다.

SCOTT@ora10g>create or replace procedure proc2
as
  2    3  begin
  4      for i in 1 .. 10000
  5      loop
  6          execute immediate
  7          'insert into t values ( '||i||')';
  8      end loop;
  9  end;
 10  /

Procedure created.

/*
    위 두 프로시저의 차이점은 바인드 변수를 사용한 것과 그렇지 않은 것과의 차이다.
    둘 다 동적 SQL을 사용했으며 로직은 동일하다.
    즉, 바인드 변수의 사용 여부에만 차이가 있다.

    두개의 결과물을 비교하기 위해 필자(토마스 카이트)가 개발한 runstats라는 툴을 사용할 것이다.
*/

SCOTT@ora10g>set serveroutput on
SCOTT@ora10g>
SCOTT@ora10g>exec runstats_pkg.rs_start

PL/SQL procedure successfully completed.

SCOTT@ora10g>exec proc1


PL/SQL procedure successfully completed.


SCOTT@ora10g>exec runstats_pkg.rs_middle

PL/SQL procedure successfully completed.

SCOTT@ora10g>exec proc2


PL/SQL procedure successfully completed.

SCOTT@ora10g>exec runstats_pkg.rs_stop(10000)
Run1 ran in 91 cpu hsecs
Run2 ran in 629 cpu hsecs
run 1 ran in 14.47% of the time

/*
    아래에서 제시할 결과는 CPU Time에 근거해서, 바인드 변수를 사용하지 않은 것이 바인드 변수를 
    사용한 것에 비해 10,000개의 로우를 입력하는 데 훨씬 긴 시간이 필요하고,
    훨씬 더 많은 자원을 차지한다는 것을 명백하게 보여 준다.
    바인드 변수 없이 로우들을 입력하면 CPU Time이 약 20배나 더 소모되었다.
*/

Name                                  Run1        Run2        Diff
STAT...parse count (hard)                5      10,012      10,007
STAT...parse count (total)              38      10,053      10,015
STAT...calls to get snapshot s          67      10,094      10,027
STAT...recursive calls              10,422      20,966      10,544
LATCH.simulator hash latch             194      11,336      11,142
LATCH.simulator lru latch              173      11,324      11,151
STAT...db block gets from cach      10,406      30,368      19,962
STAT...db block gets                10,406      30,368      19,962
LATCH.enqueues                         715      21,355      20,640
LATCH.enqueue hash chains              781      21,492      20,711
LATCH.session allocation               287      28,804      28,517
STAT...session logical reads        10,711      40,591      29,880
LATCH.library cache pin             40,589      75,113      34,524
LATCH.kks stats                          8      40,344      40,336
LATCH.library cache lock               559      62,594      62,035
LATCH.cache buffers chains          56,165     129,165      73,000
STAT...physical read bytes               0      81,920      81,920
STAT...physical read total byt           0      81,920      81,920
LATCH.row cache objects                494     128,030     127,536
STAT...session uga memory           65,464     -65,464    -130,928
STAT...session pga memory           65,536     -65,536    -131,072
STAT...session pga memory max      262,144      65,536    -196,608
LATCH.library cache                 41,215     239,696     198,481
STAT...session uga memory max      261,964      57,880    -204,084
LATCH.shared pool                   20,470     229,382     208,912

Run1 latches total versus runs -- difference and pct
Run1        Run2        Diff       Pct
164,982   1,009,419     844,437     16.34%

PL/SQL procedure successfully completed.

바인드 변수를 사용한 첫 번째 방법은 4번 하드 파스를 했고, 바인드 변수를 사용하지 않은 것은
입력하는 문장마다 한 번씩 10,000번 하드 파스를 했다는 것을 알 수 있다.
그러나 하드 파싱 항목의 차이는 단지 빙산의 일각일 뿐이다.
여기서 바인드 변수를 사용하지 않는 방법은 바인드 변수를 사용하는 것보다
거의 20배 정도의 래치를 사용했다는 것을 알 수 있다.

출처 : 전문가를 위한 오라클 데이터베이스 아키텍처 - 토마스 카이트

Oracle - 디폴트 롤, DBA, CONNECT, RESOURCE

(sunshiny) — Fri, 27 Apr 2012 17:39:45 +0900

# 디폴트 롤
데이터베이스 설치 시, 디폴트 스키마들이 생성되는 것처럼 디폴트 롤 또한 생성되게 된다.
이 디폴트 롤의 대부분은 많은 문제점을 내포하고 있으며, 조만간 변경되거나 삭제될 것이다.

* CONNECT 롤
버전에 따른 데이터베이스에 대한 접근 외의 권한도 존재

* RESOURCE 롤
다양한 권한을 이미 내장하고 있으며, UNLIMITED_TABLESPACE 라는 권한이 숨겨진 상태로 할당되어 있어 이 권한을 가지는 사람은 데이터베이스 내에서 존재하는 모든 테이블스페이스들을 대상으로 무제한 저장공간을 사용하는 것이 가능하다.
이 롤의 사용 여부를 반드시 재검토해보아야만 한다.

- Release 9.2.0.8.0 - Production

SQL> SELECT * --PRIVILEGE
  2      FROM DBA_SYS_PRIVS
  3      WHERE GRANTEE IN('CONNECT', 'RESOURCE')
  4  ;

GRANTEE                        PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
CONNECT                        CREATE VIEW                              NO
CONNECT                        CREATE TABLE                             NO
CONNECT                        ALTER SESSION                            NO
CONNECT                        CREATE CLUSTER                           NO
CONNECT                        CREATE SESSION                           NO
CONNECT                        CREATE SYNONYM                           NO
CONNECT                        CREATE SEQUENCE                          NO
CONNECT                        CREATE DATABASE LINK                     NO
RESOURCE                       CREATE TYPE                              NO
RESOURCE                       CREATE TABLE                             NO
RESOURCE                       CREATE CLUSTER                           NO
RESOURCE                       CREATE TRIGGER                           NO
RESOURCE                       CREATE OPERATOR                          NO
RESOURCE                       CREATE SEQUENCE                          NO
RESOURCE                       CREATE INDEXTYPE                         NO
RESOURCE                       CREATE PROCEDURE                         NO

16 rows selected.

- Release 10.2.0.1 , Release 11.2.0.1

SQL> SELECT * --PRIVILEGE
  2      FROM DBA_SYS_PRIVS
  3      WHERE GRANTEE IN('CONNECT', 'RESOURCE')
  4  ;

GRANTEE                        PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
CONNECT                        CREATE SESSION                           NO
RESOURCE                       CREATE TRIGGER                           NO
RESOURCE                       CREATE SEQUENCE                          NO
RESOURCE                       CREATE TYPE                              NO
RESOURCE                       CREATE PROCEDURE                         NO
RESOURCE                       CREATE CLUSTER                           NO
RESOURCE                       CREATE OPERATOR                          NO
RESOURCE                       CREATE INDEXTYPE                         NO
RESOURCE                       CREATE TABLE                             NO

9 rows selected.


/*
    테스트 계정 생성
    Release 11.2.0.1
*/

SQL> CREATE USER user_test IDENTIFIED BY test ;

User created.

SQL> SELECT GRANTEE, PRIVILEGE
  2      FROM DBA_SYS_PRIVS
  3      WHERE PRIVILEGE LIKE 'UNLIMITED%'
  4      AND GRANTEE = 'USER_TEST'
  5  ;    

no rows selected

-- RESOURCE 롤 권한 부여
SQL> GRANT RESOURCE TO user_test ;

Grant succeeded.

SQL> SELECT GRANTEE, PRIVILEGE
  2      FROM DBA_SYS_PRIVS
  3      WHERE PRIVILEGE LIKE 'UNLIMITED%'
  4      AND GRANTEE = 'USER_TEST'
  5  ;  

GRANTEE                        PRIVILEGE
------------------------------ ----------------------------------------
USER_TEST                      UNLIMITED TABLESPACE

이 외에도 잘못 쓰이는 롤로서 DBA도 존재한다.
이와 같이 디폴트 롤들이 잘못 사용되어지는 일이 없도록 관리하려면 다음의 세 가지 방식들을 고려하면 된다.

1. 디폴트 롤들에게 할당된 권한을 박탈한다.
2. 디폴트 롤들을 삭제한다. 하지만 이 같은 경우 몇몇 애플리케이션 스키마에서 문제가 발생할 수 있기 때문에 기존에 검토해야만 하는 사항들이 많이 존재한다.
3. DBA, CONNECT, RESOURCE 등과 같은 디폴트 롤들을 일반 유저에게 할당하지 않는다.

다음은 DBA_ROLES 뷰를 조회한, 디폴트 환경에서 제공되는 디폴트 롤들의 리스트이다.
이 개별적인 롤들이 포함하고 있는 권한들의 파악 및 유저에게의 할당 현황, 설정 및 사용 내역은 반드시 초기에 모니터링 해야 하는 부분이다.

SQL> DESC DBA_ROLES;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 ROLE                                      NOT NULL VARCHAR2(30)
 PASSWORD_REQUIRED                                  VARCHAR2(8)
 AUTHENTICATION_TYPE                                VARCHAR2(11)

SQL> SELECT COUNT(*) FROM DBA_ROLES ;

  COUNT(*)
----------
        55

SQL> SELECT * FROM DBA_ROLES ;

ROLE                           PASSWORD AUTHENTICAT
------------------------------ -------- -----------
CONNECT                        NO       NONE
RESOURCE                       NO       NONE
DBA                            NO       NONE
SELECT_CATALOG_ROLE            NO       NONE
EXECUTE_CATALOG_ROLE           NO       NONE
DELETE_CATALOG_ROLE            NO       NONE
EXP_FULL_DATABASE              NO       NONE
IMP_FULL_DATABASE              NO       NONE
LOGSTDBY_ADMINISTRATOR         NO       NONE
DBFS_ROLE                      NO       NONE
AQ_ADMINISTRATOR_ROLE          NO       NONE
AQ_USER_ROLE                   NO       NONE
DATAPUMP_EXP_FULL_DATABASE     NO       NONE
DATAPUMP_IMP_FULL_DATABASE     NO       NONE
ADM_PARALLEL_EXECUTE_TASK      NO       NONE
GATHER_SYSTEM_STATISTICS       NO       NONE
JAVA_DEPLOY                    NO       NONE
RECOVERY_CATALOG_OWNER         NO       NONE
SCHEDULER_ADMIN                NO       NONE
HS_ADMIN_SELECT_ROLE           NO       NONE
HS_ADMIN_EXECUTE_ROLE          NO       NONE
HS_ADMIN_ROLE                  NO       NONE
GLOBAL_AQ_USER_ROLE            GLOBAL   GLOBAL
OEM_ADVISOR                    NO       NONE
OEM_MONITOR                    NO       NONE
WM_ADMIN_ROLE                  NO       NONE
JAVAUSERPRIV                   NO       NONE
JAVAIDPRIV                     NO       NONE
JAVASYSPRIV                    NO       NONE
JAVADEBUGPRIV                  NO       NONE
EJBCLIENT                      NO       NONE
JMXSERVER                      NO       NONE
JAVA_ADMIN                     NO       NONE
CTXAPP                         NO       NONE
XDBADMIN                       NO       NONE
XDB_SET_INVOKER                NO       NONE
AUTHENTICATEDUSER              NO       NONE
XDB_WEBSERVICES                NO       NONE
XDB_WEBSERVICES_WITH_PUBLIC    NO       NONE
XDB_WEBSERVICES_OVER_HTTP      NO       NONE
ORDADMIN                       NO       NONE
OLAPI_TRACE_USER               NO       NONE
OLAP_XS_ADMIN                  NO       NONE
OWB_USER                       NO       NONE
OLAP_DBA                       NO       NONE
CWM_USER                       NO       NONE
OLAP_USER                      NO       NONE
SPATIAL_WFS_ADMIN              NO       NONE
WFS_USR_ROLE                   YES      PASSWORD
SPATIAL_CSW_ADMIN              YES      PASSWORD
CSW_USR_ROLE                   YES      PASSWORD
MGMT_USER                      NO       NONE
APEX_ADMINISTRATOR_ROLE        NO       NONE
OWB$CLIENT                     YES      PASSWORD
OWB_DESIGNCENTER_VIEW          NO       NONE

55 rows selected.

출처 : 데이터베이스 보안 - 조은백

Oracle - 권한 및 롤 관리

(sunshiny) — Fri, 27 Apr 2012 17:05:27 +0900

# 권한 및 롤 관리

-- 계정 및 패스워드 정보    
SELECT NAME, PASSWORD 
    FROM SYS.USER$ WHERE TYPE#=1
;    

-- DBA 권한 사용자 조회
SELECT DISTINCT * --A.NAME
    FROM SYS.USER$ A, SYS.SYSAUTH$ B
    WHERE A.USER# = B.GRANTEE#
    AND B.PRIVILEGE# = 4 -- DBA 권한
;

- 시스템 권한
시스템 권한은 데이터베이스 내에서 데이터를 대상으로 하는 작업들을 제외한 나머지 영역에서 유저가 실행할 수 있는 모든 액션을 대상으로 한다.
실제 이러한 시스템 권한은 두가지로 소분류가 가능한데, 첫 번째로 특정 객체가 아니라 객체 종류 전체에 걸쳐 실행되는 권한으로 정의할 수 있으며, 흔히 'ANY' 권한으로 정의할 수 있다.
이러한 ANY 권한은 100개 이상이 존재한다.
ANY 권한의 예로서 EXECUTE ANY PROCEDURE 등을 생각해 볼 수 있으며, 이때 주의할 점은 ANY 권한을 할당받았다고 하여 SYS 소유의 객체까지 자동으로 대상이 되지는 않는다는 것이다.
이것은 07_DICTIONARY_ACCESSIBILITY 파라미터의 값을 TRUE 로 설정하였을 시에 적용되며, 보안상 심각한 문제를 유발할 수 있기에 항상 디폴트 값인 FALSE 를 유지해야만 한다.

SELECT NAME 
    FROM SYS.SYSTEM_PRIVILEGE_MAP ; 

SELECT NAME 
    FROM SYS.TABLE_PRIVILEGE_MAP ;

# 중요한 시스템 권한
부적절한 관리가 이루어졌을 경우, 데이터베이스 서버 상의 전체 통제권을 획득할 수 있는 중요한 시스템 권한들이 있다.

권한 명	설명
EXECUTE ANY PROCEDURE	가장 중요한 시스템 계열 권한 중 하나이며, 이 권한이 잘못 허가되었을 경우, DBA 권한을 순식간에 획득할 수 있다.
SELECT ANY DICTIONARY	SELECT ANY DICTIONARY 권한을 가진 유저는 데이터 딕셔너리 내의 모든 테이블을 조회할 수 있다. 예를 들어 SYS.USERS$ 테이블에서 각 유저별 패스워드의 해시 값을 획득하는 것이 가능하다. 일반적인 경우에 이 권한을 가진 유저가 DBSNMP 유저 계정이다. 이 유저 계정은 디폴트를 구축되는 계정 중 하나로서, DBA 권한이 없음에도 불고하고 데이터 딕셔너리를 조회할 수 있는 유저 계정으로서 이 유저 계정을 활용하여 DBA 권한을 획득하는 것이 가능하다.
GRANT ANY PRIVILEGE GRANT ANY ROLE GRANT ANY OBJECT PROVILEGE	이 중 어떠한 권한이라도 유저에게 할당될 경우, 해당 유저 계정은 데이터베이스의 통제권을 획득하는 것이 가능하다.
CREATE LIBRARY	만약 유저가 CREATE LIBRARY나 기타 LIBRARY 관련 권한을 할당받을 경우, 해당 유저는 외부저장 프로시저 내에 공격 코드를 심어 실행하는 것이 가능해 진다.

출처 : 데이터베이스 보안 - 조은백

Oracle - SQL*PLUS의 SYSDBA 접근 제어

(sunshiny) — Fri, 27 Apr 2012 16:23:26 +0900

# SQL*PLUS의 SYSDBA 접근 제어

UNIX 계열 운영체제에서 dba 그룹에 속해있는 계정들은 sqlplus / as sysdba 를 실행하여 SYSDBA로 접근하는 것이 가능하다.
주로 이와 같은 설정을 하는 경우는 편이성 및 SYS 암호 분실 시의 복구를 위함인데 이는 dba 그룹에 속한 모든 계정이 SYS로 접근 가능한 이유 때문에 또 다른 취약점을 생성해낼 수 있다.
SQLNET.ORA 파일에 다음과 같이 SQLNET.AUTHENTICATION_SERVICES 파라미터를 NONE 으로 설정할 경우, 위에서 자동 로그인 기능은 방지되어 반드시 SYS 유저 계정의 패스워드를 명시해야만 접근 가능하다.

# sqlnet.ora 파일

SQLNET.AUTHENTICATION_SERVICES= (NONE)

[oracle@sunshiny-net admin]$ sqlplus '/as sysdba'

SQL*Plus: Release 11.2.0.1.0 Production on Fri Apr 27 16:17:59 2012
Copyright (c) 1982, 2009, Oracle. All rights reserved.

ERROR:
ORA-01031: insufficient privileges

Enter user-name: system
Enter password:
ERROR:
ORA-01017: invalid username/password; logon denied

Enter user-name: system
Enter password:

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show user
USER is "SYSTEM"

출처 : 데이터베이스 보안 - 조은백

Oracle - PFILE, SPFILE 에 관하여

(sunshiny) — Fri, 27 Apr 2012 11:49:47 +0900

# spfile
oracle 9i 이전 버젼에서는 오라클 인스턴스가 텍스트 파일 형태인 init<SID>.ora 파일을 이용해서 구동되었었다.
이 파일은 기본적으로 ORACLE_HOME/dbs 디렉토리 에 위치하였었다.
하지만 oracle 9i 에서는 SPFILE이라는 것이 새로 추가되었는데, DB서버 내에 저장되는 바이너리 파일이라는 점이 차이점이다.
또한 인스턴스에 적용하고자 하는 파라미터 값의 변동사항을 인스턴스를 내리거나 구동시킬때마다 계속해서 적용될수 있게 할수 있다.

# init<SID>.ora 와 spfile<SID>.ora 의 차이점

init<SID>.ora
텍스트파일이며 수동으로 파일을 수정할수 있다.
DB재시작시 변경된 내용이 적용
ORACLE_HOME/dbs에 위치

spfile<SID>.ora
바이너리 파일이며 직접 파일을 수정해서는 안된다.
alter system 명령으로 record parameter 값을 변경한다.
변경된 값을 일시적인지 지속적인지 결정가능하며 변경된 값을 삭제 , 또는 롤백할수 있다. (scope 속성이용)
spfile의 생성은 init<SID>.ora 로부터 생성하여도된다.
SQL> create spfile='spfile<SID>.ora' from pfile = 'init<SID>.ora' ;

인스턴스에 적용시킬 파라미터를 spfile 또는 init<SID>.ora 파일에 저장할수 있는데
oracle 9i에서 인스턴스 구동시 참조하는 파일은 아래와 같다.

우선순위에 따라 참조하는 파일이 달라진다는것에 유념해야 한다.

1순위 - spfile<SID>.ora
2순위 - spfile.ora
3순위 - init<SID>.ora

그러므로 spfile<SID>.ora 파일이 없으면 spfile.ora 이파일도 없으면 , init<SID>.ora 순으로 참조하게 되는것이다.

세 파일모두 존재 하지않으면 오라클에서는 다음과 같은 에러를 발생시킨다.
   SQL> startup
   ORA-01078: failure in processing system parameters
   LRM-00109: could not open parameter file
   'D:\ORA901\DATABASE\INITORA901.ORA'

spfile을 확인하기 위해서는 다음과 같은 쿼리를 이용한다.

SQL> show parameter spfile ;

NAME TYPE    VALUE
------------------------------------ ----------- ------------------------------
spfile string    %ORACLE_HOME%\DATABASE\SPFILE%
   ORACLE_SID%.ORA

init.ora 파일의 지정.
인스턴스 구동시 init.ora파일을 명시적으로 지정하는 방법은 이전 버젼과 동일하다.
SQL>startup pfile='경로\init<SID>.ora'

마지막으로 인스턴스 구동중일때 , spfile의 parameter를 아래와 같이 바꿀수 있다.
SQL>alter system set processes = 200 scope = spfile ; --scope는 spfile로써 spfile<SID>.ora에 기록됨
System altered.
SQL>select name, value from v$spparameter
where name = 'processes';
   NAME    VALUE
   --------------- -----
   processes 200

SQL>alter system set db_cache_size = 3M;
SQL>alter system set db_keep_cache_size=3M;
SQL>alter system set db_recycle_cache_size=3M;
SQL>alter system set shared_pool_size=60M;

SQL>show parameter shared_pool_size ;

NAME    TYPE    VALUE
-----------------------    -----    -------------
shared_pool_size    big integer    67108864

--processesd를 200 으로 변경. 이떄 scope는 spfile로써 spfileSID.ora에 기록됨
alter system set processes = 200 scope=spfile;
--사용중인 spfile의 내용
select name, value from v$spparameter

[출처] [DEV.WON] ORACLE - spfile 에 대해|작성자 데브원