태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

 

SELECT A.SID
      ,A.SERIAL#
  FROM V$SESSION
      ,V$LOCK B
      ,DBA_OBJECTS C
 WHERE A.SID = B.SID
   AND B.ID1 = C.OBJECT_ID
   AND B.TYPE = 'TM'
   AND C.OBJECT_NAME = :TABLE_NAME
--나온 결과를 KILL
ALTER SYSTEM KILL SESSION 'SID,SERIAL';  
저작자 표시
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 때찌1
TAG ORA-00054

mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=8388600
read_buffer_size=131072
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.


Number of processes running now: 0
040804 01:36:18 mysqld restarted
040804 1:36:18 InnoDB: Started
/usr/local/libexec/mysqld: ready for connections.
Version: '4.0.20' socket: '/tmp/mysql.sock' port: 3306

 

처음에는 이와 비슷한 에러가 발생했는데, 아예 mysqld 가 뜨지도 못했습니다. 그래서 optimized 와 static 옵션을 켜고 새로 컴파일해서 겨우 mysqld 는 떴지만 로그는 계속 남네요.

당장에 쓰는 데에는 문제가 없을지 궁금합니다. 이 로그가 2~3 초에 한 번은 발생하거든요.

현재 돌리고 있는 머신은 기존 서버의 유저랜드 프로그램들이 맛이 가서 임시로 돌릴 PC 거든요.

FreeBSD 5.0 이라 바이너리는 없고 컴파일할 수 밖에 없습니다.

문제 없을까요? 아니면, 램이나 CPU 같은 다른 부분에 문제가 있는 것일까요?

이 글에 대한 댓글이 총 1건 있습니다.

 

커널을 업데이트하고 나니 괜찮네요. -_-;

 

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

전 세계의 mysql을 사용하는 사람들을 가슴아프게 하는 버그입니다.

버그 내용요?

mysql.com에서도 모른답니다. -_-

 

이때까지의 경험으로는 주로 hardware장애인 경우가 많았습니다.

 

 

 

잘 사용했었는데,, 어느날 갑자기 MySql 이 죽은 후로

기동시키면 바로 죽어 버립니다.

로그는 다음과 같습니다.... 무슨 에러인지도 모르겠습니다.

====================================================================

030327 15:02:59 mysqld started

030327 15:03:00 bdb: Recovery function for LSN 1 3502454 failed

mysqld got signal 11;

This could be because you hit a bug. It is also possible that this binary

or one of the libraries it was linked against is corrupt, improperly built,

or misconfigured. This error can also be caused by malfunctioning hardware.

We will try our best to scrape up some info that will hopefully help diagnose

the problem, but since we have already crashed, something is definitely wrong

and this may fail.

 

key_buffer_size=16777216

read_buffer_size=131072

sort_buffer_size=1702047021

max_used_connections=0

max_connections=100

threads_connected=0

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2666857 K

bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

 

thd=0x84855f0

Attempting backtrace. You can use the following information to find out

where mysqld died. If you see no messages after this, something went

terribly wrong...

Bogus stack limit or frame pointer, fp=0xbffff398, stack_bottom=0x20, thread_stack=196608, aborting backtrace.

Trying to get some variables.

Some pointers may be invalid and cause the dump to abort...

thd->query at (nil) is invalid pointer

thd->thread_id=138960120

 

Successfully dumped variables, if you ran with --log, take a look at the

details of what thread 138960120 did to cause the crash. In some cases of really

bad corruption, the values shown above may be invalid.

 

The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains

information that should help you find out what is causing the crash.

030327 15:03:00 mysqld ended

 

by Mysql맹

이 글에 대한 댓글이 총 2건 있습니다.
 

이 부분이 mysql을 사용하면서 가장 error 인 부분이겠죠. debugging 자료를 가지고 mysql에 문의해 본 결과는..

 

"우리도 모르겠다" 였습니다.

 

==

 

시스템과 무슨 마찰이 있는 것 같은데..

 

보통

 

i) mysql을 새로 설치한다.

ii) 시스템을 새로 설치한다.

 

하면 해결됩니다. 원인을 마땅히 모르니 대처방안이 새로 깐다~ 밖에 없네요

 

==

 

메모리 사용량 어쩌고 하는데.. 저걸 거의 0로 만들어도 안 될 겁니다. ^^

장홍창(ChangAya)님이 2003-03-27 15:48:40에 작성한 댓글입니다.

-rw-rw----    1 mysql    mysql       25088  5월 10  2003 ib_arch_log_0000000000
-rw-rw----    1 mysql    mysql     5242880  2월 14 02:54 ib_logfile0
-rw-rw----    1 mysql    mysql     5242880  2월 13 08:58 ib_logfile1

 

위와 같이 로그 파일들 어제 백업된 것으로 복원하니 자료 손상없이 될 되더군요...

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 때찌1
mysqladmin -uuser -p version
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 때찌1

mysql 을 소스 컴파일할 때 configure 옵션 --without-readline 추가

 

또는

--with-readline 옵션

 

다음 홈 디렉토리의 .bashrc 파일을 열어 다음 두 줄을 추가합니다.

export LANG=ko_KR.EUC-KR
export LANGUAGE=ko_KR:ko:en_GB:en

 

출처 http://blog.naver.com/webman21?Redirect=Log&logNo=10000000216

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 때찌1
팁이 될런지는 모르겠습니다.
성격에 맞지 않는다면 바로바로 삭제조치하시길 바랍니다. 비번을 몰라 삭제할 수 없으니깐요


MySQL 4.1.7 의 콘솔상에서의 한글 입력을 위해서는  --without-readline 옵션을 주고 컴파일 하면 됩니다.

근데 문제가 한가지 있습니다.

디비, 테이블, 필드 등이 생성될때 아무런 옵션을 주지 않을 경우 컴파일시 지정한 문자셋을 디폴트로 하여 생성됩니다.
또한 connection 할때도 마찬가지로 디폴트 문자셋으로 연결합니다.
만일 연결 문자셋(3가지 있습니다) 과 생성된 문자셋이 다를 경우
한글 입력(insert 등등) 은 물론이거니와 출력도 제대로 되지 않습니다.

그러므로 한글 입출력이 제대로 될려면 입력하는 클라이언트(터미널) 에서의 문자셋이 생성된 문자셋과 동일해야 하며, 입력시(where 절이나, insert, update 등등 한글을 써야 하는 부분을 총칭) 해당 문자셋으로 입력이 가능해야만 합니다.

즉, 디비를 utf8 로 해놓고 연결을 euckr 로 했다면
한글 타이핑은 가능하나,
insert into tb col values('한글이 포함된 문자열');
이런식으로 할 경우 실제적인 쿼리는
insert into tb col values(''); 이런 식으로 되어버립니다.
그러므로 터미날이 항상 입력가능해야만 합니다.
아울러 문자셋이 틀릴 경우 set 명령어로 문자셋을 맞추어 주어야 합니다.
(이는 콘솔상이 아니라 그 어떤 환경도 마찬가지일거 같군요)

set character_set_client = x;
set character_set_results = x;
set character_set_connection = x;
(위에서 x 는 utf8, euckr 등등 원하는 문자셋을 적으면 됩니다.)

또 중요한 사실은
디비 등등의 생성하거나 alt 명령어로 어떤 문자셋으로 변경하던지간에
mysqldump 를 하게되면
컴파일시 지정한 문자셋을 기준으로 덤프 받습니다.
문자셋이 다를 경우 restore 등등의 작업후 혼란이 생길수도 있을거 같습니다.


한글에 대한 문제가 있으신분은 참고가 되기를 바랍니다.
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 때찌1

MySQL 데이터베이스 최적화, MySQL 성능을 200%로 1

MySQL 모니터링과 서버 튜닝

MySQL은 그 동안 이른바 APM으로 일컬어지는 아파치, PHP, MySQL 환경으로 소형 시스템이나 웹 환경에 주로 적용되어 왔지만 최근 기업들의 오픈소스 적용 바람을 타고 업무 시스템에 광범위하게 도입되고 있다. 하지만 우리나라에는 MySQL만을 다루는 책이 거의 전무할 정도로 MySQL 데이터베이스 자체에 대한 정보나 이해가 부족한 실정이다. 이번 연재를 통해 MySQL의 진정한 성능을 이끌어내자.

김병준│아이티브릿지

MySQL AB의 국내 골드 파트너인 아이티브릿지(www.itbridge.co.kr)의 MySQL 기술지원 팀장으로 MySQL을 비롯한 오픈소스에 대한 컨설팅과 튜닝 업무를 맡고 있다. 오픈소스 애플리케이션들을 기업 환경에 적절히 적용하는 것에 관심이 많다.

MySQL이 오픈소스이기 때문일까? 오라클이나 MS-SQL의 경우 적절한 하드웨어에 온갖 튜닝이 다 된 상태로 사용하는 반면 MySQL은 그저 설치만 한 상태로 사용하는 경우가 많다. MySQL에 문제가 있다고 해서 기술지원을 나가보면 기본적인 설정에도 문제가 있는 경우도 허다하다. 우선 현재 시스템에 대한 모니터링을 통해 MySQL이 적절히 작동하고 있는지와 문제가 무엇인지부터 파악하자.

MySQL 데이터베이스 모니터링

튜닝의 시작은 현재 시스템의 상태와 문제점을 파악하는 것이 가장 우선일 것이다. 이를 위해 여러 가지 방법을 통해 시스템을 모니터링하는 것이다. 현재 MySQL을 모니터링하는 방법은 3가지가 있다. 첫째로 커맨드라인 명령어들을 이용해 모니터링하는 것이며 두 번째는 GUI 기반의 관리 툴인 MySQL Administrator를 통한 모니터링하는 것이다. 마지막으로 MySQL이 남긴 각종 로그를 통한 모니터링이 있다. 먼저 가장 기본적인 모니터링 방법인 커맨드라인 명령어들을 통한 모니터링에 대해 알아보자.

