Background Image
제품 여행
2023.04.26 11:24

Index의 capacity에 관한 정보 열람

조회 수 40 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

Index Capacity 정보

 

들어가며

DBMS의 여러 기능 기능이나 구성 요소들 중에서 가장 중요한 것은 무엇일까요?
Index는 '가장' 중요한은 아니더라도 적어도 '아주 아주' 중요한 요소가 아닐까 생각 합니다.

Index가 없다면 데이터를 쌓아 두기만 할 수 있을 뿐 사실상 관리는 못하는 그런 시스템이 될 테니까요.

자료가 많으면 많을 수록 Index는 더 중요해 집니다.

이렇게 중요한 Index를 분석할 때에도 목적에 부합하는 여러가지 도구와 방법들이 있을 수 있습니다.

이 페이지에서는 그 중에서 Index의 Capaicty에 대한 정보를 리뷰해 보고자 합니다.

기본적인 사용 방법이나 설명은 매뉴얼을 통해 얻을 수 있으므로 여기서 설명은 생략합니다.

 

INDEX CAPACITY 정보 얻기

우선 CUBRID에서는 Index의 Capacity 정보를 다음과 같은 두 가지 방법으로 쉽게(?) 알아 볼 수 있습니다.

1. diagdb tool

-------------------------------------------------------------
BTID: {{0, 5952}, 5953}, idx0 ON dba.tbl, CAPACITY INFORMATION:
Distinct Key Count: 0
Total Value Count: 0
Average Value Count Per Key: 0
Total Page Count: 2
Leaf Page Count: 1
NonLeaf Page Count: 1
Height: 2
Average Key Length: 0
Average Record Length: 0
Total Index Space: 32688 bytes
Used Index Space: 200 bytes
Free Index Space: 32488 bytes
Average Page Free Space: 16244 bytes
Average Page Key Count: 0
-------------------------------------------------------------

 

 2. SHOW INDEX CAPACITY 명령 

Table_name           : 'dba.tbl'        
Index_name           : 'idx0'        
Btid                 : '(0|5952|5953)'        
Num_distinct_key     : 0        
Total_value          : 0        
Avg_num_value_per_key: 0        
Num_leaf_page        : 1        
Num_non_leaf_page    : 1        
Num_total_page       : 2        
Height               : 2        
Avg_key_len          : 0        
Avg_rec_len          : 0        
Total_space          : '31.9K'        
Total_used_space     : '200.0B'        
Total_free_space     : '31.7K'        
Avg_num_page_key     : 0        
Avg_page_free_space  : '15.9K'


위 두가지 수행 결과는 표현되는 키워드와 형식만 약간 다를 뿐 사실 동일한 내용입니다.
 

INDEX CAPACITY 세부 항목

각 항목에 대한 설명을 "SHOW INDEX CAPACITY" 명령의 결과 기준으로 설명하면 아래 표와 같습니다.

 

SHOW INDEX CAPACITY

diagdb 

의 미

비고

Table_name

 

테이블 이름

 

Index_name

 

인덱스 이름

 

Btid

 

BTID 정보 (vol ID, file ID, root_page ID)

 

Num_distinct_key

Distinct Key Count

전체 leaf 페이지에 존재하는 Distinct key 개수

 

Total_value

Total Value Count

인덱스에 저장된 OID 개수

 

Avg_num_value_per_key

Average Value Count Per Key

키 당 OID 값의 평균 개수

((Num_distinct_key > 0) ? (Total_value / Num_distinct_key) : 0)

Num_leaf_page

Leaf Page Count

Non-Leaf 페이지 개수

 

Num_non_leaf_page

NonLeaf Page Count

leaf 페이지 개수

 

Num_total_page

Total Page Count

전체 페이지 개수

 

Height

Height

트리의 높이

 

Avg_key_len

Average Key Length

평균 키 길이

((Num_distinct_key > 0) ? (sum_of_each_key_len / Num_distinct_key) : 0)

Avg_rec_len

Average Record Length

평균 페이지 레코드 길이

((Num_distinct_key > 0) ? (sum_of_each_record_len / Num_distinct_key) : 0)

Total_space

Total Index Space

인덱스에 의해 점유되는 전체 공간

 

Total_used_space

Used Index Space

인덱스의 전체 사용 공간

Total_space - Total_free_space

Total_free_space

Free Index Space

인덱스의 전체 여유 공간

 

Avg_num_page_key

Average Page Key Count

Leaf 페이지 당 평균 키 개수

((Num_leaf_page > 0) ? (Num_distinct_key / Num_leaf_page) : 0)

Avg_page_free_space

Average Page Free Space

전체 페이지 당 평균 여유 공간

((Num_total_page > 0) ? (Total_free_space / Num_total_page) : 0)

 

주1)  v11.2.3 기준입니다.

