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

Posted
Filed under MSSQL

예전에 MSSQL2008을 설치 운영하면 많은 케이스를 경험했었습니다. 여러가지 참 별개 저를 시험하더군요.

http://blog.sooli.com/310

위내용에서 UDP 1434 접속 문제가 바로 인스턴스 접속문제였습니다. 네임을 통해야 하는 상황이라면 바로 UDP통신을 해야되는 문제가 있습니다. 하지만 방화벽에서도 전혀 문제가 없는데도 APP서버에서 접속을 못하고 Linked Server 접속도 인스턴스 네임접속이 되지 않는 문제가 있었습니다. MS기술지원에서도 온갖 패킷분석을 해봐야 한다고 하지만 답답하기만 했습니다. 원인이 뭘까... 왜 윈도우 서버는 필자를 시험에 들게 할까?라는 생각을 곰곰히 해봤습니다
그래서 정말 구체적인 원인은 모르지만 팁은 알게 되었습니다. 팁. 정말 유용한 팁입니다.

"사용자

바로 ODBC 연결 테스트입니다. 한번 이 테스트를 해주면 캐쉬값이 저장되는지는 모르겠지만 인스턴스 네임 접속이 언제 안되었냐는듯 바로 잘됩니다. 이거 한번 안해줄때까지는 죽어라 안되었던 하루가 있었습니다. 원인은 모르겠습니다. MS를 욕하는거죠 ㅋㅋㅋ. MS제품이라면 찬양하던 필자가 MS제품 넨자 이러고 있습니다 ㅋㅋㅋ.
인스턴스 네임 접속에 어려움을 겪는 엔지니어 분명 있을거라 장담합니다. 이부분을 알고 있다면 삽질은 피할것입니다.
큰 데이타베이스 서버가 아니라면 대부분 기본인스턴스로 운영하기 때문에 이런 문제를 경험하기 힘들겠지만 클러스터 서비스를 운영하는 서버중 Active Stanby 서버를 각각 인스턴스를 만들어서 Active Active 로 운영하는 경우도 흔히 있습니다.
2010/05/28 21:33 2010/05/28 21:33
Posted
Filed under MSSQL

OLE DB provider "SQLNCLI10" for linked server "XXXXXX" returned message "The stored procedure required to complete this operation could not be found on the server. Please contact your system administrator
 


master database:


create procedure sp_tables_info_rowset_64


@table_name sysname,


@table_schema     sysname = null,


@table_type nvarchar(255) = null


as


declare @Result int set @Result = 0


exec @Result = sp_tables_info_rowset @table_name, @table_schema, @table_type




MSSQL2008 서버에서 MSSQL2000서버로 링크드 서버 접속이 위 에러가 발생합니다. 위와같이 저장프로시져를 만들어줘야 하는 이슈가 있고 만들어진 프로시져에 권한을 넣어줘야 합니다.
MS에 문의해 본결과 2008버젼이여서 문제가 된게 아니고 64비트에서 32비트로 접속을 할려는데 문제가 발생하는거라고 합니다.
http://support.microsoft.com/?id=906954

2010/05/19 16:35 2010/05/19 16:35
Posted
Filed under MSSQL

MSSQL2000에서 2005로 그리고 2008로 업그레이드, 마이그레이션을 하는 경우가 많이 생기는거 같습니다. 필자도 SQL2000에서 2008로 데이터를 통합시키는데 많은 고민과 강사의 강의로 인한 공부도 많이 했습니다. 업그레이드를 하면 안되는게 많기 때문에 못한다?라는 편견은 일단 버리고 어플리케이션의 수정 보완작업이 시간이 걸리고 많이 힘들다고 판단이 된다면 호환성모드를 올리지 말고 그대로 80모드로 유지를 하는 방법도 있습니다. MSSQL2008만의 특별기능을 사용하지만 못할뿐이지 운영상에는 전혀 지장을 주지 않습니다. 먼저 포스팅에서는 DTS패키지 문제는 SSIS패키지로 마이그레이션하고 수정보완작업을 해야하는 번거로움이 있지만 MSSQL2008의 성능과 안정성 및 관리에서는 참 좋다라는 결론을 내려봅니다. 필자는 DBA가 아니여도 시스팀 엔지니어가 MSSQL2008을 관리 운영할수 있게 잘 나왔다는 생각을 간간히 했습니다. 위 PDF 문서에 나온것처럼 쿼리문 수정작업이 필요합니다. 기존 MSSQL2005버젼에서 2008버젼으로 올리는 경우는 이런 호환성 문제가 없어서 바로 올려도 문제 없다는 MS강사의 말을 들었습니다. 2000에서 2005나 2008로 올리는게 주 이슈 문제가 있지만 2005에서나 2008에서는 특별히 없다는것입니다.
일단 Action Plan은 기존 80모드에서 테스트를 거치고 90이나 100모드로 올리는 과정을 거쳐야 합니다. 아니면 DB Name을 다르게 해서 하나는 80모드 하나는 100모드로 둘다 같이 운영해보는것도 좋은 방법입니다.
그러나 대부분의 업무 담당자들은 잘되는거 좋게 한다고 바꿀려고는 안합니다. 잘못되면 책임부터 온갖 뒷치닥 거리의 일은 다 해야되는 경우도 생길수 있어서입니다. DBMS 업그레이드는 신중해야 하는것도 맞지만 일부 요령만 갖고 있으면 어렵지 않게 무난한 작업을 마칠수 있다라는 결론을 내려봅니다.
2010/05/12 14:51 2010/05/12 14:51
Posted
Filed under MSSQL