커맨드라인 명령어들을 통한 모니터링

커맨드라인 명령어들을 통한 모니터링의 가장 큰 장점은 어떤 환경에서도 수행이 가능하며 가장 빠르고 정확하게 자신이 원하는 바를 알아낼 수 있다는 것이다. MySQL의 커맨드라인 프로그램과 각종 SHOW 명령어들에 대해 자세히 살펴보자.

mysqladmin
mysqladmin은 MySQL 데이터베이스의 커맨드라인 기반인 관리자 프로그램이다. Mysqladmin을 통해 시스템의 현재 설정 상황과 동작 상황을 모니터링할 수 있다. <표 1>은 mysqladmin을 통해 수행할 수 있는 성능관련 명령어들이다.

명령어 내용
extended-status MySQL 데이터베이스의 현재 상황을 보여준다.
flust-hosts MySQL에 캐시된 모든 포스트를 초기화한다.
flust-logs MySQL의 로그 파일을 새로 작성하며 초기화한다.
flust-status MySQL의 상태정보를 초기화한다.
flust-tables MySQL에 캐싱된테이블 정보를 초기화한다.
flust-thread 쓰레드 캐시에 저장된 쓰레드를 초기화한다.
flust-privileges 권한정보 테이블을 다시 읽는다.
kill id 특정 MySQL 프로세스를 죽인다.
Processlist 현재 MySQL 프로세스 목록은 본다.
Refresh 현재 캐시되어 있는 모든 테이블을 초기화하고 log 파일은 새로 만든다.
Variables 설정 가능한 모든 변수를 보여줍니다.


<화면 1> SHOW VARIABLES로 통해 본 설정


<화면 2> SHOW STATUS롤 통해 본 서버의 사용 통계

SHOW ENGINES
MySQL의 가장 큰 특징 중 하나는 여러 가지 스토리지 엔진을 가지고 있다는 것이다. 이 명령은 현재 MySQL의 시스템이 어떤 스토리지 엔진을 사용할 수 있는지 보여준다.

mysql >SHOW ENGINES
+----------------+---------+----------------------------------------------------------------+
| Engine | Support | Comment |
+----------------+---------+----------------------------------------------------------------+
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance |
| HEAP | YES | Alias for MEMORY |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables |
| MERGE | YES | Collection of identical MyISAM tables |
| MRG_MYISAM | YES | Alias for MERGE |
| ISAM | NO | Obsolete storage engine, now replaced by MyISAM |
| MRG_ISAM | NO | Obsolete storage engine, now replaced by MERGE |
| InnoDB | YES | Supports transactions, row-level locking, and foreign keys |
| INNOBASE | YES | Alias for INNODB |
| BDB | NO | Supports transactions and page-level locking |
| BERKELEYDB | NO | Alias for BDB |
| NDBCLUSTER | NO | Clustered, fault-tolerant, memory-based tables |
| NDB | NO | Alias for NDBCLUSTER |
| EXAMPLE | NO | Example storage engine |
| ARCHIVE | YES | Archive storage engine |
| CSV | NO | CSV storage engine |
| BLACKHOLE | NO | Storage engine designed to act as null storage |
+----------------+---------+----------------------------------------------------------------+

SHOW VARIABLES
MySQL은 설정 가능한 값들을 엄청나게 많이 가지고 있으며 SHOW VARIABLE 명령을 통해 현재 설정되어 있는 모든 값을 볼 수 있다. <화면 1>은 SHOW VARIABLES로 통해 살펴본 설정이다.
SHOW VARIABLES로 볼 경우 총 207개 정도의 변수가 표시된다. 오히려 너무 많아서 원하는 값을 찾기가 힘들 정도이다. 그래서 SHOW VARIABLES 명령 뒤에 LIKE ‘%키워드%’를 사용하면 원하는 값만을 볼 수 있다.

SHOW STATUS
MySQL은 내부적으로 동작 상황에 대한 실시간 통계 정보를 가지고 있다. SHOW STATUS는 이러한 통계 정보를 보기 위한 명령이다. 모니터링할 때 가장 기본이 되는 것이 바로 앞에서 설명한 SHOW VARIABLES의 정보와 SHOW STATUS의 정보이다. 웹 기반의 모니터링 툴을 비롯한 각종 모니터링 툴들이 바로 이 두 명령어를 통해 나온 정보를 조합해 사용하는 것이다. SHOW STATUS도 SHOW VARIABLES와 마찬가지로 LIKE ‘%키워드%’ 사용해 원하는 값만을 볼 수 있다.

SHOW PROCESSLIST
현재 동작하고 있는 MySQL 데이터베이스 서버의 동작중인 모든 쓰레드와 유저 커넥션 정보를 보기 위한 명령어이다. 이를 통해 얻어진 정보로 시스템 자원을 지나치게 많이 사용하거나 잘못된 수행을 하고 있는 프로세스를 죽일 수 있다.

SHOW TABLE/TABLE STATUS/INDEX/INNODB STATUS
SHOW TABLE 명령은 현재 데이터베이스에 존재하는 테이블에 대한 기본적인 정보를 보여주며 SHOW TABLE STATUS는 각 테이블의 생성 일자, 테이블 크기, 인덱스 크기 등 구체적인 정보를 보여준다. 하지만 이 때 주의할 점이 하나 있는데 바로 SHOW TABLE STATUS의 경우 테이블의 스토리지 엔진이 MyISAM인 경우에만 정확한 정보를 표시하며 InnoDB의 경우에는 부정확한 정보를 보여준다는 것이다. InnoDB 스토리지 엔진으로 되어 있는 테이블은 SHOW INNODB STATUS로 구체적인 정보를 확인할 수 있으며 SHOW INDEX를 통해 테이블의 인덱스에 대한 각종 정보를 볼 수 있다.


<화면 3> Server Connetion에서 쓰레드별 정보를 보는 화면

<화면 4> MySQL Administrator를 통해 커넥션 관련 정보를 실시간 모니터링한다.

GUI 기반의 모니터링
그동안 MySQL의 경우에는 GUI 기반의 관리 툴에 대한 지원이 매우 미약했던 것이 사실이다. 하지만 올해 초 4.1 버전 발표 이후 연속적으로 GUI 기반의 관리 툴을 발표되었으며 그 완성도 또한 이전의 여러 GUI 프로그램들에 비해 비약적인 향상을 가져왔다. 빠르고 정확한 정보의 확인을 위해 커맨드라인 관리 툴들이 유용하지만 사실 일반적인 모니터링에는 GUI 기반의 모니터링 툴의 사용이 훨씬 편하다. MySQL이 새롭게 내놓은 GUI 기반 툴 중 모니터링을 위해 이용할 수 있는 툴은 MySQL Administrator와 MySQL Query Browser이다.

MySQL Administrator
MySQL의 GUI 기반 관리 툴인 MySQL Administrator는 기존의 GUI 관리 툴과는 달리 매우 다양한 관리 업무와 모니터링 작업을 편리하게 지원한다. 이 중 가장 돋보이는 기능은 모니터링 기능인데 이 툴로 인해 MySQL 튜닝 작업이 두 배는 편리해졌다고 말할 수 있을 정도이다. MySQL Administrator의 모니터링 관련 메뉴는 Server Connections, Health, Server Logs 등 이렇게 세 가지가 있다. <화면 3>과 같이 Server Connection은 커맨드라인 명령 중 SHOW PROCESSLIST와 같은 역할과 함께 각 유저 별 접속 현황을 알 수 있다.

MySQL Administrator의 모니터링 기능의 백미는 바로 Health 메뉴이다. Health 메뉴에서는 기본적으로 Connection Health, Memory Health, Status Variables, System Variables 등 네 가지 항목을 가지고 있으며 이전 커맨드라인 모니터링에서 하던 대부분의 모니터링 작업을 여기서 수행할 수 있다. 그리고 가장 큰 특징이라면 기본적으로 보여주는 주요 사항에 대한 모니터링 외에도 SHOW STATUS를 통해 볼 수 있는 모든 항목에 대한 모니터링 그래프를 추가할 수 있다는 것이다. 이를 통해 직관적인 화면상의 변화를 보며 사용자 수의 변화나 시간대별 변화에 대한 쉽고 편한 모니터링을 할 수 있게 되었다.

MySQL Query Browser
MySQL Query Browser는 기존의 MySQL 관리자나 프로그래머들이 많이 이용하던 SQLGate와 비슷한 역할을 수행하는 프로그램이다. GUI 상에서 MySQL 쿼리들을 수행할 수 있으며 여러 탭을 이용해 빠른 작업을 할 수 있게 되었다. 또한 도움말과 명령어들에 대한 하일라이팅을 지원함으로써 편리하고 정확한 작업을 할 수 있다. 앞의 커맨드라인 명령어들을 여기에서 모두 실행해 볼 수 있다. 초기 버전에서는 한글을 입력하면 다운되는 등의 치명적인 버그가 있었으나 지금은 수정되어 우리나라의 사용자들도 자유롭게 사용할 여건이 되었다.

로그를 통한 모니터링

적절한 수준의 로그를 남기는 것은 빠르고 건강한 MySQL을 유지하는 비결이다. 일반적으로 운영되는 서버라면 에러 로그와 슬로우 쿼리 로그를 남기는 정도로 충분하지만 서비스를 위한 시험 기간이거나 문제를 찾는 시점이라면 일반 쿼리 로그(General Query Log)를 남겨 어떤 쿼리가 가장 많이 사용되는지 파악하고 그 쿼리를 더 빠르게 할 수 있는 방법이 없는지를 찾는 것은 데이터베이스 최적화하는 좋은 방법 중 하나이다. 일반적으로 MySQL을 사용하는 사용자들의 경우 기본적으로 지원하는 에러 로그만을 남기고 슬로우 쿼리 로그를 남기지 않는 경우가 많은데 슬로우 쿼리는 MySQL의 성능을 떨어뜨리는 주범이다. 반드시 슬로우 쿼리 로그를 남기고 확인해 개선점을 찾도록 하자.


