UniSQL 운영 및 튜닝 Education Course 한국컴퓨터통신㈜

목차 UniSQL 운영 및 튜닝 Chapter 1. UniSQL 데이터베이스 구조 Chapter 2. 데이터베이스 환경 인자 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 CHAPTER 1. UniSQL 구조 한국컴퓨터통신㈜

데이터베이스 볼륨 demodb UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ databases.txt sqlx.init Permanent volumes Control volumes data temp Log active index generic Temporary volumes Log archives temp temp Optional volumes Backup volumes permanent 볼륨 일단 permanent 볼륨들이 생성되면, 이들은 항상 데이터베이스의 부분이다.   data 볼륨 data 볼륨들은 데이터베이스에 생성된 애트리뷰트들, 클래스들, 인덱스들, 오브젝트들에 관한 정보를 담고 있는 파일들로 구성될 수 있는 permanent 볼륨의 일종이다. 로그 볼륨 로그 볼륨들은 데이터베이스에서 발생된 변경들을 기록한다. 이 로그는 데이터베이스 오퍼레이션이 데이터베이스의 내용을 수정하기 위해 발생될 때마다 동적으로 갱신된다. 백업 볼륨 백업 볼륨들은 전체 데이터베이스의 “명확하지 않은” 스냅샷(snapshot)을 담는다. 로그와 백업 볼륨들은 함께 사용되어 시스템과 미디어 고장 시에 commit되거나 commit되지 않은 트랜잭션들 모두를 회복할 수 있다. 로그들은 사용자-개시 rollback들을 지원하기 위해 또한 사용된다. 제어 정보 볼륨 제어 정보 볼륨들은 데이터베이스의 다양한 볼륨들을 찾고 DBA에게 아카이브 로그들이 제거될 수 있는지를 알려준다. 한국컴퓨터통신㈜

데이터베이스 볼륨(계속) UniSQL 운영 및 튜닝 databases.txt sqlx.init 한국컴퓨터통신㈜ Permanent volumes Temporary volumes Log volumes demodb demodb_x001 demodb_x002 demodb_x003 demodb_t32765 demodb_t32764 demodb_lgat demodb_lgar000 demodb_lgar001 Backup volumes Control volumes databases.txt demodb_bk0v001 demodb_bk1v001 demodb_vinf demodb_lginf demodb_bkinf sqlx.init [hanla:/home/unisql/db] createdb demodb Creating database with 1000 pages. *** UniSQL/X Standalone Release 4.0.2 Patch Level 7 *** Generated Dec 24 1999 at 10:38:45 [hanla:/home/unisql/db] ls -al drwxr-xr-x 2 wschoi kcom 512 3월 22일 14:24 ./ drwxr-xr-x 13 wschoi kcom 512 3월 22일 14:16 ../ -rw------- 1 wschoi kcom 4096000 3월 22일 14:24 demodb -rw------- 1 wschoi kcom 4096000 3월 22일 14:24 demodb_lgat -rw------- 1 wschoi kcom 124 3월 22일 14:24 demodb_lginf -rw------- 1 wschoi kcom 203 3월 22일 14:24 demodb_vinf < Unix platform > 한국컴퓨터통신㈜

데이터베이스 볼륨(계속) UniSQL 운영 및 튜닝 ordblist.txt dbparm.ini 한국컴퓨터통신㈜ Permanent volumes Temporary volumes Log volumes demodb demodbe.001 demodbe.002 demodbe.003 demodbl demodba.000 demodba.001 demodbt.FFF demodbt.FFE Backup volumes Control volumes ordblist.txt demodbb demodbv demodbl demodbk dbparm.ini < Window NT platform > 한국컴퓨터통신㈜

Permanent Volume OS의 파일 시스템에 저장 데이터베이스를 생성할 때 초기화 종류 데이터베이스 페이지 UniSQL 운영 및 튜닝 Permanent Volume OS의 파일 시스템에 저장 데이터베이스를 생성할 때 초기화 종류 control volumes, data volumes, log active volume 데이터베이스 페이지 데이터베이스 생성 시에 페이지 크기 지정(createdb 사용시 –ps 옵션 사용) 생성 시 지정되면 이후 변경 불가능 크기는 2의 배수로 1K 이상 16K 이하(default 4K) [hanla:/home/unisql/db] createdb demodb –ps 8192 Creating database with 1000 pages. *** UniSQL/X Standalone Release 4.0.2 Patch Level 7 *** Generated Dec 24 1999 at 10:38:45 [hanla:/home/unisql/db] ls -al drwxr-xr-x 2 wschoi kcom 512 3월 22일 14:26 ./ drwxr-xr-x 13 wschoi kcom 512 3월 22일 14:16 ../ -rw------- 1 wschoi kcom 8192000 3월 22일 14:26 demodb -rw------- 1 wschoi kcom 8192000 3월 22일 14:26 demodb_lgat -rw------- 1 wschoi kcom 124 3월 22일 14:26 demodb_lginf -rw------- 1 wschoi kcom 203 3월 22일 14:26 demodb_vinf 한국컴퓨터통신㈜

Control Volume 텍스트 파일 형태로 볼륨에 대한 정보 수록 볼륨 정보 UniSQL 운영 및 튜닝 볼륨 정보(demodb_vinf) 로그 정보(demodb_lginf) 백업 볼륨 정보(demodb_bkvinf) 볼륨 정보 각종 볼륨에 대한 위치 정보 수록 수정, 삭제, 이동해서는 안됨 -4 /home/unisql/db/demodb_vinf -3 /home/unisql/db/demodb_lginf -2 /home/unisql/db/demodb_lgat 0 /home/unisql/db/demodb 1 /home/unisql/db/demodb_x001 볼륨 정보 데이터베이스와 관련된 모든 볼륨들의 이름들(위치들)과 내부 볼륨 식별자들은 볼륨 정보 제어 파일에 기록된다. 이 파일에 담겨진 정보는 정보 볼륨들 내에 내부적으로 복제 된다. 이 정보의 접근은 만일 제어 파일이 재 생성될 필요가 있다면 요구된다. 데이터베이스가 재수행(restart)될 때, UniSQL/X는 볼륨 정보 제어 파일을 읽는다. 데이터베이스가 새로운 볼륨들을 가지고 확장될 때, UniSQL/X는 새로운 엔트리들을 데이터베이스 볼륨 정보 제어 파일에 추가한다. 이 정보 파일은 데이터베이스가 이동되거나 한 설치로부터 다른 것으로 복사되거나 하지 않는 한 손으로 변경되어서는 안 된다. 만일 데이터베이스가 이동되거나 복사될 때, 새로운 설치에 데이터베이스 볼륨들의 새로운 위치들을 식별하기 위해 볼륨 정보 제어 파일을 편집해야 한다. 일단 이것이 행해지면 새로운 데이터베이스의 내부 구조가 새로운 설치에 대해 생성되는 것을 보증하기 위해 installdb를 구동하라.   한국컴퓨터통신㈜

Control Volume(계속) 로그 정보 백업 정보 UniSQL 운영 및 튜닝 현재 로그 및 기존 로그에 대한 정보 수록 COMMENT: UNISQLX/LogInfo for database /home/unisql/db/demodb ACTIVE: /home/unisql/db/demodb_lgat 250 pages ARCHIVE: 0 /home/unisql/db/demodb_lgar000 0 247 COMMENT: Log archive /home/unisql/db/demodb_lgar000 is not needed any longer unless a database media crash occurs. -3 /home/unisql/db/demodb/backups 백업 정보 각 정보 볼륨에 대한 모든 백업들의 위치는 백업 정보 제어 파일에 담겨진다. UniSQL/X은 로그 파일들이 보존되는 같은 디렉토리에 이 제어 파일을 유지한다.   로그 정보 로그 정보 제어 파일은 그 데이터베이스를 위해 생성되었던 모든 액티브 또는 아카이브 로그 파일들의 이름들을 기록하는 텍스트 파일이다. 또 이것은 어느 아카이브 로그들이 더 이상 시스템 붕괴와 사용자-개시 rollback들로부터 회복하기 위해 필요되지 않는지에 관련한 정보들을 담는다. 로그 정보는 또한 미디어 붕괴(다음 데이터베이스 백업이 만들어질 때까지 미디어 고장은 없는 것으로 가정)로부터 회복을 위해 필요한 아카이브 로그들을 식별한다. 한국컴퓨터통신㈜

Data Volume 사용 목적에 따라서 지정 UniSQL 운영 및 튜닝 data volume index volume temp volume generic volume 데이터(data) 볼륨은 사용자들이 클래스들, 인스턴스들, 멀티미디어 데이터와 관련되어 필요한 정보를 담는다. 인덱스(index) 볼륨은 애트리뷰트들 상의 인덱스와 질의 처리 속도를 높이거나 무결성 제약을 보증하는 해쉬(hash)들 같이 사용자 데이터를 지원하는 정보를 담는다. 임시(temp) 볼륨은 질의 처리와 정렬에 대해 사용된다. 이것은 임시 목적을 위해 사용되는 영속 볼륨이라는 것에 유의하라. 다음 섹션에서 논의되는 임시 볼륨들과 혼동하지 말라. 임시 목적을 가진 볼륨은 오직 시스템이 비정상적으로 종료될 때 이것의 내용이 보존되지 않는다는 의미에서 “임시(temporary)”이다. UniSQL/X가 다시 시작되었을 때, 모든 임시 스페이스는 재초기화 된다. 모든 로깅은 이 볼륨에는 저지된다. 일반(generic) 볼륨. 은 다른 볼륨 목적에 식별되는 모든 타입들을 포함하여 어떤 종류의 정보도 담을 수 있다. 한국컴퓨터통신㈜

Log Active Volume 데이터베이스에 반영된 작업 내용 기록 트랜잭션의 확인 및 철회를 위한 목적 UniSQL 운영 및 튜닝 Log Active Volume 데이터베이스에 반영된 작업 내용 기록 트랜잭션의 확인 및 철회를 위한 목적 데이터베이스 복구를 위해 필수적 하나의 데이터베이스는 하나의 log active 볼륨을 가짐 filled-up되면 새로운 로그 생성, 복사 시스템 고장이나 미디어 붕괴들이 발생할 때, UniSQL/X는 로그 볼륨들이 원하는 상태로 데이터베이스를 회복하기 위해 사용될 수 있도록 로그 볼륨들을 생성한다. 이들 로그들은 모든 commit된 트랜잭션들이 데이터베이스에 반영되었다는 것과 commit되지 않은 트랜잭션들(메모리에 여전히 있는 변경들)이 데이터베이스에 나타나지 않았다는 것을 보증한다. 데이터베이스 로그는 실제로 연속적인 볼륨들의 집합으로 구성된다. 변경들의 가장 최근의 집합을 가진 로그를 액티브(active) 로그로 부르고, 모든 다른 로그들은 아카이브(archive) 로그라고 부른다. 액티브 로그를 위해 할당된 스페이스가 변경들의 레코드들로 채워지게 될 때, 이것의 페이지들은 새로운 로그(아카이브 로그)로 보관된다. 아카이브 로그는 미디어 고장과 commit되지 않았거나 데이터베이스에 기록되지 않은 변경들의 효과를 지원하기 위해 사용된다. UniSQL/X는 어느 아카이브 로그들이 일반 처리를 위해 더 이상 필요 되지 않는지를 결정하지만 이것이 자동적으로 그들을 파괴하지 않는다. 예를 들어, 정보 볼륨들의 미디어 붕괴가 일어났을 때, 어떤 아카이브 로그들은 일어난 고장 전에 그것의 상태까지 데이터베이스를 회복하기 위해 접근되는 것이 필요하다. 한국컴퓨터통신㈜

Temporary Volume temp volume Log Archive volume UniSQL 운영 및 튜닝 서버가 shutdown될 때 삭제 Log Archive volume media_failures_are_supported=1인 경우 backup시에 필요 없는 로그 삭제 가능(-r 옵션 지정) 생성되는 임시 볼륨들의 크기는 클라이언트의 요구를 처리하기 위한 공간에 의존한다. 디폴트로 UniSQL 서버는 모든 명령들을 완료하기에 필요한 만큼 많은 스페이스를 요구한다. 이 스페이스를 maxtmp_pages 시스템 파라미터를 사용하여 제한할 수 있다. 디폴트로 임시 볼륨들은 첫 데이터베이스 볼륨이 위치한 곳에 생성된다. 그러나, 다른 위치를 명세하기 위하여 voltmp_path 시스템 파라미터를 사용할 수 있다. 모든 임시 볼륨들은 모든 트랜잭션들에 의해 공유된다. 그들은 서버에 의해 관리되고, 클라이언트 편에서 개시된 명령들을 처리하기 위해 공유된다. 임시 볼륨들은 서버가 정상적으로 commdb를 통해(또는 다른 스탠드얼론 어플리케이션으로부터) 종료될 때 삭제된다. 서버가 비정상적으로 종료했을 때(예를 들어, 하드웨어 붕괴 때문에), 임시 볼륨들은 UniSQL/X 데이터베이스가 재수행(restart)될 때 삭제된다. 서버가 동작하고 있는 동안 이들 볼륨들을 삭제해서는 안 된다. 한국컴퓨터통신㈜

기타 databases.txt sqlx.init UniSQL 운영 및 튜닝 클라이언트에게 서버 위치 정보 지시 <db_name><path_to_db_volume><host_name><path_to_log_volume> UNISQLX_DATABASES 환경 변수에 파일 위치 지정 sqlx.init 인자 파일 운영 및 튜닝과 관련 데이터베이스 위치 파일 자신은 환경 변수 UNISQLX_DATABASES 를 통해 위치된다. 만일 이 환경변수가 설정되면, 유효한 databases.txt 또는 ordblist.txt(nt) 파일을 담은 디렉토리 이름이 되어야 한다. 만일 이 환경 변수가 설정되지 않았다면, databases.txt에 대해 현 작업 디렉토리에서 databases.txt가 탐색된다. 전통적 환경에서, 데이터베이스 관리자는 계층의 루트로서 databases.txt 또는 ordblist.txt 파일을 가지고 데이터베이스를 담은 디렉토리 계층을 유지할 것이다. 유틸리티들이 databases.txt 또는 ordblist.txt 파일에 수정할 수 있어야 하기 때문에, 사용자는 그 파일에 쓰기 접근을 가져야 한다. 만일 UNISQLX_DATABASES 환경 변수는 사용자가 쓰기 접근을 갖지 않은 디렉토리를 가리킨다면, 사용자는 데이터베이스를 생성하는 것이 허용되지 않는다. 이 경우에, 데이터베이스 관리자는 그 디렉토리에 사용자 쓰기 권한을 허용하거나 사용자가 databases.txt 또는 ordblist.txt의 개별 복사를 사용자가 접근하는 디렉토리에 생성하고 그 디렉토리로 환경 변수를 설정할 필요가 있다. 한국컴퓨터통신㈜

프로세스 3 종류의 프로세스(master, server, client) master는 머신 당 하나 UniSQL 운영 및 튜닝 프로세스 3 종류의 프로세스(master, server, client) master는 머신 당 하나 server는 데이터베이스 당 하나 UniSQL 사용 모드 client/server mode standalone mode(server와 client가 하나의 프로세스로 실행) 클라이언트 프로세스는 사용자가 데이터베이스와 대화하는 것을 허용하는 프로세스이다. 사용자는 sqlx.init(UNIX) 또는 dbparm.init(Windows)에 있는 워크스페이스 메모리와 관련된 다양한 파라미터들을 설정하여 클라이언트 워크스페이스의 크기를 튜닝할 수 있다. (자세한 사항은 8장 “시스템 파라미터”를 보라.) 클라이언트는 사용자가 작성한 어플리케이션이나 UniSQL에 의해 제공되는 유틸리티 sqlx, isqlx, 또는 backupdb가 될 수 있다. 서버 프로세스는 클라이언트와 데이터베이스 간의 채널이다. 데이터베이스 당 오직 한 서버가 있다. 데이터베이스 관리자가 그 서버에 연결할 수 있는 클라이언트들의 수에 제한을 줄 수 있을 지라도(max_client 시스템 파라미터에 의해) 필요한 만큼의 많은 클라이언트들이 주어진 서버에 연결을 할 수 있다. 하나 이상의 서버(각 데이터베이스당 하나)가 한 호스트에 동작할 수 있다. 마스터 프로세스는 서버와 클라이언트 간의 통신 지휘자이다. 마스터는 오직 클라이언트가 데이터베이스 서버에 연결을 요청할 때 또는 새로운 서버나 드라이버가 시작될 때, 이 통신 프로세스에 관련된다. 요청된 서버를 찾기 위해, 마스터는 databases.txt 파일 또는 시스템 파라미터 파일의 db_hosts 파라미터의 값(Unix일 때 sqlx.init이나 Windows일 때 dbparm.ini)을 이용한다. 한국컴퓨터통신㈜

Client/Server mode UniSQL 운영 및 튜닝 Host 1 Host 2 master server Host 3 client n database 한국컴퓨터통신㈜

Standalone application UniSQL 운영 및 튜닝 Standalone mode Host 1 Standalone application (client & server) database 스탠드얼론 모드는 주어진 클라이언트 어플리케이션에 대해 데이터베이스에 배재적 접근을 제공하기 위해 사용된다. 스탠드얼론 모드에서 클라이언트와 서버는 같은 프로세스이다. 마스터는 스탠드얼론 어플리케이션을 동작시키는데 요구되지 않는다. 정의에 의해, 만일 스탠드얼론 클라이언트가 데이터베이스에 연결된다면, 다른 클라이언트는 그 데이터베이스에 연결될 수 없다. 오직 하나의 접근을 요구하는 모든 프로세스는 스탠드얼론 모드로 동작되어야 한다. 스탠드얼론 모드에서, locking은 데이터베이스 레벨에서 행해진다. 따라서 프로세싱은 클라이언트/서버 모드보다 더 빠르다. 한국컴퓨터통신㈜

데이터베이스 접속 절차(c/s mode) client master server server DB 1 DB 2 UniSQL 운영 및 튜닝 데이터베이스 접속 절차(c/s mode) client (3) 연결 요청 master (1) databases.txt (4) 서버 확인 (1) $UNISQLX_DATABASES (2) 현재 디렉토리 (5) 연결 설정 server server (2) 변수 설정 sqlx.init (1) 환경 변수 값 (2) 현재 디렉토리 (3) 데이터베이스 디렉토리 (4) $UNISQLX/admin DB 1 DB 2 Client/Server Mode Standalone Mode 실행 프로세스크의 크기가 작다 실행 프로세스의 크기가 크다 다수의 클라이언트의 접근 가능 독점적인 접근 가능 동시성 제어 수행 동시성 제어 수행하지 않음 클라이언트의 수가 증가할 수록 성능 저항 한국컴퓨터통신㈜

클라이언트 워크스페이스 클라이언트 캐쉬 서버로부터의 모든 데이터는 클라이언트 워크스페이스에 자동적으로 저장 UniSQL 운영 및 튜닝 클라이언트 워크스페이스 클라이언트 캐쉬 서버로부터의 모든 데이터는 클라이언트 워크스페이스에 자동적으로 저장 클라이언트는 반복적으로 값을 액세스할 때 서버를 거치지 않고 워크스페이스를 액세스 한국컴퓨터통신㈜

연습문제 1 UniSQL DBMS 기반의 시스템은 서버와 클라이언트 프로세스 두개만으로도 다중 사용자에게 서비스 할 수 있다. Standalone 모드에서는 마스터 프로세스가 필요하지 않다. 한 머신에 두개 이상의 마스터 프로세스가 존재할 수 도 있다. 데이터베이스 서버가 수행하고 있는 중에도 볼륨을 추가할 수 있다. 하나의 머신에 databases.txt 파일은 하나만 존재한다. 로그 볼륨(log active, log archive)은 데이터베이스가 존재하는 한 항상 존재한다. 사용자가 데이터베이스를 위해 10M정도의 볼륨을 생성하였다. 시스템이 운용중에 10M의 공간을 모두 사용하였을 때는 서버 오류가 발생하므로 그전에 시스템을 중지하고 새로운 볼륨을 생성해야 한다. 한국컴퓨터통신㈜

연습문제 1 generic 볼륨만으로는 데이터베이스 서비스를 할 수 없다. UniSQL 운영 및 튜닝 연습문제 1 generic 볼륨만으로는 데이터베이스 서비스를 할 수 없다. 필요없는 볼륨을 생성했을 경우는 데이터베이스 서버 프로세스를 중지하고 그 볼륨을 삭제할 수 있다. 임의의 시점에 log active 볼륨과 log archive 볼륨은 각각 하나씩 존재한다. 하나의 데이터베이스를 A 사용자는 standalone 모드로, B 사용자는 클라이언트 모드로 동시에 사용할 수 없다. 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 CHAPTER 2. 데이터베이스 환경 인자 한국컴퓨터통신㈜

환경 변수 환경 변수 설정 방법(csh) UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ UNISQLX setenv UNISQLX /home/unisql LD_LIBRARY_PATH setenv LD_LIBRARY_PATH /usr/lib:$UNISQLX/lib UNISQLX_DATABASES setenv UNISQLX_DATABASES $UNISQLX PATH setenv PATH ($PATH $UNISQLX/{bin,utilities}) UNISQLX_LANG setenv UNISQLX_LANG En_US UNISQLX_MODE setenv UNISQLX_MODE client UniSQLX 환경변수는 UniSQL 데이터베이스 시스템이 설치된 디렉토리를 지정 UNISQL_DATABASES 변수는 클라이언트 또는 서버 프로세스가 데이터베이스 접근시 접근하고자 하는 데이터베이스 위치 정보를 알기 위해 databases.txt를 읽는 디렉토리를 설정한다. PATH는 실행 화일의 위치를 지정하는 환경변수로 UNISQL/X의 bin, utilities를 추가한다. UNISQLX_LANG 변수는 UniSQL에서 사용하는 언어를 지정하는 변수로 En_US, Ko_KR이 있다. UNISQL_MODE는 –sa , -cs등의 옵션을 정하지 않았을 때, default 값을 지정한다. LD_LIBRARY_PATH(Solaris)는 사용자의 library 디렉토리를 지정하는 변수로 이 변수에 UniSQL의 library를 추가한다. (AIX는 LIBPATH(사용방법은 동일), HP_UX는 SHLIB_PATH) 한국컴퓨터통신㈜

