<게으른 프리랜서> 블로그 술이

제2의 비엔지니어 인생관을 꿈꾸며

29 Entries : Results for MSSQL

MSSQL DATABASE MIRROR

Posted
Filed under MSSQL

사용자 삽입 이미지
우리가 흔히 시스템에서 이중화라는 말을 하곤합니다. 서비스 이중화인지 데이터의 이중화인지는 관련업무 서비스가 어떻게 진행되느냐에 따라 달라지곤 하겠죠.
일일이 백업을 배치로 걸어놓느냐 아니면 클러스터를 하느냐 여러가지 DB 이중화에 대한 고민을 하게 됩니다. 그래서 MSSQL2005 이상부터는 DB 미러링이라는 기능이 있습니다. 정말 정말 좋은 기능중의 하나라고 장담합니다. 필자가 클러스터보다 더 매력을 느끼는 기능이 바로 미러링 기능입니다.
사용자 삽입 이미지
일단 클러스터는 공유볼륨을 구성하는 스토리지가 있어야 한다는것입니다. 비용 많이 듭니다. 하지만 미러링의 장점은 위 그림과 같이 PC든 가상화든 트랙잭션 I/O가 실시간으로 아주 심하지만 않으면(대규모 엔터프라이즈가 아닌한 이럴일이 거의 없다) 공간의 제한을 받지 않는다는것입니다. 레이드 미러링 처럼 DB도 미러링이 실시간으로 된다는것이 참 신기 하기만 합니다. 요즘 기가빗 네트워크 망을 이용하기 때문에 대여폭 걱정도 없습니다. 기가빗 대여폭을 감당하기에 디스크 I/O 성능 부터 걱정이 되니까요...
사용자 삽입 이미지
DB미러링도 Failover 기능이 가능합니다. MS에 기술 관계자에게 물어본 결과 위 내용을 들었습니다. 실질적으로 해본건 닷넷2.0 환경에서 해봤다고 하고 나머지는 테스트 시뮬레이션을 해보지 않았다고 합니다. 그럼 사이트를 닷넷 2.0이상만 해야되는 건가?라는 말을 하다가 기술 담당자는 ODBC,JDBC 다 된다고 전해주었습니다. 해당 링크 사이트도 전달해주더군요. 필자가 테스트 해본건 Native Client 커넥트를 사용했습니다. 개발자의 도움을 얻었죠.친한 개발자라 적극적으로 도와준 덕분에 이 결과를 얻었습니다.

<%

 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관리 솔루션은 미러링이 짱이다?라는 글을 남겨봅니다.

2010/02/28 03:40 2010/02/28 03:40

MSSQL2008 설치시 유의점

Posted
Filed under MSSQL

최신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:

•

SQLServer2008SP1-KB968369-IA64-ENU.exe

•

SQLServer2008SP1-KB968369-x64-ENU.exe

•

SQLServer2008SP1-KB968369-x86-ENU.exe

3.

Extract the packages as follows:

•

SQLServer2008SP1-KB968369-IA64-ENU.exe /x:c:\SQLServer2008_FullSP1\PCU

•

SQLServer2008SP1-KB968369-x64-ENU.exe /x:c:\SQLServer2008_FullSP1\PCU

•

SQLServer2008SP1-KB968369-x86-ENU.exe /x:c:\SQLServer2008_FullSP1\PCU

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.
robocopy C:\SQLServer2008_FullSP1\PCU c:\SQLServer2008_FullSP1 Setup.exe
robocopy C:\SQLServer2008_FullSP1\PCU c:\SQLServer2008_FullSP1 Setup.rll 

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.
robocopy C:\SQLServer2008_FullSP1\pcu\x86 C:\SQLServer2008_FullSP1\x86 /XF Microsoft.SQL.Chainer.PackageData.dll
robocopy C:\SQLServer2008_FullSP1\pcu\x64 C:\SQLServer2008_FullSP1\x64 /XF Microsoft.SQL.Chainer.PackageData.dll
robocopy C:\SQLServer2008_FullSP1\pcu\ia64 C:\SQLServer2008_FullSP1\ia64 /XF Microsoft.SQL.Chainer.PackageData.dll

Note If you accidentally copy the Microsoft.SQL.Chainer.PackageData.dll file, you may receive the following error message when you run the Setup.exe file.


SQL Server Setup has encountered the following error:
The specified action LandingPage is not supported for the SQL Server patchingg operation.
Error code 0x84BF0007



If this issue occurs, restore the Microsoft.SQL.Chainer.PackageData.dll file back to the original version.

6.