<화면 5> MySQL Auery Browser

MySQL 서버 튜닝

MySQL의 튜닝은 MySQL의 데이터베이스 시스템 관련 파라미터들에 대한 튜닝과 각각의 스토리지 엔진 관련 튜닝으로 나눠진다. 이번 호에서는 MySQL의 데이터베이스 시스템 즉 MySQL 전체 성능에 영향을 미치는 튜닝에 대해 알아보고 각각의 스토리지 엔진에 대한 튜닝과 최적화는 다음 호에 알아보자. MySQL의 시스템 관련 튜닝은 MySQL의 설정 파일인 my.cnf(윈도우의 경우는 my.ini) 파일을 수정하게 되며 MySQL 커넥션에 관한 부분과 메모리에 관한 부분으로 나눌 수 있다. 먼저 커넥션에 관한 부분부터 살펴보자.

MySQL 커넥션 튜닝

실제적으로 MySQL이 가장 많이 사용되는 분야를 꼽는다면 역시 인터넷 분야라고 할 수 있다. 포탈 사이트나 게임 사이트 등 부하가 매우 많이 발생하는 사이트에서 가장 문제되는 것은 MySQL의 커넥션에 관련된 문제이다. 커넥션에 관련된 모니터링은 SHOW STATUS LIKE ‘%CONNECT%’로 알아 볼 수 있다.

mysql> SHOW STATUS LIKE ‘%CONNECT%’;
+-------------------------------+---------------+
| Variable_name | Value |
+-------------------------------+---------------+
| Aborted_connects | 12 |
| Connections | 212 |
| Max_used_connections | 112176 |
| Threads_connected | 168 |
+-------------------------------+---------------+
4 rows in set (0.00 sec)
mysql> SHOW STATUS LIKE ‘%CLIENT%’;
+-------------------------------+---------------+
| Variable_name | Value |
+-------------------------------+---------------+
| Aborted_clients | 2 |
+-------------------------------+---------------+
1 row in set (0.00 sec)

connect_timeout/interactive_timeout/wait_timeout
connect_timeout은 MySQL이 클라이언트로부터 접속 요청을 받는 경우 몇 초까지 기다릴지를 설정하는 변수이다. 기본 값은 5초이며 일반적으로 수정할 필요는 없다. Interactive_timeout은 ‘mysql>’과 같은 콘솔이나 터미널 상에서의 클라이언트 접속을 말한다. 기본 값으로 8시간이 잡혀 있으나 1시간 정도로 낮추는 것이 좋다. 이런 접속은 그다지 빈번하지 않으며 작업을 위해 접속하는 경우가 많기에 따로 설정하지 않아도 큰 영향은 없다. 가장 중요한 것은 wait_ timeout으로 wait_timeout은 접속한 후 쿼리가 들어올 때까지 기다리는 시간이다. 접속이 많은 데이터베이스 시스템에서는 이 값을 낮춰 sleep 상태로 커넥션만 유지하고 있는 클라이언트들의 접속을 빠르게 끊어줘 동시 접속을 낮추는 것으로 전체 성능을 크게 향상시킬 수 있다.

하지만 주의할 점은 너무 낮추게 되면 실제로 서비스를 하기도 전에 끊어진다든지 지나치게 잦은 커넥션이 발생한다는 것이다. 일반적으로 15~20 사이의 값이 적당하며 SHOW STATUS를 통해 aborted_client가 가장 적게 발생하도록 값을 맞춰야 한다. Aborted client는 2% 아래인 것이 바람직하며 물론 없는 것이 가장 좋은 상태이다.

net_buffer_length/max_allowed_packet
MySQL의 커넥션은 쓰레드 단위로 일어나는데 각 쓰레드가 생성되면서 메시지 전송을 위한 버퍼를 생성하게 된다. 일반적으로 max_allowed_packet만을 정해 놓는 경우가 많은데 net_buffer_ length를 설정해 두면 그 용량을 넘는 메시지를 전달해야 할 경우 자동으로 이 값을 늘리게 된다. 그러므로 가장 효율을 높이기 위해서는 net_buffer_length를 일반적인 쿼리에서 전송되는 바이트 값의 평균 정도를 생각하여 충분히 낮은 값을 설정해두고 max_allowed_ packet은 최대로 전송될 수 있는 높은 값을 설정하는 것이 좋다. max_allowed_packet은 1GB까지 설정할 수 있다.

max_connections/back_log
max_connections는 서버가 허용하는 최대한의 커넥션 수이다. MySQL 데이터베이스를 운영하고 있는 서버의 사양에 따라 달라질 수 있으며 일반적으로 120~250개 정도로 설정하는 것이 보통이다. 하지만 접속이 많고 고용량 서버의 경우 1000개 정도의 높은 값을 설정하는 것도 가능하다. Too many connection 에러가 발생하지 않도록 적절한 값을 설정하는 것이 중요하다. Back_log의 경우 max_connection 이상의 접속이 발생할 때 얼마만큼의 커넥션을 큐에 보관할지에 대한 설정 값이다. 기본 값은 50이며 접속이 많은 서버의 경우 이 값을 늘릴 필요가 있다.

skip-name-resolve
외부로부터 접속 요청을 받을 경우 인증을 위해 IP를 호스트네임으로 바꾸는 과정이 수행된다. 말하자면 hostname lookup 과정이 수행되는데 접속이 많은 서버에서는 이 과정에서 상당히 많은 과부하가 발생한다. 그러므로 인증 부분을 호스트 기반이 아닌 IP 기반으로 변경하고 이 같은 옵션을 통해 hostname lookup 과정을 생략하면 눈에 띄는 성능 향상을 경험할 수 있을 것이다.

MySQL 메모리 튜닝

사실 데이터베이스 시스템 튜닝은 메모리 관련 파라미터를 조정하는 것이 90% 정도를 차지한다고 할 수 있을 정도로 데이터베이스 시스템의 성능은 메모리 관련 설정들에 큰 영향을 받는다. MySQL의 메모리 부분 튜닝은 사실 대부분 스토리지 엔진에 특화된 부분이다. 하지만 시스템 전체에 영향을 미치는 메모리 설정이 있는데 쓰레드 관련 메모리 설정과 쿼리 캐시관련 메모리 설정이 그러하다. 먼저 쓰레드 관련된 메모리 설정부터 살펴보자

쓰레드 관련 메모리 튜닝
MySQL은 커넥션마다 하나의 쓰레드를 생성시켜 요청을 처리하게 된다. 그래서 쓰레드가 생성되는 시점에 쓰레드에 메모리가 할당되며 많은 쓰레드가 생성되고 사라지면서 과부하가 발생한다. 일반적인 시스템에서는 쓰레드 관련 파라미터들의 조정할 필요는 없지만 부하가 심한 서버에서는 모니터링 결과에 따라 이 설정을 변경해 성능 향상을 이룰 수 있다. 먼저 현재 쓰레드와 관련된 상태를 알아보자.

mysql> SHOW STATUS LIKE ‘%THREAD%’;
+-------------------------------+---------------+
| Variable_name | Value |
+-------------------------------+---------------+
| Delayed_insert_threads | 0 |
| Slow_launch_threads | 0 |
| Threads_cached | 0 |
| Threads_connected | 1 |
| Threads_created | 2 |
| Threads_running | 1 |
+-------------------------------+---------------+
6 rows in set (0.00 sec)

앞에서 볼 수 있는 항목 중 Threads_connected가 Threads_ cached에 비해 매우 높다면 thread_cache_size를 높여줄 필요가 있다. Thread_cache_size는 지나치게 높여둘 필요는 없으며 일반적으로 threads_connected의 피크 치보다 약간 낮은 수치 정도를 설정하는 것이 좋다. 이를 통해 쓰레드가 생성되고 소멸되면서 겪게 되는 메모리, 각종 자원, 시간 등의 낭비를 줄일 수 있다. 쓰레드와 관련해 또 하나 설정할 수 있는 옵션은 thread_concurrency인데 이 옵션은 솔라리스 외의 시스템에서는 신경 쓸 필요가 없으며 솔라리스에서는 CPU 수에 2를 곱한 값을 넣어주면 된다.

캐싱 관련 메모리 튜닝
MySQL 데이터베이스 시스템에서 메모리 관련 주요 설정들은 대부분 캐싱과 관련된 파라미터들이다. 버퍼 풀(buffer pool) 크기, 키 캐시(key cache) 크기, 쿼리 캐시 크기 등이 있는데, 이 중 앞의 두 개는 InnoDB와 MyISAM의 핵심 파라미터이기에 다음 호에 설명하게 되며 여기서 살펴볼 항목은 바로 쿼리 캐시에 관한 부분이다.

쿼리 캐시란?

쿼리 캐시란 빈번하게 수행되는 Select 관련 쿼리와 쿼리의 결과를 임시 저장하는 캐시 메모리이다. 데이터베이스 시스템에서 가장 시간이 많이 걸리는 것은 바로 디스크를 액세스하는 작업이다. 그러므로 디스크를 액세스하는 작업을 줄이는 것이 가장 크게 성능을 올리는 것이다. 쿼리 캐시는 Select 쿼리에만 해당되며 쿼리 캐시를 사용하지 않게 되거나 쿼리 캐시에 저장된 내용을 초기화하게 되는 경우는 다음과 같다.

◆ 데이터나 테이블 구조가 변경되었을 때
◆ 쿼리 캐시에 저장된 것과 다른 쿼리가 접수되었을 때
◆ 하나의 트랜잭션이 commit과 함께 마무리되었을 때
◆ 쿼리가 내부적으로 임시 테이블을 생성해야 할 때

현실적으로 어려운 이야기지만 이 같은 경우는 줄이면 줄일수록 쿼리 캐시의 사용률과 효율을 높여 더 빠른 성능을 기대할 수 있다.