인자 환경 설정 인자 파일(sqlx.init) UniSQL 운영 및 튜닝 성능 및 운영에 미세하고도 심각한 영향 DBA가 설정 및 운영 인자 파일 sqlx.init 서버 인자 클라이언트 인자 UniSQL 시스템 파라미터에 할당된 값들은 UniSQL 데이터베이스 시스템의 전체 성능과 행동을 결정한다. 이들 파라미터들은 UniSQL/X와 UniSQL/M 모두에 동일하다. UniSQL 시스템 파라미터들은 설치를 위한, 또는 원하는 데이터베이스를 위한 또는 특정 사용자를 위한 sqlx.init 파일에 파라미터 값들을 설정하여 재정의 할 수 있는 디폴트 값들을 가진다. 한국컴퓨터통신㈜

인자 파일 우선 순위 서버 인자 클라이언트 인자 쉘 환경 변수는 모든 인자 파일보다 우선 UniSQL 운영 및 튜닝 데이터베이스 홈 디렉토리/sqlx.init $UNISQLX/admin/sqlx.init 클라이언트 인자 클라이언트가 실행된 디렉토리/sqlx.init 쉘 환경 변수는 모든 인자 파일보다 우선 예: UNISQLX_NUM_DATA_BUFFERS $UNISQLX/admin 디렉토리에 있는 sqlx.init 파일은 설치 전체에 대한 디폴트 파라미터 값들을 정의하기 위해 사용된다; 즉, 이것은 모든 데이터베이스들에 대한 값들을 정의하기 위해 사용된다. sqlx.init 파일에서 발견되는 설정들은 시스템 파라미터들로서 이전에 할당된 값들을 무효화시킨다. 모든 파라미터들을 위한 값들을 명세할 필요 없다. 예를 들어, 사용자의 sqlx.init 파일은 오직 약간의 파라미터들을 재정의 할 수 있다; 명세되지 않은 파라미터들은 sqlx.init 파일에 포함될 필요는 없다. sqlx.init 파일들이 모두 읽혀진 후에, 마지막 패스가 파일 값들을 무효화하는(override) 환경 변수들을 찾기 위해 프로세스 환경 상에 행해진다. 설정된 모든 파라미터에 대해서, 탐색이 UNISQLX_ 와 대문자 파라미터 이름의 접합(concatenation)인 환경 변수에 대해 행해진다. 만일 환경 변수가 존재하면, 그 값이 이전에 파라미터에 할당된 값을 무효화하기 위해 사용된다. 예를 들어, 만일 UNISQLX_SR_BUFFERS 환경 변수가 설정되면, sqlx.init 파일에 있는 sr_buffers 파라미터의 값이 UNISQLX_SR_BUFFERS의 값에 의해 대체된다. 한국컴퓨터통신㈜

인자 적용 방법 서버 인자 : 서버 구동 시점 클라이언트 인자 : 클라이언트 구동 시점 변경 사항 적용을 위해서는 재구동 필요 UniSQL 운영 및 튜닝 인자 적용 방법 서버 인자 : 서버 구동 시점 클라이언트 인자 : 클라이언트 구동 시점 변경 사항 적용을 위해서는 재구동 필요 $UNISQLX/admin/sqlx.init 보다 local sqlx.init 사용 권장 한국컴퓨터통신㈜

버퍼 관련 인자 num_data_buffers sr_buffers UniSQL 운영 및 튜닝 버퍼 관리자가 캐쉬하고 있는 페이지 수  버퍼 크기 = num_data_buffers  page_size 성능에 많은 영향 데이터베이스의 크기 및 실 메모리, swap 크기 고려 과다한 크기는 swapping으로 인한 thrashing 야기 세밀한 모니터링 및 조정 필요 sr_buffers sort 질의 처리에 사용되는 버퍼 수 sort 질의가 많을 경우에는 크게 설정 일반적으로 256  512 권장 num_data_buffers 페이지 버퍼 교체 알고리즘이 메모리에 페이지를 들이고 나가는 교환을 위해 사용된다. 이 파라미터는 메인 메모리에 캐쉬된 데이터 버퍼들의 수를 명세한다. (각 버퍼의 크기는 createdb의 –ps 옵션에 의해 명세된 데이터베이스 페이지의 크기). 이 파라미터의 최소 값은 5 버퍼이다. 최대 값은 UniSQL/X 서버나 UniSQL/X 스탠드얼론 어플리케이션이 동작하는 머신에서 가능한 메모리의 양에 직접적으로 달려있다. 50 버퍼들 보다 작은 값은 실제 크기의 데이터베이스를 위해서는 너무 작다. 4 KB의 페이지 크기를 가진 데이터베이스에서, 500 버퍼의 디폴트 값은 2MB의 메모리를 요구한다. 만일 최소값보다 더 작은 값을 명세한다면, 디폴트 값이 사용된다. 이 값이 높을수록, 더 많은 요청된 페이지가 페이지 버퍼 풀(pool)에 캐쉬된다. 이것은 I/O를 감소시킨다. 그러나, 만일 이 값이 시스템의 메모리 자원보다 크면 운영체제에 의해 페이지 버퍼 풀의 과도한 교환이 발생한다. 만일 이것이(thrashing) 일어나면, 당신은 당신의 시스템을 위해 더 많은 메모리를 요구하든지 이 파라미터의 값을 줄여야 한다. sr_buffers 이 파라미터는 정렬 목적을 위해 할당되는 임시 목적 볼륨이나 일반 볼륨들의 자유 스페이스에서 서버 버퍼들의 수를 가리킨다. 각 클라이언트에 대해 서버 상에 그 자신의 정렬 버퍼 집합이 할당된다. 이 파라미터의 최소값은 16이고 이것이 디폴트이다. 만일 최소값보다 작은 수가 주어지면, 디폴트 값이 사용된다. 정렬이 완료될 때, 정렬 버퍼는 반환된다. 한국컴퓨터통신㈜

flush_data_buffer_factor UniSQL 운영 및 튜닝 flush_data_buffer_factor 버퍼 내의 dirty 페이지 비율의 한계점 표시 dirty 페이지가 버퍼 내에 많아지면 디스크 입출력 두 배 증가 적용 가능 값 : 0.7(70%)  0.9(90%) 기본 값 : 0.8(80%) 변경하지 않는 것이 좋음 UniSQL/X의 회복 시스템은 dirty 데이터 페이지를 데이터베이스로 write (force)없이 commit과 rollback을 허용한다. dirty 페이지들은 나중에 데이터베이스에 비동기적으로 write될 수 있다. 이 방법은 I/O를 감소시키기 때문에, commit과 rollback 뿐만 아니라, 앞으로의 같은 페이지에 대한 복수개의 갱신들에 효율적이다.. 그러나 이러한 이점은 어떠한 경우에 단점이 될 수도 있다. 만일 모든 데이터 버퍼들이 오직 dirty 페이지들로 채워진다면, UniSQL/X 페이지 버퍼 교환 알고리즘은 두 번의 I/O들을 실행한다: 교환 버퍼에 현재 놓인 dirty 페이지 방출하기 위해, 원하는 페이지를 읽어 들이기 위해. 이러한 상황은 이 파라미터의 값이 도달되고 UniSQL/X가 대기중이거나 체크포인트 오퍼레이션이 진행중일 때, dirty 데이터 페이지들을 강제로 방출하므로 해결될 수 있다. 이 파라미터의 값은 데이터 버퍼에 있는 dirty 페이지들의 원하는 상황 인자들을 가리킨다. 일단 이 인자에 도달되면, dirty 데이터 페이지들은 디스크로 강제된다. 이 파라미터의 최소값은 .30 (30%)이다. 그러나 0.70 ~ 0.90 사이의 값 (70~90%)이 권고된다. 디폴트 값은 0.80이다. 만일 당신이 .30 보다 적은 값을 명세하거나 1.0 보다 크게 명세하면, 디폴트 값이 사용된다. 한국컴퓨터통신㈜

checkpoint_interval 체크포인트 작업 수행 주기 지정 UniSQL 운영 및 튜닝 checkpoint_interval 체크포인트 작업 수행 주기 지정 체크포인트: 빠른 재시작 복구(restart recovery)를 위해 주기적으로 트랜잭션들의 이미지를 디스크에 출력하는 작업 값이 클 수록 재시작 복구 작업이 오래 걸림 값이 작을 수록 정상 작업이 오래 걸림 num_log_buffers와 관련(num_log_buffers의 값보다 크게) 체크포인트의 목적은 scan 되어야 할 로그 페이지들의 수와 구동(restart) 회복 프로세스 동안 다시 행해져야하는 작업의 양을 제한하는 것이다. 체크포인트시 마다 UniSQL/X가 이전 체크포인트 이후로 발생한 commit되거나 commit되지 않은 변경된 데이터 페이지들을 방출(flush)한다. 오랫동안 commit되지 않고 남아있는 페이지들은 회복 동안 지연을 피하기 위하여 방출된다. 즉, 체크포인트는 강제로 변경되고 자주 사용되는 데이터 페이지가 그 페이지를 담은 버퍼가 대치될 때까지 기다림 없이 방출되게 한다. 게다가, 체크포인트 프로세스는 시스템에 있는 각 트랜잭션의 상태를 로그에 기록한다. 만일 이 파라미터의 값이 크면, 시스템 고장 후 데이터베이스를 회복하고 다시 온라인으로 가져오는데 오랜 시간이 걸릴 수 있다. 매우 작은 값은 시스템 고장 이벤트에 시스템 회복을 위해 필요한 시간을 줄여준다. 그러나 작은 값은 체크포인트의 빈도가 증가되기 때문에 성능에 부정적 영향을 미친다. 사용자는 시스템 성능에 근거한 값을 선택하여야 한다. 만일 회복 타임보다 효율적 런타임 성능을 원한다면, checkpoint_interval을 높은 값으로 설정하고 빠른 회복 타임을 원한다면 작은 값을 선택하라. 한국컴퓨터통신㈜

볼륨 관리 관련 인자 voltmp_path maxtmp_pages volext_path UniSQL 운영 및 튜닝 임시로 생성될 temp 볼륨 경로 지정 지정 않으면 데이터베이스 생성된 경로 사용 maxtmp_pages 임시로 생성될 temp 볼륨 크기(페이지 수) 지정 -1 : 무한, 0 : 생성 않음, size : 한계 파일 시스템의 크기에 맞게 지정 필요 volext_path 볼륨 자동 추가 시 경로 지정 voltmp_path 파라미터는 임시 볼륨들이 생성되는 위치(디렉토리)를 식별하는 스트링이다. 이 파라미터의 디폴트 값은 첫 데이터베이스 볼륨이 생성된 위치이다(createdb 유틸리티의 –f 옵션을 사용) 만일 값이 없거나 NULL이 주어지면, 디폴트가 사용된다. Maxtmp_pages는 임시 볼륨들을 위해 할당될 수 있는 페이지들의 최대 수를 명세한다. 이 디폴트 값은 무제한 페이지 수를 가리키는 –1이다. 실제 제한은 voltmp_path에 의해 명세되는 UNIX 상에 이용 가능한 스페이스에 의해 부과된다. 만일 0의 값이 주어지면, 임시 볼륨이 생성되지 않는다. 이 경우에, DBA는 임시 목적들을 위한 permanent 볼륨들을 생성하기 위해 addvoldb 유틸리티를 사용할 수 있다. 만일 –1 이외의 음수 값이 주어지면, 디폴트가 사용된다. volext_path 파라미터는 데이터베이스에 대한 permanent 볼륨 확장이 생성되는 곳의 위치를 식별하는 스트링이다. 만일 위치를 명세하지 않거나 NULL을 명세한다면, volext_path의 값은 디폴트로 첫 데이터베이스 볼륨이 생성되었던 위치이다(createdb 유틸리티의 –f 옵션을 사용). UniSQL/X는 auto_volext_factor의 값이 0보다 클 때, 데이터베이스를 자동적으로 확장할 수 있다. 한국컴퓨터통신㈜

볼륨 관리(계속) unfill_factor UniSQL 운영 및 튜닝 페이지의 여유 스페이스 비율 지정 인스턴스의 페이지 간 이동을 저하시키는 효과 0(0%) ~ .30(30%), 기본값 : .10(10%) filled_area Unfilled_area Overhead Unfill_factor 파라미터는 미래의 갱신을 위하여 각 heap 페이지에 점유된 스페이스의 백분율을 정의한다. 가능한 클래스의 인스턴스들은 물리적으로 연속된 공간에 삽입된다. 그러나, 갱신된 인스턴스를 위해 원래 페이지 상에 그 인스턴스를 저장하기에 충분한 스페이스가 없는 경우에 크기를 증가할 때 시간이 걸릴 수 있다. 이 상황에서, 그 인스턴스는 다른 페이지에 재 할당될 필요가 있다. 이 같은 상황은 성능의 관점에서 바람직하지 않다. 이들 상황들을 막기 위하여 디폴트로 UniSQL/X는 이 파라미터를 .10 (10 %)로 설정한다. 이 값을 .30 (30 %)까지 증가시킬 수 있다. 데이터의 갱신이 빈번하게 발생한다면 이 값을 늘릴 수 있다. Generic volume Index volume 한국컴퓨터통신㈜

볼륨 관리(계속) unfill_index_factor warn_outofspace_factor UniSQL 운영 및 튜닝 볼륨 관리(계속) unfill_index_factor 인덱스 페이지의 여유 스페이스 비율 지정 인덱스 페이지의 split을 저하시키는 효과 0(0%) ~ .35(35%), 기본값 : .20(20%) warn_outofspace_factor 볼륨 부족 경고 메시지 임계값(비율 형태) 가용 페이지 < 볼륨 페이지  인자값 최종적으로 가용 페이지가 10 미만으로 줄 때까지 경고 메시지 출력 기본값 : 0.15(15%) auto_volext_factor 볼륨 자동 추가 시 크기 결정(배수 형태) 자동 추가볼륨 페이지 수 = 초기생성 볼륨 페이지 수  auto_volext_factor 1 : 기본값, 0 : 자동 추가 불허용 unfill_index_factor 파라미터는 인덱스가 생성될 때 사용된다. 이것은 새로운 인덱스의 각 페이지 상에 점유될 스페이스의 양을 결정한다. unfill_index_factor에 의해 알려진 점유된 스페이스의 양은 B+ 트리 인덱스 상의 성능에 영향을 미친다. 왜냐하면 인덱스 페이지들은 그들이 꽉 차면 분할되기 때문이다. 이 점유된 스페이스는 새로운 레코드가 인덱스된 클래스에 추가될 때 인덱스 페이지의 분할을 방지하기 위해 사용된다. 이 파라미터에 대한 디폴트 값은 .20 (20 %)이고, 최대값은 .35 (35 %)이다. 인덱스가 생성된 후에 클래스의 커다란 수의 레코드들을 추가를 기대할 때, 최대 값이 사용되어야 한다. warn_outofspace_factor는 데이터베이스 볼륨이 스페이스가 고갈되어 수행될 때 경고를 주기 위해 사용된다. 자동 경고 메시지가 데이터베이스 볼륨이 페이지 할당 동안 자유 페이지들의 특정 수 이하로 떨어질 때 주어진다. 시발점(threshold) 값은 사용 가능 데이터베이스 볼륨 페이지들의 총 수와 이 파라미터의 값을 곱하여 계산된다. 새로운 경고의 시발점은 warn_outofspace_factor와 가능한 페이지들의 수를 곱하여 계산된다. auto_volext_factor 파라미터는 자동 볼륨 확장이 데이터베이스 시스템에 추가될 때 사용된 최소 페이지 수를 결정한다. 최소 페이지 수는 –p 옵션을 가지고 createdb 유틸리티를 실행하는 동안 생성된 첫 데이터베이스 볼륨의 페이지 수와 auto_volext_factor를 곱한 결과에 의해 결정된다. 한국컴퓨터통신㈜

복구/로깅 UniSQL 운영 및 튜닝 Commit 수행 시 Update query 수행 시 한국컴퓨터통신㈜ 2b 1c Active log Data volume Client Log buffer data buffer < Server Memory > < Disk > 1b 2d 1a 2c 2a Update query 수행 시 - 1a: DB(volume)으로 부터 data load - 1b: log를 log buffer에 기록 - 1c: data buffer의 data를 갱신 Commit 수행 시 - 2a: client workspace에서 dirty page flush - 2b: log buffer에 write - 2c: active log에 log record 기록 - 2d: data volume에 기록(필요에 따라) 한국컴퓨터통신㈜

복구/로깅 관련 인자 log_path log_size UniSQL 운영 및 튜닝 로그가 저장될 경로 지정 로그는 데이터베이스, 백업 볼륨과 분리 저장 데이터베이스 생성시에 지정하는 것이 좋음 log_size 로그 볼륨의 페이지 수 지정 로그는 동시 진행 트랜잭션을 위해 충분히 크게 기본 : 초기 볼륨 페이지, 최소 : 100 성능에 큰 영향 log_path는 파라미터는 로그 파일들의 위치와 데이터베이스 백업을 위한 디폴트 위치들을 명세하는 스트링이다. 데이터베이스 파일들, 로그 파일들, 데이터베이스 백업 파일들을 물리적으로 다른 디스크/미디어 장치에 놓는 것이 바람직하다. 그렇지 않으면, 그 데이터베이스의 볼륨이 위치된 디스크가 고장이 나면, 로그와 데이터베이스 백업들이 손상될 것이고 이것은 데이터베이스를 회복시키는 것을 불가능하게 할 수 있다. 이 파라미터의 디폴트 값은 데이터베이스의 위치이다. 만일 NULL 값을 명세하거나 값을 주지 않으면, 디폴트 값이 사용된다. log_size 파라미터는 로그 파일 페이지들의 수를 가리킨다(액티브 로그와 아카이브 로그들). 로그의 크기는 포화에 도달함 없이 동시 트랜잭션의 모든 동적 변경들을 처리하도록 충분히 커야 한다; 그렇지 않으면, rollback시, 일반 처리시 그리고 시스템 붕괴 회복시에 현저한 성능 저하가 있을 것이다 한국컴퓨터통신㈜

복구/로깅(계속) num_log_buffers UniSQL 운영 및 튜닝 서버 내에 유지되는 로그 버퍼 수 LWA 프로토콜에 의해 로그는 트랜잭션 끝나는 시점에는 항상 디스크에 출력 따라서, 무작정 큰 값은 의미 없음 기본 값 100 동시 사용자가 많고 write가 많은 시스템은 기본 값보다는 많이 할당 이 파라미터는 로깅 목적을 위해 메모리에 캐쉬된 로그 버퍼들의 수를 명세한다. 각 버퍼의 크기는 데이터베이스 페이지 크기(이것은 데이터베이스가 createdb의 –ps 옵션을 사용하여 생성될 때 결정된다)에 속해 있다. 큰 값은 트랜잭션들이 길고 많을 때 로그 I/O를 줄인다. 이것은 디스크에 쓰는(write) 로그의 동기화를 줄인다. 50 ~ 100 버퍼들의 값이 권고된다. 디폴트 값은 50 버퍼이다. 이것은 4 KB의 한 페이지 크기를 가진 데이터베이스에서 400 KB를 요구한다. num_log_buffers에 대한 최소값은 3 버퍼이다. 최대값은 UniSQL/X를 수행하는 머신에 이용 가능한 메모리의 양에 직접적으로 달려있다. 만일 당신이 최소값 보다 작은 값을 명세한다면, 디폴트 값이 사용된다. num_log_buffers 파라미터는 데이터베이스 수정과 많은 동시 트랜잭션 하에서 UniSQL/X의 성능을 증대시키기 위하여 가장 중요한 파라미터중의 하나이다. 이 파라미터를 증가시키는 것은 머신 메모리 사용을 증가시킬 것이고 당신의 머신에서 교환(swapping)을 줄일 수 있다. 운영 체제는 실제 메모리에 맞추지 않은 데이터의 많은 양에 순응하기 위해 교환(swap)한다. 나쁜 성능을 가져오는 과다한 교환(swapping)은 서버의 실제 메모리가 모든 할당된 메모리에 순응하도록 충분히 크지 않다는 것을 가리킨다. 한국컴퓨터통신㈜

복구/로깅(계속) media_failures_are_supported UniSQL 운영 및 튜닝 기존 로그의 보관 여부 표시(0|1) 기존 로그 보관 않으면 트랜잭션의 확인/철회 시에 이를 자동 삭제 트랜잭션이 진행 중에는 철회를 대비하여 보관 기존 로그 보관 않으면 media crash시 복구 불가 기존 로그의 보관으로 인한 파일 시스템 full 방지 ( 주기적인 백업 시에 기존 로그 삭제 ) 기존 로그 보관 및 주기적 백업 권장 이 파라미터는 데이터베이스에 장애 발생시 회복을 지원하기를 원하는지 아닌지를 명세한다. 이 파라미터가 0 (OFF 또는 NO)으로 설정될 때, 액티브 로그가 꽉 찼고, 어느 액티브(commit되지 않은) 트랜잭션의 기록이 있다면, UniSQL/X는 전체 액티브 로그를 새로운 아카이브 로그에 복사한다. 아카이브 로그는 일단 액티브 변경이 완료되면(commit 또는 abort), UniSQL/X에 의해 제거된다. 만일 모든 액티브 로그 페이지들을 사용하는 매우 커다란 트랜잭션을 가진다면, UniSQL/X는 아카이브들을 가지고 액티브 로그를 확장하여 그 트랜잭션을 계속한다. 이들 아카이브들은 일단 commit이나 abort를 하면 자동적으로 제거된다. 이 파라미터의 디폴트 값은 1 (YES 또는 ON)이다. 이것은 미디어 고장이 지원됨을 가리킨다. 만일 media_failures_are_supported가 1로 설정되고, 일단 액티브 로그가 꽉 차면, 이것은 완전히 아카이브로 복제된다. 이 경우에, 아카이브 로그는 제거되지 않는다. 한국컴퓨터통신㈜

