: 1 : 2 : 3 : 4 : 5 : 6 : ... 14 :

RewriteRule 설정

2013/04/05 14:40 / Linux/Etc


.htaccess의 예


php_flag register_globals on
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^(www)\.domain\.co\.kr$ [NC]
RewriteRule (.*) http://www.domain.co.kr/$1 [R=301,L]
ErrorDocument 401 http://www.domain.co.kr/401error.html


간단하게 요정도?
난 RewriteCond와 RewriteRule에 대해서만 언급해보려한다.
RewriteEngine On은 Rewrite모듈의 사용을 위해 기본적으로 On으로 설정해두는것이 좋다.
RewriteBase는 기본적으로 .htaccess가 위치안 물리적 경로로 설정하지만 Rewrite의 쓰임이 너무 광범위하기에 다르게 쓰이는 경우도 많다.
그 외에 RewriteOptions, RewriteLog, RewriteLogLevel, RewriteLock, RewriteMap등은 심화과정이므로 취급하지 않습니다 ^^;;

이 글은 완벽하지 않다. 잘쓴 글도 아니고 잘 되어있는 글도 아니다.
하지만 당신이 컴퓨터에 대한 열정이 있고 그만큼의 노력이 있었으며 독학에 재능이 있다면 이정도의 글로도 만족할것이라 믿는다. (쓸데없는 잡담이 너무 많은거 뺴고... ㅡㅡ;;)

이제 본론으로 고고-


Rewrite모듈은 URL Rewrite 엔진일까?

RewriteCond와 RewriteRule의 기본 형태
RewriteCond와 RewriteRule의 기본 형태는 이렇다.

RewriteCond TestString CondPattern
RewriteRule Pattern Substitution

RewriteCond는 RewriteRule을 위해 존재하기도 하지만 RewriteRule은 RewriteCond를 위해 존재하기도 한다.
하지만 순서는 거의 대부분 Cond후에 Rule이 온다.
Cond는 생략하고 Rule만 있는경우도 많다.
기본형태는 이러하지만 RewriteCond만 있을수도 있고 RewriteRule만 있을수도 있으며 둘다 여러개일수도 있고 둘중 하나만 여러개일수도 있다. 순서도 맘대로라서 엄청나게 다양한 수법이 가능하다 ㅋ

처리 경로(흐름)
제일 먼저 Rule의 Pattern에 어긋나지 않는다면 Cond의 TestString으로 가서 조건검사를 시작한다. 그후 CondPattern을 지나 Substitution으로 처리되어 조건에 만족하게 된다.

다음을 보자

...
RewriteRule Pattern Substitution

RewriteCond TestString CondPattern
RewriteRule Pattern Substitution

RewriteRule Pattern Substitution
...

위의 경우 Cond와 Rule이 막 써있다 ㅋ 두개 이상의 Rule이 있을경우 위 Rule이 처리, 적용된 결과가 다시 두번째 Rule에 적용된다. 또 아래 Rule이 있다면 그 결과가 다시 검사될것이다.
혹은. 위의 조건에 맞지 않는 값이라면 다음 Rule로 넘긴다.


이하부터는 패턴, 대용(대체), 조건패턴등의 한글화를 섞어 쓰겠다.
Cond는 조건의 약자이고 Rule은 그대로 규칙, 법이다.

특수 문자
프 로그래밍을 하면서 그 프로그램 내부 코드나 명령어로 쓰이고 있어서 쓰지 못하는 문자가 많다. 여기서도 마찬가지이다. 하지만 어디서나 존재하는 Escape문자 있으니 여기서는 "\"(역슬래쉬(원))표시가 쓰인다. 보통 .이 잘못쓰일것을 대비하여 \.로 쓰는게 보통이다.
예 : domain.co.kr ==> domain\.co\.kr
주로 점.이나 대괄호[], 괄호()등에 쓰인다.

RewriteCond
RewriteCond의 기본 구문은 이미 위에서도 나왔다.
그곳 Test스트링부분에 $N이나 %N이 쓰인다면 역참조 기능을 제공하게된다.
여기서 N은 (1<=N<=9)이다.
$N의 경우 현재 처리되고있는 Rule에서 가르키고 있는 패턴이 그룹으로 묶여 제공된다.
$N을 하나의 변수처럼 사용할수 있게되는것이다.
아래도 나와있지만 괄호로 그룹을 묶은 부분이 변수로 사용된다.

RewriteCond %{HTTP_HOST} ^[^.]+\.domain\.co\.kr$
RewriteRule ^(.+) %{HTTP_HOST}$1 [C]
RewriteRule ^([^.]+)\.domain\.co\.kr(.*) /home/$1/htdocs$2

위 예제의 경우 도메인 앞의 URI를 $1로 그 뒤 경로를 $2로 지정하여 특정 디렉토리의 내용을 읽도록 하는 내용이다.
이것을 짧게 한줄로 고쳐보자면

RewriteRule ^([^.]+)\.domain\.co\.kr(.*) /home/$1/htdocs$2

요정도?

%N은 현재 처리중인 Cond에서 가르키고있는 조건과 일치한 패턴이 그룹으로 묶여 제공된다.
이건 잘 안쓰이는것같아서 정말 잘쓰이는 다음으로 패쓰~

%{Name}의 경우 해당 서버의 변수를 가지고 올수있다.
변수의 개수는 정말 엄청나게 많다. 하지만 자주 쓰이는 변수들은 아래를 통해서 한번 확인해보세요 ^^

Server Name : domain.com
Protocol : HTTP/1.1
Server Port : 80
Method : GET
Servlet Path : /index.php
Remote Host : 192.168.0.4
Remote Port : -1
Remote Address : 192.168.0.4
Content Length : 0
Header_Accept : text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Header_User-Agent : Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Header_Referer : null
Local Name : domain.com
Local Port : 80
Locale : ko_KR
Scheme : http
Request URI : /index.php

Request URL : http://domain.com/index.php


CondPattern
CondPattern에서 쓰이는 내부 명령어? 특수명령어?등을 알아보도록하자

-d => 디렉토리를 뜻한다.
결론적으로 Test스트링이 디렉토리를 가리키거나 포함하고 있을때 처리된다.
-f => 파일을 뜻한다.
Test스트링이 파일을 가리키거나 포함하고 있을때 처리된다.
-l => 심볼릭링크를 뜻한다.
Test스트링이 심볼릭링크를 가리키거나 포함하고 있을때 처리된다.
심볼릭 링크가 뭐냐고 물으신다면 리눅스나 유닉스를 공부해보세요 ^^ 라고 답하고 싶다^^

그리고 느낌표(!)는 부정을 뜻한다.

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ http://test.domain.co.kr/$1

위의 예제는 Request내용이 디렉토리나 파일을 가르키고 있지 않을경우 저쪽 사이트로 돌리라는 뜻. ^^
$1로 하위주소는 유지하려하고 있습니다 ^^

