Automatic PGA Memory Management

What is Automatic PGA Memory Management?
Initialization parameters SORT_AREA_SIZE and HASH_AREA_SIZE are used to specify the maximum amount of memory for each session in Oracle8i or earlier.
In Oracle9i, the following parameters specify the maximum amount of the PGA memory available to all server processes for every instance.
(PGA: Program Global Area)

PGA_AGGREGATE_TARGET
Specify the total amount of PGA memory available to instance. You can dynamically change the parameter at instance level. Set the parameter to any value between 10M and 4096G-1 bytes.

WORKAREA_SIZE_POLICY
Specify if the size of the SQL workarea should be tuned automatically or manually.
AUTO: tune automatically
MANUAL: tune manually

When WORKAREA_SIZE_POLICY is set to MANUAL, the maximum amount of memory is defined by the parameter such as HASH_AREA_SIZE. When WORKAREA_SIZE_POLICY is set to AUTO, the maximum amount of memory is defined automatically and the parameters such as HASH_AREA_SIZE are ignored.
If PGA_AGGREGATE_TARGET is set, WORKAREA_SIZE_POLICY will be set to AUTO by default.

How to determine PGA_AGGREGATE_TARGET.
The following formula is used as a guideline.

OLTP systems:
PGA_AGGREGATE_TARGET=(total actual memory*80%)*20%

DSS systems:
PGA_AGGREGATE_TARGET=(total actual memory*80%)*50%

PGA_AGGREGATE_TARGET of DSS systems is determined larger than that of OLTP systems because DSS systems normally access large amount of data by sorting with ORDER BY or GROUP BY.

There three types of SQL workarea executions as follows:
optimal: workarea execution of which all processes such as sort are executed on memory
onepass: workarea execution that requires the minimum writes to a disk
multipass: workarea execution that requires heavy writes to a disk because SQL workarea is too low

The following are standard tuning goal:
workarea execution - optimal >= 90%
workarea execution - multiplass = 0%

Most of the workarea executions are executed in optimal mode to reduce workarea execution - onepass.
The following query enables you to monitor the status of PGA memory in V$STSSTAT.

select name ,value ,100*(value/ decode((select sum(value) from v$sysstat where name like 'workarea exec%'),0,null,(select sum(value) from v$sysstat where name like 'workarea exec%'))) pct from v$sysstat where name like 'workarea exec%' / NAME VALUE PCT ---------------------------------------------------------------------- workarea executions - optimal 1529 100 workarea executions - onepass 0 0 workarea executions - multipass 0 0

If VALUE of workarea execution - multiplass is not 0% or VALUE of workarea executions - onepass exceeds 10%, you need to increase PGA_AGGREGATE_TARGET. If VALUE of workarea executions - optimal is 100%, you may reduce PGA_AGGREGATE_TARGET.

http://www.insight-tec.com/en/mailmagazine/vol170.html 

관련 한글 문서 : http://openframework.or.kr/Wiki.jsp?page=AssignMemoryAutomaticallyForSQLExecution 

10053 trace

on

 alter session set events '10053 trace name context forever';

off

ALTER SESSION SET EVENTS '10053 trace name context OFF';

file ( oracle 11g )

$ORACLE_HOME/diag/rdbms/orcl/trace

oracle pivot

LISTAGG : oracle 11g r2 에서 새로 추가된 함수. 기존에 존재 하던
pivot 함수( 또는 복잡한 SQL) 보다 간결하고 간단하게 구현하도록 제공하고 있다.

