Background Image
조회 수 217 추천 수 1 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

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

이전글: CUBRID Internal: 큐브리드의 저장공간관리 (DIsk Manager, File Manager)

 

볼륨은 어떻게 관리될까?

- 볼륨 헤더(Volume Header)와 섹터 테이블(Sector Table) -


 앞선 글에서 디스크 매니저(Disk Manager)가 섹터의 예약(reservation)을 관리한다고 이야기하였다. 이번 글에서는 볼륨 내의 섹터들이 어떻게 관리되는지에 대한 구체적인 이야기와 이를 위해 볼륨이 어떻게 구성되어 있는지를 다룬다. 여기서 다루어지는 볼륨의 구조는 그대로 non-volatile memory (SSD, HDD 등)에 쓰여진다.

 

볼륨 구조


 디스크 매니저의 가장 큰 역할은 파일생성과 확장을 위해 섹터들을 제공해주는 것이다. 이를 위해 각 볼륨은 파일들에 할당해줄 섹터들과 이를 관리하기 위한 메타(meta)데이터로 이루어져 있다. 메타데이터들이 저장된 페이지를 볼륨의 시스템 페이지(System Page)라고 하며, 볼륨에 대한 정보와 각 섹터들의 예약 여부를 담고 있다. 시스템 페이지는 다음과 같이 두가지로  분류할 수 있다.

  • 볼륨 헤더 페이지 (Volume Header Page, 이하 헤더 페이지): 페이지 크기, 볼륨 내 섹터의 전체/최대 섹터, 볼륨 이름 등, 볼륨에 대한 정보를 지니고 있는 페이지

  • 섹터 테이블 페이지 (Sector Table Page, 이하 STAB 페이지): 볼륨 내의 각 섹터의 예약여부를 비트맵으로 들고 있는 페이지

이러한 시스템페이지들은 볼륨이 생성될 때 미리 볼륨 내의 정해진 공간에 쓰이고, 이 페이지들이 포함된 섹터를 제외한 나머지 섹터들이 파일 매니저로부터의 섹터 예약요청을 처리하기 위해 사용된다. 볼륨 헤더는 볼륨의 첫 번째 페이지에 할당되고, STAB 페이지는 헤더 페이지의 바로 다음 페이지부터 볼륨의 크기를 모두 커버할 수 있는 만큼의 양이 연속적으로 할당된다(disk_stab_init()). 이를 도식화하면 다음과 같다.

volume_format.png

첫 섹터가 시스템 페이지들을 위해 할당된 모습을 볼 수 있다. 시스템 페이지들의 수가 한 섹터를 못 채울 경우 그림처럼 시스템페이지들을 위해 할당된 섹터 내의 페이지들이 일부 사용되지 않을 수 있고, 볼륨에 크기가 커지면 이에 따라 시스템페이지들을 위한 섹터가 둘 이상 할당될 수도 있다.

 

볼륨 헤더 (Volume Header)


볼륨 헤더(DISK_VOLUME_HEADER)는 볼륨의 첫 번째 페이지에 쓰이며, 기본적으로 볼륨에 대한 정보들이 고정 크기로 들어가고 나머지 공간에는 가변길이 변수들이 들어간다. 볼륨 헤더가 담고 있는 정보는 크게 5가지 정도로 분류할 수 있다.

- 볼륨 정보: 볼륨 자체에 대한 정보로 볼륨 전체에 공통으로 적용되는 정보이다. 볼륨의 타입, 캐릭터 셋(set), 생성 시간, 섹터당 페이지 수, 페이지의 크기 등이 저장된다.

- 섹터 정보: 볼륨의 현재 섹터의 정보이다. 볼륨 내에 몇 개의 섹터가 있는지, 얼마나 확장될 수 있는지 등이 저장된다.

- 시스템페이지 정보: 앞서 이야기한 시스템페이지에 대한 정보들이 저장된다.

- 체크포인트 정보: 마지막으로 체크포인트가 성공 시 체크포인트의 시작 지점의 로그 레코드 LSA 정보가 저장된다. 이는 리커버리과정에서 사용된다.

- 가변길이 변수: 볼륨 헤더 페이지 내에서 볼륨 헤더의 모든 고정변수를 제외한 나머지 공간은 가변길이 변수들을 위한 공간이다. 볼륨의 full path나 사용자 정의 comment 등이 저장된다.

- 기타: reserved 등 동작과 무관한 특수목적 변수들이 저장된다.

구체적으로 볼륨 헤더 구조체(DISK_VOLUME_HEADER)가 담고 있는 정보(변수)들은 다음과 같다.

 