주2)  각각의 항목은 Overflow Page에 대한 정보를 포함하지 않은 상태로 보여 집니다. 

       다만, Total_value 항목은 Overflow Page의 정보를 포함합니다.

주3)  Overflow Page영역의 정보는 이후 버전에서 포함 될 예정입니다.

 

사용해 보기1

 

우선 자료가 많지 않은 작은 테이블을 가지고 검토를 해 봅시다.

아래와 같이 동일한 구성의 두 테이블읋 준비해서 각각 50건과 500건을 입력합니다.

drop table if exists t1, t2;
create table t1(id int primary key, v1 int, v2 int);
create index idx1 on t1(v1);
create index idx2 on t1(v2);
create table t2 like t1;  

insert into t1 select rownum, rownum % 10, 1 from db_class a, db_class b, db_class c limit 50;
insert into t2 select rownum, rownum % 10, 1 from db_class a, db_class b, db_class c limit 500;

 

아래 명령으로 Capacity 정보를 얻어 봅니다.

;line on
show all indexes capacity  of t1;
show all indexes capacity  of t2;

 

아래에서 왼쪽은 t1 테이블 오른쪽은 t2 테이블에 대한 결과입니다.

=== <Result of SELECT Command in Line 1> ===

<00001> Table_name           : 'dba.t1'
        Index_name           : 'idx1'
        Btid                 : '(0|5696|5697)'
        Num_distinct_key     : 10
        Total_value          : 50
        Avg_num_value_per_key: 5
        Num_leaf_page        : 1
        Num_non_leaf_page    : 0
        Num_total_page       : 1
        Height               : 1
        Avg_key_len          : 4
        Avg_rec_len          : 84
        Total_space          : '16.0K'
        Total_used_space     : '1000.0B'
        Total_free_space     : '15.0K'
        Avg_num_page_key     : 10
        Avg_page_free_space  : '15.0K'
<00002> Table_name           : 'dba.t1'
        Index_name           : 'idx2'
        Btid                 : '(0|5760|5761)'
        Num_distinct_key     : 1
        Total_value          : 50
        Avg_num_value_per_key: 50
        Num_leaf_page        : 1
        Num_non_leaf_page    : 0
        Num_total_page       : 1
        Height               : 1
        Avg_key_len          : 4
        Avg_rec_len          : 804
        Total_space          : '16.0K'
        Total_used_space     : '928.0B'
        Total_free_space     : '15.1K'
        Avg_num_page_key     : 1
        Avg_page_free_space  : '15.1K'
<00003> Table_name           : 'dba.t1'
        Index_name           : 'pk_t1_id'
        Btid                 : '(0|5568|5569)'
        Num_distinct_key     : 50
        Total_value          : 50
        Avg_num_value_per_key: 1
        Num_leaf_page        : 1
        Num_non_leaf_page    : 0
        Num_total_page       : 1
        Height               : 1
        Avg_key_len          : 4
        Avg_rec_len          : 20
        Total_space          : '16.0K'
        Total_used_space     : '1.3K'
        Total_free_space     : '14.7K'
        Avg_num_page_key     : 50
        Avg_page_free_space  : '14.7K'

3 rows selected. (0.004562 sec) Committed. (0.000016 sec)

1 command(s) successfully processed.
 

=== <Result of SELECT Command in Line 1> ===

<00001> Table_name           : 'dba.t2'
        Index_name           : 'idx1'
        Btid                 : '(0|5952|5953)'
        Num_distinct_key     : 10
        Total_value          : 500
        Avg_num_value_per_key: 50
        Num_leaf_page        : 1
        Num_non_leaf_page    : 0
        Num_total_page       : 1
        Height               : 1
        Avg_key_len          : 4
        Avg_rec_len          : 804
        Total_space          : '16.0K'
        Total_used_space     : '8.0K'
        Total_free_space     : '8.0K'
        Avg_num_page_key     : 10
        Avg_page_free_space  : '8.0K'
<00002> Table_name           : 'dba.t2'
        Index_name           : 'idx2'
        Btid                 : '(0|6016|6017)'
        Num_distinct_key     : 1
        Total_value          : 500
        Avg_num_value_per_key: 500
        Num_leaf_page        : 1
        Num_non_leaf_page    : 0
        Num_total_page       : 1
        Height               : 1
        Avg_key_len          : 4
        Avg_rec_len          : 1380
        Total_space          : '16.0K'
        Total_used_space     : '1.5K'
        Total_free_space     : '14.5K'
        Avg_num_page_key     : 1
        Avg_page_free_space  : '14.5K'
<00003> Table_name           : 'dba.t2'
        Index_name           : 'pk_t2_id'
        Btid                 : '(0|5824|5825)'
        Num_distinct_key     : 500
        Total_value          : 500
        Avg_num_value_per_key: 1
        Num_leaf_page        : 1
        Num_non_leaf_page    : 0
        Num_total_page       : 1
        Height               : 1
        Avg_key_len          : 4
        Avg_rec_len          : 20
        Total_space          : '16.0K'
        Total_used_space     : '11.8K'
        Total_free_space     : '4.1K'
        Avg_num_page_key     : 500
        Avg_page_free_space  : '4.1K'

