출처 : http://blogs.msdn.com/b/distributedservices/archive/2012/01/16/how-to-configure-the-msdtc-service-to-listen-on-a-specific-rpc-server-port.aspx



My name is Steven Graves and I am a Senior Support Escalation Engineer on the Windows Core Team.  In this blog, I will discuss how to configure MSDTC to use a specific port on Windows Server 2012/2012R2 as this has slightly changed from the way it is configured in Windows Server 2008 R2 in order to prevent overlapping ports.  As a reference, here is the blog for Windows 2008 R2.

How to configure the MSDTC service to listen on a specific RPC server port
http://blogs.msdn.com/b/distributedservices/archive/2012/01/16/how-to-configure-the-msdtc-service-to-listen-on-a-specific-rpc-server-port.aspx

Scenario

There is a web server in a perimeter network and a standalone SQL Server (or Clustered SQL Server instance) on a backend production network and a firewall that separates the networks. MSDTC needs to be configured between the web server and backend SQL Server using a specific port in order to limit the ports opened on the firewall between the networks.

So as an example, we will configure MSDTC to use port 5000.

There are two things that need to be configured on the frontend web server to restrict the ports that MSDTC will use.

  • Configure the ports DCOM can use
  • Configure the specific port or ports for MSDTC to use

Steps

1. On the web server launch Dcomcnfg.exefrom the Run menu.

2. Expand Component Services, right click My Computer and select Properties

clip_image002

3. Select the Default Protocols tab

clip_image004

4. Click Properties button

clip_image006

5. Click Add

6. Type in the port range that is above the port MSDTC will use. In this case, I will use ports 5001-6000.

7. Click OK back to My Computer properties window and click OK.  Here is the key that is modified in the Registry for theephemeral ports.

clip_image008

8. Start Regedt32.exe

9. Locate HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC

10. Right click the MSDTC key, select New and DWord (32-bit) Value

11. Type ServerTcpPort for the key name

12. Right click ServerTcpPort key and select Modify

13. Change radio button to Decimal and type 5000 in the value data, click OK.  This is how the registry key should look

clip_image010

14. Restart the MSDTC Service (if stand-alone) or take the MSDTC Resource offline/online in Failover Cluster Manager if clustered.

To confirm MSDTC is using the correct port:

  1. Open an Administrative command prompt and run Netstat –ano to get the port and the Process Identifier (PID)
  2. Start Task Manager and select Details tab
  3. Find MSDTC.exe and get the PID
  4. Review the output for the PID to show it is MSDTC

clip_image012

Now DTC will be using the port specified in the registry and no other processes will try to use the same port thus preventing an overlap of ports.

Steven Graves
Senior Support Escalation Engineer
Microsoft Core Support

저작자표시

'Dev > SQL' 카테고리의 다른 글

SQL Server CLR - 레지스트리 읽기  (0) 2008.10.10
CTE (Common Table Expression)  (0) 2008.07.08
테이블 변수  (0) 2008.07.04
SQL Server 2005 버전 부터 기존 Native 확장프로시저의 개념으로 .net 환경의 CLR 코드의 통합을 제공한다

기본 네이티브 확장프로시저는의 문제점은 위험한 코드로 인해 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 이외의 리소스에 대해서 접근이 안됐다.

그래서 권한 수준을 "외부"나 "안전하지 않음"으로 배포를 해야 한는데 배포를 하면 다음과 같은 에러가 발생한다.

오류: 어셈블리 'IntCryptNetProc'에 PERMISSION_SET = EXTERNAL_ACCESS에 대한 권한이 없으므로 어셈블리 'IntCryptNetProc'에 대한 CREATE ASSEMBLY가 실패했습니다. 어셈블리는 DBO(데이터베이스 소유자)에게 EXTERNAL ACCESS ASSEMBLY 권한이 있고 데이터베이스에 TRUSTWORTHY 데이터베이스 속성이 있는 경우 또는 어셈블리가 현재 인증서로 서명되어 있거나 EXTERNAL ACCESS ASSEMBLY 권한이 있는 관련 로그인을 소유한 비대칭 키로 서명되어 있는 경우에 권한이 부여됩니다. 이 데이터베이스를 복원하거나 연결한 경우 데이터베이스 소유자가 이 서버의 올바른 로그인에 매핑되어 있는지 확인하십시오. 그렇지 않으면 sp_changedbowner를 사용하여 문제를 해결하십시오.