[Flag]
라인마다 Flag라 불리우는 깃발을 달수가 있습니다. 일종의 옵션으로 작용합니다 ^^

F => 403에러 Forbidden페이지로 된다.
L => Last라는 뜻입니다. 위의 Cond들은 여기까지만 적용된다
아래부터는 새로 시작 되겠지용~
N => 새로운 Rule이 시작된다는 깃발.
QSA => Cond의 대용을 지난 결과에 덧붙인다.
NE => Out될 값에 특수문자가 HexCode로 되어 포함되어있는경우
R => 리다이렉션. 무조건 넘긴다. 뒤 주소로 넘긴다는 뜻이지요 ^^
NC => 대소문자 구별없다는 뜻.
OR => 프로그래밍의 or와 비슷하다.


아래를 참고하시죠 ^^

RewriteCond %{REMOTE_HOST} ^domain.* [OR]
RewriteCond %{REMOTE_HOST} ^DOMAIN.* [OR]
RewriteCond %{REMOTE_HOST} ^DOMAIN2.* [NC]
RewriteRule ^(.*)$ http://www.domain.co.kr/$1 [R,L]

domain나 DOMAIN나 DOMAIN2나 domain2로부터 접속한 접속에 대하여 리다이렉트한다. http://www.domain.co.kr/로 접속하게된다. 보통 IP주소를 적게되겠다.

RewriteRule
여기부터는 아주 간단간단하게... ㅡㅡ;

텍스트

. => ?과 같습니다. 무엇이든 하나의 문자를 뜻합니다. A가 될수도 있고 Z가 될수 있다. 반드시 한글자.
[A] => 역시 하나의 문자가 올수 있다는 뜻. ex) a[eo]t => aot 혹은 aet
[^A] => 문자는 올수 없다는 뜻~ A부터 Z까지~



? => 0개 또는 1개의 텍스트.
* => 0개 또는 1개 이상의 텍스트.
+ => 1개 이상의 텍스트. 0은 될수 없다.



그룹

(텍스트) => 위의 텍스트에 속한 세가지를 조합하여 쓸수 있다
예로 (..)는 두글자라는 거지요 ^^
몇번째 그룹이냐에 따라서 위에 설명한 $N의 변수로 불러 쓸수있니다.



Anchors

^ => 줄의 시작을 나타낸다 ex) ^a => a로 시작
$ => 줄의 끝을 말한다. ㄷㅌ) a$ => a로 끝
==========================================================================
출처 : http://mycastor.tistory.com/77
2013/04/05 14:40 2013/04/05 14:40
샤이 이 작성.

당신의 의견을 작성해 주세요.

문자셋(charset)

2013/03/07 16:21 / Linux/Mysql
문자셋 문제는 항상 개발자를 괴롭힌다. 나도 문자셋에 대해서는 제대로 이해하지 못하고 사용하고 있었던 것이 사실이다. 이 내용을 작성하면서도 매우 명쾌하게 모든 사실을 이해한 것은 아니지만, 그래도 도움이 되고자 글을 남긴다.

예전엔 EUC-KR 이라고 흔히 완성형 한글이라고 불렀던 형태의 인코딩을 사용했었다. EUC-CN, EUC-JP, EUC-TW 등의 인코딩 방식도 있었던 것으로 보아 나름 표준이었던 것 같다. 조합형 한글, 확장 완성형 한글 등의 방식이 있었지만 일부 글자를 표현하지 못한다던가 하는 각각의 장단점이 있었다.

지금에 이르러서는 UTF-8이라는 헝태로 통일되어 사용되어지고 있는데, 한글은 한자, 일본어 등을 포함한 모든 유니코드 문자를 모두 표현할 수 있다는 장점이 있기 때문이다.

