제2의 비엔지니어 인생관을 꿈꾸며
connstr = "Provider=SQLNCLI10.1;Password=db_pass;Persist Security Info=True;User ID=dbuser_id;Initial Catalog=DB name;Data Source=ip address A;Failover Partner=ip address B"
set dbo = server.CreateObject("ADODB.Connection")
dbo.open(connstr)
set rs = dbo.Execute("select top 200 * FROM [DB].[table_id].[xxx]")
do while Not rs.Eof
Response.Write(rs(0) & "<BR>")
Response.Write(rs(0).Name & "<BR>")
rs.MoveNext
loop
%>
위 커넥트를 참조하여 셀렉트 쿼리문을 날리고 출력이 되면 바로 DB에 연결이 되는거죠. 필자는 주 서버를 바로 죽여서 스탠바이 서버가 주서버로 변경되고 난후 다시 사이트 접속을 해봤습니다. IP접속 활성화 상태가 바로 Partner B서버로 넘어가는게 보였습니다. 클러스터보다 더 빨리 쉽게 넘어간걸 보고 너무 놀라웠습니다만 다시 원래 주서버로 원복을 시켰을때는 DB서버에 연결이 되지 않았습니다. 즉 웹서비스라면 재시작을 해줘야만 연결이 가능했죠. 한번 Failover는 가능했지만 두번 다시 Failover 는 되지 않았습니다. 어플리케이션 단에서 DB 접속 Retry 옵션이 있어야만 가능하다는 말을 들었지만 클러스터처럼 VIP를 바라보는게 아니기 때문에 이부분에 대해서는 많은 연구와 테스트가 필요하다는 결론을 내려봅니다. 위그림처럼 DB미러링은 데이터의 완전성을 위한것이지 서비스의 완전성을 위한건 아니라는 결론입니다. 장애 대책을 임시나마 이용하면 더더욱 좋은 기능이지만 이걸 주목적으로 사용하다간 위험하다는거죠.
대부분의 데이타베이스 관리나 운영자들이 미러링 기능을 사용하지 않는거 같습니다. 전략적으로 좋은 기능인거 같다는 생각을 해봅니다만 비용상 효율적인 DB관리 솔루션은 미러링이 짱이다?라는 글을 남겨봅니다.
최신OS Windows2008 R2 버젼과 MSSQL2008 버젼에서의 설치문제는 여러가지 이슈가 있었습니다. 일단 R2버젼에서 SQL2008 클러스터 설치부터가 안됩니다. MS가 버그로 인정했고 그에대한 대책이 서비스팩1을 통합시켜 패킹시켜 설치를 하는 방법을 지시하였습니다.
윈도우XP에 클라이언트 접속툴도 설치에서 에러가 나기도 합니다.
그래서 결국 MSSQL2008은 무조건 SP1으로 통합시켜서 설치를 해야만 별 희안한 에러를 보지 않습니다.SP2가 나오면 SP2로 패킹시키면 더 좋겠지만 이에 방법은
1. |
Copy the original SQL Server 2008 source media to c:\SQLServer2008_FullSP1 . |
||||||
2. |
Download the Service Pack 1 package. The package names are as follows:
|
||||||
3. |
Extract the packages as follows:
Note Make sure that you complete this step for all architectures to ensure the original media is updated correctly. |
||||||
4. |
Run the following commands to copy the Setup.exe file and the Setup.rll file from the extracted location to the original source media location. |
||||||
5. |
Run the following commands to copy all files (not the folders), except the Microsoft.SQL.Chainer.PackageData.dll file, in C:\SQLServer2008_FullSP1\PCU\ Architecture to C:\SQLServer2008_FullSP1 \ Architecture to update the original files.
|
||||||
6. |
Determine if you have the Defaultsetup.ini file in the following folders:
If you have the Defaultsetup.ini file in the folders, open the Defaultsetup.ini file, and then add PCUSOURCE=".\PCU" to the file as follows: ;SQLSERVER2008 Configuration File [SQLSERVER2008] ... PCUSOURCE=".\PCU" If you do not have the Defaultsetup.ini file in the folders, create the Defaultsetup.ini file in the folders, and add the following content to the file: ;SQLSERVER2008 Configuration File [SQLSERVER2008] PCUSOURCE=".\PCU" Note This file tells the Setup program where to locate the SP1 source media that you extracted in step 3. |
||||||
7. |
Start the Setup program. |
MS기술지원 받을때 전달받은 지침서입니다. SP1으로 패킹시킨후로 아직까지 에러는 구경하지 못했습니다.
두번째로 여러사람들이 참 많이도 고생하는 통신포트 오픈 문제입니다. TCP 1433 포트만을 기억하는 사용자들은 UDP사용의 존재 유무를 모르고 있는게 대부분입니다. 필자는 MS엔지니에게 수차례 확인을 거쳤슴에도 불구하고 UDP는 오픈을 하지 않아도 된다라고 확답을 얻었지만 UDP 1434를 열어주지 않으면 DB서버에 접속을 할수 없었습니다. 왜그럴까?라는 의문을 계속 하던 찰나에 앗~!? 하며 생각난건 인스턴스 네임이 존재할경우입니다. 어떤건 TCP1433만 열었는데도 잘되고 어떤건 안되고 하는걸 참 희안하다 생각하는데 인스턴스네임을 찾아가야 하는거라면 UDP를 사용하겠구나라는 생각을 해봤습니다. 즉 이제까지 기본인스턴스로 사용해봤지 멀티인스턴스로 나가면서 네임을 붙여서 해보진 않았기 때문이였습니다. 우리가 흔히 사용하는 넷바이오스 네임을 사용할때 UDP를 열어줘야 하듯 SQL도 마찬가지로 네임을 사용해야 한다면 UDP를 사용해야 하겠지?라는 필자만의 판단입니다. 이게 아니라면 아니겠지만 확실하다고는 말을 못하겠습니다. 그냥 추측일뿐이지...(이런데 아는척 했다간 개망신 ㅋㅋㅋ)
MSSQL2005부터 SSIS 패키지라는게 있습니다. DTS 로컬패키지를 업그레이드 한거라 생각을 합니다만 기존에 DTS를 계속 사용해도 됩니다. 하지만 64비트 2008운영체제에 SQL2008이라면 예전 DTS는 실행이 되되 수정을 하기가 곤란합니다. 편법으로 dll수정과 여러가지 방법을 제공하곤 있지만 그냥 포기하고 SSIS로 마이그레이션 하고 거기서 약간 수정해서 사용하는것이 정신건강상 이롭습니다.
SQL에 대해서 많이 몰랐던 필자가 DTS란거까지 접하면서 결국 예전 방식은 그냥 포기하고 SSIS로 전환하는것이 SQL2008에대한 예의?ㅋㅋ 라고 봅니다. 예전거 고수해봐야 머리 아플거 뻔합니다.
암호로 보호된 SSIS 패키지의 경우 구성 탭을 클릭하여 패키지 암호 대화 상자에 암호를 입력합니다. 그렇지 않으면 암호로 보호된 패키지를 실행하는 SQL Server 에이전트 작업이 실패합니다. -SQL보안 정책우선 문제인지는 모르겠지만 암호화를 하지 않으면 실행이 되지 않는데 여러 담당 DB관리자가 존재한다면 암호화를 하지 않는다면 다른 DB서버의 정보를 볼수 있기 때문에 암호를 반드시 넣어야 한다는 권장사항이다. |