락킹(locking) read의 종류 UniSQL 운영 및 튜닝 repeatable read 같은 데이터를 한 트랜잭션 내에서 여러 번 검색할 경우에 항상 같은 값을 읽는 것을 보장 non-repeatable read dirty read 확인(commit)되지 않은 데이터를 읽을 수 있음 dirty read는 한 트랜잭션에 의해 임의의 객체에 대한 수정/입력/삭제가 commit되기 전에 다른 트랜잭션이 변경된 오브젝트들을 검색/수정하는 것이 허용될 때 발생한다. 트랜잭션 T1은 오브젝트를 갱신한다. 그 때, 트랜잭션 T2는 T1이 commit/abort되기 전에 그 오브젝트를 읽는다. 만일 T1이 abort되면, T2는 결코 commit되지 않는 오브젝트의 내용을 보게 된다. 트랜잭션 T1은 인스턴스 O1을 삭제하고 클래스 C에 인스턴스 O2를 삽입한다. 그 때, 트랜잭션 T2는 클래스 C 상에 질의를 실행한다. 만일 T1이 abort되면, T2는 결코 commit되지 않은 인스턴스 O2를 보게 되고, 결코 삭제되지 않은 O1을 보지 못하게 된다. 두개의 트랜잭션들은 동시에 같은 오브젝트를 갱신한다. 두 트랜잭션들은 commit되지 않은 값들에 근거한 그 오브젝트의 새로운 값들을 도출할 수 있다. 만일 한 트랜잭션이 abort되거나 양쪽 트랜잭션이 commit되었다면, 그 데이터베이스에 있는 저장되고 잃어버린 값은 알려지지 않는다. 이것은 때때로 잃어버린 update로서 참조된다. repeatable read: 밈의의 트랜잭션이 한 오브젝트의 값을 자신의 트랜잭션에서 수정하지 않은 이상 몇 번에 걸쳐 읽더라도 항상 같은 값을 볼 수 있어야 한다.. 한국컴퓨터통신㈜

락킹(locking)(계속) UniSQL/X의 isolation level UniSQL 운영 및 튜닝 클래스 인스턴스 REP COMMIT UNCOMMIT TRAN_REP_CLASS_ REP_INSTANCE COMMIT_INSTANCE UNCOMMIT_INSTANCE N/A TRAN_COMMIT_CLASS_ UNCO- MMIT 한국컴퓨터통신㈜

락킹(locking)(계속) UniSQL/X의 락킹 UniSQL 운영 및 튜닝 프로토콜 데이터에 대해 읽기 작업은 S-lock을, 쓰기 작업은 X-lock을 획득해야 한다 인스턴스에 대해 S-lock을 얻으려면 먼저 해당 클래스에 IS-lock을 획득해야 한다 인스턴스에 대해 X-lock을 얻으려면 먼저 해당 클래스에 IX-lock을 획득해야 한다 UniSQL/X에서 사용하는 2-단계 락킹 프로토콜에서, 트랜잭션은 오브젝트를 읽는데 shared lock을, 오브젝트를 갱신하는데 exclusive lock을 얻는데, 이것은 충돌 연산들이 동시에 수행되지 못하게 하기 위해서 이다. UniSQL/X가 lock 요구를 받으면, 이것은 lock이 이미 획득된 다른 lock들과 충돌을 일으키는지 테스트한다. 만일 그렇다면, 그 트랜잭션을 보류시켜 그 lock의 허용을 연기한다. 그 트랜잭션은 일단 다른 트랜잭션들이 그 lock을 해제하면 다시 재개하여 그 lock을 얻는다. 일단 lock이 해제되면, 더 이상 새로운 lock들이 요청되지 않는다. Shared lock: 시스템은 그 클래스의 인스턴스들의 클래스 정의(스키마 정의)를 읽는 것을 허용하기 위해 클래스 상에 S_LOCK을 얻는다. 이 lock은 또한 인스턴스들 상에 S_LOCK들을 얻음 없이 그 클래스의 모든 인스턴스들이 읽어지는 것을 허용한다. 그 클래스 상의 S_LOCK은 인스턴스들의 스키마 정의와 그 클래스의 인스턴스들의 어떠한 값들을 변경하는 것으로부터 다른 트랜잭션들을 막는다. 시스템은 인스턴스를 읽기 위해 인스턴스상에 S_LOCK을 얻는다. 이 경우에, IS_LOCK이 그 인스턴스의 클래스 상에 얻어져야 한다. Intention shared lock: 시스템이 그 클래스의 인스턴스의 클래스 정의(스키마 정의)를 읽는 것을 허용하기 위해 클래스 상에 IS_LOCK을 얻는다. 이 lock은 또한 그 클래스의 몇 인스턴스들이 인스턴스들 상에서 shared lock들(S_LOCK)들을 얻어 읽어지도록 허용한다. 그 클래스 상의 IS_LOCK은 다른 트랜잭션들이 그 인스턴스의 클래스 정의(즉, 스키마 정의)를 변경하는 것과 그 클래스의 모든 인스턴스들을 변경하는 것으로부터 막는다. 한국컴퓨터통신㈜

락킹(locking)(계속) 특징 UniSQL 운영 및 튜닝 클래스에 대한 S-lock 설정 해당 클래스의 스키마를 읽는 경우 해당 클래스의 상위 또는 하위 클래스를 읽는 경우 “select * from …”과 같은 질의를 수행하는 경우 트랜잭션에서 읽는 인스턴스의 수가 lock_escalation 값보다 큰 경우 클래스에 대한 X-lock 설정 해당 클래스를 수정하는 경우 트랜잭션에서 쓰는 인스턴스의 수가 lock_escalation 값보다 큰 경우 Exclusive lock: 시스템은 클래스의 인스턴스들의 클래스 정의(스키마 정의)를 변경하는 것을 허용하기 위하여 클래스 상에 X_LOCK을 얻는다. 이 lock은 또한 클래스의 모든 인스턴스들이 그 인스턴스들 상에 X_LOCK (또는 S_LOCK)들을 얻음 없이 갱신되는(읽어지는)것을 허용한다. 그 클래스 상의 X_LOCK은 다른 트랜잭션들이 그 클래스의 클래스 정의나 인스턴스들의 값들을 읽거나 갱신하는 것을 막는다. 시스템은 인스턴스를 갱신하기 위해 그 인스턴스 상에 X_LOCK을 얻는다. 이 경우에, IX_LOCK이 그 인스턴스가 거주하는 클래스 상에 얻어져야 한다. Intention exclusive lock: 시스템은 클래스의 인스턴스의 클래스 정의(스키마 정의)를 읽도록 허용하기 위해 한 클래스 상에 IX_LOCK을 얻는다. 이 lock은 또한 클래스의 몇 인스턴스들이 그 인스턴스들 상에 exclusive lock(shared lock)들을 얻어 갱신되는(읽어지는) 것을 허용한다. 그 클래스 상의 IX_LOCK은 다른 트랜잭션들이 그 인스턴스의 그 클래스 정의(스키마 정의)를 변경하는 것 그리고 그 클래스의 모든 인스턴스들을 읽거나 변경하는 것으로부터 막는다. IX_LOCK들은 인스턴스들이 UniSQL/X 프로토콜에 더 미세한 입자들이기 때문에 인스턴스들 상에 결코 얻어지지 않는다. 한국컴퓨터통신㈜

락킹(locking)(계속) 특징(계속) UniSQL 운영 및 튜닝 클래스에 대한 SIX-lock 설정 클래스에 대해 S-lock을 가지고 있는 트랜잭션이 다시 X-lock을 요구할 경우 Rootclass metaclass로 수정 또는 검색 질의 불가능 lock의 유효 범위 X-lock : 트랜잭션 종료 시점(즉, 확인 또는 철회 시점) S-lock : REP(트랜잭션 종료 시점), COMMIT(읽기 끝나는 시점), UNCOMMIT(lock 요청 않음) SIX_LOCK은 S_LOCK과 IX_LOCK들의 조합으로서 클래스 상에 얻어진다. 이 lock은 그 클래스의 인스턴스들의 클래스 정의(스키마 정의)를 읽는 것과 인스턴스들 상에 S_LOCK을 얻음 없이 클래스의 모든 인스턴스들을 읽는 것을 허용한다. 이것은 또한 이들 인스턴스들 상에 X_LOCK들을 얻어 그 클래스의 인스턴스들 몇을 갱신하는 것을 허용한다. SIX_LOCK들은 인스턴스들이 UniSQL/X 프로토콜에서 가장 작은 입자이기 때문에 인스턴스들 상에 결코 얻어지지 않는다. 한국컴퓨터통신㈜

동시성 제어 및 락킹(locking) 관리 관련 인자 UniSQL 운영 및 튜닝 동시성 제어 및 락킹(locking) 관리 관련 인자 isolation_level 데이터 일관성 유지를 위한 락킹 정책 Repeatable, Commit, Uncommit Class, Instance “TRAN_REP_CLASS_REP_INSTANCE” “TRAN_REP_CLASS_COMMIT_INSTANCE” “TRAN_REP_CLASS_UNCOMMIT_INSTANCE” “TRAN_COMMIT_CLASS_COMMIT_INSTANCE” “TRAN_COMMIT_CLASS_UNCOMMIT_INSTANCE” 이 파라미터는 트랜잭션의 isolation 레벨을 가리킨다. UniSQL/X는 트랜잭션들이 이 파라미터를 조정하여 isolation 레벨을 변경함으로써 일관성의 제약을 낮추어 수행하는 것을 허용한다. 트랜잭션의 isolation 레벨은 트랜잭션이 다른 동시 트랜잭션들로부터 허용될 충돌의 정도의 치수이다. isolation 레벨이 높을수록, 충돌이 덜 발생하고 동시성(concurrency)은 더 낮아진다 한국컴퓨터통신㈜

동시성 제어 및 락킹(locking) 관리(계속) UniSQL 운영 및 튜닝 동시성 제어 및 락킹(locking) 관리(계속) lock_escalation 클래스 단위로의 락킹 변경 임계 값(threshold) 기본 락킹 단위 : 인스턴스 지정 값 이상의 인스턴스 락킹을 확보하면 클래스 락킹으로 변경 일괄 처리 프로그램과 같이 다량의 락킹을 요구하는 경우에는 이 값을 크게 설정 일반적으로 기본 값인 100은 작은 값이므로 크게 설정하는 것이 좋음 UniSQL/X는 multigranularity 락킹 메커니즘을 사용하는 공유된 데이터에 동시 접근을 동기화한다. UniSQL/X는 실행되는 오퍼레이션에 따라 데이터베이스를 전체에, 특정 클래스들에, 또는 인스턴스들에 lock을 걸 수 있다. 이 계획하에서, 모든 클래스들과 인스턴스들은 데이터베이스 상에 lock을 가지고 묵시적으로 lock된다. 데이터베이스 데이터의 어느 유형에 접근을 위해 필요한 lock들은 자동적으로 이 파라미터의 값에 의해 결정된다. 이 파라미터는 인스턴스들 상에서의 lock들이 클래스 lock으로 확대되기 전에 클래스의 개별적 인스턴스들 상에 얻어진 lock들의 최대 수를 명세한다. 과도하게 큰 lock 테이블을 피하기 위해, 이 파라미터에 값을 명세하는 것은 중요하다. 이것은 동시성 제어 메커니즘의 성능에 영향을 줄 수 있다. 이 파라미터의 최소 값은 5 이다. 디폴트 값은 100이다. 만일 값이 최소값보다 작게 주어지면, 디폴트 값이 사용된다. 한국컴퓨터통신㈜

동시성 제어 및 락킹(locking) 관리(계속) UniSQL 운영 및 튜닝 동시성 제어 및 락킹(locking) 관리(계속) lock_timeout_in_secs 최대 락킹 대기 시간(단위:초) 락킹을 얻지 못하면 해당 오퍼레이션은 취소 주의 : 전체 트랜잭션은 철회되지 않음  적절한 정책 필요 기본 값인 -1인 무한정 대기할 수 있으므로, 적절한 시간 지정(lock_isolation_level 고려) 3 계층 구조에서 응용 서버는 최종 클라이언트 입장에서는 공유 자원이므로 작은 값을 적용 이 파라미터는 lock을 기다리는 최소 시간의 양을 가리킨다. 만일 lock이 명세된 시간의 양 내에 허용되지 않는다면, 그 lock이 거절되고 그 오퍼레이션의 수행은 취소된다. UniSQL/X는 오퍼레이션이 lock 타임아웃 때문에 취소되었음을 알리는 에러를 리턴한다. 타임아웃들은 사용자들과 어플리케이션들에 의해 주의 깊게 처리되어야 한다. 이 파라미터의 디폴트 값은 lock이 허용될 때까지 또는 트랜잭션의 deadlock의 결과로 rollback될 때까지 무한정 기다리는 것이다(-1). 0의 값은 lock을 기다리지 않음을 가리킨다. 만일 음수 값이 주어지면, 디폴트 값이 사용된다. 한국컴퓨터통신㈜

동시성 제어 및 락킹(locking) 관리(계속) UniSQL 운영 및 튜닝 동시성 제어 및 락킹(locking) 관리(계속) deadlock_detection_interval 교착 상태 검사 주기 지정(단위 : 초) 두 개 이상의 트랜잭션이 락킹을 대기하고 있고, 이 중 하나라도 이전 검사 주기 이후부터 락킹을 대기할 경우에 교착 상태 검사 수행 lock_isolation_level과 관련 높을 수록 이 값을 적게, 낮을 수록 이 값을 크게 설정 일반적으로 기본 값(30) 적용 두 개 이상의 트랜잭션들이 각각 상대편이 끝나기를 기다리는 상황을 deadlock이라 한다. 이러한 상태에서 관련된 트랜잭션들은 서로가 진행하는 것을 막는다. deadlock이 일어나면, UniSQL/X는 deadlock에 있는 트랜잭션중의 하나를 rollback하여 그 문제를 해결한다. rollback된 그 트랜잭션은 가장 젊은 트랜잭션일 것이다. 적어도 두 개의 중단된(suspended) 트랜잭션들이 있고, 그들 중 하나가 마지막 deadlock 검출이 수행된 동안 계속 중단(suspended)되었을 때, 모든 deadlock_detection_interval 마다 deadlock 검출이 수행된다. 만일 interval 값이 매우 작다면, deadlock이 드물지라도, deadlock을 찾기 위해 많은 시간이 소모된다. 만일 그 interval이 매우 길다면, deadlock 검출을 위한 비용이 덜 든다. deadlock 검출을 위한 시스템 디폴트 값은 30초이다. 만일 0 또는 음수 값이 주어지면, 디폴트가 사용된다. 한국컴퓨터통신㈜

동시성 제어 및 락킹(locking) 관리(계속) UniSQL 운영 및 튜닝 동시성 제어 및 락킹(locking) 관리(계속) thread_quantum 클라이언트의 최대 서버 사용 시간(단위:millisec) 특정 스레드가 다른 스레드에 선점(preempt)되지 않고 서버를 사용할 수 있는 최대 시간 성능에 많은 영향 최적의 값을 찾고자 할 때는 다양한 형태의 테스트가 필요 일반적으로 기본 값(50)은 큰 값으로, 5  30 정도에서 테스트하여 최적의 값 적용 이 파라미터는 일정 시간 후 실행의 thread가 선점될 프로세스 가상 시간으로 수 100분의 1초 단위로 명세한다. 이 값은 오직 근사값이다. 왜냐하면 실제 선점(preemption)은 interval 값이 초과된 다음에 특정 데이터베이스 이벤트에 보여지기 때문이다(즉, 페이지 찾기(lookup) 또는 오브젝트 lock). 운영체제 clock resolution 보다 더 작은 값은 이 resolution으로 올림이 일어난다. 만일 당신이 0 보다 같거나 작은 값을 명세한다면, 스케쥴러는 무의식적인 선점(preemption)을 수행하지 않는다. 달리 말하면, 서버에서 실행 thread는 선점됨 없이 완료까지 수행한다. 디폴트 값은 백만분의 3 초이다. 최대 값은 없다. 한국컴퓨터통신㈜

클라이언트 요구 조절 관련 인자 active_requests max_clients UniSQL 운영 및 튜닝 서버가 동시에 처리하는 최대 스레드 수 자원의 효과적 사용을 위해 제한하는 것이 좋음 실제 동시 사용자 수 고려 max_clients 서버에 접속할 수 있는 클라이언트 수 active_requests 파라미터는 서버 튜닝을 위한 동시 액티브 요청들의 수를 설정한다. 디폴트는 50 이다. max_clients 파라미터는 서버가 받아들일 수 있는 동시 클라이언트 연결들의 최대 수를 식별한다. 만일 max_clients 제한이 도달되고, 새로운 클라이언트가 서버에 연결을 시도하면, 새로운 연결은 거부된다. 디폴트 값은 500이다. 한국컴퓨터통신㈜

워크스페이스 관련 인자 max_quick_size initial_workspace_table_size UniSQL 운영 및 튜닝 워크스페이스 관련 인자 max_quick_size quick fit 알고리즘 : 메모리 할당을 위한 정책 max_quick_size보다 작은 크기의 메모리를 요구할 경우에는 매우 빠르게 처리 이보다 큰 크기의 오브젝트를 빈번히 요구할 경우에는 이 값을 크게 설정 해주는 것이 좋음 최소 32 바이트에서 1KB 까지 가능(기본 : 256) 지속적인 모니터링 필요 initial_workspace_table_size 내부 OID 테이블 크기 오브젝트 캐슁을 위한 hash table 기본값 4092(약 4K), 최소 1K 이상 워크스페이스는 quick fit이라 불리는 저장소(storage) 관리 알고리즘을 사용한다. 이것은 개별 리스트들 상에 있는 같은 크기의 free block들을 유지한다. free block들은 그들이 max_quick_size에의해 명세된 바이트의 수 밑에 있는 한 이들 특정 리스트들 상에 유지된다. 이 크기보다 더 큰 할당은 다소 더한 오버헤드를 가지는 다른 수단에 의해 처리된다. 이 파라미터는 만일 어플리케이션이 max_quick_size의 현재 설정보다 큰 오브젝트들의 빈번한 사용을 한다고 결정되면 증가될 수 있다. initial_workspace_table_size 파라미터는 세션중에 참조되는 오브젝트들의 총 수의 평가로 설정될 수 있다. 이 파라미터의 최소값은 1 KB이다. 디폴트 값은 4092 (4 KB) 오브젝트들이다. 만일 최소값보다 작은 수가 주어진다면, 시스템 디폴트가 사용된다. 한국컴퓨터통신㈜

워크스페이스(계속) max_block_size max_block_count UniSQL 운영 및 튜닝 새로이 할당되는 메모리 블록 크기 기본 128(KB), 최소 16(KB) max_block_count 워크스페이스 내에 할당 가능한 메모리 블록 수 이 수를 넘으면 “메모리 부족” 메시지 출력 메모리를 많이 필요로 하는 응용은 크게 설정 기본 128(블록), 최소 1(블록) max_block_size: quick fit 알고리즘은 저장소(storage)의 커다란 블록을 할당하고 이들 블록 내에서 작은 할당들을 관리한다. 만일 블록 내에 이용 가능한 저장소 모두가 할당되면, quick fit 알고리즘은 부가적인 저장소 블록을 할당한다. max_block_size 파라미터는 이들 블록들의 크기를 명세한다. 이것은 워크스페이스 내에서 단일 할당의 최대 크기를 정의하는 또 다른 효과를 가진다. 이 파라미터의 최소값은 16 KB이다. 디폴트 값은 128 KB이다. 만일 16 KB 보다 적은 수가 주어진다면, 디폴트가 사용된다.   max_block_count 파라미터는 max_block_size와 밀접히 관련된다. 이것은 시스템이 경고 메시지를 주기 시작하기 전에 할당될 수 있는 커다란 워크스페이스 블록들의 수를 설정한다. 만일 어플리케이션이 커다란 양의 저장소를 요구한다면, 프로그램 종료를 일으킬 가상 주소 공간이 고갈 될 수 있다. 워크스페이스 경고 메시지들은 어플리케이션이 커다란 양의 메모리를 소비됨이 진행중인지 아는 것을 허용한다. 만일 어플리케이션이 일반적으로 커다란 수의 블록들을 할당한다면, max_block_size 파라미터는 각 블록이 더 커지고 총 블록들의 수가 더 작아지도록 증가되어야 한다. 이 파라미터의 최소값은 1 블록이다. 디폴트 값은 128 블록이다. 만일 값이 최소값 보다 작게 주어지면, 시스템 디폴트가 사용된다. 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 연습문제 2 데이터베이스 서버 프로세스는 자신의 sqlx.init를 찾기 위해 $UNISQLX/admin 디렉토리를 가장 먼저 찾는다. 서버 프로세스의 환경을 변경하기 위해 sqlx.init 파일의 변수를 수정하면 수정 사항을 프로세스에 반영하기 위해 반드시 서버 프로세스를 재구동 해야 한다. 서버 프로세스의 메모리 크기를 결정하는 인자에는 num_log_buffer, num_data_buffer, sr_buffer, max_block_size 등이 있다. 한번 입력된 데이터를 절대로 수정하지 않는 다면 unfill_factor의 값을 0.6 이하로 하는 것이 최적이다. UniSQL 데이터베이스 시스템에서 commit된 데이터는 commit 즉시 바로 disk에 반영되지 않을 수 도 있다. 로그 파일의 크기가 클 수록 성능에 좋은 영향을 미친다. 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 연습문제 2 Media_failure_are_supported 변수가 0으로 설정되어 있으면 절대로 log archive 파일은 생성되지 않는다. Isolation level에서 dirty read를 허용하지 않는 단계가 Repeatable read 를 보장하는 단계보다 동시성을 높일 수 있다. 한 클래스에 T1 트랜잭션이 IX-lock을 가지고 있는 순간에 T2- 트랜잭션이 요청한 IX-lock은 허용될 수 있다. 하나의 long-term transaction 과 여러 개의 short-term transaction이 수행될 때, Thread_quantom의 값이 작은 것은 short-term transaction의 수행에 유리하다. 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 CHAPTER 3. UniSQL 운영 한국컴퓨터통신㈜