Determine if you have the Defaultsetup.ini file in the following folders:

•

C:\SQLServer2008_FullSP1\x86

•

C:\SQLServer2008_FullSP1\x64

•

C:\SQLServer2008_FullSP1\ia64

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에대한 예의?ㅋㅋ 라고 봅니다. 예전거 고수해봐야 머리 아플거 뻔합니다.

2009/12/08 23:41 2009/12/08 23:41

MSSQL2005,2008 DTS 패키지 실행

Posted
Filed under MSSQL
2005 버젼으로 넘어오면서 SSIS 패키지로 전환되고 기존에 DTS 로컬패키지는 구성요소와 호환성 관련 요소를 설치해야 한다. SQL에 대해 맨땅에 헤딩하는 필자로서는 하나하나 할때마다 항상 장벽에 걸린다.
2008 버젼부터는 32비트만 2000 DTS 패키지 수정이 가능하지만 64비트 버젼부터는 SSIS 패키지로 마이그레이션한후 비쥬얼 스튜디오로 수정작업을 해야만 한다. 이게 왜 안되나 했더니... <--- 이런줄 알았는데 아니다. 확인해보니 2008 서버 64비트 버젼까지 제대로 되었는데 현재 풀리지 않는 케이스가 2008 R2 버젼에서 DTS 구성요소를 설치해도 자꾸 설치하라고 에러 메세지를 출력하고 있다.MS에 케이스 진행을 하고 나면 버그인지 아닌지 업데이트가 나올런지는 모르겠지만 뭔가 해결이 되겠지뭐.
확장자가 dts에서 .dtsx로 만들어지고 기존에 구성이랑 크게 달라진점은 모르겠지만 실행 방법또한 2000이랑 많이 달라서 장벽에 장벽이였다. 이것저것 많이 엔지니어한테 물어본결과 크게 달라진건 없고 약간의 방식만 다를뿐 거의 같았다. 보안이 업그레이드가 되어서 마우스로 한다고 그리 만만한게 아니였으니 SQL의 S자도 모르는 필자가 삽질의 단계를 거치는 날의 연속이다.
사이트를 찾아본 결과 다음사이트에서 설명을 잘해주고 있다.

http://msdn.microsoft.com/ko-kr/librar ··· %29.aspx

필자가 현재 성공한 방법으로는 dtexec 커맨드를 이용한 실행방법이다. SQL 작업스케쥴에 등록했더니 SSIS 암호풀이 문제에서 걸리는건지 뭔지 몰라서 작업실패가 떨어진다. 그냥 윈도우 스케쥴 작업에 배치로 걸어놓는게 편할건지 SQL잡에 넣는게 편할건지는 아직 고민이다.
MS에서 SQL지원 담당자가 회사에 들어오니 이부분을 물어보면 이유가 뭔지 알겠지 뭐.
암호로 보호된 SSIS 패키지의 경우 구성 탭을 클릭하여 패키지 암호 대화 상자에 암호를 입력합니다. 그렇지 않으면 암호로 보호된 패키지를 실행하는 SQL Server 에이전트 작업이 실패합니다.
-SQL보안 정책우선 문제인지는 모르겠지만 암호화를 하지 않으면 실행이 되지 않는데 여러 담당 DB관리자가 존재한다면 암호화를 하지 않는다면 다른 DB서버의 정보를 볼수 있기 때문에 암호를 반드시 넣어야 한다는 권장사항이다.
2009/11/17 09:37 2009/11/17 09:37

MSSQL 백업후 복원시 로그인 사용자 계정 오류해결

Posted
Filed under MSSQL
A서버의 SQL계정과 B서버에서 A서버의 SQL계정을 동일하게 만들었다고 하지만 내부적으로 다른 계정이 되는것입니다. 스키마 문제일수도 있고 SID값을 인식하는지도 모른다는 생각을 해보는데...

이러한 문제를 해결해주는것이 sp_change_users_login 저장 프로시져입니다. 이 저장 프로시져를 이용하면 복원된 데이타베이스의 계정과 새로 만든 로그인 계정을 연결 시켜 줄 수 있습니다.

USE DATABASE
go
EXEC sp_change_users_login 'Update_One', '계정', '계정'

위와같이 하면 복원된 데이타베이스의 사용자 권한에 문제를 해결할수 있게 됩니다.


위사항을 모르고 있었던 필자는 테이블을 내보내고 일일이 계정 생성하고 권한 넣어주고 소유자 넣어주고 모든걸 수동으로 노가다 했던적이 있었음..
2009/10/15 09:36 2009/10/15 09:36