분류 변수 타입 변수명 설명
볼륨 INT8 db_charset 데이터베이스의 캐릭터 셋
INT16 volid 해당 볼륨의 볼륨 식별자
DB_VOLTYPE type 볼륨의 타입, 볼륨이 어떻게 관리될지를 결정
Permanent: 영구적으로 볼륨유지
Temporary: 서버 종료/재시작시 제거. 임시데이터를 저장하는데 기존 볼륨의 공간이 부족할 경우 생성된다.
DB_VOLPURPOSE purpose 볼륨의 이용목적, 볼륨을 어떻게 사용할지를 결정
Permanent: 영구적인 데이터를 저장할 것.
Temporary: 임시적인 데이터를 저장할 것. 임시데이터를 저장할 때에 임시타입의 볼륨을 만들기전에 임시목적의 영구타입볼륨이 있을 경우 먼저 사용한다.
INT64 db_creation 데이터베이스 생성시간
INT16 next_volid 여러 볼륨이 있을 경우 그들을 연결하는 포인터, 다음 볼륨의 식별자를 담음
DKNPAGES sect_npgs 한 섹터당 페이지 수
INT16 iopagesize 한 페이지의 크기
HFID boot_hfid 볼륨 부팅과 멀티 볼륨관련된 정보를 담고있는 힙(Heap)파일의 식별자
섹터 DKNPAGES nsect_total 볼륨의 현재 총 섹터 수, 볼륨파일의 크기를 결정
DKNPAGES nsect_max 볼륨이 확장될 수 있는 최대 크기의 섹터 수
SECTID hint_allocsect 섹터예약시 섹터테이블의 어디부터 탐색할지 캐싱해둔 값
시스템 페이지 DKNPAGES stab_npages 섹터테이블이 차지하는 페이지 수
PAGEID stab_first_page 섹터테이블의 시작페이지
PAGEID sys_lastpage 마지막 시스템 페이지 (현재 stab_first_page+stab_npages -1)
체크포인트 LOG_LSA chkpt_lsa 체크포인트 시작점의 LSA, 리커버리분석의 시작점 (ARIES의 master record)
가변길이 변수 char [1] var_fields 가변길이 변수들의 시작점, var_fileds + offsetto* 가 각 가변변수의 위치
INT16 offset_to_vol_fullname 볼륨의 절대경로 이름의 offset
INT16 offset_to_next_vol_fullname next_volid 볼륨의 절대경로 이름의 offset
INT16 offset_to_vol_remarks 볼륨에 대한 코멘트의 offset
코멘트는 볼륨포맷(disk_format())시에 적히는 것으로 유저가 addvoldb를 실행하면서 적는 코멘트나 볼륨의 공간이 가득차 자동으로 새로운 볼륨을 만들어질 경우 적히는 코멘트("Automatic Volume Extension") 등이 들어간다.
기타 INT32 reserved0/1/2/3 미래 확장성을 위한 예약변수들
INT8/32 dummy1/2 alignment를 위한 더미변수들
char [] magic 볼륨파일의 매직넘버

* 각 변수에 대한 설명을 달아두었긴 했지만, 명확한 이해를 위해서는 각 변수의 값이 언제 설정되고, 어떻게 사용되는지 등을 알아야 한다. 이에 대한 자세한 내용은 각 변수가 이용되는 부분을 설명할 때 다시 살펴보도록 한다.

 

섹터 테이블 (Sector Table)


 섹터 테이블(STAB)은 볼륨 내 모든 섹터들의 사용 여부(예약 여부)를 저장하고 있는 비트맵이다. 섹터 테이블 페이지의 하나의 비트는 하나의 섹터의 예약 여부를 나타낸다. 섹터 테이블은 볼륨 헤더 페이지의 바로 다음 페이지(볼륨의 두번째 페이지, stab_first_page)부터 시작하여 볼륨의 최대 크기(nsect_max)를 커버할 수 있는 만큼의 페이지(stab_npages)를 사용한다. 섹터예약에 관한 연산을 수행할 때, 각 비트를 하나씩 순회하며 연산을 수행할 수도 있지만 큐브리드는 비트들을 DISK_STAB_UNIT (이하 unit, 유닛)이라는 단위로 묶어 관리, 연산하고 불가피할 경우에만 비트를 순회한다. 비트연산을 할 때에 CPU 아키텍쳐등을 고려하여 효율적인 방법으로 처리 할 수 있도록 이러한 처리단위를 제공한다. 정리하자면 섹터 테이블의 비트맵은 여러페이지로 구성되며 각 페이지는 다시 유닛으로 나뉘고, 유닛의 비트들은 각각의 하나의 섹터의 예약 여부를 나타낸다. 섹터 테이블을 읽거나 조작하는 등의 연산은 모두 이 유닛을 기반으로 이루어진다.

* 현재 유닛은 다음과 같이 UINT64형이다. CPU아키텍처나 디자인에 맞춰 이 값을 변경시키면 STAB의 관리 단위를 변경 시킬 수 있다. 주석 또한 이 값의 변경을 통해 유닛단위를 쉽게 변경할 수 있을 것이라 이야기하고 있다.