Syntax :
LISTAGG   ( <expr> [ ,  <delimiter> )   WITHIN  GROUP   ( ORDER BY  <oby_expression_list> )

 

그외에 다른 방법으로 사용 가능한 SQL

1. PL /SQL

 create or replace type t_vc as table of varchar2(4000);
/

create or replace function pivot return t_vc pipelined
as
  v_last_deptno emp.deptno%type := null;
  v_line  varchar2(4000);
begin
  for r in (select deptno , ename from emp order by deptno) loop
    if v_last_deptno is null then
      v_line:=rpad(r.deptno,11) || ': ';
      v_last_deptno := r.deptno;
    end if;
    if r.deptno <> v_last_deptno then
      pipe row(v_line);
      v_line:=rpad(r.deptno,11) || ': ';
      v_last_deptno := r.deptno;
    end if;
    v_line := v_line || rpad(r.ename,11);
  end loop;
  pipe row(v_line);
  return;
end pivot;
/

출력결과

SQL> select * from table(pivot);

COLUMN_VALUE
-----------------------------------------------------------------------------------------------------------------------------------
10    : CLARK KING    MILLER
20    : JONES FORD    ADAMS      SMITH  SCOTT
30    : WARD TURNER    ALLEN      JAMES  BLAKE     MARTIN

2. SQL ( DECODE 사용 )

SELECT   a.deptno
    ,        MAX(DECODE(a.r, 1,a.ename))
             || MAX(DECODE(a.r, 2,', ' || a.ename))
             || MAX(DECODE(a.r, 3,', ' || a.ename))
             || MAX(DECODE(a.r, 4,', ' || a.ename))
             || MAX(DECODE(a.r, 5,', ' || a.ename))
             || MAX(DECODE(a.r, 6,', ' || a.ename))
             || MAX(DECODE(a.r, 7,', ' || a.ename))
             || MAX(DECODE(a.r, 8,', ' || a.ename))
             || MAX(DECODE(a.r, 9,', ' || a.ename))
             || MAX(DECODE(a.r,10,', ' || a.ename)) names
   FROM    (SELECT t.deptno
            ,      t.ename
            ,      ROW_NUMBER()
                   OVER (PARTITION BY t.deptno
                         ORDER BY     NULL) r
            FROM   emp t) a
   GROUP BY a.deptno
   ORDER BY a.deptno
   /

출력결과

    DEPTNO NAMES
---------- ----------------------------------------------------------------------------------------------------------------------
 10 CLARK, KING, MILLER
 20 JONES, FORD, ADAMS, SMITH, SCOTT
 30 WARD, TURNER, ALLEN, JAMES, BLAKE, MARTIN

 3. SQL ( sys_connect_by_path )

select deptno,
 substr( max( sys_connect_by_path( ename, '; ') ), 3 ) names
 from ( select deptno, ename, row_number() over ( partition by deptno order by ename ) rn
   from emp )
 start with rn = 1
 connect by prior deptno = deptno and
   prior rn+1 = rn
 group by deptno
 order by deptno
/

출력결과

     DEPTNO NAMES
---------- ----------------------------------------------------------------------------------------------------
 10 CLARK; KING; MILLER
 20 ADAMS; FORD; JONES; SCOTT; SMITH
 30 ALLEN; BLAKE; JAMES; MARTIN; TURNER; WARD

참고자료 :

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::NO::P11_QUESTION_ID:766825833740

Magic Number

Magic Number 란??
   -  Oracle 이 정확한 Selectivity 를 계산할 수 없을때 사용되는 Default  값이다.

Oracle 이 Magic Number 를 사용했다는것은 제대로된 실행계획을 산출해내지 못할 가능성이 높기 때문에,

상황에 따라서 통계정보 또는 SQL 튜닝을 해야 할 것이다.

Magic Number 는 주로 바인드 변수에 의하여 선택이 된다. 바인드 변수 사용시 어떤 값이 나올지 예측하기

힘들기 때문에 사용되는것이다.

1. Range : 5%

select * from t1 where c1 >= :b1;
select * from t1 where c1 <= :b1;
select * from t1 where c1 between :b1 and :b2;

2. Function : 1%

select * from t1 where f1(c1) = 1;
select * from t1 where f1(c1) = :b1;
select * from t1 where f1(c1) > :b1; -- 5%

Function 사용시 어떤 값이 return 될지 알수 없기 때문에 magic number 가 사용되며,
Function Based Index를 사용하여 해결 가능하다.

3. Like : 5%

select * from t1 where c1 like :b1;
select * from t1 where c1 like '%A';
select * from t1 where c1 like '%A%';

가급적 Magic Number 를 사용하지 않아야 겠지만 ...
Bind 변수의 경우 Soft Parsing 에 유리하기 때문에 trade off 를 고려하여(패턴에 따라서..) 튜닝해야 한다.

Lock Mode

데몬 프로세스 생성

http://kldp.org/node/62759  참고 ...

[펌] Buffer Cache 관련 Wait

[3] Buffer Cache 관련 Wait

■ Buffer Cache 구조

Buffer Cache의 기본적인 기능은 여러 프로세스에 의해 공통으로 자주 액세스 되는 데이터베이스 블록을 메모리에 캐쉬하여 물리적인 디스크 IO를 최소화함으로써 더 빠른 액세스 속도를 제공하기 위한 것이다. 복잡한 설명은 생략하고, Buffer Cache 의 기본구조를 이해하기 위한 몇 가지 핵심 용어들을 간단히 정리해 보도록 하겠다.

▷ Buffer header

모든 버퍼 블록들은 각자의 buffer header를 통해 액세스되고 관리된다. 즉, 메모리에 캐쉬된 특정 데이터 블록에 대한 액세스는 먼저 해쉬 알고리즘을 통해 cache chain 상의 buffer header를 찾고 해당 buffer header에 기록된 데이터 블록의 메모리상 주소를 찾아가 원하는 정보를 읽는 방식으로 이루어진다. Buffer header에 기록되는 주요정보는 다음과 같으며 Buffer header의 내용은 V$bh 뷰를 통하여 조회해볼 수 있다.

     - 메모리상에서의 해당 버퍼블록의 주소
     - 해당 버퍼 블록(실제로는 버퍼헤더)가 포함되어 있는 hash chain
     - LRU, LRUW, CKPTQ와 같은 리스트상에서의 해당 버퍼블록의 위치
     - 해당 버퍼블록에 대한 User, Waiter와 상태를 나타내는 각종 Flag 

▷ Hash Buckets/ Hash Chains

Buffer Cache의 모든 블록은 해쉬 알고리즘을 통해 관리된다. 곧, 데이터 블록의 DBA, Class 값으로 Hash Function을 적용하여 해당 블록이 속하는 hash buckets을 할당하며, 동일한 hash buckets에 할당되는 데이터 블록의 버퍼헤더들은 linked list형태로 hash chain을 이루게 된다. Hash buckets/hash chains는 특정 데이터 블록을 찾아가기 위한 수단을 제공한다. 각각의 hash buckets에는 자신에 속한 hash chain을 보호하기 위한 latch(cache buffers chains)가 할당된다. 

▷ LRU

LRU는 두개의 리스트, 즉 LRUW와 LRU 리스트의 쌍으로 구성된다. LRUW(LRU Write list)는 dirty list와 같은 말이며, 수정되어 디스크에 반영되어야 할 블록들의 리스트이다. LRU(Least recently used list)는 LRUW에 올라가지 않은 나머지 버퍼 블록들이 등록되어 있다. Buffer cache 상의 버퍼블록은 반드시 LRU나 LRUW 둘 중의 하나에 등록되며, 두 리스트에 동시에 포함되는 경우는 없다. LRU는 Free Buffer를 찾기 위한 수단을 제공한다. 경합을 피하기 위해 버퍼캐쉬 블록들을 여러 개의 LRU쌍으로 나누어 관리할 수 있으며, 각 LRU리스트를 보호하기 위해 Latch(Cache buffers lru chain)가 하나씩 할당된다.

■ Buffer Cache 운영규칙

▷ 메모리상의 특정 버퍼블록을 찾아가거나, 특정 블록이 메모리에 캐쉬 되어 있는지를 확인하기 위해서 오라클은 hash bucket/hash chain 구조를 사용한다. 

▷새로운 데이터블록을 디스크로부터 메모리로 읽어 들이기 위한 free buffer를 확보하기 위해 오라클은 LRU 리스트를 사용한다. 

▷ 버퍼블록은 LRU나 LRUW 둘 가운데 하나에 등록된다.

▷ 하나의 블록에 대해 시간대가 다른 여러 개의 복사본이 존재할 수 있으며, 그 가운데 오직 CURRENT 버퍼만이 변경될 수 있다. 

▷하나의 버퍼블록은 한번에 오직 하나의 프로세스에 의해서만 변경될 수 있다. 

■ Buffer Cache 관련 Waits

버퍼캐쉬와 관련되어 흔히 발생하는 대표적인 Wait 이벤트는 다음과 같다. 

▷ buffer busy waits

여러 세션이 동시에 같은 블록을 읽으려고 하거나 여러 세션이 같은 블록에 대한 변경작업이 완료되기를 기다리고 있는 경우에 발생하며, 특정 블록에 대한 경합을 해소하기 위한 조치는 블록의 유형에 따라 달라진다. Data block에 대한 경합이 많은 경우는 Pct free나 Pct used 값을 사용하여 블록 당 로우수를 줄이거나, 특정 블록에 로우 입력이 몰리는 구조의 인덱스(right-hand-index)일 경우는 reverse key index의 사용을 검토하는 등의 방법이 있으며, segment header의 경합이 많은 경우는 freelist 수를 늘리거나 Extent의 크기를 증가시키는 등의 방법이 있고, undo header나 undo block에 대한 경합은 롤백세그먼트의 개수나 크기를 증가시키는 것이 전형적인 조치 방법이다. v$waitstat과 x$kcbfwait을 이용하며 Class 또는 file별로 wait 발생상황을 판단할 수 있다. 

▷ free buffer waits/write complete waits

DBWR가 dirty buffer를 write하는 동안 서버 프로세스가 대기하고 있는 경우 발생한다. 곧, 너무나 많은 dirty buffer가 생겨나거나 DBWR의 쓰기 속도가 충분히 튜닝 되지 못한 경우에 발생한다. 점검 포인트는 물리적 디스크의 속성(stripe size, layour, cache size) 최적화, Raw device의 활용, Async IO나 multi-DBWR(db_writer_processes) 활용여부 등이다.

위와 같은 버퍼 블록에 대한 경합 역시 비효율적인 실행계획을 통해 수행되는 애플리케이션에 의하여 불필요하게 많은 블록이 메모리로 올라오는 것이 원인일 경우가 많으므로 경합이 빈번한 블록이 속하는 테이블/인덱스 명을 찾아낼 수 있다면 관련 SQL을 찾아내어 보다 효과적인 튜닝작업이 이루어질 수 있을 것이다. v$session_wait의 p1,p2 컬럼에 각각 file#, block#값을 표시하여 주므로 이 값을 이용하여 아래의 SQL문으로 현재 어떤 오브젝트에 대하여 해당 wait가 발생하고 있는지를 추적할 수 있다. ( 1회에 소개한 SQL문에서는 Additional Info 값을 참조. )

     select segment_name, segment_type
     from dba_extents
     where file_id = :file#
     and :block# between block_id and block_id + blocks -1

▷ cache buffers chains latch

SGA내에 캐쉬된 데이터블록을 검색할 때 사용된다. 버퍼캐쉬는 블록들의 chain을 이루고 있으므로 각각의 chain은 이 Latch의 child들에 의해 보호된다. 이 Latch에 대한 경합은 특정 블록에 대한 대량의 동시 액세스가 발생할 때 유발된다. 애플리케이션을 검토해 보아야 한다. 
Ø cache buffers lru chain latch
버퍼캐쉬의 버퍼를 LRU 정책에 따라 이동시켜야 할 필요가 있는 경우 프로세스는 이 Latch 획득하게 된다. 이 Latch에 대한 경합은 Multiple buffer pool을 사용하거나 DB_BLOCK_LRU_LATCHES 를 증가시켜 LRU Latch의 개수를 늘려서 해소할 수 있다. SQL문을 튜닝하면 해당 프로세스에 의해 액세스 될 블록의 수가 줄어들 것이므로 당연히 효과를 거둘 수 있다.

위와 같이 버퍼캐쉬를 관리하는 Latch에 대한 경합은 경합이 집중되는 특정 Child Latch에 의해 관리되는 버퍼블록을 찾아 해당 블록이 속한 세그먼트 정보를 알아낸다면 보다 효과적인 조치가 가능할 것인데, latch free wait일 경우 v$session_wait의 p1raw 값이 해당 Latch address를 의미한다. 이 값을 x$bh의 hladdr 값과 조인하면 관련 오브젝트 이름을 추적해볼 수 있다. 

     select file#, dbarfil, dbablk, obj, o.name
     from x$bh bh, obj$ o 
     where bh.hladdr = :latch_address
     and bh.obj = o.obj#;


http://www.oracle.com/technology/global/kr/pub/columns/dbtuning03.html?_template=/ocom/print

Understanding Oracle's Locally Managed Tablespaces

http://www.databasejournal.com/features/oracle/article.php/10893_2223631_1/Understanding-Oracles-Locally-Managed-Tablespaces.htm

Understanding Oracle's Locally Managed Tablespaces

By Amar Kumar Padhi

Locally Managed Tablespace (LMT) is one of the key features in Oracle database. These have been made available since Oracle 8i. It is worth using LMTs considering the benefits in doing so. I have put forward some scenarios that may be worth noting, for systems that are already using LMTs or planning to shift to LMTs.

Benefits of LMTs

Below are the key benefits offered by LMTs. Not all are achievable when migrating to LMTs.

1. Dictionary contention is reduced.

   Extent management in DMTs is maintained and carried out at the data dictionary level. This requires exclusive locks on dictionary tables. Heavy data processing that results in extent allocation/deallocation may sometimes result in contentions in the dictionary.

   Extents are managed at the datafile level in LMTs. Dictionary tables are no longer used for storing extent allocation/deallocation information. The only information still maintained in the dictionary for LMTs is the tablespace quota for users.

2. Space wastage removed.

   In DMTs, there is no implied mechanism to enforce uniform extent sizes. The extent sizes may vary depending on the storage clause provided at the object level or the tablespace level, resulting in space wastage and fragmentation.

   Oracle enforces the uniform extents allocation in the LMTs (when created with UNIFORM SIZE clause). Space wastage is removed, as this would result in all the same sized extents in the tablespace.

3. No Rollback generated.

   In DMTs, all extent allocations and deallocations are recorded in the data dictionary. This generates undo information thus using vital resources and may compete with other processes.

   In LMTs, no rollback is generated for space allocation and deallocation activities.

4. ST enqueue contention reduced.

   In DMTs, Space Transaction (ST) enqueue is acquired when there is a need for extent allocations in DMTs. It is also exclusively acquired by SMON process for coalescing free space in DMTs. Only one such enqueue exists per instance, and may sometimes result in contention and performance issues if heavy extent processing is being carried out. The following error is common in such scenario.

   ORA-01575: timeout warning for space management resource
   

   As ST enqueue is not used by LMTs it reduces the overall ST enqueue contention.

5. Recursive space management operations removed.

   In DMTs, SMON process wakes up every 5 minutes for coalescing free space in DMTs. Optionally, the ALTER TABLESPACE <tablespace name> COALESCE command is also used to coalesce DMTs and reduce fragmentation.

   On the other hand, LMTs avoid recursive space management operations and automatically track adjacent free space, thus eliminating the need to coalesce free extents. This further reduces fragmentation.

6. Fragmentation reduced.

   Fragmentation is reduced in LMTs but not completely eliminated. Since adjacent free spaces are automatically tracked, there is no need to do coalescing, as is required in the case of DMTs.

Management of Extents in LMTs

Oracle maintains a bitmap in each datafile to track used and free space availability in an LMT. The initial blocks in the datafiles are allocated as File Space Bitmap blocks to maintain the extent allocation information present in the datafile. Each bit stored in the bitmap corresponds to a block or a group of blocks. Whenever the extents are allocated or freed, oracle changes the bitmap values to reflect the new status. Such updates in the bitmap header do not generate any rollback information.

The number of blocks that a bit represents in a bitmap depends on the database block size and the uniform extent size allocated to the tablespace. For example, if the DB_BLOCK_SIZE parameter is set to 8K, and the tablespace is created with uniform extent sizing of 64K, then 1 bit will map to one 64K extent, i.e., 64K (extent size)/8K (block size) = 8 database blocks.

Allocation Types in LMTs

Allocation type plays a very important role in how the LMT is behaving. It specifies how the extent is being allocated by the system. There are three types of allocating extents in LMTs- USER, SYSTEM and UNIFORM.

• USER- The LMT behaves as DMT, allocating extents as per the storage clause provided with the object or defaulted at tablespace level. The advantage is that allocation of extents is managed at the datafile level and such tablespaces will not compete for ST enqueue. The disadvantage is that such tablespaces are not subject to uniform extent allocation policy. DMTs that are converted to LMTs fall under this type.

• SYSTEM- Oracle manages the space. The extents are auto allocated by the system based on an internal algorithm. Allocation of extents is managed at the datafile level and such tablespaces will not compete for ST enqueue. Such tablespaces would have extents of varying sizes and would result in fragmentation and some space being wasted. This is a good alternative if the extent sizes of the various objects to be placed in the tablespace cannot be determined.

• UNIFORM- All extents are of fixed size in the system. The size is provided when creating the LMT. This type gives all the benefits offered by LMT and one should aim at achieving this.
  
  
  

  Storage parameters usage in LMT

  Storage parameters are used in DMTs to specify the object sizing. These parameters are not of much importance in UNIFORM type LMTs but play a role in deciding the initial allocation of space. Oracle considers the storage clause for the initial number of extents that should be allocated. For example, LMT is created with 32K extent size. The database block size is 8k.

  SQL> create table am05 (col1 number)
    2  storage (initial 100k next 100k minextents 1 maxextents unlimited pctincrease 0);
  
  SQL> select segment_name, segment_type, extent_id,  bytes, blocks
    2  from user_extents where segment_name = 'AM05';
  
  SEGMENT_NAME         SEGMENT_TYPE        EXTENT_ID      BYTES     BLOCKS
  -------------------- ------------------ ---------- ---------- ----------
  AM05                 TABLE                       0      32768          4
  AM05                 TABLE                       1      32768          4
  AM05                 TABLE                       2      32768          4
  AM05                 TABLE                       3      32768          4
  

  Oracle allocates four extents, the total size being 128K that is closer to the 100K provided for initial extent size. Please note that all the extents allocated have the uniform extent size of 32K. Only the number of extents to be allocated is decided based on the storage clause. See example below to clarify this.

  SQL> create table am06 (col1 number)
    2  storage(initial 200k next 100k minextents 2 maxextents unlimited pctincrease 0);
  
  SQL> select segment_name, segment_type, extent_id,  bytes, blocks
    2  from user_extents where segment_name = 'AM06';
  
  SEGMENT_NAME         SEGMENT_TYPE        EXTENT_ID      BYTES     BLOCKS
  -------------------- ------------------ ---------- ---------- ----------
  AM06                 TABLE                       0      32768          4
  AM06                 TABLE                       1      32768          4
  AM06                 TABLE                       2      32768          4
  AM06                 TABLE                       3      32768          4
  AM06                 TABLE                       4      32768          4
  AM06                 TABLE                       5      32768          4
  AM06                 TABLE                       6      32768          4
  AM06                 TABLE                       7      32768          4
  AM06                 TABLE                       8      32768          4
  AM06                 TABLE                       9      32768          4
  
  10 rows selected.
  
  SQL> select sum(bytes)/1024 from  user_extents where segment_name = 'AM06';
  
  SUM(BYTES)/1024
  ---------------
              320
  

  As per the storage clause, the table should be allocated 200K + 100K of space (since minextents is 2). Oracle rounds off on the higher side and allocates 10 extents of 32K, totaling 320K.

  Even pctincrease plays a role in uniform LMTs as the below example shows.

  SQL> create table am07  (col1 varchar2(200))
    2  storage(initial 16K next 16K minextents 5 maxextents unlimited pctincrease 50);
  
  Table created.
  
  SQL> select segment_name, segment_type, extent_id,  bytes, blocks
    2  from user_extents where segment_name = 'AM07';
  
  SEGMENT_NAME         SEGMENT_TYPE        EXTENT_ID      BYTES     BLOCKS
  -------------------- ------------------ ---------- ---------- ----------
  AM07                 TABLE                       0      32768          4
  AM07                 TABLE                       1      32768          4
  AM07                 TABLE                       2      32768          4
  AM07                 TABLE                       3      32768          4
  AM07                 TABLE                       4      32768          4
  
  SQL> select sum(bytes)/1024 from  user_extents where segment_name = 'AM07';
  
  SUM(BYTES)/1024
  ---------------
              160
  

  As per the storage clause the required initial size of the table should be 146K (16 + 16 + 24 + 36 + 54), Oracle rounds on the higher side to 160K (5 32K extents).

  Hence, storage could be used to allocate the initial size for an object. The Default Storage clause cannot be specified for LMTs at tablespace level.

  SQL> create tablespace users4
    2  datafile 'D:\oracle\oradata3\users4.dfb' size 5M
    3  autoextend off
    4  extent management local uniform size 32K
    5  default storage(initial 100k next 100k minextents 2 maxextents unlimited pctincrease 50);
  create tablespace users4
  *
  ERROR at line 1:
  ORA-25143: default storage clause is not compatible with allocation policy
  

  Please refer the example section for LMT creations and migration examples.

DICTIONARY MANAGED TABLESPACE를 사용 대비, LOCALLY MANAGED TABLESPACE를 사용하는 것의 장점 [OTN]

제품 : ORACLE SERVER

작성날짜 :

DICTIONARY MANAGED TABLESPACE를 사용 대비, LOCALLY MANAGED TABLESPACE를 사용하는 것의 장점
===========================================================================================

PURPOSE

---

이 문서는, Locally Managed Tablespace에 대한 설명과 함께,
Dictionary Managed Tablespace 대비, 장점을 기술하는 데 목적이 있다.

Explanation

---

1. LOCALLY MANAGED TABLESPACE

Locally Managed Tablespace는, 자체 extent에 대한 관리를 각각의 데이터 파일에
비트맵 형식으로 저장하여 관리하는 테이블스페이스로, 데이터 파일을 구성하는
블럭이 비어 있는지, 사용 중인지에 대한 정보를 관리한다.
비트맵의 각각의 비트는, 하나의 블럭 또는 블럭의 그룹에 해당하는 정보를 나타낸다.

익스텐트가 할당되거나, 비워지거나, 재사용될 때, 오라클에서는 블럭의 새로운
상태를 나타내기 위해 비트맵의 값을 변경한다. 이와 같은 변경사항은 기본 방식인
Dictionary Managed Tablespace와는 달리,
rollback 정보를 생성하지 않는데, 이것은 데이터 딕셔너리의 테이블을 갱신하지
않기 때문이다 (테이블스페이스 별 quota 정보는 제외).

1) 공간 정보 관리를 위한 내부 작업을 줄임.
2) 데이터 딕셔너리 테이블에 대한 경합 감소됨.
3) 익스텐트 관리와 관련된 관련 rollback 생성이 되지 않음.
4) Coalescing 이 불필요함.