쿼리 캐시의 사용

먼저 현재 사용하고 있는 MySQL이 쿼리 캐시를 지원하는 버전인지 아닌지 확인하자.

mysql> SHOW VARIABLES LIKE ‘HAVE_QUERY_CACHE’;
+-------------------------------+---------------+
| Variable_name | Value |
+-------------------------------+---------------+
| have_query_cache | YES |
+-------------------------------+---------------+
1 row in set (0.00 sec)

만약 쿼리 캐시가 없는 MySQL 버전을 사용하고 있다면 가능하면 업그레이드를 하도록 한다. 가장 쉽고 확실한 성능 향상법은 최신 버전의 소프트웨어를 사용하는 것이라는 것을 잊지 말자. MySQL의 경우 특히 4.1 버전 이후로 많은 부분에 있어 성능과 기능이 향상되었다. 아직도 3.x 버전을 사용하고 있다면 이번 기회에 업그레이드를 고려해 보는 것이 좋다.

쿼리 캐시를 지원하는 버전일 경우 ‘query_cache_size=64M’와 같은 방식으로 정확한 쿼리 캐시 크기를 정해 주는 것만으로 쿼리 캐시를 사용하게 된다. 그리고 쿼리 캐시의 동작 방식을 정해주는 옵션으로 query_cache_type이라는 옵션이 있는데 0은 쿼리 캐시를 비활성화시키게 되고 1은 사용 가능한 모든 쿼리가 쿼리 캐시를 이용하게 되며, 2는 쿼리 캐시를 이용하라고 정해주는 쿼리만 쿼리 캐시를 이용하게 된다. 2의 경우는 쿼리문 뒤에 SQL_CACHE라고 덧붙여주면 된다.

쿼리 캐시 최적화

데이터베이스 관련 모든 메모리 설정은 높다고 다 좋은 것이 아니다. 중요한 것은 균형 값을 찾아내는 것이다. 왜냐하면 쿼리 캐시와 MyISAM의 키 캐시, InnoDB의 버퍼 풀은 소중한 메모리 공간을 놓고 서로 경쟁하는 관계이기 때문이다.

먼저 쿼리 캐시 크기를 결정해야 한다. 일반적으로 시스템 전체 메모리의 5%에서 10% 사이를 사용하는 것이 보통이다. 일단 이 사이의 값으로 설정한 후 모니터링을 통해 쿼리 캐시 사용률이 100%에 가깝도록 하는 것이 좋다. 이를 모니터링하는 가장 좋은 방법은 MySQL Administrator를 사용하는 것으로 MySQL Administ rator의 Health 부분에서 쿼리 캐시의 효율을 지속적으로 모니터링할 수 있기 때문이다.
다음으로 쿼리 캐시에서 받아들일 쿼리의 최대 크기를 설정하는 것이 필요하다. Query_cache_limit 옵션으로써 기본 값은 1MB이나 이는 너무 큰 값일 경우가 많다. 빈번하게 사용되는 쿼리의 용량이 어느 정도인지 살펴본 후 이보다 10% 정도 높은 값을 설정하자.

DB 튜닝은 과학이 아니라 예술

데이터베이스의 튜닝은 무조건 높고 가장 좋은 것을 찾는 과학이라기보다는 균형의 미를 찾는 예술이라고 할 수 있다. 하나를 높이면 그만큼 다른 부분에서 손해를 보는 만큼 그 사이의 최적의 값을 찾는 것이 중요하며 이는 지속적인 모니터링으로 얻어질 수 있는 부분이다. 이번 호에서는 MySQL의 모니터링과 서버 전반에 대한 튜닝에 대해 알아봤다. 다음 호에는 MySQL의 성능과 바로 직결되는 부분인 MyISAM과 InnoDB 두 스토리지 엔진의 튜닝에 대해 알아보기로 하며 이번 연재를 통해 많은 분들이 MySQL의 진정한 성능을 느껴 볼 수 있길 바란다.

 

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

사족

무슨 소린지 잘 모르겠따.

난 언제 저런걸 이해해 보려나, 아니 내가 일반 개발자인 이상은 DBA는 무리인가

ㅋㅋㅋ

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

 

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 때찌1
MySQL 4.1.x 문자셋, 인코딩, UTF-8
2005/03/13 오전 1:23 | 데이터베이스

오밤중에 잠이 안와서 MySQL 갖고 노는 중..

현재 나의 Fedora Core 3 UTF-8 리눅스 상에서, JDBC와 한글 문제를 일으키지 않는 MySQL 4.1.x 설정 상태는...

기존 버전에서는 "euc-kr"로 표기되는 문자셋이 "euckr"로 바뀌었다.

/etc/my.cnf

[client] default-character-set=utf8 [mysqld] default-character-set=utf8 [mysqldump] default-character-set=utf8 

JDBC Driver URL

jdbc:mysql://localhost:3306/struts?useUnicode=true&characterEncoding=UTF8 

현제 문자셋 정보 보기

show variables like 'c%'; 
- 결과
character_set_client : utf8 character_set_connection : utf8 character_set_database : utf8 character_set_results : utf8 character_set_server : utf8 character_set_system : utf8 character_sets_dir : /usr/share/mysql/charsets/ collation_connection : utf8_general_ci collation_database : utf8_general_ci collation_server : utf8_general_ci 

이미 생성된 DATABASE의 문자셋 바꾸기

mysql> SET character_set_client = utf8; mysql> SET character_set_results = utf8; mysql> SET character_set_connection = utf8; mysql> ALTER DATABASE [DB명] DEFAULT CHARACTER SET utf8; 

이미 데이터가 들어간 테이블의 문자셋 변환

create table test (merong varchar(20) collate latin1_general_ci); 이렇게 만들어진 테이블에 한글 데이터를 넣은 후 필드를 euckr 로 변경하려면 다음처럼 해야 합니다. alter table test modify merong binary(100); alter table test modify merong varchar(20) collate euckr_korean_ci; binary 로 바꾸면 문자셋 특성이 사라지기 때문에 이런 변환과정을 거쳐야 합니다(메뉴얼에 의하면). 그냥 바꾸면 문자들이 손상됩니다. 
참조 : Database.sarang.net에 올라온 글




기타 MySQL 한글(대부분 UTF-8) 사용에 관한 문제를 계속 이 글에 추가할 예정

  추천수 (0)  답글 (0)  참조글 (0) http://kr.blog.yahoo.com/kwon37xi/1236536.html  
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 때찌1

set tab off
set heading off feedback off echo off verify off
set space 1 pagesize 0

set linesize 300

spool asdkfj.sql

SELECT * from emp;
spool off

 

 

select HDMEMBER_PK||','||PASSWD||','||NAME||','||JUMIN||','||BIRTHDAY
       ||','||BIRTHDAYFLAG||','||ZIPCODE||','||ADDR1||','||ADDR2
       ||','||TELNO||','||CELLNO||','||EMAIL||','||HOMEPAGE||','||NICKNAME
       ||','||HOBBY||','||JOB||','||NEWSSENDFLAG||','||MEMBERLEVEL
       ||','||JOINDATE||','||JOINFLAG||','||CRYPT
from hdmember
where rownum <= 1

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 때찌1
exp setvect/t6622 file=20051113.dmp buffer=40960000 log=20051113.log tables=setvect.hdmember
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 때찌1


PostgreSQL 강좌 1
-설치 및 기본 사용법-

    한동훈/KLUG 회장

     

1. 들어가는말

    요즘은 한참 RDBMS가 유행이다. 눈만 뜨고 일어나면 데이터 베이스 솔루션이니 뭐니 하면서 마치 RDBMS를 모르면 이 세상을 살아 갈수 없는 것처럼 만든다. 적어도 그 대상을 프로그래머로 국한을 시키더라도 말이다.

    하지만 아직도 자그마한 중소기업에서는 클리퍼나 DB+ 같은 것을 사용하여 만든 데이터 베이스 프로그램을 사용하기도 한다. 무릇 어떠한 필요성이 어떠한 발명이나 발전을 있게 하는 것 같다. 요즘은 데이터 베이스 분야에도 관계형 개념을 넘어 객체지향 개념이나 분산개념이 도입되기도 한다. 가면 갈수록 세상은 빠르게 변하는 것 같고, 더욱 더 많은 능력을 프로그래머에게 요구하는 것 같다.

    우리가 일반적으로 알고 있는 RDBMS 중에는 오라클, 인포믹스 같은 수백만원을 호가하는 본격 상용 데이터 베이스 시스템이 많이 알려져 있다. 하지만 이에 못지 않은 데이터 베이스 시스템이 공개용으로 여러분 가까이에 있다고 하면 어떻게 할 것인가 ?

    리눅스 사용자라면 PostgreSQL이라는 강력한 RDBMS 있다는 것을 알고 있을 것이다.
    물론 PostgreSQL이외에도 쓸 만한 데이터 베이스 시스템으로 mSQL과 mySQL이라는 것도 있다.
    PostgreSQL는 정말 중간규모 정도의 기업에서 대용량 데이터 베이스를 처리하기에도 충분한 기능을 가지고 있다. 이제 PostgreSQL의 중요특징을 살펴보도록 하자 .

 