결론은 "권한이 있는 계정"으로 "TRUSTWORTHY 데이터 베이스 속성"이 되어있는 Database 에만 "외부"나 "안전하지 않음"의 권한 수준을 가지는 CLR를 배포할수 있다.

권한있는 계정은 sa나 그에 상응한는 계정으로 처리하면 되고 TRUSTWORTHY 데이터 베이스 속성은 아래와 같이 만들면 된다.

ALTER DATABASE SecureDB SET TRUSTWORTHY ON;



이번 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
출처 : http://technet.microsoft.com/ko-kr/library/ms190766.aspx


SQL Server 2005 온라인 설명서(2007년 9월)
공통 테이블 식 사용

CTE(공통 테이블 식)는 SELECT, INSERT, UPDATE, DELETE 또는 CREATE VIEW 문 하나의 실행 범위 내에서 정의되는 임시 결과 집합이라고 볼 수 있습니다. CTE는 개체로 저장되지 않고 쿼리 지속 시간 동안만 존재한다는 점에서 파생 테이블과 비슷합니다. 그러나 CTE는 파생 테이블과 달리 자체 참조가 가능하며 동일 쿼리에서 여러 번 참조될 수 있습니다.

CTE를 사용하여 다음을 수행할 수 있습니다.

  • 재귀 쿼리를 만들 수 있습니다. 자세한 내용은 공통 테이블 식을 사용하는 재귀 쿼리를 참조하십시오.
  • 일반적인 뷰 사용이 필요하지 않을 때, 즉 메타데이터에 정의를 저장할 필요가 없을 때 뷰를 대체할 수 있습니다.
  • 스칼라 하위 SELECT에서 파생된 열 또는 비결정적이거나 외부 액세스가 없는 함수를 기준으로 그룹화할 수 있습니다.
  • 동일 문에서 결과 테이블을 여러 번 참조할 수 있습니다.

CTE를 사용하면 가독성이 향상되고 복잡한 쿼리를 쉽게 유지 관리할 수 있는 이점이 있습니다. 쿼리를 개별적이고 단순한 논리적 구성 블록으로 나눌 수 있습니다. 그런 다음 이 단순한 블록을 사용하여 최종 결과 집합이 생성될 때까지 보다 복잡한 중간 CTE를 작성할 수 있습니다.

CTE는 함수, 저장 프로시저, 트리거 또는 뷰 같은 사용자 정의 루틴에서 정의될 수 있습니다.

CTE는 CTE를 나타내는 식 이름, 선택적인 열 목록 및 CTE를 정의하는 쿼리로 구성되어 있습니다. CTE를 정의한 후에는 SELECT, INSERT, UPDATE 또는 DELETE 문에서 테이블이나 뷰처럼 참조할 수 있습니다. CTE는 CREATE VIEW 문에서 정의하는 SELECT 문의 일부분으로 사용될 수도 있습니다.

CTE의 기본 구문 구조는 다음과 같습니다.

WITH expression_name [ ( column_name [,...n] ) ]

AS

( CTE_query_definition )

모든 결과 열에 대한 고유 이름이 쿼리 정의에 제공된 경우에만 열 이름 목록이 선택 사항입니다.

CTE를 실행하는 문은 다음과 같습니다.

SELECT <column_list>

FROM expression_name

예

다음 예에서는 CTE 구조의 구성 요소인 식 이름, 열 목록 및 쿼리를 보여 줍니다. CTE 식 Sales_CTE에는 3개의 열(SalesPersonID, NumberOfOrders 및 MaxDate)이 있으며 각 영업 사원의 SalesOrderHeader 테이블에 총 판매 주문 수 및 가장 최근의 판매 주문 날짜로 정의됩니다. 문이 실행될 때 영업 사원에 대해 선택한 열을 반환하기 위해 그리고 해당 영업 사원의 관리자에 대한 유사 세부 정보를 검색하기 위해 CTE가 두 번 참조됩니다. 영업 사원 및 관리자에 대한 데이터는 모두 단일 행으로 반환됩니다.

코드 복사
USE AdventureWorks;
GO
WITH Sales_CTE (SalesPersonID, NumberOfOrders, MaxDate)
AS
(
    SELECT SalesPersonID, COUNT(*), MAX(OrderDate)
    FROM Sales.SalesOrderHeader
    GROUP BY SalesPersonID
)
SELECT E.EmployeeID, OS.NumberOfOrders, OS.MaxDate,
    E.ManagerID, OM.NumberOfOrders, OM.MaxDate