3 rows selected. (0.005187 sec) Committed. (0.000019 sec)

1 command(s) successfully processed.
 

 

    Num_distinct_key와 Total_value를 비교해서 보면 pk_t1_id는 unique 하므로 입력된 레코드 건수와 키의 개수, Total_value의 개수가 동일함을 볼 수 있고,

   idx2는 레코드가 모두 동일한 값을 갖으므로 Total_value의 개수는 레코드 개수와 동일하지만 Num_distinct_key는 항상 1임을 볼 수 있다.

   idx1은 키가 중복되어 Num_distinct_key는 값이 일정 개수 이상으로 늘지 않고 있음을 볼 수 있다.

 

사용해 보기2

이제 데이터의 양을 늘려서 다른 부분들에 대해 검토 해 보겠습니다.

우선 아래와 같은 구문을 이용해서 테이블을 생성하고 데이터를 입력합니다.

drop table if exists tbl;
create table tbl(id int primary key, v1 int, v2 int, v3 int, s char(120));
create index idx1 on tbl(v1, s);
create index idx2 on tbl(v2, s);
create index idx3 on tbl(v3, s);

insert into tbl select rownum, rownum % 5000, rownum % 500, 1, 'cubrid string test' from db_class a, db_class b, db_class c, db_class d limit 100000;
;line on
show all indexes capacity  of tbl;


이 상태에서 아래 명령으로 100건의 레코드를 삭제한 후의 상태와 전체를 모두 삭제한 후의 상태를 확인해 봅니다.

delete from tbl where id%1000 = 1;
show all indexes capacity  of tbl;

delete from tbl;
show all indexes capacity  of tbl;


아래의 표에서 비교해서 볼 수 있습니다.

100000건 입력 후

100건 삭제 후

전체 삭제 후

=== <Result of SELECT Command in Line 1> ===

<00001> Table_name           : 'dba.tbl'
        Index_name           : 'idx1'
        Btid                 : '(0|6208|6209)'
        Num_distinct_key     : 5688
        Total_value          : 100688
        Avg_num_value_per_key: 17
        Num_leaf_page        : 345
        Num_non_leaf_page    : 1
        Num_total_page       : 346
        Height               : 2
        Avg_key_len          : 426
        Avg_rec_len          : 571
        Total_space          : '5.4M'
        Total_used_space     : '3.1M'
        Total_free_space     : '2.2M'
        Avg_num_page_key     : 16
        Avg_page_free_space  : '6.6K'
<00002> Table_name           : 'dba.tbl'
        Index_name           : 'idx2'
        Btid                 : '(0|6272|6273)'
        Num_distinct_key     : 650
        Total_value          : 100150
        Avg_num_value_per_key: 154
        Num_leaf_page        : 76
        Num_non_leaf_page    : 1
        Num_total_page       : 77
        Height               : 2
        Avg_key_len          : 374
        Avg_rec_len          : 920
        Total_space          : '1.2M'
        Total_used_space     : '593.3K'
        Total_free_space     : '635.7K'
        Avg_num_page_key     : 8
        Avg_page_free_space  : '8.3K'
<00003> Table_name           : 'dba.tbl'
        Index_name           : 'idx3'
        Btid                 : '(0|6336|6337)'
        Num_distinct_key     : 1
        Total_value          : 100000
        Avg_num_value_per_key: 100000
        Num_leaf_page        : 1
        Num_non_leaf_page    : 0
        Num_total_page       : 1
        Height               : 1
        Avg_key_len          : 485
        Avg_rec_len          : 1192
        Total_space          : '16.0K'
        Total_used_space     : '1.3K'
        Total_free_space     : '14.7K'
        Avg_num_page_key     : 1
        Avg_page_free_space  : '14.7K'
<00004> Table_name           : 'dba.tbl'
        Index_name           : 'pk_tbl_id'
        Btid                 : '(0|6080|6081)'
        Num_distinct_key     : 100310
        Total_value          : 100310
        Avg_num_value_per_key: 1
        Num_leaf_page        : 156
        Num_non_leaf_page    : 1
        Num_total_page       : 157
        Height               : 2
        Avg_key_len          : 4
        Avg_rec_len          : 12
        Total_space          : '2.4M'
        Total_used_space     : '1.5M'
        Total_free_space     : '926.2K'
        Avg_num_page_key     : 643
        Avg_page_free_space  : '5.9K'

4 rows selected. (6.017251 sec) Committed. (0.000028 sec)

1 command(s) successfully processed.

=== <Result of SELECT Command in Line 1> ===