2. 테이블스페이스의 공간 관리

1) 사용되지 않는 익스텐트 정보가 비트맵에 의해 관리됨.
(따라서, 테이블스페이스의 일부분이 비트맵 정보를 저장하는 데 사용됨)
2) 각 비트는, 블럭이나, 블럭의 그룹의 정보를 나타냄.
3) 비트 정보는, 사용 중인지, 그렇지 않은지를 나타냄.
4) DBA_EXTENTS 나 DBA_FREE_SPACE 등의 뷰는 동일하게 사용됨.

3. 구문 규칙

EXTENT MANAGEMENT 절의 LOCAL 옵션을 사용하면, 테이블스페이스가
Locally Managed 방식으로 생성된다.

Extent_management_clause:
[EXTENT MANAGEMENT
{DICTIONARY | LOCAL
{AUTOALLOCATE | UNIFORM [SIZE integer M] }}

옵션 설명:

DICTIONARY 테이블스페이스에 대해 Dictionary Table를
사용하여 공간 정보를 관리함. ( 기본 값 )
LOCAL 테이블스페이스가에 대해 비트맵을 사용하여
Locally Managed 방식으로 공간 정보를 관리함.
AUTOALLOCATE 테이블스페이스에 대한 익스텐트 관리를 시스템에서
관장하도록 함.
(사용자는 익스텐트의 크기를 수동으로 지정할 수 없음)
UNIFORM 테이블스페이스가 동일한 크기의 익스텐트로 구성되도록
지정함. 크기는 기본적으로 바이트 단위로 지정
( 익스텐트 크기를 KB 또는 MB 단위로 지정하기 위해서는
K 또는 M 을 사용하여 지정)
이 옵션을 사용하게 되면, DEFAULT Storage 절,
MINIMUM EXTENT 또는 TEMPORARY 옵션을 사용할 수 없다.

Oracle 9.2 이전 버젼에서는, EXTENT MANAGEMENT 절을 SYSTEM 테이블스페이스를
제외한 permanent tablespace나, temporary tablespace 생성 시 지정할 수 있었다.
Oracle 9.2부터는 SYSTEM 테이블스페이스를 포함한 모든 테이블스페이스를
Locally managed 방식으로 생성할 수 있다.
CREATE DATABASE에서 EXTENT MANAGEMENT LOCAL 절을 사용하게 되면,
오라클에서는 SYSTEM 테이블스페이스를 Locally Managed Tablespace로 생성하며,
익스텐트의 크기는 오라클에서 결정하게 된다. 이 기능을 사용하기 위해서는,
COMPATIBLE 옵션이 9.2 또는 그 이상으로 지정되어 있어야 한다.
Locally Managed SYSTEM tablespace는 기본적으로 AUTOALLOCATE 방식을
사용하게 되며, Locally Managed 방식으로 SYSTEM 테이블스페이스를 생성할 때,
UNIFORM extent 크기를 지정할 수 없다.

다음 storage parameter(NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS)와
DEFAULT STORAGE는 Locally Managed Tablespace에서는 사용할 수 없다.

테이블스페이스 생성 후에는 공간관리 방법을 변경할 수 없다.

Oracle 8.1.6부터, Dictionary Managed Tablespace를 Locally Managed
Tablespace로 마이그레이션을 할 수 있으나, 8.1.5에서는 그와 같은 작업을
수행할 수 없다.

기존에 사용해 왔던 테이블스페이스를 Locally Managed 방식으로 전환
시키기 위해서는 DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL 프로시져를
사용하면 된다.
그리고, DBMS_SPACE_ADMIN 패키지는 Locally Managed Tablespace를
관리하는 데 필요한 각종 프로시저를 제공한다.

다음 문장에서, 데이터베이스 블럭 크기가 2K인 것을 가정하였다.

CREATE TABLESPACE tbs_1
DATAFILE 'file_tbs1.dbf' SIZE 10M
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 128K

위 문장을 수행시키면, Locally Managed Tablespace를 생성하며,
모든 extent의 크기를 128K로 할 때, 비트맵의 각 비트는 64개 블럭에 대한
정보를 나타낸다. 기본적으로, 데이터베이스 블럭의 크기의 기본값을 2K로
가정하였을 때, 각 비트는 하나의 extent(128K)에 대한 정보를 나타내므로,
각 비트맵은 64개의 오라클 블럭을 필요로 하게 된다.

( 64 블럭 = 128K UNIFORM SIZE / 2K ORACLE BLOCK SIZE )

4. Dictionary Managed Tablespace를 사용하는 것 대비, Locally Managed
Tablespace를 사용하였을 경우의 장점

1) Locally Managed Tablespace는 가용한 공간에 대한 정보를 데이터
딕셔너리에 저장하지 않으므로, 데이터 딕셔너리에 대한 경합을
줄이게 된다.

2) Extent에 대한 local management를 통해, 인접한 가용 공간의 정보를
자동으로 관리하게 되므로, 가용 extent에 대한 coalesce 작업을
수행하지 않아도 된다.

3) 공간 관리를 위한 데이터베이스 내부 처리 작업을 피할 수 있다. 반면
이와 같은 내부 처리 작업은 Dictionary Managed Tablespace에서는
필요한데, extent를 사용하거나, 반납을 하는 등의 작업이 발생할 때마다
rollback segment나 데이터 딕셔너리 테이블의 공간을 사용하거나
반납하는 등의 작업이 필요하게 된다.

4) Locally Managed Tablespace에서의 extent의 크기는, 시스템에 의해
자동적으로 관리된다. 반면, 모든 extent는 Locally Managed Tablespace
에서는 동일한 크기를 사용하게 할 수도 있다.

5) Extent에 대한 정보를 나타내는 비트맵의 변경 사항은 rollback 정보를
생성하지 않는다. 이것은, 데이터 딕셔너리의 정보를 변경하지 않기
때문이다. ( 테이블스페이스에 대한 quota 정보와 같은 일부 사항은
예외 )

6) Fragmentation을 줄일 수 있다.

Example

---

Reference Documents

---

<Note:93771.1> Locally Managed Tablespace in Oracle 8i
<Note:103020.1> Migration from Dictionary Managed to Locally Managed
Tablespaces
<Note:105120.1> Advantages of Using Locally Managed vs Dictionary Managed Tables
paces


http://kr.forums.oracle.com/forums/thread.jspa?threadID=477238&tstart=15 

lseek 를 이용한 파일 조작

출처 : http://cafe.daum.net/info0U/MBKS/19?docid=1F4gb|MBKS|19|20090512140641&q=lseek&srchid=CCB1F4gb|MBKS|19|20090512140641 

2.3.4절. 예제코드

다음은 실제 작동되는 예제 코드이다. 어려운 내용은 없음으로 주석으로 대신하도록 하겠다. 아래코드는 학습목적으로 연습삼아 만든 코드이다. 에러처리, 입출력검사, 코드 효율성, 인터페이스 등은 염두에 두지 않은 코드이다. 숨어있는 버그를 잡거나 깨끗하게 코드를 다시 만들어 보는것도 많은 도움이 될것이다.

예제 : seek_db.c