FROM HumanResources.Employee AS E
    JOIN Sales_CTE AS OS
    ON E.EmployeeID = OS.SalesPersonID
    LEFT OUTER JOIN Sales_CTE AS OM
    ON E.ManagerID = OM.SalesPersonID
ORDER BY E.EmployeeID;
GO

다음은 결과 집합의 일부입니다.

코드 복사
EmployeeID  NumberOfOrders MaxDate  ManagerID NumberOfOrders MaxDate
----------- -------------- ---------- --------- -------------- ----------
268         48             2004-06-01 273       NULL           NULL
275         450            2004-06-01 268       48             2004-06-01
276         418            2004-06-01 268       48             2004-06-01
277         473            2004-06-01 268       48             2004-06-01

'Dev > SQL' 카테고리의 다른 글

How to Configure MSDTC to Use a Specific Port in Windows Server 2012/2012R2  (0) 2014.07.03
SQL Server CLR - 레지스트리 읽기  (0) 2008.10.10
테이블 변수  (0) 2008.07.04

INF: 질문과 대답 - SQL Server 2000 - 테이블 변수

이 문서가 적용되는 제품 보기.
기술 자료 ID : 305977
마지막 검토 : 2006년 11월 20일 월요일
수정 : 5.0

요약

이 문서에서는 SQL Server 2000에 소개된 테이블 변수와 관련된 질문과 대답(FAQ) 몇 가지를 제공합니다.

테이블 변수에 대한 SQL Server 온라인 설명서의 설명을 보려면 다음 Microsoft 웹 사이트를 방문하십시오.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ta-tz_7ysl.asp (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ta-tz_7ysl.asp)

추가 정보

질문 1: 임시 테이블을 이미 사용할 수 있는데 테이블 변수를 소개한 이유는 무엇입니까?

대답 1: 테이블 변수는 임시 테이블에 비해 다음과 같은 장점이 있습니다.
• SQL Server 온라인 설명서의 "테이블" 문서에서 언급한 것처럼 로컬 변수 같은 테이블 변수에는 잘 정의된 범위가 있으며, 종료할 때 자동으로 정리됩니다.
• 테이블 변수는 임시 테이블에 비해 저장 프로시저(stored procedure)를 재컴파일하는 횟수가 적습니다.
• 테이블 변수가 포함된 트랜잭션은 테이블 변수의 업데이트 기간 동안만 지속됩니다. 따라서 테이블 변수에는 잠금과 로깅 리소스가 덜 필요합니다. 테이블 변수의 범위는 제한되어 있고 영구 데이터베이스의 일부가 아니기 때문에 트랜잭션 롤백의 영향을 받지 않습니다.
질문 2: 임시 테이블을 사용할 때보다 테이블 변수가 저장 프로시저를 재컴파일하는 횟수가 적다는 것은 무슨 뜻입니까?

대답 2: 다음 문서에서는 저장 프로시저를 재컴파일하는 몇 가지 이유를 설명합니다.