2.PostgreSQL 의 개요 및 특징

    PostgreSQL 의 공식 사이트인 'http://www.PostgreSQL.org" 의 대문짝에는 다음과 같은 글이 커다랗게 쓰여있다.

    " PostgreSQL는 강력한 차 세대 객체 - 관계형 DBMS로서 Berkeley Postgres 데이터베이스 관리 시스템에서 파생되었다. PostgreSQL는 강력한 객체-관계형 데이터 모델과 풍부한 데이터 타입, 쉬운 확장성을 가지고 있으며, PostQuel 질의 언어를 확장된 SQL의 부분 집합으로 대체하고 있다."

    PostgreSQL은 한마디로 객체지향 기능을 가지고 있는 관계형 데이터 베이스 시스템이다. PostgreSQL의 모태가 되는 최초의 Postgres 프로젝트는 1986년 마이클 스톤브레이커(Michale Stonebraker) 교수에 의해 주도되었으며. DRAPA(방위 진보 리서치 기관 ), ARO(육군 리서치연구소). NSF(미 국립 과학 재단) 등 여러 기관으로부터 후원을 받았다. 즉, 애초에 상업적인 목적으로 개발된 것이 아니라 교육 연구차원에서 개발된 것이였다. 나중에 설명하겠지만 이러한 특징은 PostgreSQL의 데이터 타입에서도 나타난다. 그리고 아이러니컬 하게도 PostgreSQL에 관련된 문서는 직접적으로 사용자 매뉴얼에 나타난 것보다도 각종 논문으로 발표된 것이 훨씬 많다.

    PostgreSQL는 매우 다양한 연구와 여러 응용 결과를 구현하는데 사용되어져 왔으며, 금융상의 데이터 분석 시스템, 제트엔진의 성능을 모니터링 하는 패키지, 소행성의 운동을 추적하는 데이터 베이스, 의학정보 데이터 베이스, 몇 개의 지리정보 시스템 등에 관련된 업무에 이용되어져 왔다.

    Postgres는 또한 여러 대학에서 교육용으로 쓰여져 왔다. 마침내 Illustra Information Technologies 에서는 일부의 코드를 사용하여 그것을 상업화하였다
    1992년에 Postgre는 '세퀴이어 2000과학 컴퓨팅 프로젝트'의 주요한 데이터 처리기로 선정되었다. 나아가서 1993년에는 내부 사용자 집단의 크기가 두배에 가까워졌다. 이것은 코드의 원형을 관리하고 그것을 지원하는 일에 데이터 베이스 연구 중 더 많은 시간이 할당되어 가고 있다는 점을 명백하게 말해준다. 이러한 힘든 수고를 줄이기 위해서 공식적으로 이 프로젝트는 버전4.2를 마지막으로 종료되었다.

    PostgreSQL는 이러한 Postgres의 마지막 릴리즈인 버전4.2에서 파생되었으며, 버클리 소재 캘리포니아 대학에서 개발되었다. PostgreSQL6.0 이전의 버전은 흔히 Postgre95라고 불러왔다.

    PostgreSQL의 코드는 현재 완전히 ANSI C로 작성되었으며, 코드의 크기도 약25%가 줄었고, 성능개선과 코드유지 부분에 대한 많은 내부적 변화가 있었다. PostgreSQL 버전은 이전의 Postgres에 비교해볼 때 상당한 속도상의 이점이 있다고 한다.

    PostgreSQL의 세가지 중요특징은 다음과 같다.

      관계형 모델 : Postgres 프로젝트 리서치의 최초의 목적 중의 하나는 복합객체(complex object), 규칙(rule) 등을 다룰 수 있으며, 고수준으로 확장가능한 관계형 DBMS를 제작하려던 것이었다. 따라서 PostgreSQL는 관계형 DBMS가 가지고 있는 거의 모든 기능을 가지고 있다. 예를 들면 SQL에서 서술적인 질의어의 사용과 질의 최적화, 동시성제어, 트랜잭션처리, 멀티 유저 기능 등을 제공하고 있다.

      고수준 확장성 : PostgreSQL는 사용자 정의 오퍼레이터와 타입, 함수, 엑세스 메쏘드를 지원한다.

      객체지향 : PostgreSQL는 상속, 객체와 같은 객체지향개념에서 볼 수 있는 여러 특징을 초보적이나마 구현하고 있다. 이러한 특징 때문에 어떤 사람들은 PostgreSQL를 설명할 때 ORDBMS라고 말하기도 한다.

    PostgreSQL는 일반적인 구조는 postmaster. postgres. frontend 의 3가지 부분으로 구성되어 있다.

      ◐ postmaster는 최상위 데몬 프로세스이다. 이것은 frontend와 backend 프로세스 사이의 통신을 담당하며, 공유버퍼 풀(공유메모리 내부에)을 할당하며. 시작 시에 다른 초기화 부분을 수행한다.

      ◐ postgres는 backend 데이터베이스 서버 프로세스이다. 질의(query)를 수행하는 등의 실제 작업을 처리한다. postmaster는 해당 frontend 접속마다 새로운 backend 프로세스를 시작시킨다. postgres backend는 항상 서버머쉰에서 수행된다.

      ◐ frontend 응용프로그램(예를들면 psql)은 아마 또 다른 머신(예를 들면 클라이언트 워크스테이션)상에서 돌아 갈수 있으며, postmaster를 거쳐서 postgres backend 에게 접속을 요청한다.

    여기에서 backend라는 용어는 어떠한 (데이타베이스)시스템에서 실질적으로 사용자의 요청을 처리하는 엔진과 유사한 부분이라고 보면 된다. frontend는 사용자의 입력을 받아 들이거나 요청을 접수하여 backend로 전달하는 인터페이스 부분을 일컫는다. PostgreSQL에서 backend는 postgres 프로세스이고, frontend는 psql 이나 여타의 PostgreSQL 사용자 응용프로그램이다.

    PostgreSQL는 정말 다양한 API를 지원한다. 이중에서 아마도 앞으로 주로 사용하게 될 API가 하나 이상씩은 있을 것이다. 마음에 드는 것을 골라서 마음껏 사용해보기 바란다.

      ·C API

      ·C ++ API

      ·Tcl API

      ·Perl API

      ·Python API

    이중에서 C와 C ++ API는 일반적인 라이브러리와 클래스 형태로 제공한다. PostgreSQL가 공개적인 성격을 띄고 있다는 점 때문에 정말 수도 헤아릴 수 없을 정도의 지원 툴이 전세계의 여러 사람에 의해 개발되어 사용되고 있다.
    PostgreSQL 내외부에서 비공식, 공식적으로 지원되는 툴이나 다양한 패키지를 잠깐 나열해보자

      ·ODBC, UDBC, JDBC 드라이버

      ·자바 레트둘, 자바 클래스

      ·WISQL- 윈도우즈 상호대화식 질의 툴

      ·ISQL- 상호대화식 질의 툴

      ·AppGEN 개발시스템- PostgreSQL 4GL 웹 데이터베이스 어플리케이션

      ·EARP - 웹 테이타 베이스 디자인 /구현 툴

      ·dbengine- 웹 인터페이스

      ·NeoSoft NeoWebScript - Apache 웹서버 모듈

      ·PHP/FI - 서버 측 html 엠베디드 스크립트 언어

      ·WDB -P95 -PostgreSQL 와 웹의 게이트 웨이

      ·ESQL/C

    이에 대한 자세한 내용을 알고 싶으면, 얼마 전에 나온 "Linux Database HOWTO" 문서를 참조하게 바란다. 다음에서 구할 수 있다.

    http://sunsite.unc.edu/LDP/HOWTO/Database-HOWUO.html

 

3. PostgresSQL 저작권

    PostgresSQL는 기본적으로 소스수준까지도 공개적인 성격을 띄고 있다. GPL은 아니지만 사용, 복사, 수정, 배포에 있어서 자유로우며 무료로 구할 수 있다. 아울러 COPYRIGHT문서에는, 소프트웨어 사용으로 인한 손해에 대해 어떠한 보증도 하지 않으며, 상업적인 이용이나 어떤 특별한 목적에의 사용에 대해서도 보증(warranties)을 거부한다고 명시하고 있다. 즉 상식적인 수준에서 공개 소프트웨어의 범주에 포함된다고 보면 될 것 같다.

 