#include <sys/types.h> #include <unistd.h> #include <string.h> #include <sys/stat.h> #include <sys/types.h> #include <fcntl.h> #include <unistd.h> #include <stdio.h> // DB 포맷 확인용 #define APPNAME "MYDB" // ANSI 코드 // 스크린 지우기 #define SCR_CLEAR printf("^[[2J") // x,y 좌표로 커서이동하기 #define MOVE_CURSOR(x, y) printf("^[[%d;%dH", x, y) // 메시지를 출력하고 사용자 입력을 기다린다. // 스크린 지우기 전에 메시지를 확인할 목적으로 // 사용된다. #define WAIT_INPUT(x) printf("%s", x);getchar() // 개행문자 제거 #define chop(str) str[strlen(str)-1] = '\0'; // 헤더의 크기 정의 // 헤더는 recode 를 제외한 파일의 가장앞에 있는 // 정보이다. // DB 포맷 정보 크기 #define DBINFO_SIZE strlen(APPNAME) // R_NUM,INC_NUM 크기 #define INDEX_SIZE sizeof(int)*2 // 전체 헤더 크기 #define HEADER_SIZE INDEX_SIZE + DBINFO_SIZE // 메인메뉴 char *menu = " 데이타수 : %d ==================== 1. 리스트 보기 2. 리스트 추가 3. 리스트 삭제 4. 종료 ==================== input : "; // 레코드 입력 메뉴 char *input_menu = " 번 호 : 이 름 : 전화번호 : "; // 레코드 구조체 typedef struct _data { int num; // 일련번호 char name[16]; // 이름 char tel_num[16]; // 전화번호 } Data; // R_NUM, INC_NUM typedef struct _index_num { int datanum; // R_NUM : 데이타 총갯수 int incnum; // INC_NUM : 데이타 일련번호 } Index_num; // Index_num 값 즉 R_NUM 과 INC_NUM // 을 얻어온다. Index_num get_indexnum(int fd) { Index_num index_num; lseek(fd, DBINFO_SIZE, SEEK_SET); read(fd, (void *)&index_num, HEADER_SIZE); return index_num; } // DB 파일을 체크한다. // 파일의 처음 4바이트 문자가 APPNAME 과 같으면 참 int dbcheck(fd) { char dbname[8]; memset(dbname,0x00,8); read(fd, dbname, 8); if (strncmp(dbname, APPNAME, DBINFO_SIZE) ==0) return 1; else return -1; } // 최초에 DB파일이 생성되지 // 않았을때 DB 파일을 초기화 시켜준다. // DB 포멧정보(APPNAME)이 들어가고 R_NUM, INC_NUM // 은 0으로 초기화 된다. int init_datanum(int fd) { Index_num index_num; write(fd, APPNAME, DBINFO_SIZE); memset((void *)&index_num, 0x00, INDEX_SIZE); write(fd, (void *)&index_num, INDEX_SIZE); } // 레코드가 insert 되었을 경우 // R_NUM과 INC_NUM 을 증가시킨다. int inc_indexnum(int fd) { int datanum; Index_num index_num; index_num = get_indexnum(fd); index_num.datanum++; index_num.incnum++; lseek(fd, DBINFO_SIZE, SEEK_SET); write(fd, (void *)&index_num, INDEX_SIZE); return 1; } // 메인 메뉴를 출력한다. void print_main_menu(fd) { Index_num index_num; index_num = get_indexnum(fd); printf(menu,index_num.datanum); } // 서브메뉴를 출력한다. void print_menu(char *sub_menu) { printf(sub_menu); } // 레코드를 삽입한다. // 레코드 삽입위치는 파일의 마지막이다. void input_data(Data mydata, int fd) { // 파일의 마지막으로 이동 lseek(fd, 0, SEEK_END); write(fd, (void *)&mydata, sizeof(Data)); inc_indexnum(fd); } // 레코드 리스트를 출력한다. void print_data(int fd) { int i; int offset = 0; Data list; Index_num index_num; index_num = get_indexnum(fd); // 레코드의 시작위치로 이동한다. lseek(fd, HEADER_SIZE, SEEK_SET); for (i = 0; i < index_num.datanum; ) { read(fd, (void *)&list, sizeof(Data)); if (list.num > 0) { i++; printf("%3d %16s %16s\n", list.num, list.name, list.tel_num); } } } // 레코드를 삭제한다. // 실제로 데이타를 삭제하지는 않으며 // Data.num 에 (-1)을 곱해준다. int del_data(int fd,int num) { int offset; int del_flag; Data list; Index_num index_num; index_num = get_indexnum(fd); printf("delete num is %d\n", num); // 입력된 번호가 1 보다 작거나 레코드 수보다 클경우 if ((index_num.incnum-1) > index_num.incnum || num < 1) return -1; // 삭제하고자 하는 레코드의 위치로 이동한다. offset = (sizeof(Data)*(num-1)) + HEADER_SIZE; lseek(fd, offset, SEEK_SET); read(fd, (void *)&list, sizeof(Data)); if (list.num < 0) { printf("list.num is : %d\n", list.num); return -2; } del_flag = list.num*(-1); // 삭제하고자 하는 레코드의 위치로 이동해서 // list.num*(-1) 값을 입력한다. lseek(fd, offset, SEEK_SET); write(fd, (void *)&(del_flag), sizeof(int)); // R_NUM 을 1 감소시킨다. lseek(fd, DBINFO_SIZE, SEEK_SET); index_num.datanum--; write(fd, (void *)&(index_num), INDEX_SIZE); return 1; } // 메뉴선택에 대한 처리 void sel_menu(fd) { char menu_num; Index_num index_num; // R_NUM과 INC_NUM 을 구해온다. index_num = get_indexnum(fd); while(1) { Data mydata; char buf[11]; char num[11]; int state; char data[16]; SCR_CLEAR; // 화면 clear MOVE_CURSOR(1,1); // 커서이동 print_main_menu(fd); // Main 메뉴출력 fgets(num, 11, stdin); // 입력번호에 따라 분기한다. switch(atoi(num)) { // 리스트 출력 case 1 : print_data(fd); WAIT_INPUT("Press any key!!"); break; // 입력 case 2 : SCR_CLEAR; MOVE_CURSOR(1,1); print_menu(input_menu); MOVE_CURSOR(2,12); printf("%d", ++index_num.incnum); mydata.num = index_num.incnum; MOVE_CURSOR(3,12); fgets(mydata.name, 16, stdin); chop(mydata.name); MOVE_CURSOR(4,12); fgets(mydata.tel_num, 16, stdin); chop(mydata.tel_num); input_data(mydata, fd); WAIT_INPUT("Press any key!!"); break; // 삭제 case 3 : MOVE_CURSOR(10,1); printf("삭제번호 "); fgets(buf, 11, stdin); state = del_data(fd, atoi(buf)); if (state < 0) { printf("잘못된번호 선택\n"); } WAIT_INPUT("Press any key!!"); break; case 4 : printf("bye bye\n"); exit(0); default : break; } } } int main(int argc, char **argv) { int data_num = 0; int is_fileok = 0; int fd; Data mydata; if (argc != 2) { printf("Usage : ./seek_db dbfile\n"); exit(0); } if ((access(argv[1], F_OK) == 0)) { is_fileok = 1; } fd = open(argv[1], O_CREAT|O_RDWR, S_IRUSR|S_IWUSR); if (fd < 0) { perror("error : "); exit(0); } if (is_fileok == 0) { printf("FILE INIT\n"); init_datanum(fd); } else { if (dbcheck(fd) != 1) { fprintf(stderr, "%s 는 잘못된 DB 파일입니다\n", argv[1]); exit(0); } } sel_menu(fd); close(fd); return 1; }

DBMS는 소프트웨어의 기본, OS부터 충실히 공부해야

http://www.ittoday.co.kr/home/post/post_view.jsp?dseq_no=7943&menuId=ABAA&cateCode=ABAA&pageCode=7943&curPage=&serType=&serText=

[멘토를 찾아서](1)김기완 알티베이스 대표

"DBMS는 소프트웨어의 기본, OS부터 충실히 공부해야"

“데이터베이스관리시스템(DBMS)는 모든 소프트웨어의 기본입니다.”

김기완 알티베이스 대표의 DBMS 사랑은 남다르다. 20여년을 DB분야에서만 있었으니 최고의 DB전문가라고 할 수 있을 것이다. 특히 국산 DBMS를 직접 개발하는 회사까지 차렸으니 DB분야에서 DBA부터 개발, 컨설팅, 영업 등 할 수 있는 역할은 다 해봤으리라.

‘멘토를 찾아서’라는 기획을 위해 시간을 내달라고 했을 때 김 대표는 흔쾌히 허락했다. DBMS 분야에 뛰어들기 위해 몇 년간 준비하고 있다는 말에 업계 선배로서 바쁜 와중에도 시간을 내준 것. DB를 공부하려는 후배들을 위해 인터뷰를 허락하는 것은 당연하다고 했다.

김 대표의 첫 인상은 푸근했다. 오라클에 맞서 10여년을 버텨 온 알티베이스 수장으로서의 강한 카리스마 대신 학교에서 볼 수 있는 선배의 모습이었다. 안경너머로 보이는 눈빛이 진지함과 호기심으로 가득 차 있는 듯했다. 벤처 CEO다운 도전 정신이 어디에서 나왔을까 하는 생각이 들 정도였다.

김 대표는 "DBMS 분야로 진출하고 싶은 학생들이나 초보 개발자에게 꼭 필요한 것은 운용체계(OS)에 대한 공부"라고 조언했다. 운용체계를 배우면 DBMS에 대한 기본지식을 쌓을 수 있다는 것이다. 그는 이어 "컴파일러, 자료구조, 파일처리 3가지를 배우면 DBMS를 알기가 쉽다"고 설명했다.

김 대표는 DBMS 분야로 취업을 희망하는 학생들에 대한 조언으로 학생으로서 기본에 충실하고 개발 능력을 키우는 것이 중요하다고 했다. DBMS가 네트워크, 운용체계, 자료구조 등 모든 컴퓨터 시스템과 관련돼 있으니 그에 대한 전반적인 지식을 쌓는 것도 필요하다고 했다.

그는 무엇보다 창의성을 갖추는 것도 중요하다고 강조했다. 풀어가는 과정이 다 다를 수 있는데, 오히려 다른 방식으로 문제를 풀어가는 것을 보면 직원으로 채용하고 싶을 정도로 매력을 느낀다고 말했다.

알티베이스의 개발자 채용 방식은 독특하다. 출신학교 등의 선입관을 배제하고 면접을 보는 과정에서 문제를 내고, 직접 칠판에 나와 풀게 하는 방식으로 진행된다. 정확한 답도 중요하겠지만 그 답을 찾아내는 과정도 중요시한다. 기본기와 창의성을 강조하는 대목이다.

김 대표는 경쟁을 즐기고 있는 것 같았다. 한국오라클이라는 탄탄대로의 직장을 과감히 그만두고 누구나 반대했던 국산 DBMS개발 회사 창업을 할 때도 그랬단다. 또한 매년 적절한 계획 속에 투자를 하면서 시장을 공략했을 때도 그랬다.

무엇보다 그는 최근 국산 DBMS가 많이 나오는 것에 대해서도 적극적으로 찬성했다. 경쟁이란 것이 필수적으로 필요하다는 논리 때문이다. 삼성이 해외에서 1위를 휩쓰는 배경에는 LG전자와의 경쟁이 크게 한 몫 했다는 얘기다. 그는 티맥스소프트, 큐브리드 등 국산 DBMS가 많이 생기는 것에 대해서는 적극 찬성하고 같이 시장을 키워야 한다고 하면서도 오히려 일회성으로 그쳐서는 안 된다는 점을 강조했다. 모두 기본에 충실해 고객에게 기쁨을 줄 때만이 지속적으로 생존가능성이 있다는 것이다.

대학생과 예비개발자, 초보 개발자에게 그는 ‘기본을 갖추라’고 강조했다. 스스로도 대학 시절 공부를 많이 하지 못해 대학원까지 가서 공부했다면서, 지금 현재 있는 상황에서 최선을 다해 기본기를 갖추기 위해 노력을 해야 한다고 말했다.

다음은 김기완 대표와의 일문일답.

- DBMS로 오라클 등 글로벌 기업과 경쟁하기 힘든 데, 과감하게 창업을 하게 된 동기는?

