728x90

이 강좌는 윈도우 2000 을 기준으로 작성하고 있기에... 그리고, 초급을 대상으로 하기는 하지만... 조금은 중급적인 부분도 사이사이 다루고 있기에... 조금은 내용이 깊어질 것도 같습니다... ^^

예를 들면 이번 강좌가 그러한 부분중에 하나이지요.. 조금은 중급적인 요소가 없지않은....

해서 이번 강좌는 OLE DB와 UDA(Universal Data Access) 에 대한 이야기부터 한번 해볼까 합니다.. 또한,이 부분을 좀 더 구체적으로 설명하기 위해서2001년 3월말에 나올 taeyo's Advanced ASP 책의 일부를 편집하여 사용할 것이기도 합니다. 히힛... (은근한 책 광고임다... ^-^) 국내 ADO, MTS, COM+의 대가인 최현진 사장(인브레인)님의 감수를 거친 부분이라.... 내용면에서도 조금은 흡족하지 않을까 하는 기대를 가져봅니다... ^^ 기대기대...

우리는 저번 강좌에서 Ms Access와 MS SQL 서버의 경우에 데이터베이스를 ODBC 세팅하는 부분까지 이야기해 보았습니다... 그렇다면 복습의 차원에서 여쭤보겠습니다... 왜??? 무엇땜시.. 우리는 ODBC를 세팅했던 것이었나요? 왜? 그렇게 하지 않으면 안되는 것이었던 것일까아아아아요....~~~~~

그 이유는... 데이터베이스로의 접근 때문이었습니다. 예전의 데이터베이스들은 폐쇄적이었기에.. 데이터베이스 자체에서 제공하는 클라이언트가 없다면 데이터베이스 서버로 접근할 수가 없었습니다.. 하지만, 그러다보니 서로 다른 데이터베이스간에 데이터를 공유하기에 어려움이 있었지요.. 해서, 이러한 폐쇄적인 것들을 개방적으로 오픈할 방법을 생각해 냈는데 그게 바로 ODBC 랍니다. Open Database Connectivity 라는 ODBC를 말이죠....

해서 우리는 웹쪽의 ASP나 Win32 어플리케이션들에서 특정 데이터베이스를 접근하기 위해서.. 그 연결통로라 볼 수 있는 ODBC 를 잡아야 했던 것입니다요... 그리고나면, 우리는 소스중에서 그 연결문자인 DSN 을 이용해서 해당 데이터베이스로 접근이 가능하게 되거든요.... ^^ 그래서 이전 강좌에서 열심히 ODBC를 잡았던 것입니다. ASP 에서 데이터베이스와 연동하기 위해서도 역시나 ODBC 의 연결이 필요하니까요

하지만, 그사이 세상은 놀랄만큼 바뀌고, 발전했지요. 그러니, 그 사이에 ODBC 를 능가할만한 것이 또한 등장할만도 하다는 느낌이 사정없이 들죠? 그렇습니다. 마이크로소프트는 그 사이에 이 방법을 구체하시켜서 ODBC 보다 뛰어난 성능을 가진 OLE DB 라는 것을 등장시켰습니다. 오옷... 대단한 MS (아부성은 아닙니다.)

그리고, MS는 ASP나 Win32 에서 ODBC나 OLEDB와 같은 연결통로를 통해서 데이터를 넣고, 조회하는 등의 작업을 하기 위해서 데이터를 핸들링 할 수 있는 기술을 또한 발전시켜 왔는데.. 그것은 바로 ADO 라는 것입니다. 이미 게시판을 어느정도 만들어 보신 분은 이미 만나보셨겠지만  ADODB.Connection, ADODB.RecordSet, ADODB.Command 등이 그것이랍니다.

다시 설명드리자면.. OLE DB는 RDBMS 에 접근할 수 있는 통로를 제공하는 역할을 담당하는 기술이구요..
(게다가, OLE DB 는 RDBMS 외에 비 관계형 데이터들에게도 접근이 가능합니다.)
ADO는 사실상의 데이터를 처리하는 역할을 하는 담당하는 기술입니다. OLE DB. 이름은 어디선가 자주 들어본 것... 좀 더 알아봅시다.진정코 OLEDB 그것은과연 무엇일까요? 이것은 마이크로소프트의 UDA라는 전략을 구현하는 기술중의 하나입니다...

어라? 그럼 또 UDA는 뭐야? 뭐가 이리 복잡해... -.- 라고 하실만도 합니다.  저도 그랬으니까요.. 하지만, 알고보면 무지 간단한 전략입니다. (단순하게 생각하면요) 하지만, 실제 이 전략에 의해 구현되는 기능들은 가히 몸서리쳐질만 하지요.. (물론, 못 느끼시는 분도 있을 수 있고, "그게 뭐...대단해?" 하시는 분도 있을 수 있습니다)
그렇다면, 알아봅시다. UDA 라는 것.. 그리고 그를 이루는 근간이 되는 OLE DB를 말이죠

UDA 란? UDA는 Universal Data Access를 나타내는 말입니다.

이것은 광범위한 데이터들을 접근할 수 있도록 하는 마이크로소프트의 기술로 UDA 전략이라고도 표현하죠. UDA라는 말은 일종의 개념적이며, 기술 전략적인 이름일 뿐이고, 실제로 이를 구현하는 것은 ADO와 OLE DB 입니다.뒤집어 이야기하면, ADO와 OLE DB를 사용하여 광범위하게 위치한 데이터들을 처리하게 하는 기술을 UDA라고 표현할 수 있을 것입니다.

그렇다?? 그렇다면 OLEDB는 무엇일까요?

여러분들도 어디선가 들어는 본 듯한 말일 것이기는 합니다. 하지만, 여러분들은 OLEDB 라는 단어보다는 아마도 ODBC에 더욱 친숙함을 느끼고 있을 겁니다. 지금까지 대부분의 프로젝트를 ODBC를 통해서 구현해 왔을터이니 말이져. 

그렇다면, 여러분이 프로젝트에서 사용한 ODBC의 역할은 무엇이었을까요?

다시금 이야기하자면 이기종의 데이터베이스를 접근할 수 있게 해주는 표준적인 방법으로 였을 겁니다. 거의 모든 관계형 데이터베이스를 접근할 수 있게 해 주는 것이 ODBC였으니 말이죠. 저의 경우도 인포믹스와 오라클에 대해서 ODBC를 이용하여 프로젝트를 수행해 본 경험이 있습니다. 인포믹스 때는 ODBC 가 안 잡혀서 죽는줄 알았습니다. .. 우찌우찌 성공하기는 했지만요... -.-  어쨋든 ODBC는 실로 멋진 기술임에 틀림없슴다.

그러나, OLEDB의 화려한 등장으로 인해 ODBC의 세상은 조금 흔들리고 있습니다. OLE DB는 ODBC보다 한층 이상을 뛰어넘는 모습을 보여주고 있으니 말입니다. 

놀라지나 마세요.... OLEDB는 말입니다.  이 녀석을 사용하면 말이죠. 그게 말입니다.... 두 - - 둥.....