만약 sector_id가 32100인 섹터에 대한 예약여부를 확인하려할 때, STAB에서 해당 비트의 위치는 어떻게 구할 수 있을까? 이는 마치 초에서 (시,분,초)를 구하듯 (page_id, offset_to_unit, offset_to_bit) 으로 다음과 같이 계산된다.

page_id: (볼륨헤더의 stab_first_page) + sector_id / (페이지의 비트 수)
offset_to_unit: sector_id % (페이지의 비트 수) / (페이지내 유닛의 수)
offset_to_bit: sector_id % (페이지의 비트 수) % (페이지내 유닛의 수)

만약 1KB 페이지, 64bit unit이라면 sector_id 32100인 (3, 117, 36)이 된다. 안타깝게도 페이지의 크기가 2^n형태가 아니기 때문에 OS의 페이지 테이블이나 CPU 캐시처럼 단순 비트 쉬프트연산으로 유닛과 오프셋등을 구할 수 없다. 때문에 비싼 /, % 연산이 사용된다.

* IO 페이지의 크기는 4KB, 16KB 등 2^n형태이더라도 모든 페이지가 공통적으로 페이지타입, LOG_LSA 등의 공간을 이미 예약해두었기 때문에 실제 사용가능한 크기는 이 영역을 제외한 크기이다.

 

섹터 테이블의 연산

 섹터의 예약정보를 조회하거나 예약하려면 섹터테이블의 비트맵을 조작해야한다. 이러한 연산들은 앞서 말한 유닛 단위를 기반으로 이루어지며, 하나의 섹터 비트나 유닛을 참조할 일 보다는 여러 유닛들을 참조하는 경우가 대부분이기 때문에 커서(Cursor, DISK_STAB_CURSOR)와 이터레이션 인터페이스(disk_stab_iterate_units())를 제공한다. 커서는 볼륨 내 한 섹터의 STAB에서의 위치(page_id, offset_to_unit, offset_to_bit)를 가리킨다. 또, 커서가 가리키는 유닛에 대한 연산을 위해 커서가 가리키고 있는 유닛의 포인터(page, unit)를 들고 있다.

typedef struct disk_stab_cursor DISK_STAB_CURSOR;                 
struct disk_stab_cursor
{
    const DISK_VOLUME_HEADER *volheader;    /* Volume header */

    PAGEID pageid;      /* Current page ID */
    int offset_to_unit;     /* Offset to current unit in page. */
    int offset_to_bit;      /* Offset to current bit in unit. */

    SECTID sectid;      /* Sector ID */     

        // 위의 변수들은 모두 현재 커서가 가리키는 섹터에 대한 정보와 STAB내에서 섹터의 위치
        // 아래의 변수들은 위의 변수들이 가리키는 STAB내의 유닛을 참조하기 위한 포인터

    PAGE_PTR page;      /* Fixed table page. */                   
    DISK_STAB_UNIT *unit;       /* Unit pointer in current page. */
};

이터레이션 함수인 disk_stab_iterate_units() 의 선언부는 다음과 같다. (설명에 필요하지 않은 인자들은 제외하였다.)

static int disk_stab_iterate_units (..., DISK_STAB_CURSOR * start, DISK_STAB_CURSOR * end, DISK_STAB_UNIT_FUNC f_unit, void *f_unit_args)

앞서 이야기한 커서 자료형의 start, end와 이터레이션하면서 유닛에 적용할 함수(DISK_STAB_UNIT_FUNC)와 함수의 인자를 매개변수로 받는 것을 볼 수있다. 이 함수는 [start, end) 범위의 유닛을 순회하면서 각 유닛마다 DISK_STAB_UNIT_FUNC함수를 적용 시킨다. 여타 프로그래밍언어에 있는 map() 함수를 생각하면 이해가 쉽다. start, end 커서는 disk_stab_cursor_setat\()) 류의 함수를 통해 STAB의 시작이나 끝, 특정 sector ID로 설정된다. DISK_STAB_UNIT_FUNC* 는 함수포인터로 다음과 같다.

typedef int (*DISK_STAB_UNIT_FUNC) (..., DISK_STAB_CURSOR * cursor, bool * stop, void *args);