"주위의 많은 반대에도 불구하고 창업을 하게 된 이유는 창업에 대해 성공하리라는 자신감과 재미가 있었기 때문이다. 게다가 한국오라클에서 7여년간 일하면서 많은 기술을 알고 있었기 때문에 더욱 확신이 있었다. 국산 DBMS의 활성화, 한국 오라클의 아성을 넘어보는 것이 앞으로의 목표다."

- 알티베이스에 대해 자랑한다면?

"소프트웨어에 대해 배우고자 하는 학생, 개발자라면 우리 회사가 적격이다. DB와 관련한 많은 레퍼런스 소스(reference source)가 있어 어려움을 겪을 때 참고 할 수 있고, 중소기업이기 때문에 다양한 경험을 쌓을 수 있다. 그러나 외국회사에서 와서 벤치마킹 할 정도로 회사 업무들이 체계화 돼있고 프로세스가 잘 정립돼 있기 때문에 DB 를 배우려 하는 학생 뿐 아니라 소프트웨어 업무에 관심이 있는 학생들 모두에게 많은 이득이 될 것이다. 소프트웨어를 체계적으로 배울 수 있는 곳이 알티베이스라고 자신한다."

- 해외 진출 계획은?

"현재 활발하게 해외 진출을 준비 중이다. 일단, 일본과 중국에 진출할 생각인데 우리나라에서 검증된 제품으로 천천히, 꾸준히 도약할 생각이다. 현재 알티베이스의 DBMS 버전이 5인데, 많은 기업에서 쓰고 있는 안정화된 버전인 알티 4 로 런칭할 것이다."

- 티맥스소프트와 큐브리드 역시 DBMS를 만드는 기업이다. 한국 최초의 국내 DBMS를 만든 기업으로써 이들과의 경쟁에 대해 어떻게 생각하는가?

"경쟁이란 것은 필수적으로 필요한 것이다. 삼성의 제품들이 해외에서 1위를 휩쓰는 이유가 무언지 아는가? 바로 LG가 있었기 때문이다. 서로 경쟁하면서 지금의 삼성을 만든 것이다. 알티베이스 역시 이들과 선의의 경쟁을 통해 글로벌 업체가 될 것이다."

- 알티베이스, 티맥스소프트, 큐브리드 등 국산 DBMS의 바람이 거세다. 최근에는 공공기관에도 외국의 DBMS를 제치고 수주권을 따냈는데, 이러한 국산 DBMS의 선전을 어떻게 생각하는가.

"바람직한 현상이다. 그러나 일시적인 현상으로 그치면 절대 안된다. 꾸준하게 점진적으로 발전해야 하며, 시장 규모도 키워야 한다. 고객과의 관계에서 가장 중요한 신뢰를 잘 유지하는 것이 도움이 될 것이다."

- 대학을 졸업하고 나서 가장 힘들었던 시기는?

"첫 직장이었던 삼성종합기술원에서 근무했었을 때다. 삼성종합기술원은 당시 IT사관학교로 불릴 정도로 교육을 잘 시키는 곳으로 유명했다. 슈퍼 컴퓨터관련 업무를 했었던 그곳은 너무 체계적이고 권위를 강조하던 곳이었다. 개인적으로는 그 문화에 적응하기가 가장 힘들었다. 그래서 1년 반을 지내고 나서 한국오라클로 옮겼다. 그러나 많은 것을 배울 수 있어 좋은 기회였던 것은 분명한 사실이다."

-한국 오라클에서 어떤 일을 했으며 자신에게 도움이 많이 되었나?

"1993년에 오라클에 입사를 했는데, 그때는 한국 오라클이 설립 초창기였을 때였다. 그래서 사원수가 적어 혼자서 다양한 분야의 일을 하게 되었는데, 그렇게 해서 많은 업무를 배울 수 있었다. 그때 수 십명에서 시작한 오라클이 8년 뒤 퇴사 할 때는 사원수가 800여명으로 늘어나 있었다."

- 그렇다면, 현재 취업을 앞둔 대학생들에게도 한국오라클이 매력적인가?

"시각에 따라 다르게 볼 수가 있다. 이전과 비교할 때 적어도 현재의 한국오라클은 성장 속도가 많이 둔화됐다. 업무도 체계적으로 시스템화돼 있기 때문에 한 분야만 배울 수 있지 전체 흐름을 배우기는 어려운 구조다. 그래서 많은 것을 배워야 하는 신입에게 추천하고 싶지는 않다. 물론 개발이라는 측면을 강조한 얘기다."

- 선배들의 말을 들어보면, 한국에 있는 외국계 기업들은 대부분의 업무가 세일즈나, 고객응대 파트라고 하는데, 사실인가?

"회사는 장사를 하는 곳이므로, 그것은 당연한 것이다. 게다가 본사는 미국에 있으므로 다른 나라에는 그 나라를 지원해줄 정도면 된다. 물론 한국오라클에도 엔지니어가 있긴 하지만 깊이 있는 지식을 갖기는 힘들 것이다. 그런 측면에서 보면 국내 기업들이 강점이 많다. 소스코드도 직접 볼 수 있고 개발을 하면서 많은 것을 배울 수가 있다."

        김 대표와 양지웅 대학생 명예기자가 기념촬영 하고 있다.

-요즘은 높은 실업난과 더불어 많은 대학생들이 대학원을 생각한다. 공대생이 대학원에 가서 더 공부를 하는 것에 대해 어떻게 생각하나?

"대학원, 좋다. 대학원에서는 대학에서 배우지 못한 것을 배울 수 있다. 체계적인 업무, 각종 문서와 논문을 쓰면서 어떻게 써야 논리적으로 글을 쓸 수 있는가에 대해서도 익힐 수 있다. 게다가 학업기간도 경력으로 쳐주니 공부를 더 하고 싶은 학생이라면 추천한다."

- 알티베이스는 현재 성균관대와 연계해 DBMS 임베디드 석사 과정을 만들어 진행하고 있는데.

"인재를 발굴하기 위해 성대와 협약을 맺어 하는 프로그램으로, 우리 회사에서 석사 과정의 비용을 지원해주고 졸업 후 입사하는 제도다. 자격은 DB분야를 모른다 하더라도 DB관련 업무를 꼭 하고 싶은 사람, 재미있어 하는 사람이면 좋다. 필기 시험을 보기 때문에 개발에 대한 지식이 있으면 더욱 가능성이 높아진다. 현재 시행한지 1년 정도 지났는데, 학기 중에는 공부를 하고, 주마다 한 번씩의 기술 세미나와 방학 중에 인턴을 하게 된다. 현재 학생 수는 10명으로 모두 열정과 열기가 대단하다."

- DB컨설턴트가 되고 싶은 학생에게 조언 한다면?

"컨설팅은 다른 회사에 가서 자기의 생각을 파는 일종의 ‘장사’ 이므로 말의 표현력과 재치가 가장 중요하다. 한 분야가 아닌 많은 분야에 대한 해박한 지식을 가지고 있어야 함은 물론이다."

-DB 분야로 인생의 진로를 정하고 싶은 대학생들이나 초보 개발자들이 무엇을 더 배우면 좋을까?

"뭐니뭐니 해도 운용체계(OS)에 대한 공부가 필수다. DBMS는 DB에 대한 운용체계라 할 수 있다. 그 운용체계 또한 윈도 같은 운용체계와 같이 내부적으로 구성돼 있으므로, 운용체계를 배우면 DBMS에 대한 기본 지식을 쌓을 수 있다. 또한, 컴파일러와 자료구조, 파일처리를 배워두면 좋다. 그 위에 실무 능력을 겸비해야 진정한 실력자라 할 수 있다."

- DB 관련 분야 취업을 희망하는 학생이나 초보 개발자에게 한마디 조언 한다면.

"일단은, 그것을 정말로 좋아해야 한다고 생각한다. 아무리 회사가 좋아도 자신이 좋아하는 일이 아니라면, 회사나 자신에게나 독이 된다. 학생의 신분으로서 기본에 충실해야 하고 개발 능력을 키우는 것도 필요하다. 프로그램 코드가 1000라인에서 10000라인으로 늘어난다면 그것은 단순하게 라인 수만 증가하는 것이 아님을 명심해야 한다. 더불어, DB라는 것이 네트워크, OS, 자료구조 등 모든 컴퓨터 시스템과 관련돼 있으니 그에 대한 전반적인 지식도 쌓으면 더욱 좋겠다."

<양지웅 대학생 명예기자 jiwoong.com@gmail.com >

’멘토를 찾아서’ 기획시리즈는 대학생 명예기자 혹은 온라인 기자가 IT업계의 뛰어난 멘토들을 직접 방문해 소개하는 코너로 개발자 포털 데브멘토(www.devmento.co.kr)와 아이티투데이가 공동기획해 연재합니다.

이기는기업 _ 알티베이스 편

CJ 그룹에서 제작한 사내방송  

외산 DBMS 불만은 ‘높은 유지보수비’

http://www.itdaily.kr/news/articleView.html?idxno=19499  외산 DBMS 불만은 ‘높은 유지보수비’

국산 DBMS 성능 및 지원에 대체적으로 만족

2009년 05월 26일 (화) 22:35:06 김소연 기자soy@itdaily.kr