위키백과 "UTF-8" (http://ko.wikipedia.org/wiki/UTF-8)



MySQL도 4.0 에서 4.1 로 넘어가면서 기존의 문자열 타입의 컬럼의 크기를 나타내는 방식이 byte 수에서 글자 수로 변경되었다.

예를 들어, varchar(10) 이 기존에 10 bytes 로 영문 10자 또는 한글 5자(한 글자에 2byte)를 넣을 수 있다는 의미였는데, 문자에 상관 없이 10글자를 넣을 수 있다는 의미로 변경된 것이다.


문자열 크기 변경 때문에 당시 4.0 에서 4.1 로 마이그레이션 하면서 데이터를 많이 날려먹었던 기억이 난다. 멀티바이트 컬럼의 크기가 절반으로 줄어서 생긴 문제라고 하는데, 당시에는 제대로 이해하지 못하고 넘어갔었다...


어쨋든, 상황은 리눅스 콘솔에서 INSERT를 시도하면 지정한 컬럼 크기 만큼 한글이 들어가지 않고 짤려서 나오는 증상이 발생하면서 부터 시작됐다.

 
mysql> show create table char_default;
+--------------+-------------------------------+
| Table | Create Table |
+--------------+-------------------------------+
| char_default | CREATE TABLE `char_default` (
`char` varchar(10) NOT NULL,
PRIMARY KEY (`char`))
ENGINE=MyISAM DEFAULT CHARSET=utf8 |
+--------------+-------------------------------+
1 row in set (0.00 sec)

위의 내용대로라면 char 컬럼의 크기는 한글/영문 구분없이 10글자가 들어갈 수 있어야 하는데, 실제 결과는 한글 3 + 1/3 글자가 들어가는 것이었다.

 
mysql> insert into char_default set `char`='가나다라마바사아자차';
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> select * from char_default;
+------------+
| char |
+------------+
| 가나다?
+------------+
1 row in set (0.00 sec)

처음엔 단순히 utf8 문자셋의 한글이 3 bytes 를 차지하기 때문에 varchar(10) 안에 10 bytes 만큼만 기록되는 것이다라고 생각을 했었다.

하지만 문제는 문자셋 세팅에 있었다. 리눅스 콘솔 자체의 문자셋이 utf8 인 것과 별개로, MySQL 클라이언트의 문자셋 설정이 latin1 로 되어있었기 때문이다.

 
mysql> show variables like 'c%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
| completion_type | 0 |
| concurrent_insert | 1 |
| connect_timeout | 10 |
+--------------------------+----------------------------+
14 rows in set (0.00 sec)


latin1 문자셋은 1글자가 1 byte 이다. utf8로 입력된 문자열 '가나다라마바사아자차'를 MySQL Client가 latin1 형태로 Server에 전달하다 보니, 한글 1글자당 3 bytes로 인식되어 결국, latin1 10 글자 만큼만 저장된 것인데, 마치 varchar(10)이 10 bytes 크기를 가지기 때문인 것 처럼 판단하도록 만들어버린 것이다.

이런 경우에는 간단히 아래 명령어로 해결이 가능하다.

 
mysql> set names utf8;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'c%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
| collation_connection | utf8_general_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
| completion_type | 0 |
| concurrent_insert | 1 |
| connect_timeout | 10 |
+--------------------------+----------------------------+
14 rows in set (0.00 sec)

MySQL Client의 세팅이 utf8로 정상적으로 적용된 후에, 기존에 입력되었던 row를 조회해보면 아예 깨져서 나오는 것을 볼 수가 있다. latin1 문자셋으로 입력되었기 때문에 latin1 환경에서 보면 한글이 보일지 모르지만, 윈래 의도했던 utf8 로 보면 전혀 맞지 않는 형태로 표현이 되는 것이다.

 
mysql> select * from char_default;
+-------------------------+
| char |
+-------------------------+
| e°€e??e?¤e |
+-------------------------+
1 row in set (0.00 sec)


정상적인 설정에서 한글을 다시 입력해보면,

 
mysql> insert into char_default set `char` = '가나다라마바사아자차';
Query OK, 1 row affected (0.00 sec)
mysql> select * from char_default;
+--------------------------------+
| char |
+--------------------------------+
| e°€e??e?¤e |
| 가나다라마바사아자차 |
+--------------------------------+
2 rows in set (0.00 sec)

정상적으로 10글자가 표시되는 것을 볼 수가 있다.

 
mysql> set names latin1;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from char_default;
+------------+
| char |
+------------+
| 가나다?
| ?????????? |
+------------+
2 rows in set (0.00 sec)

거꾸로 utf8 환경에서 정상적으로 입력한 row 도 latin1 환경에서 보면 제대로 보이지 않는다.
문자셋 혼동의 결과를 정확하게 판단하기 위해 다시 한 번 테스트.

 
mysql> insert into char_default set `char` = '가나다123';
Query OK, 1 row affected, 1 warning (0.03 sec)
mysql> select * from char_default;
+------------+
| char |
+------------+
| 가나다?
| ?????????? |
| 가나다1 |
+------------+
3 rows in set (0.00 sec)


위의 show variables 결과에서 볼 수 있듯이, 문자셋 환경도 Server, Client, Connection 등의 다양한 부분에 지정할 수 있다.

예를 들어 server에는 utf8로 저장되어있는 데이터지만, 콘솔의 환경이 euc-kr 일 때,

1
mysql> set names euckr;

로 설정하고 사용하면 문자셋 같의 변환을 mysql이 알아서 해준다.

추가로, MySQL 을 설치하고 초기 설정 할 때도 기본 문자셋을 잘 지정해 놓는 것이 중요하다.
위의 예시에서 server와 database 설정이 latin1로 되어있기 때문에 my.ini 환경설정에서 해당 부분을 수정 후 서비스를 재시작 하였다.

 
# vi /etc/my.cnf
# cat /etc/my.cnf
[mysql]
character-sets-dir = utf8
default-character-set = utf8
[mysqladmin]
character-sets-dir = utf8
default-character-set = utf8
[mysqlcheck]
character-sets-dir = utf8
default-character-set = utf8
[mysqldump]
character-sets-dir = utf8
default-character-set = utf8
[mysqlimport]
character-sets-dir = utf8
default-character-set = utf8
[mysqlshow]
character-sets-dir = utf8
default-character-set = utf8
[myisamchk]
character-sets-dir = utf8
[myisampack]
character-sets-dir = utf8
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
# old_passwords=1
# Disabling symbolic-links is recommended to prevent assorted security risks;
# to do so, uncomment this line:
# symbolic-links=0
character-set-server = utf8
default-character-set = utf8
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
# service mysql restart
# mysql -p
Enter password:

 
mysql> show variables like 'c%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| 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 |
| completion_type | 0 |
| concurrent_insert | 1 |
| connect_timeout | 10 |
+--------------------------+----------------------------+
14 rows in set (0.00 sec)



결과적으로, MySQL의 문자열 컬럼 크기는 byte가 아니라 글자 수라는 것이 사실이며,
사용자는 클라이언트, 서버, 커넥션의 문자셋 환경을 잘 맞춰주어야 원하는 결과를 얻을 수 있다는 것이다.

=======================================================================
출처 : http://docs.cena.co.kr/index.php?mid=textyle&category=13634&document_srl=19401
2013/03/07 16:21 2013/03/07 16:21
샤이 이 작성.

당신의 의견을 작성해 주세요.

create tablespace : 오라클 데이터베이스내에서 생성되고 처리될 테이블들의 레코들들이 실제로 존재할 영역을 디스크 상에 물리적으로 생성시키는 명령어이다.

tablespace_name : 생성될 테이블 스페이스의 이름이다.

datafile : 데이터베이스내에서 사용되는 레코드들이 실제로 디스크상에 파일로 존재하게 되는데, 이때의 파일의 위치와 이름을 지정하는 곳이다.

data_file : 데이터베이스내에서 사용되는 레코드들이 실제로 디스크상에 파일로 존재하게 되는데, 이때의 파일의 위치와 이름을 지정하는 곳이다.

data_full_file_name : 레코드들이 실제로 존재할 디렉토리(절대패스사용)와 파일의 이름이다.

size : 테이블 스페이스내의 레코드들을 저장할 디스크상의 파일의 최대 코기를 지정해 줄 수 있다.

datafilesize : 레코드들을 저장할 파일의 크기를 k(킬로바이트), M(메가바이트)의 단위를 사용하여 나타낼 수 있다.

initial : 테이블 생성시 해당 테이블에 할당되어 있는 영역의 크기를 지정해 줄 수 있다.

datafilesize_min : 테이블생성시 사용할 수 있는 공간의 크기로, 예를 들어 10m로 지정되면 생성된 임의의 테이블에 입력되는 데이터들을 10m의 영역에 저장한다는 의미이다.

next : 처음에 저장될 데이터의 영역인 initial만큼을 다 쓰고 더 이상의 공간이 없을 때, 사용할 수 있는 영역을 할당 시켜 준다.

datafilesize_max : 추가로 테이블에 데이터가 입력될 때, 사용할 수 있는 여역의 크기이다. 예를 들어 5M를 할당하여 두면, 임의의 테이블이 사용한 영역이 10M (위의 initial영역의 크기이다)를 넘을 경우, 주가로 5M만큼의 영역을 더 사용할 수 있게 된다. 따라서 총 사용공간은 15M가 된다.

minextents minuum : next 영역으로 할당할 수 있는 최소의 갯수를지정해 줄 수 있다.

maxextents maxnum : next 영역으로 할당할 수 있는 최대의 갯수를 지정해 줄 수 있다.

picincrease num : next를 지정하여 추가로 사용할 영역을 확장하고자 할 때, 늘어날 영역의 크기를 '%'로 나타낸 값이다. pct는 '%'를 의미한다. 예를 들어 picincrease 5라고 지정해 두면, next로 추가로 작업할 영역을 늘여 줄때, 처음에는 next롤 설정된 영역만을 확장시켜 주나, 두 번째부터는 next영역의 크기에서 5%만큼 더 크게 확장시켜 주게 되는 것이다.

online/offline : 테이블 스페이스 생성시 online이나 offline 중 택일하여 쓸 수 있으며, 생략하면 online을 의미한다.
online으로 설정하여 테이블 스페이스를 생성하면, 테이블스페이스를 생성함과 동시에 데이터베이스 사용자들이 사용가능하다는 것을 의미하며, 일반적으로 online으로 설정하여 사용한다.

-- 테이블스페이스 정보 조회
select * from dba_data_files;
select * from dba_tablespaces;

-- 테이블스페이스생성
create tablespace info_data
datafile '/oracle/infodata/infodata.dbf'
size 200m
default storage(
initial 80k
next 80k
minextents 1
maxextents 121
pctincrease 80
)online;

-- 테이블스페이스 online / offline
> alter tablespace tablespace_name offline;
> alter tablespace tablespace_name online;

-- 생성된 테이블 스페이스의 추가하기 공간 늘여주기
alter tablespace info_data
add datafile '/oracle/infodata/infodata/dbf'
size 100m;

-- 생성된 테이블 스페이스 크기 변경하기
alter database datafile '/oracle/infodata/infodata.dbf'
RESIZE 200M;

-- 테이블스페이스 변경하기
alter tablespace tax2110
default storage(
initial 1024k
next 2048k
minextents 1
maxextents 5
)online ;
pctincrease 기본이 50%이다

-- 테이블스페이스 자동확장 추가 (Automatic Extension)
alter tablespace tax2110
add datafile 'd:\tablespace\tax2110_03.dbf'
size 50m
autoextend on next 10m
maxsize 100m;
-> maxsize 를 지정할때 데이터 화일보다 크거나 같아야함.

-- 기존테이블스페이스에 자동확장 변경하기
alter database datafile 'd:\tablespace\tax2110_03.dbf'
autoextend on next 10m
maxsize 100m;

-- 테이블스페이스 삭제
drop tablespace tablespace_name
including contents --> 테이블스페이스의 모든 세그먼트를 삭제( 데이터가 있는 테이블스페이스는 삭제할수 없다)
cascade constraints; --> 삭제된 테이블스페이스 내의 테이블의 기본키와 유일키를 참조하는
다른 테이블스페이스의 테이블로부터 참조무결성 제약 조건을 삭제합니다.
$ rm kit.dbf -- Drop한 tablespace명의 Datafile이 kit.dbf일때.


-- 테이블 스페이스 의 물리적파일까지 삭제하기
drop tablespace test_tbs including contents and datafiles;

-- 오프라인 테이블스페이스
alter tablespace tax2110 offline;

-- 데이터베이스 사용자 아이디 생성 및 수정
create user 사용자아이디
identified by 비밀번호(새비밀번호)


-- 유저생성
create user panda
identified by panda123

default tablespace yswater_ts;


-- 생성한 유저에 권한주고 연결하기
grant resource,connect to panda;
grant dba to panda;

CREATE TABLESPACE SWERPDB_DATA
DATAFILE 'D:\DATABASE\SWERPDB_DATA01.ORA' SIZE 100M
AUTOEXTEND ON NEXT 10M MAXSIZE 4000M
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

CREATE TABLESPACE SWERPDB_INDEX
DATAFILE 'D:\DATABASE\SWERPDB_INDEX01.ORA' SIZE 100M
AUTOEXTEND ON NEXT 10M MAXSIZE 4000M
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

CREATE TEMPORARY TABLESPACE SWERPDB_TEMP
TEMPFILE 'D:\DATABASE\SWERPDB_TEMP01.ORA' SIZE 100M
AUTOEXTEND ON NEXT 5M MAXSIZE 1000M
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1024K;

-- USER 생성하여 tablespace를 USER에게 지정
create user swerpuser identified by swerpuser
default tablespace swerpdb_data
temporary tablespace swerpdb_temp;

-- USER에게 DB권한설정
grant connect, resource, dba to swerpuser;

-- drop user swerpuser cascade;

-- drop tablespace swerpdb_data including contents cascade constraints;
-- drop tablespace swerpdb_index including contents cascade constraints;
-- drop tablespace swerpdb_temp including contents cascade constraints;

grant CREATE DATABASE LINK, CREATE TABLE, ALTER ANY TABLE, BACKUP ANY TABLE, DROP ANY TABLE, SELECT ANY TABLE,INSERT ANY TABLE, UPDATE ANY TABLE, DELETE ANY TABLE,
CREATE PROCEDURE, CREATE ANY PROCEDURE, ALTER ANY PROCEDURE, DROP ANY PROCEDURE, EXECUTE ANY PROCEDURE, CREATE SESSION,LOCK ANY TABLE,COMMENT ANY TABLE,
CREATE SEQUENCE, CREATE ANY SEQUENCE, ALTER ANY SEQUENCE, DROP ANY SEQUENCE,SELECT ANY SEQUENCE, CREATE TRIGGER, CREATE ANY TRIGGER, ALTER ANY TRIGGER, DROP ANY TRIGGER,
CREATE VIEW, CREATE ANY VIEW,DROP ANY VIEW
TO RMUSER;




===========================================================================
출처 : http://bangganji.tistory.com/77
2013/02/28 11:19 2013/02/28 11:19
샤이 이 작성.

당신의 의견을 작성해 주세요.

ms-sql 쿼리를 실행 중 db명 입력시 특정 db명에서 오류가 발생 할 시

ex) use 디비명
     use www.aaa.or.kr