4. PostgresSQL 의 설치

    PostgresSQL는 다음의 플랫폼에서 동작한다.

     

    aix                     IBM on  AIX 3.2.5

    alpha                  DEC Alpha AXP  on OSF/1.2.0

    BSD44_derived    OSs derived from 4.4-lite BSD
                             (NetBSD,FreeBSD)

    bsdi                    BSD/OS 2.0, 2.0.1 2.1

    dgux                   DG/UX  5.4R3.10

    hpux                   HP PA-RISC on HP-UX 9.0

    i386_solaris         i386 Solaris

    irix5                    SGI MIPS on IRIX 5.3

                             SPARC on Linux ELF

                             (For non-ELF Linux, see LINUX_ELF below)

    sparc_solaris       SUN SPARC on Solaris 2.4

    sunos4               SUN SPARC on SunOS 4.1.3

    svr4                   INTEL x86 on Intel SVR4

    ultrix4                 DEC MIPS on Ulrix 4.4

    nextstep에서는 약간의 문제가 있다고 한다.

     

    part 1 PostgerSQL를 소스 파일로 설치하기

    현재까지 나온 PostgresSQL 6.1.1의소스 파일의 압축분량은 대략 2메가 이다. 소스파일의 압축을 풀면 대략 10메가정도 된다. 설치시에는 최소메모리 8메가와 소스 바이너리 사용자 데이터 베이스에 대략 45메가 정도의 디스크 공간을 필요로 한다 대용량의 데이터 베이스를 구축하지 않을 거라면 사실 이정도 까지도 필요하지 않다. 소스파일을 풀고 컴파일하여 바이너리를 둘 공간과 약간의 데이터 베이스 저장공간만 있으면 된다.

    지금 9월 30일 현재까지 나온 최신의 공식버전은 6.1.1이다 베타버젼은 6.2b11까지 나와있다. 10월 초경에는 6.2.가 나올 예정이고 12월 경에는 6.3이 나올 예정이라고 한다 사실 PostgresSQL과 다른 공개용 DRBMS를 비교해볼 때, PostgresSQL은 비표준적인 부분을 많이 지원해왔던 것이 사실이다. 그리하여 사용자 확장성은 정말 뛰어나게 되었으나 기본 표준인 ANSI SQL을 여전히 완전하게는 지원하지 못하고 있다. 아마도 그중에서 정말 요긴하게 사용되는 것은 subselects, primary/secondary key, constraint 정도 가 될 것이다. 하지만 사실 이런 기능의 대부분은 PostgresSQL에서 사용자 정의 함수와 인덱스 생성을 통하여 해결할 수 있는 부분들이다. 이제 6.2 버전부터 이러한 표준 SQL부분을 본격적으로 지원하겠다고 한다. 6.2 베타 버전에서도 벌써 테이블의 필드네에서 기본 DEFAULT 값을 지정하거나 NOT NULL키워드를 사용할 수 있다. 6.2 버전을 손꼽아 기다려볼만 하다.

    하지만 여기서는 현재까지의 공식버전인 6.1.1 의 설치를 기준으로 설명하겠다. PostgresSQL에서의 한글 사용문제도 있고 추가적인 기능은 나중에 탐미해도 충분할 것 같기 때문이다.

    이미 PostgresSQL를 설치하였다면 이 부분을 건너뛰면 된다. 괜히 본 것 또 보면 머리만 아프고 식욕만 떨어질 뿐이다.

    설치를 하기로 마음 먹었다면 PostgresSQL 사이트나 국내BBS Linux 동호회에서 PostgresSQL 최신버전을 받아오자. 예전의 Postgres 95 와 현재의 PostgresSQL 6.x  대 버전은 서로 설치방법이 조금 다르지만, PostgresSQL 6.x 대에서는 거의 같다. 혹시 베타버전을 설치하려는 분이나 며칠 있으면 나올 PostgresSQL 6.2를 설치하고 싶다면 그것으로 설치해도 상관은 없다.
    PostgresSQL 6.1.1을 포함한 이하 버전을 설치하려고 하고, 테이블 명이나 필드명에 한글을 사용하고 싶다던지, 2바이트 문자를 정규표현식으로 검색하고 싶다면, 다음 사이트에서 PostgresSQL 의 버전에 맞는 2바이트 코드 패치파일인 jp.patch.gz를 가져온다.

    ftp://ftp.sra.co.jp/pub/cmd/postgres/

    사실, PostgresSQL의 기본 설치는 ./configure, make, make install, initab 만으로도 충분하다. 물론 Postgres 이런 작업을 수행해야 한다는게 중요하다. 환경변수를 잡는다던지 여타의 것들은 이제 하나하나 설명하겠다.

      1) postgres 계정이 없다면 만든다.
      물론 이전에 만들어 두었다면 다시 손볼 필요는 없다.

      2) 디스크 용량이 충분한지 체크한다.
      가끔 희한한 에러가 나는 경우가 나는 경우를 자주 볼 경우가 있는데 이럴 경우에 'df'을 쳐보니 남은 디스크 용량이 0 이었다. 여유있게 50메가 정도의 여유분을 잡아놓고 시작해보자. 요즘에는 디스크 가격이 정말 싸다.

      3) 일단 postgresql-v6.1.1.tar.gz을 postgres 홈 디렉토리에 가져다 놓자

      4) Linux를 비롯한 몇몇 시스템에서는 flex를 사용한다.
      시스템에 있는 flex가 문제가 없는 버전인지 점검한다. 다음과 같이 친다.

        flex - version

      flex가 없다면 아마도 그것이 필요없을 것이다. 2.5.2나 2.5.4. 이상이면 O.K. 2.5.3. 이나 2.5.2. 이전의 버전이면 flex를 업그레이드 해야 한다.

      ftp://prep.ai.mit.edu/pub/gnu/flex-2.5.4.tar.gz에서 구할 수 있다.

      5) 이제 postgres 홈 디렉토리(/home/postgres)에 있는 PostgresSQL배포본의 압축을 풀어보자.

        cd
        tar xvzf postgresql-v6.1.1.tar.gz

      혹시 GUN tar가 아니면, gzip 과 tar 명령을 두번으로 나누어 사용해야 할 필요가 있을 것이다.

      6) 한글을 사용하려면
      위에서 받아둔 패치로 소스트리를 패치해야 한다. 테이블 명이나 컬럼명에 한글을 사용하지 않아도 된다면 6단계는 뛰어넘어도 된다. 물론 데이터의 내용을 한글로 사용하는 것은 이 패치를 하지 않아도 전혀 지장 없다.

        gzip -dc jp.patch.gz | patch -p0

      src/ 디렉토리에 Makefile.custom파일을 만들어서 JP=1 이라고  한 줄 적어준다.

      7) /usr/local/pgsql 디렉토리를 postgres 소유로 만들어둔다.

        su -l

        Password : ***********

        mkdir/usr/local/pgsql

        chown postgres.postgres /usr/local/pgsql

      8) 앞으로는 계속 postgres 사용자 계정으로 로긴하여 작업해야 한다!
      혹시 무의식적으로 root로 컴파일 작업을 하지 않도록 한다. 자신의 시스템이 너무나도 느린 386 시스템이거나, 다시 컴파일 하기가 정말 싫은 사람이 root 로 컴파일하는 실수를 범했다면, 다음 명령으로 아무 문제없이 사용할 수는 있다.

        chown -R postgres.postgres POSTGRES_ INSTALL_DIRECTORY

      src 디렉토리로 들어가서 ./configure를 실행하여 자신의 시스템에 맞는 사양을 고르면 된다. Linux 사용자라면 엔터만 두세 번 두들기면 알아서 잡아준다.

        cd

        cd postgresql-v6.1.1/src

        /configure

      여기에서 잠시 readline 라이브러리에 대해서 짚고 넘어가자. readline은 bash.psql 과 같은 명령행 기반 프로그램에서 히스토리 기능과 편집기능을 제공해주는 아주 편리한 라이브러이이다.  readline 라이브러리는 홈디렉토리의 .inputrc에서 설정을 읽어오기 때문에 2바이트 문자를 처리하려면 ~/.inputrc 에 다음의 한 줄을 적어주면 한글을 사용할 수 있다.

        set eightbit

      readline 라이브러리는 주위에서 쉽게 구하여 설치할 수 있을 것이다.

      9) 컴파일한다.

        make

      "All of PostgreSQL is successfully made. Ready to install"이라는 메시지가 보인다면 성공한 것이다 .

        make install

      보통 별 무리없이 잘 설치될 것이다. 설치되지 않는 대부분의 경우는 /usr/local/pgsql 디렉토리를 만들어 두는 것을 깜빡 했거나, postgres 의 소유로 되어 있지 않아서 그럴 것이다.

      10) 시스템이 공유 라이브러리를 잘 찾을 수 있도록 root로 로긴하여 /etc/ld.so.conf 파일에 다음의 한 줄을 추가한다.

        /usr/local/pgsql/lib

      그리고 /sbin/ldconfig를 실행한다.
      혹시 Linux 시스템이 아닌 다른 UNIX 시스템이라면 다음과 같이 해야 할 필요성이 있을지도 모르겠다.

      bash 의 경우 : export LD_LIBRARY_PATH=/usr/local/pgsql/lib

      csh 의 경우 : setenv LD_LiBRARY_PATH /usr/local/pgsql/lib

      데이터베이스를 생성할 때 "pg_id:can't load library 'libpq.so'" 라는 메시지를 받는다면 위의 작업이 필요하다.

      11) postgre로 로긴하여 postgreSQL을 위한 환경변수 설정을 한다. 이후의 모든 작업은 postgres사용자로 로긴하여 수행하여야 한다. PostgreSQL를 사용하려면 반드시 환경변수를 설정하여야 한다. 가끔 환경변수를 설정하지 않고 PostgreSQL가 작동하지 않는다고 이야기하는 분들이 많다.

      bash 사용자라면, 다음의 내용을 ~/.bash_profile에 적어넣는다.

        PATH-$PATH:/usr/local/pgslq/bin

        MANPATH=/usr/local/pgsql/man

        PGLIB=/usr/local/pgsql/lib

        PGDATA=/usr/local/pgsql/data

        export PATH MANPATH PGLIB PGDATA

      csh 사용자라면 setenv를  사용하여 똑같이 환경변수를 설정할 수 있다.
      다시 로긴하거나 source 명령을 수행하여 환경변수를 적용시킨다.

        source~/.bash_profile

      12) 데이터 베이스를 초기화한다.

        initdb

      13) 데이터 베이스에 접근할 퍼미션을 설정한다.
      이 작업은 /usr/local/pgsql/data/pg_hba.conf를 편집함으로써 할 수 있다. 이 파일을 편집하고 난 뒤에는 반드시 read only 모드로 만들어 두자.

      14) postmaster 데몬을 수행한다.

        postmaster > server.log 2> & 1 &

      15) postgers를 부팅시에 자동으로 띄우게  하려면 다음과 같이 하면된다.
      Linux를 포함한 거의 모든 UNIX 시스템에서 /etc.rc.d 디렉토리밑에 부팅시에 수행되는 여러 스크립트들이 있다.
      그중에서 rc.local 정도의 파일에 다음과 같이 적어주면 된다.

        su postgres -c "/usr/local/pgsql/bin/postmaster -S -D /usr/local/pgsql/data "

      RedHat 리눅스 같은 경우에는 rc.d 구조가 조금 다르긴 하지만 rc.local 파일에 그냥 적어주는 것이 편하다.

      16) 이왕 말이 나온 김에 postmaster를 좀더 효율적으로 띄우는 옵션을 잠깐 살펴보자.
      postmster는 몇 가지 작업을 위해 공유 메모리를 사용한다. 기본 설정은 64버퍼로 되어 있으며 하나의 버퍼당 8K를 차지한다. 필자는 대략 4메가의 메모리인 512버퍼를 postmaster에 부여하여 사용하고 있다. 너무 적으면 성능이 조금 떨어지고, 너무 많으면 오히려 이상징후가 생길 수 있으니 자신의 시스템 사양에 맞게 적당하게 잡아두자.
      그리고  postmaster의 backend는 기본적으로 디스크 케슁을 하지 않고, 변화가 생길 때 마다 곧바로 디스크에 기록하므로 속도가 좀 느려진다. 디스크캐슁을  활성화하려면 backend 옵션('-o') 에 -F를 설정하면 된다.

      필자는 다음과 같은 postmaster 초기 부팅 옵션 값을 사용하고 있다.

        su -l postgres -c "/usr/local/bin/postmaster -S -B 512 -o -F -D /usr/local/pgsql/data "

      17) 그 외의 여러 시스템에서 필요한 사항을 잠깐 살펴보자.

        Ultrix4.x : Ultrix4.x 에 동적 로더가 없다면 libdl-1.1 패키지를 설치해야 한다. 이것은 다음에서 구할 수 있다.

        Linux : Linux-elf 는 잘 설치된다. i486이상의 프로세스를 사용하고 있다면, template/LInux-elf에 "-m486"을 컴파일 옵션에 추가할 수 있다.
        ELF가 아닌 리눅스에서는 .old 라이브러리를 반드시 얻어서 시스템에 설치해야 한다. 이 라이브러리는 postgres포트에서 동적으로 링크 로딩을 할 수 있는 능력을 부여한다. dld 라이브러리는 선사이트의 리눅스 배포본에서 얻을 수 있다. 현재의 이름은 dld-3.2.5 이다.

        BSD/OS : BSD/OS 2.0 와 2.01에서는 GNU dld 라이브러리를 설치해야 한다.

        NeXT : NeXT 포트는 Tom R Hageman tom@basil.icce.rug.nl이 제공한다.
        이 판은 공유라이브러리와 세마포어 헤더파일이 필요하다. NEXTSTEP에서 돌아가는 PostgreSQL의 바이너리 배포본도 Tom에게서 general public으로 얻을 수 있다.

      18) PostgreSQL를 운영하려면 사용할 데이터 베이스와 사용자를 등록해야 한다.
      /usr/local/pgsql/bin 에 보면 이와 관련된 프로그램이 준비되어 있다. test라는 데이터베이스를 만들려면 createdb명령을 사용하면 된다.

        $ createdb test

      linuxer라는 사용자를 등록하려면 다음과 같이 하면 된다.

        $ createuser linuxer

        Enter user's postgres ID or RETURN to use unix user ID : 514 -> [Enter]

        ls user " inuxer " allowed to create to database (y/n) y

        ls user " inuxer " allowed to create to add users?(y/n) y

        createuser : linuxer was successfully added

      linuxer라는 사용자에게 데이터베이스를 생성할 권리를 제공했지만, 또 다른 사용자를 추가할 권리를 주지 않았다. 참고적으로 이야기하면 사용자를 추가할 권리를 주지 않으면 해당사용자는 자신의 데이터베이스를 삭제할 수 없게 된다.

      createdb와 createuser에 반대되는 명령은 destrotdb와 destroyuser 명령이다. test라는 데이터 베이스를 만들었으면 이제 잠깐 테스트해 보자

        $psql test

        Welcome to the POSTGRESQL interactive sql monitor :

        Please read the file COPYRIGHT for copyright terms of POSTGRESQL

        type \? for help on slash commands

        type \q to quit

        type \g or terminate with semicolon to execute query

        You are currently connected to the database : test

        test => craeat table 연습(

        test -> 이름 test

        test -> 번호 int4

        test -> );

        CREATE

        test =>\d 연습

       

      Table=연습
       

      Field

      Type

      Length

      이름

      text

      var

      번호

      int4

      4

       

      test => inster into 연습 values ('꺼벙이'.1);

      INSERT 154615

      test => inster into 연습 values ('멍청이'.2);

      INSERT 154616

      test => select*from 연습 :
       

      이름

      번호

      꺼벙이

      1

      멍청이

      2

      (2 rows)

      test =>
      postmaster backend에 접속하려면 반드시 해당 데이터 베이스를 명시해야 한다. 그렇지 않으면 사용자 아이디와 같은 데이터베이스를 찾으려고 할 것이다. 데이터베이스를 삭제(drop)할 때 조차도 해당 데이터베이스에 접속해 있는 상태에서는 불가능하고, 임시적인 다른 데이터 베이스에 접속한 다음에 원하는 데이타 베이스를 제거하여야 한다.
      PostreSQL의 슈퍼유저인 postgres에게는 이러한 용도로 template1 이라는 별의미 없는 데이터 베이스가 하나있다.

    part 2  PostgreSQL를 바이너리로 설치하기

    PostgreSQL를 본격적으로 활용측면에서 살펴 보기 전에 PostgreSQL를 바이너리로 설치하는 방법을 잠시 살펴본다. 바이너리는 주로 rpm으로 배포된다. 물론 데비안 페키지형식인 deb로 배포되긴 하지만 여기서는 PostgreSQL 의 rpm 배포판을 다루겠다. 필자는 주로 슬렉웨어를 사용하는 데 슬렉웨어에 rpm 패키지를 설치 관리할수 있도록 해주는 rpm 패키지를 설치하고  PostgreSQL 6.1 rpm 판을 설치하려다 잘 되지 않았다. 사용하고 있는 rpm 버전이 낮아서 그런지 모르겠다.

    PostgreSQL rpm 패키지는 역시 레드헷에서 설치가 잘된다. 국내 BBS 리눅스 동호회나 레드햇에서 PostgreSQL rpm 패키지를 쉽게 구할 수 있다.

    root로 로긴하여 일상적인 rpm 명령으로 설치하면 된다.

      $rpm -ivh pgsql61.rpm

    패키지의 이름은 다를 수 있다. 필자가 설치해본 PostgreSQL rpm 판은 관련파일을 여러곳으로 분산시키는 경향이 있었다. 바이너리는 /user/bin 에, 데이터파일과 리소스 파일은 /var/lib/postgresql에 들어간다. 이미 데이터베이스 초기화가 되어 있으므로 initdb로 할 필요없다.

    PostgreSQL rpm 패키지에는 몇 가지 문제가 있다. postmaster를 실행시키려면 퍼미션 에러가 떨어지는데 이는 다음을 수행하여 해결할 수 있다.
    물론 root로 수행해야 한다.

      $chown -R postgres /var/lib/postgresql

    또 하나의 예상치 못한 문제점은 PostgreSQL의 슈퍼유저 권한이 postgres 에게 있는 것이 아니라 deamon에게 있다는 것이다. PostgreSQL를  rpm으로 설치하고 데이터 베이스와 사용자를 아무리 추가하려고 해도 되지 않아서 data 디렉토리의 pg_user 데이터를 바리너리 에디터로 살펴보니 황당하게도 deamon으로 설정되어 있는 것이 아닌가? 패키징한 사람이 어떤 이유로 이렇게 한 것인지 알 수는 없지만 우리는 이런 상황을 바로 잡아보자 먼저 root 상태에서 deamon으로 로긴해야 한다. deamon은 일반적인 계정이 아니라 시스템의 효율적인 운영을 위해 생성되는 계정이다.

      $ su -I deamon

      $ createuser postgres

    postgres에게 데이터 베이스와 사용자 추가권한을 부여한다. 이제 postgres 계정으로 로긴하여 앞서와 마찬가지로 데이터 베이스와 사용자를 추가하면 된다. 하지만 이렇게 한다고 해서 모든 문제가 해결되는 것은 아니다. 그냥 간단하게 배우기에는 별문제가 없겠지만 데이터베이스 시스템을 구축한다는 측면에서 보면 꼭 소스파일로 설치하던지, 제대로 된 바이너리 패키지를 구해서 설치하기 바란다.

 