현재 국내에서 DBMS를 사용 중인 기업의 대부분은 오라클 등 외산 DBMS이다. 이들 외산을 사용하고 있는 고객들은 안정성과 대용량 데이터 처리 능력 등에 대체적으로 만족하고 있는 것으로 조사됐다. 하지만 국산 DBMS에 비해 높은 유지보수액과 서비스 등에는 강한 불만을 갖고 있는 것으로 나타났다. 컴퓨터월드는 최근 공공, 금융, 병원, 대학 등의 산업별 IT 담당자들을 대상으로 ‘DBMS 만족도’를 설문조사한 결과 이 같이 드러났다. 오라클이 89% 점유 설문조사에 답한 기업들이 현재 운영 중인 DBMS 브랜드는 오라클(89%), 마이크로소프트(25%), 사이베이스(16%), 알티베이스(12%), IBM(8%) 순으로 나타났다. 설문에 답한 기업의 79% 이상이 3년 전에 DBMS를 도입했다고 답했으며, 1년 이내와 2년~3년 이내에 도입했다고 밝힌 기업은 각각 10%와 11%였다. 오라클 DBMS를 도입해 사용 중이라는 한 기업의 담당자는 "여러 분야에서 다양하게 사용하는 DBMS라 안정성이 보장되었다는 생각으로 오라클 DBMS를 도입하게 되었다"고 말했다. 오라클 DBMS가 국내 시장에서 보편화되어 비교적 안정된 시스템으로 인식되고 있다는 게 그의 설명이다. DBMS를 도입해 사용 중인 기업의 대부분은 구축 시스템의 특성에 따라 기술지원, 제품의 안정성, 경제성 등을 복합적으로 검토해 DBMS를 중복 도입해 사용 중인 것으로 나타났다. 그 예로 한 공공기관은 주요 업무 추진에는 오라클 DBMS를, BPM 시스템 구축에는 마이크로소프트 DBMS를 도입해 사용 중이라고 밝혔다. 이 관계자는 "업무에 맞는 DBMS를 구축해 처리의 안정성이 높아 만족하며 사용하고 있다"고 말했다. 한 공공기관 역시 오라클 DBMS는 기간계 시스템에 활용 중이며 시스템 부하가 적은 사이베이스 DBMS는 서비스용 시스템에, 상대적으로 비용이 적게 드는 마이크로소프트 DBMS는 단순 업무 활용에, 알티베이스 DBMS는 메모리 DBMS로 사용하고 있는 것으로 조사됐다. 58%가 DBMS 사용에 만족 설문에 답한 기업의 57.89% 이상이 현재 사용 중인 DBMS에 만족하고 있고, 이어 매우 만족은 11%, 보통은 26%, 불만족스럽다는 5%로 각각 조사됐다. 만족의 이유로는 사용하는데 큰 문제가 없다는 점, 특별한 장애와 제약사항이 없어 업무 처리에 안정적이라는 것이다. 두 종류의 외산 DBMS를 도입해 사용 중이라는 금융권의 한 관계자는 "시장에서 보편적으로 사용하고 있는 DBMS라 애플리케이션이나 여러 솔루션에 대한 호환성이 좋으며 운영에 필요한 정보 공유가 용이하다"며 "특히 유닉스 시스템에서의 뛰어난 안정성을 보장해 주며 대용량 데이터 처리 능력이 강력하다"고 밝혔다. 제품의 기능에 대한 만족도를 묻는 질문에는 74% 이상이 만족하고 있고, 16%는 보통, 10%는 매우 만족한다고 답변했다. 오라클 DBMS를 도입해 사용 중인 한 대학의 관계자는 "오라클 DBMS는 타 제품이 가지지 않는 기능들을 포함하고 있어 전반적으로 만족하고 있다"며 "특히 다양한 함수 기능이 지원되고 사용하기가 용이하다는 것이 만족스럽다"고 말했다. 하지만 그는 "운영 중인 데이터의 규모에 따라 대용량 성능이 반드시 필요하다고는 볼 수 없다"고 말했다. 역시 오라클 DBMS를 사용하고 있다는 한 공공기관의 관계자는 전반적인 만족도가 불만족스럽다고 답변했다. 그 이유를 묻는 질문에 "범용성 및 많은 개발자, 안정적인 성능 보장은 대체로 만족스럽다고 할 수 있지만 버그 및 오류에 대한 지원 및 패치 신뢰도가 낮기 때문이다"고 밝혔다. 반면, 국산 DBMS 제품인 알티베이스 DBMS를 도입해 사용 중인 한 대학의 담당자는 "수강 신청에 대비해 고효율 메모리 DBMS를 도입하고자 했다"며 "국내 통신 시장 등에서 다수의 사이트를 확보하며 안정성이 입증된 알티베이스 DBMS를 도입하게 되었다"고 밝혔다. 덧붙여 그는 "외산 DBMS에 뒤지지 않는 제품의 기능과 성능에 대해 대체로 만족하고 있으며 특히 빠른 처리 속도와 신속하고 친절한 유지보수가 만족스럽다"고 말했다. 성능에 대한 만족도에 대한 질문에는 만족(58%), 보통(26%), 매우 만족(16%) 순으로 나타나 응답자의 대부분이 사용 중인 DBMS의 기능과 성능에 만족하고 있는 것으로 나타났다. 알티베이스 DBMS를 도입해 사용 중인 한 기업의 담당자는 "호환성이 미흡하긴 하지만 빠른 유지보수 대응으로 신속한 처리가 가능하다"며 "특히 대용량 DBMS 사용에도 손색이 없어 국산 DBMS도 성능이 크게 향상됐다"고 밝혔다. 덧붙여 그는 "다양한 제품과의 호환성 완성이 시급한 과제라 할 수 있다"고 말했다. <상세 내용은 컴퓨터월드 6월 호 참조>

DATABASE BOOK 간단리뷰

밥먹기 전에 ... 가지고 있는 DB 책 에 대해서 평을 해본다 .. ㅡㅡ;;

순서는 난이도

1. An Introduction to DATABASE SYSTEMS (C.J.DATE)
- 말할것도 없이 그 유명하신 수학자 DATE 의 책이다. DATE가 수학자여서 그런지 충실히 개념 위주의 설명으로 되어 있으며, 대학 학부 책으로도 꽤 쓰인다. ( 개인적으로 이책이 학부 DB책에는 적합하지 않다고 생각함 )
내용이 다소 주관적이고 증명하기 위해 말이 다소 어렵지만 처음 DB를 접하는 사람들에게 개념을 빡시게(?) 심어주는 좋은책 이라고 할수 있다..( 다만 해석본은 해석이 난해 하다 ..) - (인하대 학부 DB책)

2. DATABASE Principles, Programming, and Performance  (Patrick O’neil / Elizabeth O’neil)
- 외대에서 쓰는 학부DB 책이다. 개인적으로 잘 되어 있는 책이라고 본다. 난이도는 KORTH 책보다는 조금 낮은정도? 개념과 원리를 적절하게 설명한 책이라고 볼수 있겠다.

3. DATABASE SYSTEMS (KORTH) 
- 이것 또한 유명하신 KORTH 가 지은 책이다. 이책의 난이도는 DATE 책 보다 높다. 개념과 원리 를 적절히
  섞어 가면서 기술하였기때문에 DBMS 접근도 일부 들어 있다. DB의 개념을 알고 있다면 이책을 보는것도  
  좋을 거라고 본다. 하지만 난이도 탓인지 챕터마다 자세한 설명은 나와 있지 않다.

4. DATABASE Management Systems (Raghu Ramakrishnan)
- 책이름에서도 나와 있듯이 DBMS 접근방법의 책이라고 볼수 있다. 그래서 위에 책보다 난이도가 꽤 높다.
인덱스나 트리 조인 파일구조 개념및 원리가 꽤 자세하게 기술되어 있다. 난이도가 있기때문에 선행 학습이 필요한 책이라고 볼수 있겠다. ( 성대에서 수업하는 학부 DB책이기도 하다. 학부 DB책으로써는 상당한 난이도를 자랑한다. ;;)

5. DATABASE SYSTEMS THE COMPLETE BOOK (Ullman)
- 유명하신 울만 이 지은 DBMS 책이다. 난이도는 가지고 있는 DB책중에 가장 높다. 철저히 DBMS 구현 중심의 이론들로만 쓰여진 책이다. 이것또한 개념없이 보았다가는 KO 당할수 있다.

오라클 책

1. BOP ( beginning oracle programming )
- 오라클 가장 기본서인 빨갱이 책이다. 내용은 다소 쉽지만 어려운 부분도 일부 존재한다.
오라클에 기초적인 부분들을 두루 설명하고 있으므로 초보자라면 한번 볼만한 책이다. ( 근데 두껍다 ;;)

2. expert one-on-one Oracle 
- BOP를 다 보았다면 이책을 보는것을 권장한다. 비슷한 개념이지만 BOP 보다는 상세하게 오라클 아키텍쳐를 다루고 있다. 개념과 실습 위주의 책으로써 다소 아키텍쳐 부분이 미약한것은 단점이다. ( BOP 보다 더 두껍다 ;;)

3. Expert Oracle Database Architecture 
- 오라클 아키텍쳐에 근거하여 기술한책이다. 오라클 아키텍쳐에 대해서 자세히 알고 있으면 이책은 꼭 봐야 할거 같다. 하지만 기본지식이 없다면 매우 어려울수도 있다.

4. Cost Based oracle fundamentals 
- 난이도 최상이다. CBO 에 대해서 다루고 있으며, QP 하는 사람이라면 꼭 봐야 할 책중 하나다. 개념 숙지 안하고 봤다간 좌절감에 그날 공부는 끝이다 ...

5. ORACLE 공식 교재
- 내용면에서는 이 공식교재를 따라갈 책은 없다. 그만큼 오라클에서 직접 만들었기때문에 매우 좋은 책이다.
하지만 교재값이 엄청비싸고(OCP 취득시에 책값 30~40만원 물론 어둠의 경로가 ..;;) 양이 매우 많다는거..?
이것만 다 숙지해도 오라클의 전체적인 흐름은 알고 있다고 말할수 있다.


등등 잡다한 DB 책은 많지만 .. 저 것들만 다 봐도 2년 농사 성공이다 ..ㅡㅡ;;



 

recursive relationship

DATE 가 쓴 DATABASE SYSTEMS 책의 ERD 이다..

매주 알티베이스 가서 세미나를 하기 때문에 부랴부랴 하고는 있는데 ...

누구나 다 아는 recurisive relationship 에서 EXP IMP 를 도저히 모르던중에 의미를 찾았다 ..

자료구조 수준의 Opeation

• explosion : 
  explosion은 입력으로 부품번호가 들어가서 출력으로 조립에 필요한 하위부품 정보가 나오는 Operation이며, 이를 재귀적으로 적용하면 Indented BOM을 구성한다
• implosion : 
  Implosion은 부품번호를 입력하면 이 부품으로 조립되는 모든 조립부품을 출력해 준다. 이는 Reorder를 내는데 사용된다. 보통 Implosion은 1 level 상위를 대상으로 한다.

EXP를 따라가면 이 부품을 만들기 위해 필요한 부품의 정보가 나오고

IMP를 따라가면 이 부품으로 조립되는 부품의 모든 정보가 나온다?? ;;;

. 주요 질의

Indented Bill은 부품의 전체 Tree 구조를 알수 있게 해준다. 이때 Tabel에서 정의한 leve을 보면 부품의 포함관계를 알 수 있다. Copy Bill은 전체 Tree 구조중의 부분 Tree를 Copy 하는 질의이다. 이 질의는 새로운 부품에 대한 BOM을 작성할 때 기존의 부붐을 많이 공유하므로 Copy 한 것의 일부분만 수정하여 새로운 BOM을 구성하면 되므로 매우 유효하다.

Relational db의 SQL을 이용할 경우 다음과 같은 기본 질의를 지원할 수 있다.

1 level explosion 과 implosion

explosion:
SELECT *
  	FROM STRUCTURE
	WHERE Parent-Part = "A";

implosion:
SELECT *
	FROM STRUCTURE
	WHERE Component="C"

부품 이름등 부가적인 정보를 알고 싶을경우 Part-Master Tabel과 Join을 하여 결과를 보여준다. 말단의 부품까지 모든 Tree 구조를 보여주기 위해서는 다음과 같은 View와 Recusive Join을 하는 질의를 작성해야 한다. 이러한 Recursive join은 데이타베이스에 성능저하에 많은 영향을 주며 질의 자체가 항시 다시 Compile되기 때문에 관계형 데이타베이스를 기초한 BOM 프로세스 작성은 적합하지 않다.

CREATE VIEW BILL
	AS SELECT one.*, two.Component, two.Quantity-per
	FROM Structure one, Structure two
	WHERE one.Component = two.Parent       /*  1 level 이상 경우 처리 */
	OR	one.Componet NOT NULL;         /* 1 level  경우 처리 */

SELECT *
	FROM BILL
	WHERE Parent="A"

위의 결과를 실제 MS Access 7.0으로 구현한결과가 다음과 같다.

Structure

ID	parent	component	description
1	A	D
2	A	E
3	B	F
4	B	G
5	C	H
6	C	I
7	H	J
8	I	K

위의 Record 에 대하여 아래와 같은 질의가 가능하며 그결과는 다음의 표와 같다. (잘못된 Query : C-H-J관계가 나타나야 함)

SELECT a.parent, a.compont, a.description
FROM structure AS a, structure AS b
WHERE a.component=b.parent or a.component is Not Null
GROUP BY a.parent, a.compont, a.description;

Multi level query

parent	component	description
A	D
A	E
B	F
B	G
C	H
C	I
H	J
I	K

http://engdb.tripod.com/kedb/kms/knowledge/19971113.htm

티맥스와 알티베이스, 같은 목표 다른 전략

http://www.ddaily.co.kr/news/news_view.php?uid=49849

오라클 기술 따라하기 VS 오라클 기술 빗겨가기

2009년 05월 13일 14:15:40 / 심재석 기자 sjs@ddaily.co.kr

