기본 네이티브 확장프로시저는의 문제점은 위험한 코드로 인해 SQL Server 자체의 보안이나 실행에 영향을 줄수 있다는것인데 2005 부터 지원되는 CLR의 경우 SQL Server와 실행의 완벽한 분리로 리스크를 최소한으로 줄였다고 한다.
이번에 SQL Server 암호화 모듈을 위해 Native 확장프로시저및 CLR 코드로 만들어 비교해 봤는데 CLR 의 압승이었다
Native의 경우 crypto++ 이라는 라이브러리로 래핑을 하였고 CLR의 경우 System.Security.Cryptography 의 라이브러리를 사용해서 만들었다.
대강의 느낌은 CLR 쪽이 3배 이상 빠른것으로 판단이되며 추측키로는 C++의 경우 확장프로시저 내의 객체 인스턴스 메모리의 할당하는 부분에서 승패를 가르지 않았는가 생각이 들지만 확인은 못해봤다.
아니면 알고리즘 구현 자체에 품질 문제 일수도 있을테고...
어찌 되었던 원래의 목적인 다중키 관리를 위해 키 저장소가 필요했고 키 저장소를 위해 xml 파일등 보다는 레지스트리에 저장을 하는것이 바이너리저장및 나름의 이점이 있지 않을까 생각이 들었고, 간단한 WinForm 을 제작하여 테스트를 해보았을때도 문제가 없었다.
그리고 CLR로 올리고 테스트 하는순간 레지스트리 접근을 못한다는것을 알았다
이유인 즉..
디폴트로 SQL Server CLR를 배포했을 경우 권한 수준이 "안전"(SAFE)수준으로 배포가 되어 SQL Server 이외의 리소스에 대해서 접근이 안됐다.
그래서 권한 수준을 "외부"나 "안전하지 않음"으로 배포를 해야 한는데 배포를 하면 다음과 같은 에러가 발생한다.
결론은 "권한이 있는 계정"으로 "TRUSTWORTHY 데이터 베이스 속성"이 되어있는 Database 에만 "외부"나 "안전하지 않음"의 권한 수준을 가지는 CLR를 배포할수 있다.
권한있는 계정은 sa나 그에 상응한는 계정으로 처리하면 되고 TRUSTWORTHY 데이터 베이스 속성은 아래와 같이 만들면 된다.
이번 CLR을 테스트 해보면서 거듭 느낀점은 .net 코드도 충분히 쓸만하게 성능이 나온다는것이다
경우에 따라서는 기존 native 보다 더 좋은 성능이 나오는것에 대해서 당황(?)을 하기도 하지만.. ^^
참고 :
http://technet.microsoft.com/ko-kr/library/ms345101.aspx
http://technet.microsoft.com/ko-kr/library/ms187861.aspx
http://msdn.microsoft.com/en-us/library/ms189524.aspx
ps.
위에 사항을 해결하기 위해 RegistryPermission 라는 클래스를 많이 찾아보았는다. (삽질..)
물론 직접적인 도움이 되지는 않았지만 먼가가 새로운 세계가 있는 갑다. 흐흐..
'Dev > SQL' 카테고리의 다른 글
How to Configure MSDTC to Use a Specific Port in Windows Server 2012/2012R2 (0) | 2014.07.03 |
---|---|
CTE (Common Table Expression) (0) | 2008.07.08 |
테이블 변수 (0) | 2008.07.04 |