다음과 같이 사용 할 수 있습니다.

ex) use 디비명
     use [www.aaa.or.kr]
2013/02/07 10:19 2013/02/07 10:19
샤이 이 작성.

당신의 의견을 작성해 주세요.

RRD tool 사용 중 서버 이전이나 복구 시 다음과 같은 에러 메세지가 발생하며 동작이 안될 시
(ex: cacti 모니터링 툴)

ERROR: This RRD was created on another architecture

rrd 파일의 경우 32bit 와 64bit가 호환되지 않아 그냥 사용할 수 없습니다.

원본 rrd 파일이 있는 곳에서 rrdtool 로 xml 로 생성한 후 xml 파일을 사용할 시스템에서 rrd 파일로 복원
해서 사용하실 수 있습니다.

ex)
rrd 파일이 있는 디렉토리 상위에 특정 디렉토리를 생성한 후 (여기서는 ../rrd 로 생성)

다음과 같이 입력하여 현재 디렉토리의 *.rrd 파일을 ../rrd/*.xml 파일로 덤프

# for i in ./*.rrd;do rrdtool dump $i ../rrd/$i.xml;done

사용 할 시스템에 생성한 *.xml을 모두 복사 한 후 리스토어 (여기서는 ../rra 로 리스토어)

# for i in ./*.xml;do rrdtool restore "$i" "../rra/${i%.xml}";done

생성된 rrd 파일의 소유권한을 rrd 파일을 사용하는 데몬의 유저로 변환하는 것도 잊지 말아야 합니다.

#
chown cacti.cactiuser *.rrd

2013/01/29 18:08 2013/01/29 18:08
샤이 이 작성.

당신의 의견을 작성해 주세요.

아파치 errors 로그에 다음과 같은 메세지가 기록되며 아파치 종료가 되지 않거나 강제종료 등의 문제가 발생할 경우

[alert] (11)Resource temporarily unavailable: setuid: unable to change to uid: 99

자원이 일시적으로 사용 불가능함


아파치 mpm 의 MaxClients 설정 등으로 인해 특정 uid (ex:nobody) 의 서버 프로세스가 시스템의 허용 수를
초과 하였는지 의심해 볼 수 있습니다.

특정 사용자의 사용가능한 프로세스의 최대갯수 제한

확인 :
ulimit -u

설정:
ulimit -u 2048

ulimit 설정은 현재 세션에서만 적용 되며 기본값을 변경하기 위해서는 /etc/security/limits.conf 파일에 다음과 같이 등록하면 됩니다.

(사용자) (soft or hard or all) (옵션) (값)
*                -      nofile          2048
root             -      nproc           2048

2013/01/29 17:50 2013/01/29 17:50
샤이 이 작성.

당신의 의견을 작성해 주세요.

1.OS 튜닝과 마찬가지로, 웹 서버도 튜닝작업을 수행한다고 해서 웹 서버가 지니고 있는 성능이 2~3배 이상 향상되는 일은 없다.

어디까지나 본래 지니고 있는 서버의 성능을 충분히 발휘할 수 있도록 조정하는 것이 튜닝 작업이다.

2.웹 서버 병목현상

과부하로 웹 서버가 응답을 제대로 반환하지 못할 경우, 그원인이 되는 것은 웹 서버의 설정과는 관계없는 것이 대분분이다.

웹 서버는 비교적 안정된 소프트웨어로, 자체만으로는 시스템에 부하를 유발하는 소프트웨어는 아니다.

드러난 웹서버의 응답불능상태의 원인을 이 웹 서버에 있다고 할 수는 없다. 열이 나고 있다고 해서 해열하는 것만으로는 병이 낫지 않는 것과 마찬가지다.

이 상황에서는 아무리 아파치 설정을 만진다고 해도 그 외의 부분에서 문제가 발생하고 있는 이상. 의미가 없다는 것을 의색해야 한다.

아파치 설정을 변경하면서 상태를 살펴보는 대책이 아닌, 장애 원인을 찾기 위한 지식이 가장 중요하다.

[추측하지 말고 계산하라]

문제의 상당수는 ps나 sar,vmstat등의 툴을 사용하면 파악할 수 있다.

한편 "하드웨어나 OS가 충분히 성능을 발휘할 수 있는 상태" 이면서 "부하가 큰 상황"에서, 웹 서버의 설정으로 족쇄가 되는 항목은 분명히 있다.

3. 아파치의 병렬처리와 [MPM-mulity processing module]

아파치를 비롯하여 불특정 다수의 클라이언트에 공개된 네트워크 서버는 동시에 복수의 클라이언트로부터 접속되더라도 계속해서 처리할 수 있도록 병렬처리를 수행할 필요가 있다.

병렬처리를 수행하지 않는 서버에서는 특정 클라이엍느가 접속해서 서버와 입출력을 하고 있는 동안, 다른 클라이언트 서버에 접속할 수가 없다.

특히 아파치를 시작으로 하는 웹 서버는 얼마나 많은 다수의 접속을 동시에 처리할 수 있는가가 성능의 기준이 되는 소프트웨어이므로, 병렬처리의 구현이 서버의 성능에 미치는 영향이 상당히 크다고 할 수 있다.

*병렬처리의 구현 모델

- 프로세스를 여려 개 생성해서 병렬처리를 실현하는 멀티 프로세스 모델 [prefork]

- 프로세스가 아니라 보다 경량의 실행단위인 쓰레드를 사용하는 멀티 쓰레드 모델 [Worker]

- 입출력을 감시해서 이벤트가 발샣아는 타이밍에 처리를 전환하는, 시그널 쓰레드로 병렬처리하는 이벤트 구동 모델 [event MPM-실험모듈]

4. prefork와 worker, 프로세스와 쓰레드

- prefork

: 기본적으로 프로세스간에 메모리를 직접 공유하지는 않는다. 메모리 공간이 독립해 있으므로 안전하다.

: 안전지향, 후방호환성이 높은 MPM

- worker

: 멀티쓰레드에서는 메모리 공간 전체를 복수의 쓰레드가 공유하므로, 리소스 경합이 발생하지 않도록 주의할 필요가 있다. 이것이 멀티쓰레드 프로그래밍이 복잡하다고 하는 이유다.

: 확장성이 높은 MPM

mod_perl을 worker로 작동시킬 경우에는 펄이 ithreads로 쓰레드를 생성한다. 펄의 쓰레드 구현은 다소 특수하기 때문에, prefork로 작동시킨 경우와는 다소 사양의 차이가 있다. 이를 꺼려해서 prefork를 선택하는 사용자가 많을 수 있다.

5. 성능관점에서 본 멀티프로세스/멀티쓰레드의 차이

일반적으로 멀티프로세스 보다 멀티쓰레드 방식이 가볍고 더 빠르다고 한다. 주된 이유는 다음 두가지다.

- 복수의 메모리 공간을 각각 지닌 멀티프로세스보다 메모리 공간을 공유하는 멀티쓰레드쪽이 메모리 소비량이 적다.

- 멀티쓰레드는 메모리 공간을 공유하고 있으므로, 쓰레드 전환에 걸리는 비용이 더 적다.

실제 아파치를 이용함에 있어서는 어떨까.

메모리 소비에 관해서는 실제 멀티쓰레드를 이용한느 worker에 손이 올라간다.

다만, prefork방식에서도 멀티프로세스의 부보 자식 프로세스에서 갱신이 되지 않는 메모리 공간은 공유되므로(실질적으로 초반에는 70%이상 메모리 공유가 있다), 현저한 차이가 나는 것은 아니다.

또 한가지는 "컨텍스트 스위치" 비용의 차다.

멀티태스킹 OS는 서로 다른 처리를 수행하는 처리단위로 프로세스/쓰레드를 짧은 시간에 전환하여 병렬처리를 실현하고 있다.

이 때의 프로세스/쓰레드 전환처리를 "컨텍스트 스위치"라고 한다.

따라서 멀티쓰레드방식인 worker는 메모리 공간을 공유하기 때문에 메모리 공간의 전환처리는 생략할 수 있고, 이는 이에 발생되는 CPU상의 메모리 캐시를 사용하지 않고 그대로 유지할 수 있게 하므로 성능에 미치는 영향은 현저하다고 할 수 있다.

->정리

- prefork를 worker로 변경하더라도 하나의 클라이언트에 대한 응답시간이 고속화되는 것은 아니다.

- prefork를 worker로 변경하더라도 메모리가 충반하다면 동시에 처리할 수 있는 접속 수는 변하지 않는다.

- prefork를 worker로 변경하더라도 대량의 컨텍스트 스위치가 없다면(동시에 병렬적으로 대량의 액세스가 없다면)효과는 크지 않다.

"prefork를 worker로 변경했더라도 성능이 개선되는 상황은 제한되어 있다."

"메모리 용량이 크지 않거나 소비량을 줄이고자 할 경우, 컨텍스트 스위치 횟수가 많아서(대량의 액세스) CPU의 리소스를 줄이고자 할 경우 worker 방식으로의 전환을 고려해 볼 필요가 있다"

6. 하나의 클라이언트에 대한 하나의 프로세스/쓰레드

둘의 공통점은, 아파치 클라이언트로부터 온 하나의 요청에 대해 기본적으로 하나의 프로세스 혹은 하나의 쓰레드를 할당해서 처리한다는 점이다.

즉 동시에 10개의 클라이언트로부터 요청이 있을 경우,10개의 프로세스 또는 10개의 쓰레드를 생성해서 응답한다.

따라서, 동시에 생성할 수 있는 프로세스/쓰레드 수가 아파치의 성능을 좌우하는 항목이 된다. 이러한 프로세스/쓰레드 수를 제어하는 설정항목의 최적화를 찾는 것이 아파치 튜닝의 핵심이라 할 수 있을 것이다.

7. httpd.conf 설정 - 아파치의 안전판 MaxClients

웹 서버는 "언제 어느 정도의 트래픽이 발생할지는 예상할 수 없다"는 점을 전제로 설계되어 있다.

그래서 아파치는 프로세스/쓰레드 수를 부하에 맞게 동적으로 제어하여 한다. 그러나 동적으로 제어한 결과가 머신의 리소스를 고갈시킬정도로 많은 프로세스/쓰레드를 생성하는 것이면 곤란하다.

이 때문에 안전판으로서, "동시에 접속할 수 있는 클라이언트 개수의 상한값"이 준비되어 있다. 이 안전판이 없다면 해당 시스템이 허용할 수 있는 수 이상의 요청이 동시에 몰려올 경우, 메모리를 다 써버려서 OS가 hang-up되거나 CPU사용률을 모두 점유해서 응답불가능 상태가 되는 치명적인 장애를 초래하게 된다.

오버 요청이 있을 경우 Maxclients는 다음 동작을 하게 된다.

-처리를 마치지 못한 용청에는 대기행렬내에서 일정시간 기다려 준다.

-대기행렬이 넘쳐날 듯 하면 해당 요청에 대해 에러를 반환해서 클라이언트로 응답을 돌려준다.

이로써 OS 자체가 hang-up되는 등의 쵝악의 사태를 피할 수 있게 된다.

이 상한값은 정적인 값이다. 머신이 지니고 있는 리소스에 맞게 수동으로 설정할 필요가 있다. 이 조정이 아파치 튜닝의 핵심이 된다. 반대로 이 외의 항목으로 성능에 영향을 미치는 것은 많지 않다.

prefork - MaxClients

prefork의 경우 안전판이 되는 것은 ServerLimit와 MaxClients 라는 두 가지 디렉티브로 설정된다. 둘 다 아파치가 생성하는 프로세스 수의 상한값이다.

-ServerLimit : 서버 수, 이를테면 프로세스 수의 상한

-MaxClients : 동시에 접속할 수 있는 클라이언트 수의 상한

본래는 위의 의미이지만 하나의 클라이언트를 하나의 프로세스에서 처리하므로 양자는 거의 같은 의미다. (같은 값으로 설정하면 된다.)

문제는 어느 정도의 값으로 설정하느냐인데, "이 값으로 해야 한다"라고 단정된 수치는 없다.

상한 수치를 계산하기 위해서는 다음 두 가지를 먼저 알아야 한다.

- 서버가 탑재되어 있는 물리 메모리의 양

-프로세스 하나당 평균 메모리 소비량

전자는 하드웨어 스펙을 참조하면 알 수 있다.(free 등의 명령)

후자는 ps나 top으로도 확인 가능하지만, proc 파일 시스템을 통해 조사해 보겠다.

cat /proc/프로세스 PID/status

[root@nehal-testweb1 proc]# cat /proc/27350/status
Name: httpd
State: S (sleeping)
SleepAVG: 98%
Tgid: 27350
Pid: 27350
PPid: 19888
TracerPid: 0
Uid: 99 99 99 99
Gid: -1 -1 -1 -1
FDSize: 64
Groups: -1
VmPeak: 160576 kB
VmSize: 160572 kB
VmLck: 0 kB
VmHWM: 14728 kB <- 해당 프로세스가 실제 사용하고 있는 메모리 영역의 크기가 된다.
VmRSS: 14724 kB
VmData: 10196 kB
VmStk: 84 kB
VmExe: 536 kB
VmLib: 15376 kB
VmPTE: 248 kB
StaBrk: 19d80000 kB
Brk: 1a70f000 kB
StaStk: 7fffe86b1f00 kB
Threads: 1
SigQ: 0/63488
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001200
SigCgt: 000000018400446b
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
Cpus_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00ffffff
Mems_allowed: 00000000,00000001
[root@nehal-testweb1 proc]#

언뜻 보면 이 VmHWM 값으로부터 httpd의 각 프로세스의 평균값을 구하면 될 것처럼 보인다.

예를 들면 VmHWM: 14728 kB 의 경우 평균 메모리사용량을 15MB로 계산하고, 서버 총 메모리를 4GB, OS 할당을 512MB로 잡았을 경우 MaxClients의 값은 230이 되게 된다.

ex)

4GB(총) - 0.5GB(OS) = 3.5G

3.5GB/0.15GB = 230

그러나 이것만으로는 판단재료가 불충분하다. 리눅스는 물리 메모리를 절약하기 위해 부모 프로세스와 자식 프로세스에서 일부 메모리를 공유한다. 이런 공유 메모리를 고려하면 보다 큰 값을 설정하는 것이 가능하다.

"카피 온 라이트" -부모/자식 프로세스간 메모리 공유

모든 프로세스에는 부모 프로세스가 있다. prefork인 아파치의 경우 하나의 특정 httpd 부모 프로세스가 우선 가동해서 복수의 httpd 자식 프로세스를 생성한다. 부모와 자식은 서로 독립된 메모리 공간을 실현하기 위해 fork에 동반해서 부모로부터 자식에게 메모리의 내용을 있는 그대로 복사하지만 이러한 복사 처리는 매우 비용이 높은 처리이다.

그래서 리눅스는 fork 단계에서 가상 메모리 공간에 매핑된 물리 메모리 영역은 복사하지 않고 부모와 자식간에 이를 공유한다.

이러한 공유는 부모 자식에게 가상 메모리 공간은 각각 마련해 주고, 각각의 메모릭 공간으로 부터 동일한 물리 메모리 영역을 매핑함으로써 실현된다.

부모 혹은 자식이 가상메모리에 대해 쓰기를 수행하면, 해당 쓰기 작업이 수행된 영역만 더 이상 공유할 수 없게 된다.

역으로 쓰기 작업이 수행되지 않은 메모리 영역은 항상 계속해서 공유되어 있을 수 있으며, 이에 따라 메모리상의 페이지 중복을 피해서 메모리를 효율적으로 이용할 수가 있다.

이런한 구조를 " Copy on Write" 라고 한다. "쓰기 작업시에 복사한다" 라는 의미다.

카피 온 라이트로 공유 메모리 사이즈 확인

MaxClients를 설정하려면 실제로 사용하고 있는 메모리 영역 내의 공유 물리 메모리 크기도 고려할 필요가 있다.

공유 메모리 영역은 /proc/프로세스PID/smaps 의 데이터 참조로 확인할 수 있지만, 데이터량이 많으므로 그 자체로는 어렵다.

============================================================================
출처 : http://joe0912.blog.me/60101396833

2013/01/29 17:14 2013/01/29 17:14
샤이 이 작성.

당신의 의견을 작성해 주세요.

아파치 멀티 프로세싱 모듈 옵션 설정 시

MaxClients를 256 이상 설정하기 위해서는 아파치 소스를 수정하고 컴파일 해야 한다는 걸로
알고 있는 경우가 많습니다.

아파치 2.x 버전 이상부터는 소스에 최대치가 20000 으로 설정이 되어 있기 때문에 20000 이하는
따로 소스를 수정하고 컴파일 할 필요가 없습니다.

사용시에는 ServerLimit값을 MaxClients 보다 먼저써야되고 크게 잡아줘야 됩니다.

ex) httpd-mpm.conf

<IfModule mpm_prefork_module>
    StartServers             500
    ServerLimit             2000
    MinSpareServers       500
    MaxSpareServers       700
    MaxClients              2000
    MaxRequestsPerChild  500
</IfModule>
2013/01/29 17:08 2013/01/29 17:08
샤이 이 작성.

당신의 의견을 작성해 주세요.


MySQL 파라메터 중
skip_name_resolve





MySQL 레퍼런스를 보면


"skip_name_resolve를 적용하게 되면 MySQL 서버가 클라이언트들의 접속시 DNS LOOKUP 과정을
생략시킨다."



 


덧붙여서 인터넷에 있는 글들을 본다면 "그러므로 속도가 빠르다" (인터넷 대부분의 글들) ...... 라고
설명이 되어 있다.



 



오라클은 접근 하려는 스키마의 ID와 패스워드를 알고 있는 상태에서 각 서버간의 네트워크 접근 권한만 허용된다면,


리스너를 통해 마음대로 접속할 수 있다. ( 물론 sqlnet.ora 파일에 접근 제한 설정이 안된 상태)



 


하지만 그와 다르게 MYSQL은 DB가 자체적으로 ID PASSWORD
그리고 IP(HOST)를 체크한다.


위 3가지 조건 중 하나라도 만족을 하지 못한다면, DB에 접근 할 수 없다.



 


MYSQL의 계정 권한이 저장된 USER 테이블을 조회한다면 이러한 결과값을 볼수 있다.


(또한 hash 함수로 암호화 저장 되어 있는 password를 볼 수 있다.)



 


mysql> select user, host , password from
mysql.user;
+----------+---------------------+-------------------------------------------+
|
user | host |
password
|
+----------+---------------------+-------------------------------------------+
|
root | localhost |
*E74858DB86EBA20BC33D0AECAE8A8108C56B17FA |
| repl |
% | *A424E797037BF97C19A2E88CF7891C5C2038C039 |
| dumpuser
| 192.168.100.100 | *56C09388C92050AD66D96D207790DFBA76CD410B |


| testuser | kthcorp |
*56C09388C92050AD66D96D207790DFBA76CD410B
|
+----------+--------------------+-----------------------------------------------+



 


해당 계정들을 대상으로 하여서 서버로의 접근 상황을 예로 든다면


일단 해당 ID와 패스워드를 모두 알고 있다고 하여도 모든 계정들의 접근에는 제한이 있다.


왜냐하면 host 컬럼에 등록된 IP 권한들이 모두 다르기 때문이다.



 


1. root 계정의 경우 localhost 로 등록되어 있어서 로컬에서만 접근이 가능하다.


(보안상 root는 로컬에서만 접근하도록 허용하는 것이 좋다.)



 


2. repl 계정의 경우 %로 되어 있다.


%는 어디서 접근을 하던지 간에 무조건 id와 패스워드만을 알고 있다면 접근을 허용 해준다.



 


3. dumpuser의 경우 192.168.100.100이라는 곳에서만 접근을 허용 해준다.



 


4. testuser의 경우 kthcorp라는 호스트를 가진 클라이언트가 접근 요청시에만 허용
해준다.



 


위의 1,2,3 의 경우는 모두 MYSQL 서버가 클라이언트 접근 요청시 자체적으로 판단이 가능하다는 것을 알 수 있다.


하지만 4번의 경우 MYSQL이 kthcorp 라는 호스트명을 가진 서버가 어느 서버인지를 알 수가 없다.



 


그러므로 4번 testuser 계정이 접근을 요청할 경우,


MySQL 서버는 먼저 /etc/hosts 파일에서 kthcorp라는 호스트명을 가진 서버의 ip를 체크하여 접근을 허용해준다.



 


가상의 시나리오를 한가지 생각하자면,


MySQL 서버에 저러한 host명으로 등록된 계정들이 굉장히 빈번하게 접근할 경우,


그 때마다 MYSQL은 일일이 hosts 파일을 체크하며, 접근을 제한하려 하므로 서버에는 부하가 생길 것이다.


그러므로 skip_name_resolve 라는 파라메터를 설정하여 이러한 룩업 과정을 생략함으로,


서버에 접근 부하를 줄일수 있다고 한다면 이 얼마나 좋은 상황인가.....?



 


하여 직접 테스트를 해보았다.


결론은 skip_name_resolve 파라메터를 적용한다면, 위의 룩업 과정을 생략한다.


그런데 중요한 점은 인증 과정을 생략하고 접근을 허용해주겠다는 의미가 아니라,


이러한 인증 없이 그냥 HOST로 등록된 계정들은 무시하겠다는 의미이다....


그러므로 skip_name_resolve 파라메터를 적용한 순간부터는 HOST명으로
등록된 계정들은 모두 서버에 접근할 수 없다.


(localhost, ip, %로 등록된 계정만 접근할 수
있다)



 



일반적으로 DBA 조직이 운영하는 서비스 DB에서는


산발적으로 개별 클라이언트들을 모두 MySQL 서버로 붙게 하는 구성은 하지 않을
것이다.


DB 앞단에 존재하는 WAS 서버에서 커넥션을 조절하며, 관리를
하기에


이러한 skip-name-resolve와 관련된 이슈 사항을 접할 일은 사실상 흔치 않을 것이다.



 



/etc/hosts 파일과 mysql.user 테이블의 상호 연관성 테스트 시나리오



 


1. MySQL 서버 hosts 파일에 등록된 클라이언트 서버의 host ip 부분을 삭제 한후,


클라이언트에서 host로 등록된 계정 접속을 시도할 경우 접근이 불가능함을 알 수 있다.


단 최초 mysql 서버 오픈 이후 이미 인증한 hosts에 한해서는 hosts 파일을 삭제해도 접근이 가능함을 알 수 있다.


(메모리에 host 정보 기록됨)



 


2. skip_name_resolve 설정된 MySQL 서버에 /etc/hosts가 등록된 계정으로도 접근 불가능함을 알 수
있다.

=====================================================================
출처:http://www.cyworld.com/oracooler/9179996

2012/12/20 16:16 2012/12/20 16:16
샤이 이 작성.

당신의 의견을 작성해 주세요.

사용자 삽입 이미지
센토사 섬에 위치한 유니버셜 스튜디오.
정문 앞의 거대한 조형물이 내가 어디에 있는지 뚜렷하게 알려주고 있다.
매표소 앞 안내하는 아가씨가 우리가 한국인 이라는 것을 알아보고
신이나서 한국말로 안내를 해준다 아르바이트 하는 학생쯤으로 보이는데
한국에 우호적인 것 같아 기분이 좋다.


사용자 삽입 이미지
유니버셜 스튜디오는 여러 영화들을 컨셉으로 여러가지 즐길 거리를 만들어 두었는데
그 중 하나인 영화 "미이라"를 컨셉으로 한 놀이시설 입구.
롯데월드 매직아일랜드에 있는 지하 롤러 코스터에 미이라 영화 분위기를 첨가 했다고 생각하면 맞을듯..
가장 재밌는 놀이기구는 트랜스포머 와 배틀스타 갤럭티카.
사실 놀이기구의 수는 그렇게 많지는 않아 유니버셜 스튜디오 입장권이 꽤나 비싸게 느껴짐.


사용자 삽입 이미지
비가 내리는 타이밍에 입장한 워터월드.
망한영화 "워터월드"를 컨셉으로 쇼를 보여주는 내용으로 간략한 줄거리는
"나쁜놈들이 쳐들어와 남자 주인공이 여자주인공을 구출한다" 라는 내용.


사용자 삽입 이미지
쇼를 시작하기 전에 20여분 동안 배우들이 이러고 놉니다..
좌석은 색깔별로 존이 구분되어 있는데 앞쪽 구역에 앉으면 물벼락을 맞는다는..
마구 물을 뿌리는 와중에도 안전구역은 철저히 지킴.. 메인 쇼가 시작되고 나서도
모터보트 등등으로 마구 물을 뿌려준다. 물에 젖기 싫은 사람은 좌석을 고를때 신중히..

사용자 삽입 이미지
악당A의 특수능력 공중비행!
사용자 삽입 이미지
우리나라에도 아시아 최대 규모의 유니버셜 스튜디오 건설중이라고 하는데
얼마전에 부지 가격과 관련해서 논란이 있다는 기사를 본 듯함.
전체적인 분위기는 다른 유원지들과 크게 다를바는 없는듯 하다.


사용자 삽입 이미지

사용자 삽입 이미지
얌차에서 몇년 분의 딤섬을 몰아서 먹는 바람에 딤섬따위 쳐다보기도 싫었지만
미식가인 친구녀석이 꼭 먹어봐야 한다고 하는 바람에 들어간 "딘타이펑"
물 한잔에도 돈을 받는다 ㅋ.. 닭고기국물 딤섬국수와 꼭 먹어야 한다는 소룡포.
딤섬따위 보기도 싫었지만 맛있다...
딘타이펑은 한국에도 분점이 있으니 기회되면 들려봐야 할 듯.


사용자 삽입 이미지
이탈리아에서 젤라또를 너무 맛있게 먹어 거금 6천원 가량의 젤라또를 샀는데
화남.. 가격은 몇배 맛은 절반 ... 비추

사용자 삽입 이미지
싱가폴 ver 먹자골목 이름은 기억이 잘 안남..
현지인들이 많이 가는 곳이라는데 외국들은 대체로 한국과 달리 밖에서 사먹는걸 더 많이 하는 분위기 인듯
그러고보면 차이나타운의 아파트에도 부엌은 없는 구조 였던걸로 기억된다...
들어가 보진 않았지만 구조상 없는걸로...



사용자 삽입 이미지

한국인들이 꼭 먹는다는 칠리크랩.
숙소의 주인 아저씨 께서 "점보 씨푸드" 칠리크랩의 부당한 가격에 대하여 열변을 토하셔서
(주인장 아저씨의 말에 따르면) 맛이 비슷한 현지인들이 자주 찾는 합리적인 가격의 음식점
(이라고 쓰고 주인 아저씨가 소개료로 커미션을 받는 듯한 음식점.)에서 칠리 크랩을 먹었다.
떡볶이 양념과 살짝 비슷한 느낌이 드는 달콤한 칠리소스에 미니번을 찍어먹는 맛이 일품
게를 먼저 먹고 밥을 비벼 먹으면 정말 맛있다. 싱가폴에 오면 역시나 꼭 먹어봐야할 1순위
그 유명한 "점보 씨푸드" 표 칠리크랩도 괜찮을 것 같다 사실 가격과 맛은 그렇다 치고 시원한
강바람을 맞으면서 깔끔한 테이블에 분위기 있게 먹는 것도 나쁘지 않다고 생각 된다.
숙소 주인 아저씨는 깔끔하게 차려입고 양손으로 게를 뜯어먹는 것도 웃기다고는 하지만~

사용자 삽입 이미지

사용자 삽입 이미지
또 하나의 싱가폴 명물 사태.
현지인들이 맥주와 함께 즐겨 먹는 안주 중 하나
쉽게 말하자면 소스에 찍어먹는 직화구이 꼬치구이들.. 맛은 있는데 딱히 닭꼬치 보다 월등히 뛰어나다
라는 생각은 들지 않는다. 비첸향에서 사온 육포를 꺼내놓고 같이 먹으니 서빙하는 아주머니가
멋진 안주라며 엄지 손가락을 치켜듬 사실 칠리크랩이 소화가 다 되지 않아 더 맛이 별루 였었던 걸지도...

개인적으로 별 생각 없이 갑작스레 가기도 했고 비행기값을 투자한데 비해 일정도 짧았기에 뭔가 좀 아쉬움이
남는 싱가폴 여행.
물가도 생각보다 비싸긴 하지만 깔끔하고 치안이 좋아 가볍게 다녀오기에 좋은 여행지 인 것 같다.

한줄평 : 야경 분위기가 정말 매력적인 멋진 도시!
주의 : 꼭 연인이랑 갈것!

2012/10/24 23:49 2012/10/24 23:49
샤이 이 작성.

당신의 의견을 작성해 주세요.

: 1 : 2 : 3 : 4 : 5 : 6 : ... 14 :