disk_stab_iterate_units()에서 이터레이션되어 만나는 각 유닛에 대한 커서를 인자로 받아 사용자가 정의한 작업을 진행한다. 이 때 stop에 true를 넣고 함수를 종료하면, disk_stab_iterate_units() 의 이터레이션이 종료된다. 예를 들어 30개의 섹터를 예약하려 할 때, 이번 유닛에서 30개의 섹터 예약을 모두 완료했다면 더 이상의 작업을 중지하는 종료 조건으로 활용할 수 있다. 이러한 유닛 이터레이션을 통한 연산에는 섹터들 예약, 섹터들 예약 해제, 가용 섹터들의 갯수 확인 등이 있다. 좀 더 확실한 이해를 위해 가용 섹터들의 갯수확인에 사용되는 DISK_STAB_UNIT_FUNCdisk_stab_count_free() 와 이에 대한 호출부를 살펴보자.

// free sector의 갯수를 구하는 함수 정의
static int disk_stab_count_free (THREAD_ENTRY * thread_p, DISK_STAB_CURSOR * cursor, bool * stop, void *args)
{   
    DKNSECTS *nfreep = (DKNSECTS *) args;

    /* add zero bit count to free sectors total count */
    *nfreep += bit64_count_zeros (*cursor->unit);
    return NO_ERROR;
}

// 함수 호출부
int disk_rv_volhead_extend_redo (THREAD_ENTRY * thread_p, LOG_RCV * rcv)
{
      ...
      disk_stab_cursor_set_at_sectid (volheader, volheader->nsect_total - nsect_extend, &start_cursor); 
      disk_stab_cursor_set_at_end (volheader, &end_cursor);
        error_code = disk_stab_iterate_units (thread_p, volheader, PGBUF_LATCH_READ, &start_cursor, &end_cursor, disk_stab_count_free, &nfree);
      ...
    disk_cache_update_vol_free (volheader->volid, nfree);
      ...
}

호출부의 예는 recovery의 redo phase에 사용되는 함수중 하나인 disk_rv_volhead_extend_redo() 로, 실제로 확장된 볼륨 내의 free setor의 갯수를 디스크 캐시에 업데이트하기 위한 코드이다. 확장하기 전의 위치(volheader->nsect_total - nsect_extend)에 start커서를 두고, stab의 끝에 end커서를를 두고 disk_stab_iterate_units()함수를 호출하여 [start, end)를 순회하며 모든 유닛들에서 0인 비트들의 갯수를 구하는 것을 볼 수 있다.

* 이러한 이터레이션 방식은 파일매니저와 디스크매니저의 여러 곳에서 사용된다. 대표적으로 나중에 살펴볼 파일 매니저의 파일 테이블과 유저 테이블 등에서도 이러한 패턴으로 데이터를 접근, 조작한다.


이어서 다룰 디스크 매니저 내용은 다음과 같다.

- 섹터 예약 및 예약 해제

- 볼륨 확장


  1. CUBRID의 개발 문화: CUBRID DBMS 프로젝트 빌드 가이드와 빌드 시스템 개선

    시작하며 이전 포스팅에서 CUBRID의 개발 문화: CUBRID DBMS는 어떻게 개발되고 있을까? 라는 주제로 블로그 글을 작성했었던 기억이 납니다. 날짜를 들여다보니 2021년 4월 29일에 작성되었으니 코로나 팬데믹을 이겨내고 CUBRID에서 여러 프로젝트를 진행하느라 시간이 훌쩍 지나갔네요. 그 사이 CUBRID는 11.2 (elderberry) 버전 릴리즈를 지나 11.3 (fig) 버전 릴리즈를 앞두고 있습니다. 이번에도 마찬가지로 [CUBRID의 개발 문화]라는 말머리를 가지고 CUBRID DBMS 프로젝트 빌드에 대한 이야기를 해보려고 합니다. 이전 포스팅의 ‘CUBRID DBMS는 어떻게 개발되고 있을까?’에서 소개했던 개발 프로세스와 프로젝트 기여 가이드의 내용과 조금 주제가 달라보일 수 있는데, 프로젝트 빌드에 대한 내용이 어떻게 개발 문화로까지 이어질 수 있는지 소개해 드리려고 합니다. 빌드 준비하기 누군가 코드를 기여하려고 할 때 빌드는 가장 먼저 해야 하는 첫 발걸음이면서, 동시에 제일 첫 번째로 마주하는 어려움입니다. 먼저 개발 환경에서 프로젝트를 빌드하기 위해서 여러 도구와 라이브러리를 설치하고, 프로젝트의 빌드 방법을 알아야 합니다. 이 때 기여하려...
    Date2023.09.08 Category오픈소스 이야기 By유형규 Views28 Votes0
    Read More
  2. 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김지원 Views190 Votes0
    Read More
  3. 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사니조아 Views160 Votes0
    Read More
  4. 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김재은 Views217 Votes1
    Read More
  5. 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김동민 Views534 Votes2
    Read More
  6. 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 Views362 Votes1
    Read More
  7. 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 Views2620 Votes0
    Read More
  8. 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김주호 Views268 Votes0
    Read More
  9. 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 Views601 Votes0
    Read More
  10. 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우수빈 Views447 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