데이터베이스 생성 방법 createdb [options] database_name 작업 내용 UniSQL 운영 및 튜닝 databases.txt에 이름 및 위치 정보 등록 데이터베이스 파일 및 로그 파일 생성 생성되는 파일 종류 데이터베이스 초기 파일, 로그 파일, 볼륨 정보 파일, 로그 정보 파일 기타 지정된 옵션 사항 createdb 유틸리티는 데이터베이스들을 생성하고 미리 만들어진 UniSQL/X 시스템 클래스들을 가지고 그들을 초기화한다. 데이터베이스에 권한이 주어진 초기 사용자들을 정의하는 것이 또한 가능하다. 일반적으로 데이터베이스 관리자만이 createdb 유틸리티를 사용한다. 로그들과 그 데이터베이스의 위치는 이 명령에서 또한 명세된다. 만일 데이터베이스와 로그 위치가 명세되지 않으면 sqlx.init 파일에 있는 값들이 사용된다. createdb와 다른 유틸리티들은 Unix상에서는 databases.txt, NT상에서는 ordblist.txt라는 알려진 모든 데이터베이스의 위치에 관한 정보를 담은 한 파일을 유지한다. 이 파일은 스탠드얼론 어플리케이션들과 데이터베이스 관리 유틸리티들을 수행시키기 위해서 뿐만 아니라 서버를 구동시키기 위해서 사용된다. 모든 클라이언트 어플리케이션들은 데이터베이스 이름을 통해 연결할 원하는 데이터베이스를 명세한다. 사용자는 데이터베이스의 절대 경로 또는 데이터베이스 서버의 호스트 이름과 같은 다른 정보들을 공급하도록 요구되어지지 않는다. 대신에, 이 정보는 많은 사용자들에 의해 접근될 수 있는 공통 파일에 유지된다. 이 파일은 생성되고 createdb, copydb, renamedb, deletedb를 포함하는 몇 개의 유틸리티들에 의해 자동적으로 유지되고 다음 포맷의 일련의 라인들로 구성된다. 한국컴퓨터통신㈜

데이터베이스 생성(계속) createdb options UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ 옵션 인자 설명 기본값 -f file-path 초기 볼륨이 위치할 경로 지정 현재 -l log-file-path 로그 볼륨이 위치할 경로 지정 -p pages 초기 볼륨의 페이지 수 지정 1000 -lp log-pages 로그 볼륨의 페이지 수 지정 -ps page-size 페이지 크기(바이트) 4096 -r 같은 이름의 데이터베이스 삭제 수행 않음 -s server-name 데이터베이스 생성할 호스트 명 현재 시스템 -u user-file 사용자를 입력할 경우에 사용 없음 -v 작업 내용 출력 UniSQL/X 클라이언트와 서버와 작업할 때, 모든 UniSQL/X 데이터베이스들은 다음을 만족시켜야 한다:     유일한 이름을 가져야 하고, databases.txt 파일에 리스트 되어야 한다.   이것은 데이터베이스들을 접근할 때 머신들을 가로질러 작업하는 것을 포함하여 UniSQL/M과 작업할 때도 또한 적용된다. 클라이언트/서버 모드에서 작업하는 모든 사용자에 의해 사용되는 단일 그리고 중앙 databases.txt 또는 ordblist.txt 파일이 있어야 한다. (일단 서버가 구동되면, 데이터베이스의 위치는 UNIX 상의 sqlx.init 파일 또는 NT 상의 dbparm.ini 파일에 있는 db_hosts 파라미터에 의해 결정된다.) %createdb demodb –ps 8192 –l /home/log –f /home/data –lp 300 –p 500 500page(4M, 1page=8192Kbyte) 크기의 generic volume(demodb)을 가진 demodb 데이터베이스를 생성, log(demodb_lgat) 볼륨은 /home/log 디렉토리에 생성되고, generic 볼륨은 /home/data 디렉토리에 생성된다. 로그 볼륨의 크기는 300page(2.4M) 이다. 한국컴퓨터통신㈜

데이터베이스 볼륨 추가 한 파일로 DB를 구성하기 어려운 경우 각 볼륨을 특정 용도로 사용하고 싶은 경우 방법 UniSQL 운영 및 튜닝 데이터베이스 볼륨 추가 한 파일로 DB를 구성하기 어려운 경우 각 볼륨을 특정 용도로 사용하고 싶은 경우 방법 addvoldb [options] database_name num_of_pages 예: 데이터 저장 용도로 5000 페이지 추가 addvoldb -sa -f /home/DB -pu data demodb 5000 addvoldb options 옵션 인자 설명 기본값 -sa|cs stand-alone, client/server mode 지정 $UNISQLX_MODE -f vol_path 볼륨이 저장될 경로 지정 현재 디렉토리 -pu vol_purpose 용도 지정(generic, data, index, temp) generic -n vol_name 볼륨의 이름 DB_x번호 addvoldb 유틸리티는 데이터베이스에 새로운 볼륨들을 더하기 위해 사용된다. 새로운 볼륨들이 더해지지 전에, DBA는 성능 이익을 제공하기 위한 계획하도록 권고된다. 성능은 일반 규칙들이 지켜질 때 개선된다. 디스크 스페이스의 커다란 양을 가진 더 적은 볼륨들이 작은 양의 디스크 스페이스를 가진 많은 볼륨들 보다 선호된다. I/O의 성능을 위해서는 데이터, 인덱스, 임시 정보들이 완전히 다른 디스크 드라이브의 다른 볼륨들로 저장될 때 감소된다. %addvoldb –sa –pu temp –f /home/data demodb 500 500page크기의 temp volume(demodb)을 demodb 데이터베이스에 추가. 추가될 볼륨(demodb_x001)볼륨은 /home/data 디렉토리에 생성 한국컴퓨터통신㈜

볼륨정보 확인 데이터베이스 볼륨 모니터링 spacedb [-sa | -cs] [-o output_file] database UniSQL 운영 및 튜닝 볼륨정보 확인 데이터베이스 볼륨 모니터링 사용법 spacedb [-sa | -cs] [-o output_file] database % spacedb demodb Space description for database ‘demodb’ with page 4096. Volid Purpose total_pages free_pages VolName 0 GENERIC 500 216 /home/db/demodb 1 TEMP 500 247 /home/db/demodb_x001 --------------------------------------------------------------------- 2 1000 463 Volid Purpose total_pages free_pages VolName 0 TEMP 567 564 /home/db/demodb_t3434 spacedb 유틸리티는 데이터베이스에 있는 모든 영속 데이터 볼륨들의 간략한 설명을 표준 출력(stdout)으로 프린트한다. 이 유틸리티에 의해 리턴되는 정보는 볼륨 ID와 이름, 각 볼륨의 목적, 각 볼륨과 관련된 총(total)/빈(free) 스페이스을 포함한다. 볼륨들의 총 수, 사용되는 데이터베이스 페이지들 그리고 사용되지 않은 데이터베이스 페이지들이 spacedb에 의해 프린트된다. 한국컴퓨터통신㈜

데이터베이스 삭제 stand-alone 상태에서만 가능 방법 UniSQL 운영 및 튜닝 데이터베이스 삭제 stand-alone 상태에서만 가능 방법 deletedb [-o outfile_file] database_name 작업 내용 관련된 데이터베이스 파일들을 삭제 databases.txt 파일에서 관련 사항 삭제 -o 옵션은 deletedb의 출력을 콘솔에 메시지들이 보여지도록 하는 대신에 파일에 기록하게 한다. 명령 라인 상에 식별되는 데이터베이스_이름 은 /usr/smith/test_db 같이 경로가 될 수 없고, test_db 같이 단순 이름으로 주어져야 한다. 한국컴퓨터통신㈜

데이터베이스 서버 구동 방법 start_server [-timeout second] database_name 작업 내용 UniSQL 운영 및 튜닝 데이터베이스 서버 구동 방법 start_server [-timeout second] database_name 작업 내용 시스템에 마스터가 존재하지 않으면 먼저 구동 이전에 비정상적으로 서버가 종료된 경우에 restart recovery 수행 timeout 기간 동안에 이루어지지 않으면 종료 start_server 유틸리티는 $UNISQLX/utilities/ 에 있는 UNIX 쉘 스크립트이다. 이 유틸리티는 마스터가 수행중인지를 체크한다. 만일 이것은 마스터 프로그램이 수행중이지 않다면, 그 서버를 구동하기 전에 마스터를 구동한다. 일단 마스터가 수행중이면, 그 때 이것은 서버를 구동한다. start_server 는 서버가 연결을 받을 준비가 되었을 때만 서버가 구동되도록 결정한다. 만일 몇 가지 이유로 서버가 고장 회복을 수행할 때(이것은 다소 시간이 걸릴 수 있다), start_server는 명세된 타임아웃 시간 뒤에 타임아웃된다(디폴트로 33초). 타임아웃 시간 후에, start_server는 서버가 연결을 받아들일 준비가 되어 있지 않다고 당신에게 알리는 메시지와 함께 종료한다. 서버가 연결하는 것을 보증하기 위하여, 당신은 당신이 start_server를 실행할 때 더 긴 타임아웃 시간을 명세할 수 있다. 한국컴퓨터통신㈜

데이터베이스 서버 종료 방법 stop_server database_name 작업 내용 주의 사항 UniSQL 운영 및 튜닝 현재 진행중인 트랜잭션 취소 후 종료 주의 사항 kill 명령으로 서버를 종료 시키지 말 것 부득이한 경우에는 sqlx -sa database로 반드시 데이터베이스 회복시킬 것 회복 작업은 절대 중단시키지 말 것 stop_server 유틸리티는 commdb –S 기능을 수행하는 유닉스 유틸리티이다. 이것의 주요 기능은 서버를 우아하게 셧다운하고, start/stop 기능을 일관성 있게 수행하기 위하여 start_server와 연결하여 사용된다. 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 연습문제 3-1 현재 작업 디렉토리의 서브 디렉토리로 data, log, index, temp 디렉토리를 생성하고 다음과 같은 구조를 같는 데이터베이스를 생성하시오 데이터베이스 생성 및 볼륨 추가(작업이 끝난후 spacedb의 결과는 다음과 같음) hanla: /user/student] spacedb -sa testdb Space description for database 'choidb' with pagesize 2048. Volid Purpose total_pages free_pages Vol Name 0 GENERIC 300 44 /user/student/data/testdb 1 DATA 300 35 /user/student/data/testdb_x001 2 INDEX 100 50 /user/student/data/testdb_x002 3 TEMP 200 35 /user/student/data/testdb_x003 ------------------------------------------------------------------------------------- 4 900 164 Space description for temporary volumes for database testdb with pagesize 2048 제어 파일과 databases.txt 파일의 내용을 확인하시오. 서버를 구동한 후 client/server 모드로 데이터베이스에 접속하시오. testdb 데이터베이스에 임의의 클래스와 인스턴스를 생성하시오. %sqlx –cs testdb sqlx> create class employee ( id integer, name char(20) ); sqlx> insert into employee(id, name) values(1, ‘lee’); sqlx> insert into employee(id, name) values(2, ‘lee’); sqlx> insert into employee(id, name) values(3, ‘lee’); sqlx> insert into employee(id, name) values(4, ‘lee’); sqlx> insert into employee(id, name) values(5, ‘lee’); sqlx> create index on employee(id); sqlx> ;x sqlx> ;commit 한국컴퓨터통신㈜

데이터베이스 복사 방법 copydb [options] source_database target_database 내용 UniSQL 운영 및 튜닝 데이터베이스 복사 방법 copydb [options] source_database target_database 내용 현재 DB와 똑같은 상태의 DB 생성 백업 목적 또는 테스트 용도의 DB 생성 stand-alone 상태에서만 가능 copydb 유틸리티는 데이터베이스를 한 위치에서 다른 곳으로 복사하거나 이동하기 위해 사용된다. 데이터베이스의 모든 볼륨과 제어 파일은 새로운 타겟에 복사되고 새로운 로그가 새로운 데이터베이스를 지원하기 위해 생성된다. 새로운 데이터베이스는 복사하는 데이터베이스의 이름과 다른 이름이 주어져야 한다. 한국컴퓨터통신㈜

target database 초기 볼륨 디렉토리 지정 UniSQL 운영 및 튜닝 데이터베이스 복사(계속) copydb options 옵션 인자 설명 기본값 -s server_name 호스트 명 현재 호스트 -f file_path target database 초기 볼륨 디렉토리 지정 현재 디렉토리 -l log_file_path target database 로그 볼륨 디렉토리 지정 (1) -f option (2) src DB log -e volext_path target database 확장 볼륨 디렉토리 지정 (1) -tf option (2) src DB ext -tf to_from_path 각 볼륨에 대해 복사할 경로 지정 없음 -r target DB와 같은 것이 있으면 삭제 수행 않음 -m 복사 후 source DB 삭제 수행 않음 볼륨 복사 경로 파일 (-tf): 더 복잡한 데이터베이스 볼륨들의 복사가 필요할 때, 다른 디렉토리에 개별적 볼륨들의 이름과 위치를 담은 파일이 공급될 수 있다. 원시 데이터베이스의 모든 볼륨들이 이 파일에 담겨져야 한다. 각 볼륨을 식별하는 구문은 다음과 같다:   볼륨식별자 원시_완전볼륨이름 타겟_완전볼륨이름 모든 파라미터들은 각 볼륨들에 대해 공급되어야 한다. 볼륨식별자 는 볼륨 번호를 식별하는 integer이다. 원시_완전볼륨이름 은 볼륨 이름의 원시 경로명이고 타겟_완전볼륨이름 은 새로운 보륨에 대한 타겟 경로명이다. 이 파일은 데이터베이스 볼륨 정보 제어 파일을 –tf 옵션으로 명세될 파일에 복사하여 쉽게 만들어질 수 있다. 첫 두 아규먼트들(볼륨식별자 와 원시_완전볼륨이름)은 볼륨 복사 경로 파일에 이미 존재한다. 이것은 타겟_완전볼륨이름 파라미터를 포함하기 위해 편집되어야 한다. 한국컴퓨터통신㈜

데이터베이스 복사(계속) 예제 UniSQL 운영 및 튜닝 다음 볼륨 파일 가지는 demodb를 testdb로 복사 cat demodb_vinf -5 /user1/demodb_vinf -4 /user1/log/demodb_lginf -3 /user1/log/demodb_bkvinf -2 /user1/log/demodb_lginf 0 /user1/demodb 1 /user1/db/demodb_x001 2 /user1/temp/demodb_x002 3 /user1/index/demodb_x003 한국컴퓨터통신㈜

데이터베이스 복사(계속) 예제(계속) UniSQL 운영 및 튜닝 다음과 같은 파일을 작성 cat volcopy.txt 다음의 명령 수행 copydb -l /user2/log -tf volcopy.txt demodb testdb 0 /user1/demo /user2/testdb 1 /user1/db/demodb_x001 /user2/db/testdb_x001 2 /user1/temp/demodb_x002 /user2/temp/testdb_x002 3 /user1/index/demodb_x003 /user2/index/testdb_x003 한국컴퓨터통신㈜

target database 확장 볼륨 경로 지정 UniSQL 운영 및 튜닝 데이터베이스 재명명 사용 방법 renamedb [options] source_database target_database renamedb options 옵션 인자 설명 기본값 -e volext_path target database 확장 볼륨 경로 지정 src DB 경로 -tf vol_tofrom_path 각 볼륨에 대해 복사할 경로 지정 renamedb 유틸리티는 존재하는 데이터베이스의 현재 이름을 변경한다. 정보 볼륨들, 로그 볼륨들, 제어 파일들이 새로운 이름과 일치되게 또한 재 명명된다. copydb, renamedb 같지 않게 부가적 디스크 저장소를 요구하지 않는다. 왜냐하면 데이터베이스가 거기서 재명명되기 때문이다. 한국컴퓨터통신㈜

데이터베이스 백업 백업 결정 사항 UniSQL 운영 및 튜닝 백업할 데이터의 선택 전체 데이터베이스 또는 일부만 백업? 데이터의 유효 또는 보존 기간? 데이터베이스와 함께 백업되어야 할 다른 파일? 백업 방법 사용 가능한 백업 툴 및 백업 장비? incremental 백업이나 on-line 백업 필요? backupdb 유틸리티는 모든 데이터베이스 페이지들, 제어 파일들, 데이터베이스를 백업시와 일치된 상태로 복구하기 위해 필요되는 로그 레코드들을 복사한다. 이 유틸리티는 당신이 미디어 고장과 데이터베이스 파일들의 우발적 손상으로부터 복구할 수 있도록 해주는 데이터베이스 유지 전략의 주요 부분이다. 백업들은 전체(full)로부터 작은 증가(small incremental)까지 몇 개의 레벨들에서 행해질 수 있다. 초기 버전으로부터 나중 버전으로 백업을 복구하는 것은 불가능하다. 이 이유 때문에, 데이터베이스를 더 새로운 버전으로 이주한 후에, 새롭게 이주된 데이터베이스를 즉시 백업하라. 이전 버전에 대한 백업 파일들은 더 이상 데이터베이스의 새로운 버전을 복구하기 위해 사용될 수 없다. 한국컴퓨터통신㈜

데이터베이스 백업(계속) 백업 결정 사항(계속) UniSQL 운영 및 튜닝 백업된 데이터의 복구 미디어 장애의 경우, 장애 이전의 모든 데이터를 복구해야 하는가? 어느 시점의 데이터베이스 상태로 복구해도 무방한가? 복구에 걸리는 시간은 얼마나 되는가? 복구된 데이터베이스를 이전의 데이터베이스와 같이 쓸 수 있는가?   한국컴퓨터통신㈜

데이터베이스 백업(계속) backupdb UniSQL 운영 및 튜닝 방법 backupdb [options] source_database 내용 off-line, on-line, incremental 백업 가능 disk와 tape 등의 미디어 지정 가능 dbname_bk0v000, dbname_bkvinf 파일 생성 백업 파일이 2GB를 넘으면 다음 파일 생성 dbname_bk0v000, dbname_bk0v001 점진적 백업을 지원하는 것에 더불어, UniSQL/X는 백업들이 복수개의 볼륨들로 나누어지는 것을 허용한다. 만일 백업에 대한 원래 타겟이 꽉 차면, 시스템은 사용자에게 백업을 취소하거나 그것을 새로운 위치나 깨끗한 저장 매체에 계속할 수 있다. 예를 들어 새로운 테이프를 설치한 후 할 수 있다. 각 연속은 복구 동안 백업 로깅과 연속화를 위하여 그 자신의 유닛(unit) 번호를 백업 볼륨에 더한다 backupdb 명령 실행 후에, 전체 백업은 단일 테이프 상에서 완료된다면, 시스템은 테이프 라벨 상에 놓을 정보를 보여준다. 이것은 오직 하나의 백업 볼륨을 포함한다. Backup Volume Label; Level: 0, Unit: 0, Database bdb, Backup Time: Mon Nov 11 15:43:30 1996 그러나, 만일 첫 테이프가 꽉 차고, 백업이 완료되지 않았다면, 부가적 프롬프트들이 새로운 테이프가 두 번째 볼륨에 백업을 계속하기 위해 삽입되어야 함을 가리킨다.. 한국컴퓨터통신㈜

데이터베이스 백업(계속) backupdb(계속) UniSQL 운영 및 튜닝 on-line 백업 on-line 백업은 특정 시점의 데이터베이스 이미지의 fuzzy snapshot 제공 commit 되지 않은 데이터가 저장될 수 있음 다른 데이터베이스 작업의 진행에 영향 incremental 백업 0, 1, 2 단계 제공 이전 레벨 백업을 기반으로 이후 변경 사항 백업 복구 시 마찬가지 순서로 수행 점진적 백업들은 이전 백업 이후로 수정된 데이터베이스 페이지만을 저장하여 전형적인 백업 크기와 지속시간을 감소시키는 방법을 제공한다. UniSQL/X는 3 개의 백업 레벨 0, 1, 2를 허용한다. 레벨 0는 백업 시작시 일관된 상태로 데이터베이스를 복구하기 위해 필요되는 모든 데이터베이스 페이지를 담는 전체 백업이다. 점진적 레벨 1 백업이 만들어질 수 있기 전에, 이 레벨의 백업이 있어야 한다. 점진적 레벨 1은 오직 마지막 레벨 0 백업 이후의 변경만을 저장한다. 후속적 레벨 1 백업들은 만일 백업 디렉토리가 같다면 이전 레벨 1을 덮어쓴다. 그러나 만일 테이프 백업이 사용된다면 이전 레벨 1은 복구를 위해 여전히 사용될 수 있다. 이것은 만일 몇 가지 이유 때문에 대부분 최근 레벨 1 백업이 파괴되고 같은 레벨 0로부터 도출된 이전의 레벨 1 백업들이 있다. 점진적 레벨 2 백업이 만들어 질 수 있기 전에 이 레벨의 백업이 있어야 한다. 점진적 레벨 2는 오직 마지막 레벨 1 백업 이후의 변경들만을 저장한다. 모든 경우에, 레벨 2 백업들은 레벨 1 백업들까지 이고, 레벨 1 백업들은 레벨 0 백업들까지 이다. 한국컴퓨터통신㈜

데이터베이스 백업(계속) backupdb options UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ 옵션 인자 설명 기본값 -sa|-cs off-line, on-line 지정 $UNISQLX_MODE -l destination 백업 저장될 경로 지정 Log file 경로 -lv 백업 레벨 백업 레벨(0,1,2) -r 백업 후 기존 로그 삭제 수행 않음 디렉토리 경로명 또는 장치명 (-l): 이 옵션은 백업이 쓰여질 디렉토리의 이름 또는 장치명을 명세한다. 만일 백업 위치 아규먼트가 생략되면, 시스템은 sqlx.init 파일에 명세된 log_path 위치를 사용한다. 이 디폴트의 예외는 createdb를 사용하여 데이터베이스 생성시에 다른 경로명을 명세했을 때 만들어진다(더 자세한 정보를 위하여 “데이터베이스 생성” 과 “데이터베이스 복사와 이동”을 보라).   아카이브 로그의 삭제 (-r): 데이터베이스를 복구하기 위해 더 이상 필요되지 않는 아카이브 로그 파일들은 이 옵션을 명세하여 제거될 수 있다. 만일 당신이 아카이브 로그들을 제거하기로 결정하고 현재 백업 파일들이 UniSQL/X의 제어에서 벗어난 환경 때문에 잘못되었다면(즉 백업이 거주하는 곳의 디스크 고장), 당신은 예전 백업으로부터 데이터베이스를 복구할 수 없을 수 있다. 그런고로, 당신은 아카이브 로그들을 제거할 것인지를 결정할 때 주의해야 한다. 우리는 그들을 제거하기 전에 아카이브 로그들을 테이프에 복사할 것을 권고한다. 데이터베이스 백업들과 아카이브 로그들에 관한 정보는 이전에 기술된 정보 로그에 기록된다. 한국컴퓨터통신㈜