<00001> Table_name           : 'dba.tbl'
        Index_name           : 'idx1'
        Btid                 : '(0|6208|6209)'
        Num_distinct_key     : 5688
        Total_value          : 100688
        Avg_num_value_per_key: 17
        Num_leaf_page        : 345
        Num_non_leaf_page    : 1
        Num_total_page       : 346
        Height               : 2
        Avg_key_len          : 426
        Avg_rec_len          : 571
        Total_space          : '5.4M'
        Total_used_space     : '3.2M'
        Total_free_space     : '2.2M'
        Avg_num_page_key     : 16
        Avg_page_free_space  : '6.6K'
<00002> Table_name           : 'dba.tbl'
        Index_name           : 'idx2'
        Btid                 : '(0|6272|6273)'
        Num_distinct_key     : 650
        Total_value          : 100150
        Avg_num_value_per_key: 154
        Num_leaf_page        : 76
        Num_non_leaf_page    : 1
        Num_total_page       : 77
        Height               : 2
        Avg_key_len          : 374
        Avg_rec_len          : 921
        Total_space          : '1.2M'
        Total_used_space     : '593.6K'
        Total_free_space     : '635.4K'
        Avg_num_page_key     : 8
        Avg_page_free_space  : '8.3K'
<00003> Table_name           : 'dba.tbl'
        Index_name           : 'idx3'
        Btid                 : '(0|6336|6337)'
        Num_distinct_key     : 1
        Total_value          : 100000
        Avg_num_value_per_key: 100000
        Num_leaf_page        : 1
        Num_non_leaf_page    : 0
        Num_total_page       : 1
        Height               : 1
        Avg_key_len          : 485
        Avg_rec_len          : 1192
        Total_space          : '16.0K'
        Total_used_space     : '1.3K'
        Total_free_space     : '14.7K'
        Avg_num_page_key     : 1
        Avg_page_free_space  : '14.7K'
<00004> Table_name           : 'dba.tbl'
        Index_name           : 'pk_tbl_id'
        Btid                 : '(0|6080|6081)'
        Num_distinct_key     : 100310
        Total_value          : 100310
        Avg_num_value_per_key: 1
        Num_leaf_page        : 156
        Num_non_leaf_page    : 1
        Num_total_page       : 157
        Height               : 2
        Avg_key_len          : 4
        Avg_rec_len          : 12
        Total_space          : '2.4M'
        Total_used_space     : '1.5M'
        Total_free_space     : '925.4K'
        Avg_num_page_key     : 643
        Avg_page_free_space  : '5.9K'

4 rows selected. (0.016022 sec) Committed. (0.000017 sec)

1 command(s) successfully processed.
 

=== <Result of SELECT Command in Line 1> ===

<00001> Table_name           : 'dba.tbl'
        Index_name           : 'idx1'
        Btid                 : '(0|6208|6209)'
        Num_distinct_key     : 489
        Total_value          : 489
        Avg_num_value_per_key: 1
        Num_leaf_page        : 30
        Num_non_leaf_page    : 1
        Num_total_page       : 31
        Height               : 2
        Avg_key_len          : 428
        Avg_rec_len          : 446
        Total_space          : '494.8K'
        Total_used_space     : '217.5K'
        Total_free_space     : '277.2K'
        Avg_num_page_key     : 16
        Avg_page_free_space  : '8.9K'
<00002> Table_name           : 'dba.tbl'
        Index_name           : 'idx2'
        Btid                 : '(0|6272|6273)'
        Num_distinct_key     : 495
        Total_value          : 495
        Avg_num_value_per_key: 1
        Num_leaf_page        : 33
        Num_non_leaf_page    : 1
        Num_total_page       : 34
        Height               : 2
        Avg_key_len          : 422
        Avg_rec_len          : 447
        Total_space          : '542.7K'
        Total_used_space     : '221.3K'
        Total_free_space     : '321.4K'
        Avg_num_page_key     : 15
        Avg_page_free_space  : '9.5K'
<00003> Table_name           : 'dba.tbl'
        Index_name           : 'idx3'
        Btid                 : '(0|6336|6337)'
        Num_distinct_key     : 1
        Total_value          : 431
        Avg_num_value_per_key: 431
        Num_leaf_page        : 1
        Num_non_leaf_page    : 0
        Num_total_page       : 1
        Height               : 1
        Avg_key_len          : 485
        Avg_rec_len          : 520
        Total_space          : '16.0K'
        Total_used_space     : '656.0B'
        Total_free_space     : '15.3K'
        Avg_num_page_key     : 1
        Avg_page_free_space  : '15.3K'