1. 복구 모델을 SIMPLE로 변경 후 DBCC SHRINKFILE을 수행 
 
2. BACKUP LOG <dbname> TO DISK = 'NUL' 을 실행 후 DBCC SHRINKFILE을 수행
 
3. 로그 백업을 받고 DBCC SHRINKFILE을 수행

USE [master]
GO
ALTER DATABASE [dbname] SET RECOVERY SIMPLE WITH NO_WAIT
GO

USE dbname
DBCC SHRINKFILE(dbname_Log,100)

USE [master]
GO
ALTER DATABASE [dbname] SET RECOVERY FULL WITH NO_WAIT
GO


MSSQL2008에서는 로그 정리하는 구문이 바뀌거나 없어졌습니다. SQL사이트에서 위 3가지 방법을 제시해주더군요. 전 1번만 알고 있었는데 단순모드로 변경 안해주더라도 작업을 실행할수 있는 방법이 있었다는걸 알게되었습니다.




트랙잭션로그정리(2005 버젼까지만 TRUNCATE_ONLY가 된다)

------------------------------------------------------------------  
USE Master  
GO  
BACKUP LOG DATABASE WITH TRUNCATE_ONLY  
------------------------------------------------------------------  
USE DATABASE  
DBCC SHRINKFILE(DBNAME_Log,100)  
------------------------------------------------------------------

2010/04/14 09:01 2010/04/14 09:01
Posted
Filed under MSSQL
BACKUP DATABASE DBName TO disk='\\servername\sharename\backupfile.bak'

ex) backup database soolidb to disk ='\\192.168.0.123\db-bak\soolidb.bak'

sql서비스 시작계정 권한이 해당 네트워크 드라이브 접근 경로 권한에 있어야 됨.

하드디스크 용량이 없고 풀백업을 받아야 하는 생황이라면 여러가지 고민을 하게 됩니다. 기존 MDF와LDF화일을 받아갈려면 오프라인 시켜야만 화일 접근이 가능하기 때문에 운영중에 DB를 백업 받아야 하는 상황이 연출되곤 합니다. 요즘은 대부분 로컬 대여폭이 기가빗 대여폭을 사용하기 때문에 자체 하드디스크에 백업을 받기보단 네트워크 드라이브로 백업을 날려주는것도 좋은 방법이라는 생각을 해봅니다. 대부분 서버에 디스크 용량이 많이 남아 있지 않은데 로컬디스크에 풀백업을 남겨두는건 서버관리에 많은 불편함을 주게 됩니다.
위 백업방법을 선택하면 디스크 용량문제에 대한 고민을 어느정도 해결해 줄수 있습니다.

1. 풀백업을 자주 받아야 하는 경우
2. DB용량이 큰경우
3. 랜카드 대여폭이 기가빗 이상인경우(100M/bps여도 상관은 없지만 시간이 조금 오래걸린다)
4. 장기보존이 필요없는 경우(덮어쓰기 백업으로 백업서버 용량을 절약할수 있다)
5. PC로 공유서버 백업을 운영한다면 적은비용에 백업정책을 운영 할 수 있다.

이처럼 백업은 장애대비 데이터의 유지 관리 전략에 비중을 두고 있습니다. 대부분 회사에서는 백업쪽에 많은 비용을 투자하지는 않습니다. 지금까지 잘돌아가니까요. 뻑나면 관리자들이 사표쓰고 나가야 되니까요...
그리고 어떤 회사는 백업에 많은 라이센스 비용을 지불하면서 운영을 하고 있습니다. 정작 비싼 라이센스는 다른쪽으로 운영이 되야 하는데 단순한 백업으로도 라이센스를 사용하는데 문제가 있다는것입니다. 단순한 백업은 위와같이 PC백업으로 유지하고 중요한 서버의 백업을 비용이 드는 백업 정책으로 유지해야 한다는 필자의 판단입니다.(대부분의 관리자들은 자기돈 들어가는게 아니니 전혀 신경을 쓰지 않습니다. 관리자들이 잘해봐야 위에서는 알아주지도 않기 때문이죠.)
DB의 백업정책. 트랜잭션 로그부터 여러가지 많습니다. 단순한 백업을 유지하는 전략으로 위와 같은 쿼리문을 작업배치로 걸어두면 좋을거 같다는 생각으로 포스팅 합니다.

2010/03/15 11:36 2010/03/15 11:36