데이터베이스 복구 방법 내용 UniSQL 운영 및 튜닝 restoredb [options] source_database backupdb 수행된 상황에서 데이터베이스를 복구 복구 시점 지정 시 dd-mm-yyyy:hh:mm:ss 옵션 인자 설명 기본값 -lv 복구 레벨 복구 레벨 지정(0, 1, 2) -d 복구 시점 복구 시점 지정 가장 최근 시점 restoredb 유틸리티는 백업이 취해진 이후에 만일 필요하다면 모든 아카이브/액티브 로그들에 기록된 정보들을 사용하여 데이터베이스의 백업으로부터 데이터베이스를 복구한다. 만일 필요로되는 백업들 또는 아카이브 로그들이 기대되는 위치에서 실제로 찾아지지 않는다면, restoredb 명령은 이들 파일들을 위해 프롬프트를 줄 것이다. 점진적 백업으로부터의 회복은 취해진 가장 높은 백업 레벨로부터 시작할 것이다. 복구 일 (-d). 이 옵션은 주어진 시간 까지 존재했던 조건으로 데이터베이스를 복구하기 위해 주어질 수 있다. 당신은 dd-mm-yyyy:hh:mm:ss 로 시간을 명세해야 한다. 예를 들어, 31-12-1994:17:30:10. 만일 당신이 시간을 명세하지 않는다면, 모든 아카이브와 액티브 로그들이 마지막 백업으로부터 마지막 commit된 트랜잭션까지 적용된다. 만일 당신이 –d 옵션에 대해 시간을 명세하지 않으면, UniSQL/X는 마지막 백업으로부터 주어진 시간까지 모든 commit된 변경들을 적용한다. 그 시간 간격 동안 데이터베이스에 commit되지 않은 오브젝트들은 복구될 수 없다. 한국컴퓨터통신㈜

데이터베이스 복구(계속) 예제 UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ stop_server demodb backupdb -sa -l /home/backup -lv 0 demodb start_server demodb backupdb -cs -l /home/backup -lv 1 demodb (on-line 으로 full backup이후 수정된 데이터를 백업한 file을 /home/backup에 저장시킴) backupdb -cs -l /home/backup -lv 1 demodb (이전과 같은 작업을 수행하며 이전의 백업화일을 삭제하고 새로 파일을 저장함) (1997/12/07 15:00:00) 한국컴퓨터통신㈜

restoredb -lv 1 -d 07/12/1997:15:25:00 demodb UniSQL 운영 및 튜닝 데이터베이스 복구(계속) 예제(계속) 시스템 장애발생 15:30:00 restoredb -lv 0 demodb (일단 full 백업받은 데이터를 복구) restoredb -lv 1 -d 07/12/1997:15:25:00 demodb (1레벨 백업을 이용하여 15:25분 상태의 demodb로 복구완료) 한국컴퓨터통신㈜

연습문제 3-2 3-1에서 생성한 데이터베이스를 full backup하시오 UniSQL 운영 및 튜닝 연습문제 3-2 3-1에서 생성한 데이터베이스를 full backup하시오 데이터베이스를 강제로 손상시키시오.(rm testdb) 데이터베이스를 복구하시오. 한국컴퓨터통신㈜

데이터베이스 재구축 필요 UniSQL 운영 및 튜닝 현재 운영하고 있는 시스템을 교체할 경우 DBMS를 업그레이드할 경우 최적의 상황으로 볼륨을 재구성하고 싶은 경우 백업 또는 기타 용도로 현재 DB를 파일로 받고 싶은 경우 현재 DB 내에 불안정한 상태가 있는 경우 garbage를 없애 최적의 상황으로 재구성하고 싶은 경우 한국컴퓨터통신㈜

데이터베이스 재구축(계속) 데이터베이스를 파일로 만들기 UniSQL 운영 및 튜닝 데이터베이스 재구축(계속) 데이터베이스를 파일로 만들기 방법 unloaddb [options] database_name 내용 stand-alone 상태에서만 가능 기존의 데이터베이스에는 아무런 영향 없음 다음과 같은 파일 생성 database_schema, database_objects, database_indexes, ***.lo OID 연결을 위한 해쉬 파일 생성 기본으로 /temp 사용, 다른 경로 지정 권고 unloaddb 유틸리티는 데이터베이스를 압축하거나 존재하는 데이터베이스를 UniSQL/X 시스템 소프트웨어의 새로운 버전으로 이주시킬 때 loaddb 유틸리티와 함께 사용된다. 달리 표현하면, unloaddb와 loaddb 유틸리티들은 한 버전에서 다른 버전으로 데이터베이스를 다시 로드하기 위해 함께 사용될 수 있다. 스키마 파일(*_schema): 데이터베이스의 스키마 정의를 담는다. 이것은 앞의 예에서 testdb_schema로 보여주듯이 _schema 앞에 데이터베이스 이름이 붙여져 생성된다. 오브젝트 파일(*_objects): 데이터베이스에 담겨진 오브젝트들(인스턴스들)을 담는다. 이것은 앞의 예에서 testdb_objects로 보여주듯이 _objects 앞에 데이터베이스의 이름이 붙여져 생성된다. 인덱스 파일(*_indexes): 데이터베이스에 정의된 인덱스들을 담는다. 인덱스 파일 이름은 _indexes 앞에 데이터베이스의 이름이 붙여져 형성된다. GLO들은 스키마, 오브젝트, 인덱스 파일과 같은 디렉토리에 언로드된다. loaddb가 나중에 그 오브젝트 파일을 로드하기 위해 호출될 때, 이들 오브젝트들은 오브젝트 파일들과 같은 디렉토리에서 찾아지고 데이터베이스에 올바로 로드될 것이다. 한국컴퓨터통신㈜

-i 옵션에서 지정한 클래스의 인스턴스가 참조하는 인스턴스를 함께 unload UniSQL 운영 및 튜닝 데이터베이스 재구축(계속) unloadb options 옵션 인자 설명 기본값 -i input_file unload 하고자 하는 클래스 지정 없음(모든 클래스) -ir -i 옵션에서 지정한 클래스의 인스턴스가 참조하는 인스턴스를 함께 unload 실행 않음 -e estimated-size unloadb 받을 인스턴스 수 연산에 의해 -n num_cached_page 메모리에 저장할 객체 테이블의 페이지수 100 -od output-path 파일을 출력한 경로 지정 현재 디렉토리 -so 스키마만 unload -oo 데이터만 unload -f hash-filename 해쉬 파일 이름 시스템 생성 % unloaddb –v demodb Demodb 데이터베이스를 unloaddb utility를 사용하여 텍스트 파일 형태로 내린다. 한국컴퓨터통신㈜

데이터베이스 재구축(계속) unloaddb 파일 형태 @target_class_id|attribute_number UniSQL 운영 및 튜닝 데이터베이스 재구축(계속) unloaddb 파일 형태 OID 표현 %id class_name class_id %class class_name (attr_1, …, attr_N) 1: value_1 … value_N 2: value_1 … value_N @target_class_id|attribute_number sqlx> select id, name from ioo sqlx> ;x id name =================================== 5 'choi ' 4 'cho ' 3 'park ' 2 'lee ' 1 'kim ' [hanla:/user2/users/wschoi/edu] cat demodb_objects %class ioo (id name) 1: 5 'choi ' 2: 4 'cho ' 3: 3 'park ' 4: 2 'lee ' 5: 1 'kim ' 한국컴퓨터통신㈜

데이터베이스 재구축(계속) 텍스트 데이터를 데이터베이스로 로드 UniSQL 운영 및 튜닝 loaddb loaddb [options] db_name object_file stand-alone 상태에서 dba user만 가능 loaddb 유틸리티는 대량의 데이터를 가지고 데이터베이스에 거주시키기 위한 빠르고 쉬운 방법을 제공한다. loaddb는 워크스페이스에 새로운 인스턴스들을 로드하는 오버헤드 없이 데이터베이스에 직접 인스턴스들을 생성한다. loaddb에 대한 입력 파일 포맷은 단순 태뷸러(tabular) 포맷을 따른다. 이것은 전통적 관계형 데이터베이스로부터 거대한 데이터의 양을 끌어올 때 효과적인 수단이다. loaddb를 수행할 때, 스탠드얼론 모드에서 UniSQL/X를 수행시켜야 한다. 한국컴퓨터통신㈜

데이터베이스 재구축(계속) loaddb options UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ 옵션 인자 설명 기본값 -u user_name 데이터베이스 사용자(dba) public -p password 사용자의 패스워드 -e estimated_size load할 인스턴스 수(해쉬 테이블 크기) 5000 -no NULL 처리 수행 않음 -s|-l -s:문법만 검사, -l:데이터만 로드 둘 다 수행 -v 실행 과정 출력 수행 않음 -c commit 주기 주어진 값만큼 중간 commit 수행 수행 않음 -vc -c와 함께 사용되면 commit된 수 출력 수행 않음 -ns 통계 정보를 만들지 않음 통계 반영 -nl 로그 만들지 않음 로그 만듬 % loaddb –u dba –nl –l –v testdb demodb_objects Unloaddb를 통해 생성된 demodb_objects 파일을 사용하여 testdb라는 데이터베이스에 데이터를 로드한다. 위 작업은 dba 사용자의 권한으로 생성하고 로그를 생성하지 않으며(-nl), 문법검사를 하지 않는다(-l). 한국컴퓨터통신㈜

데이터베이스 재구축(계속) 예제 UniSQL 운영 및 튜닝 운영 중인 demodb를 이용하여 testdb 작성 각 볼륨의 위치 및 크기 초기 볼륨 : /home/DB, 2000 페이지 데이터 볼륨 : /home/DB, 10000 페이지 인덱스 볼륨 : /home/INDEX, 3000 페이지 temp 볼륨 : /home/TEMP, 5000 페이지 로그 볼륨 : /home/LOG, 4000 페이지 한국컴퓨터통신㈜

데이터베이스 재구축(계속) 작업 순서 UniSQL 운영 및 튜닝 1. deletedb 이용 기존 데이터베이스 삭제 2. createdb 이용 데이터베이스 생성 3. addvoldb 이용 용도별 데이터베이스 볼륨 생성 4. 스키마 입력 sqlx -sa -u dba -i dbname_schema dbname 5. loaddb 이용 데이터 입력 6. 인덱스 생성 한국컴퓨터통신㈜

데이터베이스 재구축(계속) 예제(계속) UniSQL 운영 및 튜닝 1 단계 : 파일 생성 unloaddb -f /user1/temp/hash.data -v demodb 2 단계 : 볼륨 생성 createdb -p 2000 -f /home/DB -l /home/LOG -lp 4000 testdb addvoldb -sa -pu data -f /home/DB testdb 10000 addvoldb -sa -pu index -f /home/INDEX testdb 3000 addvoldb -sa -pu temp -f /home/TEMP testdb 5000 한국컴퓨터통신㈜

데이터베이스 재구축(계속) 예제(계속) UniSQL 운영 및 튜닝 3 단계 : 스키마 입력 sqlx -sa -u dba -i demodb_schema testdb 4 단계 : 데이터 로드 loaddb -u dba -nl -l -ns -c 1000 -v -vc -e 100000 testdb demodb_objects optimizedb -v testdb 5 단계 : 인덱스 생성 sqlx -sa -i demodb_indexes testdb 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 연습 문제 3-3 Unloaddb 유틸리티를 사용하여 testdb_objects, test_schema, test_indexes 파일을 생성하고 그 내용을 확인하시오. Deletedb 유틸리티를 사용하여 기존의 testdb를 삭제하고 testdb 구조와 동일한 구조의 targetdb를 생성하시오 Sqlx와 loaddb 유틸리티를 사용하여 testdb에 생성된 모든 정보(스키마, 데이터, 인덱스)를 targetdb에 입력하시오 한국컴퓨터통신㈜

사용자 관리 사용자 관리: 데이터 및 스키마의 접근 제한 UniSQL 운영 및 튜닝 기본 단위는 클래스 사용자와 그룹을 통하여 접근 관리 시스템에서 제공하는 db_user 클래스를 통하여 관리 시스템에서 제공하는 기본 사용자 DBA 모든 그룹의 멤버 데이터베이스의 모든 객체 접근 가능 PUBLIC 모든 사용자는 PUBLIC 사용자의 멤버 인증의 기본 단위는 클래스이다. 각 데이터베이스 사용자는 데이터베이스에 있는 db_user 클래스의 한 인스턴스에 의해 표현된다. 이 db_user 인스턴스는 접근하는 각 클래스에 대한 사용자의 권한을 유지한다. 그 클래스에 대한 인증은 GRANT 문장을 사용하여 달성된다. 오직 DBA나 주인(owner)만이 주어진 클래스에 대한 권한을 양도할 수 있다. 한 클래스에 대한 인증은 단일 사용자나 사용자의 리스트(이것은 그룹으로 언급됨)에 양도될 수 있다. 권한이 한 그룹에 양도될 때, 그 그룹의 모든 멤버들은 같은 권한을 받는다. 모든 새로운 사용자는 PUBLIC 그룹의 멤버이다. DBA는 모든 그룹의 멤버이고 데이터베이스에 있는 모든 오브젝트에 접근할 수 있다. DBA를 포함하여 모든 사용자들은 PUBLIC 그룹의 멤버들이다. 한국컴퓨터통신㈜

사용자 관리(계속) 사용자 추가 UniSQL 운영 및 튜닝 ‘add_user’ 메소드 사용 dba 와 dba의 멤버만이 사용 가능 ‘add_user’ 메소드의 인자는 사용자 이름과 패스워드 패스워드가 명시되지 않으면 패스워드는 blank 예제 CALL add_user(‘홍길동’,’허균00’) ON CLASS db_user; 사용자ID 패스워드 add_user() 메소드는 데이터베이스가 살아있는 동안 사용자를 추가하기 위해 사용된다. 이것은 db_user 클래스 메소드이다. 이것은 두 아규먼트들을 취한다: name과 password. 이 모두는 스트링으로서 메소드에 전달된다. name 아규먼트가 요구되고 유일해야 한다. 만일 password가 명세된 사용자에 요구되지 않는다면, 빈 스트링 ‘’가 두 번째 파라미터로서 사용된다. 새로운 사용자는 자동적으로 PUBLIC 그룹에 추가된다. <Class Name> db_user <Attributes> name : character varying(1073741823) id : integer password : db_password direct_groups : set_of(db_user) groups : set_of(db_user) authorization : db_authorization triggers : sequence_of(object) <Constraints> INDEX(name) 한국컴퓨터통신㈜

사용자 관리(계속) 사용자 삭제 UniSQL 운영 및 튜닝 ‘drop_user’ 메소드 사용 dba 와 dba의 멤버만이 사용 가능 ‘drop_user’ 메소드의 인자는 사용자 이름 삭제된 클래스의 소유자는 자동적으로 DBA가 됨 예제 CALL drop_user(‘홍길동’) ON CLASS db_user; db_user 클래스는 DBA에 의해 소유된다. db_user 클래스의 drop_user() 메소드는 오직 DBA 그룹의 DBA 사용자에 의해서만 호출될 수 있다. db_user() 메소드는 아규먼트로서 사용자 이름을 취한다. <Methods> set_password() function au_set_password_method set_password_encoded() function au_set_password_encoded_method add_member() function au_add_member_method drop_member() function au_drop_member_method print_authorizations() function au_describe_user_method <Class Methods> add_user() function au_add_user_method drop_user() function au_drop_user_method find_user() character varying(1073741823) function au_find_user_method login() function au_login_method 한국컴퓨터통신㈜

사용자 관리(계속) 그룹과 멤버 UniSQL 운영 및 튜닝 그룹과 사용자는 같은 객체이며, 멤버를 같은 사용자가 그룹임 그룹의 생성과 삭제는 사용자와 같은 메소드 사용 그룹에 멤버를 추가하는 메소드는 ‘add_member’ 예 call add_user(‘개발부’,’000’) on class db_user to :grp; call add_user(‘홍길동’, ‘abc’) on class db_user to :user1; call add_user(‘임꺽정’, ’def’) on class db_user to :user2; call add_member(:user1) on :grp; call add_member(:user2) on :grp; 사용자들, 그룹들이 add_user() 메소드 호출을 사용하거나 데이터베이스 사용자 정의 파일을 사용하여 생성할 때 추가될 수 있다. 일반 접근 권한들을 만들기 위해 DBA는 그룹들을 만든다. 모든 사용자는 거기에 멤버들을 추가하여 단순히 그룹이 될 수 있다. 번역기 변수들은 add_member() 메소드에 포함을 위해 리턴 OID를 유지하기 위해 사용될 수 있다. 한국컴퓨터통신㈜

사용자 관리(계속) 멤버의 삭제 UniSQL 운영 및 튜닝 그룹에 멤버를 삭제하는 메소드는 ‘drop_member’ 예 call find_user(‘개발부’) on class db_user to :grp; call drop_member(‘홍길동) on :grp; drop_member()라는 db_user 인스턴스 메소드는 그룹으로부터 멤버를 삭제하기 위하여 사용된다. 당신은 DBA나 DBA 그룹의 멤버로서 또는 제거될 멤버로부터의 그룹으로서 데이터베이스에 로그인 해야 한다. 한국컴퓨터통신㈜

사용자 관리(계속) 권한 부여 UniSQL 운영 및 튜닝 임의의 클래스에 대하여 특정 사용자에게 권한 부여 가능 권한 부여 가능자: 클래스의 소유자, DBA, 권한을 가진 그룹의 멤버 권한 부여 예 GRANT select ON employee TO 홍길동 GRANT all privileges ON employee TO 홍길동 with grant option; 권한 삭제 예 REVOKE select ON employee FROM 홍길동 현재의 사용자들에게 부여된 권한을 모두 검색하는 방법 call print_authorizations() on class db_authorizations; 일부 또는 전체 권한들이 클래스 단위로 클래스 상에 사용자(또는 그룹)에 양도(GRANT)될 수 있다. 일부 또는 전체 권한들을 양도하는 권한은 사용자에게 또한 클래스 단위로 클래스 상에 사용자(또는 그룹)에게 양도될 수 있다. 클래스의 주인, DBA 또는 권한을 양도 받은 모든 사용자(또는 그룹의 멤버)가 클래스에 대해 권한을 양도할 수 있다. 권한이 사용자나 그룹에 양도될 때, 권한 애트리뷰트가 갱신된다. 클래스에 권한들의 양도자와 DBA는 언제든지 이 권한들을 취소할 수 있다. 사용자로부터 제거된 권한들은 이 사용자에 의해 권한이 양도된 모든 사용자로부터 제거될 것이다. 한국컴퓨터통신㈜

모니터링 데이터베이스 서버 관리 UniSQL 운영 및 튜닝 commdb 마스터에 대한 명령 데이터베이스 서버 리스트 출력, 서버 및 마스터 종료 options -Q : quit -P : print -S : shutdown one server -A : shutdown master and all servers -H : halt shutdown -I : immediate server shutdown commdb 유틸리티는 마스터 디몬과 서버 프로그램들에 관한 상태 정보를 표준 출력으로 출력한다. 이것은 또한 사용자가 특정 서버를 셧다운하거나 마스터 디몬을 셧다운하거나 현재 수행중인 모든 서버들을 셧다운하는 방법을 제공한다. 셧다운 프로세스는 즉각 개시되거나 명세된 분의 수에 의해 지연될 수 있다. 셧다운 요구가 지연될 때, 사용자는 셧다운 타임이 만료되기 전에 셧다운을 중단시킬 수 있다. 한국컴퓨터통신㈜

모니터링(계속) 클라이언트 상태 관리 UniSQL 운영 및 튜닝 방법 killtran [options] database 기능 서버에 접속한 클라이언트에 대해 다음의 정보 접속한 클라이언트의 호스트 명 사용자 ID PID 프로그램 이름 특정 클라이언트 종료 기능 killtran 유틸리티는 외부 일반 실행 환경으로부터 액티브 트랜잭션을 일방적으로 중단하기 위해 사용한다. killtran 유틸리티는 클라이언트/서버 모드에서만 사용될 수 있다. 그 트랜잭션은 서버로부터 제거된다. 클라이언트 프로세스는 제거되지 않는다. 그러나, 클라이언트가 서버에 연결을 시도한 다음에, 클라이언트는 그것의 트랜잭션이 일방적으로 중단되었음을 인지 받는다. 이 유틸리티는 데이터베이스의 DBA에 의해서만 오직 사용될 수 있다. 한국컴퓨터통신㈜

‘client-host’로 부터의 모든 연결 해제 UniSQL 운영 및 튜닝 모니터링(계속) 클라이언트 상태 관리(계속) killtran options 옵션 인자 설명 기본값 -t tran-index tran_index의 트랜잭션을 삭제 수행 않음 -u user ‘user’의 모든 연결 해제 수행 않음 -h client-host ‘client-host’로 부터의 모든 연결 해제 수행 않음 -pg pgm-name ‘pgm-name’인 모든 연결 해제 수행 않음 -p DBA password DBA password 옵션 없음 접속 상태 출력 % killtran demodb Tran index User name Host name Process id Program name --------------------------------------------------------------------------------------- 4 uniweb host1 637 uts 5 vision3 host1 839 usqlx_cs % killtran -t 4 demodb ( 4번 트랜잭션 강제 종료 ) Ready to kill the following transactions: Tran index User name Host name Process id Program name ------------------------------------------------------------------------------- 2 wschoi hanla 15077 usqlx_cs Do you wish to proceed ? (Y/N)y Killing transaction associated with transaction index 2 한국컴퓨터통신㈜

모니터링(계속) 락킹 모니터링 UniSQL 운영 및 튜닝 방법 lockdb [-o output_file] database 내용 출력 내용은 6 개 부분으로 구별 서버 인자, 클라이언트 정보, 시스템 클래스, 사용자 정의 클래스, 인스턴스, 페이지 락킹 lockdb 유틸리티는 주어진 데이터베이스에 대한 락킹(locking) 액티비티의 현재 스냅샷(snapshot)을 제공한다. 그 데이터베이스에 현재 접근하고 있는 클라이언트 어플리케이션들 가운데 lock 충돌과 동시성 제어 문제를 식별하기 위해 사용될 수 있다. lockdb 유틸리티는 lock들을 기다리는 클라이언트들 뿐만 아니라 그 lock들을 갖고 있는 클라이언트들과 얻어진 lock들 모두의 출력된 요약을 제공한다. 한국컴퓨터통신㈜