이기종의 관계형 데이터베이스뿐 아니라, 비 관계형 데이터들에게도 접근할 수 있습니다.... 즉, SQL서버나, 오라클과 같은 RDBMS 뿐 아니라.. 메일폴더, 각각의 메일자체, 디렉토리, 웹 사이트등등.. 그러한, 비 관계형인 계층 구조적인 데이터들에게도 접근할 수 있게 한다는 것이지요.... 저의 경우 OLE DB란 단어를 처음 만난 것은 3~4년전 이었던 것으로 기억되는데요...  사실 그 때도 OLEDB를 통해서 관계형 데이터베이스 이외의 데이터들에게까지 접근할 수 있다는 이야기는 들었었지만, 어떻게 그것이 가능한지에 대해서는 그다지 많은 정보를 얻을 수 없었었던 기억이 있슴다.  하지만, 이제 ADO 2.5에 들어서며 이를 가능하게 하는 편리한 방법들이 등장하였다는 것이죠. 놀라시지 않나요? 전 무지하게 놀랬는데... 흠...

그렇다면, 놀래고 싶은 분들은 조금 놀래보시구요...
(진짜로 안 놀래다니.. 흠.. 일부러라도 놀라는 척 해주지..... -.-)
어쨋든 우리는 이제 OLE DB를 통해서데이터베이스외의 자료들에 대한 접근도 가능하게 된다는 것은  기억해 두시기 바랍니다. 물론, 앞으로도 대부분의 경우는 데이터베이스로의 접근을 위해 사용되겠지만, 기회는 열려져 있다는 것이죠. (익스체인지 서버관련 솔루션을 개발할 때는 100% 필수입니다. 이거..)

사실, 현재 2001년에 태오에게 주어진 임무가 바로 그러한 작업인데요.... Exchange 2000 Server 를 이용해서 웹 메일 시스템과 그룹웨어, 전자결재, KMS 를 구현하는 작업입니다. 그러다보니 데이터베이스가 아닌 메일 시스템에 접근할 방법이 필요하구요.. 저는 이를 OLEDB와 ADO2.5를 통해서 가능하게 하고 있답니다... ^^ 물론, MSDN을 참고해서요

자..... 다음의 그림은 UDA 아키텍쳐(Architecture) 입니다.

그림에서 볼 수 있는 것처럼 UDA 기술은 ADO와 OLE DB를 사용하여 SQL 데이터뿐 아니라 비 SQL적인 데이터들(메일, 텍스트, 디렉토리서비스등)에도 접근을 가능하게 하구요. 데이터를 처리할 수 있게 합니다. 또한, OLE DB를 통해서 기존의 ODBC를 통한 데이터의 연결도 이용할 수 있게 되어 있답니다. 이처럼 OLE DB를 통한 접근은 기존의 ODBC가 부족했던 점을 완전히 메꾸고 있구요... ODBC 때에 비해서 접근 속도도 많은 향상을 가져왔습니다. ..

그렇다고, 이 OLEDB 기술이 ODBC를 없애버리고 세상을 바꾸자는 의도를 가지고 있는 것은 아닙니다. 기존의 기술을 더욱 발전시키자는 데에 목적을 두고 있는 것이 OLEDB 기술인 것이랍니다. 유식하게 말하면, 온고지신(溫故知新)의 개념인 것이져.. 온고지신... 태오 한문도 쫌 함다...

잠깐 !! 잘모르겠는디요. ADO, ODBC, OLEDB 뭐가 무엇을 하는것이죠?

그렇습니다. 분명 혼란함을 느끼시는 분들이있을 것입니다. 
이 즈음에서 간단하게만 정리하고 계속나아가고자하는데요. 
ADO는 데이터를 다루는 개체이며, ODBC, OLEDB는 데이터의 제공자격입니다. 
무슨 말인지 잘 이해가 안 된다면 다음 예를 보도록 하세요. (이것은 단지 예일 뿐이기는 합니다)

우리에게는 동시통역기가 하나있다고 가정해 봅시다요. 
이를 동작시키면 외국말들이 자동으로 알아들을 수 있게 나온다고 가정합니다.
또한, 우리가 이야기하면 자동으로 번역해서 말을 전해주기도 하고 말이죠. 
대신에 그러한 기능을 사용하기 위해서는 그 통역기에는 통역하고픈 각각의 나라용 칩을 
기계에 추가해 주어야 합니다.

기본적으로 미국, 러시아, 일본의 칩은 제공된다고 가정합시다. 
이제 외국사람들을 만나는 것은 겁나지 않을 것입니다. 
만나면 즉시 이 자동통역기를 동작시키면 되니 말이죠. 하하.. 이젠 외제를 만나도 걱정없을 검다...
그런데, 갑작스럽게 남아프리카 사람을 만나게 되었습니다. 이 때도 걱정이 없슴다. 
남아프리카용 통역 칩을 사서 기계에 장착하면 되니 말이죠. 돈만 있으면... 하하

이 동시통역기가 바로 ADO라고 볼 수 있으며, 각 나라용 칩은 ODBC 라고 볼 수 있습니다. 
그리고 각각의 외국인들은 데이터베이스들이라고 볼 수 있고 말이죠. 이해가 가시죠?

그런 어느날, 기존의 통역기능을 좀 더 효과적으로 사용할 수 있으면서도, 
동물의 언어까지도 통역이 가능한 기술이 개발되었으니 그것이 바로 OLEDB 기술이라 
하더라는 말씀입니다.

주의할 것은 이렇게 원본 데이터를 우리가 사용할 수 있게 제공해주는 역할을 하는 것이 
ODBC, OLEDB 기술이구요. 이렇게 제공받은 데이터를 처리하는 기술이ADO라는 것.

어때요? 쏙쏙 들어오죠???


이제 여러분은 OLE DB 라는 것을 사용하면 뭔가 상당한 이익이 있을 것이라는 막연한 기대를 가지게 되었을 것입니다. 하지만, 그것은 막연한 기대로 끝나지만은 않을 겁니다... 실제로 상당한 성능의 향상을 가져다 주니까요... 그렇다면, OLE DB 라는 것은 어떻게 사용할 수 있을까를 여러분이 이제 충분히 궁금해 하실 시간이 되었네요..

ODBC 를 잡은 것을 여러분이 ASP 코드에서 사용하기 위해선, 이미 해보신 분들은 알겠지만.. 다음과 같은 코드를 통해서 가능합니다... ADO의 Connection 개체를 통해서 말이지요.

Dim adoCn
Set adoCn = Server.CreateObject("ADODB.Connection")