국내를 대표하는 데이터베이스관리시스템(DBMS) 업체인 티맥스소프트와 알티베이스가 같은 DBMS 시장을 놓고, 색다른 전략을 펼치고 있어 주목된다.

이 시장의 절대강자인 오라클을 따라 잡는다는 목표는 같지만, 기술 개발 면에서 다른 행보를 보이고 있는 것이다.

티맥스가 ‘오라클 기술 따라잡기’에 주력하고 있다면, 알티베이스는 ‘오라클이 관심 없는 기술 개발’을 주요 전략으로 삼고 있다.

단적인 예로 티맥스소프트는 지난 해 11월 오라클의 리얼 액티브 클러스터(RAC)과 유사한 ‘티맥스 액티브 클러스터’ 기술을 선보였다. 

RAC는 공유 DB 클러스터 기술로, 오라클이 DBMS 시장을 장악할 수 있었던 주요 무기였다. 특히 국내 고객들은 RAC 기술에 대한 수요가 많았다.

티맥스는 오라클 RAC에 대한 고객의 니즈에 대응하기 위해 RAC와 거의 유사한 TAC를 개발했다. 비슷한 기술을 기반으로, ‘근접 서비스, 저렴한 가격’이라는 국산 SW라는 장점을 이용해 오라클을 따라잡겠다는 전략이다.

반면 알티베이스는 오라클이 가지 않는 길을 가는 전략을 택했다. 오는 7월 선보일 예정인 ‘알티베이스 데이터 스트림(ADS)’가 대표적이다. 알티베이스는 오라클이 관계형DBMS에 집중하고 있는 것과는 반대로 스트림 DBMS라는 새로운 개념의 DBMS를 개발했다.

같은 기술로 세계 최고의 SW기업과 경쟁하는 것은 무리라는 판단 아래, 대신 고객의 니즈를 창출해 나가는 ‘블루오션’을 만들어 가겠다는 것이다.

알티베이스가 10년 전 오라클, IBM, MS와 맞서 국산DMBS로 시장에 안착할 수 있었던 것도 메인메모리DBMS라는 새로운 시장을 공략했기 때문이다.

알티베이스 김기완 사장은 “오라클 기술의 뒤만 좇아가면 평생 2등을 넘어설 수 없다. 오라클이 시도하지 않는 새로운 기술이 있어야 시장을 선도할 수 있다”고 말했다.

한국을 대표하는 두 DBMS 업체의 각기 다른 전략이 어떤 결과를 가져올 지 이들의 5년 후의 모습에 귀추가 주목된다.

<심재석 기자> sjs@ddaily.co.kr

--------------------------------------------------------------

오라클 기능을 따라하면 가격 경쟁력이 생겨 그만큼 어느정도 수요도 늘겠지만 그 이상의 의미가 있을지는 의문이고 ...

새로운 기술을 개발하는것은 그 기술이 안정화 및 검증이 되기까지의 시간과 

새로운 기술에 대한 불안한 요소가 존재하지만 .. 잘되면 대박이겠고 ...

국내 업체 끼리 싸우는 치킨게임이 되는것이 아닌 외산 업체와의 경쟁력 확보라는 점에서는 긍정적으로 본다. 

어느 정책이 유리한지는 현재로서는 중립적이라고 생각함... 

알티베이스 “이젠 오라클이 우릴 쫓아올 것”

http://www.datanet.co.kr/news/news_view.asp?id=45172&acate1=0&acate2=5

알티베이스 “이젠 오라클이 우릴 쫓아올 것”
데이터 관리 뉴패러다임은 ‘통합·스트리밍’
2009-05-12/오전 11:09:43/김선애 기자
 
 
 
“데이터 통합과 스트리밍은 데이터 관리의 새로운 패러다임이다. 이를 바탕으로 오라클이 우리를 쫓아오도록 만들겠다.”

김기완 알티베이스 대표는 11일 신제품 발표 기자간담회에서 이같이 말하고 “이번에 발표하는 신제품은 그 어떤 경쟁사도 내놓지 못한 새로운 개념의 솔루션”이라며 “향후 10년 동안 알티베이스가 지향하는 바를 분명히 보여주는 것”이라고 자신했다.

알티베이스, ‘실시간 전사 데이터 관리 솔루션’ 업체로 진화
알티베이스가 이날 발표한 제품은 ‘알티베이스 데이터 인테그레이터(ALTIBASE Data Integrator 이하 ADI)’와 ‘알티베이스 데이터 스트림(ALTIBASE Data Stream 이하 ADS)’이다.

알티베이스는 이 솔루션을 통해  ‘실시간 전사 데이터 관리 솔루션’ 업체로 진화할 것이라고 장담하고 있으며, 데이터가 생성되는 시점에 가공·이용할 수 있는 혁신적인 개념이라고 소개한다.

ADI는 실시간으로 데이터를 얻기 위해 저장된 모든 데이터를 불러들이는 전통적인 방법과 달리 로그에서 데이터의 변경된 내용만을 가져올 수 있어 IT 리소스 사용을 최소화하면서 사용자가 빠른 시간에 원하는 데이터를 불러들일 수 있다.

로그기반 데이터 분석 기법인 CDC(Changed Data Capture) 기술이 적용된 ADI는 이기종 DBMS간 실시간 데이터 복제가 가능하며, 다양한 데이터 베이스와 신규 구축 시스템의 통합 및 연동이 가능하다.

로그를 분석해 변경된 데이터만 불러오기 때문에 CPU 사용률이 2~4%에 불과해 운영 시스템의 성능영향을 최소화할 수 있다. 다양한 OS와 DBMS를 지원하기 때문에 시스템 구조의 변경이 없고, IT 인프라를 추가로 구입할 필요가 없다.

제품개발을 담당한 김성진 데이터스트림연구실장은 “CDC를 사용화해 제품을 만든 곳은 전 세계적으로 미국의 벤처회사 2곳 뿐이며, 이곳은 오라클 데이터베이스의 로그분석을 한다”며 “알티베이스는 데이터베이스를 개발한 기업인 만큼 데이터베이스의 특성을 잘 알기 때문에 CDC 기반의 데이터 통합 솔루션에서 큰 영향력을 발휘할 수 있을 것으로 기대한다”고 말했다.

ADS, 실시간 데이터 저장하고 불러오는 번거로운 작업 탈피
올해 하반기 출시 예정인 ADS는 알티베이스가 ‘데이터 관리의 새로운 혁명’이라고 자부하는 신기술이다.

ADS의 핵심은 분산환경에서 실시간 데이터 전송을 할 수 있는 네트워크 기반기술 ‘DDS(Data Distribution Service)’이며, 이 기술을 기반으로 상용화된 제품을 제공하는 곳은 알티베이스가 최초라고 강조한다.

DDS는 UDP 기반의 데이터 전송기술을 사용해 데이터 유·손실이 없으며, 빠른 속도로 전송이 가능하다. 노드에 데이터를 나누어 처리하기 때문에 데이터를 위한 별도의 서버나 탐색 솔루션이 필요하지 않다. 애플리케이션이 네트워크에서 데이터 흐름으로 관리하고 우선순위를 부여하며, 방향결정이 가능해 실시간 전송되는 데이터에서도 QoS가 보장된다.

DDS는 대규모 네트워크나 멀티캐스트 환경, 데이터 전송 속도가 생명인 금융·통신·국방 등의 분야, 연속적으로 데이터가 변경되는 증권사, 교통정보 시스템, 비행관제 시스템 등에 활용될 수 있다.

김성진 실장은 “알티베이스의 DBMS와 ADS, ADI는 데이터베이스에서 일어나는 모든 액션을 통합적으로 볼 수 있는 시각을 제공한다. 어떤 데이터베이스 환경이나 관리환경에서도 알티베이스를 통해 분석, 관리할 수 있다”고 설명했다.

김기완 대표는 “향후 10년의 키워드는 통합과 스트리밍이다. 특히 스트리밍 기술은 데이터 관리의 새로운 패러다임이 될 것”이라며 “생성된 데이터를 저장한 후 처리하는 전통적인 방법으로는 급증하는 데이터를 관리할 수 없다. 이제는 데이터 생성시점에 가공, 이용할 수 있는 통합과 스트리밍이 이슈가 된다”고 거듭 강조했다.
 
 
 
 

<인터뷰>“데이터스트림 기술로 DBMS 시장 새 지평 연다”

원본기사 보기..

김기완 알티베이스 사장, “실시간 전사 데이터 관리 솔루션 업체로 진화”

“지난 30년 동안 이어져온 DBMS 기술을 이어갈 기술은 스트림 처리와 데이터 통합입니다. 알티베이스가 지난 10년 동안 MMDBMS(Main Memory DBMS)와 하이브리드 DBMS 개발로 이슈를 만들었던 것처럼, 앞으로는 데이터 스트림과 이기종 DBMS와의 연동·통합에 가장 확신을 주는 솔루션으로 시장을 리드해 나갈 것입니다.”  올해로 DBMS 시장 진출 10년째를 맞이한 대표적인 국산 DBMS 업체 알티베이스의 김기완 사장은 새로운 10년을 준비하기 위한 핵심 키로 ‘알티베이스 데이터 인티그레이터’와 ‘알티베이스 데이터 스트림’ 솔루션을 제시하고, 실시간 전사 데이터 관리 솔루션 업체로의 진화를 선언했다.  김 사장은 “소프트웨어 전문기업으로서 10년을 넘기는 경우가 통계적으로 1%도 채 안 되는 데, 알티베이스는 메모리 DBMS로 새로운 시장을 열었고 하이브리드 형태의 DBMS로 일반 시장에서도 성공적으로 영역을 넓혀나갔다”며 “최근에는 국방부 등 공공기관에서의 도입이 증가하고 있으며 통신/금융 분야도 여전히 알티베이스의 캐시카우”라고 밝혔다.  알티베이스의 주력 제품인 하이브리드 DBMS를 비롯해, 새롭게 구성된 솔루션 2종을 포함한 포트폴리오는 최근 고객들의 관심사가 이기종 DBMS간 데이터의 실시간 통합·연동, 스트림데이터의 실시간 전송과 처리로 이동하고 있는 데 주목해 알티베이스가 약 2년간 개발해 발표한 것이다.  오는 6월 출시될 예정인 ‘알티베이스 데이터 인티그레이터’는 고객이 오라클, 사이베이스 등 기존에 사용하고 있는 DBMS 제품들과 어떻게 연동할 것인지를 고민하고, 내놓은 솔루션이다. 이 솔루션은 연동하려는 제품의 로그를 직접 읽어내는 로그 기반 CDC(Changed Data Capture) 방식으로, 해외에도 퀘스트소프트웨어의 셰어플렉스와 IBM의 인포스피어 CDC 두  제품 정도만 나와 있는 상태다.  김 사장은 이와 더불어, DBMS 시장의 새로운 지평을 열 기술로 ‘데이터 스트림’을 지목했다. 현행 방식은 새롭게 발생하는 데이터는 반드시 저장한 다음 처리·분석하는 과정을 거치고 있는 데. 스트림 처리 방식은 데이터를 저장하지 않고 처리하는 게 특징이다. 김 사장은 “데이터 스트림은 분산 환경에서 폭발적으로 증가하는 신규 데이터에 대한 실시간 전송 및 처리를 지원하는 혁신적인 제품"이라며 “다양한 노드에서 발생하는 방대한 데이터의 실시간 전송 및 처리를 위해 DDS(Distribution Data Service), DSMS(Data Stream Management System), CEP(Complex Event Processing) 등 신규 기술을 대거 채용했다”고 밝혔다.  김 사장은 또 “오라클과 같은 경쟁업체를 비슷한 기술개발로 뒤따라가는 것이 아니라, 데이터 스트림이라는 새로운 기술 이슈로 완전히 차별화된 DBMS를 제공함으로써 경쟁우위를 가져가겠다”고 덧붙였다. 한편, 알티베이스는 이번 신제품 출시를 통해 올해 2곳 정도의 레퍼런스를 확보할 계획이다.  김나연 기자 grace@ittoday.co.kr --------------------- 아하 ... 가장가리에 있는 데이터스트림 연구실 .. 뭐 하나 했었는데 ... 괜찮네 ㅎㅎ ..