Client의 isolation level UniSQL 운영 및 튜닝 모니터링(계속) 락킹 모니터링(계속) 부분 1 : 관련 서버 인자 값 부분 2 : 각 클라이언트의 상황 Lock Escalation at = 100, Run Deadlock interval = 30 프로그램 이름 머신의 이름(IP) 트랜재션 번호 사용포트 Transaction(index 1, usqlx_cs, opal@vision|10272) Isolation READ COMMITED CLASSES AND READ UNCOMMIT INSTANCES Timeout_period 30 Client의 isolation level 위 예에서, lock escalation 레벨은 100 인스턴스들로 설정되고 deadlock 검출 간격은 30 초로 설정된다. 위 예에서, 트랜잭션 인덱스는 1이고, 프로그램 이름은 usqlx_cs, 사용자는 opa,|, 호스트 머신은 vision, 클라이언트 프로세스 식별자는 10272 , isolation 레벨은 READ COMMITTED CLASSES AND READ UNCOMMITTED INSTANCES, 그리고 lock timeout 설정은 30초인 것을 알수 있다.. 한국컴퓨터통신㈜

모니터링(계속) 락킹 모니터링(계속) UniSQL 운영 및 튜닝 부분 3 : 시스템 클래스에 대한 정보 한국컴퓨터통신㈜ HTABLE NAME = Lock Object Table, NENTRIES = 9 OID = 0| 60| 1, Num granted = 2, Num_waiting = 0 Class = Rootclass. GRANTED : Tran_index = 1, Lock = IX_LOCK, Count = 0, Numsubgranules= 0 Tran_index = 2, Lock = IX_LOCK, Count = 0, Numsubgranules = 0 NON_2PL_RELEASED: Tran_index = 3, Lock = IS_LOCK lockdb 출력의 세 번째 섹션은 오브젝트 lock 테이블의 내용을 보여준다. 이것은 어느 클라이언트가 어떤 오브젝트들 상에 어떤 타입의 lock들을 갖고 있는지를 보여준다. 오브젝트 lock 테이블 출력의 시작에, 얼마나 많은 엔트리들(오브젝트들)이 lock되었는지에 관한 정보가 출력되고, 그 엔트리들이 출력된다. 한국컴퓨터통신㈜

모니터링(계속) 락킹 모니터링(계속) UniSQL 운영 및 튜닝 부분 4 : 사용자 정의 클래스에 대한 정보 부분 5 페이지 락킹에 관한 정보 페이지 락킹은 매우 드물게 발생 트랜잭션 1과 2가 동시에 foo 클래스에 대해 IX 클래스 락을 가지고 있는 상태 OID = 0 | 64| 1, Num granted = 2, Num_waiting = 0 Class = foo. GRANTED : Tran_index = 1, Lock = IX_LOCK, Count = 0, Nsubgranules = 0 Tran_index = 2, Lock = IX_LOCK, Count = 2, Nsubgranules = 2 HTABLE NAME = Lock Page Table, NENTRIES = 0 lock들을 갖고 있는 클라이언트 트랜잭션의 리스트가 출력된다. 트랜잭션은 트랜잭션 인덱스에 의해 식별된다. 만일 더 많은 정보가 그 트랜잭션을 식별하기 위해 필요된다면, 그 출력의 클라이언트 정보 섹션의 트랜잭션 인덱스를 크로스-참조하라. 다음 예에서, 트랜잭션 1과 2는 클래스 foo 상에 IX_LOCK을 갖는다. 유사하게, 페이지 Lock Table은 페이지들 상에 lock을 현재 갖고 있는 그리고 페이지 상에 lock을 기다리는 클라이언트 트랜잭션들을 보여준다. 각 페이지에 대해 보여지는 lock 정보는 오브젝트들에 대해 보여지는 것과 거의 동일하다. 오직 차이는 OID와 클래스 이름을 보여주는 대신에, 출력이 Vol_Page로서 lock된 페이지를 식별한다. 한국컴퓨터통신㈜

모니터링(계속) 락킹 모니터링(계속) UniSQL 운영 및 튜닝 부분 6 : 인스턴스에 대한 락킹 정보 한국컴퓨터통신㈜ 트랜잭션 2가 foo 클래스의 한 인스턴스에 대한 X-lock을 가지고 있는 상태에서 트랜잭션 1이 X-lock을 요청하였으나 락을 부여받지 못하고 대기하고 있는 상태 OID = 0| 240| 1, Num granted = 1, Num waiting = 1 Instance of class = foo. GRANTED : Tran_index = 2, Lock = X_LOCK, Count = 2 WAITING: Tran_index = 1, Lock = X_LOCK, Start_waiting_at = Tue May 13 18:09:23 1997 Wait_for_nsecs = 30, Num_waiting_for = 1, Waiting_for_trans = 2 OID = 0| 240| 4, Num granted = 1, Num waiting = 0 트랜잭션 1는 클래스 foo 상에 X_LOCK을 기다리고 있다. 그 트랜잭션은 트랜잭션 2의 X_LOCK의 해제를 기다리고 있다. 트랜잭션 1은 특정 시간에 lock을 기다리고 있다. 시간을 재는 트랜잭션은 lock_timeout_in_secs 시스템 파라미터에 의해 명세된 시간 동안만 lock을 기다린다. 한국컴퓨터통신㈜

데이터베이스 통계 정보 수정 방법 내용 UniSQL 운영 및 튜닝 optimizedb [-c class_name | -o output_file] database 내용 stand-alone 상태에서 수행 가능 통계 정보는 효율적인 ‘질의 처리 방안’을 수립하는데 매우 중요 주기적으로 실행 UniSQL/X는 질의 실행 계획을 생성하기 위해 질의 최적기를 사용한다. 질의 최적기는 클래스에 있는 오브젝트들의 수, 접근하는 페이지들의 수, 애트리뷰트 값들의 분산 같은 통계적 정보를 사용한다(예: 애트리뷰트들의 최소/최대 값). 클래스(또는 데이터베이스)가 광범위하게 수정되었을 때, 당신은 질의 프로세스를 최적화하기 위해 optimizedb 유틸리티를 사용할 수 있다. 한국컴퓨터통신㈜

삭제된 객체 정보 처리 방법 내용 UniSQL 운영 및 튜닝 compactdb [-v] database 삭제된 객체 정보(OID) 정리 가용 공간 확보 OID 값 변경 가능 오브젝트가 삭제되면, 그 오브젝트에 대한 OID(그리고 그 heap 파일에 있는 관련된 슬롯)는 즉시 매립될 수 없다. 왜냐하면 거기에 삭제된 오브젝트들을 참조하는 다른 존재하는 오브젝트들이 있을 수 있기 때문이다. 압축동안 이들 참조가 발견될 것이고 null로 되는데, 이것은 OID가 재사용을 위해 매립되는 것을 허용할 것이다. 인스턴스들을 이미 가지는 클래스가 변경될 때, UniSQL/X는 스키마 변경을 반영하기 위해 존재하는 모든 인스턴스들을 즉시 수정하지 않는다. 인스턴스들은 그들이 수정될 때 현재 스키마 레벨 까지 도달된다. 이 메소드는 그 클래스가 현재 스키마 표현들 뿐만 아니라 예전 스키마 표현들을 담는 것을 요구한다. 압축 후에, 클래스에 있는 모든 인스턴스들은 현재 스키마 표현까지 도달되고, 부가적 스키마 표현들은 삭제된다. 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 연습 문제 3-4 Sqlx를 사용하여 임의의 인스턴스를 update 하고 commit 하기전에 lockdb를 사용하여 현재 데이터베이스의 lock를 확인하시오. Killtran을 사용하여 앞에서 갱신을 시도한 클라이언트를 kill 하시오. 개발부와 관리부라는 그룹을 생성하시오. 개발부에 홍길동, 임꺽정 멤버를 추가하고 관리부에는 이몽룡, 성춘향, 변학도를 추가하시오. 임꺽정 사용자를 삭제하시오. 홍길동 사용자로 데이터베이스에 접근하여 person(id, name) 클래스를 생성하고 인스턴스를 입력한 후 성춘향에게 검색 권한을 이몽룡에게는 모든 권한을 부여하시오. 이몽룡으로 부터 person 클래스에 대한 update 권한을 삭제하시오. Print_authorizations() 메소드를 사용하여 이몽룡의 권한 사항을 검색하시오. Sqlx> select * from db_user name id password direct_groups groups authorization triggers ======================================================================== 'DBA' NULL NULL {} {} db_authorization NULL 'PUBLIC' NULL NULL {} {} db_authorization NULL '개발부' NULL db_password {db_user} {db_user} db_authorization NULL '겨리부' NULL db_password {db_user} {db_user} db_authorization NULL '홍궉동' NULL db_password {db_user, db_user} {db_user, db_user} db_authorization NULL '임꺽정' NULL db_password {db_user, db_user} {db_user, db_user} db_authorization NULL '이멉렵' NULL db_password {db_user, db_user} {db_user, db_user} db_authorization NULL '성쳅픈' NULL db_password {db_user, db_user} {db_user, db_user} db_authorization NULL '변학도' NULL db_password {db_user, db_user} {db_user, db_user} db_authorization NULL 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 CHAPTER 4. 튜닝 한국컴퓨터통신㈜

성능에 영향을 미치는 사항 분석 설계 구현 데이터베이스 환경 설정 하드웨어 UniSQL 운영 및 튜닝 비즈니스 로직 질의 부적절 자원할당 시스템을 가동한 후 원하는 성능이 나오지 않을 경우에 관리자는 어디에서 부터 원인을 파악할지 막막할 수 있다. 원인을 분석하기 위해서는 많은 기초 데이터와 현재의 상태에 대한 자세한 정보를 알고 있어야 빠르게 성능 향상을 할 수 있다. 튜닝을 위한 정보들은 다음과 같다. 클래스 다이아그램 각 클래스의 인스턴스의 수와 크기 데이터베이스의 볼륨의 상태 Active 사용자 수 응용프로그램이 수행하는 질의문 클라이언트 코드와 서버상의 코드 한국컴퓨터통신㈜

튜닝 시스템 튜닝 데이터베이스 튜닝 프로그램 튜닝 질의 튜닝 UniSQL 운영 및 튜닝 볼륨 관리, 인자 설정 불필요하거나 반복적인 부분 제거 질의 튜닝 인덱스 처리 유도 및 여러 테크닉 개발 단계부터 적용하도록 유도 튜닝 단계는 개발 중이거나 완료되어 사용중인 시스템의 성능을 높이는 단계이다. 이 단계에서 필수적인 사항은 실제 운영하고자 하는 시스템 환경이 구축되어 있어야 한다는 것이다. 시스템 테스트 단계에서 나쁘지 않은 성능을 보였다고 해서 실 운영 환경에서 이와 같은 성능을 보장하는 것은 아니기 때문이다. 튜닝에 들어가기에 앞서 이러한 실 운영 환경 하에서의 다양한 테스트 결과를 확보해두어야 한다. 다양한 시스템 테스트 결과를 이용하여 실제 튜닝 대상을 추출할 수 있으며, 튜닝 시에 비교 수치로 활용할 수 있다. 대부분의 경우에 성능 문제는 어떠한 하나의 문제에 의해서 발생되기 보다는 하드웨어, 운영 체제, 데이터베이스 구성, 프로그램 구조, 질의 형태 등과 같은 요소에 의해 복합적으로 발생되는 경우가 많으며, 이러한 요인 가운데 가장 큰 원인은 시스템 설계 상의 오류이다. 한국컴퓨터통신㈜

데이터베이스 볼륨 관리 볼륨의 적절한 분산 배치 UniSQL 운영 및 튜닝 디스크 병목 현상 회피 및 관리 편이 도모 용도별 분산 배치 generic, data, index, temp, log 동시에 사용될 가능성이 있는 볼륨은 분산 예) data & log, data & index, data & temp RAID 디스크 UniSQL/X의 사용자 정의 및 확장 볼륨에는 generic, data, index, temp 볼륨과 같은 네 가지 종류가 있다. 이들은 용도에 따라서 분류되며, 실 운영 데이터베이스의 경우에 각각의 볼륨을 적절히 나누어 구성해주는 것이 좋으며, 가능하다면 물리적인 디스크의 구성을 고려하여 배치하는 것이 좋다. SCSI 디스크를 사용하고 있을 경우에는 물리적으로 분리되어 있는 SCSI 컨트롤러가 관장하는 디스크를 각각의 데이터베이스 볼륨으로 이용하면 디스크 컨트롤러에 부과되는 입출력 요구를 분산화 할 수 있게 되어 디스크 병목 현상을 줄일 수 있다. 하지만, RAID 디스크를 사용하고 있다면 RAID 디스크의 특성상 이 사항은 별 의미가 없게 된다. 그러나, 각각의 볼륨을 서로 다른 디스크에 할당하기 어려운 경우에는 동시에 사용되지 않는 볼륨들을 하나의 디스크에 할당하는 정책이 필요하다. 예를 들어, 로그 볼륨과 데이터 볼륨을 서로 분리하거나, 인덱스와 데이터를 분리하는 것과 같은 방법을 사용할 수 있다. 한국컴퓨터통신㈜

데이터베이스 볼륨 관리 / UniSQL 운영 및 튜닝 database1 database2 database3 kcomdb kcomdb_log kcomdb_temp kcomdb_data kcomdb_index kcomdb_backup 위에 나타낸 그림에서는 세 개의 물리적으로 다른 디스크가 존재하는 경우를 가정하였다. 이 경우에 최소한 서로 다른 6개의 디렉토리가 필요함을 알 수 있다. 이를 하나씩 살펴보면, 데이터베이스의 헤드 페이지가 존재하는 디렉토리(/database1/db), 로그 디렉토리(/database1/log), temp 볼륨을 위한 디렉토리(/database1/temp), data 볼륨을 위한 디렉토리(/database2/data), index 볼륨을 위한 디렉토리(/database3/index), 백업 파일을 저장하기 위한 디렉토리(/databse3/backup)와 같다. 여기서는 가급적 디스크 입출력 요구를 최소화하기 위하여 각 디렉토리를 서로 다른 파일 시스템에 배치하였다. 한국컴퓨터통신㈜

볼륨 크기 서비스 중 볼륨 확장 일어나지 않도록 구성 UniSQL 운영 및 튜닝 generic : 대략 5000 페이지 정도(4K 단위) data, index : 각각이 너무 크거나 작지 않도록 산출 공식 또는 estimatedb_data, estimatedb_index 이용 temp temporary temp vs. permanent temp 일괄 처리 프로그램(on-line vs. off-line) 급격한 성능 저하 요인 성능 vs. 관리 및 자원(backup) 데이터베이스 구성 시에 고려해야 할 또 하나의 사항은 각 데이터베이스 볼륨의 크기이다. 데이터베이스 볼륨의 크기는 DBA가 적절한 수치를 찾아내어 구성해야 하며, 시스템 운영 중에는 주기적으로 볼륨의 크기를 모니터링하여 필요 시에는 재조정해야 한다. 볼륨의 크기는 너무 커서도 작아서도 안 된다. 현재 상황에 적합한 볼륨 크기를 유지해주는 것이 필요하며, DBA는 볼륨 크기에 항상 관심을 가져야 한다. 이제 각각의 볼륨 크기를 산출하는 방법에 대해서 알아보자. 먼저, 데이터베이스의 스키마 및 컨트롤 정보가 저장되는 generic 볼륨에 대해서 알아보면, 물론 이 사항은 클래스의 개수 및 복잡도에 좌우되기는 하지만, 경험적으로 보아 5,000 페이지 정도면 적당하다. (단, 이 사항은 페이지의 크기가 4K라고 가정한 경우에 해당한다) 이 볼륨은 데이터베이스를 생성하여 스키마를 입력했을 때 사용되는 스페이스를 제외하면 크게 늘어나지 않기 때문에 그리 크게 잡아줄 필요는 없다. 한국컴퓨터통신㈜

볼륨 크기(계속) 로그 UniSQL 운영 및 튜닝 현재 로그(active log), 기존 로그(archive log) 현재 로그는 circular queue 방식으로 사용 현재 로그가 fill up되면 새로이 로그 볼륨을 생성 로그 확장으로 인한 응답 시간 불규칙 가능성 로그 볼륨의 크기 media_failures_are_supported [0|1] 백업 정책 권장 사항 media_failures_are_supported = 1 백업 시에 더 이상 필요 없는 기존 로그 삭제 기능 (-r) 다음 백업 주기까지 새로운 기존 로그의 생성 없도록 적절한 크기 할당 지속적인 모니터링 필요 DBA가 할당한 temp 볼륨의 양이 작을 경우(즉, 현재 처리 중인 질의가 요구하는 양 보다 남아 있는 양이 적은 경우)에는, 그 순간에 해당 페이지를 생성하게 된다. 이 경우에는 temp 볼륨의 부족 현상으로 인해 새로운 temp 볼륨 생성을 위한 디스크 입출력 요구로 인하여 거의 모든 클라이언트 요구가 처리되지 못한다. 이러한 문제를 피하기 위해서는 충분한 양의 스페이스를 미리 할당해 두는 것이 필요하다. 그러나, 여기서 한 가지 더 고려할 사항은 특정 일괄 처리 프로그램을 위해서 과도한 양의 temp 볼륨을 할당하는 것은 보다 많은 백업 처리 시간 및 백업 디바이스 양을 요구한다는 점이다. 이러한 경우라면, 특정 일괄 처리 프로그램을 야간(또는 비 업무 시간)에 off-line 상태로 수행시키는 방안을 검토해보는 것이 적절할 것이다. 로그 볼륨의 크기는 백업 정책과 연관되어 있다. 백업 시에는 현재 로그 내에 존재하는 이미 확인 또는 철회된 로그 레코드들은 삭제되고 이 레코드가 차지하고 있던 스페이스는 다시 사용될 수 있도록 로그가 재정리된다. 따라서, 가장 좋은 정책은 다음 백업 주기까지 로그가 확장되지 않도록 충분한 로그 페이지를 할당하여 사용하다가, 백업 시에 로그를 정리한 후 다시 재사용하는 것이다. 이를 위해서는 시스템을 어느 정도 운영한 후 모니터링하여 백업 주기 내에 몇 번이나 로그가 새로이 생성되는지 모니터링해야 한다. 또한, 백업 시에는 더 이상 필요 없는 기존 로그들을 삭제할 수 있는 옵션(-r)을 사용할 수 있는다. 한국컴퓨터통신㈜

질의 튜닝 필요성 방법 UniSQL 운영 및 튜닝 전체 성능을 가장 크게 좌우 SQL : 비절차식(nonprocedural) 언어 쉽지만 무절제하게 사용하는 경우가 많음 UniSQL은 가능한 모델과 질의가 매우 다양 방법 같은 결과를 도출하는 다양한 질의를 작성하여 가장 효과적인 질의를 채택 기계적인 작업 질의 튜닝은 데이터베이스 응용 프로그램 튜닝 작업의 핵심이라 할 수 있다. 우리가 사용하는 질의 언어는 SQL 이다. 잘 알려진 바대로 SQL은 비절차식(nonprocedural) 언어이다. 즉, 사용자는 원하는 값에 대한 사항만 명시할 뿐 이것을 가져오기 위한 방법에 대해서는 지정하지 않는다. 이러한 비절차식 언어의 특성으로 인하여 SQL은 초급자도 매우 쉽게 익히고 사용할 수 있다는 장점을 가지는 반면에 무절제한 방식으로 사용되는 경우도 많다. UniSQL은 다른 관계형 데이터베이스와는 달리 가능한 질의 형태가 훨씬 다양하기 때문에 이 부분에 대한 확실한 이해가 필요하다. 처음에 시작할 때는 여러 가지 가능한 질의를 만들어보고 이를 계량적으로 비교하여 선택하는 방법이 좋으며, 어느 정도 경험이 쌓이면 기계적으로 수행할 수 있을 것이다. 이를 위해서는 다양한 형태의 질의 문장을 다루어 보는 것이 최선의 방법이라 할 수 있다. 한국컴퓨터통신㈜

질의 튜닝 방법 인덱스 처리 유도 질의 횟수 줄이기 조건식 변경 스키마 변경 등 UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ 시스템의 환경은 사이트의 사정에 따라 모드 다르기 때문에 성능에 대한 요구 조건도 다르다. UniSQL DBMS는 사용자의 환경에 맞게 자신의 데이터베이스를 튜닝할 수 있는 많은 factor를 제공한다. 그러나 최상의 성능을 이끌어 낼 수 있는 특정한 법칙은 없다. 한국컴퓨터통신㈜

질의 처리 방안 질의 처리 방안은 트리 형태로 표현 pre-order로 검색한 결과 UniSQL 운영 및 튜닝 순차 처리(sequential scan) 인덱스 처리(index scan) 정렬(sort) 오브젝트 처리(object fetch) 루프 죠인(nested-loop join) 병합 죠인(merge join) pre-order로 검색한 결과 질의의 튜닝을 위해서는 해당 질의의 플랜을 알아보는 것이 급선무이다. 직관적인 형태의 접근 방법보다는 훨씬 객관적인 결과를 얻을 수 있으므로 이를 알아두는 것이 무엇보다도 필요하다. UniSQL/X에서는 질의 최적화기가 선택한 질의 처리 방안과 질의 처리에 사용된 자원의 양에 대한 통계 정보를 볼 수 있는 방법이 있다. 먼저 질의 처리 방법을 보기 위해서는 다음과 같이 수행하면 된다. % sqlx testdb sqlx>set optimization level 257 sqlx>;x sqlx>SELECT * FROM foo WHERE i = 1; Query plan: Index scan(foo, foo.i=1) 또는, 다음과 같이 UNISQLX_OPTIMIZATION_LEVEL이라는 shell 변수를 설정한 후에 sqlx 또는 프로그램을 수행시키면 질의 처리 방안을 볼 수 있다. 한국컴퓨터통신㈜