<00004> Table_name           : 'dba.tbl'
        Index_name           : 'pk_tbl_id'
        Btid                 : '(0|6080|6081)'
        Num_distinct_key     : 437
        Total_value          : 437
        Avg_num_value_per_key: 1
        Num_leaf_page        : 4
        Num_non_leaf_page    : 1
        Num_total_page       : 5
        Height               : 2
        Avg_key_len          : 4
        Avg_rec_len          : 19
        Total_space          : '79.8K'
        Total_used_space     : '10.6K'
        Total_free_space     : '69.2K'
        Avg_num_page_key     : 109
        Avg_page_free_space  : '13.8K'

4 rows selected. (0.006074 sec) Committed. (0.000018 sec)

1 command(s) successfully processed.
 

 

 

이 비교 테이블 중에서 PK인 pk_tbl_id에 대해서 우선 살펴 보겠습니다.

우선 Num_distinct_key값이 각각 100000, 99900, 0 으로 표시 되지 않았음을 볼 수 있습니다. 이상하다고 생각되겠지만 이 값들은 사용자가 입력한 정보가 아니라 현재 Index의 상태를 보여주는 용도이기 때문입니다.

우선 처음 100000개를 입력한 상태에서 100310으로 입력건수보다 많은 키가 존재하는 이유는 내부 처리 과정에서 FENCE_KEY와 같은 관리용 키가 생성되었기 때문입니다.

100건을 삭제한 후에도 값이 줄지 않고 있는 이유는 삭제되었다고 해도 Index에 정보가 남아 있는 상태이기 때문입니다. 이런 정보는 VACUUM을 통해서 정리가 됩니다.

전체 삭제 후에도 437개가 있는 것으로 표시되는 것은 VACUUM이 현재 수행 중이어서 정리를 하고 있는 중이기 때문입니다. 아직 전체 정리가 덜 된 상태라고 볼 수 있습니다.

 

이제 idx3 인덱스를 살펴 보겠습니다.

Num_total_page와 같은 페이지 수 정보를 보면 1로 변함이 없습니다. 다른 인덱스들이 데이터 양에 따라 페이지수의 변화가 있는데 비해 idx3는 항상 1개의 페이지만 가지고 있는 것처럼 보입니다.  그 이유는 현재 보여지는 정보에서는  OID Overflow-pages에 대한 정보를 포함하고 있지 않기 때문에 그런 착각을 불러 일으키는 것입니다.

 

마무리

인덱스의 Capacity 정보를 볼 때  혼동 할 만한 부분들에 대해서 간단하게 살펴 보았습니다.

현재 버전에서 아쉬운 점은 OID Overflow pages에 대한 정보가 없다는 것인데 이 부분은 차후 버전에서 개선 될 것입니다.