PostgreSQL 이 무엇입니까??

PostgreSQL 은 차세대 DBMS (database management system) 연구의 프로토타입인 POSTGRES DBMS 의 발전된 형태입니다. PostgreSQL 이 강력한 데이타 모델과 풍부한 데이타형을 그대로 유지하면서 PostQuel 질의어를 확장된 SQL 의 서브셋으로 대체했습니다. PostgreSQL 은 공짜이며 전체 소스가 공개되어 있습니다.

PostgreSQL 개발은 PostgreSQL 개발자 메일링리스트를 구독하는 인터넷 개발자들의 모임에 의해 이루어지고 있습니다. 현재 코디네이터는 마크 G. 푸르니에(Marc G. Fournier, scrappy@postgreSQL.org ) 입니다. 참여하고 싶으신 분은 밑의 내용을 참조하십시오. 현재로써는 이 팀이 PostgreSQL 의 개발을 모두 담당하고 있습니다.

PostgreSQL 1.01 의 저자는 앤드류 유(Andrew Yu)와 졸리 첸(Jolly Chen)이었습니다. 다른 많은사람들이 포팅, 테스팅, 디버깅, 그리고 코드를 향상시키는데 참여했습니다. PostgreSQL 은 Postgres 로부터 파생되었는데, Postgres 의 원래 코드는 캘리포니아 대학 버클리의 마이클 스톤브레이커 교수의 지도 하에 많은 대학원생, 학부생, 그리고 스태프 프로그래머들이 노력한 결과물이었습니다.

버클리에서 개발될 때 이 소프트웨어의 원래 이름은 Postgres 였습니다. 1995년에 SQL 기능이 추가되면서 Postgres95 로 바뀌었습니다. 1996년 말에 다시 이름이 PostgreSQL 로 바뀌었습니다.

1.2) PostgreSQL 은 어디에서 실행될 수 있습니까?

저자들은 PostgreSQL 을 다음 플랫폼에서 컴파일하고 테스트해보았습니다. (어떤 경우에는 gcc 2.7.0 을 필요로 합니다)

• aix - IBM on AIX 3.2.5 or 4.x
• alpha - DEC Alpha AXP on Digital Unix 2.0, 3.2, 4.0
• BSD44_derived - OSs derived from 4.4-lite BSD (NetBSD, FreeBSD)
• bsdi - BSD/OS 2.0, 2.01, 2.1, 3.0
• dgux - DG/UX 5.4R4.11
• hpux - HP PA-RISC on HP-UX 9.0, 10
• i386_solaris - i386 Solaris
• irix5 - SGI MIPS on IRIX 5.3
• linux - Intel x86 on Linux 2.0 and Linux ELF SPARC on Linux ELF PPC on Linux Elf (For non-ELF Linux, see LINUX_ELF below).
• sco - SCO 3.2v5
• sparc_solaris - SUN SPARC on Solaris 2.4, 2.5, 2.5.1
• sunos4 - SUN SPARC on SunOS 4.1.3
• svr4 - Intel x86 on Intel SVR4 and MIPS
• ultrix4 - DEC MIPS on Ultrix 4.4

다음 플랫폼에서는 문제점과 버그들이 발견되었습니다.

• nextstep - Motorola MC68K or Intel x86 on NeXTSTEP 3.2

1.3) PostgreSQL 을 어디에서 구할 수 있을까요?

PostgreSQL 의 주된 anonymous FTP 사이트는 다음과 같습니다 :

• ftp://ftp.postgreSQL.org/pub

다음과 같은 미러사이트들이 있습니다 :

• ftp://postgres95.vnet.net/pub/postgres95
• ftp://ftp.luga.or.at/pub/postgres95
• ftp://cal011111.student.utwente.nl/pub/postgres95
• ftp://ftp.uni-trier.de/pub/database/rdbms/postgres/postgres95
• ftp://rocker.sch.bme.hu

1.4) PostgreSQL 의 저작권은 어떻게 됩니까?

PostgreSQL 의 저작권은 다음과 같습니다.

PostgreSQL Data Base Management System

Copyright (c) 1994-6 Regents of the University of California

이 소프트웨어와 그 문서의 사용, 복사, 수정, 배포는 어떤 목적이든 상관없이 무료로, 서면동의 없이 다음 조건 하에 허락됩니다. 위의 저작권 사항과 이 문단, 그리고 다음 두 문단이 모든 사본에 유지되어야만 합니다.

캘리포니아 대학은 직접적이든 간접적이든 특별하든 사고였든 어떤 경우에도 이 소프트웨어와 그 문서를 사용함으로써 결과적으로 일어나는 금전적인 손해를 포함하여 어떤 위험에 대해서도 비록 캘리포니아대학이 그러한 위험의 가능성에 대해 충고를 받았다고 할지라도 책임지지 않는다.

캘리포니아 대학은 특히 (Postgres가) 특정한 목적에 적합하여 판매할 수 있을 것이라는 보증을 포함하여 그 외의 어떤 보증도 하지 않는다. 여기에 제공되는 소프트웨어는 "있는 그대로" 제공되며 캘리포니아 대학은 유지보수, 기술지원, 업데이트, 향상, 수정 등을 제공할 어떤 의무도 없다.

http://wiki.kldp.org/KoreanDoc/html//PostgreSQLfaq_korean/PostgreSQLfaq_korean.html 

알티베이스 "하이브리드 DBMS로 저비용 고효율 실현

<창간2주년기획>(22)알티베이스 "하이브리드 DBMS로 저비용 고효율 실현"

DBMS의 중요성 높아지며 투자절감효과 커져

알티베이스는 ‘저비용 고효율’을 표방한 하이브리드 데이터베이스관리시스템(DBMS) ‘알티베이스 5’<사진>를 제공하고 있다. 이 제품은 비용 절감 뿐만 아니라 업무생산성을 제고하는 것을 목표로 내걸고 있다. 이는 DBMS의 중요성이 갈수록 높아지는 것과 비례한다. 기업 내 데이터의 중요성이 날로 커지면서 DBMS는 기업 비즈니스의 필수 인포메이션 인프라로서 중추적인 역할을 담당하고 있다. 특히 갈수록 방대해지는 데이터 사이즈와 다양한 애플리케이션 도입 확대로 효율적인 데이터 관리는 기업의 최대 관심사로 떠올랐고, DBMS의 새로운 선택 기준으로 데이터 관리 및 리소스 활용 측면이 부각되고 있다. 알티베이스는 “알티베이스 5가 저비용 고효율 데이터베이스 구축을 위해 최적화된 하이브리드 DBMS”라는 점을 강조한다. 하이브리드 DBMS란, 단일 DBMS 내에서 고성능을 보장하는 MMDBMS와 범용성으로 대변되는 대용량 데이터 처리를 위한 DRDBMS를 동시에 지원하는 혁신적인 아키텍처다. 기업의 업무 특성과 액세스 빈도에 따라 데이터를 차등 관리해 효율적인 데이터 관리와 리소스 활용도를 크게 높여준다. 또한 기업의 환경 및 서비스 특성에 따라 MMDBMS 전용, DRDBMS 전용, 하이브리드용으로 선택적으로 사용 가능해, DBMS 중복 구매에 따른 비용을 절감할 수 있음은 물론, 개발 및 관리, 유지보수도 쉽게 할 수 있는 이점도 제공한다. ’알티베이스 5’는 실시간 대안 DBMS를 표방하고 있는 만큼 대용량 데이터베이스의 효율적인 관리를 위한 범용성 측면의 다양한 기능이 추가됐다. ▲효율적인 메모리 자원 관리를 위한 유저 메모리 테이블스페이스(User Memory Tablespace) ▲최대 4GB의 BLOB 컬럼 ▲시공간 데이터를 저장, 관리하는 스파티오-템포럴(Spatio-Temporal) 등을 지원한다. 또한 데이터베이스의 안정성과 영속성을 보장하는 신뢰성 측면의 기능도 보강됐다. 정상 종료시에도 100% 완벽하게 복구 가능하도록 변경된 데이터베이스에 대해 로깅이 수행되는 것이 특징이다.   <알티베이스는 어떤 회사?> 알티베이스는 외산 DBMS 벤더들의 점유율이 90%를 넘나드는 국내 DBMS 시장에서 DBMS 개발만을 고집해온 토종 DBMS 대표 기업이다. 알티베이스는 고성능 데이터 처리를 지원하는 MMDBMS(Main Memory DBMS)로 틈새 시장을 개척하며 금융, 통신 분야를 중심으로 독자적인 영역을 구축해오다, 지난 2004년 ‘DBMS의 새로운 대안’을 표방한 하이브리드 DBMS(Hybrid DBMS) 출시와 함께 범용 DBMS 시장으로의 진입을 선언, 외산 벤더들과의 본격적인 경쟁을 펼치고 있다. 이종 DBMS 구매로만 가능하던 데이터의 차별화된 관리를 단일 DBMS로 처리할 수 있게 됨에 따라 기업들은 중복 DBMS 구매 회피, 관리의 단순성 및 용이성 제고, 유지보수 비용 절감의 효과를 동시에 기대할 수 있게 됐다. DBMS 업계 최초이자 연속으로 GS 인증을 획득한 바 있으며, 2006년 신SW대상 영예의 대상인 대통령상을 받기도 했다. 이 회사는 설립 이후 지금까지 DBMS 라이선스 기준 약 700억원의 대체 수요를 발굴해 로열티 지불에 따른 외화 유출 방지에 기여하고 있다. SK텔레콤, KT, KTF, LG텔레콤, 굿모닝신한증권, 하나대투증권, 한화증권, 신영증권, 키움증권, 코스콤, 삼성증권 등이 알티베이스의 주요 고객이다. 또한 중국, 일본, 대만 등에도 레퍼런스를 확보해 외화 획득 및 국위 선양에도 나서고 있다. <미니인터뷰/ 김기완 대표> 김기완 알티베이스 대표는 ‘위기는 곧 기회다’라는 말을 강조했다. 그는 소프트웨어 기업들에게 있어서 준비란, 사용자의 요구에 최적화된 제품과 경쟁사가 제공할 수 없는 차별화된 서비스 확보라고 판단하고 있다. 어려울 때일수록 본연의 업무에 충실히 하고, 내실을 다지는데 보다 많은 자원을 투입해야 한다는 것이다. 김 대표는 “전 세계를 강타한 경제 불황은 DBMS 시장에 호재로 작용했다”면서 “특정 벤더 제품만을 고수하던 고객들이 TCO 및 ROI 측면에서 제품을 다시 바라보기 시작했다”고 말했다. 김 대표는 “기존 제품의 품질 향상, 기존 제품을 확대할 수 있는 신제품 확보, HW/SW 벤더들과의 협력 체제 구축, 파트너들과의 긴밀한 공제 체제를 강화해 내수 시장에서의 점유율을 확대해 나갈 것”이라고 말했다. 이병희 기자 shake@ittoday.co.kr http://www.ittoday.co.kr/home/post/post_view.jsp?dseq_no=7219&menuId=AAAI&cateCode=AAAI&pageCode=7219&curPage=&serType=&serText=