질의 처리 방안 해석(계속) 간단한 검색 UniSQL 운영 및 튜닝 SELECT country FROM resort WHERE name = ‘Seawind’; // resort.name에 인덱스가 없을 경우 Sequential scan(resort) // resort.name에 인덱스가 있을 경우 Index scan(resort, resort.name=‘Seawind’) 한국컴퓨터통신㈜

질의 처리 방안 해석(계속) 간단한 죠인 UniSQL 운영 및 튜닝 SELECT r.name FROM resort r, hotel h WHERE r.name = h.name; Nested-loop join(r.name = h.name) // case 1 Sequential scan(r) Sequential scan(h) Merge join(r.name = h.name) // case 2 한국컴퓨터통신㈜

질의 처리 방안 해석(계속) 간단한 죠인(계속) UniSQL 운영 및 튜닝 Nested loops // case 3 Sequential scan(r) Index scan(h, r.name=h.name) … where r.name = h.name and r.name =‘Seawind’ Nested loops // case 4 Index scan(r, r.name=‘Seawind’) 한국컴퓨터통신㈜

질의 처리 방안 해석(계속) path expression UniSQL 운영 및 튜닝 SELECT beach.description FROM resort Object fetch(resort.beach = seashore) sequential scan(resort) 한국컴퓨터통신㈜

질의 처리 방안 해석(계속) derived table UniSQL 운영 및 튜닝 SELECT resort.name, cabin.size_in_sq_ft FROM resort, TABLE(resort.cabins) AS dt(cabin) Object fetch(dt.cabin=cabin) Nested loops Sequential scan(resort) Sequential scan(dt) 한국컴퓨터통신㈜

질의 처리 정보 여러 질의 중 효율적인 것 선택하는 기준 UniSQL 운영 및 튜닝 질의 처리 정보 여러 질의 중 효율적인 것 선택하는 기준 ;.c(clear statistics) ;.x(print statistics) % sqlx testdb sqlx>;.c sqlx>SELECT * from foo WHERE id = 1; sqlx>;x // 질의 결과 sqlx>;.x // 질의 처리 통계 정보 위와 같이 두 가지의 새로운 명령어를 사용하였다. 먼저 사용한 명령어(;.c)는 현재까지의 통계 정보를 초기화시키는 것이고, 두번째 사용한 명령어(;.x)는 통계 정보를 출력한다. 이와 같이 통계 정보를 출력시키면 많은 정보가 출력되지만, 가장 중요한 정보는 서버가 질의를 처리하기 위해서 읽은 데이터 페이지 수(Num_data_page_fetches)이다. 이 정보는 같은 결과를 가져올 수 있는 두 개 이상의 질의 문장의 질의 처리 비용을 비교하는데 사용되는 정보이다. 즉, 이 값이 크면 클수록 절대적으로 읽어야 하는 페이지의 수가 많다는 의미가 되며, 따라서 적은 페이지를 읽는 질의 문장이 보다 효율적인 질의 문장에 해당한다. Histogram of client requests ……. Client Execution Statistics Server Execution Statistics Num_data_page_fetches = 90 Num_data_page_dirties = 29 Num_data_page_ioreads = 0 Num_data_page_iowrites = 0 한국컴퓨터통신㈜

인덱스 검색 조건에 해당하는 attribute 또는 path expression에 인덱스가 존재하면 이를 이용 UniSQL 운영 및 튜닝 인덱스 검색 조건에 해당하는 attribute 또는 path expression에 인덱스가 존재하면 이를 이용 대부분의 성능 문제 질의 : 순차 처리 가장 먼저 인덱스 처리가 되고 있는지 확인 인덱스 처리 유도  즉각적인 성능 향상 가급적 모든 질의는 인덱스 처리되도록 유도 대부분의 경우에 성능의 문제를 일으키는 질의 문장은 인덱스 처리가 되지 않아서 그런 경우가 대부분이다. 즉, 순차 처리에 의해서 이루어지기 때문에 처리 시간이 몹시 오래 걸리게 된다. 따라서, 제일 먼저 질의 처리 방안을 통해 인덱스 처리가 되는지 알아보아야 한다. 만약 인덱스 처리가 되지 않고 있다면 적절한 인덱스를 설정하여 인덱스 처리를 유도해야 한다. 한국컴퓨터통신㈜

인덱스(계속) 인덱스가 사용될 수 없는 경우 UniSQL 운영 및 튜닝 질의 문장 내에서 조작이 일어나는 경우 SELECT * FROM foo WHERE SUBSTRING(yymm FROM 1 FOR 4) = ‘1997’; 부정형으로 질의가 작성된 경우 SELECT * FROM foo WHERE yymm <> ‘199701’; NULL과 비교하는 경우 SELECT * FROM foo WHERE yymm IS NULL; 그 외에 질의 최적화기가 선택하는 경우 한국컴퓨터통신㈜

대상 클래스 선정 인스턴스가 적지 않은 경우 랜덤 액세스가 빈번한 경우 특정 범위의 데이터나 특정 순서에 따라 처리하는 경우 UniSQL 운영 및 튜닝 대상 클래스 선정 인스턴스가 적지 않은 경우 랜덤 액세스가 빈번한 경우 특정 범위의 데이터나 특정 순서에 따라 처리하는 경우 특정 경우를 제외하면 거의 모든 클래스에는 하나 이상의 인덱스가 존재 대량의 데이터를 입력/수정/삭제하는 경우 인덱스 제거 -> 수행 -> 생성 클래스에 인스턴스 수가 상대적으로 적지 않은 경우에는 인덱스가 존재해야 한다. 대략적으로 보아 데이터베이스 내에서 5 - 6 page 정도 이내를 차지하는 클래스에는 인덱스가 없더라도 속도 차이가 별로 존재하지 않는다. 그러나, 그 이상이 된다면 인덱스를 설정해야 한다. 일반적으로, 랜덤(random) 액세스가 빈번하거나, 특정 범위의 데이터나 특정 순서에 따라 처리해야 하는 경우에는 인덱스가 존재해야 한다. 특정한 경우를 제외하면 일반적으로 거의 모든 클래스에는 하나 이상의 인덱스가 존재하게 된다. 그러나, 데이터의 백업용으로 존재하는 클래스나 전체 처리(full scan)를 위한 클래스에는 인덱스를 설정할 필요가 없다. 업무에 따라서는 처음에는 인덱스가 없이 데이터만 입력되다가 어느 시점부터 인덱스를 가지게 되는 경우도 있을 수 있다. 여러 개의 인덱스가 존재하는 경우에 동시에 많은 양의 데이터를 입력/수정/삭제하는 경우에는 많은 오버헤드가 부과되므로 인덱스를 설정하거나 해제하는 시점은 매우 중요하게 된다. 일괄 처리로 데이터를 입력하는 경우에는 입력 대상이 되는 클래스에 인덱스가 설정되어 있을 경우에, 해당 인덱스를 해제한 후에 일괄 처리 작업을 수행하고 이후에 다시 인덱스를 설정하는 것과 같은 방법을 사용하는 것도 좋은 방법이다. 한국컴퓨터통신㈜

튜닝 단계에서의 인덱스 설정 해당 클래스의 액세스 형태 수집 주요 어트리뷰트의 선정 UniSQL 운영 및 튜닝 프로그램 소스 또는 로그 이용 주요 어트리뷰트의 선정 주요 어트리뷰트 : 액세스 유형에 자주 사용 되거나, 성능에 영향을 줄 것으로 예상되는 것 주요 어트리뷰트의 종류, 평균, 최대, 최소 인스턴스 수 조사 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 CHAPTER 5. 질의 튜닝 사례 한국컴퓨터통신㈜

사례 1 인덱스 어트리뷰트 조작에 의한 순차 처리 질의 변경 UniSQL 운영 및 튜닝 값의 의미를 파악 범위 이용 SELECT amount FROM check WHERE substring(yymm from 1 for 4) = ‘1997’; WHERE yymm BETWEEN ‘199701’ AND ‘199712’; 인덱스 속성은 비교되기 전에 변형이 일어나면 인데스를 사용할 수 없다. 그러나 인덱스 컴럼을 변형시키지 않고도 비교되는 상대 컬럼의 변형을 통해 거의 모든 경우를 표현해 낼수 있다. 위 예와 같이 check 라는 클래스의 yymm이라는 속성에 인덱스가 설정되어 있다 하더라도 substring이라는 변형을 가하면 인덱스 스캔을 하지 못하고 순차 검색을 한다. 따라서 이러한 질의는 의미상으로 동등하면서 속성에 변형을 가하지 않는 질의로 변경하므로서 인덱스 스캔을 할 수 있도록 한다. 한국컴퓨터통신㈜

사례 2 LIKE 질의 최적화 UniSQL 운영 및 튜닝 attr LIKE [‘string%’ | ‘string%’ | ‘%string%’] 값의 의미를 파악 범위 이용 ID 구조 : 사업부(1) 부서(1) 사원번호(4) SELECT name FROM employee WHERE id LIKE ‘12%’; WHERE id BETWEEN ‘120000’ AND ‘129999’; Like 질의는 기본적으로 인덱스 스캔을 할 수 없으므로 조건의 의미를 분석하여 like 연산자를 사용하지 않고 다른 연산자를 사용하여 의미상 동등한 질의를 만들 수 있다. 한국컴퓨터통신㈜

사례 3 NULL 비교 질의 최적화 UniSQL 운영 및 튜닝 NULL과의 비교는 인덱스 사용 못함 인스턴스 수나 분포에 따라 다름 충분한 테스트 이후에 적용 SELECT name,email_addr FROM customer WHERE email_addr IS NOT NULL; WHERE email_addr > ‘’; 인덱스 속성이 NULL로 비교되면 인데스 스캔을 할 수 없다. 그것은 속성의 값이 NULL인 인스턴스는 인덱스에 저장됮 않기 때문이다. 한국컴퓨터통신㈜

사례 4 부정형 질의 최적화 UniSQL 운영 및 튜닝 부정형을 긍정형으로 바꿔서 표현 주의 : OR 질의는 인덱스 처리되지 않음 SELECT name FROM employee WHERE dept_id <> ‘100’; WHERE dept_id < ‘100’ OR dept_id > ‘100’; SELECT name FROM employee WHERE dept_id < ‘100’ OR dept_id > ‘100’; SELECT name FROM employee WHERE dept_id < ‘100’ UNION SELECT name FROM employee WHERE dept_id > ‘100’ SELECT name FROM employee WHERE dept_id < ‘100’ UNION ALL 부정형으로 조건을 기술한 경우에도 인덳스 스캔을 하지 않는다. 인덱스 컴럼은 비교되는 상수값과 B-Tree 방식으로 스트링을 비교하여 찾는 것이므로 주어진 값이 아닌 값을 찾는 부정형 조건에는 직접 비교해야 할 값이 존재하지 않으므로 논리적으로 볼 때 이미 비교할 방법이 없다. 물론 부정형으로 작성된 SQL도 상당 부분 긍정형으로 바꾸어 인덱스를 사용하게 할 수 있다. 질의 문장에서는 UNION을 이용하여 두 개의 질의 문장을 연결하여 사용하였다. 이와 같이 두 개의 조건을 각각의 질의 문장으로 분리시키면 각각은 인덱스 처리가 된다. 그러나, 여기서 한 가지 더 생각해야 할 사항은 UNION에 대한 것이다. UNION은 기본적으로 각각의 결과를 이용하여 수학적 개념의 SET으로 처리하도록 되어 있다. 즉, 중복을 허용하지 않는다는 점이다. 따라서, 각각의 결과를 병합하는 과정에서 중복 여부를 검사하도록 되어 있다. 하지만, 우리가 작성한 질의 문장은 중복이 있을 수가 없으므로 이런 경우에는 명백한 오버헤드가 된다. UNION ALL은 두 개의 결과를 바로 병합하도록 정의되어 있으므로 중복 검사의 오버헤드를 제거할 수 있다. 한국컴퓨터통신㈜

사례 5 OR 질의 최적화 UniSQL 운영 및 튜닝 한 어트리뷰트에 대해 EQUAL 형태 질의 한국컴퓨터통신㈜ SELECT name FROM employee WHERE dept_id = ‘100’ OR ‘200’; WHERE dept_id IN (‘100’,’200); SELECT name FROM employee WHERE dept_id = ‘100’ OR tft_id = ‘1’; SELECT name FROM employee WHERE dept_id=‘100’ UNION SELECT name FROM employee WHERE tft_id=‘1’; SELECT name FROM employee WHERE dept_id=‘100’ UNION ALL SELECT name FROM employee WHERE tft_id=‘1’ AND dept_id<>‘100’; OR를 이용한 질의 문장에 대해서 생각해보자. 위에서 언급한 바와 같이 OR를 이용한 질의는 이를 이용하여 연결된 조건식에 사용된 모든 어트리뷰트에 인덱스가 설정되어 있다고 하더라도 순차적으로 처리된다. 따라서, 어떠한 방식으로든 OR를 사용하지 않고 인덱스 처리가 가능하도록 질의 문장을 작성해야 한다. 한국컴퓨터통신㈜

사례 6 group by 질의 최적화 UniSQL 운영 및 튜닝 having 절은 가급적 where 절에 표현 SELECT job, avg(salary) FROM employee GROUP BY job HAVING job = ‘manager’; WHERE job = ‘manager’ GROUP BY job; 위의 질의는 job이 MANAGER인 사람들에 대해서 평균 급여를 알아내는 질의이다. 하지만, 위의 질의는 굉장히 비효율적으로 처리된다. 일단 emp 클래스의 모든 인스턴스를 가지고 와서 이들을 그룹으로 묶는 과정에서 job = ’MANAGER’인 인스턴스만 선택하고 나머지는 버리게 된다. 따라서, 이러한 질의 조건은 WHERE 조건에 명시하여 효율적으로 최적화할 수 있다. 물론, job에 인덱스가 설정되어 있다고 하더라도 HAVING 절에 사용되면 사용할 수 없으므로 액세스 속도를 위해서는 HAVING 절을 이용하여 조건식을 명시하는 것은 절대적으로 피해야 한다. 한국컴퓨터통신㈜

사례 7 Path expression 질의 최적화 UniSQL 운영 및 튜닝 CREATE CLASS doo(i int); CREATE CLASS foo(f doo); SELECT f FROM foo WHERE f.i = 1; Query plan: Object fetch(foo.f=doo) Sequential scan(foo) 컴포지션 관계의 클래스 구조에서 조건절에 path expression이 사용되었을 경우에는 path expresison의 모든 속성에 대해 인덱스를 생성하여야만 검색 성능을 향상 시킬 수 있다. CREATE INDEX ON foo(f); CREATE INDEX ON doo(i); Query plan: Nested loops Index scan(doo, foo.f=1) Index scan(foo, foo.f=doo) 한국컴퓨터통신㈜

사례 8 Set derived table 질의 최적화 UniSQL 운영 및 튜닝 SELECT name, dt_cabin.size_in_sq_ft FROM resort, TABLE(cabins) AS t(dt_cabin) WHERE country=‘Korea’ AND dt_cabin.bed_description=‘King size’; Query plan: Object fetch(t.dt_cabin=cabin) Nested-loop join(table(resort) -> t) Index scan(resort, resort.country=‘Korea’) Sequential scan(t) 위의 질의 문장과 같은 형태가 set derived table을 이용한 전형적인 질의에 해당한다. 여기서 cabin.bed_description에 인덱스가 설정되어 있다고 가정하자. cabin.bed_description에 설정된 인덱스는 위 질의 문장과 같이 사용되었을 경우에는 활용되지 못한다. 그 이유는 set derived table을 이용하여 액세스할 때는 중간 테이블 형태로 변형되기 때문이다. 이러한 질의 문장의 성능을 높이고자 하는 경우에는 다음과 같은 질의 문장으로의 변형을 고려해볼 수 있다. 다음에 제시하는 질의 문장은 결국 cabin.bed_description에 설정된 인덱스를 활용할 수 있도록 조건식을 독립적인 질의 문장으로 분리시키고 이를 IN을 이용하여 연결하는 방법을 사용한 것이다. SELECT name, dt_cabin.size_in_sq_ft FROM resort, TABLE(cabins) AS t(dt_cabin) WHERE country=‘Korea’ AND dt_cabin IN (SELECT cabin from cabin WHERE bed_description = ‘King size’); Query plan: Index scan(cabin, cabin.description=‘King size’) Object fetch(t.dt_cabin=cabin) Nested-loop join(table(resort) -> t) Index scan(resort, resort.country=‘Korea’) Sequential scan(t) 한국컴퓨터통신㈜

사례 9 양방향 링크 이용한 set 질의 최적화 UniSQL 운영 및 튜닝 sales_sheets serial_no char(5) item char(10) price monetary sales_master sales_sheet sales_sheet master_no char(10) customer char(20) contents set(sales_sheets) Set으로 연결된 두 클래스 간에 질의를 하는 경우에 대부분의 경우에 set derived table을 이용하여 질의하게 된다. 그러나, 질의 조건이 set 쪽에만 존재한다든가 하는 이유에 의해서 성능이 좋지 않은 경우가 있다. 특히, 두 클래스에 인스턴스가 상당히 많은 경우에 이런 현상은 더 심하게 나타날 수 있다. 이 경우에 역방향 링크가 있으면 좀 더 효율적인 질의를 작성할 수 있다. 위의 데이터 모델은 어떤 회사에서 발생하는 매출 전표를 표현한 것으로, 매출 전표 한 장에는 여러 개의 제품이 기입될 수 있다고 가정하였다. 이 데이터 모델을 이용하여 특정 제품이 어떤 고객에게 얼마나 팔렸는가를 알아보기 위한 질의를 set derived table을 이용하여 작성해 보면 다음과 같다. SELECT customer, sum(t.price) FROM sales_sheet, TABLE(sales_contents) AS dt(t) WHERE t.item = ‘ABC’ GROUP BY customer; Query plan: Object fetch(dt.t=sales_sheets) Nested-loop join(table(sales_sheet) -> dt) Sequential scan(sales_sheet) Sequential scan(dt) 한국컴퓨터통신㈜

사례 9(계속) 양방향 링크 이용한 set 질의 최적화(계속) UniSQL 운영 및 튜닝 SELECT customer, sum(t.price) FROM sales_sheet, TABLE(sales_contents) AS dt(t) WHERE t.item = ‘ABC’ GROUP BY customer; Query plan: Object fetch(dt.t=sales_sheets) Nested-loop join(table(sales_sheet) -> dt) Sequential scan(sales_sheet) Sequential scan(dt) 위에 나타낸 바와 같이 상당히 복잡한 질의 처리 방안을 가진다. 질의의 조건이 t.sales_item에 존재하기 때문에 sales_sheets.sales_item에 인덱스가 존재하더라도 이를 활용하지 못하고 순차적으로 처리될 수 밖에 없다. 따라서, 데이터 건수가 많아질수록 성능이 급속히 나빠지게 된다. 이런 경우에는 set derived table을 사용하지 않고 sales_sheets에 있는 역방향 링크를 이용하면 좋은 성능을 얻을 수 있다. SELECT sales_master.customer, sum(price) FROM sales_sheets WHERE item = ‘ABC’ GROUP BY sales_master.customer; Query plan: Object fetch(sales_sheets.sales_master = sales_sheet) Index scan(sales_sheets, sales_sheets.item = ‘ABC’) 이상과 같이 set을 이용한 질의의 최적화 시에는 set derived table을 사용하는 질의를subquery를 이용하여 약간 변형하는 방법과 역방향 링크가 존재할 경우에 이를 이용하는 방법이 있을 수 있다 한국컴퓨터통신㈜

사례 10 상속 구조에서의 질의 최적화 UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ manager id char(5) name char(20) support-manager develop-manager sales-manager region char(20) region char(20) territory char(20) 상속 구조를 갖는 모든 manager를 대상으로 다음과 같은 질의를 수행할 경우 manager 클래스의 name 속성에 인덱스가 설정되어 있다 하더라도 순차 검색을 한다. 그이유는 상속 구조에서 인덱스는 상속되지 않기 때문이다. SELECT id FROM ALL manager WHERE name = ‘John’; Query plan: Sequential scan(manager) 상속구조를 같는 클래스 계층구조에서는 인덱스가 상속되지 않으므로 부모 클래스는 물론 모든 자식 클래스의 속성에 인덱스를 생성해야지만 인덱스 스캔을 할 수 있다. CREATE INDEX ON support_manager(name); CREATE INDEX ON develop_manager(name); CREATE INDEX ON sales_manager(name); Index scan(manager, manager.name = ‘John’) 한국컴퓨터통신㈜

사례 11 case를 이용한 질의 최적화 UniSQL 운영 및 튜닝 질의 조건에 따라 select-list가 변경되는 경우 SELECT name, salary * 1.2 FROM employee WHERE work_grade = ‘A’ UNION SELECT name, salary * 1.0 FROM employee WHERE work_grade = ‘B’ SELECT name, salary * 0.8 FROM employee WHERE work_grade = ‘C’; employee 클래스의 인스턴스 수가 상당히 많다면 여러 번 같은 클래스를 액세스하는 것은 상당한 오버헤드가 된다. 따라서, 한 번의 액세스로 모든 처리를 할 수 있도록 CASE 문장을 사용하면 하나의 질의 문장으로 표현할 수 있으며, 따라서 한 번의 액세스만으로 처리할 수 있게 된다. Case when 구조를 사용하여 한번의 클래스 스캔으로 주어진 질의의 결과를 생성할 수 있다. SELECT name, CASE WHEN work_grade = ‘A’ THEN salary * 1.2 WHEN work_grade = ‘B’ THEN salary * 1.0 WHEN work_grade = ‘C’ THEN salary * 0.8 END FROM employee 한국컴퓨터통신㈜

사례 12 OID를 사용한 데이터 갱신 UniSQL 운영 및 튜닝 갱신할 인스턴스의 OID를 이미 알고 있는 경우 update object 구문 사용 update employee set age = 30 where name = ‘홍길동’; update object oid set age = 30; 한국컴퓨터통신㈜