새 버전에서 정보가 추가되면 다시 변경 사항에 대해 설명 드리겠습니다.

 

 


  1. No Image

    CSQL에서 PreparedStatement 사용하여 Query Plan 확인하기

    CSQL에서 PreparedStatement 사용하여 Query Plan 확인하기 Prepare statement를 이용하여 값을 질의에 포함하지 않고 bind 했을 경우와 질의상에 값을 직접 포함하였을 경우, 일부 상황에서 값에 대한 해석이 모호해져 질의 플랜이 다르게 만들어져 질의의 성능이 달라지는 경우가 있습니다. 이를 위해 csql 에서 prepare statement 사용하는 방법을 정리하였습니다. 아래 확인 예시는 11.2 에서 해결된 부분이나, 그 이전 부분에서 질의 수행 계획이 달라졌음에 대한 이해를 위해 사용하였습니다. CSQL에서 PreparedStatement 사용 1. Prepared Statement 생성 PREPARE stmt_name FROM 'sql문'; 2. Prepared Statement 실행 EXECUTE stmt_name [USING value, value2 ...]; 3. Prepared Statement 해제 {DEALLOCATE | DROP} PREPARE stmt_name; 사용 예시(2가지) 1. csql > PREPARE pstmt FROM 'SELECT 1 + ?'; csql > EXECUTE pstmt USING 4; csql > DROP PREPARE pstmt; 2. csql > PREPARE pstmt FROM 'SELECT col1 + ? FROM tbl WHERE col2 = ?'; csql > SET @a=3, @b='abc'; csql > EXECUTE pstmt USING @a, @b; csql > DROP PREPARE pst...
    Date2023.05.11 Category제품 여행 By김지원 Views43 Votes0
    Read More
  2. No Image

    Index의 capacity에 관한 정보 열람

    Index Capacity 정보 들어가며 DBMS의 여러 기능 기능이나 구성 요소들 중에서 가장 중요한 것은 무엇일까요? Index는 '가장' 중요한은 아니더라도 적어도 '아주 아주' 중요한 요소가 아닐까 생각 합니다. Index가 없다면 데이터를 쌓아 두기만 할 수 있을 뿐 사실상 관리는 못하는 그런 시스템이 될 테니까요. 자료가 많으면 많을 수록 Index는 더 중요해 집니다. 이렇게 중요한 Index를 분석할 때에도 목적에 부합하는 여러가지 도구와 방법들이 있을 수 있습니다. 이 페이지에서는 그 중에서 Index의 Capaicty에 대한 정보를 리뷰해 보고자 합니다. 기본적인 사용 방법이나 설명은 매뉴얼을 통해 얻을 수 있으므로 여기서 설명은 생략합니다. INDEX CAPACITY 정보 얻기 우선 CUBRID에서는 Index의 Capacity 정보를 다음과 같은 두 가지 방법으로 쉽게(?) 알아 볼 수 있습니다. 1. diagdb tool ------------------------------------------------------------- BTID: {{0, 5952}, 5953}, idx0 ON dba.tbl, CAPACITY INFORMATION: Distinct Key Count: 0 Total Value Count: 0 Average Value Count Per Key: 0 Total Page Count: 2 Leaf Page Count: 1 NonLea...
    Date2023.04.26 Category제품 여행 By사니조아 Views40 Votes0
    Read More
  3. CUBRID Internal: Disk Manager #1: 볼륨 헤더(Volume Header)와 섹터 테이블(Sector Table)

    이전글: CUBRID Internal: 큐브리드의 저장공간관리 (DIsk Manager, File Manager) 볼륨은 어떻게 관리될까? - 볼륨 헤더(Volume Header)와 섹터 테이블(Sector Table) - 앞선 글에서 디스크 매니저(Disk Manager)가 섹터의 예약(reservation)을 관리한다고 이야기하였다. 이번 글에서는 볼륨 내의 섹터들이 어떻게 관리되는지에 대한 구체적인 이야기와 이를 위해 볼륨이 어떻게 구성되어 있는지를 다룬다. 여기서 다루어지는 볼륨의 구조는 그대로 non-volatile memory (SSD, HDD 등)에 쓰여진다. 볼륨 구조 디스크 매니저의 가장 큰 역할은 파일생성과 확장을 위해 섹터들을 제공해주는 것이다. 이를 위해 각 볼륨은 파일들에 할당해줄 섹터들과 이를 관리하기 위한 메타(meta)데이터로 이루어져 있다. 메타데이터들이 저장된 페이지를 볼륨의 시스템 페이지(System Page)라고 하며, 볼륨에 대한 정보와 각 섹터들의 예약 여부를 담고 있다. 시스템 페이지는 다음과 같이 두가지로 분류할 수 있다. 볼륨 헤더 페이지 (Volume Header Page, 이하 헤더 페이지): 페이지 크기, 볼륨 내 섹터의 전체/최대 섹터, 볼륨 이름 등, 볼륨에 대한 정보를 지니고 있는 페이지 섹터 테이...
    Date2023.03.30 Category제품 여행 By김재은 Views92 Votes1
    Read More
  4. JPA와 CUBRID 연동 가이드

    JPA? JPA는 자바의 ORM 기술 표준으로 인터페이스의 모음입니다. 표준 명세를 구현한 구현체들(Hibernate, EclipseLink, DataNucleus)이 있고, JPA 표준에 맞춰 만들면 사용자는 언제든 원하는 구현체를 변경하며 ORM 기술을 사용할 수 있습니다. 이번 CUBRID 연동 가이드에서는 대표적으로 많이 사용하는 Hibernate를 사용하여 작성했습니다. 버전 정보 SpringBoot: 2.7.8 Hibernate: 5.6.14.Final Java: 11 CUBRID: 11.0.10, 11.2.2 JPA와 CUBRID 연동 1) 라이브러리 설정 Maven 프로젝트에 JPA(Hibernate), CUBRID JDBC 라이브러리를 넣기 위해 pom.xml에 설정을 합니다. CUBRID JDBC를 받기 위해 repository도 같이 추가해야 합니다. 2) JPA 설정 필요한 라이브러리를 다 받은 뒤 JPA 설정 파일인 persistence.xml에 설정을 해줘야 합니다. 해당 파일은 표준 위치가 정해져 있기 때문에 /resources/META-INF/ 밑에 위치해야 합니다. DBMS 연결 시 필요한 정보와 JPA 옵션들을 설정해 줍니다. 기본적으로 driver, url, user, password를 설정하고, 방언(dialect)도 필수적으로 설정해야 합니다. DBMS가 제공하는 SQL 문법과 함수들이 조금씩 다르기 때문에 JPA가 어떤 DBMS...
    Date2023.02.22 Category나머지... By김동민 Views244 Votes2
    Read More
  5. dblink를 이용한 remote-server materialized view 기능

    Materialized View Materialized View(이하 MView) 이것은 말 그대로 View의 일종으로 일반 View는 논리적인 스키마인데 반해, MView는 물리적 스키마입니다. 논리적 스키마는 실제 데이터가 데이터베이스에 저장되어 있지 않고 데이터를 가져오기 위한 SQL질의만 저장되어 있다라는 것이고, 물리적 스키마 혹은 테이블이라는 것은 셀제 데이터가 데이터베이스에 저장되어 있다라는 것입니다. MView는 필요한 결과를 가져오는 질의가 빈번하게 자주 사용 될 경우, 질의 실행 시간 속도 향상을 위해 데이터베이스 테이블을 만들어 저장해 두는 것으로 실행 비용이 많이 드는 조인이나, Aggregate Function을 미리 처리하여 필요할 때 테이블을 조회 하도록 하는 것 입니다. 예를 들면 대용량의 데이터를 COUNT, SUM, MIN, MAX, AVG 처럼 자주 사용되는 Aggregate Function 실행 속도를 향상을 위해서, 질의 실행 결과을 데이터베이스 테이블로 생성해 두는 벙법입니다. 즉, 자주사용되는 View의 결과를 데이터베이스에 저장해서 질의 실행 속도를 향상시키는 개념입니다. 이번 글에서는 일반적인 MView와 더불어 현재 작업 중인 데이터베이스 로컬 서버가 아닌 원격지(remote) ...
    Date2023.02.20 Category나머지... Bybwkim Views185 Votes1
    Read More
  6. DBeaver 환경을 새로운PC에 간편하게 복원하기

    현재 Java로 구현된 데이터베이스 관리 툴 중에 가장 인기가 있는 툴이 DBeaver가 아닌가 생각된다. DBeaver 툴은 CUBRID 또한 지원을 해서 SQL Query browser의 기능을 충분히 수행한다. ※ DBeaver 특징 □ Community Edition 버전을 사용하면 라이센스(Apache License)가 무료이다. □ 자바/이클립스 기반으로 개발되어서 윈도우, 리눅스, MAC에서 구동된다. □ JDBC 기반으로 해서 DB를 지원한다. (CUBRID, ORACLE, SQL Server, MySQL, Postgresql ... ) □ 개발소스가 공개되어서 버그픽스가 가능하고 새로운 기능을 개발하여 사용이 가능하다. □ 릴리즈도 거의 2주마다 되기 때문에 버그 픽스또한 매우 빠른 편이다. CURBID를 DBeaver에서 사용하는 방법은 "DBeaver Database Tool 큐브리드 사용하기" 를 참조 하면 도움이 될 것이다. 필자는 해당 툴을 사용하다가 사용하는 PC를 바꾸게 되어 기존 설정을 백업해서 복구 하고자 한다. Workspace를 따로 빼서 사용하지 않은 기본 설정으로 사용하신 분을 기준으로 백업/복구를 가이드 하고자 한다. 순서는 다음과 같다. 1. 먼저 백업하고자 하는 기존의 환경에서 탐색기 창을 연다. 2. 주소/디렉터리 위치 표기창에 %appdata%...
    Date2022.12.26 Category나머지... ByHiCLASS Views1255 Votes0
    Read More
  7. CUBRID Flashback

    Introduction 큐브리드 11.2 버전이 릴리즈되면서 Flashback 기능도 함께 소개되었습니다. 아래에서는 큐브리드에서 제공하는 Flashback 에 대한 기능을 이해하기 위한 Background와 흐름, 그리고 사용방법에 대해 소개해드리겠습니다. Background Supplemental logging 사용자가 트랜잭션을 수행하면 트랜잭션 로그가 기록됩니다. 트랜잭션 로그에는 사용자가 변경하기 전의 데이터 (UNDO)와 사용자가 변경한 후의 데이터 (REDO)가 저장됩니다. Flashback에서는 별도의 전용 데이터 공간을 만들기 보다는 이미 로그 볼륨에 저장된 트랜잭션 로그를 사용합니다. 트랜잭션 로그의 UNDO와 REDO를 이용해 사용자가 수행한 SQL구문을 추측합니다. 하지만 트랜잭션 로그에는 데이터베이스의 물리적인 변경에 대한 데이터만을 가지고 있기 때문에, 논리적인 단위 (SQL 구문)으로 반환해야하는 Flashback을 위해서는 추가적인 데이터가 필요합니다. 추가적인 데이터에는 트랜잭션을 수행한 사용자 정보 등이 있으며, 해당 정보는 Supplemental log를 통해 저장됩니다. 따라서, Flashback을 수행하기 위해서는 ‘supplemental_log’ 시스템 파라미터를 1 또는 2로 설정해줘야...
    Date2022.10.25 Category제품 여행 By김주호 Views210 Votes0
    Read More
  8. No Image

    CUBRID to MySQL DBLink

    CUBRID DBLink 란 데이터베이스에서 정보를 조회하다 보면 종종 외부 데이터베이스의 정보 조회가 필요한 경우가 있습니다. 이렇게 외부 데이터베이스의 정보를 조회하기 위해서 CUBRID DBLink를 이용하면 CUBRID, Oracle, MySQL의 데이터베이스의 정보를 조회할 수 있도록 기능을 제공하며, 타 데이터베이스의 정보를 마치 하나의 데이터베이스에서 조회하는 것과 같은 효과를 발휘합니다. 이 글에서는 CUBRID DBLink와 MySQL의 데이터베이스의 정보를 조회하는 방법을 가이드합니다. 적용 환경 OS 버전 : CentOS Linux 7 CUBRID 버전 : CUBRID 11.2.1 MySQL 버전 : MySQL 8.0 MySQL 서버 설정 설치되어 있는 MySQL 서버에서 해야하는 설정입니다. 1. MySQL SSL 설정 SQL 8.0 이상부터 ssl이 기본으로 설정되어 있어 설정을 끄고 실행합니다. 변경 후에는 MySQL을 재시작 해야합니다. 파일 위치: /etc/my.cnf ssl=0 ssl이 잘 적용이 되었는지 확인합니다. [root@localhost ~]# show variables like '%ssl%'; +----------+| Variable_name| Value |+-------------------------------------+----------+ | have_openssl | DISABLED | | have_ssl | DISABLED | 2. MySQL ...
    Date2022.10.25 Category제품 여행 Bysmnam Views401 Votes0
    Read More
  9. No Image

    CUBRID to Oracle DBLink

    CUBRID DBLink란 데이터베이스에서 정보를 조회하다 보면 종종 외부 데이터베이스의 정보 조회가 필요한 경우가 있습니다.이렇게 외부 데이터베이스의 정보를 조회하기 위해서 CUBRID DBLink를 이용하면 CUBRID, Oracle, MySQL의 데이터베이스의 정보를 조회할 수 있도록 기능을 제공하며, 타 데이터베이스의 정보를 마치 하나의 데이터베이스에서 조회하는 것과 같은 효과를 발휘합니다. 이 글에서는 CUBRID DBLink와 Oracle의 데이터베이스의 정보를 조회하는 방법을 가이드합니다. 적용 환경 OS 버전 : Centos7 Linux 7 CUBRID 버전 : CUBRID 11.2.1 Oracle 버전 : Oracle21.3.0.0.0 CUBRID DBLink 설정 다음은 CUBRID에서 Oracle DBLink를 위한 설정 방법입니다. 설정에 필요한 부분들은 다음과 같이 설정하였습니다. Oracle Server IP : 192.168.64.152 Oracle Server Port : 1521 Oracle SID : orcl Oracle 계정 : c##test Oracle 계정 암호 : test CUBRID Server IP : 192.168.64.153 CUBRID DB명 : demodb * Oracle 테이블 정보 create table code( s_name char(1), f_name varchar(6) ); 1. Oracle 설정 1-1) Oracle Client, ODBC Driver 설치 Oracle Instant Clien, ...
    Date2022.10.25 Category제품 여행 By우수빈 Views254 Votes0
    Read More
  10. 공공부문 DBMS 정보자원 현황

    행정안전부/한국지능정보사회진흥원(NIA)에서는 매년 '범정부EA기반 공공부문 정보자원 현황 통계보고서'를 발간합니다. 2022년도 통계보고서는 금년 7월 초에 공개가 되었으며, 최근에 전자신문에서 통계보고서를 기반으로 한 스페셜리포트 기사(공공SW 외산 쏠림 해법은?)를 게재하였습니다. 전자신문 기사에서 공공SW 외산 쏠림 해법으로 2가지를 제시했습니다. 오픈소스 소프트웨어를 활용하여 외산 종속을 탈피하거나 공공부문 SaaS 국산화를 추진하자는 것입니다. 사실 국내 SW 산업은 정보보호, 관제 등 일부 분야를 제외하고 OS, DBMS, WEB/WAS, 백업 등 대부분의 영역에서 외산 편중이 높은 상황입니다. 이제부터 DBMS에 한정해서 조금 더 살펴보겠습니다. 아래 데이터는 2021년 기준이며, Oracle이 63.6%로 여전히 1위 자리를 지키고 있으며, 이어서 Microsoft (SQL Server), 큐브리드, 티맥스데이터(Tibero)가 순위를 차지하고 있습니다. [출처 : 2022년도 범정부EA기반 공공부문 정보자원 현황 통계보고서, 55쪽] 비록 Oracle와 Microsoft의 수량 점유율이 약 80%로 쏠림 현상이 강하게 나타나고 있으나, 큐브리드와 티맥스데이터의 수량을 합치면 15%가 ...
    Date2022.10.21 Category시장 살펴보기 By정병주 Views204 Votes0
    Read More
Board Pagination Prev 1 2 3 4 5 6 7 8 9 10 ... 15 Next
/ 15

Contact Cubrid

대표전화 070-4077-2110 / 기술문의 070-4077-2113 / 영업문의 070-4077-2112 / Email. contact_at_cubrid.com
Contact Sales