243586 (http://support.microsoft.com/kb/243586/) INF: 저장 프로시저(Stored Procedure) 재컴파일 문제 해결 방법
"임시 테이블 작업으로 인한 재컴파일" 절에서는 임시 테이블로 인한 재컴파일 같은 문제를 방지하는 몇 가지 요구 사항이 나열되어 있습니다. 이러한 제한은 테이블 변수에 적용되지 않습니다.

테이블 변수는 CREATE 또는 ALTER 문이 실행될 때 '재확인'이 발생하도록 만드는 배치에만 해당됩니다. 이것은 임시 테이블에 발생할 수 있습니다. 임시 테이블은 중첩된 저장 프로시저에서 테이블을 참조할 수 있도록 '재확인'할 필요가 있습니다. 테이블 변수는 저장 프로시저가 이미 컴파일된 계획을 사용할 수 있도록 이 과정을 완벽하게 피하므로 저장 프로시저를 처리할 리소스가 절약됩니다.

질문 3: 테이블 변수의 단점은 무엇입니까?

대답 3: 임시 변수와 비교하여 다음과 같은 몇 가지 단점이 있습니다.
• PRIMARY 또는 UNIQUE 제약 조건을 위해 만든 시스템 인덱스 이외에 테이블 변수에는 클러스터되지 않은 색인을 만들 수 없습니다. 따라서 클러스터되지 않은 인덱스가 있는 임시 테이블과 비교할 때 쿼리 성능에 영향을 미칠 수 있습니다.
• 테이블 변수는 임시 테이블에서 할 수 있는 것처럼 통계를 유지하지 않습니다. 자동 만들기를 통해서나 CREATE STATISTICS 문을 사용하여 테이블 변수에 통계를 만들 수 없습니다. 따라서 큰 테이블에서 복잡한 쿼리를 수행하는 경우 통계가 없으면 최적화 프로그램이 쿼리를 위한 최적의 계획을 확인하는 것을 방해하여 해당 쿼리의 성능이 영향을 받을 수 있습니다.
• 초기 DECLARE 문 다음에 테이블 정의를 변경할 수 없습니다.
• INSERT EXEC 또는 SELECT INTO 문에서 테이블 변수를 사용할 수 없습니다.
• 테이블 유형 선언에서 CHECK 제약 조건, DEFAULT 값 및 계산된 열은 사용자 정의 함수를 호출할 수 없습니다.
• EXEC 문 또는 sp_executesql 저장 프로시저 외부에서 테이블 변수를 만든 경우 EXEC 문 또는 sp_executesql 저장 프로시저를 사용하여 테이블 변수를 참조하는 동적 SQL Server 쿼리를 실행할 수 없습니다. 테이블 변수는 로컬 범위에서만 참조할 수 있기 때문에 EXEC 문과 sp_executesql 저장 프로시저는 테이블 변수의 범위 밖에 있게 됩니다. 그러나 테이블 변수 로컬 범위가 EXEC 문이나 sp_executesql 저장 프로시저에 있기 때문에 EXEC 문이나 sp_executesql 저장 프로시저 내에서 테이블 변수를 만들고 모든 처리를 수행할 수 있습니다.
질문 4: 실제 디스크에 있는 데이터베이스에서 유지되기 때문에 임시 또는 영구 테이블에 비해 향상된 성능을 보장하는 테이블 변수 메모리 전용 구조가 있습니까?

대답 4: 테이블 변수는 메모리 전용 구조가 아닙니다. 테이블 변수에는 메모리에 저장할 수 있는 것보다 많은 데이터를 저장할 수 있기 때문에 디스크에 데이터를 저장할 위치가 있어야 합니다. 테이블 변수는 임시 테이블과 유사한 tempdb 데이터베이스에 만들어집니다. 메모리를 사용할 수 있는 경우 테이블 변수와 임시 테이블 모두 메모리에 만들어지고 처리됩니다(데이터 캐시).

질문 5: 임시 테이블 대신 테이블 변수를 사용해야 합니까?

대답 5: 대답은 다음 세 가지 요소에 따라 달라집니다.
• 테이블에 삽입된 행 수
• 쿼리가 저장된 재컴파일 수
• 쿼리 유형 및 성능에 대한 인덱스와 통계의 종속성
경우에 따라 임시 테이블이 있는 저장 프로시저를 작은 저장 프로시저로 나누면 재컴파일이 더 작은 단위로 발생하므로 유용합니다.

일반적으로 상당히 많은 양의 데이터가 있고 테이블 사용이 반복될 때를 제외하고는 가능하면 테이블 변수를 사용하는 것이 좋습니다. 이 경우 임시 테이블에 인덱스를 만들어 쿼리 성능을 높일 수 있습니다. 그러나 각 시나리오는 다를 수 있습니다. 테이블 변수가 특정 쿼리나 저장 프로시저에 대한 임시 테이블보다 유용한지 테스트하는 것이 좋습니다.

그래도 원하는 정보를 찾을 수 없으면 다음 Microsoft SQL Server 뉴스 그룹을 방문하십시오. Microsoft SQL Server 뉴스 그룹 (http://support.microsoft.com/newsgroups/)

이 문서나 다른 Microsoft SQL Server 기술 자료 문서에 대한 의견이 있으면 SQLKB@Microsoft.com (mailto:sqlkb@microsoft.com)으로 보내주시기 바랍니다.



Microsoft 제품 관련 기술 전문가들과 온라인으로 정보를 교환하시려면 Microsoft 뉴스 그룹 (http://support.microsoft.com/newsgroups/default.aspx)에 참여하시기 바랍니다.

'Dev > SQL' 카테고리의 다른 글

How to Configure MSDTC to Use a Specific Port in Windows Server 2012/2012R2  (0) 2014.07.03
SQL Server CLR - 레지스트리 읽기  (0) 2008.10.10
CTE (Common Table Expression)  (0) 2008.07.08

+ Recent posts

티스토리툴바