사례 13 효율이 좋지 않은 인덱스를 선택 좋은 인덱스로 처리되나 성능 저하 UniSQL 운영 및 튜닝 질의 최적화기의 통계 정보를 갱신 좋은 인덱스로 처리되나 성능 저하 가져오는 오브젝트의 개수가 많은 경우 temp volume에 질의 처리 결과 출력 작업 select list를 사용하지 말고 object navigation으로 처리 API (db_get)또는 UniTcl 명령어(uw_get) 이용 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 CHAPTER 6. 프로그램 튜닝 한국컴퓨터통신㈜

대상 선정 시스템 테스트 결과 분석 UniSQL 운영 및 튜닝 로그 사용 검색 질의 질의, 처리 시간, 시작 및 끝 시간, (검색 건수) 기타 질의 OID 기반 검색, 삽입, 수정, 삭제 질의 질의(또는 대상 클래스), 처리 시간, 시작 및 끝 시간 특별히 오래 걸리거나 응답 시간이 불규칙한 질의, 루프, 로직, 함수 검출 대표적인 시스템 테스트 환경은 테스트 데이터, 테스터, 체크 리스트 등을 들 수 있다. 테스트 데이터는 사실 프로그램 개발 초기에 실제 운영 시에 사용되는 데이터를 확보해주어야 한다. 개발 단계에서는 문제를 일으키지 않는 프로그램이(이러한 원인은 주로 건수가 작거나 사용자가 적기 때문에 기인한다), 운영 단계에서 사용자의 불만을 사는 경우가 많다.. 두 번째로 필요한 것은 다수의 테스터이다. 대부분의 경우에 소수의 사용자를 대상으로 했을 경우에는 문제를 일으키지 않다가 다수의 사용자에 대해서는 시스템이 예측할 수 없는 성능을 보이는 경우가 있다. 마지막으로는 체크 리스트이다. 즉, 대상 프로그램에서 특정 루틴 내지는 질의 문장의 응답 시간, 대상으로 하는 건수, 그 당시의 동시 사용자 수를 기본으로 하여 현장에서 필요하다고 생각되는 것들을 기록으로 남겨두면 좋다. 응용 프로그램 자체에 로그를 남기도록 하여 이를 기본으로 튜닝 대상을 설정하는 것이 좋다. 로그를 쓰기 위한 오버헤드는 존재하지만 이는 무시해도 좋은 정도이니 크게 염두에 두지 않아도 된다. 로그를 남기는 방법은 검색 질의 문장을 사용하는 경우에는 질의 문장과 처리 시간, 시작 시간, 끝 시간은 필수적으로 기록되어야 한다. 또한, 알 수 있다면 검색 건수를 기록하는 것도 도움이 될 수 있다. 질의 문장을 사용하지 않고 OID를 직접 이용하여 검색, 삽입, 수정, 삭제하는 경우에는 질의 문장 대신 대상 클래스 명을 기록한다.. 한국컴퓨터통신㈜

중복 제거 루트 내의 반복 질의, 로직, 함수 제거 UniSQL 운영 및 튜닝 1 sec/run  100 loops = 100 secs 부분적으로 나눠서 반복 처리하는 로직 하나로 묶어서 처리(group by 이용) 예: 부서별로 당해년도 매출 실적 출력 (1) 부서 코드 가져와서 루프 내에서 한 부서씩 처리 (2) group by를 이용하여 하나의 질의로 처리 클래스 액세스 횟수 최소화되도록 질의 서버가 읽는 인스턴스 수를 최소화 기본적으로 원하는 성능이 나오지 않는 프로그램을 대상으로 선정하면 된다. 이때 성능이 가변적으로 나오는 프로그램을 발견할 수 있을 것이다. 이러한 것들에 대해서는 테스트 당시에 다른 작업(예를 들어, 백업 작업)이 진행된 것이 있는 지 확인해 보는 것이 필요하다. 대상 프로그램이 선정되면 문제가 되는 부분을 발견할 수 있을 것이다. 즉, 특별히 오래 걸리는 질의 문장이나 루프, 로직, 함수 등을 찾아낼 수 있을 것이다. 이러한 부분을 집중적으로 살펴보면 해결책을 찾아낼 수 있을 것이다. 일단은 큰 맥락을 살펴보는 것이 중요하다. 루프 내에서 필요 없는 함수를 반복 호출한다거나, 필요 없는 로직을 반복 수행한다거나, 같은 결과를 가져오는 질의 문장을 매번 수행시키는 것과 같은 부분이 없는 지 살펴봐야 한다. 이와 같은 부분의 수행에 매 1초만 걸리더라도 루프를 100번만 돌아도 100초가 된다. 따라서, 이와 같은 부분이 있는지 로그 및 소스 프로그램을 통해 살펴보고 제거해야 한다.  또한, 질의 문장을 하나로 처리할 수 있음에도 불구하고 하나씩 반복해서 처리하는 부분이 있을 수 있다. 이런 부분은 과감하게 질의를 하나로 묶어서 처리할 수 있도록 한다. 이러한 경우는 종종 group by를 잘 이용하면 된다. 예를 들어, 부서별로 당해년도 매출 실적을 가져와야 하는 질의에 대해서 생각해보자. 첫번 째 방법은 모든 부서 코드(또는 명)을 부서 코드 클래스에서 가져와서 이 값으로 질의 문장을 만들어(즉, 부서 코드(또는 명)을 where 조건에 명시하여) 이를 반복 수행시킬 수 있다. 이와는 다르게 where 조건에서 부서 코드(또는 명)을 삭제하고 이를 group by 절에 명시하여 질의 문장을 하나로 만들 수 있다. 한국컴퓨터통신㈜

사례 업무 내역 UniSQL 운영 및 튜닝 모 회사 손익 시스템 중 일부 알고리즘 한국컴퓨터통신㈜ So04 So05 work_day character(6) dpt_code character(4) bgt_code character(6) dpt_tag character(2) dstb_tag character(2) amt numeric(20,5) So05 work_day character(6) dpt_code character(4) bgt_code character(6) dpt_tag character(2) dstb_tag character(2) amt numeric(20,5) Ic01 dpt_code character(4) apl_day character(8) fin_day character(8) dpt_name character(20) team_ldr_empno character(5) bsn_unit_code character(4) sub_dpt_code character(4) center_code character(4) dpt_code_div character(1) bldg_name character(20) ……………. So01 work_day character(6) dpt_code character(4) dpt_set set_of(ic01) dstb_basic character(1) dpt_tag character(2) dstb_order character(1) emp_cnt numeric(12,0) rpt_order character(3) xxx_dpt character(4) 데이터 량 So04, So05 클래스: 수천건 So01, Ic01 클래스: 수백건 So01과 Ic01의 Cardinality: 약 1:10 한국컴퓨터통신㈜

사례(계속) 중간질의 결과 UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ select dpt_code, dpt_tag, dstb_order, t.dpt_code, ( select dpt_tag from so01 where work_day = '$work_day' and dpt_code = t.dpt_code), ( select trim(cast(emp_cnt as char(3))) from so01 where work_day = '$work_day' and dpt_code = t.dpt_code) from so01,TABLE(dpt_set) as tbl(t) where work_day = '$work_day' and dstb_basic = '1' order by dpt_tag,dstb_order,dpt_code dpt_code dpt_tag dstb_order t.dpt_code sub_query1 sub_query2 0101 12 1 0212 02 14 0101 12 1 0215 02 10 0101 13 1 0242 02 8 0101 14 2 0232 02 5 ……… 0112 21 4 0300 01 11 0112 23 3 0301 01 6 0112 30 2 0301 01 13 …….. 동일한 dpt_code 연속 한국컴퓨터통신㈜

사례(계속) 튜닝 전 코드(Tcl 코드) UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ # receiving arguments from client set db_name [uw_find_entry db_name] set work_day [lindex [uw_find_entry work_day] 0] set pmer [lindex [uw_find_entry pmer] 0] # database connection uw_database_env $db_name uw_open_sql "delete from so05 where work_day = '$work_day'" set pre_sql "insert into so05 (work_day, dpt_code, bgt_code, dpt_tag, dstb_tag, amt) select work_day, dpt_code, bgt_code, dpt_tag, dpt_tab, amt) from so04 where work_day = '$work_day' and clt_code != '11111'" uw_open_sql $pre_sql uw_open_sql "commit work” set main_sql "select dpt_code,dpt_tag,dstb_order,t.dpt_code, ( select dpt_tag from so01 where work_day = '$work_day’ and dpt_code = t.dpt_code), ( select cast(emp_cnt as char(3) ) from so01 where work_day = '$work_day' and dpt_code = t.dpt_code) from so01,TABLE(dpt_set) as tbl(t) where work_day = '$work_day' and dstb_basic = '1' order by dpt_tag,dstb_order,dpt_code " set h_select [uw_open_sql $main_sql] 한국컴퓨터통신㈜

사례(계속) UniSQL 운영 및 튜닝 outer query 한국컴퓨터통신㈜ set tuple [uw_fetch $h_select] while { $uw_msg(sqlcode) == 0 } { set dpt_code1 [lindex $tuple 0] set dpt_code [lindex $tuple 3] set dpt_tag [lindex $tuple 4] set cnt [lindex $tuple 5] set sql "select d.dpt_code from so01,table(dpt_set) as t(d) where dpt_code ='$dpt_code1’ “ set h [uw_open_sql $sql ] uw_close_sql $h set where_clause "" set i 0 set codes [uw_fetch $h] if { $i == 0 } { append where_clause "'$code'" } else { append where_clause ",'$code'" } uw_cursor next $h incr i outer query 튜닝 1 ( ) 튜닝 2 ( ) 튜닝 3 한국컴퓨터통신㈜

사례(계속) UniSQL 운영 및 튜닝 inner query 한국컴퓨터통신㈜ 튜닝 4 ( ) set sql “select sum(emp_cnt) from so01 where dpt_code in ($where_clause) “ set h [uw_open_sql $sql] set sum_cnt [uw_fetch $h] uw_close_sql $h set sql "select dpt_code,bgt_code,sum(amt), dstb_tag from so05 where work_day = '$work_day’ and dpt_code = '$dpt_code' group by dpt_code,bgt_code, dstb_tag " set h1 [uw_open_sql $sql] set j 1 while { $uw_msg(sqlcode) == 0 } { set value [uw_fetch $h1] set t_amt [lindex $value 2] set temp [expr [expr $cnt / $sum_cnt] * $t_amt] set dstb_tag [lindex $value $3] set bgt_code [lindex $value $1] set sql1 "select so05 where work_day = '$work_day' and dpt_code = '$dpt_code' and bgt_code = '$bgt_code’ and dpt_tag = '$dpt_tag' and dstb_tag = '$dstb_tag' " set han1 [uw_open_sql $sql1] set no $uw_msg(sqlres) inner query 튜닝 4 ( ) 한국컴퓨터통신㈜

사례(계속) UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ if { $no == 0 } { set result_sql "insert into so05(work_day, dpt_code, dpt_tag, dstb_tag, amt, bgt_code,dstb_dpt) values ('$work_day','$dpt_code','$dpt_tag', $dstb_tag', $temp, '$bgt_code');" } else { set result_sql "update so05 set amt = amt + $temp where work_day = '$work_day' and dpt_code = '$dpt_code' and bgt_code = '$bgt_code' and dpt_tag = '$dpt_tag’ and dstb_tag = '$dstb_tag' " } uw_open_sql $result_sql uw_cursor next $h1 uw_cursor next $h_select set tuple [uw_fetch $h_select] 튜닝 5 ( ) 한국컴퓨터통신㈜

사례 분석(계속) 튜닝 1: nested cursor UniSQL 운영 및 튜닝 사례 분석(계속) 튜닝 1: nested cursor 질의1: "select dpt_code,dpt_tag,dstb_order,t.dpt_code, (select dpt_tag from so01 where work_day = '$work_day’ and dpt_code = t.dpt_code), (select cast(emp_cnt as char(3)) from so01 where work_day = '$work_day' and dpt_code = t.dpt_code) from so01,TABLE(dpt_set) as tbl(t) where work_day = '$work_day' and dstb_basic = '1' order by dpt_tag,dstb_order,dpt_code ” 질의2: "select dpt_code,bgt_code,sum(amt), dstb_tag from so05 where work_day = '$work_day’ and dpt_code = '$dpt_code' group by dpt_code,bgt_code, dstb_tag ” 이 사례에서는 질의1이 outer query가 되고 질의2가 inner query가 됨 outer loop의 질의 결과가 상당히 많은 경우, 성능 저하 해결 방안: outer 질의의 결과를 화일에 저장한 후 cursor를 닫음 한국컴퓨터통신㈜

사례 분석(계속) 튜닝 2: 중복질의 UniSQL 운영 및 튜닝 앞의 질의는 outer query 결과 만큼 실행 질의 "select d.dpt_code from so01,table(dpt_set) as t(d) where dpt_code ='$dpt_code1’ “ 앞의 질의는 outer query 결과 만큼 실행 page 42의 결과를 분석하면 dpt_code의 결과는 같은 결과값이 여러 번 반복되므로 dpt_code의 값이 변화되기 전까지는 앞의 질의를 실행하지 않아도 됨 해결방안: dpt_code의 값이 변화되는 시점에서 한번만 질의를 수행 한국컴퓨터통신㈜

사례 분석(계속) 튜닝 3: 불필요한 코드 UniSQL 운영 및 튜닝 1)번 부분의 코드는 2) 번 질의를 수행하기 위한 코드 set sql "select d.dpt_code from so01,table(dpt_set) as t(d) where dpt_code ='$dpt_code1’ “ set h [uw_open_sql $sql ] uw_close_sql $h ………... set sql “select sum(emp_cnt) from so01 where dpt_code in ($where_clause) “ 1)번 부분의 코드는 2) 번 질의를 수행하기 위한 코드 해결방안: 1)번의 기능을 host 변수를 사용하여 해결가능 set sql "select sum(set{d.dpt_code}) to x from so01, table(dpt_set) as t(d) where dpt_code = '$dpt_code1'" set h [uw_open_sql $sql] set sql "select sum(emp_cnt) from so01 where dpt_code in x " 1 ) 2 ) 한국컴퓨터통신㈜

사례 분석(계속) 튜닝 4: 불필요한 질의 UniSQL 운영 및 튜닝 set sql1 "select so05 from so05 where work_day = '$work_day' and dpt_code = '$dpt_code' and bgt_code = '$bgt_code’ and dpt_tag = '$dpt_tag' and dstb_tag = '$dstb_tag' " set han1 [uw_open_sql $sql1] 앞의 질의의 목적은 So05 클래스에 데이터를 입력 또는 갱신할 것 인지의 여부를 검사하기 위한 질의 해결방안: db_find_unique(uw_find_unique) 함수 사용 db_find_unique 함수를 사용하기 위한 제약 조건: 클래스내에 한 개의 unique 키가 설정되어 있어야함 따라서 unique가 될수 있는 임의의 키를 so05 클래스에 삽입 set tot_code "$work_day-$dpt_code-$bgt_code-$dpt_tag-$dstb_tag" set oid [uw_find_unique so05 tot_code $tot_code] if { oid == "" } { set result_sql "insert into so05(work_day, dpt_………” else { ……. } 한국컴퓨터통신㈜

사례 분석(계속) 튜닝 5: 비효율적인 질의 UniSQL 운영 및 튜닝 set result_sql "update so05 set amt = amt + $temp where work_day = '$work_day' and dpt_code = '$dpt_code' and bgt_code = '$bgt_code' and dpt_tag = '$dpt_tag' and dstb_tag = '$dstb_tag' " 앞의 질의를 처리하기 위하여 so05 클래스 전체의 데이터를 스캔 해결방안: OID를 사용한 갱신 OID를 사용하기 위해서는 앞의 질의부에서 미리 OID를 검색하여야함 set result_sql "update object $oid set amt = amt + $temp 한국컴퓨터통신㈜

사례 결과(계속) UniSQL 운영 및 튜닝 튜닝 후 코드(Tcl 코드) 한국컴퓨터통신㈜ # receiving arguments from client set db_name [uw_find_entry db_name] set work_day [lindex [uw_find_entry work_day] 0] set pmer [lindex [uw_find_entry pmer] 0] # database connection uw_database_env $db_name uw_open_sql "delete from so05 where work_day = '$work_day'" set pre_sql "insert into so05 (work_day, dpt_code, bgt_code, dpt_tag, dstb_tag, amt) select work_day, dpt_code, bgt_code, dpt_tag, dpt_tab, amt) from so04 where work_day = '$work_day' and clt_code != '11111'" uw_open_sql $pre_sql uw_open_sql "commit work” set main_sql "select dpt_code,dpt_tag,dstb_order,t.dpt_code, (select dpt_tag from so01 where work_day = '$work_day’ and dpt_code = t.dpt_code), (select cast(emp_cnt as char(3)) from so01 where work_day = '$work_day' and dpt_code = t.dpt_code) from so01,TABLE(dpt_set) as tbl(t) where work_day = '$work_day' and dstb_basic = '1' order by dpt_tag,dstb_order,dpt_code " set h_select [uw_open_sql $main_sql] 한국컴퓨터통신㈜

사례 결과(계속) UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ set result_file "/tmp/result.data" set output_fd [open $result_file w] if { $output_fd < 0 } return while { $uw_msg(sqlcode) == 0 } { set tuple [uw_fetch $h_select] for { set i 0 } { $i < 6 } { incr i} { set value [lindex $tuple $i] if { $i < 5 } { puts -nonewline $output_fd "$value@" } else { puts $output_fd "$value" } uw_cursor next $h_select close $output_fd uw_close_sql $h_select set output_fd [open $result_file r ] set k 0 gets $output_fd tuple 튜닝 1 ( nested cursor 제거 ) 한국컴퓨터통신㈜

사례 결과(계속) UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ 튜닝 2 ( 중복된 질의 제거 ) 튜닝 3 ( 불필요한 while { [eof $output_fd] != 1 } { incr k set tuple [split $tuple "@"] set dpt_code1 [lindex $tuple 0] set dpt_code [lindex $tuple 3] set dpt_tag [lindex $tuple 4] set cnt [lindex $tuple 5] if { $k == 1 } { set first_dptcode $dpt_code1 set sql "select sum(set{d.dpt_code}) to x from so01, table(dpt_set) as t(d) where dpt_code = '$dpt_code1'" set h [uw_open_sql $sql] uw_close_sql $h set sql "select sum(emp_cnt) from so01 where dpt_code in x " set sum_cnt [uw_fetch $h] set sql "select dpt_code,bgt_code,sum(amt), dstb_tag from so05 where work_day = '$work_day' and dpt_code = '$dpt_code' group by dpt_code,bgt_code, dstb_tag " set h1 [uw_open_sql $sql] } 튜닝 2 ( 중복된 질의 제거 ) 튜닝 3 ( 불필요한 코드 제거 ) 한국컴퓨터통신㈜

사례 결과(계속) UniSQL 운영 및 튜닝 한국컴퓨터통신㈜ 튜닝 4 ( 중복 질의 제거 ) 튜닝 5 ( 효율적인 질의 ) while { $uw_msg(sqlcode) == 0 } { set value [uw_fetch $h1] set t_amt [lindex $value 2] set temp [expr [expr $cnt / $sum_cnt] * $t_amt] set dstb_tag [lindex $value $3] set bgt_code [lindex $value $1] set tot_code "$work_day-$dpt_code-$bgt_code-$dpt_tag-$dstb_tag" set oid [uw_find_unique so05 tot_code $tot_code] if { oid == "" } { set result_sql "insert into so05(work_day, dpt_code, dpt_tag, dstb_tag, amt, bgt_code,dstb_dpt) values('$work_day', '$dpt_code', '$dpt_tag', '$dstb_tag',$temp, '$bgt_code');" else { set result_sql "update object $oid set amt = amt + $temp" } uw_open_sql $result_sql uw_cursor next $h1 gets $output_fd tuple set dpt_code [lindex $tuple 0] if { $first_dptcode == $dpt_code1 } { incr k } else { set k 0 튜닝 4 ( 중복 질의 제거 ) 튜닝 5 ( 효율적인 질의 ) 한국컴퓨터통신㈜

UniSQL 운영 및 튜닝 문제 해결 한국컴퓨터통신㈜

Database connection fail UniSQL 운영 및 튜닝 Database connection fail 오류 메시지 sqlx -cs testdb “ ERROR: Failed to connect to database server, ’testdb', on the following host(s): hanla “ 원인 UniSQL 환경 변수 UNISQLX_DATABASES가 설정되지 않아서 databases.txt화일을 클라이언트가 찾지 못함 testdb의 서버가 동작중이지 않음 대처 방안 UNISQLX_DATABASES 환경변수를 databases.txt가 존재하는 디렉토리로 설정(.cshrc .profile .login) start_server를 사용하여 서버 구동 한국컴퓨터통신㈜

Database connection fail(계속) UniSQL 운영 및 튜닝 Database connection fail(계속) 오류 메시지 sqlx -sa testdb “ERROR: Unable to mount disk volume "/user1/users/db/testdb_lgat". The database "/user1/users/db/testdb", to which the disk volume belongs, is in use by user wschoi on process 20240 of host hanla since Sat Sep 18 12:06:13 1999.“ 원인 testdb의 데이터베이스 서버가 구동중 대처 방안 서버를 정지하고 -sa 로 접속 sqlx -cs 로 접속 한국컴퓨터통신㈜

Database connection fail(계속) UniSQL 운영 및 튜닝 Database connection fail(계속) 오류 메시지 sqlx> update boo set id = 10 where id = 10 sqlx> ;x ERROR: Your transaction (index 2, wschoi@hanla|15304) timed out waiting on X_LOCK lock on instance 0|1381|16 of class boo. You are waiting for user(s) wschoi@hanla|15271 to finish. 0 command(s) successfully processed. 원인 Update 대상 인스턴스에 대해 다른 트랜잭션이 이미 lock을 획득하고 있으므로 해당 트랜잭션이 lock을 얻지 못하고 update가 실패 대처 방안 Lockdb utility를 사용하여 현재 서버의 lock의 상태를 파악 Lockdb의 상태에 따라 대응 % lockdb choidb ………… % killtran choidb *** UniSQL/X Client Release 4.0.2 Patch Level 7 *** Generated Dec 24 1999 at 10:48:09 Tran index User name Host name Process id Program name --------------------------------------------------------------------------- 1 wschoi hanla 15271 usqlx_cs % killtran –t 1 choidb 한국컴퓨터통신㈜