5. PostgreSQL 기초 사용법

    PostgreSQL 의 특징인 부분들을 활용하기 이전에 먼저 PostgreSQL에서 지원하는 SQL 의 기본 사용법을 잠깐 살펴보자. PostgreSQL은 아직은 ANSI SQL을 완벽하게 지원하지 않는다. 다른 자유롭게 구할 수 있는 RDBMS에 비해볼 때 표준 부분에서는 조금 떨어지는게 사실이다. 하지만, 일반적인 사용에는 전혀 지장이 없으며, 다른 RDBMS에서는 지원하지 않는 다양한 비표준기능들을 많이 지원한다.

    관계형 데이터 베이스에서는 보통 레코드(recoard)와 필드(field)라는 용어대신에 테이블(표-table), 로우(행-row), 컬럼(열-column)이라는 용어를 사용한다.
    여기서는 일반적으로 많이 사용되는 용어를 기준으로 사용할 것이다.
    먼저 다음의 내용을 자신이 편리하게 사용하고 있는 에디터로 편집해보자. 명령행에서 일일이 치는 것은 정말 짜증스러운 일이 아닐 수 없다.

     

    create table  날씨 (- 날씨 테이블

    도시 varchar (20)

    최저온도 int.

    최고온도 int.

    강수량 real.

    날짜 date

    ):

     

    insert into 날씨 values ('서울'. 10.27.0.0.'1997/10/1');

    insert into 날씨 values ('서울'. 12.25.0.12.'1997/10/2');

    insert into 날씨 values ('부산'. 13.28.0.32.'1997/10/1');

    insert into 날씨 values ('광주'. 15.25.0.73.'1997/9/28');

    insert into 날씨 values ('대전'. 10.27.0.0.'1997/10/4');

    insert into 날씨 values ('대구'. 15.23.0.15.'1997/10/3');

    insert into 날씨 values ('천안'. 9.22.0.42.'1997/10/2');

    insert into 날씨 values ('마산'. 13.24.0.01.'1997/10/1');

    insert into 날씨 values ('전주'. 12.29.0.0.'1997/10/5');

    insert into 날씨 values ('인천'. 14.23.0.25.'1997/11/2');

 

    이 파일을 weather.sql으로 저장한다. .
    앞으로 모든 작업은 mydb위에서 하는걸로 가정하겠다 다음과 같이 mydb를 만들어두자

      $ createdb mydb

    이제 데이터 베이스에 접속한다.

      $ psql mydb

    약간의환영 메시지가 나온다. 앞서 저장했던 SQL 질의어가 담긴 파일을 불러서 실행하는 명령은 '\i filename'이다.

      mydb=> \i weather.sql

    정상적으로 테이블을 만들고 해당 값을 삽입할 것이다. SQL 질의어에 대한 간단한 온라인 도움말은 '\ hcommand'형식으로 얻을 수 있다. psql 모니터링은 프로그램에서 제공하는 몇 가지 명령어는 '\?'를 사용하면 알 수 있다. 기억이 잘 안날 때 자주 사용하기 바란다.

     

    mydb => \?

    \?- help

    \a - toggle field-alignment (currenty on)

    \C [<captn>]-set html3 caption (currently")

    \connect <dbname|-> <user> - connect to new database (currently 'ddoch')

    \copy table {from | to} <fname>

    \d [<table>] - list tables and indicies in database or columns in <table>, * for all

    \di- list only indicied in database

    \ds - list only sequences in database

    \dt - list only tables in database

    \e [<fname>]- edit the current query buffer or <fname>, \E execute too

    \f [<sep>]- change field separater (currently '|')

    \g [<fname>][<cmd>] - send query to backend [end results in fname> or pipe]

    \h [<cmd>] - help on syntax of sql commands. *for all commands

    \H - toggle html3 output (currently off)

    \i <fname> - read and execute queries from filename

    \I - list all databases

    \m - toggle monitor-like table display (currently off)

    \o [<fname>] [<cmd>]-send all query result to stdout, <fname>, or pipe

    \p - print the current query buffer

    \q - quit

    \r - reset(clear) the query buffer

    \s [<fname>] - print history or save it in <fname>

    \t - toggle table headings and row count (currently on)

    \T [<html>]-set html3.0 <table...> options (currently")

    \x - toggle expanded output (currently off)

    \z - list current grant/revoke permissions

    \! [<cmd>] - shell escape or command

    mydb =>

     

    mydb =>\h

    type \h <cmd> where <cmd> is one of the following:

    abort                        abort                           alter table

    begin                        begin transaction         begin work

    cluster                      close                           commit

    commit work             copy                            create

    create aggregate       create database            create function

    create index              create operator               create rule

    create sequence        create table                  create type

    create view               declare                         delete

    drop                         drop aggregate              drop database

    drop function             drop index                     drop operator

    drop rule                   drop table                      drop sequence

    drop type                  drop view                       end

    end transaction          explain                          fetch

    grant                         insert                            listen

    load                          notify                            purge

    reset                         revoke                          rollback

    select                        set                               show

    update                      vacuum

    type \h " for a complete description of all commands

    mydb =>

 

    1) select

    '날씨' 테이블에 입력한 모든 데이터를 검색해보자

      mydb => select * from 날씨 ;
       

    도시

    최저온도

    최고온도

    강수량

    날짜

    천안

    9

    22

    0.42

    10-02-1997

    대전

    10

    26

    0.1

    10-04-1997

    서울

    10

    27

    0

    10-01-1997

    서울

    12

    25

    0.12

    10-02-1997

    전주

    12

    29

    0.

    10-05-1997

    마산

    13

    24

    0.01

    10-01-1997

    부산

    13

    28

    0.32

    10-01-1997

    인천

    14

    23

    0.25

    11-02-1997

    광주

    15

    25

    0.73

    09-28-1997

     

    이번에는 최저 온도가 가장 낮은 순서대로 검색해보자

      mydb => select *from 날씨 order by 최저온도 asc;

    asc는 오름차순으로 정리하는 것이다. 내림차순으로 정리하려면 desc를 사용하면 된다. 여기에서 정렬은 order by를 사용하면 된다. 여기에서 정렬은 order by를 사용하여 최저온도에 적용하였다.

    이번에는 강수량이 0.1에서 0.3사이인 행의 도시와 강수량을 구해보자.

      mydb => select 도시, 강수량 from 날씨 where 강수량 > 0.1 and 강수량 < 0.3 ;
       

    도시

    강수량

    서울

    0.12

    대구

    0.15

    인천

    0.25

 

    다음을 10월달의 기록 중에 최저온도 최고온도의 차이가 10도 미만인 행을 찾아서 도시와 날짜와 도시와 날짜에 대한 정보를 날짜와 대한 정보를 날씨2 라는 테이블에 저장해 보자

      mydb = > select 도시,날짜 into table 날씨2 from 날씨

      mydb = > where 날짜  > = '1997/10/1'

      mydb = >and 날짜  <= '1997/10/3'

      mydb = >and (최고온도- 최저온도) < 10;

      SELECT

      mydb = > select *from 날씨2;

     

    도시

    날짜

    대구

    10-03-1997

     

    2) update

    10월 1일 날의 최저온도를 2도 더하고 최고온도를 2도 빼보자

      mydb => update 날씨 set 최저온도=최저온도+2, 최고온도=최고온도-2

      mydb => where 날짜 = '1997/10/1';

      UPDATE

    3) delete

    delete 명령은 내부 데이터를 삭제한다 테이블 전체를 삭제하려면 drop를 써야 한다.

      mydb => delete from 날씨2

      DELETE

      mydb => select * from 날씨2 ;
       

    도시

    날짜


      mydb => drop table 날씨2;

      DROP

      mydb => select*from 날씨2;

      WARN: 날씨2: Table does not exist.

    4) alter

    '배기 가스 유출량' 이라는 칼럼을 하나 삽입해보자.

      mydb => alter table 날씨 add column 배기가스유출량 int;

      ADD

      mydb =>\d 날씨

       

      Table = 날씨

       

    Field

    Type

    Length

    도시

    varchar

    20

    최저온도

    int4

    4

    최고온도

    int4

    4

    강수량

    float8

    8

    날짜

    data

    4

    배기가스유출량

    int4

    4


      mydb =>

    현재 PostgresSQL 6.1.1 까지의 버전에는 특정 컬럼을 제거하는 명령은 없다. 6.2 이상에서 컬럼을 제거하려면, 제거하고자 하는 컬럼을 제외한 나머지 컬럼을 모두 select 하여 다른 데이블로 저장한 다음, 이전 테이블을 삭제하고, 새로 만든 테이블을 이전 테이블의 명칭으로 변경하면 된다.

    5) 전체함수

    PostgreSQL는 count, sum, average, max min 과같은 전체함수를 지원한다.

      mydb => select max(강수량) from 날씨 ;

      max

      -----

      0.73

    6)  psql의 모니터링 명령어

    psql은 libpq에 기반한 SQL 모니터링 프로그램이다. 여러 가지 다양한 기능을 제공하기 때문에 활용을 해볼 만하다. .
    psql 의 내부 모니터링 명령어 중에서 자주 사용하는 것만 설명하겠다. 나머지는 필요에 따라서 \?를 입력하여 살펴보기 바란다.

    \? : 도움말

    \a : 필드 정렬자 토글

    \C : html3 캡션 설정

    \c : 데이터베이스에 접속

    \d : 현재 데이터 베이스의 전체 테이블 또는 특정 테이블 출력

    \di :데이터 베이스 내부의 인덱스만 출력

    \ds :데이터 베이스 내부의 시퀀스만 출력

    \dt :데이터 베이스내부의 테이블만 출력

    \e : 현재버퍼에 있는 질의어나 파일을 편집

    \f : 필드 구분자 변경 (보통은 '|')

    \h : SQL 명령어에 대한 문법적 도움발출력

    \H : 질의의 결과를 html3 으로 출력할지의 여부 결정

    \i : 외부 파일에서 질의를 읽어서 실행함

    \l : 시스템의 모든 데이터 베이스를 출력

    \p : 현재의 질의 버퍼를 출력

    \q : 종로

    \r : 질의 버퍼를 청소

    \t : 헤더정보와 행의 갯수를 출력할지의 여부결정

          \T : html3.0 <Table...> 옵션결정

          \z : 현재의 허용/취소 권한 출력

          \! : 쉘 명령어 실행

    이중에서 \i 와 \d, \h 정도를 가장 많이 사용하게 될 것이다.

    7) psql 외부옵션

    psql 모니터링 프로그램은 아주 유용한 외부옵션을 많이 제공한다. 이걸 사용하면 쉘스크립트로 PostgreSQL를 사용한 CGI 프로그램을 간단하게 짤 수 있다.

      -c 질의어 : psql  명령행으로 들어가지 않고 질의어만 전달하여 작업할 수 있다.
                       간단한 PostgreSQL작업에 유용하다.

      -d 디비이름 : 접속할 데이터 베이스를 지정한다.

      -e : backend로 보낸 질의어를 echo 한다.

      -f 파일이름 : psql 내부에서 \i 명령을 사영하듯이, 외부에서도 SQL 질의어가 담긴
                         파일을 지정하여 실행할 수 있다

      -H 호스트 이름 : postmaster 가 수행되고 있는 호스트에 접속한다 기본값은
                              localhost 이다.

      -l : 사용가능한 데이테 베이스 목록을 출력한다.

      -n : psql 내부 명령행에서 readline 라이브러리를 사용하지 않는다.
            한글입력에 문제가 있을 때 사용할 수 있다.

      -p 포트 : postmaster 가 돌아가고 있는 인터넷 tcp 포트를 지정한다.
                   기본값은 5432이다.

      -q : 여러 가지 부가적인 메시지를 출력하지 않도록 한다.

      -s : 싱글 스텝모드로 psql을 실행한다. 질의어를 실행하기 전에 엔터키를 한번 더
             쳐야 한다. 조심해야 할 작업에 사용할 수 있다.

    쉘에서 어떠한 목적으로 psql 내부에 들어가지 않고 작업을 할 수 있다.

      $ psql mydb -e -c "select * from 날씨"

    다음호에서는 실제적인 업무에서 사용될 법한 좀더 복잡한 데이터 베이스를 PostgreSQL로 다루어 보면서 활용방안을 살펴보겠다.

크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 때찌1
이전버튼 1 2 이전버튼