adoCn.Open "DSN=MyDB" 'Access일 경우
(혹은adoCn.Open"DSN=MySQLDB;uid=xx;pwd=xx" 'SQL 서버일 경우 )


소스에서 사용한 DSN은 이전 강좌에서 여러분이 세팅한 ODBC의 DSN 값을 사용해서 이루어집니다.  ODBC를 사용할 경우는 위와 같은 방법으로 접근해야 하지요.. 하지만, OLE DB를 사용할 경우는 ODBC와 같은 세팅은 필요치 않습니다.. 코드에서 단지 연결문자열만으로 아주 쉽게 사용할 수가 있게 되지요... 즉, OLE DB 를 사용하게 된다면 위와 같은 코드는 다음과 같은 코드로 바꾸어 사용할 수 있게 됩니다.

Dim strConnect, adoCn
Set adoCn = Server.CreateObject("ADODB.Connection")

str = "Provider=SQLOLEDB;Data Source=(local);Initial Catalog=pubs;user ID=xx;password=xx;"
adoCn.Open strConnect

중요한 부분은 소스중에서 커넥션 객체의 Open 메소드에 사용하는 연결문자열인데요..  소스중에 Provider=SQLOLEDB;Data Source=(local);Initial Catalog=pubs;user ID=xx;password=xx; 라고  되어져 있는부분이 그것입니다.

즉, OLE DB를 사용하기 위해서는 이 연결문자열만 잘 구성하면 그것으로 OK 라는 이야기가 되지요. 그렇다면, 이제 여러분이 외워야 할것은 이 연결 문자열임을 알 수 있습니다.  그렇다면, 이 연결문자열이 의미하는 것을 이제조목 조목 알아봅시다...  문자열 내에서 각각의 정보는 세미콜론인 ; 로써 구분이 되는데요...

첫번째 정보는 프로바이더 정보입니다.

Provider가 바로 그것이지요....  만일, SQL 서버를 사용한다면 SQLOLEDB 라는 문자열을 사용해야지만 SQL 서버용 OLEDB를 이용할 수 있게됩니다.  만일, ORACLE를 사용하려 한다면 MSDAORA 라는 OLEDB 프로바이더를 지정해야 하지요... ^^  이러한 각각의 OLE DB 프로바이더 이름이나, OLE DB 프로바이더는 각각의 데이터베이스 업체에서 제공합니다.  이것은 MS 에서 제공하는 것이 아닙니다. 즉, 여러분의 회사가 Informix 를 사용하고 있는데...  OLE DB 를 사용하고 싶어졌다면 인포믹스 측에 연락해서 OLE DB 용 프로바이더를 제공해 달라고 부탁하시면 됩니다. 
현재즈음이면 대부분의 데이터베이스 업체가 OLE DB 공급자를 제공해 주고 있을 겁니다. 아마도..말이죠. 그리고, 그것을 받아서 서버에 설치하시면 해당 데이터베이스 서버용 OLE DB를 사용할 수가 있게 되는 것이지요. 기본적으로 Windows 2000 에서 제공하는 것은 MS의 제품관련 OLE DB 들이라는 것을 기억하세요... ^^ 
여기서는 SQL 서버에 접속하려 하기에 Provider=SQLOLEDB 라는 것을 지정하였던 것이죠...  중요... 이 문자열은 다닥다닥 붙여쓰셔야 합니다. ^^

두번째 정보는 Data Source 입니다.

물론, 정보를 지정하는데에 특별한 순서가 있는 것은 아닙니다만... 일반적으로 이런 순서로 지정합니다. 기분 나쁘시다면 순서는 여러분 맘대로 하셔도 돼요... ^^  Data Source=(local) 이것은 사용하고자 하는데이터베이스 서버가 설치된 서버의 이름을 지정하는 것입니다. (local)이라고 지정하면 현재의 자신의 서버에 데이터베이스 서버가 설치되어져 있을 경우에 가능하구요...  네트웍의 다른 서버에 데이터베이스 서버가 있을 경우는...  그 서버의 서버이름을 기입해 주시면 됩니다. 예를 들어 네트웍 상의 Sony 라는 서버에 데이터베이스 서버가 있다면  이 부분을 Data Source=Sony 라고 주시면 된 답니다. 어렵지 않죠?

세번째 정보는 사용할 데이터베이스 정보입니다.

데이터베이스 서버안에 존재하는... 여러 데이터베이스중에 어떤 데이터베이스를 사용할 것인지 정하는 것이지요.... 하지만, 인자이름이 조금은 외우기 부담스러운...  Initial Catalog 이네요.. 어쨋든 외워야 합니다...  해서 소스에서는 Initial Catalog=pubs 라고 하였습니다. SQL 서버에서 기본적으로 제공되는 Pubs 데이터베이스를 사용하겠다고 지정한 것이죠...

네번째, 다섯번째의 인자는 User ID와 password 입니다. 이것은 SQL 서버의 해당 데이터베이스로 접근할 수 있는 계정 아이디와 비밀번호를 적어주면 됩니다...  중요한 것은 위의 문자열들은 띄워쓰기를 꼭 지켜주어야 한다는 것입니다. User ID에서 User 라는 단어와 ID라는 단어사이에는 꼭 한칸을 띄워주어야 합니다.  
Initial Catalog 도 마찬가지 이구요. 대, 소문자는 구분하지 않아도 에러가 안 나지만...  띄워쓰기는 반드시 지켜주어야 합니다. ^^ 반드시, 꼭, 기필코, 여하튼, 결사코, 겁나게. 

어렵지 않죠??? 그럼 지금부터 30초 드리겠습니다. 이 문자열을 외우시기 바랍니다.... 
어어... 스크롤바 내리지 말고 위로 올려서 어서 외우세요.. 어~~ 외우라니깐요...

 

흠....

외우기가 어렵다구요..??? 조금은 그럴 수 있죠. 하지만, 외우셔야 합니다. 
하지만, 아무리 외워도 또 시간이 지나면 까먹죠... 그렇기에 쉽게 이 OLE DB 연결문자열을 만들 수 있는 방법을 알려드리겠습니다. 이 방법은 꼭 외워두세요...

 

1. 먼저 바탕화면에 새로운 텍스트 파일을 하나 만듭니다. 그리고, 그 파일의 이름을 바꾸시는데 그 이름을  
    OLEDB.UDL 이라고 지정합니다. 파일 이름은 뭐라해도 상관없지만 확장자는 반드시 UDL이어야 합니다. 
    그러면 다음 그림과 같이 아이콘이 바뀔 것입니다.

2. 그 아이콘에 마우스 우측 클릭해서 등록정보로 갑니다. 그러면 아래 그림처럼 Provider이라는 탭이 나올텐데, 그 탭으로 가면 현재 여러분의 시스템에서 지원되는 모든 OLE DB 공급자들이 나올겁니다. 우리는 여기서 SQL Server 을 사용할 것이기에 아래의 그림처럼 그것을 선택하시구요.  다음 탭인 Connection 탭으로 이동하세요 (혹은 Next >> 버튼을 누르세요)

3. Connection 탭으로 이동하시면 다음과 같은 화면이 나올 것입니다. 그림에도 표시해 두었지만 먼저 1번 칸에
    는 접근할 데이터베이스 서버의 이름을 기입해 주세요. 만일, 로컬 서버에 데이터베이스 서버가 설치되어져 
    있다면 (local)이라고 하셔도 됩니다. 2 번 칸에는 해당 DB 서버로 접근할 수 있는 계정 아이디와 비밀번호를 
    기입하시면 됩니다.

위와 같이 설정하시고 나면 3번의 "Select the database on the Server" 의 콤보박스를 클릭할 경우 여러분이 기입한 내용을 기반으로 해당 데이터베이스 서버에 지정한 계정 아이디와 비밀번호로 접근을 자동으로시도합니다... 만일, 위의 그림에서 지정한 부분중 틀린 부분이 있다면 다음과 같은 에러가 날 수도 있습니다.

이 에러화면은 계정의 아이디가 없거나, 비밀번호가 일치하지 않을 경우 입니다. 이런 경우는 계정을확인하시면 됩니다. ^^  만일, 모든 것이 잘 맞아 떨어졌다면 다음 그림처럼 위의 윈도우는 현재 DB 서버가 가지고 있는 데이터베이스들이 나온답니다.

4. 이렇게 디비들이 마구 나온다면... 접근이 제대로 된 것입니다. ^^ 성공축하....추카추카

그러면, 우리가 사용할 MyDataBase 를 선택하고 바로 밑의 버튼인 Test Connection 을 꼭 누르세요. 
그럼 현재까지 지정한 것들을 가지고 다시금, 완전히, 실제로 OLE DB 접근 테스트를 합니다.
그리고, 성공하면 다음과 같은 메시지가 나오지요. 꼭 이거 나와야 합니다.

오홋홋... 마치 ODBC 잡을때와 비슷한 절차를 거치고 있네요.. ^^ 하지만, 이 작업은 반드시 해야하는 작업이 아닙니다.. OLE DB 연결 문자열을 도저히 외울수 없는 분들에게 유용한 방법이지요....

 

이렇게 세팅을 끝내고 난 다음에는 뭘 어떻게 하느냐?

5. 이제 세팅이 끝난 뒤, 바탕화면에 존재하는 OLEDB.UDL 을 "메모장"으로 로딩을 합니다. 
    그림과 같이 말이지요.. ^^

그러면, 메모장에는 다음과 같이 OLEDB 연결 문자열이 만들어져 있는 것을 볼 수 있을 것입니다.

비밀번호는 제가 일부러 *** 처리했음을 양해바랍니다.... ^^  또한, Persist Security Info=False; 라는 부분은 우리에게 필요없는 부분이기에.. 그림에서는 그 부분을 지우고 보여드림도 양해바랍니다. 원래의 결과에서는 Persist Security Info=False; 라는 부분이 있을 겁니다. 하지만, 우리에게는 그것이 필요없으니 지우셔도 무방합니다. 있어도 무방하구요..  ^^

고로, OLE DB 연결문자열을 외우시기 싫거나, 자체 CPU가 딸려서 잘 외워지지 않는 분들은... 이러한 방법으로 언제나 연결 문자열을 만들어 내면 되는 것입니다.... ^^ 어때요? 쉽죠??

자... 조금은 길었지만...

OLE DB를 통해서 데이터베이스를 접근하는 방법을 이제 장려해야 하겠다는 생각이 들으셨을 것이라 생각하구요.. OLE DB를 사용하기 위해서는 연결 문자열만을 외우면 된다는 것도아셨을 겁니다.

 

그리고, 윈도우 2000에서는 ODBC 보다는 OLE DB를 사용하는 것이... 훨씬 낫다는 것을 기억하세요... 여러가지 장점이 있으니까요... ^^ 그중에 하나는 ODBC의 경우 ASP에서 여러 개의 데이터베이스를 접근하기 위해선, 각각의 데이터베이스를 모두 ODBC잡아야 하는 반면, OLE DB 연결 문자열을 사용하면... 그러한 것이 하나도 없이 ASP 내부에서 여러 데이터베이스로 자유자재로 접근이 가능하게 됩니다. ^^

 

 

 

자... 이것으로 OLE DB 에 대한 이야기도 어느정도 이야기가 되었네요.. 더욱 궁금하신 것은 2001년 4월 초에 출시되는(된) 태오의 심혈의 대작... 두~~둥 

"taeyo's Advanced ASP to be professional"을 참고하세요

^^ 조금은 더 깊은 이야기가 있습니다. (과연 속아줄것인가?....)  그럼.. 이제 이러한 지식을 기반으로...  다음 강좌에서부터는 ASP에서 OLE DB를 이용해서 게시판을 만들어나가기 시작하겠습니다. 글 올리기를 시작으로 해서 말이지요... ^^  기대가 사정없이 되지요.. 크핫핫.... ...

그럼 다음 강좌에서..... 다시... 10000 나요~!


PS :Ms Access를 OLE DB로 연결하고 싶다면 Microsoft.Jet.OLEDB.4.0을 사용하심 됩니다. 해서, Ms Access 경우때의 연결문자열은 다음과 같이 만들어 사용하고는 합니다.

"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\temp\Nwide.mdb"

여기서의 Data Source 는 데이터베이스 파일의 경로를 적어주시면 됩니다. 반드시 물리적인 경로를요



출처 : http://www.taeyo.net/Columns/View.aspx?SEQ=224&PSEQ=15&IDX=3

728x90

'용어' 카테고리의 다른 글

클래스패스와 환경 변수, 그것이 알고 싶다.   (0) 2010.01.05
DBMS의 종류  (0) 2010.01.04
아카이빙(Archiving) 과 백업(Backup) 의 차이점  (0) 2009.11.12
당신도 데이터베이스 관리자인가요?  (0) 2009.07.08
DBA란?  (0) 2009.07.08
728x90

아카이브(Archive)

l        향후 엑세스될 필요가 있는 정보의 1차 소스

l        운영환경으로부터 고정 콘텐츠 또는 비정형데이터를 추출함으로써 운용 효율성 향상

l        장기간 보존

l        엔터프라이즈 아카이브는 대량의 오브젝트를 축적

l        정보의 보관주기 및 폐기 등을 위한 어플리케이션 및 비즈니스 정책이 고려되어야 함



백업(Backup)

l        복구 목적으로 사용되는 2차 사본

l        장애시 어플리케이션이 특정시점으로 복구될 수 있도록 함으로써 가용성 향상

l        단기간 보존

l        주기적인 데이터 덮어쓰기

l        정책적인 요구사항이 거의 없음



(출처 : 효성인포메이션시스템(주)Next Generation Content Archiving Solution Seminar, 2006년 5월 17일)

728x90

'용어' 카테고리의 다른 글

DBMS의 종류  (0) 2010.01.04
OLE DB에 대한 이야기  (0) 2009.12.17
당신도 데이터베이스 관리자인가요?  (0) 2009.07.08
DBA란?  (0) 2009.07.08
아직도 UTF-8을 안 쓰십니까?  (0) 2009.07.08
728x90

현장중계! 대한민국 개발자의 도전과 희망
1부, 기술 분야별 고민 해결 리포트

“당신도 데이터베이스 관리자인가요?”

고승훈 | 프로피아 오라클 기술팀장

데이터베이스를 처음 접하는 관리자가 갖는 막연한 두려움을 없애고 사소한 것이라도 원리에 충실한 지식만 있으면 어떠한 상황에서도 해결책이 있다는 것을 알려주기 위해서 이 글을 쓴다.

필자가 오라클을 접했을 때가 지난 1996년이었던 것으로 기억된다. 그때 버전은 7.0이었고 현재 버전이 10g로 변화하면서 Partitioning, Materialized View, Stream, Cache Fusion, Grid 등 새로운 기능 및 개념들이 많이 추가되었다. 
오라클을 처음 관리했을 때는 필자 역시 초보였고 뭐하나 작업을 하기 위해서는 명령문을 제대로 쓰고 있는가 하고 몇 번이고 망설이면서 사용했던 경험들이 많다. 필자의 초기 실수담을 하나 들자면 보통 오라클의 데이터베이스 파일의 확장자가 .dbf이다. 이전 파일 데이터베이스로는, dBASE IV들을 사용했던 경험자들은 알겠지만, 이것 역시 확장자가 dbf이다. 오라클을 몰랐던 필자는 오라클에서 사용했던 dbf 파일이 dBASE IV용 데이터 파일인 줄 알고 ftp로 전송을 시도했던 적이 있다. 물론 그날 전산실은 뒤집어졌음은 두말할 필요도 없다. 
필자의 생각에는 경험 없는 지식은 없다고 본다. 즉 머릿속으로만 기억하는 것은 지식으로써 의미가 반감된다는 것이다. 데이터 모델링, 재난 복구, 데이터베이스 운영 설계 등 생각만으로는 힘든 부분들이 많다. 특히 데이터 모델링 부분은 경험을 바탕으로 한 지식이 뒷받침되어야 한다. 이 글에서는 누구나 쉽게 이해할 수 있는 분야 중에서 재난 복구에 관한 필자의 경험을 통해 문제해결의 실마리를 푸는 각자의 열쇠를 찾기 바란다.

두 가지 순발력 테스트

글을 시작하기 전에 독자들에게 순발력과 관련된 상황문제를 제시해 보겠다. 5분이내로 정확하게 해답을 생각해내는 사람이라면 순발력이 좋다고 봐도 괜찮을 것이다.

“B지점의 입고량 좀 알고 싶소”

첫 번째 상황이다. 이것은 SQL문 작성에 관한 것인데 물류 쪽에서 가끔 나올 수 있는 질의다. 제품, 판매, 입고 등 3개의 테이블이 기본으로 주어지고 질의는 다음과 같다.

한 영업소 부장이 2004년 B지점에서 판매된 제품의 현재까지의 입고량을 보고 싶다고 갑자기 요청을 했다. 단순히 데이터만 보여주면 되었기 때문에 단순 조인으로 3개 테이블을 SELECT 작업을 했다. 그런데 이런! 결과가 10분이 지나도 나오지 않는 것이 아닌가? 당장 나온다고 큰소리 치고 시작했는데 10분이 지나고 20분이 지나도 나오지 않는 것이 아닌가? 등에선 땀이 나고 결국 30여분이 지나서야 결과가 나왔다. 그런데 이런 지점 코드가 B가 아니라 A라고 하면서 다시 결과를 보고 싶다고 한다. 이때 여러분은 어떻게 할 것인가? 또 다시 그대로 진행을 하여 30분 동안 기다릴 것인가?

답은 간단하다. 단순 조인 SQL문을 수정한 다음 질의를 하는 것이 낫지 않겠는가? 이제 질의문을 한 번 더 보자. 우리가 보고 싶은 것은 입고 현황이다. 즉 판매 쪽은 단지 판매가 된 제품코드를 얻기 위한 것이다. 그러므로 조금 더 생각을 하면 먼저 ‘2004년 A지점에서 팔린 제품 코드를 얻은 다음 이 코드를 가지고 입고량을 볼 수 있다’고 생각할 수도 있고, ‘2004년에 입고된 제품 중 2004년 A지점의 판매 내용에 있는지 여부를 체크한 다음에 있으면 입고량을 본다’라고도 해석할 수 있다. 이 두 가지의 경우에 따라 사용되는 SQL문이 달라진다. 처음에 제시한 내용에 대한 SQL문은 다음과 같이 나타낼 수 있다. 
<리스트 1>과 <리스트 2>는 서로 다르다. 그리고 맨 처음 생각했던 3개 테이블의 단순 조인과는 또 다르다. 결과는 단순 조인문과 <리스트 1>, <리스트 2>의 결과 값은 같다. 그러나 수행결과 시간에서 차이가 날 것이다. 왜 차이가 날까? 질의문 작성의 원칙은 ‘되도록이면 데이터를 줄여라’, 그리고 ‘필요 없는 조건수행을 하지 마라’이다. <리스트 1>은 데이터를 줄이는 부분에 충실한 것이고 <리스트 2>는 필요 없는 조건 수행을 없앤 것이다.

데이터베이스의 공간 할당

두 번째 상황은 데이터베이스 공간 할당이다. 여러분이 해결할 사항은 다음과 같다.

판매 입력을 배치 작업으로 진행하는 중에 갑자가 더 이상 EXTENTS를 증가할 수 없다는 메시지가 계속 나온다. 추가적으로 100MB짜리 데이터 파일을 추가했지만 같은 메시지가 계속 나온다. 오늘은 월말이고 내일 아침 판매회의 때 이달 말 판매 현황에 대한 보고서를 뽑기 위해서 영업부 직원들이 언제 작업을 할 수 있는지 물어보고 초보 데이터베이스 관리자였던 필자는 여러 방면으로 해결책을 찾아보고 있었다. 여러분들은 어떻게 할 것인가?

이 같은 문제는 데이터베이스 관리자가 겪는 에러 사항 중 가장 일반적인 문제라고 생각한다. 그런데 가끔 증가를 시켰는데도 문제가 계속적으로 발생하는 경우가 종종 있다. 요즘 버전에서도 가끔 일어나는데 우리가 아무 의미 없이 사용한 옵션 하나가 이러한 문제의 원인이다. 오라클에서는 ‘EXTENT는 연속된 공간의 세그먼트의 집합’이라고 한다. 이것을 기억하기 바란다. 예전에 필자가 겪었던 문제의 하나인데 디스크가 비쌌던 시절 ‘EXTENT 증가실패’ 메시지가 나와서 필자는 흔히 하는 방식대로 ‘ALTER TABLESPACE ADD .. ;’ 명령을 사용하여 증가를 시켰다. 사이즈는 100MB를 주었다. 그런데 동일 메시지가 발생을 했다. 이상하게도 전체적인 테이블스페이스 사용률도 70% 정도 밖에 안 되고 데이터 파일도 추가시켜 주었는데 발생을 했다. 여러분들은 어떤 측면으로 볼 것인가? 필자가 앞에서 했던 말 중 연속된 공간이라는 것을 떠올리면 답이 나올 수 있을 것이다. 그리고 EXTENT 증가시 그 크기를 어떻게 정하는지도 생각을 해라. 문제의 테이블 SALE이란 테이블의 PCTINCREASE 값이 기본 값인 50%로 되어 있었던 것이다. 그래서 EXTENT가 증가할 때마다 그전 크기의 50%만큼 계속 증가되어 최종적으로 약 80MB 정도가 마지막 EXTENT 크기가 된 것이다. 다음 EXTENTS의 크기는 ‘80+ 80*0.5= 120MB’가 되어서 새롭게 추가시킨 100MB로는 어림도 없었던 것이다. 그리고 전체 공간에서 30% 정도의 FREE 영역이 있다 해도 그것이 연속된 FREE 공간이라는 확신은 없다. 그래서 그 이후부터는 어떤 일이 있어도 PCTINCREASE 값은 0으로 설정한다. 
앞의 두 가지 상황에서 여러분들은 다른 선택을 했을지도 모른다. 그러나 문제를 어떤 방향으로 해석하느냐가 얼마나 중요한가를 느꼈을 것이며, 우리가 미처 인식하지 못했던 부분에서 나올 수도 있다는 사실이다. 항상 표면상의 문제뿐만 아니라 그 속에 숨어 있는 뜻을 알고자 하는 노력이 필요하다는 것을 필자는 두 가지 상황을 예로 들어 얘기하고 싶었던 것이고, 이제부터 필자가 쓰고자 하는 내용은 이러한 조그마한 지식이 어떻게 최악의 상황에서 필자를 구원했는지 이야기하려는 것이다.

최악의 상황은 예고 없이 찾아온다

지난 1999년쯤에 발생한 일이다. 필자는 전산실 데이터베이스 관리자로 근무하고 있었고, 그날은 일요일이어서 직접 회사 당직근무를 하고 있는데, 갑자기 영업부에서 회의 자료를 출력하는데 오류가 나온다는 것이다. 난 프로그램의 순간적인 오류로 생각하고 다시 시도해 보라고 한 다음에 전화를 끊었다. 그런데 이번엔 다른 영업부에서 전화가 왔다. 판매 자료가 조회 중에 갑자기 나오지 않는다는 것이다. 필자는 설마 데이터베이스가 어떻게 될 것이라고는 생각하지도 못한 상황에서 서버실로 들어가 보았다. 그 당시 필자의 회사는 다른 곳으로 이전하기 위해서 잠시 서버를 다른 곳에 옮겨둔 상태였기 때문에 서버 상태를 보기 위해서는 직접 그곳에 가야 했다. 서버실에 들어서니 상황이 생각했던 것보다 심각하다는 느낌을 받았다. 서버의 디스크에서는 소리가 ‘킥킥’하고 들렸던 것이다. 설마 디스크가? 그러나 이러한 필자의 생각은 적중했다. 디스크가 완전히 깨진 것이었다. 아침에 서버를 점검할 때에는 이상이 없었는데 한 시간도 안 지나서 디스크가 깨진 소리가 들린 것이었다.

백업은 당신의 수호천사

그 당시 필자의 회사는 백업 시스템이 제대로 갖추어지지 않았다. 데이터베이스 관리자로서 백업은 익스포트만 받았던 필자는 실제 물리적인 디스크에서 오류가 나자 복구할 수 있는 방법이 생각나지 않았다(그때 당시 왕 초보 관리자였음을 기억하기 바람). 만일 필자가 아카이브로 운영하고 있었고 백업 데이터 파일이 있었다면 아주 쉽게 복구한 다음 아무 일이 없었다는 듯이 무사히 당직근무를 마쳤을 것이다. 그러나 백업받은 데이터 파일은 한 달 전 파일이었고 더 큰 문제는 익스포트 백업은 테이프 이상으로 인해 복구가 불가능한 상태가 된 것이다. 백업도 없는 상황에서, 그리고 데이터베이스는 오픈되지 않는 상태에서 어떻게 한 달간의 자료를 살릴 것인가? 
그래서 필자는 항상 데이터베이스 관리자에게 당부하는 것이 백업이다. 흔히 하는 말로 “복구에 실패한 관리자는 용서할 수 있어도 백업에 실패한 관리자는 용서할 수 없다”는 말이 있다. 백업은 최대로 보수적으로 봐야 한다. 그 이유는 하드웨어라는 것들은 바로 몇 분 후에 무슨 일이 생길지 모르는 매체이기 때문이다. 테이프도 깨질 수 있고 백업 스토리지도 언제든지 망가질 수도 있다는 것을 초보 데이터베이스 관리자는 명심하기 바란다. 물론 최근의 장비들이 신뢰도가 높다고 하지만 가능성이 0%가 아니기 때문이다. 
사실 오라클에서는 데이터 파일에서 직접 데이터를 끄집어낼 수 있는 DUL(Data UnLoader)을 사용하여 깨지는 않는 데이터 파일에서 데이터를 복구할 수는 있겠지만 사실 당시에는 DUL이란 것이 있는지도 몰랐고 서비스 비용도 만만치 않은 이유도 있긴 하다.

침착한 대처는 좀 더 나은 상황을 만든다

우선 필자는 디스크 복구 여부를 확인하기 위해서 하드웨어 업체를 불렀고(물론 공유일이었으므로 서비스료를 지불했다. 당시 시간당 17만원으로 기억한다. 서비스료 산정은 다 알다시피 해당 엔지니어가 출발하는 시간부터 산출된다) 결과는 복구불능으로 파악되었다. 좀 더 복구와 관계된 조치를 하기 위해서는 미국으로 보내야 했고 기간은 한 달이 소요된다고 했다. 그러나 이 방법은 현재 상황에서는 불가능한 선택이었다. 그 이유는 바로 내일 아침에 바로 서비스가 되어야 했는데 한 달 동안 기다릴 수도 없었고 결과 또한 비관적이었기 때문이다. 그리고 깨진 디스크에 있는 데이터도 판매 데이터가 있는 디스크였기 때문에 한 달 전 자료가 있으므로, 필자는 마음을 비우고 한 달 동안의 판매 데이터를 수작업으로 입력하는 최악의 경우를 생각하고 조치방법을 생각했다. 
우선 데이터베이스를 정상적으로 오픈시켜야 했다. 오라클 관리자들은 알겠지만 No Archive Log 상태에서 데이터 파일이 깨졌을 경우에는 복구 자체가 되지 않는다. 필자는 우선 문제가 되는 데이터 파일을 offlline drop 옵션을 사용하여 오픈시켰다(<화면 1>). 또한 No Archive Log 상태로 운영 중인 데이터베이스는 offline만의 옵션으로 수행되지 않는다. 그리고 offline drop 옵션을 사용하면 해당 데이터 파일은 해당 데이터베이스에서는 영원히 사용하지 못한다.

<화면 1> OFFLINE DROP 옵션 사용 후 데이터베이스 오픈 


이때 필자의 머리에 한 가지 생각이 스치고 지나갔다(여기서부터는 약간의 데이터베이스 지식이 필요하다). 오라클 데이터베이스의 경우 하나의 테이블 스페이스에 여러 개의 데이터 파일이 존재할 수 있다. 처음에 설정한 데이터 파일이 모두 사용되면 또 다른 데이터 파일을 추가함으로써 결과적으로 하나의 테이블 스페이스에 여러 개의 데이터 파일이 존재하게 된다. 
문제의 판매용 테이블 스페이스는 4개의 데이터 파일로 구성된 것이었는데 그 중 하나가 깨진 디스크에 존재했고 이 데이터 파일을 offline drop 옵션을 사용해서 데이터베이스를 오픈시킨 것이다(<그림 1>). 필자는 그러면 안 깨진 데이터 파일에서 최근의 판매 데이터를 가지고 올 수 있는 방법이 있지 않을까 생각한 것이다.

<그림 1> OFFLINE된 데이터 파일 


그러면 해당 데이터가 어떤 데이터 파일에 있는지 알아야 하는데 이때 사용하는 것이 ROWID이다. 오라클에서는 하나의 row를 유일하게 구분하는 키 값이 ROWID이며 이 값의 포맷은 버전별로 약간 다르지만 오라클8 ROWID 포맷에 대해서는 다음의 <그림 2>에 나와 있다.

<그림 2> ROWID 포맷 


ROWID 값으로 해당 데이터가 어느 파일의 어느 블럭에 있는지 알 수 있는 것이다. 문제는 보통 테이블을 SELECT 작업을 해야 하는데 <화면 2>와 같은 에러가 나올 것이다. 이것을 보면 모든 데이터의 ROWID 값을 알기 위해서는 TABLE FULL SCAN을 해야 하는데 FULL SCAN을 하는 순간 ORA-00376 에러가 나온다는 것이다.

<화면 2> FULL SCAN시 에러 발생(ORA-00376) 


참고로 데이터가 어느 데이터 파일에 있는지 확인할 수 있는 명령문을 보면 다음과 같다. 우선 데이터 파일의 상대적인 파일 번호를 우선 알아야 되며, 해당 데이터의 ROWID에서 상대적 파일 번호를 찾아내어 비교하면 된다.

<화면 3> 상대적인 FILE 번호 


<화면 4> 상대적인 FILE 번호 


<화면 3>과 <화면 4>에서와 같이 해당 테이블 스페이스 TEST는 4개의 파일에 분포되어 있고 실제 데이터도 4개의 파일에 분포되어 있다는 것이 확인됐다(앞의 결과는 데이터 파일이 깨지기 전이므로 <화면 4>의 결과가 제대로 나온 것이다). <화면 4>에서 조건절에서 적절한 조건 값을 주면 조건 값에 맞는 데이터가 어느 데이터 파일에 있는지 나올 것이다. 
그러면 모든 데이터에 대한 ROWID도 알 수 없는 상황에서 어떻게 복구할 수 있을까? 해결책은 깨진 디스크에 있는 데이터 파일이 해당 테이블 스페이스에서 가장 먼저 만들어진 파일이라는 것에 힌트를 얻을 수 있다. 그리고 해당 테이블을 SELECT할 때는 이미 만들어져 있는 INDEX를 통해 SELECT를 해야 한다는 점, 이 두 가지를 기억해야 한다. 가장 먼저 만들어진 파일이라면 오래된 자료가 있을 가능성이 가장 높고 INDEX SCAN을 통해 최근의 데이터 중심으로 SELECT를 하면 정상적인 데이터를 얻을 수 있다. 필자의 경우에는 우선적으로 최근의 판매 데이터만을 얻으면 최상의 결론이었기 때문에 혹시 하는 생각으로 인덱스로 잡혀 있는 판매일자를 최근 한 달 것으로 SELECT를 해보았다. 결과는 대성공으로, 데이터를 가지고 올 수 있었다. 그때의 기분은 하늘을 날아갈 듯이 기뻤다. 왜냐하면 필자의 생각대로 진행이 되었기 때문이다. 이때가 개인적으로 하나의 도약을 할 수 있었던 상황으로 생각된다. 최악의 경우 수작업 입력을 생각했는데, 무작정 안 될 것이라고 포기하지 않고 데이터베이스의 기본적인 구조를 이해한 상태에서 적절한 조치를 통해 데이터를 복구할 수 있었던 것이다.

<화면 5>와 <화면 6>은 FULL SCAN과 INDEX SCAN의 차이를 극명하게 보여준다. 
<화면 5>와 <화면 6>에서와 같이 인덱스를 통한 데이터 SELECT 작업은 오류 없이 TRACE 결과를 보여주지만 해당 테이블을 FULL SCAN하는 경우에는 데이터 파일에 문제가 있기 때문에 ORA-376 에러가 난다.

<화면 5> INDEX SCAN 


<화면 6> FULL SCAN 


<그림 3> INDEX SCAN 원리 


사실 INDEX SCAN 원리(<그림 3>)는 초보 데이터베이스 관리자라도 모두 알 것이다. 그러나 중요한 요소는 그것을 적용시키는 순발력과 평상심일 것이다. 보통 당황하면 아는 것도 까먹는 경우가 많다. 특히 대안이 마땅하지 않는 경우에는 더욱 그럴 것이다. 그러나 모든 일이 대안이 없는 경우는 없다. 최악의 대안도 해법이 될 수 있기 때문이다. 그러므로 초보 데이터베이스 관리자에게 필자가 얘기하는 것은 우리가 의미 없이 지나가는 지식도 이런 상황에서는 아주 최선의 해결책이 될 수 있다는 것이다. “개똥도 약에 쓰려면 없다”는 말이 있는데 아주 흔해빠진 것이라도 정작 쓰려고 하려면 없다는 뜻이다. INDEX SCAN과 FULL SCAN은 데이터베이스에서의 아주 기본적인 개념이다. 이것을 정확히 이해하고 쓴다면 관리적인 차원에서도 많은 도움이 될 것이다. 필자도 처음부터 모든 것을 다 아는 것은 아니었고 기초적인 내용에 충실한 결과 현재가 있다고 생각한다.

기본에 충실하기 위한 생각

필자가 얘기하고 싶은 것은 항상 기본에 충실하고 아는 것도 다시 한번 보라는 것을 얘기하고 싶다. 사실 우리가 대부분의 업무에서 사용하고 있는 것은 아주 특별하고 어려운 기술을 사용하는 것이 아니고 일반적이고 쉬운 부분을 중심으로 이용한다. 이러한 일반적인 것을 해당 데이터베이스 시스템에 최선의 방안으로 선택하고 이용하는 것은 관리자의 몫이란 생각이 든다. 그리고 필자의 미숙한 글을 읽어준 사람들에게 감사를 드린다.


출처 : 마이크로소프트웨어 [2004년 11월호]

728x90

'용어' 카테고리의 다른 글

DBMS의 종류  (0) 2010.01.04
OLE DB에 대한 이야기  (0) 2009.12.17
아카이빙(Archiving) 과 백업(Backup) 의 차이점  (0) 2009.11.12
DBA란?  (0) 2009.07.08
아직도 UTF-8을 안 쓰십니까?  (0) 2009.07.08
728x90

http://cafe.naver.com/prodba/2040

728x90

'용어' 카테고리의 다른 글

DBMS의 종류  (0) 2010.01.04
OLE DB에 대한 이야기  (0) 2009.12.17
아카이빙(Archiving) 과 백업(Backup) 의 차이점  (0) 2009.11.12
당신도 데이터베이스 관리자인가요?  (0) 2009.07.08
아직도 UTF-8을 안 쓰십니까?  (0) 2009.07.08
728x90

ASP 등으로 되어 있는 이전 사이트들을 .NET으로 마이그레이션하다가 한번씩 겪는 문제점 중 하나는 그놈의 지긋지긋한 한글 인코딩 문제입니다.

 

그 유명한 베스트셀러(?)인 '조엘 온 소프트웨어'에서도 이러한 인코딩 문제에 대해 언급을 하고 있습니다. 미국애들 중에 몇몇이 여전히 ASCII를 쓰는 것처럼, 우리나라 개발자들 역시 여전히 KSC-5601이나 ECU-KR 인코딩을 고집하는 사람들이 많습니다.

 

심지어 일반 사용자들마저도 한글 인코딩과 관련된 문제를 겪어보지 않은 사람들이 없을 것입니다. 가장 대표적인 사례로, 페이지의 이미지가 보이지 않는 일은 누구나 겪어 봤을 것입니다. 실제 이미지가 없는 경우는 제외하고, 이 문제의 원인 중 99%는 이미지 파일 이름이 한글로 되어 있는 경우입니다.

대부분의 사이트 또는 지식검색 등에서는 IE의 옵션에서 URL을 항상 UTF-8로 보냄이라는 옵션을 꺼서 해결하라고 말하곤 합니다. 문제는 이것이 근본적인 해결책은 아니며, 한글 인코딩 문제의 해결을 더더욱 멀게 만드는 장벽이 된다는 것입니다.

 

잠깐 빗나갔는데 다시 개발에 대해서 초점을 맞춰서 다시 얘기해보겠습니다.

일반적으로 한글 인코딩과 관련된 문제가 말썽을 부릴 소지가 있는 경우는 다음과 같습니다.

1. 웹 페이지의 한글 컨텐츠가 KSC-5601이나 EUC-KR로 되어 있는 경우

2. 브라우저에서 호출하는 URL에 한글이 포함되어 있는 경우

3. 데이터베이스에서 한글 인코딩이 UTF-8이 아닌 다른 것으로 지정되어 있는 경우

 

먼저 1번의 경우..

근본적인 문제가 생기는 원인은 ASP.NET을 비롯하여 .NET에서는 기본 인코딩이 UTF-8인 것부터 출발합니다. 그러므로 예를 들어, 웹 페이지의 한글 컨텐츠가 KSC-5601이나 EUC-KR로 되어 있는 경우, 인코딩이 깨지게 되는 것입니다.

물론 이 문제의 잘못이 무조건 개발자에게만 있느냐하면, 절대 그렇지는 않습니다. 일반적으로 웹 페이지를 디자인하는 것은 웹 디자이너들의 몫이며, 이 디자이너들이 페이지를 디자인할 때 KSC-5601이나 EUC-KR을 사용해서 작성해버리는 경우가 대다수입니다.

또, 종종 개발자를 당혹스럽게 하는 것 중 하는 .inc나 .js를 통해 include한 파일의 경우입니다. 아무 이상 없이 잘 돌던 .js였는데, 단지 ASPX 내에 붙여 넣었다는 이유만으로 스크립트 에러가 발생합니다. 이러한 경우, 역시 십중팔구는 스크립트 파일 내에 한글이 포함되어 있는 경우입니다.

 

일단 이 문제를 해결할 수 있는 방법은..

각 페이지의 meta 태그 등에서 charset을 지정해주거나,

web.config에서 다음과 같이 인코딩을 지정해주는 방법이 있습니다.

 

<configuration>
   <system.web>
      <globalization 
         requestEncoding="ksc5601-1987"
         responseEncoding="ksc5601-1987"
         fileEncoding="ksc5601-1987"/>
   </system.web>
</configuration>

그런데, 이렇게 하면 정말 해결이 된 것일까요?

역시 이것 역시 임시적인 해결책에 지나지 않습니다.

더이상 인코딩 문제를 겪지 않으려면, UTF-8을 쓰는 것이 확실한 답입니다.

그러므로 바람직한 방법은 설사 디자이너가 다른 인코딩으로 전달을 해왔다고 하더라도, 메모장 등을 통해서 UTF-8로 변환해서 저장하는 것입니다. 스크립트 파일들 역시 메모장에서 연 다음 UTF-8로 변환해서 저장합니다.

 

2번의 경우.. 한글이 포함된 URL의 경우, 올바른 전송을 위해서는 한글을 URL에 맞게 인코딩을 수행해야 합니다.

 

예를 들어..

http://search.naver.com/search.naver?where=nexearch&query=한글인코딩&frm=t1

이 아니라..

http://search.naver.com/search.naver?where=nexearch&query=%C7%D1%B1%DB%C0%CE%C4%DA%B5%F9&frm=t1

가 되어야 한다는 것입니다.

(물론 네이버는 euc-kr 인코딩을 쓰고 있긴 합니다. -_-;;)

 

.NET의 경우..

문자열을 신뢰할 수 있는 URL 문자열로 만들기 위해 두 개의 메서드를 제공합니다.

HttpServerUtility.UrlEncode

HttpUtility.UrlEncode

 

이와는 반대로 다시 디코딩해서 원래의 문자로 돌리도록 다음 메서드들도 제공됩니다.

HttpServerUtility.UrlDecode

HttpUtility.UrlDecode

 

결국 Response 시에는 UrlEncode를 사용해서 인코딩을 하고, Request 받은 것을 처리할 때는 다시 UrlDecode를 사용해서 디코딩을 하는 형태로 해결을 하면 됩니다.

 

물론 이러한 부분을 처리하는데는 개발자의 귀차니즘이 수반되게 됩니다. 그 귀차니즘 덕분에 수많은 사용자들이 URL을 항상 UTF-8로 전송 옵션을 꺼야 합니다.

 

3번의 경우.. SQL 서버에서보다는 Oracle에서 많이 볼 수 있는 경우입니다.

상당수 Oracle 데이터베이스가 UTF-8이 아닌.. 심지어 US-ASCII7을 사용하는 경우가 있습니다.

대표적인 경우가 회사 내부에서 SAP을 사용하는 경우인데, 제가 알고 있기론 SAP 설치 시 기본 인코딩이 US-ASCII7인 걸로 압니다.

그래서 어떤 문제가 생기느냐? .NET에서 Oracle에 연결하기 위한 프로바이더로 ODP.NET이라는 놈이 있습니다. 이놈은 .NET이 붙은 넘 답게.. UTF-8을 사용합니다.

고로 ODP.NET을 사용하여 데이터베이스 인코딩이 US-ASCII7로 지정된 DB에서 한글 데이터를 읽으면 한글이 깨져버리는 사태가 발생하게 됩니다.

이에 대한 해결책은 DB 서버의 인코딩을 바꿔주거나, 쿼리에서 일일이 Encode 메서드를 사용해서 UTF-8로 변환하거나, 받은 후 애플리케이션 코드에서 인코딩을 변환시켜주는 수 밖에 없다는 것입니다. 어느 것 하나 쉬운게 없는데, 이러한 고생을 하는 이유가 한글 인코딩에 대해 무지했던 과거의 개발자/시스템 관리자들이 저질러 놓은 사고입니다.

 

사실 가장 이상적인 것은 Windows에서 인코딩을 UTF-8만 사용하도록 해버리면 확실한 해결책이 될지도 모릅니다. 대신 언젠가 만약 그런 날이 온다면, 기존의 UTF-8을 사용하지 않은 웹 사이트들은 문제가 생기게 되겠죠.

그러나, UTF-8이 표준화되었으므로 언젠가는 정말로 그런 날이 올지도 모릅니다. 그런 날이 오지 않기를 빌면서 통일을 반대하는 것보다는 하나씩 하나씩 바꿔 나가야 하지 않을까 합니다.

 

제발 이제는.. UTF-8을 쓰세요.

[출처] 아직도 UTF-8을 안 쓰십니까?|작성자 안재우

[출처] 아직도 UTF-8을 안 쓰십니까?|작성자 안재우


http://blog.naver.com/saltynut/120020091973

728x90

'용어' 카테고리의 다른 글

DBMS의 종류  (0) 2010.01.04
OLE DB에 대한 이야기  (0) 2009.12.17
아카이빙(Archiving) 과 백업(Backup) 의 차이점  (0) 2009.11.12
당신도 데이터베이스 관리자인가요?  (0) 2009.07.08
DBA란?  (0) 2009.07.08

+ Recent posts

티스토리툴바