쉽고 명쾌한 설명을 위해, 이 문서에서는 개발 및 응용 플랫폼으로 Microsoft Visual Studio 버전 6.0, Microsoft Windows NT 버전 4(서비스 팩 4), SQL Server 7.0 및 Oracle 7.3을 사용합니다. Visigenic Software ODBC 드라이버(버전 2.00.0300)는 Oracle 7.3에 사용되고 Microsoft Corporation ODBC 드라이버(버전 3.70)는 SQL Server 7.0에 사용됩니다. Microsoft SQL Server 7.0에는 Oracle용 OLE DB 드라이버가 제공되지만 이 장에서는 이 드라이버에 대해 폭넓게 다루지 않습니다.

개요

응용 프로그램 마이그레이션 프로세스는 복잡해 보일 수 있습니다. RDBMS마다 아키텍처에 많은 차이가 있습니다. Oracle 아키텍처를 설명하는 데 사용되는 단어나 용어는 Microsoft SQL Server와 전혀 다른 의미를 가지는 경우가 많습니다. 또한 Oracle과 SQL Server 모두 SQL-92 표준에 대한 많은 확장을 독자적으로 개발했습니다.

응용 프로그램 개발자의 입장에서 보면 Oracle과 SQL Server의 데이터 관리 방식이 비슷합니다. 내부적으로 Oracle과 SQL Server 사이에는 차이점이 많지만 이 차이점를 적절히 다루면 마이그레이션하는 응용 프로그램이 별다른 영향을 받지 않습니다.

개발자들이 마주치는 가장 큰 마이그레이션 문제는 각 RDBMS가 제공해야 하는 SQL-92 SQL 언어 표준과 확장을 구현하는 것입니다. 최대한 일반적인 프로그램 코드를 작성하고자 하는 일부 개발자들은 표준 SQL 언어 문만 사용합니다. 일반적으로, 이는 Oracle과 SQL Server를 포함한 많은 데이터베이스 제품에서 일관되게 구현되는 초급 SQL-92 표준으로 프로그램 코드를 제한한다는 뜻입니다.

이 방식을 사용하면 프로그램 코드가 불필요하게 복잡해져 프로그램 성능이 크게 떨어질 수 있습니다. 예를 들어, Oracle의 DECODE 함수는 Oracle 전용 비표준 SQL 확장입니다. Microsoft SQL Server의 CASE 식은 중고급 SQL-92 확장이며 일부 데이터베이스 제품에서는 구현되지 않습니다.

Oracle DECODE와 SQL Server CASE 식은. 이 함수들을 사용하지 않는 다른 방법은 같은 기능을 수행하는 프로그램 코드를 작성하는 것입니다. 그러나 이렇게 하면 RDBMS에서 훨씬 많은 데이터를 검색해야 할 것입니다.

또한 프로시저를 통해 SQL 언어를 확장하면 문제가 발생할 수 있습니다. Oracle PL/SQL과 SQL Server Transact-SQL 언어는 기능은 비슷하지만 구문은 서로 다릅니다. 각 RDBMS와 프로시저를 통한 그 확장 사이에 정확한 대응 관계는 없습니다. 따라서 프로시저나 트리거 같은 저장 프로그램을 사용하지 않기로 결정할 수 있습니다. 저장 프로그램은 성능과 보안 면에서 다른 방법으로는 얻을 수 없는 많은 이점을 제공할 수 있기 때문에 사용하면 도움이 됩니다.

독자적인 개발 인터페이스를 사용하면 또 다른 문제가 발생합니다. Oracle OCI(Oracle Call Interface)를 사용하여 프로그램을 변환하려면 보통 리소스에 많은 투자를 해야 합니다. 여러 RDBMS를 사용하게 될 응용 프로그램을 개발할 때는 개방형 데이터베이스 연결(ODBC) 인터페이스를 사용하는 것이 좋습니다.

ODBC는 다양한 데이터베이스 관리 시스템에서 동작하도록 설계되었습니다. ODBC는 데이터베이스 전용 드라이버의 서비스를 통해 다양한 데이터베이스에서 동작하는 일관된 응용 프로그래밍 인터페이스(API)를 제공합니다.

일관된 API란 프로그램이 Oracle에서 동작하든 SQL Server에서 동작하든 상관없이 연결 설정, 명령 실행 및 결과 검색을 위해 프로그램이 호출하는 함수가 동일하다는 뜻입니다.

또한 ODBC는 공통된 작업을 수행하지만 데이터베이스마다 구문이 다른 SQL 함수를 지정하기 위해 표준화된 호출 수준 인터페이스를 정의하고 표준 이스케이프 시퀀스를 사용합니다. ODBC 드라이버는 프로그램 코드의 수정을 요구하지 않고 이 ODBC 구문을 Oracle 또는 Microsoft SQL Server 고유의 SQL 구문으로 자동 변환할 수 있습니다. 프로그램을 작성한 다음 ODBC가 실행 시에 변환 프로세스를 수행할 수 있도록 하는 것이 최상의 방법일 때도 있습니다.

ODBC는 모든 데이터베이스에서 완전한 데이터베이스 독립성, 완전한 기능성, 높은 성능을 제공할 수 있는 마법의 솔루션이 아닙니다. 데이터베이스 및 제3의 공급업체마다 제공하는 ODBC 지원 레벨이 다릅니다. 일부 드라이버는 다른 인터페이스 라이브러리 위에 매핑된 핵심 API 함수만 구현합니다. Microsoft SQL Server 드라이버 같은 일부 드라이버는 고성능 전용 드라이버에 완전한 레벨 2 지원을 제공합니다.

핵심 ODBC API만 사용하는 프로그램의 경우 일부 데이터베이스에서 기능과 성능이 떨어질 수 있습니다. 뿐만 아니라, Oracle DECODE나 SQL Server CASE 식처럼 ODBC 이스케이프 시퀀스로 나타낼 수 없는 기본 SQL 확장도 있습니다.

또한 데이터베이스의 최적화 프로그램을 활용하도록 SQL 문을 작성하는 것이 일반적인 방식입니다. Oracle에서 성능 개선을 위해 사용하는 기법과 방법이 Microsoft SQL Server 7.0에서도 반드시 최상의 방식이라고는 할 수 없습니다. ODBC 인터페이스는 RDBMS 간에 기법을 변환할 수 없습니다.

ODBC는 응용 프로그램이 데이터베이스 고유의 기능을 사용하거나 성능을 튜닝하는 것을 막지 않지만 응용 프로그램은 데이터베이스 고유의 코드 구역을 일부 필요로 합니다. ODBC를 사용하면 프로그램 구조 및 대부분의 프로그램 코드를 여러 데이터베이스에 걸쳐 일관되게 유지하기가 쉽습니다.

OLE DB는 차세대 데이터 액세스 기술입니다. Microsoft SQL Server 7.0에서는 SQL Server의 구성 요소 자체에 OLE DB가 이용됩니다. 또한 응용 프로그램 개발자는 SQL Server 7.0을 사용하여 새로 개발할 때 OLE DB 사용을 고려해야 합니다. Microsoft는 SQL Server 7.0에 Oracle 7.3용 OLE DB 공급자를 제공합니다.

OLE DB는 조직 전체에 걸쳐 데이터를 관리할 수 있도록 Microsoft가 제공하는 시스템 차원의 전략적 프로그래밍 인터페이스입니다. OLE DB는 ODBC의 기능을 기반으로 구축되도록 설계된 개방형 명세입니다. ODBC는 관계형 데이터베이스에 액세스할 수 있도록 설계되었으며 OLE DB는 메인프레임 ISAM/SAM과 계층적 데이터베이스, 전자 메일과 파일 시스템 저장소, 텍스트, 그래픽 데이터와 지역 데이터, 사용자 정의 업무 개체 같은 비관계형 정보 원본과 관계형 정보 원본에 액세스할 수 있도록 설계되었습니다.

OLE DB는 다양한 데이터베이스 관리 시스템 서비스를 캡슐화하고, 이러한 서비스를 구현하는 소프트웨어 구성 요소를 만들 수 있도록 하는 COM 인터페이스 집합을 정의합니다. OLE DB 구성 요소는 데이터를 포함하고 공개하는 데이터 공급자, 데이터를 사용하는 데이터 소비자, 쿼리 프로세서나 커서 엔진처럼 데이터를 처리하고 전송하는 서비스 구성 요소로 구성됩니다.

OLE DB 인터페이스는 OLE DB 구성 요소 공급업체가 고품질의 OLE DB 구성 요소를 신속하게 상품화할 수 있도록 구성 요소들의 원활한 통합을 돕기 위한 것입니다. 뿐만 아니라, OLE DB에는 현재 공급되고 있는 광범위한 ODBC 관계형 데이터베이스 드라이버를 계속적으로 지원할 수 있도록 하는 ODBC 브리지가 포함됩니다.

이 문서의 구성

Oracle에서 SQL Server로의 단계적 마이그레이션을 돕기 위해, 각 절에서 Oracle 7.3과 Microsoft SQL Server 7.0 사이의 차이점에 대해 간략하게 설명합니다. 또한 변환 고려 사항, SQL Server 7.0의 이점 및 여러 가지 예제도 제공합니다.

아키텍처 및 용어

성공적인 마이그레이션을 시작하려면 Microsoft SQL Server 7.0과 관련된 기본 아키텍처 및 용어를 이해해야 합니다. 이 절에 제공되는 많은 예제는 이 문서의 일부로 포함된 예제 Oracle 및 SQL Server 응용 프로그램에서 발췌한 것입니다.

Oracle에서 데이터베이스라는 용어는 아래와 같은 구성 요소가 포함된 전체 Oracle RDBMS 환경을 뜻합니다.

• Oracle 데이터베이스 프로세스와 버퍼(인스턴스)
• 중앙 집중식 시스템 카탈로그 하나가 포함된 SYSTEM 테이블 공간
• DBA로 정의되는 다른 테이블 공간(선택적)
• 2개 이상의 온라인 REDO 로그
• 보관된 REDO 로그(선택적)
• 기타 파일(제어 파일, Init.ora 등)

Microsoft SQL Server 데이터베이스는 테이블 공간과 흡사하게 데이터, 응용 프로그램 및 보안 메커니즘을 논리적으로 구분합니다. Oracle은 다중 테이블 공간을 지원하고 SQL Server는 다중 데이터베이스를 지원합니다. 또한 테이블 공간을 사용하면 데이터의 실제 배치를 지원할 수 있으며 SQL Server는 파일 그룹을 통해 이와 똑같은 기능을 제공합니다.

Microsoft SQL Server는 기본적으로 아래와 같은 데이터베이스를 설치합니다.

• model 데이터베이스 - 새로 만드는 모든 사용자 데이터베이스의 템플릿입니다.
• tempdb 데이터베이스 - 임시 작업 저장소 및 정렬 연산에 사용된다는 점에서 Oracle의 임시 테이블 공간과 비슷합니다. Oracle의 임시 테이블 공간과는 달리 사용자들이 로그오프할 때 자동으로 삭제되는 임시 테이블을 만들 수 있습니다.
• msdb 데이터베이스 - SQL Server 에이전트 및 에이전트의 계획된 작업, 경고, 복제 정보를 지원합니다.
• pubs 및 Northwind 데이터베이스 - 교육용 예제 데이터베이스로 제공됩니다.

기본 데이터베이스에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

각 Oracle 데이터베이스는 SYSTEM 테이블 공간에 있는 중앙 집중식 시스템 카탈로그 또는 데이터 딕셔너리에서 실행됩니다. 각 Microsoft SQL Server 7.0 데이터베이스는 아래 항목에 대한 정보가 포함된 자체의 시스템 카탈로그를 유지합니다.

• 데이터베이스 개체(테이블, 인덱스, 저장 프로시저, 뷰, 트리거 등)
• 제약 조건
• 사용자 및 사용 권한
• 사용자 정의 데이터 형식
• 복제 정의
• 데이터베이스에 사용되는 파일

또한 SQL Server의 master 데이터베이스에는 아래와 같은 개별 데이터베이스에 대한 일부 정보 및 시스템 카탈로그가 포함된 중앙 집중식 시스템 카탈로그가 제공됩니다.

• 각 데이터베이스의 데이터베이스 이름 및 기본 파일 위치
• SQL Server 로그인 계정
• 시스템 메시지
• 데이터베이스 구성 값
• 원격 서버 및 연결된 서버
• 현재 활동 정보
• 시스템 저장 프로시저

Oracle의 SYSTEM 테이블 공간과 마찬가지로 SQL Server의 master 데이터베이스도 다른 모든 데이터베이스에 액세스하는 데 사용할 수 있어야 합니다. 이런 점에서 중요한 데이터베이스 변경 후에 master 데이터베이스를 백업하여 장애로부터 보호하는 것이 중요합니다. 데이터베이스 관리자가 master 데이터베이스를 구성하는 파일을 미러링할 수도 있습니다.

Oracle RDBMS는 테이블 공간으로 구성되며 테이블 공간은 데이터 파일로 구성됩니다. 테이블 공간 데이터 파일은 블록이라는 내부 단위로 정의됩니다. 블록 크기는 Oracle 데이터베이스가 처음 만들어질 때 DBA를 통해 설정되며 512부터 8192바이트까지 지정할 수 있습니다. Oracle 테이블 공간에 개체를 만들 때 사용자는 확장 영역(초기 확장 영역, 다음 확장 영역, 최소 확장 영역, 최대 확장 영역)이라는 단위로 공간을 지정합니다. Oracle 확장 영역은 크기가 다양하며 최소한 5개의 블록이 연속되어 있어야 합니다.

Microsoft SQL Server에서는 데이터베이스 수준에 파일 그룹을 사용하여 테이블과 인덱스의 실제 위치를 제어합니다. 파일 그룹은 하나 이상의 파일이 포함된 논리 컨테이너이며 파일 그룹에 포함된 데이터는 그 파일 그룹에 속하는 모든 파일에 걸쳐 비례적으로 채워집니다.

파일 그룹을 정의하거나 사용하지 않으면 데이터베이스를 만들 때 암시적으로 정의되는 기본 파일 그룹에 데이터베이스 개체가 배치됩니다. 파일 그룹을 사용하여 아래 작업을 수행할 수 있습니다.

• 큰 테이블을 여러 파일로 분산시켜 I/O 처리 능력을 향상시킵니다.
• 인덱스를 해당 테이블이 아닌 다른 파일에 저장하여 I/O 처리 능력과 디스크 동시성을 향상시킵니다.
• text, ntext, image 열(대용량 개체)을 해당 테이블이 아닌 별도의 파일에 저장합니다.
• 데이터베이스 개체를 특정 디스크 스핀들에 배치합니다.
• 파일 그룹의 각 테이블 또는 테이블 집합을 백업하고 복원합니다.

SQL Server에서는 파일을 페이지라는 내부 단위로 정의합니다. 페이지 크기는 8192바이트(8KB)로 고정되어 있습니다. 페이지는 8개의 연속 페이지로 크기가 고정된 확장 영역으로 구성됩니다. SQL Server 데이터베이스에 테이블이나 인덱스를 만들면 한 페이지가 자동으로 할당됩니다. 이에 따라 전체 확장 영역을 할당하는 것보다 효율적으로 작은 테이블과 인덱스를 저장할 수 있습니다.

Oracle 형식의 세그먼트는 대부분의 Microsoft SQL Server 설치에 필요하지 않습니다. 대신, SQL Server는 하드웨어 기반 RAID 또는 Windows NT 소프트웨어 기반 RAID를 사용하여 데이터를 더 효율적으로 분산시키거나 스트라이프할 수 있습니다. Windows NT 소프트웨어 기반 RAID 또는 하드웨어 기반 RAID는 하나의 논리 드라이브로 나타나는 여러 디스크 드라이브로 구성된 스트라이프 세트를 설정할 수 있습니다. 이 스트라이프 세트에 데이터베이스 파일이 만들어지면 디스크 하위 시스템이 여러 디스크 간에 I/O 로드를 분산시킬 책임을 집니다. 관리자가 RAID를 사용하여 여러 개의 실제 디스크에 데이터를 분산시키는 것이 바람직합니다.

SQL Server에 권장되는 RAID 구성은 RAID 1(미러링) 또는 RAID 5(예비 패리티 드라이브가 있는 스트라이프 세트)입니다. RAID 10(패리티가 있는 스트라이프 세트 미러링)도 권장되지만 앞의 두 가지 옵션보다 훨씬 비용이 많이 듭니다. 스트라이프 세트는 데이터베이스 파일에 대한 일반적인 임의 I/O를 분산시키는 기능이 뛰어납니다.

RAID를 사용하지 않는 경우 RAID에서 얻을 수 있는 이점을 어느 정도 제공하는 파일 그룹이 좋은 대안이 될 수 있습니다. 또한 여러 개의 실제 RAID 배열에 걸쳐 있는 아주 큰 데이터베이스의 경우, 파일 그룹은 여러 RAID 배열 간에 I/O를 제어된 방식으로 좀더 많이 분산시킬 수 있는 매력적인 방법이 될 수 있습니다.

트랜잭션 로그 파일은 순차적 I/O를 위해 최적화되어야 하며 한 지점에 장애가 발생해도 유지되어야 합니다. 따라서 트랜잭션 로그에는 RAID 1(미러링)이 권장됩니다. 이 드라이브의 크기는 적어도 온라인 REDO 로그와 롤백 세그먼트 테이블 공간을 합한 크기와 같아야 합니다. 논리 드라이브에 정의된 모든 공간을 차지하는 로그 파일을 하나 이상 만들어야 합니다. 파일 그룹에 저장된 데이터와 달리 트랜잭션 로그 항목은 언제나 순차적으로 기록되며 비례적으로 채워지지 않습니다.

RAID에 대한 자세한 내용은 SQL Server 온라인 설명서, Windows NT Server 설명서, Microsoft Windows NT Resource Kit를 참조하십시오.

Oracle RDBMS가 시작될 때마다 자동 복구가 수행됩니다. Oracle RDBMS는 테이블 공간 파일의 내용이 온라인 REDO 로그 파일의 내용과 일치하는지 확인합니다. 이들이 일치하지 않으면, Oracle은 온라인 REDO 로그 파일의 내용을 테이블 공간 파일에 적용한 다음(롤포워드) 롤백 세그먼트에 있는 커밋되지 않은 트랜잭션을 모두 제거합니다(롤백). 온라인 REDO 로그 파일에서 필요한 정보를 얻지 못하면 Oracle은 보관된 REDO 로그 파일을 참조합니다.

Microsoft SQL Server 7.0도 시작될 때마다 시스템의 각 데이터베이스를 검사하여 자동 데이터 복구를 수행합니다. 먼저 master 데이터베이스를 검사하고 시스템의 다른 모든 데이터베이스를 복구하기 위한 스레드를 시작합니다. 각 SQL Server 데이터베이스에 대해 자동 복구 메커니즘이 트랜잭션 로그를 검사합니다. 트랜잭션 로그에 커밋되지 않은 트랜잭션이 있으면 트랜잭션이 롤백됩니다. 그런 다음 복구 메커니즘이 커밋은 되었지만 아직 데이터베이스에 기록되지 않은 트랜잭션을 트랜잭션 로그에서 검사합니다. 이런 트랜잭션이 있으면 그 트랜잭션을 다시 수행하여 롤 포워드합니다.

각 SQL Server 트랜잭션 로그에는 Oracle 롤백 세그먼트와 Oracle 온라인 REDO 로그를 결합한 기능이 있습니다. 각 데이터베이스에는 모든 데이터베이스 변경 사항을 기록하고 그 데이터베이스의 모든 사용자가 공유하는 자체의 트랜잭션 로그가 있습니다. 트랜잭션이 시작되고 데이터 수정이 발생하면 수정 이벤트는 물론 BEGIN TRANSACTION 이벤트가 로그에 기록됩니다. 이 이벤트는 자동 복구 중에 트랜잭션 시작점을 결정하는 데 사용됩니다. 각 데이터 수정 문이 수신되면 변경 사항이 데이터베이스 자체에 기록되기 전에 트랜잭션 로그에 기록됩니다. 자세한 내용은 이 장의 뒷부분에 나오는 "트랜잭션, 잠금 및 동시성" 절을 참조하십시오.

SQL Server에는 완료된 트랜잭션이 SQL Server 디스크 캐시에서 트랜잭션 로그 파일로 정상적으로 기록되었는지 확인하는 자동 검사점 메커니즘이 있습니다. 검사점은 마지막 검사점 이후 수정된 모든 캐시 페이지를 데이터베이스에 기록합니다. 커밋되지 않은 데이터 페이지라고도 하는 이러한 캐시 페이지를 데이터베이스에 검사점으로 처리하면 완료된 모든 트랜잭션이 디스크에 확실히 기록됩니다. 이를 통해 정전 같은 시스템 고장 시 복구하는 데 걸리는 시간이 단축됩니다. 이 설정은 SQL Server 엔터프라이즈 관리자 또는 Transact-SQL(sp_configure 시스템 저장 프로시저)을 사용하여 복구 간격 설정을 수정하면 변경할 수 있습니다.

Microsoft SQL Server는 아래와 같은 여러 가지 데이터 백업 옵션을 제공합니다.

• 데이터베이스 전체 백업

  데이터베이스 전체를 백업하려면 BACKUP DATABASE 문 또는 백업 마법사를 사용합니다.

• 차등 백업

  데이터베이스 전체 백업을 한 후 BACKUP DATABASE WITH DIFFERENTIAL 문 또는 백업 마법사를 사용하여 변경된 데이터와 인덱스 페이지만 정기적으로 백업합니다.

• 트랜잭션 로그 백업

  Microsoft SQL Server의 트랜잭션 로그는 각 데이터베이스와 연결되어 있습니다. 트랜잭션 로그는 백업되거나 잘릴 때까지 채워집니다. SQL Server 7.0의 기본 구성에 따라, 트랜잭션 로그는 사용 가능한 모든 디스크 공간을 사용하거나 구성된 최대 크기에 이를 때까지 자동으로 커집니다. 트랜잭션 로그가 너무 많이 차면 오류가 발생할 수 있고 트랜잭션 로그를 백업하거나 잘라낼 때까지 더 이상 수정하지 못할 수 있습니다. 다른 데이터베이스는 영향을 받지 않습니다. BACKUP LOG 문 또는 백업 마법사를 사용하여 트랜잭션 로그를 백업할 수 있습니다.

• 파일 또는 파일 그룹 백업

  SQL Server가 파일 및 파일 그룹을 백업할 수 있습니다. 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

데이터베이스 사용 중에 백업을 수행할 수 있으므로 계속적으로 실행되어야 하는 시스템을 백업할 수 있습니다. SQL Server 7.0의 백업 처리와 내부 데이터 구조가 개선되어, 백업을 수행할 때 트랜잭션 처리량에 대한 영향을 최소화하고 데이터 전송 속도를 최대화할 수 있습니다.

Oracle과 SQL Server 모두 특정 로그 파일 형식을 필요로 합니다. SQL Server에서는 백업 장치라고 부르는 이러한 파일을 SQL Server 엔터프라이즈 관리자, Transact-SQL sp_addumpdevice 저장 프로시저 또는 이에 상응하는 SQL-DMO 명령을 사용하여 만듭니다.

수동으로 백업할 수도 있지만 SQL Server 엔터프라이즈 관리자나 데이터베이스 유지 관리 계획 마법사를 사용하여 주기적인 백업 또는 데이터베이스 활동을 기반으로 하는 백업을 계획하는 것이 바람직합니다.

데이터베이스 전체 백업(장치)에 트랜잭션 로그 백업 및 차등 백업을 적용하면 데이터베이스를 특정 시점으로 복원할 수 있습니다. 데이터베이스 복원은 백업에 포함된 정보로 데이터를 덮어씁니다. 복원은 SQL Server 엔터프라이즈 관리자, Transact-SQL(RESTORE DATABASE), SQL-DMO를 사용하여 수행할 수 있습니다.

Oracle 아카이버를 꺼서 자동 백업을 무시할 수 있듯, Microsoft SQL Server에서는 db_owner 고정 데이터베이스 역할의 구성원이 검사점이 나타날 때마다 트랜잭션 로그의 내용이 지워지도록 지정할 수 있습니다. SQL Server 엔터프라이즈 관리자(검사점에서 로그 잘라내기), Transact-SQL(sp_dboption 저장 프로시저) 또는 SQL-DMO를 사용하여 이 작업을 수행할 수 있습니다.

Oracle SQL*Net은 Oracle 데이터베이스 서버와 클라이언트 사이의 네트워크 연결을 지원합니다. Oracle SQL *Net은 TNS(Transparent Network Substrate) 데이터 스트림 프로토콜과 통신하며 사용자가 특별한 코드를 작성할 필요없이 다양한 네트워크 프로토콜을 실행할 수 있도록 합니다. SQL*Net은 Oracle의 핵심 데이터베이스 소프트웨어 제품에 제공되지 않습니다.

Microsoft SQL Server에서는 Net-Libraries(네트워크 라이브러리)가 테이블 형식 데이터 스트림(TDS) 프로토콜을 사용하여 클라이언트와 서버 사이의 네트워크 연결을 지원합니다. 이들을 사용하면 명명된 파이프, TCP/IP 소켓 또는 다른 프로세스간 통신(IPC) 메커니즘을 실행하는 클라이언트의 동시 연결이 가능합니다. 모든 클라이언트 Net-Libraries가 SQL Server CD-ROM에 제공되므로 따로 구입할 필요가 없습니다.

SQL Server Net-Library 옵션은 설치 후에 변경할 수 있습니다. 클라이언트 네트워크 유틸리티는 Windows NT, Windows 95 또는 Windows 98 운영 체제를 실행하는 클라이언트에 대한 기본 네트워크 라이브러리 정보와 서버 연결 정보를 구성합니다. ODBC 데이터 원본 설정 중에 변경되었거나 ODBC 연결 문자열에 명시적으로 코딩되지 않은 한, 모든 ODBC 클라이언트 응용 프로그램은 동일한 기본 네트워크 라이브러리와 서버 연결 정보를 사용합니다. 네트워크 라이브러리에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

Oracle 응용 프로그램을 Microsoft SQL Server 7.0으로 적절히 마이그레이션하려면 SQL Server에 구현된 데이터베이스 보안 및 역할을 이해해야 합니다.

로그인 계정

사용자는 로그인 계정을 사용하여 SQL Server 데이터나 관리 옵션에 액세스할 수 있습니다. 로그인 계정을 가진 사용자는 SQL Server에 로그인한 다음 게스트 액세스가 허용되는 데이터베이스만 볼 수 있습니다. 게스트 계정은 기본값으로 설정되지 않으므로 따로 만들어야 합니다.

SQL Server는 Windows NT 인증 모드(통합 보안)와 SQL Server 인증 모드(표준 보안)라는 두 종류의 로그인 보안을 제공합니다. SQL Server 7.0은 표준 보안과 통합 보안을 결합한 혼합 보안도 지원합니다.

Windows NT 인증 모드는 로그온 연결을 확인할 때 Windows NT의 보안 메커니즘을 사용하며 사용자의 Windows NT 보안 자격 증명을 기반으로 합니다. SQL Server에 대한 로그인 ID나 암호를 네트워크 연결에서 직접 가져오므로 사용자들은 이러한 로그인 정보를 입력할 필요가 없습니다. 이런 경우 항목이 syslogins 테이블에 기록되고 Windows NT와 SQL Server 간에 확인됩니다. 이를 트러스트된 연결이라고 하며 이 연결은 두 Windows NT 서버 간의 트러스트 관계처럼 작용합니다. 이는 Oracle 사용자 계정과 관련된 IDENTIFIED EXTERNALLY 옵션처럼 동작합니다.

SQL Server 인증 모드에서는 사용자가 SQL Server에 대한 액세스를 요청할 때 로그온 ID와 암호를 입력해야 합니다. 이를 트러스트되지 않은 연결이라고 합니다. 이 연결은 Oracle 사용자 계정과 관련된 IDENTIFIED BY PASSWORD 옵션처럼 동작합니다. 표준 보안 모델을 사용하여 로그인하면 SQL Server 데이터베이스 엔진에만 액세스할 수 있으며 사용자 데이터베이스에는 액세스할 수 없습니다.

이러한 보안 메커니즘에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

그룹, 역할 및 사용 권한

Microsoft SQL Server와 Oracle은 사용 권한을 사용하여 데이터베이스 보안을 유지합니다. SQL Server의 문 수준 사용 권한은 새 데이터베이스 개체를 만들 수 있는 권한을 제한하는 데 사용되며 Oracle의 시스템 수준 사용 권한과 비슷합니다.

SQL Server는 개체 수준 사용 권한도 제공합니다. Oracle처럼 개체 수준 소유권은 개체 작성자에게 할당되며 양도할 수 없습니다. 다른 데이터베이스 사용자들은 개체 수준 사용 권한을 부여받아야만 그 개체에 액세스할 수 있습니다. sysadmin 고정 서버 역할, db_owner 고정 데이터베이스 역할 또는 db_securityadmin 고정 데이터베이스 역할의 구성원은 개체에 대한 사용 권한을 다른 사용자에게 부여할 수 있습니다.

SQL Server의 문 수준 사용 권한과 개체 수준 사용 권한을 데이터베이스 사용자 계정에 직접 부여할 수 있습니다. 그러나 데이터베이스 역할에 대한 사용 권한을 관리하는 것이 더 간단한 경우가 많습니다. SQL Server의 다양한 역할은 데이터베이스 사용자 그룹에 권한을 부여하거나 해지하는 데 사용되며 Oracle의 여러 가지 역할과 흡사합니다. 역할은 특정 데이터베이스와 연결된 데이터베이스 개체입니다. 여러 데이터베이스 간에 동작하는, 각 설치와 연결된 고정 서버 역할이 몇 가지 있습니다. sysadmin이 한 가지 예입니다. Windows NT 그룹을 데이터베이스 사용자는 물론 SQL Server 로그인으로도 추가할 수 있습니다. Windows NT 그룹 또는 Windows NT 사용자에게 사용 권한을 부여할 수 있습니다.

데이터베이스가 가질 수 있는 역할 또는 Windows NT 그룹 수에는 제한이 없습니다. 기본 역할인 public은 모든 데이터베이스에 항상 제공되며 제거할 수 없습니다. public 역할은 Oracle의 PUBLIC 계정과 아주 비슷한 기능을 합니다. 각 데이터베이스 사용자는 언제나 public 역할의 구성원입니다. 데이터베이스 사용자는 public 역할 외에도 숫자에 상관없이 모든 역할의 구성원이 될 수 있습니다. Windows NT 사용자나 그룹은 숫자에 상관없이 모든 역할의 구성원이 될 수 있으며 항상 public 역할에도 속합니다.

데이터베이스 사용자와 게스트 계정

Microsoft SQL Server에서는 사용자 로그인 계정으로 데이터베이스와 그 개체를 사용하기 위해 권한을 부여받아야 합니다. 로그인 계정으로 데이터베이스에 액세스할 때 아래 방법 중 하나를 사용할 수 있습니다.

• 로그인 계정을 데이터베이스 사용자로 지정할 수 있습니다.
• 로그인 계정이 데이터베이스의 게스트 계정을 사용할 수 있습니다.
• Windows NT 그룹 로그인을 데이터베이스 역할에 매핑할 수 있습니다. 그러면 그 그룹의 구성원인 각 Windows NT 계정이 데이터베이스에 연결할 수 있습니다.

db_owner나 db_accessadmin 역할 또는 sysadmin 고정 서버 역할의 구성원이 데이터베이스 사용자 계정 역할을 만듭니다. 계정에는 SQL Server 로그인 ID, 데이터베이스 사용자 이름(선택적), 역할 이름(선택적) 같은 여러 매개 변수가 포함될 수 있습니다. 데이터베이스 사용자 이름이 사용자의 로그인 ID와 같을 필요는 없습니다. 데이터베이스 사용자 이름을 제공하지 않으면 사용자의 로그인 ID와 데이터베이스 사용자 이름이 같습니다. 역할 이름을 제공하지 않으면 데이터베이스 사용자는 public 역할에만 속합니다. 데이터베이스 사용자를 만든 후 그 사용자에게 역할을 필요한 개수 만큼 지정할 수 있습니다.

db_owner 또는 db_accessadmin 역할의 구성원은 게스트 계정도 만들 수 있습니다. 게스트 계정은 유효한 SQL Server 로그인 계정이 데이터베이스 사용자 계정이 없어도 데이터베이스에 액세스할 수 있도록 합니다. 기본적으로, 게스트 계정은 public 역할에 할당된 모든 권한을 상속하지만 이러한 권한을 public 역할의 권한보다 크거나 작게 변경할 수 있습니다.

Windows NT 사용자 계정이나 그룹 계정에 SQL Server 로그인이 할 수 있는 것과 똑같이 데이터베이스 액세스 권한을 부여할 수 있습니다. 그룹의 구성원인 Windows NT 사용자는 데이터베이스에 연결할 때 그 Windows NT 그룹에 할당된 사용 권한을 받습니다. 데이터베이스 액세스 권한이 부여된 둘 이상의 Windows NT 그룹의 구성원인 경우 사용자는 자신이 속한 모든 그룹의 권한을 결합한 권한을 받습니다.

sysadmin 역할

Microsoft SQL Server sysadmin 고정 서버 역할의 구성원은 Oracle DBA의 구성원과 비슷한 사용 권한을 가집니다. SQL Server 7.0에서, sa SQL Server 인증 모드 로그인 계정은 SQL Server가 Windows NT 컴퓨터에 설치되어 있으면 로컬 Administrators 그룹의 구성원이므로 기본적으로 이 역할의 구성원입니다. sysadmin 역할의 구성원은 SQL Server 로그인은 물론 Windows NT 사용자와 그룹도 추가하거나 제거할 수 있습니다. 이 역할의 구성원은 대개 아래와 같은 책임을 가집니다.

• SQL Server 설치
• 서버 및 클라이언트 구성
• 데이터베이스 만들기*
• 로그인 권한 및 사용자 권한 설정*
• SQL Server 안팎으로 데이터 전송*
• 데이터베이스 백업 및 복원*
• 복제 구현 및 유지 관리
• 무인 작업 계획*
• SQL Server 성능 모니터링 및 튜닝*
• 시스템 문제 진단

* 표시가 붙은 항목들은 다른 보안 역할이나 사용자에게 위임할 수 있습니다.

sysadmin 고정 서버 역할의 구성원이 SQL Server 7.0에서 수행할 수 있는 작업에는 제한이 없습니다. 따라서 이 역할의 구성원은 모든 데이터베이스 및 특정 SQL Server 인스턴스의 모든 개체(데이터 포함)에 액세스할 수 있습니다. Oracle DBA와 마찬가지로 sysadmin 역할의 구성원만이 실행할 수 있는 여러 가지 명령과 시스템 프로시저가 있습니다.

db_owner 역할

Microsoft SQL Server 데이터베이스와 Oracle 테이블 공간은 사용 방식은 비슷하지만 관리 방식은 다릅니다. 각 SQL Server 데이터베이스는 독립적인 관리 도메인입니다. 각 데이터베이스에는 데이터베이스 소유자(dbo)가 할당됩니다. 이 사용자는 언제나 db_owner 고정 데이터베이스 역할의 구성원입니다. 다른 사용자들은 db_owner 역할의 구성원이 될 수도 있습니다. 이 역할의 구성원인 모든 사용자는 자신의 데이터베이스와 관련된 관리 작업을 관리할 수 있습니다. 이는 한 DBA만 모든 테이블 공간의 관리 작업을 관리하는 Oracle과 다릅니다. 이러한 작업은 아래와 같습니다.

• 데이터베이스 액세스 관리
• 데이터베이스 옵션 변경(읽기 전용, 단일 사용자 등)
• 데이터베이스 내용 백업 및 복원
• 데이터베이스 사용 권한 부여 및 해지
• 데이터베이스 개체 만들기 및 제거

db_owner 역할의 구성원은 자신의 데이터베이스 안에서 모든 작업을 수행할 수 있는 권한이 있습니다. 이 역할에 할당된 대부분의 권한을 여러 고정 데이터베이스 역할로 분리하거나 데이터베이스 사용자에게 부여할 수 있습니다. sysadmin이라는 서버 차원의 권한이 없어도 데이터베이스의 db_owner 권한을 가질 수 있습니다.

Microsoft SQL Server 설치 및 구성

Oracle과 SQL Server의 기본적인 구조 차이를 이해하고 있다면 마이그레이션 프로세스의 첫 단계를 수행할 준비가 된 것입니다. SQL Server 쿼리 분석기를 사용하여 아래와 같은 스크립트를 실행해야 합니다.

1. Windows NT 소프트웨어 기반 RAID 또는 하드웨어 기반 RAID 레벨 5를 사용하여 모든 데이터를 보관할 수 있는 크기의 논리 드라이브를 만듭니다. Oracle 시스템, 임시 테이블 공간, 응용 프로그램 테이블 공간에 사용되는 총 파일 공간을 더해 예상 공간을 계산할 수 있습니다.
2. Windows NT 소프트웨어 기반 RAID 또는 하드웨어 기반 RAID 레벨 1을 사용하여 트랜잭션 로그를 보관할 둘째 논리 드라이브를 만듭니다. 이 드라이브의 크기는 적어도 온라인 REDO와 롤백 세그먼트 테이블 공간을 더한 크기와 같아야 합니다.
3. SQL Server 엔터프라이즈 관리자를 사용하여 Oracle 응용 프로그램의 테이블 공간과 같은 이름을 가진 데이터베이스를 만듭니다. 예제 응용 프로그램에서는 USER_DB 데이터베이스 이름을 사용합니다. 데이터와 트랜잭션 로그에 대해 각각 1단계와 2단계에서 만든 디스크와 일치하는 파일 위치를 지정합니다. 여러 개의 Oracle 테이블 공간을 사용한다고 여러 개의 SQL Server 데이터베이스를 사용할 필요가 없으며 바람직하지도 않습니다. RAID가 자동으로 데이터를 분산시킵니다.
4. 아래와 같이 SQL Server 로그인 계정을 만듭니다.

   USE MASTER
   EXEC SP_ADDLOGIN STUDENT_ADMIN, STUDENT_ADMIN
   EXEC SP_ADDLOGIN DEPT_ADMIN, DEPT_ADMIN
   EXEC SP_ADDLOGIN ENDUSER1, ENDUSER1
   GO

5. 아래와 같이 데이터베이스에 역할을 추가합니다.

   USE USER_DB
   EXEC SP_ADDROLE DATA_ADMIN
   EXEC SP_ADDROLE USER_LOGON
   GO

6. 아래와 같이 역할에 사용 권한을 부여합니다.

   GRANT CREATE TABLE, CREATE TRIGGER, CREATE VIEW,
   CREATE PROCEDURE TO DATA_ADMIN
   GO

7. 아래와 같이 로그인 계정을 데이터베이스 사용자 계정으로 추가합니다.

   EXEC SP_ADDUSER ENDUSER1, ENDUSER1, USER_LOGON
   EXEC SP_ADDUSER DEPT_ADMIN, DEPT_ADMIN, DATA_ADMIN
   EXEC SP_ADDUSER STUDENT_ADMIN, STUDENT_ADMIN, DATA_ADMIN
   GO

아래 그림은 이 프로세스가 완료된 후의 SQL Server 및 Oracle 환경을 나타낸 것입니다.

데이터베이스 개체 정의

각 RDBMS는 개체 정의에 관한 SQL-92 표준을 준수하기 때문에 테이블, 뷰, 인덱스 같은 Oracle 데이터베이스 개체를 Microsoft SQL Server로 쉽게 마이그레이션할 수 있습니다. Oracle SQL 테이블, 인덱스 및 뷰 정의를 SQL Server 테이블, 인덱스 및 뷰 정의로 변환할 때는 비교적 간단한 구문 변경만 수행하면 됩니다. 데이터베이스 개체와 관련된 Oracle과 Microsoft SQL Server의 몇 가지 차이점이 아래 표에 정리되어 있습니다.

범주	Microsoft SQL Server	Oracle
열 수	1024	254
행 크기	8060바이트+16바이트(각 text 또는 image 열을 가리킴)	제한 없음(행마다 Long 또는 Long Raw가 하나만 허용됨)
최대 행 수	제한 없음	제한 없음
BLOB 형식 저장소	행과 함께 저장되는 16바이트 포인터 및 다른 데이터 페이지에 저장된 데이터	테이블마다 Long 또는 Long Raw가 하나만 허용됩니다. 행의 끝에 있어야 합니다. 데이터가 행과 같은 블록에 저장됩니다.
클러스터된 테이블 인덱스	테이블 당 하나	테이블 당 하나(인덱스 구성된 테이블)
클러스터되지 않은 테이블 인덱스	테이블 당 249개	제한 없음
단일 인덱스의 최대 인덱스 열 수	16	16
인덱스 안의 최대 열 길이 값	900바이트	½블록
테이블 명명 규칙	[[[서버.]데이터베이스.]소유자.] 테이블_이름	[스키마.]테이블_이름
뷰 명명 규칙	[[[서버.]데이터베이스.]소유자.] 테이블_이름	[스키마.]테이블_이름
인덱스 명명 규칙	[[[서버.]데이터베이스.]소유자.] 테이블_이름	[스키마.]테이블_이름

데이터베이스 개체를 만드는 데 사용되는 프로그램 또는 Oracle SQL 스크립트로 작업을 시작한다고 가정합니다. 이 스크립트 또는 프로그램을 복사하고 아래와 같이 수정합니다. 각 변경 사항에 대해서는 이 절의 나머지 부분에서 설명합니다. 이 예제는 예제 응용 프로그램 스크립트인 Oratable.sql 및 Sstable.sql에서 발췌한 것입니다.

1. 데이터베이스 개체 ID가 Microsoft SQL Server 명명 규칙을 준수하는지 확인합니다. 인덱스의 이름만 바꾸면 될 것입니다.
2. 데이터 저장소 매개 변수를 SQL Server에서 동작하도록 수정합니다. RAID를 사용하는 경우 저장소 매개 변수가 필요하지 않습니다.
3. Oracle 제약 조건 정의를 SQL Server에서 동작하도록 수정합니다. 필요하면 외래 키 DELETE CASCADE 문을 지원하는 트리거를 만듭니다. 테이블이 여러 데이터베이스에 걸쳐 있으면 트리거를 사용하여 외래 키 관계를 유지합니다.
4. 클러스터된 인덱스를 사용하도록 CREATE INDEX 문을 수정합니다.
5. 데이터 변환 서비스를 사용하여 CREATE TABLE 문을 새로 만듭니다. Oracle 데이터 형식이 SQL Server 데이터 형식에 어떻게 매핑되는지 유의하면서 문을 검토합니다.
6. 모든 CREATE SEQUENCE 문을 제거합니다. 시퀀스 사용을 CREATE TABLE 또는 ALTER TABLE 문의 ID 열로 바꿉니다.
7. 필요하면 CREATE VIEW 문을 수정합니다.
8. 모든 동의어 참조를 제거합니다.
9. 응용 프로그램에서 Microsoft SQL Server 임시 테이블의 사용과 그 유용성을 평가합니다.
10. 모든 Oracle CREATE TABLEUAS SELECT 명령을 SQL Server SELECTUINTO 문으로 바꿉니다.
11. 사용자 정의 규칙, 데이터 형식, 기본값을 어떻게 사용할 것인지 평가합니다.

아래 표는 Oracle과 Microsoft SQL Server의 개체 ID 처리 방법을 비교한 것입니다. 대부분의 경우, SQL Server로 마이그레이션할 때 개체의 이름을 변경할 필요가 없습니다.

Oracle	Microsoft SQL Server
1-30자 데이터베이스 이름: 최대 8자 데이터베이스 링크 이름: 최대 128자	1-128자의 유니코드 문자 임시 테이블 이름: 최대 116자
ID 이름은 반드시 문자로 시작해야 하며 영숫자 문자 또는 _, $, #을 포함할 수 있습니다.	ID 이름은 영숫자 문자 또는 _로 시작할 수 있으며 사실상 모든 문자를 포함할 수 있습니다. ID가 공백으로 시작하거나 _, @, #, $ 이외의 문자가 포함된 경우 ID 이름을 [ ](구분 기호)로 묶어야 합니다. 개체가 아래 문자들로 시작되는 경우 @로 시작되면 지역 변수입니다. #로 시작되면 임시 로컬 개체입니다. ##로 시작되면 임시 글로벌 개체입니다.
테이블 공간 이름은 고유해야 합니다.	데이터베이스 이름은 고유해야 합니다.
ID 이름은 사용자 계정(스키마) 안에서 고유해야 합니다.	ID 이름은 데이터베이스 사용자 계정 안에서 고유해야 합니다.
열 이름은 테이블과 뷰 안에서 고유해야 합니다.	열 이름은 테이블과 뷰 안에서 고유해야 합니다.
인덱스 이름은 사용자 스키마 안에서 고유해야 합니다.	인덱스 이름은 데이터베이스 테이블 이름 안에서 고유해야 합니다.

Oracle 사용자 계정에 있는 테이블에 액세스할 때는 정식 이름을 사용하지 않아도 테이블을 선택할 수 있습니다. 다른 Oracle 스키마의 테이블에 액세스하려면 스키마 이름 앞에 마침표(.) 하나와 테이블 이름을 포함해야 합니다. Oracle 동의어는 추가적인 위치 투명도를 제공할 수 있습니다.

Microsoft SQL Server는 테이블을 참조할 때 다른 규칙을 사용합니다. 하나의 SQL Server 로그인 계정으로 여러 데이터베이스에 같은 이름의 테이블을 만들 수 있기 때문에 [[데이터베이스_이름.]소유자_이름.]테이블_이름 규칙을 사용하여 테이블과 뷰에 액세스합니다.

아래 항목의 테이블에 액세스	Oracle	Microsoft SQL Server
사용자 계정	SELECT * FROM STUDENT	SELECT * FROM USER_DB.STUDENT_ ADMIN.STUDENT
다른 스키마	SELECT * FROM STUDENT_ADMIN.STUDENT	SELECT * FROM OTHER_DB.STUDENT_ ADMIN.STUDENT

다음은 Microsoft SQL Server의 테이블 및 뷰 이름 지정에 관한 지침입니다.

• 데이터베이스 이름과 사용자 이름을 사용하는 것은 선택 사항입니다. 테이블이 STUDENT 같은 이름으로만 참조되면 SQL Server는 현재 데이터베이스의 현재 사용자 계정에서 그 테이블을 검색합니다. 그 테이블이 없으면 데이터베이스에서 예약된 사용자 이름 dbo가 소유한 동일 이름의 개체를 찾습니다. 테이블 이름은 데이터베이스의 사용자 계정 안에서 고유해야 합니다.
• 같은 SQL Server 로그인 계정은 여러 데이터베이스에서 같은 이름의 테이블을 소유할 수 있습니다. 예를 들어, ENDUSER1 계정은 USER_DB.ENDUSER1.STUDENT 및 OTHER_DB.ENDUSER1.STUDENT 데이터베이스 개체를 소유합니다. 한정자는 SQL Server 로그인 이름이 아니라 데이터베이스 사용자 이름입니다. 이들이 서로 같을 필요는 없습니다.

동시에, 이들 데이터베이스의 다른 사용자들도 아래와 같이 같은 이름으로 개체를 소유할 수 있습니다.

• USER_DB.DBO.STUDENT
• USER_DB.DEPT_ADMIN.STUDENT
• USER_DB.STUDENT_ADMIN.STUDENT
• OTHER_DB.DBO.STUDENT

따라서 데이터베이스 개체에 대한 참조의 일부로 소유자 이름을 포함하는 것이 좋습니다. 응용 프로그램에 여러 데이터베이스가 있는 경우 데이터베이스 이름도 참조의 일부로 포함하는 것이 좋습니다. 쿼리가 여러 서버에 걸쳐 있으면 서버 이름도 포함합니다.

• SQL Server에 대한 모든 연결은 로그인 시에 USE 문을 사용하여 설정된 현재 데이터베이스 컨텍스트를 가집니다. 예를 들어, 아래와 같은 시나리오를 생각할 수 있습니다.

  ENDUSER1 계정을 사용하는 어떤 사용자가 USER_DB 데이터베이스에 로그인했습니다. 그 사용자가 STUDENT 테이블을 요청합니다. SQL Server가 ENDUSER1.STUDENT 테이블을 검색합니다. 찾는 테이블이 있으면 SQL Server가 USER_DB.ENDUSER1.STUDENT에 대해 요청된 데이터베이스 작업을 수행합니다. ENDUSER1 데이터베이스 계정에 테이블이 없으면, SQL Server는 그 데이터베이스의 dbo 계정에서 USER_DB.DBO.STUDENT를 검색합니다. 그래도 테이블이 없으면 SQL Server는 테이블이 없다는 내용의 오류 메시지를 반환합니다.

• 예를 들어, DEPT_ADMIN라는 또 다른 사용자가 테이블을 소유한 경우 테이블 이름 앞에 데이터베이스 사용자의 이름(DEPT_ADMIN.STUDENT)을 포함해야 합니다. 그렇지 않으면 데이터베이스 이름이 기본값으로 현재 컨텍스트에 있는 데이터베이스가 됩니다.
• 참조된 테이블이 다른 데이터베이스에 있으면 참조의 일부로 데이터베이스 이름을 사용해야 합니다. 예를 들어, OTHERDB 데이터베이스의 ENDUSER1이 소유한 STUDENT 테이블에 액세스하려면 OTHER_DB.ENDUSER1.STUDENT를 사용합니다.

데이터베이스 이름과 테이블 이름을 2개의 마침표로 구분하면 개체의 소유자를 생략할 수 있습니다. 예를 들어, 응용 프로그램이 STUDENT_DB..STUDENT를 참조하는 경우 SQL Server는 아래와 같이 검색합니다.

1. STUDENT_DB.current_user.STUDENT
2. STUDENT_DB.DBO.STUDENT

응용 프로그램이 한 번에 한 데이터베이스만 사용하는 경우 개체 참조에서 데이터베이스 이름을 생략하면 응용 프로그램을 다른 데이터베이스에서 쉽게 사용할 수 있습니다. 모든 개체 참조는 현재 사용되고 있는 데이터베이스에 암시적으로 액세스합니다. 이는 테스트 데이터베이스와 프로덕션 데이터베이스를 같은 서버에 유지하고자 할 때 유용합니다.

Oracle과 SQL Server 모두 RDBMS 개체를 식별하기 위한 초급 SQL-92 규칙을 지원하기 때문에 CREATE TABLE 구문이 비슷합니다.

Oracle	Microsoft SQL Server
CREATE TABLE [스키마.]테이블_이름 ( {열_이름 열_속성 [기본_식] [제약 조건 [제약 조건 [...제약 조건]]]| [[,] 제약 조건]} [[,] {다음_열_이름 | 다음_제약 조건}...] ) [Oracle 전용 데이터 저장소 매개 변수]	CREATE TABLE [서버.][데이터베이스.][소유자.] 테이블_이름 ( {열_이름 열_속성[제약 조건 [제약 조건 [...제약 조건]]]| [[,] 제약 조건]} [[,] {다음_열_이름 | 다음_제약 조건}...] ) [ON 파일 그룹_이름]

Oracle의 데이터베이스 개체 이름은 대/소문자를 구분하지 않습니다. Microsoft SQL Server의 데이터베이스 개체 이름은 선택한 설치 옵션에 따라 대/소문자를 구분할 수 있습니다.

SQL Server를 처음 설치할 때 기본 정렬 순서는 사전순이며 대/소문자를 구분하지 않습니다. SQL Server 설치 프로그램을 사용하면 이 구성을 다르게 설정할 수 있습니다. Oracle 개체 이름은 언제나 고유하기 때문에 데이터베이스 개체를 SQL Server로 마이그레이션하는 데 문제가 없습니다. 사용자가 대/소문자를 구분하는 SQL Server에 설치하는 경우 문제가 발생하지 않도록 Oracle과 SQL Server의 모든 테이블 이름과 열 이름에 대문자를 사용하는 것이 좋습니다.

Microsoft SQL Server와 함께 RAID를 사용하면 대개 데이터베이스 개체를 간단하게 배치할 수 있습니다. SQL Server의 클러스터된 인덱스는 Oracle의 인덱스 구성된 테이블처럼 테이블 구조에 통합됩니다.

Oracle

Microsoft SQL Server

CREATE TABLE DEPT_ADMIN.DEPT ( DEPT VARCHAR2(4) NOT NULL, DNAME VARCHAR2(30) NOT NULL, CONSTRAINT DEPT_DEPT_PK PRIMARY KEY (DEPT) USING INDEX TABLESPACE USER_DATA PCTFREE 0 STORAGE (INITIAL 10K NEXT 10K MINEXTENTS 1 MAXEXTENTS UNLIMITED), CONSTRAINT DEPT_DNAME_UNIQUE UNIQUE (DNAME) USING INDEX TABLESPACE USER_DATA PCTFREE 0 STORAGE (INITIAL 10K NEXT 10K MINEXTENTS 1 MAXEXTENTS UNLIMITED) ) PCTFREE 10 PCTUSED 40 TABLESPACE USER_DATA STORAGE (INITIAL 10K NEXT 10K MINEXTENTS 1 MAXEXTENTS UNLIMITED FREELISTS 1)

CREATE TABLE USER_DB.DEPT_ADMIN.DEPT ( DEPT VARCHAR(4) NOT NULL, DNAME VARCHAR(30) NOT NULL, CONSTRAINT DEPT_DEPT_PK PRIMARY KEY CLUSTERED (DEPT), CONSTRAINT DEPT_DNAME_UNIQUE UNIQUE NONCLUSTERED (DNAME) )

Oracle을 사용하면 임의의 유효한 SELECT 명령으로 테이블을 만들 수 있습니다. Microsoft SQL Server에서는 같은 기능이 다른 구문으로 제공됩니다.

Oracle	Microsoft SQL Server
CREATE TABLE STUDENTBACKUP AS SELECT * FROM STUDENT	SELECT * INTO STUDENTBACKUP FROM STUDENT

SELECTUINTO 문은 이 문이 적용되는 데이터베이스에서 데이터베이스 구성 옵션 select into/bulkcopy를 true로 설정해야만 동작합니다. 데이터베이스 소유자는 SQL Server 엔터프라이즈 관리자 또는 Transact-SQL sp_dboption 시스템 저장 프로시저를 사용하여 이 옵션을 설정할 수 있습니다. sp_helpdb 시스템 저장 프로시저를 사용하여 데이터베이스의 상태를 확인합니다. select into/bulkcopy가 true로 설정되어 있지 않더라도 아래와 같이 SELECT 문을 사용하여 임시 테이블에 복사할 수 있습니다.

SELECT * INTO #student_backup FROM user_db.student_admin.student

SELECT.. INTO 문을 사용하여 새 테이블을 만들 때는 참조 무결성 정의가 새 테이블로 전송되지 않습니다.

select into/bulkcopy 옵션을 true로 설정해야 하기 때문에 마이그레이션 프로세스가 복잡해질 수 있습니다. SELECT 문을 사용하여 데이터를 테이블에 복사해야 하는 경우 먼저 테이블을 만든 다음 INSERT INTOUSELECT 문을 사용하여 테이블을 로드합니다. 구문은 Oracle과 SQL Server 모두 같으며 데이터베이스 옵션을 설정할 필요가 없습니다.

Microsoft SQL Server에서 뷰를 만드는 데 사용하는 구문은 Oracle의 구문과 비슷합니다.

Oracle	Microsoft SQL Server
CREATE [OR REPLACE] [FORCE | NOFORCE] VIEW [스키마.]뷰_이름 [(열_이름 [, 열_이름]...)] AS select_문 [WITH CHECK OPTION [CONSTRAINT 이름]] [WITH READ ONLY]	CREATE VIEW [소유자.]뷰_이름 [(열_이름 [, 열_이름]...)] [WITH ENCRYPTION] AS select_문 [WITH CHECK OPTION]

SQL Server 뷰를 사용하려면 해당 테이블이 존재해야 하고 뷰 소유자가 SELECT 문(Oracle FORCE 옵션과 비슷함)에 지정된 요청된 테이블에 액세스할 수 있는 권한이 있어야 합니다.

기본적으로, 영향을 받는 행이 뷰 범위 안에 있는지 여부를 확인할 수 있도록 뷰에 대한 데이터 수정 문이 확인되지는 않습니다. 모든 수정 사항을 확인하려면 WITH CHECK OPTION을 사용합니다. Oracle과 SQL Server의 WITH CHECK OPTION의 주된 차이점은 Oracle에서는 제약 조건으로 정의되지만 SQL Server에서는 그렇지 않다는 것입니다. 이를 제외하고는 Oracle과 SQL Server에서 같은 기능을 합니다.

Oracle은 뷰를 정의할 때 WITH READ ONLY 옵션을 제공합니다. SQL Server 응용 프로그램은 SELECT 사용 권한만 뷰 사용자에게 부여하면 같은 결과를 얻을 수 있습니다.

SQL Server 및 Oracle 뷰는 산술식, 함수 및 상수식을 사용하여 파생 열을 지원합니다. SQL Server의 구체적인 몇 가지 차이점은 아래와 같습니다.

• 데이터 수정 문(INSERT 또는 UPDATE)이 기본 테이블 하나에만 영향을 끼칠 경우에는 여러 뷰에 데이터 수정문이 허용됩니다. 단일 문의 둘 이상의 테이블에는 데이터 수정 문을 사용할 수 없습니다.
• 뷰의 text 또는 image 열에 READTEXT 또는 WRITETEXT를 사용할 수 없습니다.
• ORDER BY, COMPUTE, FOR BROWSE 또는 COMPUTE BY 절은 사용할 수 없습니다.
• 뷰에 INTO 키워드를 사용할 수 없습니다.

외부 조인으로 정의된 뷰를 외부 조인의 내부 테이블에서 열 자격을 사용하여 쿼리하는 경우 SQL Server와 Oracle의 결과가 서로 다를 수 있습니다. 대부분의 경우, Oracle 뷰는 SQL Server 뷰로 쉽게 변환됩니다.

Oracle	Microsoft SQL Server
CREATE VIEW STUDENT_ADMIN.STUDENT_GPA (SSN, GPA) AS SELECT SSN, ROUND(AVG(DECODE(grade ,'A', 4 ,'A+', 4.3 ,'A-', 3.7 ,'B', 3 ,'B+', 3.3 ,'B-', 2.7 ,'C', 2 ,'C+', 2.3 ,'C-', 1.7 ,'D', 1 ,'D+', 1.3 ,'D-', 0.7 ,0)),2) FROM STUDENT_ADMIN.GRADE GROUP BY SSN	CREATE VIEW STUDENT_ADMIN.STUDENT_GPA (SSN, GPA) AS SELECT SSN, ROUND(AVG(CASE grade WHEN 'A' THEN 4 WHEN 'A+' THEN 4.3 WHEN 'A-' THEN 3.7 WHEN 'B' THEN 3 WHEN 'B+' THEN 3.3 WHEN 'B-' THEN 2.7 WHEN 'C' THEN 2 WHEN 'C+' THEN 2.3 WHEN 'C-' THEN 1.7 WHEN 'D' THEN 1 WHEN 'D+' THEN 1.3 WHEN 'D-' THEN 0.7 ELSE 0 END),2) FROM STUDENT_ADMIN.GRADE GROUP BY SSN

Microsoft SQL Server는 클러스터된 인덱스 구조와 클러스터되지 않은 인덱스 구조를 모두 제공합니다. 이러한 인덱스는 B-트리(Oracle B-트리 인덱스 구조와 비슷함)라는 분기 구조를 형성하는 페이지들로 구성됩니다. 시작 페이지(루트 수준)는 테이블 안의 값 범위를 지정합니다. 루트 수준 페이지의 각 범위는 더 제한된 테이블 값 범위가 포함된 다른 페이지(결정 노드)를 가리킵니다. 이러한 결정 노드가 또 다른 결정 노드를 가리켜서 검색 범위를 더 좁힐 수 있습니다. 분기 구조의 마지막 수준을 잎 수준이라고 합니다.

클러스터된 인덱스

클러스터된 인덱스가 Oracle에서는 인덱스 구성된 테이블로 구현됩니다. 클러스터된 인덱스는 물리적으로 테이블과 병합된 인덱스입니다. 테이블과 인덱스가 같은 저장소 영역을 공유합니다. 클러스터된 인덱스는 데이터 행들을 인덱스 순서대로 물리적으로 재배열하여 중간 결정 노드를 형성합니다. 인덱스의 잎 페이지에는 실제 테이블 데이터가 포함됩니다. 이 아키텍처에서는 클러스터된 인덱스가 테이블 당 하나만 허용됩니다. Microsoft SQL Server는 PRIMARY KEY 또는 UNIQUE 제약 조건이 테이블에 배치될 때마다 테이블에 대해 클러스터된 인덱스를 자동으로 만듭니다. 클러스터된 인덱스는 아래 항목에 유용합니다.

• 기본 키
• 업데이트되지 않은 열
• 아래 경우처럼 BETWEEN, >, >=, <, <= 같은 연산자를 사용하여 값 범위를 반환하는 쿼리

  SELECT * FROM STUDENT WHERE GRAD_DATE
  BETWEEN '1/1/97' AND '12/31/97'
  

• 큰 결과 집합을 반환하는 쿼리

  SELECT * FROM STUDENT WHERE LNAME = 'SMITH'
  

• 정렬 연산(ORDER BY, GROUP BY)에 사용되는 열

  예를 들어, STUDENT 테이블에서는 기본 키 ssn에 클러스터되지 않은 인덱스를 포함하고 lname(성), fname(이름)에 클러스터된 인덱스를 만드는 것이 좋습니다. 학생들을 보통 이런 식으로 그룹화하기 때문입니다.

• 핫스폿을 막기 위해 수행하는 테이블의 업데이트 활동 분산. 핫스폿은 여러 사용자가 오름차순 키로 한 테이블에 삽입할 때 자주 발생합니다. 이러한 문제는 대개 행 수준 잠금을 통해 처리합니다.

클러스터된 인덱스를 제거하고 다시 만드는 것은 SQL Server의 테이블을 재구성하는 일반적인 방법입니다. 이는 데이터 페이지를 디스크에 연속적으로 배치하고 테이블에 어느 정도의 여유 공간을 다시 만들 때 사용할 수 있는 손쉬운 방법입니다. 이 방법은 Oracle의 테이블 내보내기, 제거, 가져오기와 비슷합니다.

SQL Server의 클러스터된 인덱스는 Oracle 클러스터와는 전혀 다릅니다. Oracle 클러스터는 같은 데이터 블록을 공유하고 공통의 열을 클러스터 키로 사용하는 둘 이상의 테이블을 물리적으로 그룹화한 것입니다. SQL Server에는 Oracle 클러스터와 비슷한 구조가 없습니다.

일반적으로, 테이블에 클러스터된 인덱스를 정의하면 SQL Server 성능과 공간 관리가 개선됩니다. 주어진 테이블에 대한 쿼리나 업데이트 패턴을 모르는 경우 기본 키에 클러스터된 인덱스를 만들 수 있습니다.

아래 표는 예제 응용 프로그램 원본 코드에서 발췌한 것입니다. SQL Server의 클러스터된 인덱스 사용을 눈여겨 보십시오.

Oracle	Microsoft SQL Server
CREATE TABLE STUDENT_ADMIN.GRADE ( SSN CHAR(9) NOT NULL, CCODE VARCHAR2(4) NOT NULL, GRADE VARCHAR2(2) NULL, CONSTRAINT GRADE_SSN_CCODE_PK PRIMARY KEY (SSN, CCODE) CONSTRAINT GRADE_SSN_FK FOREIGN KEY (SSN) REFERENCES STUDENT_ADMIN.STUDENT (SSN), CONSTRAINT GRADE_CCODE_FK FOREIGN KEY (CCODE) REFERENCES DEPT_ADMIN.CLASS (CCODE) )	CREATE TABLE STUDENT_ADMIN.GRADE ( SSN CHAR(9) NOT NULL, CCODE VARCHAR(4) NOT NULL, GRADE VARCHAR(2) NULL, CONSTRAINT GRADE_SSN_CCODE_PK PRIMARY KEY CLUSTERED (SSN, CCODE), CONSTRAINT GRADE_SSN_FK FOREIGN KEY (SSN) REFERENCES STUDENT_ADMIN.STUDENT (SSN), CONSTRAINT GRADE_CCODE_FK FOREIGN KEY (CCODE) REFERENCES DEPT_ADMIN.CLASS (CCODE) )

클러스터되지 않은 인덱스

클러스터되지 않은 인덱스에서는 인덱스 데이터와 테이블 데이터가 물리적으로 구분되며 테이블의 행들이 인덱스 순서대로 저장되지 않습니다. 아래 예제와 같이 Oracle 인덱스 정의를 Microsoft SQL Server의 클러스터되지 않은 인덱스 정의로 마이그레이션할 수 있습니다. 그러나 성능 상의 이유 때문에 주어진 테이블의 인덱스 중 하나를 선택하여 클러스터된 인덱스로 만들 수도 있습니다.

Oracle	Microsoft SQL Server
CREATE INDEX STUDENT_ADMIN.STUDENT_ MAJOR_IDX ON STUDENT_ADMIN.STUDENT (MAJOR) TABLESPACE USER_DATA PCTFREE 0 STORAGE (INITIAL 10K NEXT 10K MINEXTENTS 1 MAXEXTENTS UNLIMITED)	CREATE NONCLUSTERED INDEX STUDENT_MAJOR_IDX ON USER_DB.STUDENT_ ADMIN.STUDENT (MAJOR)

인덱스 구문 및 명명

Oracle의 인덱스 이름은 사용자 계정 안에서 고유합니다. Microsoft SQL Server의 인덱스 이름은 테이블 이름 안에서는 고유해야 하지만 사용자 계정이나 데이터베이스 안에서는 고유하지 않아도 됩니다. 따라서 SQL Server에서 인덱스를 만들거나 제거할 때는 테이블 이름과 인덱스 이름을 모두 지정해야 합니다. 또한 SQL Server DROP INDEX 문을 사용하면 여러 인덱스를 동시에 제거할 수 있습니다.

Oracle	Microsoft SQL Server
CREATE [UNIQUE] INDEX [스키마].인덱스_이름 ON [스키마.]테이블_이름 (열_이름 [, 열_이름]...) [INITRANS n] [MAXTRANS n] [TABLESPACE 테이블 공간_이름] [STORAGE 저장소_매개 변수] [PCTFREE n] [NOSORT] DROP INDEX ABC;	CREATE [UNIQUE] [CLUSTERED | NONCLUSTERED] INDEX index_name ON table (column [,Un]) [WITH [PAD_INDEX] [[,] FILLFACTOR = 채우기비율] [[,] IGNORE_DUP_KEY] [[,] DROP_EXISTING] [[,] STATISTICS_NORECOMPUTE] ] [ON 파일그룹] DROP INDEX USER_DB.STUDENT.DEMO_IDX, USER_DB.GRADE.DEMO_IDX

인덱스 데이터 저장소 매개 변수

Microsoft SQL Server의 FILLFACTOR 옵션은 Oracle의 PCTFREE 변수와 똑같은 방식으로 동작합니다. 테이블의 크기가 커짐에 따라 새 데이터를 수용하기 위해 인덱스 페이지가 분할됩니다. 이때 인덱스가 새 데이터 값을 수용하기 위해 자체적으로 재구성됩니다. 채우기 비율은 인덱스가 만들어질 때만 사용되며 그 후에는 유지되지 않습니다.

FILLFACTOR 옵션(값은 0부터 100까지)으로 인덱스가 처음 만들어질 때 인덱스 페이지에 남는 공간의 크기를 제어할 수 있습니다. 지정한 값이 없으면 기본 채우기 비율인 0이 사용됩니다. 이 기본값은 인덱스 잎 페이지를 가득 채우며 적어도 한 항목(고유하지 않은 클러스터된 인덱스의 경우 두 항목)에 대해 각 결정 노드 페이지에 공간을 남겨 둡니다.

채우기 비율 값이 낮으면 처음에 인덱스 페이지 분할 횟수가 줄어들며 B-트리 인덱스 구조의 수준 수가 증가합니다. 채우기 비율 값이 높으면 인덱스 페이지 공간이 더 효율적으로 사용되고 인덱스 데이터에 액세스하기 위한 디스크 I/O가 더 적게 필요하며 B-트리 인덱스 구조의 수준 수가 줄어듭니다.

PAD_INDEX 옵션을 지정하면 인덱스의 데이터 페이지뿐만 아니라 결정 노드 페이지에도 채우기 비율 설정이 적용됩니다.

Oracle에서는 최적의 성능을 위해 PCTFREE 매개 변수를 조정해야 할 수 있지만 CREATE INDEX 문에 FILLFACTOR 옵션을 포함할 필요는 거의 없습니다. 채우기 비율은 세밀한 성능 튜닝을 위한 것입니다. 채우기 비율은 기존 데이터가 있는 테이블에 새 인덱스를 만들 때 그리고 그 데이터에 앞으로 어떤 변화가 있을지 정확하게 예측할 수 있을 때만 유용합니다.

Oracle 인덱스에 대해 PCTFREE를 0으로 설정한 경우 채우기 비율 100을 사용해 보십시오. 이는 테이블에서 삽입이나 업데이트가 발생하지 않을 때, 즉 읽기 전용 테이블일 때 사용됩니다. 채우기 비율을 100으로 설정하면 SQL Server는 각 페이지가 100% 채워진 인덱스를 만듭니다.

중복된 키 무시

Oracle과 Microsoft SQL Server에서 사용자들은 고유 인덱스 열에 중복된 값을 삽입할 수 없습니다. 이렇게 하려고 시도하면 오류 메시지가 나타납니다. 그럼에도 불구하고 SQL Server에서는 개발자가 INSERT 또는 UPDATE 문이 오류에 어떤 방법으로 응답해야 하는지를 선택할 수 있습니다.

CREATE INDEX 문에 IGNORE_DUP_KEY가 지정되어 있는데 중복된 키를 만드는 INSERT 또는 UPDATE 문이 실행되면, SQL Server는 경고 메시지를 나타내고 중복된 행을 무시합니다. 즉, 중복된 행을 삽입하지 않습니다. 인덱스에 대해 IGNORE_DUP_KEY가 지정되어 있지 않으면 SQL Server는 오류 메시지를 나타내고 전체 INSERT 문을 롤백합니다. 이 옵션들에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

Oracle 응용 프로그램이 단기간 존재하는 테이블을 만들어야 할 수도 있습니다. 이런 경우 응용 프로그램은 이 목적으로 만든 모든 테이블을 이후에 반드시 제거해야 합니다. 응용 프로그램이 테이블을 제거하지 못하면 테이블 공간이 곧 복잡해져 관리가 어려워질 수 있습니다.

Microsoft SQL Server는 이런 목적을 위해서만 만들어지는 임시 테이블 데이터베이스 개체를 제공합니다. 이러한 테이블은 언제나 tempdb 데이터베이스에 만들어집니다. 테이블 이름에 따라 테이블이 tempdb 데이터베이스에 존재하는 기간이 결정됩니다.

테이블 이름	설명
#table_name	이 임시 로컬 테이블은 사용자 세션 또는 이 테이블을 만든 프로시저가 지속되는 동안에만 존재합니다. 사용자가 로그오프하거나 테이블을 만든 프로시저가 완료되면 자동으로 제거됩니다. 이러한 테이블을 여러 사용자가 공유할 수는 없습니다. 다른 데이터베이스 사용자들은 이 테이블에 액세스할 수 없습니다. 이 테이블에 대해 사용 권한을 부여하거나 해지할 수 없습니다.
##table_name	이 임시 글로벌 테이블도 대개 사용자 세션 또는 이 테이블을 만든 프로시저가 지속되는 동안에만 존재합니다. 이 테이블은 여러 사용자가 공유할 수 있으며 이 테이블을 참조하는 마지막 사용자 세션이 끊어지면 자동으로 제거됩니다. 다른 모든 데이터베이스 사용자가 이 테이블에 액세스할 수 있습니다. 이 테이블에 대해 사용 권한을 부여하거나 해지할 수 없습니다.

임시 테이블에 대해 인덱스를 지정할 수 있습니다. 뷰는 # 또는 ## 접두사 없이 tempdb에 명시적으로 만들어진 테이블에 대해서만 정의할 수 있습니다. 아래 예제는 임시 테이블 및 관련 인덱스를 생성하는 방법을 나타낸 것입니다. 사용자가 작업을 끝내면 테이블과 인덱스가 자동으로 제거됩니다.

SELECT SUM(ISNULL(TUITION_PAID,0)) SUM_PAID, MAJOR INTO #SUM_STUDENT
FROM USER_DB.STUDENT_ADMIN.STUDENT GROUP BY MAJOR

CREATE UNIQUE INDEX SUM STUDENT IDX ON #SUM STUDENT (MAJOR)

임시 테이블을 사용하여 얻을 수 있는 이점은 프로그램 코드를 수정하는 데 대한 충분한 이유가 될 것입니다.

Microsoft SQL Server는 Oracle보다 강력한 데이터 형식을 제공합니다. Oracle과 SQL Server 간에 데이터 형식을 변환할 가능성이 많습니다. 따라서 DTS 마법사를 사용하여 CREATE TABLE 문을 새로 만드는 작업을 자동화하는 것이 좋습니다. 그런 다음 필요에 따라 이러한 문을 수정할 수 있습니다.

Oracle	Microsoft SQL Server
CHAR	char 형식 열은 고정된 저장소 길이를 사용합니다. 따라서 varchar 열보다 좀더 빠르게 액세스할 수 있으므로 char를 사용할 것을 권장합니다.
VARCHAR2 및 LONG	varchar 또는 text를 사용합니다. Oracle 열의 데이터 값 길이가 8000바이트 미만이면 varchar를 사용하고 그렇지 않으면 text를 사용해야 합니다.
RAW 및 LONG RAW	varbinary 또는 image를 사용합니다. Oracle 열의 데이터 값 길이가 8000바이트 미만이면 varbinary를 사용하고 그렇지 않으면 image를 사용해야 합니다.
NUMBER	1에서 255 사이의 정수이면 tinyint를 사용합니다. -32768에서 32767 사이의 정수이면 smallint를 사용합니다. -2,147,483,648에서 2,147,483,647 사이의 정수이면 int를 사용합니다. 부동 소수점 형식의 숫자가 필요하면 정밀도와 배율이 있는 numeric을 사용합니다. 참고: float 또는 real은 반올림이 이뤄질 수 있으므로 사용하지 마십시오. Oracle NUMBER 및 SQL Server의 numeric에서는 반올림이 이뤄지지 않습니다. 확실히 알 수 없으면 Oracle NUMBER 데이터 형식과 거의 비슷한 numeric을 사용하십시오.
DATE	datetime
ROWID	identity 열 형식을 사용합니다.
CURRVAL, NEXTVAL	identity 열 형식 및 @@IDENTITY, IDENT_SEED(), IDENT_INCR() 함수를 사용합니다.
SYSDATE	GETDATE()
USER	USER

유니코드 데이터 사용

유니코드 명세는 전세계의 기업에 널리 사용되고 있는 거의 모든 문자를 위한 단일 인코딩 구성표를 정의합니다. 모든 컴퓨터는 단일한 유니코드 명세를 사용하여 유니코드 데이터의 비트 패턴을 문자로 일관성 있게 변환합니다. 따라서 같은 비트 패턴은 모든 컴퓨터에서 언제나 같은 문자로 변환됩니다. 받는 시스템에서 비트 패턴이 문자로 올바르게 변환될 것인지 걱정할 필요없이 데이터베이스나 컴퓨터 간에 데이터를 자유롭게 전송할 수 있습니다.

1바이트를 사용하여 각 문자를 인코딩하는 이 데이터 형식의 한 가지 문제라면 서로 다른 문자를 256자만 나타낼 수 있다는 것입니다. 따라서 서로 다른 알파벳에 대해 여러 인코딩 명세(또는 코드 페이지)를 정의해야 합니다. 수천 자가 넘는 간지나 한글 같은 문자 체계를 처리할 수 없다는 것도 문제입니다.

Microsoft SQL Server는 SQL Server와 함께 설치되는 코드 페이지의 정의를 사용하여 char, varchar, text 열의 비트 패턴을 문자로 변환합니다. 클라이언트 컴퓨터는 운영 체제에 설치된 코드 페이지를 사용하여 문자 비트 패턴을 해석합니다. 다양한 코드 페이지가 존재하며 어떤 코드 페이지에는 있는데 다른 코드 페이지에는 없는 문자도 있습니다. 코드 페이지에 따라 비트 패턴이 서로 다르게 정의되는 문자들도 있습니다. 다양한 언어를 처리해야 하는 국제적 시스템을 구축할 때는 여러 국가의 언어 요구 사항을 충족하는 모든 컴퓨터를 위한 코드 페이지를 선택하기가 어려워집니다. 또한 다른 코드 페이지를 사용하는 시스템과 연결될 때 모든 컴퓨터에서 정확한 변환이 수행되도록 보장하기도 어렵습니다.

유니코드 명세는 2바이트를 사용하여 각 문자를 인코딩함으로써 이 문제를 해결합니다. 2바이트를 사용하면 65,636가지의 서로 다른 패턴을 정의할 수 있기 때문에 단일 명세로 일반적인 업무용 언어를 포괄할 수 있습니다. 모든 유니코드 시스템은 같은 비트 패턴을 일관성 있게 사용하여 모든 문자를 나타내므로 시스템 간에 이동할 때 문자가 잘못 변환되는 문제가 없습니다.

SQL Server에서는 nchar, nvarchar, ntext 데이터 형식이 유니코드 데이터를 지원합니다. SQL Server 데이터 형식에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

사용자 정의 데이터 형식

model 데이터베이스 또는 단일 사용자 데이터베이스에 대해 사용자 정의 데이터 형식을 만들 수 있습니다. model에 대해 사용자 정의 데이터 형식을 정의하면 그 때부터 만들어지는 모든 신규 사용자 데이터베이스에서 그 데이터 형식을 사용할 수 있습니다. 사용자 정의 데이터 형식은 sp_addtype 시스템 저장 프로시저를 사용하여 정의됩니다. 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

CREATE TABLE 및 ALTER TABLE 문에 사용자 정의 데이터 형식을 사용하고 기본값과 규칙을 바인딩할 수 있습니다. 테이블을 만들면서 사용자 정의 데이터 형식을 사용할 때 Null 허용을 명시적으로 정의하면 이 Null 허용이 그 데이터 형식을 만들 때 정의된 Null 허용보다 우선합니다.

아래 예제는 사용자 정의 데이터 형식을 만드는 방법을 나타낸 것입니다. 인수는 사용자 형식 이름, 데이터 형식 및 Null 허용입니다.

sp_addtype gender_type, 'varchar(1)', 'not null'
go

처음에는 이 기능이 Oracle 테이블 작성 스크립트를 SQL Server로 마이그레이션할 때의 문제를 해결하는 것처럼 보일 것입니다. 예를 들어, Oracle DATE 데이터 형식을 아주 쉽게 추가할 수 있습니다.

sp_addtype date, datetime

이는 Oracle 데이터 형식 NUMBER처럼 변수 크기를 요구하는 데이터 형식에는 작동하지 않습니다. 길이도 지정해야 한다는 내용의 오류 메시지가 반환됩니다.

sp_addtype varchar2, varchar
Go
Msg 15091, Level 16, State 1
이 실제 형식에 길이를 지정해야 합니다.

Microsoft 시간 스탬프 열

시간 스탬프 열을 사용하면 BROWSE 모드 업데이트가 가능하며 커서 업데이트 작업의 효율성이 높아집니다. 시간 스탬프는 시간 스탬프 열이 포함된 행을 삽입하거나 업데이트할 때마다 자동으로 업데이트되는 데이터 형식입니다.

시간 스탬프 열의 값은 실제 날짜 또는 시간으로 저장되지 않고 테이블의 행에 대한 이벤트 시퀀스를 나타내는 binary(8) 또는 varbinary(8)로 저장됩니다. 테이블에는 하나의 시간 스탬프 열만 포함할 수 있습니다.

자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

다른 데이터베이스 사용자, 데이터베이스 그룹, public 역할에 대해 Microsoft SQL Server 개체 권한을 부여하거나 거부하거나 해지할 수 있습니다. Oracle과 달리 SQL Server에서는 개체 소유자가 자신이 소유한 개체에 대한 ALTER TABLE 및 CREATE INDEX 권한을 부여할 수 없습니다. 이러한 권한은 개체 소유자에게 남아 있어야 합니다.

GRANT 문을 지정하면 현재 데이터베이스의 사용자가 현재 데이터베이스의 데이터를 다루거나 특정 Transact-SQL 문을 실행할 수 있도록 하는 보안 시스템 항목이 만들어집니다. GRANT 문의 구문은 Oracle과 SQL Server 모두 같습니다.

DENY 문을 지정하면 현재 데이터베이스의 보안 계정에 대해 사용 권한을 거부하고 보안 계정이 해당 그룹 또는 역할 구성원을 통해 사용 권한을 상속하지 못하도록 하는 보안 시스템 항목이 만들어집니다. Oracle에는 DENY 문이 없습니다. REVOKE 문을 지정하면 이전에 부여되거나 거부된 사용 권한이 현재 데이터베이스의 사용자로부터 제거됩니다.

Oracle

Microsoft SQL Server

GRANT {ALL [PRIVILEGES][열_목록] | 사용 권한_목록 [열_목록]} ON {테이블_이름 [(열_목록)] | 뷰_이름 [(열_목록)] | 저장_프로시저_이름} TO {PUBLIC | 이름_목록 } [WITH GRANT OPTION]

GRANT {ALL [PRIVILEGES] | 사용 권한[,Un]} { [(열[,Un])] ON {테이블 | 뷰} | ON {테이블 | 뷰}[(열[,Un])] | ON {저장_프로시저 | 확장_프로시저} } TO 보안_계정[,Un] [WITH GRANT OPTION] [AS {그룹 | 역할}] REVOKE [GRANT OPTION FOR] {ALL [PRIVILEGES] | 사용 권한[,Un]} { [(열[,Un])] ON {테이블 | 뷰} | ON {테이블 |뷰}[(열[,Un])] | {저장_프로시저 | 확장_프로시저} } {TO | FROM} 보안_계정[,Un] [CASCADE] [AS {그룹 | 역할}] DENY {ALL [PRIVILEGES] | 사용 권한[,Un]} { [(열[,Un])] ON {테이블 | 뷰} | ON {테이블 | 뷰}[(열[,Un])] | ON {저장_프로시저 | 확장_프로시저} } TO 보안_계정[,Un] [CASCADE]

개체 수준 사용 권한에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

Oracle에서는 사용자에 대해서만 REFERENCES 권한을 부여할 수 있습니다. SQL Server에서는 데이터베이스 사용자와 데이터베이스 그룹 모두에 REFERENCES 권한을 부여할 수 있습니다. INSERT, UPDATE, DELETE 및 SELECT 권한은 Oracle과 SQL Server 모두 같은 방법으로 부여합니다.

데이터 무결성 및 업무 규칙 유지

데이터 무결성을 유지하면 데이터베이스의 데이터 품질이 보장됩니다. 테이블을 계획할 때는 열에 대한 유효한 값을 확인하고 열 데이터의 무결성을 유지할 방법을 결정해야 합니다. 데이터 무결성은 네 가지 범주로 구분되며 다양한 방법으로 유지됩니다.

무결성 형식	유지하는 방법
엔티티 무결성	PRIMARY KEY 제약 조건 UNIQUE 제약 조건 IDENTITY 속성
도메인 무결성	도메인 DEFAULT 정의 FOREIGN KEY 제약 조건 CHECK 제약 조건 Null 허용
참조 무결성	도메인 DEFAULT 정의 FOREIGN KEY 제약 조건 CHECK 제약 조건 Null 허용
사용자 정의 무결성	CREATE TABLE의 모든 열 수준 제약 조건과 테이블 수준 제약 조건 저장 프로시저 트리거

엔티티 무결성은 행을 특정 테이블의 고유 엔티티로 정의합니다. 엔티티 무결성은 인덱스, UNIQUE 제약 조건, PRIMARY KEY 제약 조건 또는 IDENTITY 속성을 통해 테이블의 ID 열 또는 기본 키의 무결성을 유지합니다.

명명 제약 조건

제약 조건은 항상 명시적으로 명명해야 합니다. 그렇지 않으면 Oracle과 Microsoft SQL Server가 서로 다른 명명 규칙을 사용하여 제약 조건을 암시적으로 명명합니다. 이처럼 명명 규칙이 달라지면 마이그레이션 프로세스가 불필요하게 복잡해질 수 있습니다. 제약 조건은 이름 별로 제거되기 때문에 제약 조건을 제거하거나 사용 해제할 때 불일치가 나타납니다. 제약 조건을 명시적으로 명명하기 위한 구문은 Oracle과 SQL Server 모두 같습니다.

CONSTRAINT 제약 조건_이름

기본 키 및 고유 열

SQL-92 표준은 기본 키의 모든 값이 고유할 것과 열에 Null 값을 허용하지 않을 것을 요구합니다. Oracle과 Microsoft SQL Server 모두 PRIMARY KEY 또는 UNIQUE 제약 조건이 정의될 때마다 자동으로 고유 인덱스를 만들어 고유성을 유지합니다. 또한 기본 키 열은 자동으로 NOT NULL로 정의됩니다. 테이블 당 하나의 기본 키만 허용됩니다.

클러스터되지 않은 인덱스가 요청될 수도 있지만 기본 키에 대해서는 기본적으로 SQL Server의 클러스터된 인덱스가 만들어집니다. 기본 키에 대한 Oracle 인덱스는 제약 조건을 제거하거나 사용 해제하면 제거할 수 있지만 SQL Server 인덱스는 제약 조건을 제거해야만 제거할 수 있습니다.

어떤 RDBMS이든 UNIQUE 제약 조건을 사용하면 대체 키를 정의할 수 있습니다. 테이블에 여러 개의 UNIQUE 제약 조건을 정의할 수 있습니다. UNIQUE 제약 조건 열에는 Null이 허용됩니다. SQL Server에서는 달리 지정하지 않으면 기본적으로 클러스터되지 않은 인덱스가 만들어집니다.

응용 프로그램을 마이그레이션할 때는, SQL Server의 경우 완전한 고유 키(단일 또는 다중 열 인덱스)에 대해 한 행만 NULL 값을 포함할 수 있지만, Oracle에서는 완전한 고유 키에 대해 여러 행이 NULL 값을 포함할 수 있다는 사실에 유의해야 합니다.

Oracle	Microsoft SQL Server
CREATE TABLE DEPT_ADMIN.DEPT (DEPT VARCHAR2(4) NOT NULL, DNAME VARCHAR2(30) NOT NULL, CONSTRAINT DEPT_DEPT_PK PRIMARY KEY (DEPT) USING INDEX TABLESPACE USER_DATA PCTFREE 0 STORAGE ( INITIAL 10K NEXT 10K MINEXTENTS 1 MAXEXTENTS UNLIMITED), CONSTRAINT DEPT_DNAME_UNIQUE UNIQUE (DNAME) USING INDEX TABLESPACE USER_DATA PCTFREE 0 STORAGE ( INITIAL 10K NEXT 10K MINEXTENTS 1 MAXEXTENTS UNLIMITED) )	CREATE TABLE USER_DB.DEPT_ADMIN.DEPT (DEPT VARCHAR(4) NOT NULL, DNAME VARCHAR(30) NOT NULL, CONSTRAINT DEPT_DEPT_PK PRIMARY KEY CLUSTERED (DEPT), CONSTRAINT DEPT_DNAME_UNIQUE UNIQUE NONCLUSTERED (DNAME) )

제약 조건 추가 및 제거

제약 조건을 사용 해제하면 데이터베이스 성능이 향상되고 데이터 복제 프로세스가 간소화됩니다. 예를 들어, 테이블에 처음 데이터를 입력할 때 데이터 무결성이 검사되므로 원격 사이트에서 테이블 데이터를 다시 만들거나 복제할 때 제약 조건 검사를 반복할 필요가 없습니다. PRIMARY KEY와 UNIQUE를 제외한 제약 조건을 사용 해제하거나 활성화하도록 Oracle 응용 프로그램을 프로그래밍할 수 있습니다. Microsoft SQL Server에서는 ALTER TABLE 문에 CHECK 및 WITH NOCHECK 옵션을 사용하면 이렇게 할 수 있습니다.

아래 그림은 이 프로세스를 비교한 것입니다.

SQL Server에서는 NOCHECK 절에 ALL 키워드를 사용하여 모든 테이블 제약 조건을 지연시킬 수 있습니다.

CASCADE 옵션은 부모 무결성 제약 조건 및 관련된 자식 무결성 제약 조건을 모두 사용 해제하거나 제거하므로, Oracle 응용 프로그램이 CASCADE 옵션을 사용하여 PRIMARY KEY 또는 UNIQUE 제약 조건을 사용 해제하거나 제거하는 경우 일부 코드를 다시 작성해야 할 수 있습니다.

다음은 구문 예제입니다.

DROP CONSTRAINT DEPT_DEPT_PK CASCADE

먼저 자식 제약 조건을 제거한 다음 부모 제약 조건을 제거하도록 SQL Server 응용 프로그램을 수정해야 합니다. 예를 들어, DEPT 테이블의 PRIMARY KEY 제약 조건을 제거하려면 STUDENT.MAJOR 및 CLASS.DEPT 열의 외래 키를 제거해야 합니다. 다음은 구문 예제입니다.

ALTER TABLE STUDENT
DROP CONSTRAINT STUDENT_MAJOR_FK
ALTER TABLE CLASS
DROP CONSTRAINT CLASS_DEPT_FK
ALTER TABLE DEPT
DROP CONSTRAINT DEPT_DEPT_PK

제약 조건을 추가하고 제거하는 ALTER TABLE 구문은 Oracle과 SQL Server 모두 거의 같습니다.

순차적 숫자 값 만들기

Oracle 응용 프로그램이 SEQUENCE를 사용하는 경우 Microsoft SQL Server의 IDENTITY 속성을 사용하도록 쉽게 변경할 수 있습니다.

범주	Microsoft SQL Server IDENTITY
구문	CREATE TABLE new_employees ( Empid int IDENTITY (1,1), Employee_Name varchar(60), CONSTRAINT Emp_PK PRIMARY KEY (Empid) ) 증분 값이 5인 경우 아래와 같이 합니다. CREATE TABLE new_employees ( Empid int IDENTITY (1,5), Employee_Name varchar(60), CONSTRAINT Emp_PK PRIMARY KEY (Empid) )
테이블 당 ID 열	하나
Null 값 허용	허용 안함
기본 제약 조건, 값 사용	사용할 수 없음
고유성 유지	유지됨
INSERT, SELECT INTO 또는 대량 복사 문이 완료된 후 현재의 최대 ID 번호 쿼리	@@IDENTITY(function)
ID 열을 만드는 동안 지정한 시드 값 반환	IDENT_SEED('테이블_이름')
ID 열을 만드는 동안 지정한 증분 값 반환	IDENT_INCR('테이블_이름')
SELECT 구문	SELECT, INSERT, UPDATE, DELETE 문에서 IDENTITY 속성이 있는 열을 참조할 때 열 이름 대신 IDENTITYCOL 키워드를 사용할 수 있습니다.

IDENTITY 속성을 지정하면 한 테이블 안에서 행 번호가 자동으로 매겨지지만 자체의 ID 열이 있는 여러 테이블이 같은 값을 만들 수 있습니다. 이는 IDENTITY 속성이 이 속성이 사용되는 테이블에 대해서만 고유성을 보장받기 때문입니다. 응용 프로그램이 전체 데이터베이스 또는 전세계의 모든 네트워크 컴퓨터의 모든 데이터베이스에 걸쳐 고유한 ID 열을 만들어야 하는 경우, ROWGUIDCOL 속성, uniqueidentifier 데이터 형식 및 NEWID 함수를 사용하십시오. SQL Server는 병합 복제에 전역 고유 ID 열을 사용하여 테이블의 여러 복사본에 걸쳐 행이 고유하게 확인되도록 보장합니다.

ID 열 만들기 및 수정에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

도메인 무결성은 주어진 열에 대해 유효한 항목을 유지합니다. 도메인 무결성은 형식(데이터 형식을 통해), 서식(CHECK 제약 조건을 통해) 또는 사용 가능한 값의 범위(REFERENCE 및 CHECK 제약 조건을 통해)를 제한함으로써 유지됩니다.

DEFAULT 및 CHECK 제약 조건

Oracle은 기본값을 열 속성으로 취급하고 Microsoft SQL Server는 제약 조건으로 취급합니다. SQL Server의 DEFAULT 제약 조건에는 상수 값, 인수를 취하지 않는 기본 제공 함수(Niladic 함수) 또는 NULL이 포함될 수 있습니다.

Oracle DEFAULT 열 속성을 쉽게 마이그레이션하려면 제약 조건 이름을 적용하지 않고 SQL Server의 열 수준에서 DEFAULT 제약 조건을 정의해야 합니다. SQL Server는 각 DEFAULT 제약 조건에 대해 고유한 이름을 만듭니다.

CHECK 제약 조건을 정의하는 데 사용되는 구문은 Oracle과 SQL Server 모두 같습니다. 검색 조건은 부울 식에 따라 평가되어야 하며 하위 쿼리를 포함할 수 없습니다. 열 수준 CHECK 제약 조건은 제약된 열만 참조할 수 있으며 테이블 수준 CHECK 제약 조건은 제약된 테이블의 열만 참조할 수 있습니다. 한 테이블에 여러 개의 CHECK 제약 조건을 정의할 수 있습니다. SQL Server 구문에서는 CREATE TABLE 문의 열에 열 수준 CHECK 제약 조건을 하나만 만들 수 있으며 제약 조건이 여러 개의 조건을 가질 수 있습니다.

수정한 CREATE TABLE 문을 테스트하는 가장 좋은 방법은 SQL Server의 SQL Server 쿼리 분석기를 사용하여 구문만 분석하는 것입니다. 오류가 있으면 결과 창에 오류가 나타납니다. 제약 조건 구문에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

Oracle

Microsoft SQL Server

CREATE TABLE STUDENT_ADMIN.STUDENT ( SSN CHAR(9) NOT NULL, FNAME VARCHAR2(12) NULL, LNAME VARCHAR2(20) NOT NULL, GENDER CHAR(1) NOT NULL CONSTRAINT STUDENT_GENDER_CK CHECK (GENDER IN ('M','F')), MAJOR VARCHAR2(4) DEFAULT 'Undc' NOT NULL, BIRTH_DATE DATE NULL, TUITION_PAID NUMBER(12,2) NULL, TUITION_TOTAL NUMBER(12,2) NULL, START_DATE DATE NULL, GRAD_DATE DATE NULL, LOAN_AMOUNT NUMBER(12,2) NULL, DEGREE_PROGRAM CHAR(1) DEFAULT 'U' NOT NULL CONSTRAINT STUDENT_DEGREE_CK CHECK (DEGREE_PROGRAM IN ('U', 'M', 'P', 'D')), ...

CREATE TABLE USER_DB.STUDENT _ADMIN.STUDENT ( SSN CHAR(9) NOT NULL, FNAME VARCHAR(12) NULL, LNAME VARCHAR(20) NOT NULL, GENDER CHAR(1) NOT NULL CONSTRAINT STUDENT_GENDER_CK CHECK (GENDER IN ('M','F')), MAJOR VARCHAR(4) DEFAULT 'Undc' NOT NULL, BIRTH_DATE DATETIME NULL, TUITION_PAID NUMERIC(12,2) NULL, TUITION_TOTAL NUMERIC(12,2) NULL, START_DATE DATETIME NULL, GRAD_DATE DATETIME NULL, LOAN_AMOUNT NUMERIC(12,2) NULL, DEGREE_PROGRAM CHAR(1) DEFAULT 'U' NOT NULL CONSTRAINT STUDENT_DEGREE_CK CHECK (DEGREE_PROGRAM IN ('U', 'M', 'P','D')), ...

사용자 정의 규칙 및 기본값에 대한 참고: Microsoft SQL Server 규칙 및 기본값에 대한 구문은 이전 버전과의 호환성을 목적으로 그대로 남아 있지만 새 응용 프로그램을 개발할 때는 CHECK 제약 조건과 DEFAULT 제약 조건을 사용할 것을 권장합니다. 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

Null 허용

Microsoft SQL Server와 Oracle은 Null 허용을 유지하기 위한 열 제약 조건을 만듭니다. CREATE TABLE 또는 ALTER TABLE 문에 NOT NULL을 지정하지 않은 한 Oracle 열은 기본적으로 Null이 됩니다. Microsoft SQL Server의 경우 데이터베이스 및 세션 설정이 열 정의에 사용된 데이터 형식의 Null 허용보다 우선할 수 있습니다.

모든 SQL 스크립트(Oracle과 SQL Server 모두)는 각 열에 대해 NULL과 NOT NULL을 명시적으로 정의해야 합니다. 이 전략이 어떻게 구현되는지 보려면 예제 테이블 작성 스크립트인 Oratable.sql 및 Sstable.sql을 참조하십시오. 명시적으로 지정하지 않으면 열의 Null 허용이 아래 규칙을 따릅니다.

Null 설정	설명
열이 사용자 정의 데이터 형식으로 정의된 경우	SQL Server는 데이터 형식이 만들어질 때 지정된 Null 허용을 사용합니다. 데이터 형식의 기본 Null 허용을 가져오려면 sp_help 시스템 저장 프로시저를 사용하십시오.
열이 시스템 제공 데이터 형식으로 정의된 경우	시스템 제공 데이터 형식에 옵션이 하나뿐이면 그 데이터 형식이 우선합니다. 현재 bit 데이터 형식은 NOT NULL로만 정의할 수 있습니다. 세션 설정이 SET을 통해 켜진 경우, 즉 ON인 경우 ANSI_NULL_DFLT_ON이 ON이면 NULL이 지정됩니다. ANSI_NULL_DFLT_OFF가 ON이면 NOT NULL이 지정됩니다. 데이터베이스 설정이 구성된 경우, 즉 sp_dboption 시스템 저장 프로시저를 사용하여 변경된 경우 ANSI null default가 true이면 NULL이 지정됩니다. ANSI null default가 false이면 NOT NULL이 지정됩니다.
NULL/NOT NULL이 정의되지 않은 경우	명시적으로 정의되지 않은 경우, 즉 어떤 ANSI_NULL_DFLT 옵션도 설정되지 않은 경우 세션이 변경되지 않은 것이므로 데이터베이스가 기본값(ANSI null default가 false)으로 설정된 다음 SQL Server가 NOT NULL을 지정합니다.

아래 표는 참조 무결성 제약 조건을 정의하는 데 사용되는 구문을 비교한 것입니다.

제약 조건	Oracle	Microsoft SQL Server
PRIMARY KEY	[CONSTRAINT 제약 조건_이름] PRIMARY KEY (열_이름 [, 열_이름2 [..., 열_이름16]]) [USING INDEX 저장소_매개 변수]	[CONSTRAINT 제약 조건_이름] PRIMARY KEY [CLUSTERED | NONCLUSTERED] (열_이름 [, 열_이름2 [..., 열_이름16]]) [ON 세그먼트_이름] [NOT FOR REPLICATION]
UNIQUE	[CONSTRAINT 제약 조건_이름] UNIQUE (열_이름 [, 열_이름2 [..., 열_이름16]]) [USING INDEX 저장소_매개 변수]	[CONSTRAINT 제약 조건_이름] UNIQUE [CLUSTERED | NONCLUSTERED](열_이름 [, 열_이름2 [..., 열_이름16]]) [ON 세그먼트_이름] [NOT FOR REPLICATION]
FOREIGN KEY	[CONSTRAINT 제약 조건_이름] [FOREIGN KEY (열_이름 [, 열_이름2 [..., 열_이름16]])] REFERENCES [소유자.]참조_테이블 [(참조_열 [, 참조_열2 [..., 참조_열16]])] [ON DELETE CASCADE]	[CONSTRAINT 제약 조건_이름] [FOREIGN KEY (열_이름 [, 열_이름2 [..., 열_이름16]])] REFERENCES [소유자.]참조_테이블 [(참조_열 [, 참조_열2 [..., 참조_열16]])] [NOT FOR REPLICATION]
DEFAULT	제약 조건이 아니라 열 속성입니다. DEFAULT(상수_식)	[CONSTRAINT 제약 조건_이름] DEFAULT {상수_식 | niladic-함수 | NULL} [FOR 열_이름] [NOT FOR REPLICATION]
CHECK	[CONSTRAINT 제약 조건_이름] CHECK (식)	[CONSTRAINT 제약 조건_이름] CHECK [NOT FOR REPLICATION] (식)

NOT FOR REPLICATION 절을 사용하여 복제 중에 열 수준, FOREIGN KEY, CHECK 제약 조건을 일시 중단합니다.

외래 키

외래 키를 정의하는 규칙은 모든 RDBMS에서 비슷합니다. 외래 키 절에 지정하는 각 열의 수와 데이터 형식은 REFERENCES 절과 일치해야 합니다. 이 열에 입력된 Null 이외의 값이 REFERENCES 절에 정의된 테이블과 열에 존재해야 하며 참조된 테이블의 열에는 PRIMARY KEY 또는 UNIQUE 제약 조건이 있어야 합니다.

Microsoft SQL Server 제약 조건은 같은 데이터베이스의 테이블을 참조할 수 있도록 합니다. 데이터베이스 간에 참조 무결성을 구현하려면 테이블 기반 트리거를 사용해야 합니다.

Oracle과 SQL Server 모두 자체 참조되는 테이블, 즉 같은 테이블에 있는 하나 이상의 열에 대해 참조(외래 키)를 설정할 수 있는 테이블을 지원합니다. 예를 들어, 유효한 강의 코드가 필수 과목으로 입력되도록 하기 위해 CLASS 테이블의 prereq 열이 CLASS 테이블의 ccode 열을 참조할 수 있습니다.

Oracle에서는 CASCADE DELETE 절을 통해 관련 항목 모두를 삭제하거나 업데이트하지만, SQL Server에서는 테이블 트리거를 통해 같은 기능을 얻을 수 있습니다. 자세한 내용은 이 장의 뒷부분에 나오는 "SQL 언어 지원"을 참조하십시오.

사용자 정의 무결성을 사용하면 다른 무결성 범주에 포함되지 않는 특정 업무 규칙을 정의할 수 있습니다.

저장 프로시저

Microsoft SQL Server의 저장 프로시저는 CREATE PROCEDURE 문을 사용하여 사용자 제공 매개 변수를 받거나 반환합니다. 임시 저장 프로시저를 제외한 모든 저장 프로시저는 현재 데이터베이스에 만들어집니다. 아래 표는 Oracle 및 SQL Server의 구문을 나타낸 것입니다.

Oracle	Microsoft SQL Server
CREATE OR REPLACE PROCEDURE [사용자.]프로시저 [(인수 [IN | OUT] 데이터형식 [, 인수 [IN | OUT] 데이터형식] {IS | AS} block	CREATE PROC[EDURE] 프로시저_이름 [;번호] [ {@매개 변수 데이터_형식} [VARYING] [= 기본값] [OUTPUT] ] [,Un] [WITH { RECOMPILE | ENCRYPTION | RECOMPILE, ENCRYPTION} ] [FOR REPLICATION] AS sql_문 [Un]

SQL Server에서는, 임시 로컬 프로시저의 경우 프로시저_이름 앞에 단일 번호 기호(#프로시저_이름)를 포함하고 임시 글로벌 프로시저의 경우 이중 번호 기호(##프로시저_이름)를 포함하여 tempdb 데이터베이스에 임시 프로시저를 만듭니다.

임시 로컬 프로시저는 그 프로시저를 만든 사용자만 사용할 수 있습니다. 임시 로컬 프로시저를 실행할 수 있는 사용 권한을 다른 사용자들에게 부여할 수 없습니다. 임시 로컬 프로시저는 사용자 세션이 끝날 때 자동으로 제거됩니다.

임시 글로벌 프로시저는 모든 SQL Server 사용자가 사용할 수 있습니다. 임시 글로벌 프로시저가 만들어지면 모든 사용자가 그 프로시저에 액세스할 수 있으며 사용 권한을 명시적으로 해지할 수 없습니다. 임시 글로벌 프로시저는 프로시저를 사용하는 마지막 사용자 세션이 끝날 때 제거됩니다.

SQL Server의 저장 프로시저는 32개 수준까지 중첩할 수 있습니다. 중첩 수준은 호출된 프로시저가 실행되기 시작할 때 증가하고 호출된 프로시저의 실행이 끝날 때 감소합니다.

아래 예제는 Transact-SQL 저장 프로시저를 사용하여 Oracle PL/SQL 패키지 함수를 바꾸는 방법을 보여 줍니다. Transact-SQL 버전은 SQL Server가 커서를 사용하지 않고 저장 프로시저의 SELECT 문에서 직접 결과 집합을 반환할 수 있기 때문에 훨씬 더 간단합니다.

Oracle	Microsoft SQL Server
CREATE OR REPLACE PACKAGE STUDENT_ADMIN.P1 AS ROWCOUNT NUMBER :=0; CURSOR C1 RETURN STUDENT%ROWTYPE; FUNCTION SHOW_RELUCTANT_STUDENTS (WORKVAR OUT VARCHAR2) RETURN NUMBER; END P1; / CREATE OR REPLACE PACKAGE BODY STUDENT_ADMIN.P1 AS CURSOR C1 RETURN STUDENT%ROWTYPE IS SELECT * FROM STUDENT_ADMIN.STUDENT WHERE NOT EXISTS (SELECT 'X' FROM STUDENT_ADMIN.GRADE WHERE GRADE.SSN=STUDENT.SSN) ORDER BY SSN; FUNCTION SHOW_RELUCTANT_STUDENTS (WORKVAR OUT VARCHAR2) RETURN NUMBER IS WORKREC STUDENT%ROWTYPE; BEGIN IF NOT C1%ISOPEN THEN OPEN C1; ROWCOUNT :=0; ENDIF; FETCH C1 INTO WORKREC; IF (C1%NOTFOUND) THEN CLOSE C1; ROWCOUNT :=0; ELSE WORKVAR := WORKREC.FNAME||' '||WORKREC.LNAME|| ', social security number '||WORKREC.SSN||' is not enrolled in any classes!'; ROWCOUNT := ROWCOUNT + 1; ENDIF; RETURN(ROWCOUNT);	CREATE PROCEDURE STUDENT_ADMIN.SHOW_ RELUCTANT_STUDENTS AS SELECT FNAME+'' +LNAME+', social security number'+ SSN+' is not enrolled in any classes!' FROM STUDENT_ADMIN.STUDENT S WHERE NOT EXISTS (SELECT 'X' FROM STUDENT_ADMIN.GRADE G WHERE G.SSN=S.SSN) ORDER BY SSN RETURN@@ROWCOUNT GO
EXCEPTION WHEN OTHERS THEN IF C1%ISOPEN THEN CLOSE C1; ROWCOUNT :=0; ENDIF; RAISE_APPLICATION_ERROR(-20001,SQLERRM); END SHOW_RELUCTANT_STUDENTS; END P1; /

SQL Server는 Oracle 패키지나 함수와 비슷한 구성을 지원하지 않으며 저장 프로시저를 만들기 위한 CREATE OR REPLACE 옵션도 지원하지 않습니다.

저장 프로시저의 실행 지연

Microsoft SQL Server는 개발자가 문 블록, 저장 프로시저, 트랜잭션의 실행을 시작하는 이벤트, 시간 또는 시간 간격을 지정할 수 있도록 하는 WAITFOR 문을 제공합니다. Transact-SQL의 이 문은 Oracle의 dbms_lock.sleep와 같은 기능을 합니다.

WAITFOR {DELAY '시간' | TIME '시간'}

여기서 각 항목의 의미는 아래와 같습니다.

• DELAY

  Microsoft SQL Server를 지정한 시간(최대 24시간)이 경과할 때까지 대기하도록 합니다.

• '시간'

  대기할 시간입니다. 시간은 datetime 데이터에 사용 가능한 형식 중 하나로 지정하거나 지역 변수로 지정할 수 있습니다. 날짜는 지정할 수 없으므로 datetime 값의 데이터 부분은 허용되지 않습니다.

• TIME

  지정한 시간까지 SQL Server가 대기하도록 합니다.

아래 예제를 참조하십시오.

BEGIN
WAITFOR TIME '22:20'
EXECUTE update_all_stats
END

저장 프로시저에 매개 변수 지정

저장 프로시저에 매개 변수를 지정하려면 아래 구문을 사용합니다.

Oracle	Microsoft SQL Server
변수이름 데이터형식 DEFAULT <value>;	{@매개 변수 데이터_형식} [VARYING] [= 기본값] [OUTPUT]

트리거

Oracle과 Microsoft SQL Server 모두 트리거가 있지만 구현은 약간 다릅니다.

설명	Oracle	Microsoft SQL Server
테이블 당 트리거 수	제한 없음	제한 없음
INSERT, UPDATE, DELETE 전에 트리거 실행	실행됨	실행되지 않음
INSERT, UPDATE, DELETE 뒤에 트리거 실행	실행됨	실행되지 않음
문 수준 트리거	있음	있음
행 수준 트리거	있음	없음
실행 전에 제약 조건 확인	트리거를 사용 해제하지 않은 한 확인함	확인함. 데이터 변환 서비스의 옵션이기도 합니다.
UPDATE 또는 DELETE 트리거의 이전 값 참조	:old	DELETED.열
INSERT 트리거의 새 값 참조	:new	INSERTED.열
트리거 사용 해제	ALTER TRIGGER	데이터 변환 서비스의 옵션

DELETED 및 INSERTED는 트리거 문에 대해 SQL Server가 만드는 논리적(개념 상의) 테이블입니다. 구조 면에서는 트리거가 정의되는 테이블과 비슷하며 사용자 작업으로 변경될 수 있는 행의 이전 값 또는 새 값을 저장합니다. 테이블은 Transact-SQL의 행 수준 변경 사항을 추적합니다. 이러한 테이블은 Oracle의 행 수준 트리거와 같은 기능을 제공합니다. SQL Server에서 INSERT, UPDATE 또는 DELETE 문이 실행될 때 트리거 테이블과 INSERTED 및 DELETED 테이블에 행이 동시에 추가됩니다.

INSERTED 및 DELETED 테이블은 트리거 테이블과 같습니다. 이들은 열 이름과 데이터 형식이 같습니다. 예를 들어, GRADE 테이블에 트리거를 만들면 INSERTED 및 DELETED 테이블에도 이 구조가 만들어집니다.

GRADE	INSERTED	DELETED
SSN CHAR(9) CCODE VARCHAR(4) GRADE VARCHAR(2)	SSN CHAR(9) CCODE VARCHAR(4) GRADE VARCHAR(2)	SSN CHAR(9) CCODE VARCHAR(4) GRADE VARCHAR(2)

트리거로 INSERTED 및 DELETED 테이블을 검토하면 수행해야 할 트리거 동작을 결정할 수 있습니다. INSERTED 테이블은 INSERT 및 UPDATE 문에 사용됩니다. DELETED 테이블은 DELETE 및 UPDATE 문에 사용됩니다.

SQL Server는 UPDATE 작업이 수행될 때마다 항상 이전 행을 삭제하고 새 행을 삽입하기 때문에, UPDATE 문은 INSERTED와 DELETED 테이블 모두를 사용합니다. 따라서 UPDATE가 수행될 때 INSERTED 테이블의 행은 항상 DELETED 테이블의 행과 중복됩니다.

아래 예제에서는 INSERTED와 DELETED 테이블을 사용하여 PL/SQL 행 수준 트리거를 바꿉니다. 완전 외부 조인을 사용하면 전체 테이블의 모든 행을 쿼리할 수 있습니다.

Oracle	Microsoft SQL Server
CREATE TRIGGER STUDENT_ADMIN.TRACK_GRADES AFTER INSERT OR UPDATE OR DELETE ON STUDENT_ADMIN.GRADE FOR EACH ROW BEGIN INSERT INTO GRADE_HISTORY( TABLE_USER, ACTION_DATE, OLD_SSN, OLD_CCODE, OLD_GRADE, NEW_SSN, NEW_CCODE, NEW_GRADE) VALUES (USER, SYSDATE, :OLD.SSN, :OLD.CCODE, :OLD.GRADE, :NEW.SSN, :NEW.CCODE, :NEW.GRADE), END;	CREATE TRIGGER STUDENT_ADMIN.TRACK_GRADES ON STUDENT_ADMIN.GRADE FOR INSERT, UPDATE, DELETE AS INSERT INTO GRADE_HISTORY( TABLE_USER, ACTION_DATE, OLD_SSN, OLD_CCODE, OLD_GRADE NEW_SSN, NEW_CCODE, NEW_GRADE) SELECT USER, GETDATE(), OLD.SSN, OLD.CCODE, OLD.GRADE, NEW.SSN, NEW.CCODE, NEW.GRADE FROM INSERTED NEW FULL OUTER JOIN DELETED OLD ON NEW.SSN = OLD.SSN

현재 데이터베이스 외부의 개체를 참조할 수는 있지만 현재 데이터베이스에만 트리거를 만들 수 있습니다. 소유자 이름을 사용하여 트리거 자격을 확인하는 경우 테이블 이름도 같은 방법으로 확인해야 합니다.

트리거를 32개 수준까지 중첩할 수 있습니다. 어떤 트리거가 또 다른 트리거가 있는 테이블을 변경하면 둘째 트리거가 활성화되어 셋째 트리거를 호출할 수 있으며 이런 식으로 계속 진행될 수 있습니다. 체인의 어떤 트리거가 무한 루프를 만들면 중첩 수준이 초과되어 트리거가 취소됩니다. 또한 테이블의 특정 열에 대한 업데이트 트리거가 또 다른 열을 업데이트하더라도 업데이트 트리거는 한 번만 활성화됩니다.

Microsoft SQL Server의 선언적 참조 무결성(DRI)은 데이터베이스 간 참조 무결성을 제공하지 않습니다. 데이터베이스 간 참조 무결성이 필요하면 트리거를 사용해야 합니다.

아래 문은 Transact-SQL 트리거에는 허용되지 않습니다.

• CREATE 문(DATABASE, TABLE, INDEX, PROCEDURE, DEFAULT, RULE, TRIGGER, SCHEMA, VIEW)
• DROP 문(TRIGGER, INDEX, TABLE, PROCEDURE, DATABASE, VIEW, DEFAULT, RULE)
• ALTER 문(DATABASE, TABLE, VIEW, PROCEDURE, TRIGGER)
• TRUNCATE TABLE
• GRANT, REVOKE, DENY
• UPDATE STATISTICS
• RECONFIGURE
• UPDATE STATISTICS
• RESTORE DATABASE, RESTORE LOG
• LOAD LOG, DATABASE
• DISK 문
• SELECT INTO(테이블을 만들기 때문에)

트리거에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

트랜잭션, 잠금 및 동시성

이 절에서는 Oracle과 Microsoft SQL Server에서 트랜잭션이 어떻게 실행되는지에 대해 설명하고 잠금 프로세스 및 동시성 문제에서 두 데이터베이스 유형이 어떤 차이를 보이는지 살펴봅니다.

Oracle에서는 삽입, 업데이트 또는 삭제 작업이 수행될 때 트랜잭션이 자동으로 시작됩니다. 응용 프로그램은 COMMIT 명령을 사용하여 데이터베이스에 모든 변경 사항을 저장해야 합니다. COMMIT이 수행되지 않으면 모든 변경 사항이 자동으로 롤백되거나 취소됩니다.

기본적으로, Microsoft SQL Server는 모든 삽입, 업데이트 또는 삭제 작업 후에 COMMIT 문을 자동으로 수행합니다. 데이터가 자동으로 저장되기 때문에 사용자는 어떤 변경 사항도 롤백할 수 없습니다. 암시적 또는 명시적 트랜잭션 모드를 사용하면 이 기본 동작을 변경할 수 있습니다.

암시적 트랜잭션 모드는 SQL Server가 Oracle처럼 동작할 수 있도록 하며 SET IMPLICIT_TRANSACTIONS ON 문을 통해 활성화됩니다. 이 옵션이 ON으로 설정되어 있고 해결되지 않은 트랜잭션이 하나도 없으면 모든 SQL 문이 자동으로 트랜잭션을 시작합니다. 열린 트랜잭션이 있으면 새 트랜잭션이 시작되지 않습니다. 변경 사항이 적용되고 모든 잠금이 해제되도록 사용자가 COMMIT TRANSACTION 문을 사용하여 명시적으로 열린 트랜잭션을 커밋해야 합니다.

명시적 트랜잭션은 아래와 같은 트랜잭션 구분 기호 사이에 입력하는 SQL 문 집합입니다.

• BEGIN TRANSACTION [트랜잭션_이름]
• COMMIT TRANSACTION [트랜잭션_이름]
• ROLLBACK TRANSACTION [트랜잭션_이름 | 저장점_이름]

아래 예제에서는 English에서 Literature로 학과를 변경합니다. BEGIN TRANSACTION 및 COMMIT TRANSACTION 문을 눈여겨 보십시오.

Oracle	Microsoft SQL Server
INSERT INTO DEPT_ADMIN.DEPT (DEPT, DNAME) VALUES ('LIT', 'Literature') / UPDATE DEPT_ADMIN.CLASS SET MAJOR = 'LIT' WHERE MAJOR = 'ENG' / UPDATE STUDENT_ADMIN.STUDENT SET MAJOR = 'LIT' WHERE MAJOR = 'ENG' / DELETE FROM DEPT_ADMIN.DEPT WHERE DEPT = 'ENG' / COMMIT /	BEGIN TRANSACTION INSERT INTO DEPT_ADMIN.DEPT (DEPT, DNAME) VALUES ('LIT', 'Literature') UPDATE DEPT_ADMIN.CLASS SET DEPT = 'LIT' WHERE DEPT = 'ENG' UPDATE STUDENT_ADMIN.STUDENT SET MAJOR = 'LIT' WHERE MAJOR = 'ENG' DELETE FROM DEPT_ADMIN.DEPT WHERE DEPT = 'ENG' COMMIT TRANSACTION GO

모든 명시적 트랜잭션은 BEGIN TRANSACTION...COMMIT TRANSACTION 문 안에 정의해야 합니다. SAVE TRANSACTION 문은 Oracle의 SAVEPOINT 명령과 똑같은 방식으로 동작하며 트랜잭션에 부분 롤백을 허용하는 저장점을 설정합니다.

트랜잭션 안에 다른 트랜잭션을 중첩할 수 있습니다. 이런 경우 가장 바깥쪽에 있는 쌍이 트랜잭션을 만들고 커밋하며 안쪽에 있는 쌍이 중첩 수준을 추적합니다. 중첩된 트랜잭션이 있으면 @@TRANCOUNT 함수의 값이 조금씩 증가합니다. 일반적으로, BEGINUCOMMIT 쌍을 가진 저장 프로시저나 트리거가 서로를 호출할 때 이 명시적 트랜잭션 중첩이 발생합니다. 트랜잭션은 중첩될 수 있지만 ROLLBACK TRANSACTION 문의 동작에는 거의 아무 영향도 미치지 않습니다.

저장 프로시저나 트리거에서 BEGIN TRANSACTION 문과 COMMIT TRANSACTION 문은 개수가 같아야 합니다. 쌍이 맞지 않는 BEGIN TRANSACTION 및 COMMIT TRANSACTION 문이 포함된 저장 프로시저나 트리거를 실행하면 오류 메시지가 나타납니다. 구문은 저장 프로시저나 트리거에 BEGIN TRANSACTION 및 COMMIT TRANSACTION 문이 포함된 경우 트랜잭션 안에서 이들을 호출할 수 있도록 합니다.

대형 트랜잭션의 경우 가능하면 작은 트랜잭션으로 나누십시오. 각 트랜잭션을 단일 일괄 처리 안에서 명백하게 정의하십시오. 동시성 충돌 문제를 최소화하려면 트랜잭션이 여러 배치에 걸쳐 정의되거나 사용자 입력을 기다리지 않도록 해야 합니다. 많은 Transact-SQL 문을 하나의 긴 트랜잭션 그룹으로 만들면 복구 시간이 늘어날 수 있고 동시성 문제가 발생할 수 있습니다.

ODBC로 프로그래밍할 때 SQLSetConnectOption 함수를 사용하여 암시적 트랜잭션 모드나 명시적 트랜잭션 모드를 선택할 수 있습니다. ODBC 프로그램이 어느 쪽을 선택하느냐는 AUTOCOMMIT 연결 옵션에 따라 달라집니다. AUTOCOMMIT이 ON(기본값)인 경우 명시적 모드입니다. AUTOCOMMIT이 OFF이면 암시적 모드입니다.

SQL Server 쿼리 분석기나 다른 쿼리 도구를 통해 스크립트를 만드는 경우 앞에서 설명한 명시적 BEGIN TRANSACTION 문을 포함하거나 SET IMPLICIT_TRANSACTIONS ON 문이 포함된 스크립트를 시작할 수 있습니다. BEGIN TRANSACTION 방식은 유연하고 암시적 방식은 Oracle과의 호환성이 높습니다.

Oracle과 Microsoft SQL Server는 잠금 및 격리 전략이 많이 다릅니다. Oracle에서 SQL Server로 응용 프로그램을 변환할 때 응용 프로그램 확장성을 보장하려면 이러한 차이를 고려해야 합니다.

Oracle은 명시적 또는 암시적으로 데이터를 읽는 모든 SQL 문에 대해 다중 버전 일관성 모델을 사용합니다. 기본적으로, 이 모델에서는 데이터 리더가 잠금을 얻거나 다른 잠금이 해제될 때까지 기다리지 않고 데이터 행을 읽을 수 있습니다. 리더가 변경은 되었지만 다른 작성자들이 아직 커밋하지 않은 데이터를 요청하면 Oracle은 롤백 세그먼트를 사용하여 데이터 행의 스냅샷을 다시 작성함으로써 이전 데이터를 다시 만듭니다.

Oracle에서는 데이터 작성자들이 업데이트, 삭제 또는 삽입된 데이터에 대한 잠금을 요청합니다. 이러한 잠금은 트랜잭션이 끝날 때까지 유지되기 때문에 다른 사용자들은 커밋되지 않은 변경 사항을 덮어쓸 수 없습니다.

Microsoft SQL Server는 트랜잭션이 서로 다른 종류의 리소스를 잠글 수 있도록 여러 가지 잠금 단위를 지원합니다. 잠금 비용을 최소화하기 위해 SQL Server는 작업에 적절한 수준에서 리소스를 자동으로 잠급니다. 행 같은 작은 단위로 잠그는 경우 많은 행을 잠그면 유지해야 할 잠금이 많기 때문에 동시성은 높아지지만 오버헤드도 커집니다. 테이블 같은 큰 단위로 잠그는 경우, 전체 테이블을 잠금으로 인해 다른 트랜잭션들이 테이블의 어떤 부분에도 액세스할 수 없기 때문에 동시성은 떨어지지만 유지해야 하는 잠금이 적기 때문에 오버헤드는 줄어듭니다. SQL Server는 아래 표에 정리된(작은 단위부터 나열됨) 리소스를 잠글 수 있습니다.

리소스	설명
RID	행 ID이며 단일 행 테이블을 개별적으로 잠그는 데 사용합니다.
키	인덱스에서 행을 잠그는 것입니다. 순차 가능한 트랜잭션의 키 범위를 보호하는 데 사용합니다.
페이지	8KB 데이터 페이지 또는 인덱스 페이지입니다.
확장 영역	인접한 8개의 데이터 페이지 또는 인덱스 페이지 그룹입니다.
테이블	모든 데이터와 인덱스를 포함한 전체 테이블입니다.
DB	데이터베이스입니다.

SQL Server는 여러 가지 잠금 모드를 사용하여 리소스를 잠급니다. 이러한 잠금 모드가 동시 트랜잭션이 리소스에 어떻게 액세스할 수 있는지를 결정합니다.

잠금 모드	설명
공유 잠금(S)	SELECT 문처럼 데이터를 변경하거나 업데이트하지 않는 작업(읽기 전용 작업)에 사용됩니다.
업데이트 잠금(U)	업데이트될 수 있는 리소스에 사용됩니다. 여러 세션이 읽힐 때 발생하는 일반적인 형태의 교착 상태가 리소스를 잠그고 나중에 업데이트하는 일이 없도록 만듭니다.
단독 잠금(X)	UPDATE, INSERT 또는 DELETE 같은 데이터 수정 작업에 사용됩니다. 같은 시간 같은 리소스에 여러 업데이트가 수행될 수 없도록 합니다.
내재된 잠금	잠금 계층 구조를 만드는 데 사용됩니다.
스키마 잠금	테이블의 스키마에 의존하는 작업이 실행되고 있을 때 사용됩니다. 스키마 잠금에는 스키마 안전성(Sch-S)과 스키마 수정(Sch-M)의 두 종류가 있습니다.

모든 RDBMS에서, 잠금이 빨리 해제되어 최대 동시성을 제공할 수 있어야 합니다. 트랜잭션을 최대한 짧게 만들면 잠금이 빨리 해제되게 할 수 있습니다. 가능하면, 한 트랜잭션이 서버로 여러 번 왕복하지 않도록 해야 하며 사용자 "입력"이 필요하지 않도록 해야 합니다. 또한 커서를 사용하는 경우 데이터가 신속하게 반입되도록 응용 프로그램을 코딩해야 합니다. 반입되지 않은 데이터 스캔이 서버에 공유 잠금을 유지할 수 있고 따라서 업데이터를 차단할 수 있기 때문입니다. 자세한 내용은 이 장의 뒷부분에 나오는 "ODBC 사용"을 참조하십시오.

Microsoft SQL Server나 Oracle에서 개발자는 비기본 잠금 및 격리 동작을 요청할 수 있습니다. 이를 위해 Oracle에서 제공하는 가장 일반적인 메커니즘은 SELECT 명령의 FOR UPDATE 절, SET TRANSACTION READ ONLY 명령, 명시적 LOCK TABLE 명령입니다.

Oracle과 SQL Server의 잠금 및 격리 전략은 아주 다르기 때문에 이러한 잠금 옵션을 Oracle과 SQL Server 간에 직접 매핑하기는 어렵습니다. 이 프로세스를 제대로 이해하려면 기본 잠금 동작을 변경할 수 있도록 SQL Server가 제공하는 옵션을 이해해야 합니다.

기본 잠금 동작을 변경할 수 있도록 SQL Server에서 제공하는 가장 일반적인 메커니즘은 SET TRANSACTION ISOLATION LEVEL 문 그리고 SELECT 및 UPDATE 문에 지원되는 잠금 참고입니다. SET TRANSACTION ISOLATION LEVEL 문은 사용자 세션에 대한 트랜잭션 격리 수준을 설정합니다. SQL 문의 FROM 절에서 테이블 수준의 잠금 참고를 지정하지 않는 한 이것이 세션에 대한 기본 동작이 됩니다. 트랜잭션 격리는 아래와 같이 설정합니다.

SET TRANSACTION ISOLATION LEVEL
{
READ COMMITTED
| READ UNCOMMITTED
| REPEATABLE READ
| SERIALIZABLE
}

• READ COMMITTED

  SQL Server에 대한 기본 격리 수준입니다. 이 옵션을 사용하면 응용 프로그램이 다른 트랜잭션에서 아직 커밋하지 않은 데이터를 읽지 못합니다. 그러나 이 모드에서는 페이지에서 데이터가 읽히면 바로 공유 잠금이 해제됩니다. 응용 프로그램이 같은 트랜잭션 내의 같은 데이터 범위를 다시 읽으면 다른 사용자들의 변경 사항이 표시됩니다.

• SERIALIZABLE

  이 옵션을 설정하면 트랜잭션들이 서로 격리됩니다. 쿼리 시 다른 사용자들의 변경 사항이 표시되지 않도록 하려면 트랜잭션 격리 수준을 SERIALIZABLE로 설정하십시오. SQL Server는 트랜잭션이 끝날 때까지 모든 공유 잠금을 유지합니다. SELECT 문의 테이블 이름 뒤에 HOLDLOCK 참고를 사용하여 같은 효과를 좀더 세밀한 수준으로 얻을 수 있습니다. 이들 옵션을 사용하면 동시성과 정확한 일관성 중 하나만 얻을 수 있으므로 필요할 때만 이들 옵션을 사용해야 합니다.

• READ UNCOMMITTED

  이 옵션을 설정하면 SQL Server 리더가 Oracle에서처럼 전혀 방해 없이 작업을 수행할 수 있습니다. 이 옵션은 커밋되지 않은 데이터 읽기 또는 격리 수준 0인 잠금을 구현합니다. 이는 어떤 공유 잠금도 내려지지 않고 어떤 단독 잠금도 인정되지 않는다는 뜻입니다. 이 옵션을 설정하면 커밋되지 않은 데이터를 읽는 것이 가능합니다. 또한 트랜잭션이 끝나기 전에 데이터의 값이 변경될 수 있고 행이 데이터 집합에 나타나거나 사라질 수 있습니다. 이 옵션을 설정하는 것은 트랜잭션에 있는 모든 SELECT 문의 모든 테이블에 NOLOCK을 설정하는 것과 같습니다. 이 옵션은 네 개의 격리 수준 가운데 가장 제한이 적습니다. 응용 프로그램에서 결과의 정확도에 어떤 영향을 미치는지 완전히 분석한 다음 이 격리 수준을 사용하십시오.

SQL Server는 아래와 같은 두 가지 측면에서 Oracle의 READ ONLY 기능을 지원합니다.

• 응용 프로그램의 어떤 트랜잭션이 반복 읽기 동작을 요청하는 경우 SQL Server가 제공하는 SERIALIZABLE 격리 수준을 사용해야 할 것입니다.
• 모든 데이터베이스 액세스가 읽기 전용인 경우 SQL Server 데이터베이스 옵션을 READ ONLY로 설정하여 성능을 향상시킬 수 있습니다.

Oracle의 SELECTUFOR UPDATE 문은 주로 응용 프로그램이 WHERE CURRENT OF 구문을 사용하여 커서에 위치 지정 업데이트 또는 삭제를 사용할 때 사용됩니다. 이런 경우 Microsoft SQL Server에서는 FOR UPDATE 절을 선택적으로 제거하십시오. Microsoft SQL Server 커서는 기본적으로 업데이트 가능합니다.

기본적으로, SQL Server 커서는 반입된 행에 잠금을 유지하지 않습니다. SQL Server는 최적 동시성 전략을 사용하여 업데이트들이 서로 덮어쓰지 않도록 합니다. 커서로 읽어들인 후 변경한 행을 사용자가 업데이트하거나 삭제하려 하면 SQL Server가 오류 메시지를 내보냅니다. 응용 프로그램은 이 오류 메시지를 잡아 필요에 따라 업데이트나 삭제를 다시 시도합니다. 개발자들은 커서 선언에 SCROLL_LOCKS를 사용하여 이 동작을 무시할 수 있습니다.

최적 동시성 전략은 업데이터 간의 충돌이 거의 발생하지 않는 일반적인 경우에 높은 동시성을 지원합니다. 반입된 행은 변경할 수 없다는 것을 응용 프로그램이 반드시 확인해야 하는 경우 SELECT 문에 PDLOCK 참고를 사용하십시오. 이 참고가 다른 리더들을 막지는 않습니다. 그러나 다른 잠재적 작성자들이 데이터에 대한 업데이트 잠금을 얻지 못하도록 합니다. ODBC를 사용할 때는 SQLSETSTMTOPTION (U,SQL_CONCURRENCY)= SQL_CONCUR_LOCK을 사용하여 이 효과를 얻을 수 있습니다. 그러나 이러한 옵션은 동시성을 떨어뜨립니다.

Microsoft SQL Server는 SELECTU테이블_이름 (TABLOCK) 문을 사용하여 전체 테이블을 잠글 수 있습니다. 이 문은 Oracle의 LOCK TABLEUIN SHARE MODE 문과 같은 작업을 수행합니다. 이 잠금을 설정하면 다른 사람들이 테이블을 읽을 수는 있지만 업데이트하지는 못합니다. 기본적으로, 이 잠금은 문이 끝날 때까지 유지됩니다. HOLDLOCK 키워드(SELECTU테이블_이름 (TABLOCK HOLDLOCK))도 추가하는 경우 트랜잭션이 끝날 때까지 테이블 잠금이 유지됩니다.

SELECTU테이블_이름 (TABLOCKX) 문을 사용하면 SQL Server 테이블에 단독 잠금을 설정할 수 있습니다. 이 문은 테이블에 대한 단독 잠금을 요청합니다. 이 문은 다른 사람들이 테이블을 읽거나 업데이트하지 못하도록 할 때 사용하며 명령이나 트랜잭션이 끝날 때까지 유지됩니다. 이 문은 Oracle의 LOCK TABLEUIN EXCLUSIVE MODE 문과 기능이 비슷합니다.

SQL Server는 명시적 잠금 요청에 대해 NOWAIT 옵션을 제공하지 않습니다.

쿼리가 테이블의 행을 요청하면 Microsoft SQL Server는 페이지 수준 잠금을 자동으로 만듭니다. 그러나 쿼리가 요청하는 테이블 행이 아주 많으면 SQL Server는 잠금 수준을 페이지 수준에서 테이블 수준으로 높입니다. 이 프로세스를 잠금 수준 조정이라고 합니다.

잠금 수준 조정이 이뤄지면 잠금 오버헤드가 낮아지기 때문에 대량 결과 집합에 대한 테이블 스캔 및 테이블 작업이 더 효율적으로 진행됩니다. WHERE 절이 없는 SQL 문은 보통 잠금 수준 조정이 이뤄지게 만듭니다.

테이블 공유 잠금(TABLOCK)은 읽기 작업 동안 페이지 공유 잠금이 테이블 잠금으로 조정될 때 적용됩니다. 테이블 공유 잠금은 아래와 같은 때 적용됩니다.

• HOLDLOCK 또는 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 문이 사용될 때
• 최적화 프로그램이 테이블 스캔을 선택할 때
• 한 테이블에 누적된 공유 잠금 수가 잠금 수준 조정 임계값을 초과할 때

잠금 수준 조정 임계값은 기본적으로 테이블 당 200페이지이지만 최소 및 최대 바운드를 가진 테이블 크기의 백분율에 따라 이 값을 사용자 정의할 수 있습니다. 테이블 공유 잠금은 클러스터되지 않은 인덱스를 만들 때도 사용됩니다. 잠금 수준 조정 임계값에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

테이블 단독 잠금(TABLOCKX)은 쓰기 작업 동안 UPDATE 잠금이 테이블 잠금으로 조정되었을 때 적용됩니다. 테이블 단독 잠금은 아래와 같은 때 적용됩니다.

• 업데이트 또는 삭제 작업에 사용할 수 있는 인덱스가 하나도 없을 때
• 단독 잠금이 설정된 테이블의 페이지 수가 잠금 수준 조정 임계값을 초과할 때
• 클러스터된 인덱스를 만들 때

Oracle은 행 수준 잠금을 조정할 수 없기 때문에 FOR UPDATE 절이 포함된 일부 쿼리에서 문제가 발생할 수 있습니다. 예를 들어, STUDENT 테이블에 100,000개의 데이터 행이 있고 Oracle 사용자가 아래 문을 사용하는 경우를 가정할 수 있습니다.

SELECT * FROM STUDENT FOR UPDATE

이 문은 Oracle RDBMS가 한 번에 한 행씩 STUDENT 테이블을 잠그도록 만듭니다. 여기에는 아주 많은 시간이 걸릴 수 있습니다. 결코 요청을 조정하여 전체 테이블을 잠그지 않습니다.

SQL Server에 사용되는 동일 쿼리는 아래와 같습니다.

SELECT * FROM STUDENT (UPDLOCK)

이 쿼리가 실행되면 페이지 수준 잠금이 훨씬 더 효율적이고 빠른 테이블 수준 잠금으로 조정됩니다.

교착 상태

어떤 프로세스가 다른 프로세스가 필요로 하는 페이지나 테이블을 잠그고 둘째 프로세스가 첫째 프로세스가 필요로 하는 페이지를 잠그면 교착 상태가 됩니다. SQL Server는 교착 상태를 자동으로 검색하고 해결합니다. 교착 상태가 발견되면 SQL Server는 교착 상태를 완료한 사용자 프로세스를 종료합니다.

모든 데이터 수정 후에는 프로그램 코드에서 교착 상태를 나타내는 메시지 번호 1205를 확인해야 합니다. 이 메시지 번호가 반환되면 교착 상태가 발생하여 트랜잭션이 롤백된 것입니다. 이 상황에서는 응용 프로그램이 트랜잭션을 다시 시작해야 합니다.

일반적으로 아래와 같은 간단한 몇 가지 방법을 사용하여 교착 상태를 피할 수 있습니다.

• 응용 프로그램의 모든 부분에서 같은 순서로 테이블에 액세스합니다.
• 모든 테이블에 클러스터된 인덱스를 사용하여 명시적 행 정렬이 이뤄지도록 합니다.
• 트랜잭션을 짧게 만듭니다.

자세한 내용은 Microsoft 기술 자료 문서 "Detecting and Avoiding Deadlocks in Microsoft SQL Server"를 참조하십시오.

Oracle에서 원격 트랜잭션을 수행하려면 데이터베이스 링크로 원격 데이터베이스 노드에 액세스할 수 있어야 합니다. SQL Server에서는 원격 서버에 액세스할 수 있어야 합니다. 원격 서버는 사용자가 로컬 서버를 사용하여 액세스할 수 있는 네트워크 상의 SQL Server 실행 서버입니다. 원격 서버로 설정된 서버에 대해 사용자는 그 서버에 명시적으로 로그인하지 않고도 시스템 프로시저와 저장 프로시저를 사용할 수 있습니다.

원격 서버는 쌍으로 설정됩니다. 서로를 원격 서버로 인식하도록 양쪽 서버를 구성해야 합니다. sp_addlinkedserver 시스템 저장 프로시저 또는 SQL Server 엔터프라이즈 관리자를 사용하여 각 서버의 이름을 파트너에게 추가해야 합니다.

원격 서버를 설정한 후 sp_addremotelogin 시스템 저장 프로시저나 SQL Server 엔터프라이즈 관리자를 사용하여, 그 원격 서버에 액세스해야 하는 사용자의 원격 로그인 ID를 설정하십시오. 이 단계가 완료되면 저장 프로시저를 실행하기 위한 사용 권한을 부여해야 합니다.

이제 EXECUTE 문이 원격 서버에서 프로시저를 실행하는 데 사용됩니다. 아래 예제의 경우 원격 서버 STUDSVR1에서 validate_student 저장 프로시저를 실행하고 @retvalue1에 성공 또는 실패를 나타내는 반환 상태를 저장합니다.

DECLARE @retvalue1 int
EXECUTE @retvalue = STUDSVR1.student_db.student_admin.validate_student '111111111'

자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

Oracle은 네트워크로 연결된 두 개 이상의 데이터베이스 노드에서 테이블의 내용이 변경되면 자동으로 분산 트랜잭션을 시작합니다. SQL Server 분산 트랜잭션은 SQL Server에 포함된 MS DTC(Microsoft Distributed Transaction Coordinator)의 2단계 커밋 서비스를 사용합니다.

기본적으로, SQL Server가 분산 트랜잭션에 참여하도록 지정해야 합니다. 다음 중 하나를 시작하여 SQL Server가 MS DTC 트랜잭션에 참여하도록 할 수 있습니다.

• BEGIN DISTRIBUTED TRANSACTION 문. 이 문은 새 MS DTC 트랜잭션을 시작합니다.
• DTC 트랜잭션 인터페이스를 직접 호출하는 클라이언트 응용 프로그램

아래 예제에서, 로컬 테이블 GRADE와 원격 테이블 CLASS 모두에 대한 분산 업데이트(class_name 프로시저 사용)를 눈여겨 보십시오.

BEGIN DISTRIBUTED TRANSACTION
UPDATE STUDENT_ADMIN.GRADE
SET GRADE = 'B+' WHERE SSN = '111111111' AND CCODE = '1234'
DECLARE @retvalue1 int
EXECUTE @retvalue1 = CLASS_SVR1.dept_db.dept_admin.class_name '1234', 'Basketweaving'
COMMIT TRANSACTION
GO

트랜잭션을 완료할 수 없는 경우 응용 프로그램이 ROLLBACK TRANSACTION 문을 사용하여 트랜잭션을 취소합니다. 응용 프로그램이 실패하거나 참여 리소스 관리자가 실패하면 MS DTC가 트랜잭션을 취소합니다. MS DTC는 분산 저장점 또는 SAVE TRANSACTION 문을 지원하지 않습니다. MS DTC 트랜잭션이 중단되거나 롤백되면 저장점과는 상관없이 전체 트랜잭션이 분산 트랜잭션의 맨 처음으로 롤백됩니다.

Oracle과 MS DTC의 2단계 커밋 메커니즘은 비슷하게 동작합니다. SQL Server 2단계 커밋의 첫째 단계에서는 포함된 각 리소스 관리자에게 트랜잭션 관리자가 커밋을 준비하도록 요청합니다. 준비할 수 있는 리소스 관리자가 하나도 없으면 트랜잭션 관리자는 트랜잭션에 관련된 모든 사람에게 중단 결정을 브로드캐스트합니다.

모든 리소스 관리자가 성공적으로 준비할 수 있으면 트랜잭션 관리자가 커밋 결정을 브로드캐스트합니다. 이것이 커밋 프로세스의 둘째 단계입니다. 리소스 관리자가 준비되었더라도 트랜잭션이 커밋되었는지 중단되었는지는 확실하지 않습니다. MS DTC는 커밋 또는 중단 결정이 지속될 수 있도록 순차 로그를 유지합니다. 실패한 리소스 관리자나 트랜잭션 관리자는 다시 연결될 때 확실하지 않은 트랜잭션을 조정합니다.

SQL 언어 지원

이 절에서는 Transact-SQL 언어 구문과 PL/SQL 언어 구문의 유사점과 차이점에 대해 개괄적으로 살펴보고 변환 전략에 대해 설명합니다.

Oracle DML 문과 PL/SQL 프로그램을 SQL Server로 마이그레이션할 때는 아래 절차를 따릅니다.

1. 모든 SELECT, INSERT, UPDATE, DELETE 문의 구문이 유효한지 확인합니다. 필요한 수정 작업을 합니다.
2. 모든 외부 조인을 SQL-92 표준 외부 조인 구문으로 변경합니다.
3. Oracle 함수를 적절한 SQL Server 함수로 바꿉니다.
4. 모든 비교 연산자를 검사합니다.
5. "||" 문자열 연결 연산자를 "+" 문자열 연결 연산자로 바꿉니다.
6. PL/SQL 프로그램을 Transact-SQL 프로그램으로 바꿉니다.
7. 모든 PL/SQL 커서를 비커서 SELECT 문이나 Transact-SQL 커서로 변경합니다.
8. PL/SQL 프로시저, 함수, 패키지를 Transact-SQL 프로시저로 바꿉니다.
9. PL/SQL 트리거를 Transact-SQL 트리커로 변환합니다.
10. SET SHOWPLAN 문을 사용하여 성능 쿼리를 조정합니다.

SELECT 문

Oracle과 Microsoft SQL Server에서 사용하는 SELECT 문 구문은 비슷합니다.

Oracle	Microsoft SQL Server
SELECT [/*+ optimizer_hints*/] [ALL | DISTINCT] 선택_목록 [FROM {테이블_이름 | 뷰_이름 | select_문}] [WHERE 절] [GROUP BY 식으로_그룹짓기] [HAVING 검색_조건] [START WITH U CONNECT BY] [{UNION | UNION ALL | INTERSECT | MINUS} SELECT U] [ORDER BY 절] [FOR UPDATE]	SELECT 선택_목록 [INTO 새_테이블_] FROM 테이블_원본 [WHERE 검색_조건] [ GROUP BY [ALL] 식으로_그룹짓기 [,Un] [ WITH { CUBE | ROLLUP } ] [HAVING 검색_조건] [ORDER BY 정렬_식 [ASC | DESC] ] 추가: UNION 연산자 COMPUTE 절 FOR BROWSE 절 OPTION 절

Oracle의 비용 기반 최적화 프로그램 참고는 SQL Server에서 지원하지 않으므로 제거해야 합니다. 대신, SQL Server의 비용 기반 최적화를 사용할 것을 권장합니다. 자세한 내용은 이 장의 뒷부분에 나오는 "SQL 문 튜닝"을 참조하십시오.

SQL Server는 Oracle의 START WITHUCONNECT BY 절을 지원하지 않습니다. SQL Server에서 같은 작업을 수행하는 저장 프로시저를 만들어 이 절을 대체할 수 있습니다.

Oracle의 INTERSECT 및 MINUS 집합 연산자는 SQL Server에서 지원하지 않습니다. SQL Server의 EXISTS 및 NOT EXISTS 절을 사용하여 같은 결과를 얻을 수 있습니다.

아래 예제에서는 INTERSECT 연산자를 사용하여 학생들이 듣는 모든 수업의 강의 코드와 강의 이름을 찾습니다. EXISTS 연산자가 어떻게 INTERSECT 연산자를 대체하는지 눈여겨 보십시오. 반환되는 데이터는 같습니다.

Oracle	Microsoft SQL Server
SELECT CCODE, CNAME FROM DEPT_ADMIN.CLASS INTERSECT SELECT C.CCODE, C.CNAME FROM STUDENT_ADMIN.GRADE G, DEPT_ADMIN.CLASS C WHERE C.CCODE = G.CCODE	SELECT CCODE, CNAME FROM DEPT_ADMIN.CLASS C WHERE EXISTS (SELECT 'X' FROM STUDENT_ADMIN.GRADE G WHERE C.CCODE = G.CCODE)

아래 예제에서는 MINUS 연산자를 사용하여 어떤 학생도 듣지 않는 수업을 찾습니다.

Oracle	Microsoft SQL Server
SELECT CCODE, CNAME FROM DEPT_ADMIN.CLASS MINUS SELECT C.CCODE, C.CNAME FROM STUDENT_ADMIN.GRADE G, DEPT_ADMIN.CLASS C WHERE C.CCODE = G.CCODE	SELECT CCODE, CNAME FROM DEPT_ADMIN.CLASSC WHERE NOT EXISTS (SELECT 'X' FROM STUDENT_ADMIN.GRADE G WHERE C.CCODE = G.CCODE)

INSERT 문

Oracle과 Microsoft SQL Server에서 사용하는 INSERT 문 구문은 비슷합니다.

Oracle	Microsoft SQL Server
INSERT INTO {테이블_이름 | 뷰_이름 | select_문} [(열_목록)] {값_목록 | select_문}	INSERT [INTO] { 테이블_이름 [ [AS] 테이블_별칭] WITH ( <테이블_참고_제한> [Un]) | 뷰_이름 [ [AS] 테이블_별칭] | 제한된_행집합_함수 } { [(열_목록)] { VALUES ( { DEFAULT | NULL | 식 }[,Un] ) | 파생_테이블 | 실행_문 } } | DEFAULT VALUES

Transact-SQL 언어는 테이블과 뷰에 대한 삽입은 지원하지만 SELECT 문에 INSERT 연산은 지원하지 않습니다. Oracle 응용 프로그램 코드가 SELECT 문에 대한 삽입을 수행하는 경우 이를 변경해야 합니다.

Oracle	Microsoft SQL Server
INSERT INTO (SELECT SSN, CCODE, GRADE FROM GRADE) VALUES ('111111111', '1111',NULL)	INSERT INTO GRADE (SSN, CCODE, GRADE) VALUES ('111111111', '1111',NULL)

Transact-SQL의 값_목록 매개 변수는 Oracle이 지원하지 않는 SQL-92 표준 키워드 DEFAULT를 제공합니다. 이 키워드는 삽입이 수행될 때 열의 기본값이 사용되도록 지정합니다. 지정된 열에 대한 기본값이 없는 경우 NULL이 삽입됩니다. 열이 NULL을 허용하지 않으면 오류 메시지가 반환됩니다. 열이 타임 스탬프 데이터 형식으로 정의되어 있으면 그 다음 순차 값이 삽입됩니다.

DEFAULT 키워드는 ID 열과 함께 사용할 수 없습니다. 그 다음 일련 번호를 만들려면 IDENTITY 속성을 가진 열이 열_목록 또는 값_절에 나타나서는 안 됩니다. 열의 기본값을 얻기 위해 DEFAULT 키워드를 사용할 필요는 없습니다. Oracle에서처럼, 열이 열_목록에 나타나지 않고 기본값을 가지고 있으면 그 열에 기본값이 배치됩니다. 이는 마이그레이션을 수행할 때 사용할 수 있는 호환성이 가장 높은 방식입니다.

프로시저를 실행하고 그 결과를 대상 테이블이나 뷰에 파이프하는 유용한 Transact-SQL 옵션(EXECute 프로시저_이름)이 있습니다. Oracle에서는 이 작업이 허용되지 않습니다.

UPDATE 문

Transact-SQL은 Oracle UPDATE 명령에 사용되는 대부분의 구문을 지원하기 때문에 최소한의 수정만 필요합니다.

Oracle	Microsoft SQL Server
UPDATE {테이블_이름 | 뷰_이름 | select_문} SET [열_이름 = {상수_값 | 식 | select_문 | 열_목록 | 변수_목록] {where_문}	UPDATE { 테이블_이름 [ [AS] 테이블_별칭] WITH ( <테이블_참고_제한> [Un]) 뷰_이름 [ [AS] 테이블_별칭] | 제한된_행집합_함수 } SET {열_이름 = {식 | DEFAULT | NULL} | @변수 = 식 | @변수 = 열 = 식 } [,Un] {{[FROM {<테이블_원본>} [,Un] ] [WHERE <검색_조건>] } | [WHERE CURRENT OF { { [GLOBAL] 커서_이름 } | 커서_변수_이름} ] } [OPTION (<쿼리_참고> [,Un] )]

Transact-SQL UPDATE 문은 SELECT 문에 대한 업데이트 작업을 지원하지 않습니다. Oracle 응용 프로그램 코드가 SELECT 문에 대한 업데이트를 수행하는 경우 SELECT 문을 뷰로 변환한 다음 SQL Server UPDATE 문에 그 뷰 이름을 사용할 수 있습니다. 앞에 나온 "INSERT 문" 예제를 참조하십시오.

Oracle UPDATE 명령은 PL/SQL 블록에서 프로그램 변수만 사용할 수 있습니다. Transact-SQL 언어에서는 변수를 사용하기 위해 블록을 사용할 필요가 없습니다.

Oracle	Microsoft SQL Server
DECLARE VAR1 NUMBER(10,2); BEGIN VAR1 := 2500; UPDATE STUDENT_ADMIN.STUDENT SET TUITION_TOTAL = VAR1; END;	DECLARE @VAR1 NUMERIC(10,2) SELECT @VAR1 = 2500 UPDATE STUDENT_ADMIN.STUDENT SET TUITION_TOTAL=@VAR1

DEFAULT 키워드는 SQL Server에서 열을 기본값으로 설정하는 데 사용할 수 있습니다. Oracle UPDATE 명령에서는 열을 기본값으로 설정할 수 없습니다.

Transact-SQL과 Oracle SQL은 UPDATE 문에 하위 쿼리를 사용할 수 있도록 지원합니다. 그러나 Transact-SQL FROM 절을 사용하면 조인을 기반으로 UPDATE를 만들 수 있습니다. 이 기능을 사용하면 UPDATE 구문을 좀더 읽기 쉽게 만들 수 있으며 어떤 경우에는 성능을 향상시킬 수 있습니다.

Oracle	Microsoft SQL Server
UPDATE STUDENT_ADMIN.STUDENT S SET TUITION_TOTAL = 1500 WHERE SSN IN (SELECT SSN FROM GRADE G WHERE G.SSN = S.SSN AND G.CCODE = '1234')	하위 쿼리: UPDATE STUDENT_ADMIN.STUDENT S SET TUITION_TOTAL = 1500 WHERE SSN IN (SELECT SSN FROM GRADE G WHERE G.SSN = S.SSN AND G.CCODE = '1234') FROM 절: UPDATE STUDENT_ADMIN.STUDENT S SET TUITION_TOTAL = 1500 FROM GRADE G WHERE S.SSN = G.SSN AND G.CCODE = '1234'

DELETE 문

대부분의 경우 DELETE 문은 수정할 필요가 없습니다. Oracle에서 SELECT 문에 대해 삭제를 수행하는 경우 SQL Server의 구문을 수정해야 합니다. Transact-SQL에서 이 기능을 지원하지 않기 때문입니다.

Transact-SQL은 WHERE 절에 하위 쿼리를 사용할 수 있도록 지원하고 FROM 절에 조인을 사용할 수 있도록 지원합니다. 후자는 더 효율적인 문을 만드는 데 도움이 됩니다. 앞에 나온 "UPDATE 문" 예제를 참조하십시오.

Oracle	Microsoft SQL Server
DELETE [FROM] {테이블_이름 | 뷰_이름 | select_문} [WHERE 절]	DELETE [FROM ] { 테이블_이름 [ [AS] 테이블_별칭] WITH ( <테이블_참고_제한> [Un]) | 뷰_이름 [ [AS] 테이블_별칭] | 제한된_행집합_함수 } [ FROM {<테이블_원본>} [,Un] ] [WHERE { <검색_조건> | { [ CURRENT OF { { [ GLOBAL ] 커서_이름 } 커서_변수_이름 } ] } ] [OPTION (<쿼리_힌트> [,Un])]

TRUNCATE TABLE 문

Oracle과 Microsoft SQL Server에 사용되는 TRUNCATE TABLE 구문은 비슷합니다. TRUNCATE TABLE 문은 테이블에서 모든 행을 제거하는 데 사용되며 롤백될 수 없습니다. 테이블 구조와 그 모든 인덱스는 그대로 유지됩니다. DELETE 트리거는 실행되지 않습니다. FOREIGN KEY 제약 조건이 참조하는 테이블은 잘라낼 수 없습니다.

Oracle	Microsoft SQL Server
TRUNCATE TABLE 테이블_이름 [{DROP | REUSE} STORAGE]	TRUNCATE TABLE 테이블_이름

SQL Server에서는 테이블 소유자만 이 문을 사용할 수 있습니다. Oracle에서는 테이블 소유자 또는 DELETE TABLE 시스템 권한을 가진 사람이 이 명령을 내릴 수 있습니다.

Oracle TRUNCATE TABLE 명령은 테이블의 행들이 차지하는 저장소 공간을 선택적으로 해제할 수 있습니다. SQL Server TRUNCATE TABLE 문은 테이블 데이터와 관련 인덱스가 차지하는 공간을 항상 회수합니다.

ID 및 시간 스탬프 열의 데이터 조작

Oracle 시퀀스는 특정 테이블이나 열과 직접 관련되지 않은 데이터베이스 개체입니다. 열에 시퀀스 값을 체계적으로 할당하여 열과 시퀀스의 관계를 응용 프로그램에 구현합니다. 따라서 Oracle은 시퀀스 작업을 수행할 때는 어떠한 규칙도 시행하지 않습니다. 그러나 Microsoft SQL Server의 ID 열에서는 값을 업데이트할 수 없고 DEFAULT 키워드를 사용할 수 없습니다.

기본적으로, ID 열에 데이터를 직접 삽입할 수 없습니다. ID 열은 테이블에 새로 삽입된 각 행의 고유한 일련 번호를 자동으로 만듭니다. 아래 SET 문을 사용하여 이 기본 동작을 무시할 수 있습니다.

SET IDENTITY_INSERT 테이블_이름 ON

IDENTITY_INSERT를 ON으로 설정하면 새 행의 ID 열에 어떤 값이든 삽입할 수 있습니다. 중복되는 번호가 발생하지 않도록 열에 대해 고유한 인덱스를 만들어야 합니다. 이 문의 용도는 실수로 삭제된 행의 값을 사용자가 다시 만들 수 있도록 하는 것입니다. @@IDENTITY 함수를 사용하여 바로 전의 ID 값을 얻을 수 있습니다.

TRUNCATE TABLE 문은 ID 열을 원래 SEED 값으로 다시 설정합니다. 열의 ID 값을 다시 설정하지 않으려면 TRUNCATE TABLE 문 대신 WHERE 절 없이 DELETE 문을 사용해야 합니다. 이 작업이 Oracle 마이그레이션에 어떤 영향을 미치는지 평가해야 합니다. ORACLE SEQUENCES는 TRUNCATE TABLE 명령 뒤에 다시 설정되지 않기 때문입니다.

시간 스탬프 열에서는 삽입 또는 삭제만 수행할 수 있습니다. 시간 스탬프 열을 업데이트하려 하면 아래 오류 메시지가 나타납니다.

메시지 272, 수준 16, 상태 1 TIMESTAMP 열을 업데이트할 수 없습니다.

요청된 행 잠그기

Oracle은 SELECT 명령에 지정된 행을 FOR UPDATE 절을 사용하여 잠급니다. Microsoft SQL Server에서는 이것이 기본 동작이기 때문에 FOR UPDATE에 대응하는 절을 사용할 필요가 없습니다.

행 집계와 COMPUTE 절

SQL Server COMPUTE 절은 행 집계 함수(SUM, AVG, MIN, MAX 및 COUNT)를 만드는 데 사용합니다. 행 집계 함수는 쿼리 결과에 추가 행으로 표시됩니다. COMPUTE 절을 사용하면 하나의 결과 집합에 자세한 요약 행을 표시할 수 있습니다. 하위 그룹에 대한 요약 값을 계산할 수 있고 동일 그룹에 대해 둘 이상의 집계 함수를 계산할 수 있습니다.

Oracle SELECT 명령 구문은 COMPUTE 절을 지원하지 않습니다. 그럼에도 불구하고 SQL Server COMPUTE 절은 Oracle SQL*Plus 쿼리 도구에 제공되는 COMPUTE 명령과 똑같은 역할을 합니다.

조인 절

Microsoft SQL Server 7.0에서는 하나의 조인 절에 임시 테이블과 영구 테이블을 포함하여 테이블을 최고 256개까지 조인할 수 있습니다. Oracle에는 조인 한도가 없습니다.

Oracle에서 외부 조인을 사용할 때는 외부 조인 연산자(+)가 일반적으로 조인의 하위(외래 키) 열에 배치됩니다. (+) 연산자는 고유 값이 더 적은 열을 식별하는 데 사용합니다. 외래 키가 NULL 값을 허용하지 않는 경우 항상 이렇게 되며 이 경우 (+) 연산자를 상위(PRIMARY KEY 또는 UNIQUE 제약 조건) 열에 넣을 수 있습니다. 등호(=)의 양쪽에 (+) 연산자를 넣을 수 없습니다.

SQL Server에서는 *= 및 =* 외부 조인 연산자를 사용할 수 있습니다. *는 고유 값이 더 많은 열을 식별하는 데 사용합니다. 하위(외래 키) 열이 NULL 값을 허용하지 않는 경우 등호의 상위(PRIMARY KEY 또는 UNIQUE 제약 조건) 열 쪽에 *가 배치됩니다. Oracle에서는 *가 본질적으로 반대로 배치됩니다. 등호(=)의 양쪽에 *를 배치할 수 없습니다.

*= 및 =* 연산자는 레거시 조인 연산자로 간주됩니다. SQL Server는 아래 표에 정리된 SQL-92 표준 조인 연산자도 지원합니다. 이 구문을 사용하는 것이 좋습니다. SQL-92 표준 구문은 * 연산자보다 더 강력하고 제약도 더 적습니다.

조인 연산	설명
CROSS JOIN	이 조인은 두 테이블의 교차 곱입니다. 이전 스타일의 조인에서 WHERE 절을 지정하지 않았을 때 반환되던 행과 같은 행을 반환합니다. 이 조인 형식을 Oracle에서는 카디전 조인이라고 합니다.
INNER	이 조인은 모든 내부 행이 반환되도록 지정합니다. 일치하지 않는 행은 무시합니다. 이 조인은 Oracle의 표준 테이블 조인과 같습니다.
LEFT[OUTER]	이 조인 형식은 일치하는 열이 없더라도 테이블 왼쪽의 모든 외부 행이 반환되도록 지정합니다. 이 조인은 Oracle의 (+) 외부 조인과 똑같이 동작합니다.
RIGHT[OUTER]	이 조인 형식은 일치하는 열이 없더라도 테이블 오른쪽의 모든 외부 행이 반환되도록 지정합니다. 이 조인은 Oracle의 (+) 외부 조인과 똑같이 동작합니다.
FULL[OUTER]	테이블의 행이 선택 기준과 일치하지 않더라도, 결과 집합에 행이 포함되도록 지정하고 다른 테이블에 해당하는 그 출력 열이 NULL로 설정되도록 지정합니다. 이 조인은 Oracle의 외부 조인 연산자를 "=" 기호의 양쪽에 배치(col1(+) = col2(+))하는 것과 같을 것입니다. 그러나 이는 허용되지 않습니다.

아래 코드 예제에서는 모든 학생이 듣는 수업 목록을 반환합니다. 모든 학생, 심지어 어떤 수업에도 등록하지 않은 학생도 나타날 수 있도록 성적 테이블과 학생 테이블 간에 외부 조인이 정의됩니다. 외부 조인은 수업 이름을 반환하기 위해 수업 테이블에도 추가합니다. 수업 테이블에 외부 조인을 추가하지 않으면, 어떤 수업에도 등록하지 않은 학생들의 강의 코드는 NULL(CCODE)이기 때문에 이들이 반환되지 않습니다.

Oracle	Microsoft SQL Server
SELECT S.SSN AS SSN, FNAME, LNAME FROM STUDENT_ADMIN.STUDENT S, DEPT_ADMIN.CLASS C, STUDENT_ADMIN.GRADE G WHERE S.SSN = G.SSN(+) AND G.CCODE = C.CCODE(+)	SELECT S.SSN AS SSN, FNAME, LNAME FROM STUDENT_ADMIN.GRADE G RIGHT OUTER JOIN STUDENT_ADMIN.STUDENT S ON G.SSN = S.SSN LEFT OUTER JOIN DEPT_ADMIN.CLASS C ON G.CCODE = C.CCODE

SELECT 문을 테이블 이름으로 사용

Microsoft SQL Server와 Oracle은 쿼리를 수행할 때 SELECT 문을 테이블 원본으로 사용할 수 있도록 지원합니다. SQL Server에서는 별칭을 사용해야 하지만 Oracle에서는 선택 사항입니다.

Oracle	Microsoft SQL Server
SELECT SSN, LNAME, FNAME, TUITION_PAID, SUM_PAID FROM STUDENT_ADMIN.STUDENT, (SELECT SUM(TUITION_PAID) SUM_PAID FROM STUDENT_ADMIN.STUDENT)	SELECT SSN, LNAME, FNAME, TUITION_PAID, SUM_PAID FROM STUDENT_ADMIN.STUDENT, (SELECT SUM(TUITION_PAID) SUM_PAID FROM STUDENT_ADMIN.STUDENT) SUM_STUDENT

BLOB 읽기 및 수정

Microsoft SQL Server는 text 열과 image 열을 통해 BLOB(대용량 이진 개체)을 구현합니다. Oracle은 LONG 열과 LONG RAW 열을 통해 BLOB을 구현합니다. Oracle에서는 SELECT 명령으로 LONG 및 LONG RAW 열의 값을 쿼리할 수 있습니다.

SQL Server에서는 표준 Transact-SQL 문이나 특수 READTEXT 문을 사용하여 text 및 image 열의 데이터를 읽을 수 있습니다. READTEXT 문을 사용하면 text 또는 image 열의 일부 구역을 읽을 수 있습니다. Oracle은 LONG 및 LONG RAW 열 작업을 위한 READTEXT에 상응하는 문을 제공하지 않습니다.

READTEXT 문은 TEXTPTR 함수를 사용하여 얻을 수 있는 텍스트_포인터를 사용합니다. TEXTPTR 함수는 지정된 행의 text 열이나 image 열 또는 행이 둘 이상 반환되는 경우 쿼리가 반환하는 마지막 행의 text 열이나 image 열에 대한 포인터를 반환합니다. TEXTPTR 함수는 16바이트 이진 문자열을 반환하기 때문에 텍스트 포인터를 유지하기 위한 지역 변수를 선언한 다음 READTEXT에 그 변수를 사용하는 것이 가장 좋습니다.

READTEXT 문은 반환할 바이트 수를 지정합니다. @@TEXTSIZE 함수의 값(반환할 문자 또는 바이트 수의 한도)이 READTEXT 문에 지정된 크기보다 작은 경우 전자가 후자를 대신합니다.

SET 문을 TEXTSIZE 매개 변수와 함께 사용하여 SELECT 문에서 반환될 텍스트 데이터의 크기(바이트 단위)를 지정할 수 있습니다. TEXTSIZE를 0으로 지정하면 크기가 기본값(4KB)으로 다시 설정됩니다. TEXTSIZE 매개 변수를 설정하면 @@TEXTSIZE 함수가 영향을 받습니다. SQL Server ODBC 드라이버는 SQL_MAX_LENGTH 문 옵션이 변경될 때 자동으로 TEXTSIZE 매개 변수를 설정합니다.

Oracle에서는 UPDATE 및 INSERT 명령을 사용하여 LONG 열과 LONG RAW 열의 값을 변경합니다. SQL Server에서는 표준 UPDATE 및 INSERT 문을 사용하거나 UPDATETEXT 및 WRITETEXT 문을 사용할 수 있습니다. UPDATETEXT 문과 WRITETEXT 문은 로그되지 않는 옵션을 지원하고 UPDATETEXT 문은 text 또는 image 열의 부분 업데이트를 지원합니다.

UPDATETEXT 문을 사용하여 기존 데이터를 대체 또는 삭제하거나 새 데이터를 삽입할 수 있습니다. 상수 값, 테이블 이름, 열 이름 또는 텍스트 포인터 같은 데이터를 새로 삽입할 수 있습니다.

WRITETEXT 문은 이 문의 영향을 받는 열에 있는 기존의 모든 데이터를 완전히 덮어씁니다. 텍스트 데이터를 바꾸려면 WRITETEXT를 사용하고 텍스트 데이터를 수정하려면 UPDATETEXT를 사용합니다. 전체 값이 아니라 텍스트 또는 이미지의 일부 값만 변경하기 때문에 UPDATETEXT 문이 더 융통성이 많습니다.

자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

이 절에 나오는 표들은 스칼라 값 및 집계 함수와 관련하여 Oracle과 SQL Server의 관계를 보여 줍니다. 이름은 똑같아 보여도 함수에 사용되는 인수의 개수와 형식은 서로 다르다는 데 유의해야 합니다. 또한 이 장에서는 기존의 Oracle 응용 프로그램을 쉽게 마이그레이션할 수 있도록 하는 데 중점을 두기 때문에 Microsoft SQL Server만 제공하는 함수들은 이 목록에 나오지 않습니다. Oracle은 도(DEGREES), PI(PI), 난수(RAND) 같은 함수를 지원하지 않습니다.

수식/수치 연산 함수

다음은 Oracle에서 지원하는 수식/수치 연산 함수와 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

함수 설명	Oracle	Microsoft SQL Server
절대 값	ABS	ABS
아크 코사인	ACOS	ACOS
아크 사인	ASIN	ASIN
n의 아크 탄젠트	ATAN	ATAN
n과 m의 아크 탄젠트	ATAN2	ATN2
최소 정수 >= 값	CEIL	CEILING
코사인	COS	COS
쌍곡선 코사인	COSH	COT
지수 값	EXP	EXP
최대 정수 <= 값	FLOOR	FLOOR
자연 로그	LN	LOG
밑이 n인 로그	LOG(N)	해당 없음
상용 로그	LOG(10)	LOG10
나머지 연산자	MOD	USE MODULO (%) OPERATOR
거듭제곱	POWER	POWER
난수	해당 없음	RAND
반올림	ROUND	ROUND
숫자 부호 표시	SIGN	SIGN
사인	SIN	SIN
쌍곡선 사인	SINH	해당 없음
제곱근	SQRT	SQRT
탄젠트	TAN	TAN
쌍곡선 탄젠트	TANH	해당 없음
잘라내기	TRUNC	해당 없음
목록의 최대값	GREATEST	해당 없음
목록의 최소값	LEAST	해당 없음
NULL일 때 숫자 변환	NVL	ISNULL

문자열 함수

다음은 Oracle에서 지원하는 문자열 함수 및 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

함수 설명	Oracle	Microsoft SQL Server
문자를 ASCII로 변환	ASCII	ASCII
문자열 연결	CONCAT	(식 + 식)
ASCII를 문자로 변환	CHR	CHAR
문자열의 문자 시작 위치 반환(왼쪽부터)	INSTR	CHARINDEX
소문자로 변환	LOWER	LOWER
대문자로 변환	UPPER	UPPER
문자열의 왼쪽 채우기	LPAD	해당 없음
선행 공백 제거	LTRIM	LTRIM
후행 공백 제거	RTRIM	RTRIM
문자열의 패턴 시작 위치	INSTR	PATINDEX
문자열을 여러 번 반복	RPAD	REPLICATE
문자열의 발음 기호	SOUNDEX	SOUNDEX
반복되는 공백 문자열	RPAD	SPACE
수치 데이터에서 변환된 문자 데이터	TO_CHAR	STR
부분 문자열	SUBSTR	SUBSTRING
문자 바꾸기	REPLACE	STUFF
문자열에서 각 단어의 첫 문자를 대문자로 만들기	INITCAP	해당 없음
문자열 번역	TRANSLATE	해당 없음
문자열 길이	LENGTH	DATELENGTH 또는 LEN
목록에서 가장 큰 문자열	GREATEST	해당 없음
목록에서 가장 작은 문자열	LEAST	해당 없음
NULL일 때 문자열 변환	NVL	ISNULL

날짜 함수

다음은 Oracle에서 지원하는 날짜 함수 및 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

함수 설명	Oracle	Microsoft SQL Server
날짜 추가	(날짜 열의 +/- 값) 또는 ADD_MONTHS	DATEADD
날짜 차이	(날짜 열의 +/- 값) 또는 MONTHS_BETWEEN	DATEDIFF
현재 날짜와 시간	SYSDATE	GETDATE()
달의 마지막 날	LAST_DAY	해당 없음
표준 시간대 변환	NEW_TIME	해당 없음
다음 날의 요일	NEXT_DAY	해당 없음
날짜의 문자열 표시	TO_CHAR	DATENAME
날짜의 정수 표시	TO_NUMBER(TO_CHAR))	DATEPART
날짜 반올림	ROUND	CONVERT
날짜 잘라내기	TRUNC	CONVERT
문자열을 날짜로	TO_DATE	CONVERT
NULL일 때 날짜 변환	NVL	ISNULL

변환 함수

다음은 Oracle에서 지원하는 변환 함수 및 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

함수 설명	Oracle	Microsoft SQL Server
숫자를 문자로	TO_CHAR	CONVERT
문자를 숫자로	TO_NUMBER	CONVERT
날짜를 문자로	TO_CHAR	CONVERT
문자를 날짜로	TO_DATE	CONVERT
16진수를 이진수로	HEX_TO_RAW	CONVERT
이진수를 16진수로	RAW_TO_HEX	CONVERT

기타 행 수준 함수

다음은 Oracle에서 지원하는 기타 행 수준 함수 및 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

함수 설명	Oracle	Microsoft SQL Server
NULL이 아닌 첫째 식 반환	DECODE	COALESCE
현재 시퀀스 값	CURRVAL	해당 없음
다음 시퀀스 값	NEXTVAL	해당 없음
식1 = 식2일 때 NULL 반환	DECODE	NULLIF
사용자의 로그인 ID 번호	UID	SUSER_ID
사용자의 로그인 이름	USER	SUSER_NAME
사용자의 데이터베이스 ID 번호	UID	USER_ID
사용자의 데이터베이스 이름	USER	USER_NAME
현재 사용자	CURRENT_USER	CURRENT_USER
사용자 환경(감사 추적)	USERENV	해당 없음
CONNECT BY 절의 수준	LEVEL	해당 없음

집계 함수

다음은 Oracle에서 지원하는 집계 함수 및 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

함수 설명	Oracle	Microsoft SQL Server
평균	AVG	AVG
개수	COUNT	COUNT
최대값	MAX	MAX
최소값	MIN	MIN
표준 편차	STDDEV	STDEV 또는 STDEVP
합계	SUM	SUM
분산	VARIANCE	VAR 또는 VARP

조건부 테스트

Oracle DECODE 문과 Microsoft SQL Server CASE 식 모두 조건부 테스트를 수행합니다. 테스트_값의 값이 그 다음에 오는 어떤 식과 일치하면 관련 값이 반환됩니다. 일치하지 않으면 기본_값이 반환됩니다. 기본_값이 지정되어 있지 않고 일치하는 식이 없으면 DECODE와 CASE는 NULL을 반환합니다. 다음 표는 변환된 DECODE 명령 예제를 비롯하여 구문을 정리한 것입니다.

Oracle

Microsoft SQL Server

DECODE (테스트_값, 식1, 값1 [[,식2, 값2] [U]] [,기본_값] ) CREATE VIEW STUDENT_ADMIN.STUDENT_GPA (SSN, GPA) AS SELECT SSN, ROUND(AVG(DECODE(grade ,'A', 4 ,'A+', 4.3 ,'A-', 3.7 ,'B', 3 ,'B+', 3.3 ,'B-', 2.7 ,'C', 2 ,'C+', 2.3 ,'C-', 1.7 ,'D', 1 ,'D+', 1.3 ,'D-', 0.7 ,0)),2) FROM STUDENT_ADMIN.GRADE GROUP BY SSN

CASE 입력_식 WHEN when_식 THEN 결과_식 [[WHEN when_식 THEN 결과_식] [...]] [ELSE else_결과_식] END CREATE VIEW STUDENT_ADMIN.STUDENT_GPA (SSN, GPA) AS SELECT SSN, ROUND(AVG(CASE grade WHEN 'A' THEN 4 WHEN 'A+' THEN 4.3 WHEN 'A-' THEN 3.7 WHEN 'B' THEN 3 WHEN 'B+' THEN 3.3 WHEN 'B-' THEN 2.7 WHEN 'C' THEN 2 WHEN 'C+' THEN 2.3 WHEN 'C-' THEN 1.7 WHEN 'D' THEN 1 WHEN 'D+' THEN 1.3 WHEN 'D-' THEN 0.7 ELSE 0 END),2) FROM STUDENT_ADMIN.GRADE GROUP BY SSN

CASE 식은 SELECT 문을 사용하여 부울 테스트를 수행할 수 있도록 지원합니다. DECODE 명령은 이를 허용하지 않습니다. CASE 식에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

값을 다른 데이터 형식으로 변환

Microsoft SQL Server의 CONVERT 및 CAST 함수는 다목적 변환 함수입니다. 이들은 비슷한 기능을 제공하며 식을 다른 데이터 형식으로 변환하고 다양한 특수 날짜 형식을 지원합니다.

• CAST(식 AS 데이터_형식)
• CONVERT (데이터 형식[(길이)], 식 [, 스타일])

CAST는 SQL-92 표준 함수입니다. 이들 함수는 Oracle의 TO_CHAR, TO_NUMBER, TO_DATE, HEXTORAW 및 RAWTOHEX 함수와 같은 작업을 수행합니다.

데이터 형식은 식을 변환할 모든 시스템 데이터 형식입니다. 사용자 정의 데이터 형식은 사용할 수 없습니다. 길이 매개 변수는 선택 사항이며 char, varchar, binary 및 varbinary 데이터 형식과 함께 사용됩니다. 허용되는 최대 길이는 8000입니다.

변환	Oracle	Microsoft SQL Server
문자를 숫자로	TO_NUMBER('10')	CONVERT(numeric, '10')
숫자를 문자로	TO_CHAR(10)	CONVERT(char, 10)
문자를 날짜로	TO_DATE('04-JUL-97') TO_DATE('04-JUL-1997', 'dd-mon-yyyy') TO_DATE('July 4, 1997', 'Month dd, yyyy')	CONVERT(datetime, '04-JUL-97') CONVERT(datetime, '04-JUL-1997') CONVERT(datetime, 'July 4, 1997')
날짜를 문자로	TO_CHAR(sysdate) TO_CHAR(sysdate, 'dd mon yyyy') TO_CHAR(sysdate, 'mm/dd/yyyy')	CONVERT(char, GETDATE()) CONVERT(char, GETDATE(), 106) CONVERT(char, GETDATE(), 101)
16진수를 이진수로	HEXTORAW('1F')	CONVERT(binary, '1F')
이진수를 16진수로	RAWTOHEX (binary_column)	CONVERT(char, 이진_열)

문자열이 어떻게 날짜로 변환되는지 눈여겨 보십시오. Oracle의 기본 날짜 형식 모델은 "DD-MON-YY"입니다. 다른 형식을 사용하는 경우 적절한 날짜 형식 모델을 제공해야 합니다. CONVERT 함수는 형식 모델을 필요로 하지 않고 자동으로 표준 날짜 형식을 변환합니다.

날짜를 문자열로 변환하면 CONVERT 함수의 기본 출력은 "dd mon yyyy hh:mm:ss:mmm(24h)"이 됩니다. 숫자 스타일 코드는 출력 형식을 다른 종류의 데이터 형식 모델로 지정하는 데 사용됩니다. CONVERT 함수에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

아래 표는 Microsoft SQL Server 날짜의 기본 출력을 정리한 것입니다.

세기 사용 안함	세기 사용	표준	출력
-	0 또는 100 (*)	기본값	mon dd yyyy hh:miAM(또는 PM)
1	101	미국	mm/dd/yy
2	102	ANSI	yy.mm.dd
3	103	영국/프랑스	dd/mm/yy
4	104	독일	dd.mm.yy
5	105	이탈리아	dd-mm-yy
6	106	-	dd mon yy
7	107	-	mon dd, yy
8	108	-	hh:mm:ss
-	9 또는 109 (*)	기본 밀리초	mon dd yyyy hh:mi:ss:mmm(AM 또는 PM)
10	110	미국	mm-dd-yy
11	111	일본	yy/mm/dd
12	112	ISO	yymmdd
-	13 또는 113 (*)	유럽 기본값	dd mon yyyy hh:mm:ss:mmm(24h)
14	114	-	hh:mi:ss:mmm(24h)

사용자 정의 함수

Oracle PL/SQL 함수는 Oracle SQL 문에 사용할 수 있습니다. Microsoft SQL Server에서는 보통 다른 방법을 사용하여 이 기능을 얻을 수 있습니다.

아래 예제에서는 Oracle의 사용자 정의 함수 GET_SUM_MAJOR를 사용하여 학생들이 지불하는 수업료의 합계를 냅니다. SQL Server에서는 쿼리를 테이블로 사용하여 이렇게 할 수 있습니다.

Oracle	Microsoft SQL Server
SELECT SSN, FNAME, LNAME, ) TUITION_PAID, TUITION_PAID/GET_SUM_ MAJOR(MAJOR) AS PERCENT_MAJOR FROM STUDENT_ADMIN.STUDENT	SELECT SSN, FNAME, LNAME, TUITION_PAID, TUITION_PAID/SUM_MAJOR AS PERCENT_MAJOR FROM STUDENT_ADMIN.STUDENT, (SELECT MAJOR, SUM(TUITION_PAID) SUM_MAJOR FROM STUDENT_ADMIN.STUDENT GROUP BY MAJOR) SUM_STUDENT WHERE STUDENT.MAJOR = SUM_STUDENT.MAJOR
CREATE OR REPLACE FUNCTION GET_SUM_MAJOR (INMAJOR VARCHAR2) RETURN NUMBER AS SUM_PAID NUMBER; BEGIN SELECT SUM(TUITION_PAID) INTO SUM_PAID FROM STUDENT_ADMIN.STUDENT WHERE MAJOR = INMAJOR; RETURN(SUM_PAID); END GET_SUM_MAJOR;	CREATE FUNCTION 구문이 필요하지 않습니다. CREATE PROCEDURE 구문을 사용하십시오.

Oracle과 Microsoft SQL Server의 비교 연산자는 거의 같습니다.

연산자	Oracle	Microsoft SQL Server
같음	(=)	(=)
큼	(>)	(>)
작음	(<)	(<)
크거나 같음	(>=)	(>=)
작거나 같음	(<=)	(<=)
같지 않음	(!=, <>, ^=)	(!=, <>, ^=)
크지 않음, 작지 않음	해당 없음	!> , !<
집합의 구성원에 있음	IN	IN
집합의 구성원에 없음	NOT IN	NOT IN
집합에 있는 임의의 값	ANY, SOME	ANY, SOME
집합에 있는 모든 값	!= ALL, <> ALL, < ALL, > ALL, <= ALL, >= ALL, != SOME, <> SOME, < SOME, > SOME, <= SOME, >= SOME	!= ALL, <> ALL, < ALL, > ALL, <= ALL, >= ALL, != SOME, <> SOME, < SOME, > SOME, <= SOME, >= SOME
패턴과 같음	LIKE	LIKE
패턴과 같지 않음	NOT LIKE	NOT LIKE
x와 y 사이의 값	BETWEEN x AND y	BETWEEN x AND y
사이에 있지 않은 값	NOT BETWEEN	NOT BETWEEN
값이 있음	EXISTS	EXISTS
값이 없음	NOT EXISTS	NOT EXISTS
값이 NULL이거나 NULL이 아님	IS NULL, IS NOT NULL	같습니다. 이전 버전과의 호환성을 위해 = NULL, != NULL도 사용할 수 있지만 권장되지 않습니다.

패턴 일치

SQL Server의 LIKE 키워드는 Oracle은 지원하지 않는 유용한 와일드카드 검색 옵션을 제공합니다. SQL Server는 양쪽 RDBMS에 공통된 % 및 _ 와일드카드 문자를 지원함은 물론 [ ] 및 [^] 문자도 지원합니다.

[ ] 문자 집합은 지정한 범위에서 단일 문자를 검색하는 데 사용합니다. 예를 들어, 단일 문자 위치에서 a부터 f까지의 문자를 검색하는 경우 LIKE '[a-f]' 또는 LIKE '[abcdef]'처럼 지정할 수 있습니다. 아래 표를 통해 이러한 추가 와일드카드 문자의 유용함을 확인할 수 있습니다.

Oracle	Microsoft SQL Server
SELECT * FROM STUDENT_ADMIN.STUDENT WHERE LNAME LIKE 'A%' OR LNAME LIKE 'B%' OR LNAME LIKE 'C%'	SELECT * FROM STUDENT_ADMIN.STUDENT WHERE LNAME LIKE '[ABC]%'

[^] 와일드카드 문자 집합은 지정된 범위에 NOT 문자를 지정할 때 사용합니다. 예를 들어, a부터 f까지를 제외한 모든 문자가 허용될 때 LIKE '[^a - f]' 또는 LIKE '[^abcdef]'를 사용합니다.

LIKE 키워드에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

비교 구문에 NULL 사용

Microsoft SQL Server는 전통적으로 일부 비표준 NULL 동작은 물론 SQL-92 표준을 지원했지만 Oracle에서 NULL을 사용할 수 있도록 지원합니다.

분산 쿼리를 실행하려면 SET ANSI_NULLS를 ON으로 설정해야 합니다.

SQL Server ODBC 드라이버와 SQL Server의 OLE DB 공급자는 연결될 때 자동으로 SET ANSI_NULLS를 ON으로 설정합니다. 이 설정은 SQL Server 연결 전에 응용 프로그램에서 설정하는 OLE DB 연결 등록 정보, ODBC 데이터 원본 또는 ODBC 연결 특성에서 구성할 수 있습니다. DB-라이브러리 응용 프로그램에서 연결할 수 있도록 SET ANSI_NULLS는 기본적으로 OFF로 설정됩니다.

SET ANSI_DEFAULTS가 ON이면 SET ANSI_NULLS가 사용 설정됩니다.

NULL 사용에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

문자열 연결

Oracle은 두 개의 파이프 기호(||)를 문자열 연결 연산자로 사용하고 SQL Server는 더하기 기호(+)를 사용합니다. 이 차이는 응용 프로그램 코드에서 약간만 수정하면 됩니다.

Oracle	Microsoft SQL Server
SELECT FNAME||' '||LNAME AS NAME FROM STUDENT_ADMIN.STUDENT	SELECT FNAME +' '+ LNAME AS NAME FROM STUDENT_ADMIN.STUDENT

흐름 제어 언어는 SQL 문, 문 블록 및 저장 프로시저의 실행 흐름을 제어합니다. PL/SQL과 Transact-SQL은 어느 정도의 구문 차이는 있지만 똑같은 구성을 많이 제공합니다.

키워드

이것은 각 RDBMS에서 지원하는 키워드입니다.

문	Oracle PL/SQL	Microsoft SQL Server Transact-SQL
변수 선언	DECLARE	DECLARE
문 블록	BEGIN...END;	BEGIN...END
조건부 처리	IFUTHEN, ELSIFUTHEN, ELSE ENDIF;	IFU[BEGINUEND] ELSE <조건> [BEGINUEND] ELSE IF <조건> CASE 식
무조건 끝내기	RETURN	RETURN
현재 프로그램 블록의 끝에 이어지는 문으로 무조건 이동	EXIT	BREAK
WHILE 루프 다시 시작	해당 없음	CONTINUE
지정한 간격 동안 대기	해당 없음(dbms_lock.sleep)	WAITFOR
루프 제어	WHILE LOOPUEND LOOP; LABELUGOTO LABEL; FORUEND LOOP; LOOPUEND LOOP;	WHILE <조건> BEGINU END LABELUGOTO LABEL
프로그램 설명	/* U */, --	/* U */, --
출력 인쇄	RDBMS_OUTPUT.PUT_ LINE	PRINT
프로그램 오류 발생	RAISE_APPLICATION_ ERROR	RAISERROR
프로그램 실행	EXECUTE	EXECUTE
문 종료 문자	세미콜론(;)	해당 없음

변수 선언

Transact-SQL과 PL/SQL 변수는 DECLARE 키워드로 만듭니다. Transact-SQL 변수는 @)로 구분하며 처음 만들 때는 PL/SQL 변수처럼 NULL 값으로 설정됩니다.

Oracle	Microsoft SQL Server
DECLARE VSSN CHAR(9); VFNAME VARCHAR2(12); VLNAME VARCHAR2(20); VBIRTH_DATE DATE; VLOAN_AMOUNT NUMBER(12,2);	DECLARE @VSSN CHAR(9), @VFNAME VARCHAR2(12), @VLNAME VARCHAR2(20), @VBIRTH_DATE DATETIME, @VLOAN_AMOUNT NUMERIC(12,2)

Transact-SQL은 %TYPE 및 %ROWTYPE 변수 데이터 형식 정의를 지원하지 않습니다. Transact-SQL 변수는 DECLARE 명령에서 시작할 수 없습니다. Oracle NOT NULL 및 CONSTANT 키워드는 Microsoft SQL Server 데이터 형식 정의에 사용할 수 없습니다.

Oracle의 LONG 및 LONG RAW 데이터 형식처럼 text 및 image 데이터 형식은 변수 선언에 사용할 수 없습니다. 또한 PL/SQL 스타일의 레코드 및 테이블 정의는 지원되지 않습니다.

변수 할당

Oracle과 Microsoft SQL Server에서는 아래 방법을 사용하여 지역 변수에 값을 할당합니다.

Oracle	Microsoft SQL Server
할당 연산자(:=)	SET @지역_변수 = 값
단일 행에서 열 값을 선택하기 위해 SELECT...INTO 구문 사용	리터럴 값, 다른 지역 변수가 관련된 식 또는 단일 행의 열 값을 할당하기 위해 SELECT @지역_변수 = 식 [FROMU] 사용
FETCHUINTO 구문	FETCHUINTO 구문

다음은 몇 가지 구문 예제입니다.

Oracle	Microsoft SQL Server
DECLARE VSSN CHAR(9); VFNAME VARCHAR2(12); VLNAME VARCHAR2(20); BEGIN VSSN := '123448887'; SELECT FNAME, LNAME INTO VFNAME, VLNAME FROM STUDENTS WHERE SSN=VSSN; END;	DECLARE @VSSN CHAR(9), @VFNAME VARCHAR(12), @VLNAME VARCHAR(20) SET @VSSN = '12355887' SELECT @VFNAME=FNAME, @VLNAME=LNAME FROM STUDENTS WHERE SSN = @VSSN

문 블록

Oracle PL/SQL과 Microsoft SQL Server Transact-SQL은 BEGINUEND 용어를 사용하여 문 블록을 지정할 수 있도록 지원합니다. Transact-SQL에서는 DECLARE 문 뒤에 문 블록을 사용할 필요가 없습니다. BEGINUEND 문 블록은 문이 둘 이상 실행되는 경우 Microsoft SQL Server의 IF 문과 WHILE 루프에 필요합니다.

Oracle	Microsoft SQL Server
DECLARE 변수 선언들 ... BEGIN -- 필수 구문입니다. 프로그램 문들 ... IF ...THEN 문1; 문2; 문N; END IF; WHILE ...LOOP 문1; 문2; 문N; END LOOP; END; -- 필수 구문입니다.	DECLARE 변수 선언들 ... BEGIN -- 선택적 구문입니다. 프로그램 문들 ... IF ... BEGIN 문1 문2 문N END WHILE ... BEGIN 문1 문2 문N END END -- 필수 구문입니다.

조건부 처리

Oracle PL/SQL의 ELSIF 문과는 달리 Microsoft SQL Server Transact-SQL 조건문에는 IF 및 ELSE가 포함됩니다. 여러 IF 문을 중첩하여 같은 효과를 얻을 수 있습니다. 확장 조건부 테스트의 경우 CASE 식을 사용하는 것이 읽는 데 더 쉽습니다.

Oracle	Microsoft SQL Server
DECLARE VDEGREE_PROGRAM CHAR(1); VDEGREE_PROGRAM_NAME VARCHAR2(20); BEGIN VDEGREE_PROGRAM := 'U'; IF VDEGREE_PROGRAM = 'U' THEN VDEGREE_PROGRAM_NAME := 'Undergraduate'; ELSIF VDEGREE_PROGRAM = 'M' THEN VDEGREE_PROGRAM_ NAME := 'Masters'; ELSIF VDEGREE_PROGRAM = 'P' THEN VDEGREE_PROGRAM_ NAME := 'PhD'; ELSE VDEGREE_PROGRAM_ NAME := 'Unknown'; END IF; END;	DECLARE @VDEGREE_PROGRAM CHAR(1), @VDEGREE_PROGRAM_NAME VARCHAR(20) SELECT @VDEGREE_PROGRAM = 'U' SELECT @VDEGREE_PROGRAM_ NAME = CASE @VDEGREE_PROGRAM WHEN 'U' THEN 'Undergraduate' WHEN 'M' THEN 'Masters' WHEN 'P' THEN 'PhD'. ELSE 'Unknown' END

반복 문 실행(루프)

Oracle PL/SQL은 무조건적 LOOP 및 FOR LOOP를 제공합니다. Transact-SQL은 루프를 위해 WHILE 루프와 GOTO 문을 제공합니다.

WHILE 부울_식
{sql_문| 문_블록}
[BREAK] [CONTINUE]

WHILE 루프는 하나 이상의 문이 반복 실행되는 동안 부울 식을 테스트합니다. 지정된 식의 값이 TRUE인 한 문(들)이 반복적으로 실행됩니다. 여러 문을 실행해야 하는 경우 BEGINUEND 블록 안에 이들 문을 입력해야 합니다.

Oracle	Microsoft SQL Server
DECLARE COUNTER NUMBER; BEGIN COUNTER := 0 WHILE (COUNTER <5) LOOP COUNTER := COUNTER + 1; END LOOP; END;	DECLARE @COUNTER NUMERIC SELECT@COUNTER = 1 WHILE (@COUNTER <5) BEGIN SELECT @COUNTER = @COUNTER +1 END

BREAK 및 CONTINUE 키워드를 사용하여 루프 안에서 문 실행을 제어할 수 있습니다. BREAK 키워드는 WHILE 루프에서 무조건 나가도록 만들고 CONTINUE 키워드는 WHILE 루프를 다시 시작하고 그 뒤에 오는 모든 문을 무시하도록 만듭니다. BREAK 키워드는 Oracle PL/SQL EXIT 키워드와 같습니다. Oracle에는 CONTINUE에 상응하는 키워드가 없습니다.

GOTO 문

Oracle과 Microsoft SQL Server 모두 GOTO 문을 가지고 있지만 구문은 다릅니다. GOTO 문은 Transact-SQL 배치가 레이블로 점프해서 실행되도록 만듭니다. 따라서 GOTO 문과 레이블 사이에 있는 어떤 문도 실행되지 않습니다.

Oracle	Microsoft SQL Server
GOTO 레이블; <<이곳에 레이블 이름 입력>>	GOTO 레이블

PRINT 문

Transact-SQL PRINT 문은 PL/SQL RDBMS_OUTPUT put_line 프로시저와 같은 작업을 수행합니다. 이 문은 사용자 지정 메시지를 인쇄하는 데 사용합니다.

PRINT 문의 메시지 제한은 8,000자입니다. char 또는 varchar 데이터 형식을 사용하여 정의한 변수를 인쇄되는 문에 포함할 수 있습니다. 다른 데이터 형식을 사용하는 경우 CONVERT 또는 CAST 함수를 사용해야 합니다. 지역 변수, 전역 변수 및 텍스트를 인쇄할 수 있습니다. 작은따옴표와 큰따옴표를 사용하여 텍스트를 묶을 수 있습니다.

저장 프로시저에서 복귀

Microsoft SQL Server와 Oracle 모두 RETURN 문을 가지고 있습니다. RETURN 문은 프로그램이 쿼리나 프로시저를 무조건 끝내도록 만듭니다. RETURN 문은 즉시 실행되어 완료되며 프로시저, 배치 또는 문 블록 등 끝내고자 하는 모든 지점에 사용할 수 있습니다. RETURN 뒤에 오는 문들은 실행되지 않습니다.

Oracle	Microsoft SQL Server
RETURN 식:	RETURN [정수_식]

프로그램 오류 발생

Transact-SQL RAISERROR 문은 사용자 정의 오류 메시지를 반환하고 오류가 발생한 레코드에 시스템 플래그를 설정합니다. 이 문은 PL/SQL의 raise_application_error 예외 처리기와 기능이 비슷합니다.

RAISERROR 문을 사용하면 클라이언트가 sysmessages 테이블에서 항목을 검색하거나 사용자 정의 심각성 및 상태 정보로 메시지를 동적으로 만들 수 있습니다. 이 메시지를 정의하면 메시지가 클라이언트에게 서버 오류 메시지로 반환됩니다.

RAISERROR ({msg_id | msg_str}, severity, state
[, 인수1 [, 인수2]])
[WITH 옵션]

PL/SQL 프로그램을 변환할 때 RAISERROR 문을 사용할 필요는 없을 것입니다. 아래 코드 예제에서 PL/SQL 프로그램은 raise_application_error 예외 처리기를 사용하고 Transact-SQL 프로그램은 아무것도 사용하지 않습니다. raise_application_error 예외 처리기는 PL/SQL 프로그램이 모호한 처리되지 않은 예외입니다. 오류 메시지를 반환하지 않도록 하기 위해 포함했습니다. 대신 예기치 않은 문제가 발생하면 항상 Oracle 오류 메시지(SQLERRM)를 반환합니다.

Transact-SQL 프로그램이 실패하면 항상 자세한 오류 메시지를 클라이언트 프로그램에 반환합니다. 따라서 특별한 오류 처리가 필요하지 않은 한 RAISERROR 문이 항상 필요하지는 않습니다.

Oracle	Microsoft SQL Server
CREATE OR REPLACE FUNCTION DEPT_ADMIN.DELETE_DEPT (VDEPT IN VARCHAR2) RETURN NUMBER AS BEGIN DELETE FROM DEPT_ADMIN.DEPT WHERE DEPT = VDEPT; RETURN(SQL%ROWCOUNT); EXCEPTION WHEN OTHER THEN RAISE_APPLICATION_ERROR (-20001,SQLERRM); END DELETE_DEPT; /	CREATE PROCEDURE DEPT_ADMIN.DELETE_DEPT @VDEPT VARCHAR(4) AS DELETE FROM DEPT_DB.DBO.DEPT WHERE DEPT = @VDEPT RETURN @@ROWCOUNT GO

커서 구현

Oracle의 경우 데이터베이스에 요청되는 행 수와는 상관없이 커서를 항상 SELECT 문과 함께 사용해야 합니다. Microsoft SQL Server의 경우 커서 안에 포함되지 않은 SELECT 문은 행을 클라이언트에 기본 결과 집합으로 반환합니다. 이는 클라이언트 응용 프로그램에 데이터를 반환하는 효율적인 방법입니다.

SQL Server는 커서 함수에 두 개의 인터페이스를 제공합니다. Transact-SQL 배치나 저장 프로시저에 커서를 사용하면, SQL 문을 사용하여 위치 지정 업데이트 및 삭제는 물론 커서를 선언하고 열고 반입할 수 있습니다. DB-라이브러리, ODBC 또는 OLEDB 프로그램의 커서가 사용되면, SQL Server 클라이언트 라이브러리는 커서를 더 효율적으로 처리하기 위해 기본 제공 서버 함수를 드러나지 않게 호출합니다.

Oracle에서 PL/SQL 프로시저를 들여올 때는 먼저 Transact-SQL에서 동일 기능을 수행하기 위해 커서가 필요한지 여부를 결정해야 합니다. 커서가 클라이언트 응용 프로그램에 행 집합만 반환하는 경우 Transact-SQL에서 비커서 SELECT 문을 사용하여 기본 결과 집합을 반환합니다. 한 번에 한 행씩 로컬 프로시저 변수로 데이터를 로드하는 데 커서가 사용되는 경우 Transact-SQL에서 커서를 사용해야 합니다.

다음은 커서 사용 구문을 정리한 표입니다.

작업	Oracle	Microsoft SQL Server
커서 선언	CURSOR 커서_이름 [(커서_매개 변수)] IS select_문;	DECLARE 커서_이름 CURSOR [LOCAL | GLOBAL] [FORWARD_ONLY | SCROLL] [STATIC | KEYSET | DYNAMIC | FAST_FORWARD] [READ_ONLY | SCROLL_LOCKS | OPTIMISTIC] [TYPE_WARNING] FOR select_문 [FOR UPDATE [OF 열_이름 [,Un]]]
커서 열기	OPEN 커서_이름 [(커서_매개 변수)];	OPEN 커서_이름
커서 반입	FETCH 커서_이름 INTO 변수	FETCH [[NEXT | PRIOR | FIRST | LAST | ABSOLUTE {n | @nvar} | RELATIVE {n | @nvar}] FROM] 커서_이름 [INTO @variable(s)]
반입한 행 업데이트	UPDATE 테이블_이름 SET 문U WHERE CURRENT OF 커서_이름;	UPDATE 테이블_이름 SET 문U WHERE CURRENT OF 커서_이름
반입한 행 삭제	DELETE FROM 테이블_이름 WHERE CURRENT OF 커서_이름;	DELETE FROM 테이블_이름 WHERE CURRENT OF 커서_이름
커서 닫기	CLOSE 커서_이름;	CLOSE 커서_이름
커서 데이터 구조 제거	해당 없음	DEALLOCATE 커서_이름

Transact-SQL DECLARE CURSOR 문은 커서 인수 사용은 지원하지 않지만 지역 변수는 지원합니다. 이러한 지역 변수의 값은 커서가 열릴 때 커서에 사용됩니다. Microsoft SQL Server는 DECLARE CURSOR 문에 많은 추가 기능을 제공합니다.

INSENSITIVE 옵션을 사용하여, 해당 커서가 사용할 임시 데이터 복사본을 만드는 커서를 정의할 수 있습니다. 이 임시 테이블이 커서에 대한 모든 요청에 응답합니다. 따라서, 기본 테이블을 수정해도 이 커서에 만들어진 반입이 반환하는 데이터에는 수정 사항이 반영되지 않습니다. 이 커서 유형이 액세스하는 데이터는 수정할 수 없습니다.

응용 프로그램이 커서 유형을 요청한 다음, 요청된 유형의 서버 커서가 지원하지 않는 Transact-SQL 문을 실행할 수 있습니다. 그러면 SQL Server는 그 커서 유형이 변경되었음을 나타내는 오류를 반환하거나 인수 집합이 주어지는 경우 커서를 암시적으로 변환합니다. SQL Server 7.0을 실행하여 커서 유형을 암시적으로 변환하는 인수 목록을 보려면 SQL Server 온라인 설명서를 참조하십시오.

SCROLL 옵션은 정방향 반입 외에도 뒤로 반입, 절대 반입, 상대 반입을 지원합니다. 스크롤 커서는 키 집합 커서 모델을 사용합니다. 이 모델에서는 원본으로 사용하는 테이블에 대해 사용자가 커밋하는 삭제 및 업데이트가 이후의 반입에 반영됩니다. 이는 커서가 INSENSITIVE 옵션으로 선언되지 않은 경우에만 적용됩니다.

READ ONLY 옵션을 선택하면 커서 안의 어떤 행에 대해서도 업데이트가 이뤄지지 않습니다. 이 옵션은 커서의 기본 기능(업데이트)을 무시합니다.

UPDATE [OF 열_목록] 문은 커서에 업데이트할 수 있는 열을 정의하는 데 사용합니다. [OF 열_목록]을 제공하면 나열된 열에 대해서만 수정이 허용됩니다. 목록을 제공하지 않으면 커서가 READ ONLY로 정의되어 있지 않은 한 모든 열을 업데이트할 수 있습니다.

SQL Server 커서의 이름 범위는 연결 자체입니다. 이 이름 범위는 지역 변수의 이름 범위와는 다릅니다. 첫째 커서를 할당 취소할 때까지는 동일 사용자 연결에서 기존 커서와 이름이 같은 둘째 커서를 선언할 수 없습니다.

Transact-SQL은 PL/SQL과는 달리 열려 있는 커서에 인수를 전달하는 것을 지원하지 않습니다. Transact-SQL 커서가 열려 있으면 결과 집합 구성원과 순서가 고정됩니다. 다른 사용자가 커서의 기본 테이블에 대해 커밋한 업데이트 및 삭제는 INSENSITIVE 옵션 없이 정의된 모든 커서에 대한 반입에 반영됩니다. INSENSITIVE 커서의 경우 임시 테이블이 만들어집니다.

역방향 또는 상대적 스크롤 기능이 없기 때문에 Oracle 커서는 앞으로만 움직일 수 있습니다. SQL Server 커서는 아래 표에 나온 반입 옵션을 사용하여 앞뒤로 스크롤할 수 있습니다. 이러한 반입 옵션은 커서를 SCROLL 옵션으로 선언했을 때만 사용할 수 있습니다.

스크롤 옵션	설명
NEXT	결과 집합의 첫째 행이 커서에 대한 첫째 반입인 경우 그 행을 반환합니다. 그렇지 않으면 결과 집합에서 커서를 한 행씩 이동합니다. NEXT는 전체 결과 집합을 빠짐 없이 처리할 때 사용하는 기본 방법입니다. NEXT는 기본 커서 반입입니다.
PRIOR	결과 집합의 이전 행을 반환합니다.
FIRST	결과 집합의 첫째 행으로 커서를 이동하고 그 행을 반환합니다.
LAST	결과 집합의 마지막 행으로 커서를 이동하고 그 행을 반환합니다.
ABSOLUTE n	결과 집합의 n번째 행을 반환합니다. n이 음수 값인 경우 결과 집합의 마지막 행부터 거꾸로 계산하여 n번째 행을 반환합니다.
RELATIVE n	현재 반입된 행 뒤의 n번째 행을 반환합니다. n이 음수 값인 경우 커서의 상대 위치부터 거꾸로 계산하여 n번째 행을 반환합니다.

Transact-SQL FETCH 문에는 INTO 절이 필요하지 않습니다. 반환 변수를 지정하지 않으면 행이 자동으로 단일 행 결과 집합으로 클라이언트에 반환됩니다. 그러나 프로시저가 클라이언트에 여러 행을 반환해야 하는 경우 비커서 SELECT 문을 사용하는 것이 훨씬 더 효과적입니다.

@@FETCH_STATUS 함수는 각 FETCH 뒤에 업데이트됩니다. 이 함수는 PL/SQL에 사용되는 CURSOR_NAME%FOUND 및 CURSOR_NAME%NOTFOUND 변수와 사용 방법이 비슷합니다. 반입이 성공적이면 @@FETCH_STATUS 함수가 0으로 설정됩니다. 반입이 커서의 끝을 지나 읽으려 하면 -1이 반환됩니다. 요청된 행이 커서가 열린 후 테이블에서 삭제된 경우 @@FETCH_STATUS 함수는 -2를 반환합니다. 일반적으로 -2는 SCROLL 옵션으로 선언한 커서일 때만 반환됩니다. 각 반입 뒤에 이 변수를 검사하여 데이터 유효성을 확인해야 합니다.

SQL Server는 Oracle의 커서 FOR 루프 구문을 지원하지 않습니다.

업데이트 및 삭제에 대한 CURRENT OF 절 구문과 함수는 PL/SQL과 Transact-SQL 모두 같습니다. 위치 지정 UPDATE 또는 DELETE는 지정된 커서 안의 현재 행에 대해 수행됩니다.

Transact-SQL CLOSE CURSOR 문의 경우 커서는 닫아도 데이터 구조는 다시 열 수 있도록 그대로 유지합니다. PL/SQL CLOSE CURSOR 문은 모든 데이터 구조를 닫고 해제합니다.

Transact-SQL에서는 DEALLOCATE CURSOR 문을 사용하여 커서 데이터 구조를 제거해야 합니다. DEALLOCATE CURSOR 문은 닫힌 커서를 다시 열 수 있는 CLOSE CURSOR와는 다릅니다. DEALLOCATE CURSOR 문은 커서와 관련된 모든 데이터 구조를 해제하고 커서 정의를 제거합니다.

아래 표는 PL/SQL의 커서 문 및 그에 상응하는 Transact-SQL의 커서 문을 정리한 것입니다.

Oracle	Microsoft SQL Server
DECLARE VSSN CHAR(9); VFNAME VARCHAR(12); VLNAME VARCHAR(20);	DECLARE @VSSN CHAR(9), @VFNAME VARCHAR(12), @VLNAME VARCHAR(20)
CURSOR CUR1 IS SELECT SSN, FNAME, LNAME FROM STUDENT ORDER BY LNAME; BEGIN OPEN CUR1; FETCH CUR1 INTO VSSN, VFNAME, VLNAME; WHILE (CUR1%FOUND) LOOP FETCH CUR1 INTO VSSN, VFNAME, VLNAME; END LOOP; CLOSE CUR1; END;	DECLARE curl CURSOR FOR SELECT SSN, FNAME, LNAME FROM STUDENT ORDER BY SSN OPEN CUR1 FETCH NEXT FROM CUR1 INTO @VSSN, @VFNAME, @VLNAME WHILE (@@FETCH_STATUS <> -1) BEGIN FETCH NEXT FROM CUR1 INTO @VSSN, @VFNAME, @VLNAME END CLOSE CUR1 DEALLOCATE CUR1

SQL 문 튜닝

이 절에서는 Transact-SQL 문을 튜닝하는 데 사용할 수 있는 여러 가지 SQL Server 도구에 대한 정보를 제공합니다. SQL Server 데이터베이스 튜닝에 대한 자세한 내용은 이 문서의 앞부분에 나오는 "성능 튜닝"을 참조하십시오.

SQL Server 쿼리 분석기의 그래픽 표시를 사용하면 최적화 프로그램이 문을 어떻게 처리하는지에 대해 자세한 정보를 얻을 수 있습니다.

이 그래픽 도구는 실시간으로 서버 동작을 계속 캡처하여 기록합니다. SQL Server 프로파일러는 다른 많은 서버 이벤트와 이벤트 범주를 모니터링하고, 이러한 이벤트를 사용자 정의 기준을 사용하여 필터링하고, 화면, 파일 또는 다른 SQL Server에 그 결과를 출력합니다.

SQL Server 프로파일러를 사용하여 아래 작업을 수행할 수 있습니다.

• SQL Server의 성능을 모니터링합니다.
• Transact-SQL 문 및 저장 프로시저를 디버깅합니다.
• 느리게 실행되는 쿼리를 확인합니다.
• 점차 특별한 문제로 발전하는 모든 이벤트를 캡처한 다음 테스트 시스템에서 그 이벤트를 재연하여 문제를 복제하고 격리함으로써 SQL Server에 발생하는 문제를 해결합니다.
• 전체 문을 한 번에 한 행씩 검사하여 코드가 예상대로 동작하는 것을 확인함으로써 프로젝트 개발 단계에서 SQL 문과 저장 프로시저를 테스트합니다.
• 프로덕션 시스템에서 이벤트를 캡처하고 그 이벤트를 테스트 시스템에서 재연함으로써 테스트 또는 디버깅을 위해 프로덕션 환경의 상황을 재연합니다. 별도의 시스템에서 캡처한 이벤트를 재연하면 사용자들이 프로덕션 시스템을 장애 없이 계속 사용할 수 있습니다.

SQL Server 프로파일러는 확장 저장 프로시저 집합에 그래픽 사용자 인터페이스를 제공합니다. 이러한 확장 저장 프로시저를 직접 사용할 수도 있습니다. 따라서 SQL Server를 모니터링하기 위해 SQL Server 프로파일러의 확장 저장 프로시저를 사용하는 자체적인 응용 프로그램을 작성하는 것이 가능합니다.

SET 문은 작업 세션이 유지되는 동안 또는 트리거나 저장 프로시저가 실행되는 동안 SQL Server 쿼리 처리 옵션을 설정할 수 있습니다.

Oracle 최적화 프로그램에 사용되는 ORDERED 참고와 비슷하게, SET FORCEPLAN ON 문은 최적화 프로그램이 FROM 절에 나타나는 테이블 순서와 똑같은 순서로 조인을 처리하게 만듭니다.

SET SHOWPLAN_ALL 및 SET SHOWPLAN_TEXT 문은 쿼리 또는 문의 실행 계획 정보만 반환하며 쿼리나 문을 실행하지는 않습니다. 쿼리나 문을 실행하려면 해당 표시 문을 OFF로 설정해야 합니다. 그러면 쿼리나 문이 실행됩니다. SHOWPLAN 옵션은 Oracle EXPLAIN PLAN 도구와 비슷한 결과를 제공합니다.

SET STATISTICS PROFILE ON을 사용하면, 실행되는 각 쿼리가 통상적인 결과 집합을 반환한 다음 쿼리 실행 프로필을 표시하는 추가 결과 집합을 반환합니다. SET STATISTICS IO 및 SET STATISTICS TIME 옵션도 사용할 수 있습니다.

Transact-SQL 문 처리는 컴파일과 실행이라는 두 단계로 이뤄집니다. NOEXEC 옵션은 각 쿼리를 컴파일하지만 실행하지는 않습니다. NOEXEC를 ON으로 설정하면 이를 다시 OFF로 설정할 때까지 다른 SET 문을 포함하여 이후의 어떤 문도 실행되지 않습니다.

SET SHOWPLAN ON
SET NOEXEC ON
go
SELECT * FROM DEPT_ADMIN.DEPT,
STUDENT_ADMIN.STUDENT
WHERE MAJOR = DEPT
go
STEP 1
The type of query is SETON
STEP 1
The type of query is SETON
STEP 1
The type of query is SELECT
FROM TABLE
DEPT_ADMIN.DEPT
Nested iteration
Table Scan
FROM TABLE
STUDENT_ADMIN.STUDENT
Nested iteration
Table Scan

Oracle에서는 비용 기준 최적화 프로그램의 작업과 성능에 영향을 미치려면 참고를 사용해야 합니다. Microsoft SQL Server의 비용 기준 최적화 프로그램에서는 쿼리 평가 프로세스를 지원하기 위해 참고를 사용할 필요가 없습니다. 그러나 참고를 사용해야 하는 상황이 있기 때문에 참고가 제공되기는 합니다.

INDEX = {인덱스_이름 | 인덱스_id} 참고는 해당 테이블에 사용할 인덱스 이름이나 ID를 지정합니다. 인덱스_id가 0이면 테이블 스캔이 이뤄지고 인덱스_id가 1이면 클러스터된 인덱스(있는 경우)가 사용됩니다. 이는 Oracle에 사용되는 인덱스 참고와 비슷합니다.

SQL Server FASTFIRSTROW 참고는 인덱스의 열 순서가 ORDER BY 절과 일치하면 최적화 프로그램이 클러스터되지 않은 인덱스를 사용하게 만듭니다. 이 참고는 Oracle FIRST_ROWS 참고와 비슷한 방식으로 동작합니다.

ODBC 사용

이 절에서는 Oracle과 SQL Server의 ODBC 사용 방식에 대한 정보를 제공하고 ODBC를 사용한 응용 프로그램 개발 또는 마이그레이션에 대해 설명합니다.

응용 프로그램 코드를 Oracle에서 SQL Server로 변환할 때는 아래 절차를 따릅니다.

1. Oracle Pro*C 또는 OCI(Oracle Call Interface)를 사용하여 작성한 응용 프로그램인 경우 ODBC로 변환하는 것을 고려합니다.
2. SQL Server의 기본 결과 집합과 커서 옵션에 대해 이해하고 응용 프로그램에 가장 효과적인 반입 전략을 선택합니다.
3. 필요하면 Oracle ODBC SQL 데이터 형식을 SQL Server ODBC SQL 데이터 형식에 다시 매핑합니다.
4. ODBC 확장 SQL 확장을 사용하여 일반 SQL 문을 만듭니다.
5. SQL Server 응용 프로그램에 수동 커밋 모드가 필요한지 확인합니다.
6. 응용 프로그램의 성능을 테스트하고 필요에 따라 프로그램을 수정합니다.

Microsoft는 16비트 및 32비트 버전 ODBC SQL Server 드라이버를 제공합니다. 32비트 ODBC SQL Server 드라이버는 스레드에 안전합니다. 이 드라이버는 공유 문 핸들(hstmt), 연결 핸들(hdbc) 및 환경 핸들(henv)에 대한 여러 스레드의 공유 액세스를 순차적으로 처리합니다. 그러나 여러 스레드를 사용하더라도 여전히 ODBC 프로그램이 문이나 연결 공간에 있는 작업을 올바른 시퀀스로 유지해야 합니다.

Oracle의 ODBC 드라이버는 많은 공급업체 중 어떤 공급업체라도 제공할 수 있기 때문에 아키텍처 및 작업과 관련하여 여러 가지 시나리오가 있을 수 있습니다. 따라서 해당 공급업체에 문의하여 ODBC 드라이버가 응용 프로그램 요구 사항을 충족하는지 확인해야 합니다.

대부분의 경우 Oracle의 ODBC 드라이버는 SQL*Net을 사용하여 Oracle RDBMS에 연결합니다. 그러나 Personal Oracle에 연결할 때는 SQL*Net이 사용되지 않습니다.

아래 그림에 32비트 환경에 대한 응용 프로그램/드라이버 아키텍처가 나와 있습니다.

썽킹이란 함수 호출을 가로챈 다음 특별한 처리를 통해 16비트와 32비트 간에 코드를 변환하고 대상 함수에 제어를 전송하는 것을 의미합니다. 선택 사항인 ODBC 커서 라이브러리가 드라이버 관리자와 그 드라이버 간에 어떤 방식으로 존재하는지 눈여겨 보십시오. 이 라이브러리는 정방향 커서만 지원하는 드라이버 위에 스크롤 가능 커서 서비스를 제공합니다.

Oracle과 SQL Server는 결과 집합과 커서를 서로 다르게 처리합니다. 클라이언트 응용 프로그램을 Oracle에서 SQL Server로 성공적으로 마이그레이션하고 이들이 최적의 상태로 동작하도록 하려면 이러한 차이를 반드시 이해해야 합니다.

Oracle에서, SELECT 명령의 모든 결과 집합은 클라이언트 응용 프로그램에 반입될 때 정방향 커서로 처리됩니다. 이는 ODBC, OCI 또는 Embedded SQL 등 개발 도구로 무엇을 사용하든 상관없이 적용됩니다.

기본적으로, 클라이언트 프로그램이 내리는 각 Oracle FETCH 명령(예: ODBC의 SQLFetch)은 네트워크 전체에 걸친 서버로의 왕복을 통해 한 번에 한 행이 반환되도록 합니다. 네트워크를 통해 한 번에 둘 이상의 행을 반입하고자 하는 클라이언트 응용 프로그램은 프로그램에 배열을 만들어야 합니다.

Oracle의 다중 버전 동시성 모델 때문에 읽기 전용 커서에 대해 서버 수준에서 반입 간 잠금은 유지되지 않습니다. 프로그램이 FOR UPDATE 절로 업데이트할 수 있는 커서를 지정하면 SELECT 명령 안의 요청된 모든 행이 문이 열릴 때 잠깁니다. 이러한 행 수준 잠금은 프로그램이 COMMIT 또는 ROLLBACK 요청을 할 때까지 그대로 유지됩니다.

SQL Server에서는 SELECT 문이 항상 서버에서 커서와 연결되지는 않습니다. 기본적으로, SQL Server는 SELECT 문의 모든 결과 집합 행을 간단히 클라이언트에 다시 보냅니다. 이 스트리밍은 SELECT 문이 실행되지마자 시작됩니다. 결과 집합 스트림은 저장 프로시저 안의 SELECT 문도 반환할 수 있습니다. 또한 단일 저장 프로시저 또는 명령 묶음이 단일 EXECUTE 문에 응답하여 다수의 결과 집합을 스트림할 수 있습니다.

SQL Server 클라이언트는 이러한 기본 결과 집합이 사용 가능해지면 이들을 바로 반입해야 합니다. 기본 결과 집합의 경우 클라이언트로 반입될 때 서버로의 왕복이 필요하지 않습니다. 대신, 기본 결과 집합을 반입하면 지역 네트워크 버퍼에서 프로그램 변수로 데이터가 들어옵니다. 이 기본 결과 집합 모델은 이 네트워크에 대한 단일 왕복으로 클라이언트에 여러 데이터 행을 반환하는 효율적인 메커니즘을 제공합니다. 일반적으로 네트워크 왕복을 최소화하는 것이 클라이언트/서버 응용 프로그램 성능에서 가장 중요한 요소입니다.

Oracle의 커서와 비교했을 때 기본 결과 집합은 SQL Server 클라이언트 응용 프로그램에 약간의 추가 책임을 지웁니다. SQL Server 클라이언트 응용 프로그램은 EXECUTE 문이 반환하는 모든 결과 집합 행을 즉시 반입해야 합니다. 프로그램의 다른 부분에 행을 점증적으로 제공해야 하는 응용 프로그램은 내부 배열에 행을 버퍼링해야 합니다. 모든 결과 집합 행을 반입하지 못하면 SQL Server에 대한 연결이 사용 중 상태를 유지합니다.

이렇게 되면 전체 결과 집합 행이 반입되거나 클라이언트가 요청을 취소할 때까지 UPDATE 문 같은 다른 어떤 작업도 그 연결에서 실행할 수 없습니다. 뿐만 아니라, 반입이 완료될 때까지 서버가 계속 테이블 데이터 페이지에 공유 잠금을 유지합니다. 반입이 완료될 때까지 공유 잠금이 유지되므로 이럴 때는 모든 행을 최대한 빨리 반입해야 합니다. 이 방식은 Oracle 응용 프로그램에서 공통적으로 볼 수 있는 점증적 반입 방식과 뚜렷한 대조를 이룹니다.

Microsoft SQL Server는 네트워크 전체에 걸친 결과 집합을 점증적으로 반입할 수 있도록 서버 커서를 제공합니다. SQLSetStmtOption을 호출하여 SQL_CURSOR_TYPE 옵션을 설정하는 것만으로 응용 프로그램에서 서버 커서를 요청할 수 있습니다.

SELECT 문이 서버 커서로 실행되면 EXECUTE 문이 커서 ID만 반환합니다. 이후의 반입 요청은 한 번에 반입할 행 수를 지정하는 매개 변수와 함께 커서 ID를 다시 서버에 보냅니다. 그러면 서버는 요청된 행 수를 반환합니다.

반입 요청 사이에, 연결은 다른 커서 OPEN 또는 FETCH 요청을 포함하여 다른 명령을 자유롭게 내릴 수 있습니다. ODBC에서, 이는 서버 커서를 통해 SQL Server 드라이버가 단일 연결에 여러 활성 문을 지원할 수 있다는 뜻입니다.

뿐만 아니라, 서버 커서는 보통 반입 요청 간에 잠금을 유지하지 않기 때문에 다른 사용자들에게 영향을 미치지 않고 사용자 입력을 위해 반입 사이에 일시 중지할 수 있습니다. 공유 충돌 검색 또는 독점 스크롤 잠금 동시성 옵션을 사용하여 서버 커서를 업데이트할 수 있습니다.

이러한 기능 덕분에 Oracle 개발자들은 서버 커서를 사용하여 기본 결과 집합을 사용할 때보다 쉽게 프로그래밍할 수 있지만 비용이 많이 듭니다. 기본 결과 집합과 서버 커서를 비교하면 아래와 같습니다.

• 서버에 커서 상태 정보를 유지하는 데 임시 저장소 공간이 사용되기 때문에 서버 리소스라는 측면에서 서버 커서의 비용이 더 높습니다.
• 서버 커서의 경우, EXECUTE 문 및 서버 커서의 각 반입 요청에 대해 서버를 따로 왕복해야 하기 때문에, 특정 데이터 결과 집합을 검색하는 데 드는 비용이 더 높습니다.
• 지원하는 배치 및 저장 프로시저의 종류를 생각할 때 서버 커서는 유연성이 떨어집니다. 서버 커서는 한 번에 하나의 SELECT 문만 실행할 수 있는 반면, 기본 결과 집합은 여러 결과 집합을 반환하거나 SELECT 문 이외의 다른 문을 포함한 배치 및 저장 프로시저에 사용할 수 있습니다.

이런 이유 때문에 서버 커서의 기능이 필요한 응용 프로그램 부분에만 서버 커서를 사용하는 것이 현명합니다. Ssdemo.cpp 예제 SQL Server ODBC 프로그램 파일의 LIST_STUDENTS 함수에서 서버 커서의 사용 예를 볼 수 있습니다.

Oracle RDBMS는 정방향 스크롤 커서를 지원합니다. 각 행은 쿼리에 지정된 순서대로 응용 프로그램에 반입됩니다. Oracle은 이전에 반입된 행으로 되돌아가기 위한 요청을 지원하지 않습니다. 되돌아가려면 커서를 닫은 다음 다시 여는 방법밖에 없습니다. 그러나 이렇게 하면 활성 쿼리 집합의 첫째 행으로 되돌아갑니다.

SQL Server는 스크롤 가능 커서를 지원하기 때문에 SQL Server 커서를 원하는 모든 행 위치로 옮길 수 있습니다. 정방향 스크롤과 역방향 스크롤이 모두 가능합니다. 사용자 인터페이스와 관련된 많은 응용 프로그램에서는 스크롤할 수 있는 기능이 아주 유용합니다. 스크롤 가능 커서를 사용하면, 응용 프로그램이 한 화면 전체에 해당하는 행을 한 번에 반입할 수 있으며 사용자가 요구할 때는 추가 행만 반입할 수 있습니다.

Oracle이 스크롤 가능 커서를 직접적으로 지원하지는 않지만 여러 가지 ODBC 옵션을 사용하면 이 제한을 최소화할 수 있습니다. 예를 들어, Microsoft Developer Studio 개발 시스템과 함께 제공되는 드라이버 같은 일부 Oracle ODBC 드라이버는 클라이언트 기반 스크롤 가능 커서를 드라이버 자체에 제공합니다.

그리고 ODBC 커서 라이브러리가 레벨 1 일치 수준을 따르는 ODBC 드라이버에 대해 스크롤 가능 블록 커서를 지원하기도 합니다. 이들 클라이언트 커서 옵션은 정방향 반입에 대해 RDBMS를 사용하고 결과 집합 데이터를 메모리나 디스크에 캐시함으로써 스크롤을 지원합니다. 데이터 요청이 들어오면 드라이버가 필요에 따라 RDBMS 또는 그 로컬 캐시에서 데이터를 검색합니다.

클라이언트 기반 커서는 또한 SELECT 문이 만드는 결과 집합에 대해 위치 지정 UPDATE 및 DELETE 문을 지원합니다. 커서 라이브러리는 행의 각 열에 대한 캐시 값을 지정하는 WHERE 절이 포함된 UPDATE 또는 DELETE 문을 만듭니다.

스크롤 가능 커서가 필요하고 Oracle과 SQL Server 구현에 대해 동일 원본 코드를 유지하려는 경우 ODBC 커서 라이브러리를 사용하는 것이 유용합니다. ODBC 커서 라이브러리에 대한 자세한 내용은 ODBC 설명서를 참조하십시오.

데이터 반입과 관련하여 SQL Server가 제공하는 모든 옵션에 대해 언제 어떤 옵션을 사용해야 할지 결정하기 힘들 때가 있습니다. 아래의 몇 가지 지침을 참고하면 도움이 될 것입니다.

• SQL Server에서 클라이언트로 전체 데이터 집합을 가져오는 가장 빠른 방법은 기본 결과 집합을 사용하는 것입니다. 응용 프로그램의 어떤 부분에 이 기능을 활용할 수 있을지 잘 생각해 보십시오. 예를 들어, 일괄 리포트 작성 프로세스는 일반적으로 중간에 사용자 개입이나 업데이트 없이 전체 결과 집합을 끝까지 처리합니다.
• 프로그램에 업데이트 가능 커서가 필요하면 서버 커서를 사용합니다. 위치 지정 UPDATE 또는 DELETE 문을 사용할 때는 기본 결과 집합을 절대 업데이트할 수 없습니다. 뿐만 아니라, 서버 커서는 클라이언트 기반 커서보다 업데이트 성능이 뛰어납니다. 클라이언트 기반 커서는 검색된 UPDATE 또는 DELETE 문의 등가물을 만들어 위치 지정 UPDATE 또는 DELETE 문을 시뮬레이트해야 합니다.
• 프로그램에 스크롤 가능 읽기 전용 커서가 필요한 경우 ODBC 커서 라이브러리와 서버 커서 모두 유용합니다. ODBC 커서 라이브러리는 SQL Server와 Oracle 간에 호환되는 동작을 제공하고 서버 커서는 네트워크 전체에 걸쳐 한 번에 반입할 데이터 양과 관련하여 더 많은 융통성을 제공합니다.
• 기본 결과 집합 또는 기본 결과 집합 위에 만들어진 ODBC 커서 라이브러리 커서를 사용할 때는 서버에 공유 잠금이 유지되지 않도록 최대한 빨리 결과 집합을 끝까지 반입해야 합니다.
• 서버 커서를 사용할 때는 한 번에 한 행씩 반입하지 않고 행 블록을 반입할 수 있도록 SQLExtendedFetch를 사용합니다. 이는 Oracle 응용 프로그램의 배열 형식 반입과 같습니다. 서버 커서에 대한 반입 요청을 처리하려면 항상 응용 프로그램에서 네트워크의 RDBMS까지 왕복해야 합니다.

  이를 식료품을 구입하는 것에 비춰 생각할 수 있습니다. 예를 들어, 식료품점에서 구입한 식료품을 10개의 봉투에 나눠 담은 다음 그 중 하나를 차에 싣고 집으로 가져온 후 다시 식료품점으로 돌아가 그 다음 봉투를 가져오는 경우를 가정할 수 있습니다. 물론 실제로는 이런 일이 없겠지만 서버 커서에서 단일 행을 반입하면 SQL Server에서 이런 상황이 발생합니다.

• 정방향 읽기 전용 커서만 필요로 하지만 동일 연결에 대해 열려 있는 여러 커서를 사용하는 프로그램인 경우, 전체 결과 집합을 프로그램 변수로 즉시 반입할 수 있다면 기본 결과 집합을 사용합니다. 모든 행을 즉시 반입할 수 있는지 알 수 없을 때는 서버 커서를 사용합니다.

이 전략은 생각만큼 어렵지 않습니다. 대부분의 프로그래머는 최대 한 행을 반환할 수 있는 단일 선택 문을 언제 사용해야 하는지 알고 있습니다. 단일 반입의 경우, 기본 결과 집합을 사용하는 것이 서버 커서를 사용하는 것보다 효과적입니다.

Ssdemo.cpp 예제 SQL Server ODBC 프로그램 파일의 LIST_STUDENTS 함수에서 이 방식을 사용한 예제를 확인할 수 있습니다. SELECT 문이 행을 둘 이상 반환할 경우에만 어떤 방식으로 서버 커서가 요청되는지 눈여겨 보십시오. 실행 단계가 지나면 행 집합 크기가 적절한 배치 크기로 설정됩니다. 따라서 기본 결과 집합이나 서버 커서의 경우에 같은 SQLExtendedFetch 루프가 효율적으로 동작할 수 있습니다.

커서 구현에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

ODBC 드라이버는 문 핸들(hstmt)을 사용하여 프로그램 안의 각 활성 SQL 문을 추적합니다. 문 핸들은 항상 RDBMS 연결 핸들(hdbc)과 연결됩니다. ODBC 드라이버 관리자는 연결 핸들을 사용하여 요청된 SQL 문을 지정된 RDBMS로 보냅니다. 대부분의 Oracle ODBC 드라이버는 한 연결에 여러 문 핸들을 허용합니다. 그러나 SQL Server ODBC 드라이버는 기본 결과 집합을 사용할 때 한 연결에 하나의 활성 문 핸들만 허용합니다. 이 SQL Server 드라이버의 SQLGetInfo 함수는 SQL_ACTIVE_STATEMENTS 옵션을 사용한 쿼리를 받았을 때 1을 반환합니다. 서버 커서를 사용하는 방식으로 문 옵션이 설정되어 있으면 한 연결에 여러 활성 문이 지원됩니다.

서버 커서를 요청하기 위한 문 옵션 설정에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.

SQL Server ODBC 드라이버는 Oracle의 어떤 ODBC 드라이버보다 풍부한 데이터 형식 매핑 집합을 제공합니다.

SQL Server 데이터 형식	ODBC SQL 데이터 형식
binary	SQL_BINARY
bit	SQL_BIT
char, character	SQL_CHAR
datetime	SQL_TIMESTAMP
decimal, dec	SQL_DECIMAL
float, double precision, float(n) for n = 8-15	SQL_FLOAT
image	SQL_LONGVARBINARY
int, integer	SQL_INTEGER
money	SQL_DECIMAL
nchar	SQL_WCHAR
ntext	SQL_WLONGVARCHAR
numeric	SQL_NUMERIC
nvarchar	SQL_WVARCHAR
real, float(n) for n = 1-7	SQL_REAL
smalldatetime	SQL_TIMESTAMP
smallint	SQL_SMALLINT
smallmoney	SQL_DECIMAL
sysname	SQL_VARCHAR
text	SQL_LONGVARCHAR
timestamp	SQL_BINARY
tinyint	SQL_TINYINT
uniqueidentifier	SQL_GUID
varbinary	SQL_VARBINARY
varchar	SQL_VARCHAR

timestamp 데이터 형식은 SQL_BINARY 데이터 형식으로 변환됩니다. 시간 스탬프 열의 값이 datetime 데이터가 아니라 binary(8) 데이터이기 때문입니다. 이들은 행에 대한 SQL Server 동작의 시퀀스를 나타내기 위해 사용됩니다.

Oracle용 Microsoft ODBC 드라이버에 대한 Oracle 데이터 형식 매핑이 아래 표에 나와 있습니다.

Oracle 데이터 형식	ODBC SQL 데이터 형식
CHAR	SQL_CHAR
DATE	SQL_TIMESTAMP
LONG	SQL_LONGVARCHAR
LONG RAW	SQL_LONGVARBINARY
NUMBER	SQL_FLOAT
NUMBER(P)	SQL_DECIMAL
NUMBER(P,S)	SQL_DECIMAL
RAW	SQL_BINARY
VARCHAR2	SQL_VARCHAR

다른 공급업체에서 제공하는 Oracle ODBC 드라이버의 데이터 형식 매핑은 이와 다를 수 있습니다.

ODBC 확장 SQL 표준은 Oracle과 SQL Server에 제공되는 비표준 고급 SQL 기능 집합을 지원하는 ODBC SQL 확장을 제공합니다. 이 표준은 ODBC 드라이버가 일반 SQL 문을 Oracle 및 SQL Server 고유의 SQL 구문으로 변환할 수 있도록 합니다.

이 표준은 조건자 이스케이프 문자, 스칼라 함수, 날짜/시간/시간 스탬프 값, 저장 프로그램 같은 외부 조인에 대해 다룹니다. 아래 구문을 사용하여 이러한 확장을 식별합니다.

--(*vendor(Microsoft), product(ODBC) extension *)--
OR
{extension}

변환은 실행 시에 이뤄지며 프로그램 코드의 수정을 요구하지 않습니다. 대부분의 응용 프로그램 개발 시나리오에서는, 프로그램을 작성한 다음 프로그램이 실행될 때 ODBC가 RDBMS 변환 프로세스를 수행할 수 있도록 하는 것이 가장 좋습니다.

Oracle과 SQL Server의 외부 조인 구문은 호화되지 않습니다. 이 문제는 ODBC 확장 SQL 외부 조인 구문을 사용하여 해결할 수 있습니다. Microsoft SQL Server 구문은 ODBC 확장 SQL/SQL-92 구문과 같습니다. 유일한 차이는 {oj } 컨테이너입니다.

ODBC 확장 SQL 및 SQL-92	Oracle	Microsoft SQL Server
SELECT STUDENT.SSN, FNAME, LNAME, CCODE, GRADE FROM {oj STUDENT LEFT OUTER JOIN GRADE ON STUDENT.SSN = GRADE.SSN}	SELECT SUBSTR(LNAME,1,5) FROM STUDENT	SELECT SUBSTRING(LNAME,1,5) FROM STUDENT

ODBC는 날짜, 시간, 시간 스탬프 값에 대한 세 가지 이스케이프 절을 제공합니다.

범주	약식 구문	형식
날짜	{d 'value'}	"yyyy-mm-dd"
시간	{t 'value'}	"hh:mm:ss"
시간 스탬프	{Ts 'value'}	"yyyy-mm-dd hh:mm:ss[.fU]"

날짜 형식은 SQL Server 응용 프로그램보다 Oracle 응용 프로그램에 더 많은 영향을 미칩니다. Oracle은 기본적으로 "DD-MON-YY" 날짜 형식을 사용합니다. 다른 모든 경우에는 형식 변환을 수행하기 위해 날짜 형식 모델에 TO_CHAR 또는 TO_DATE 함수가 사용됩니다.

Microsoft SQL Server는 대부분의 공통 날짜 형식을 자동으로 변환하며 자동 변환을 수행할 수 없을 때는 CONVERT 함수도 제공합니다.

아래 표에 나온 것처럼 ODBC 확장 SQL은 두 데이터베이스 모두에 작용합니다. SQL Server에는 변환 함수가 필요하지 않습니다. 그러나 ODBC 약식 구문은 일반적으로 Oracle과 SQL Server 모두에 적용할 수 있습니다.

ODBC 확장 SQL	Oracle	Microsoft SQL Server
SELECT SSN, FNAME, LNAME, BIRTH_DATE FROM STUDENT WHERE BIRTH_DATE < {D '1970-07-04'}	SELECT SSN, FNAME, LNAME, BIRTH_DATE FROM STUDENT WHERE BIRTH_DATE < TO_DATE('1970-07-04', 'YYYY-MM-DD')	SELECT SSN, FNAME, LNAME, BIRTH_DATE FROM STUDENT WHERE BIRTH_DATE < '1970-07-04'

저장 프로그램을 호출하기 위한 ODBC 약식 구문은 Microsoft SQL Server 저장 프로시저 및 Oracle 저장 프로시저, 함수, 패키지를 지원합니다. 선택 사항인 "?="는 Oracle 함수 또는 SQL Server 프로시저에 대한 반환 값을 캡처합니다. 매개 변수 구문은 호출된 프로그램과 반환 값을 주고 받는 데 사용됩니다. 대부분의 상황에서 Oracle과 SQL Server 응용 프로그램에 동일 구문을 일반적으로 적용할 수 있습니다.

아래 예제에서, SHOW_RELUCTANT_STUDENTS 함수는 Oracle 패키지 P1의 일부입니다. 이 함수는 PL/SQL 커서에서 여러 행을 반환하기 때문에 패키지 안에 존재해야 합니다. 패키지 안에 있는 함수나 프로시저를 호출할 때는 프로그램 이름 앞에 패키지 이름을 배치해야 합니다.

패키지 P1의 SHOW_RELUCTANT_STUDENTS 함수는 패키지 커서를 사용하여 여러 데이터 행을 검색합니다. 각 행은 이 함수에 대한 호출을 사용하여 요청해야 합니다. 검색할 행이 더 이상 없으면 함수는 검색할 행이 더 이상 없음을 나타내는 0을 반환합니다. 이 예제 Oracle 패키지 및 그 함수의 성능이 만족스럽지 않을 수도 있습니다. 이런 종류의 작업에는 SQL Server 프로시저가 더 효과적입니다.

일반 ODBC 확장 SQL	Oracle	Microsoft SQL Server
{?=} call 프로시저_이름[(매개 변수)]} SQLExecDirect(hstmt1,(SQLCHAR *)"{?= call owner.procedure(?)}", SQL_NTS);	SQLExecDirect(hstmt1, (SQLCHAR*)"{?= call STUDENT_ADMIN.P1. SHOW_RELUCTANT _STUDENTS(?)}", SQL_NTS);	SQLExecDirect(hstmt1, (SQLCHAR*)"{?= call STUDENT_ADMIN. SHOW_RELUCTANT _STUDENTS}", SQL_NTS);

Oracle과 SQL Server 모두 ODBC 드라이버가 다양하기 때문에 확장 SQL 함수에 대해 항상 똑같은 변환 문자열이 제공되지는 않을 것입니다. 응용 프로그램 디버깅 문제를 해결하기 위해 SQLNativeSql 함수를 사용하고자 하는 경우도 있을 것입니다. 이 함수는 SQL 문자열을 드라이버가 변환한 대로 반환합니다.

다음은 스칼라 함수 CONVERT가 포함된 아래의 입력 SQL 문자열에서 나올 수 있는 결과입니다. SSN 열은 CHAR(9) 형식으로 정의되고 숫자 값으로 변환됩니다.

원래 문	변환된 Oracle 문	변환된 SQL Server 문
SELECT (fn CONVERT (SSN, SQL_INTEGER)} FROM STUDENT	SELECT TO_NUMBER(SSN) FROM STUDENT	SELECT CONVERT(INT, SSN) FROM STUDENT

Common.cpp 예제 프로그램은 ODBC 확장 SQL 구문을 사용하지 않습니다. 대신, Oracle과 SQL Server에 공통으로 사용되지 않는 문과 함수를 숨기기 위한 일련의 뷰와 프로시저를 사용합니다. ODBC를 사용하여 작성하긴 했지만, 이 프로그램은 공통 프로그램을 작성하려는 응용 프로그래머가 마주치는 분명한 장애를 얼마나 쉽게 극복할 수 있는지 보여 주기 위해 준비한 것입니다.

이러한 방식과 전략은 비 ODBC 개발 환경에 가장 적절히 적용됩니다. ODBC를 사용하는 경우, ODBC 확장 SQL 구문을 사용하여 Oracle과 SQL Server의 구문 차이를 해결하는 방법을 고려해 보십시오.

Oracle은 사용자가 데이터를 수정할 때마다 자동으로 트랜잭션 모드로 전환합니다. 그 다음에는 명시적 COMMIT을 사용하여 데이터베이스에 변경 사항을 써야 합니다. 변경 사항을 취소하려는 사용자는 ROLLBACK 문을 사용해야 합니다.

기본적으로, SQL Server는 변경 사항이 있을 때마다 자동으로 변경 사항을 커밋합니다. 이를 ODBC에서는 자동 커밋 모드라고 합니다. 이렇게 되지 않도록 하려면 BEGIN TRANSACTION 문을 사용하여 트랜잭션을 구성하는 문 블록의 시작 위치를 지정할 수 있습니다. 이 문이 시작된 후 명시적 COMMIT TRANSACTION 또는 ROLLBACK TRANSACTION 문이 이어집니다.

Oracle 응용 프로그램과의 호환성을 유지하려면, SQLConnectOption 함수를 사용하여 SQL Server 응용 프로그램을 암시적 트랜잭션 모드에 두는 것이 좋습니다. 이를 위해서는 SQL_AUTOCOMMIT 옵션을 SQL_AUTOCOMMIT_OFF로 설정해야 합니다. 예제 프로그램에서 발췌한 아래 코드에서 이 개념을 확인할 수 있습니다.

SQLSetConnectOption(hdbc1, SQL_AUTOCOMMIT,-sql_AUTOCOMMIT_OFF);

SQL_AUTOCOMMIT_OFF 옵션은 암시적 트랜잭션을 사용하도록 드라이버에 지시합니다. 기본 옵션인 SQL_AUTOCOMMIT_ON은 자동 모드를 사용하도록 지시합니다. 이 모드에서는 각 문이 실행된 후 즉시 커밋됩니다. 수동 커밋 모드를 자동 커밋 모드로 변경하면 연결 상의 열려 있는 모든 트랜잭션이 커밋됩니다.

SQL_AUTOCOMMIT_OFF 옵션을 설정하면 응용 프로그램이 SQLTransact 함수를 사용하여 트랜잭션을 명시적으로 커밋하거나 롤백해야 합니다. 이 함수는 연결 핸들과 관련된 모든 문 핸들의 모든 활성 작업에 대해 커밋 또는 롤백 작업을 요청합니다. 또한 환경 핸들과 연결된 모든 연결에 대해 커밋 또는 롤백 작업을 수행할 것을 요청합니다.

SQLTransact(henv1, hdbc1, SQL_ROLLBACK);
(SQLTransact(henv1, hdbc1, SQL_COMMIT);

자동 커밋 모드가 꺼져 있으면 드라이버가 서버에 SET IMPLICIT_TRANSACTIONS ON 문을 내립니다. SQL Server 6.5부터는 이 모드에서 DDL 문이 지원됩니다.

수동 커밋 모드에서 트랜잭션을 커밋하거나 롤백하려면 응용 프로그램이 SQLTransact 함수를 호출해야 합니다. SQL Server 드라이버는 COMMIT TRANSACTION 문을 보내 트랜잭션을 커밋하고 ROLLBACK TRANSACTION 문을 보내 트랜잭션을 롤백합니다.

수동 커밋 모드는 SQL Server 응용 프로그램의 성능에 좋지 않은 영향을 미칠 수 있으므로 주의해야 합니다. COMMIT TRANSACTION 문자열을 보내려면 모든 커밋 요청마다 따로 서버에 왕복해야 합니다.

단일 자동 트랜잭션(COMMIT에 바로 이어지는 단일 INSERT, UPDATE 또는 DELETE)이 있는 경우 자동 커밋 모드를 사용하십시오.

Oracle RDBMS용으로 만들어진 유사 응용 프로그램의 동작을 최대한 가깝게 모방하는 SQL Server 응용 프로그램을 얼마나 쉽게 개발할 수 있는지 보여 주기 위해, 예제 프로그램에서는 자동 트랜잭션에도 수동 커밋 모드를 사용했습니다.

데이터베이스 복제 개발 및 관리

이 절에서는 Oracle과 Microsoft SQL Server 간의 복제 지원의 차이에 대해 설명합니다.

SQL Server는 Oracle의 읽기 전용 스냅샷 대신 스냅샷 복제를 구현합니다. 이름에서 알 수 있듯, 스냅샷 복제는 어느 특정 시간에 데이터베이스에 발행된 데이터의 사진을 찍거나 스냅샷을 만듭니다. 스냅샷 복제에서는 원본 서버의 데이터 변경 사항을 끊임없이 모니터링하지 않아도 되기 때문에 트랜잭션 복제보다 지속적인 프로세서 오버헤드가 적습니다. INSERT, UPDATE 및 DELETE 문(트랜잭션 복제의 특징) 또는 데이터 수정 사항(병합 복제의 특징)을 복사하는 대신, 데이터 집합의 전체 새로 고침에 의해 구독자가 업데이트됩니다. 따라서, 스냅샷 복제는 구독자에게 변경 사항만 보내지 않고 모든 데이터를 보냅니다.

SQL Server는 트랜잭션 복제도 제공합니다. 트랜잭션 복제는 게시자의 데이터베이스 트랜잭션 로그에 있는 선택된 트랜잭션을 복제용으로 표시한 다음 이들을 비동기 방식으로 구독자에게 변경 분만큼 배포하면서 트랜잭션 일관성을 유지하는 복제 유형입니다.

SQL Server는 Oracle의 업데이트 가능 스냅샷 및 Oracle의 멀티마스터 복제 모델 대신 병합 복제를 구현합니다. 병합 복제는 사이트들이 복제된 데이터에 대해 자치 변경을 수행할 수 있도록 하고 나중에 모든 사이트의 변경 사항을 병합할 수 있도록 하는 복제 유형입니다. 병합 복제는 트랜잭션 일관성을 보장하지 않습니다.

SQL Server는 유형이 다른 복제를 제공합니다. 이 복제는 ODBC를 사용하고 발행자에서 ODBC 구독자로의 밀어넣기 구독을 만듦으로써 유형이 다른 구독자에게 데이터를 게시하는 가장 간단한 방법입니다. 그러나 발행물을 만든 다음 삽입된 분산 컨트롤을 사용하여 응용 프로그램을 만드는 방법도 있습니다. 삽입 컨트롤은 구독자에서 발행자로의 밀어넣기 구독을 구현합니다. ODBC 구독자의 경우, 구독 데이터베이스가 수행되고 있는 복제와 관련된 관리 기능을 가지지 않습니다.

배포 서버는 모든 구독 서버에 ODBC 클라이언트로 연결됩니다. 복제를 위해서는 모든 배포 서버에 ODBC 32비트 드라이버를 설치해야 합니다. SQL Server 설치 프로그램은 필요한 드라이버를 Windows NT 기반 컴퓨터에 자동으로 설치합니다.

배포 프로세스는 구독자의 네트워크 이름만 사용하여 연결을 설정하기 때문에 SQL Server 구독 서버에 대해 ODBC 데이터 원본을 미리 구성할 필요가 없습니다.

SQL Server는 또한 Oracle이 SQL Server를 구독할 수 있도록 하는 ODBC 드라이버도 제공합니다. 이 드라이버는 Intel 기반 컴퓨터 전용 드라이버입니다. Oracle ODBC 구독자에게 복제하려면 Oracle 또는 해당 소프트웨어 공급업체에서 해당 Oracle SQL*Net 드라이버도 구해야 합니다.

Windows NT 레지스트리에 암호가 제공되는 경우 Oracle ODBC 드라이버가 암호를 요청하지 않고 Oracle에 연결됩니다. Windows NT 레지스트리에 암호가 제공되지 않으면 SQL Server 엔터프라이즈 관리자의 New ODBC Subscriber 대화 상자에서 DSN을 지정할 때 Oracle ODBC 데이터 원본에 대한 사용자 이름과 암호를 입력해야 합니다.

Oracle ODBC 구독자에게 복제할 때는 아래와 같은 제한이 적용됩니다.

• datetime 데이터 형식이 DATE에 매핑됩니다. Oracle DATE 데이터 형식의 범위는 B.C. 4712 - A.D. 4712입니다. Oracle에 복제할 때는 복제되는 열의 SQL Server datetime 항목이 이 범위 안에 있는지 확인해야 합니다.
• 복제된 테이블에는 text 또는 image 열 하나만 포함될 수 있습니다.
• datetime 데이터 형식은 Oracle CHAR 데이터 형식에 매핑됩니다.
• float 및 real 데이터 형식에 대한 SQL Server 범위는 Oracle 범위와는 다릅니다.

다른 ODBC 구독자 유형에 대한 드라이버는 일반 ODBC 구독자에 대한 SQL Server 복제 요구 사항을 준수해야 합니다. ODBC 드라이버는 아래 사항을 준수해야 합니다.

• ODBC 레벨 1 일치 수준을 따라야 합니다.
• 32비트이어야 하고 배포 프로세스가 실행되는 프로세서 아키텍처에 대해 스레드에 안전해야 합니다.
• 트랜잭션이 가능해야 합니다.
• 데이터 정의 언어(DDL)를 지원해야 합니다.
• 읽기 전용이어서는 안 됩니다.

데이터 및 응용 프로그램 마이그레이션

이 절에서는 Oracle 데이터베이스에서 Microsoft SQL Server 데이터베이스로 데이터를 마이그레이션하는 다양한 방법을 소개합니다.

Oracle에서 SQL Server로 마이그레이션하는 가장 간단한 방법은 Microsoft SQL Server 7.0의 데이터 변환 서비스(DTS) 기능을 사용하는 것입니다. DTS 마법사가 SQL Server로 데이터를 마이그레이션할 수 있도록 전과정을 안내합니다.

OCI(Oracle Call Interface)를 사용하여 작성한 응용 프로그램이 있는 경우 ODBC를 사용하여 응용 프로그램을 다시 작성하는 방법을 고려해 볼 수 있습니다. OCI는 Oracle RDBMS 전용이므로 Microsoft SQL Server나 다른 데이터베이스에 사용할 수 없습니다.

대부분의 경우, OCI 함수를 적절한 ODBC 함수로 바꾼 다음 지원 프로그램 코드를 적절히 변경할 수 있습니다. 나머지 비 OCI 프로그램 코드는 최소한의 수정 작업만 하면 됩니다. 아래 예제는 Oracle 데이터베이스에 대한 연결을 설정하는 데 필요한 OCI 및 ODBC 문을 비교한 것입니다.

OCI	Oracle ODBC
rcl = olog(&로그온_데이터_영역, &호스트_데이터_영역, 사용자_이름, -1, (텍스트*) 0, -1, (텍스트) 0, -1, OCI_LM_DEF);	rcl = SQLConnect(hdbc1, (SQLCHAR*) ODBC_dsn, (SQLSMALLINT) SQL_NTS, (SQLCHAR*) 사용자_이름, (SQLSMALLINT) SQL_NTS, (SQLCHAR*) 사용자_암호, (SQLSMALLINT) SQL_NTS);

아래 표는 Oracle OCI 함수 호출을 ODBC 함수로 변환할 때 참고할 수 있는 제안 사항입니다. 이러한 제안은 대략적인 것일 뿐입니다. 실제 변환 프로세스에서 함수가 정확하게 일치하지 않을 수도 있습니다. 따라서 비슷한 기능을 얻기 위해 프로그램 코드를 추가로 수정해야 할 수도 있습니다.

OCI 함수	ODBC 함수
Obindps	SQLBindParameter
Obndra	SQLBindParameter
Obndrn	SQLBindParameter
Obndrv	SQLBindParameter
Obreak	SQLCancel
Ocan	SQLCancel, SQLFreeStmt
Oclose	SQLFreeStmt
Ocof	SQLSetConnectOption
Ocom	SQLTransact
Ocon	SQLSetConnectOption
Odefin	SQLBindCol
Odefinps	SQLBindCol
Odescr	SQLDescribeCol
Oerhms	SQLError
Oexec	SQLExecute, SQLExecDirect
Oexfet	SQLExecute, SQLExecDirect, SQLFetch
Oexn	SQLExecute, SQLExecDirect
Ofen	SQLExtendedFetch
Ofetch	SQLFetch
Oflng	SQLGetData
Ogetpi	SQLGetData
Olog	SQLConnect
Ologof	SQLDisconnect
Oopen	SQLExecute, SQLExecDirect
Oparse	SQLPrepare
Orol	SQLTransact

많은 응용 프로그램이 Oracle Programmatic Interfaces(Pro*C, Pro*Cobol 등)를 사용하여 작성됩니다. 이러한 인터페이스는 SQL-92 표준 Embedded SQL 사용을 지원합니다. 또한 비표준 Oracle Programmatic 확장도 지원합니다.

C 개발 환경용 Microsoft ESQL(Embedded SQL)을 사용하여 Oracle Embedded SQL 응용 프로그램을 SQL Server로 마이그레이션할 수 있습니다. 이 환경은 성능 제어 및 SQL Server 기능 사용과 관련하여 적절하기는 하지만 ODBC 응용 프로그램보다 낮은 최적화 수준을 제공합니다.

Microsoft의 ESQL 선행 컴파일러에서는 일부 Oracle Pro*C 기능이 지원되지 않습니다. Oracle 응용 프로그램이 이러한 기능을 폭넓게 사용하는 경우 ODBC를 다시 작성하는 것이 더 나은 마이그레이션 전략일 것입니다. 이러한 기능을 정리하면 아래와 같습니다.

• 호스트 배열 변수
• 데이터 형식 대응을 위한 VAR 및 TYPE 문
• C++ 모듈에 Embedded SQL 지원
• 삽입 PL/SQL 또는 Transact-SQL 블록 지원
• 커서 변수
• 멀티 스레드 응용 프로그램 지원
• ORACA(Oracle Communication Area) 지원

Cobol로 개발한 Oracle 응용 프로그램인 경우 Micro Focus의 Cobol용 Embedded SQL로 마이그레이션할 수 있습니다. Cobol에서도 C 선행 컴파일러용 Microsoft ESQL에서와 같은 제약을 받을 수 있습니다.

Oracle Embedded SQL 응용 프로그램을 ODBC 환경으로 변환할 수 있습니다. 이 마이그레이션 프로세스는 아주 간단하며 많은 이점을 제공합니다. ODBC는 Embedded SQL과는 달리 선행 컴파일러 사용을 요구하지 않습니다. 따라서, 프로그램 개발과 관련된 많은 오버헤드가 사라집니다.

아래 표는 Embedded SQL 문과 ODBC 함수의 대략적인 관계를 나타낸 것입니다.

Embedded SQL 문	ODBC 함수
CONNECT	SQLConnect
PREPARE	SQLPrepare
EXECUTE	SQLExecute
DECLARE CURSOR 및 OPEN CURSOR	SQLExecute
EXECUTE IMMEDIATE	SQLExecDirect
DESCRIBE SELECT LIST	SQLNumResultCols, SQLColAttributes, SQLDescribeCol
FETCH	SQLFetch
SQLCA.SQLERRD[2]	SQLRowCount
CLOSE	SQLFreeStmt
COMMIT WORK, ROLLBACK WORK	SQLTransact
COMMIT WORK RELEASE, ROLLBACK WORK RELEASE	SQLDisconnect
SQLCA, SQLSTATE	SQLError
ALTER, CREATE, DROP, GRANT, REVOKE	SQLExecute, SQLExecDirect

Embedded SQL 프로그램을 ODBC로 변환할 때 나타나는 가장 큰 변화는 SQL 문 오류 처리와 관련된 것입니다. MODE = ORACLE 옵션은 흔히 Embedded SQL 프로그램을 개발할 때 사용합니다. 이 옵션을 사용하면 일반적으로 SQLCA(SQL Communications Area)가 오류 처리 작업에 사용됩니다.

SQLCA 구조는 아래 항목을 제공합니다.

• Oracle 오류 코드
• Oracle 오류 메시지
• 경고 플래그
• 프로그램 이벤트와 관련된 정보
• 가장 최근의 SQL 문이 처리한 행 수

대부분의 경우 각 SQL 문이 실행된 다음 sqlca.sqlcode 변수 값을 확인해야 합니다. 값이 0보다 작으면 오류가 발생한 것입니다. 값이 0보다 크면 요청된 문이 경고와 더불어 실행된 것입니다. Oracle 오류 메시지 텍스트는 sqlca.sqlerrm.sqlerrmc 변수에서 검색할 수 있습니다.

ODBC에서는 요청된 작업이 끝난 후 함수가 성공이나 실패를 나타내는 숫자 상태 코드를 반환합니다. 상태 코드는 리터럴 문자열로 정의되며 SQL_SUCCESS, SQL_SUCCESS_WITH_INFO, SQL_NEED_DATA, SQL_ERROR 등을 포함합니다. 각 함수 호출 뒤에 이러한 반환 값을 확인하는 것은 사용자의 몫입니다.

관련 SQLSTATE 값은 SQLError 함수를 호출하여 얻을 수 있습니다. 이 함수는 SQLSTATE 오류 코드, 데이터 원본 고유의 기본 오류 코드, 오류 메시지 텍스트를 반환합니다.

응용 프로그램은 일반적으로 ODBC 함수에 대한 이전 호출이 SQL_ERROR 또는 SQL_SUCCESS_WITH_INFO를 반환할 때 이 함수를 호출합니다. 그러나 모든 ODBC 함수는 호출될 때마다 0 또는 그 이상의 오류를 게시할 수 있으므로 응용 프로그램이 모든 ODBC 함수 호출 뒤에 SQLError를 호출할 수 있습니다.

다음은 각 환경의 오류 처리 예입니다.

Oracle Pro*C 및 EMBEDDED SQL	Oracle ODBC
EXEC SQL DECLARE CURSOR C1 CURSOR FOR SELECT SSN, FNAME, LNAME FROM STUDENT ORDER BY SSN; EXEC SQL OPEN C1; if (sqlca.sqlcode) != 0 { /* 오류 조건을 처리합니다. 오류 설명에 대해서는 sqlca.sqlerrm.sqlerrmc를 참조하십시오...*/}	if (SQLExecDirect(hstmtl, (SQLCHAR*)"SELECT SSN, FNAME, LNAME FROM STUDENT ORDER BY SSN", SQL_NTS) != SQL_SUCCESS) { /* 오류 조건을 처리합니다. 오류와 관련된 SQLSTATE 세부 사항에 대해서는 SQLError를 참조하십시오...*/}

Oracle Developer 2000을 사용하여 개발한 응용 프로그램을 SQL Server에서 사용하려는 경우 Microsoft Visual Basic으로 변환해 보십시오. Visual Basic은 양쪽 데이터베이스 모두에서 잘 동작하는 강력한 개발 시스템입니다. Microsoft Visual Studio의 다른 개발 도구 또는 PowerBuilder, SQL Windows 등을 사용할 수도 있습니다.

Developer 2000에서 바로 마이그레이션할 수 없는 경우 SQL Server로의 Oracle 게이트웨이를 사용할 수 있습니다. Oracle에서 SQL Server로 마이그레이션할 때 SQL Server로의 Oracle 게이트웨이를 중간 단계로 사용할 수 있습니다. 이 게이트웨이는 Oracle RDBMS가 SQL Server에 연결될 수 있도록 합니다. 게이트웨이가 SQL Server 데이터에 대한 모든 요청을 자동으로 변환합니다. Developer 2000 응용 프로그램에는 이 연결이 드러나지 않습니다. SQL Server 데이터는 Oracle 데이터로 나타납니다. 응용 프로그램 코드는 거의 변경하지 않아도 됩니다.

중간 단계로 SQL Server에서 직접 Developer 2000 응용 프로그램을 사용하는 방법도 있습니다. Developer 2000은 Oracle OCA(Open Client Adapter)를 사용하여 SQL Server에 직접 액세스할 수 있습니다. OCA는 ODBC 레벨 1을 준수하며 ODBC 레벨 2 함수를 제한적으로 지원합니다.

OCA는 SQL Server ODBC 드라이버와의 연결을 설정합니다. Developer 2000 도구를 SQL Server에 연결할 때는 ODBC 데이터 원본 이름을 데이터베이스 연결 문자열의 일부로 지정해야 합니다. Developer 2000 응용 프로그램을 끝내면 ODBC 데이터 원본에 대한 OCA 연결이 끊어집니다.

로그온 연결 문자열에 대한 구문이 아래 예제에 나와 있습니다. 이 예제에서, 사용자는 SQL Server STUDENT_ADMIN 계정에 로그온합니다. SQL Server ODBC 데이터 원본의 이름은 STUDENT_DATA입니다.

STUDENT_ADMIN/STUDENT_ADMIN@ODBC:STUDENT_DATA

ODBC 드라이버를 사용해도 Developer 2000 응용 프로그램이 SQL Server와 올바르게 동작한다는 보장은 없습니다. 비 Oracle 데이터 원본과 함께 동작하게 하려면 응용 프로그램 코드를 수정해야 합니다. 예를 들어, 열 보안 속성은 Oracle에만 적용되고 SQL Server에는 적용되지 않습니다.

데이터의 각 행을 식별하는 데 사용되는 키 모드를 변경해야 합니다. Oracle을 데이터 원본으로 사용하면 각 행을 식별하는 데 ROWID가 사용됩니다. SQL Server를 사용할 때는 고유한 행 값을 제공하기 위해 고유한 기본 키 값을 사용해야 합니다.

잠금 모드 또한 바꿔야 합니다. Oracle을 사용할 때 Developer 2000은 데이터 행이 변경되는 즉시 그 행을 잠그려 합니다. SQL Server를 사용할 때는 데이터베이스에 쓰일 때만 레코드가 잠기도록 잠금 모드를 지연 상태로 설정해야 합니다.

테이블에 대한 여러 삽입이 PL/SQL 프로그램 블록의 동일 데이터 페이지에 액세스할 때 발생할 수 있는 교착 상태를 포함하여 해결해야 할 다른 문제들이 많이 있습니다. 자세한 내용은 이 장의 앞부분에 나오는 "트랜잭션, 잠금 및 동시성"을 참조하십시오.

Microsoft SQL Server에는 SQL Server 데이터에서 표준 HTML 파일을 만드는 SQL Server 웹 길잡이 마법사가 제공됩니다. 이 마법사는 주기적으로 업데이트되어 정적 상태를 유지하도록 하거나 데이터가 업데이트될 때 업데이트되도록 웹 페이지를 구성할 수 있습니다. 이 마법사가 웹 페이지를 만드는 전과정을 안내합니다.

데이터베이스 예제

이 장 전체에 걸쳐 참조되는 예제 프로그램 응용 및 코드를 지원하기 위해 대학교 RDBMS 응용 프로그램 예제를 개발했습니다. 이 응용 프로그램은 Oracle 7 응용 프로그램을 SQL Server 7.0 응용 프로그램으로 변환하는 데 따른 많은 관련 사항, 문제 및 해결 요령을 보여 주기 위해 작성한 것입니다.

이 예제 응용 프로그램은 학내의 모든 활동을 추적하기 위해 4개의 테이블을 사용합니다. DEPT 테이블은 학교 내의 학과를 추적하는 데 사용됩니다. CLASS 테이블은 각 학과 내의 수업을 추적하는 데 사용됩니다. STUDENT 테이블은 학교 내의 각 학생을 추적하는 데 사용됩니다. GRADE 테이블은 각 수업에 등록한 각 학생을 추적하는 데 사용됩니다.

이 예제 응용 프로그램에서는 주민 등록 번호(ssn)가 STUDENT 테이블의 기본 키로 사용됩니다. DEPT 테이블은 학과 코드(dept)를 기본 키로 사용하고 CLASS 테이블은 강의 코드(ccode)를 기본 키로 사용합니다. 주민 등록 번호(ssn)와 강의 코드(ccode)의 조합이 GRADE 테이블의 기본 키가 됩니다.

전공 열은 STUDENT 테이블에 외래 키로 정의됩니다. 학생들은 전공을 선택할 때 DEPT 테이블에서 유효한 학과 코드(dept)를 선택해야 합니다. CLASS 테이블의 학과(dept) 열 또한 외래 키로 정의됩니다. 이 테이블에 삽입하는 강의를 DEPT 테이블의 유효한 학과(dept)와 연결해야 합니다.

GRADE 테이블에는 두 개의 외래 키가 있습니다. 수업에 학생을 등록할 때는 STUDENT 테이블에 주민 등록 번호(ssn)가 있어야 하고 CLASS 테이블에 강의 코드(ccode)가 있어야 합니다. 그래야만 존재하지 않는 학급에 학생이 등록되는 일이 없고 존재하지 않는 학생이 학급에 포함되는 일이 없습니다.

이 장 전체에 걸쳐 아래 예제 응용 프로그램이 참조됩니다.

• Orademo.cpp

  Oracle 7.3 데이터베이스의 예제 대학교 테이블에 액세스하는 Oracle ODBC 응용 프로그램입니다. 이 프로그램은 변환 프로세스가 시작되는 곳입니다. 사용자들은 이 프로그램을 사용하여 데이터를 입력하고 예제 대학교 응용 프로그램에 대한 리포트를 작성할 수 있습니다.

• Ssdemo.cpp

  ODBC를 사용하여 작성한 SQL Server 응용 프로그램입니다. 이 프로그램은 변환 프로세스가 끝나는 곳입니다. 모든 Oracle SQL 명령, 프로시저, 패키지 및 함수가 SQL Server Transact-SQL 문과 프로시저로 변환되었습니다. SQL Server 7.0과 관련된 많은 이점이 이 프로그램에 나타나 있습니다.

• Common.cpp

  Oracle과 SQL Server 모두에서 잘 동작하는 ODBC 응용 프로그램입니다. 사용자들은 Oracle이나 SQL Server에 연결할 때 ODBC 데이터 원본 이름(DSN)만 제공하면 됩니다. 그러면 이 프로그램이 요청된 RDBMS에 로그온합니다. 이 프로그램에는 다중 RDBMS 프로그램을 개발할 때 사용할 수 있는 우수한 프로그래밍 기법 예제들이 나와 있습니다.

• Orauser.sql

  예제 Oracle 프로그램에 필요한 데이터베이스 사용자 계정과 데이터베이스 역할을 만듭니다.

• Oratable.sql

  예제 Oracle 프로그램에 필요한 테이블과 뷰를 만듭니다.

• Oraproc.sql

  예제 Oracle 프로그램에 필요한 Oracle 저장 프로시저, 함수 및 패키지를 만듭니다.

• Oracommn.sql

  Common.cpp 프로그램을 지원하는 데 필요한 모든 추가 Oracle 데이터베이스 개체를 만듭니다.

• Oradata.sql

  예제 Oracle 프로그램에 필요한 예제 응용 프로그램 데이터를 테이블로 로드합니다.

• Ssuser.sql

  예제 SQL Server 프로그램에 필요한 SQL Server 사용자 계정 및 데이터베이스 역할을 만듭니다.

• Sstable.sql

  예제 SQL Server 프로그램에 필요한 SQL Server 테이블과 뷰를 만듭니다.

• Ssproc.sql

  예제 SQL Server 프로그램에 필요한 저장 프로시저를 만듭니다.

• Sscommon.sql

  Common.cpp 응용 프로그램을 지원하는 데 필요한 모든 추가 SQL Server 데이터베이스 개체를 만듭니다.

• Ssdata.sql

  예제 SQL Server 프로그램에 필요한 예제 응용 프로그램 데이터를 테이블로 로드합니다.

대상 RDBMS 플랫폼에 예제 응용 프로그램을 만들기 위해 예제 스크립트를 아래 순서대로 실행해야 합니다.

SQL Server 데이터베이스에 대해 이러한 스크립트를 실행하기 전에, 이들 스크립트와 예제 SQL Server 프로그램이 동작하도록 USER_DB라는 응용 데이터베이스를 만들어야 합니다. 이 데이터베이스는 SQL Server 엔터프라이즈 관리자나 Transact-SQL CREATE DATABASE 문을 사용하여 만들 수 있습니다. 데이터베이스를 만든 후, SQL Server 7.0에 시스템 관리자(sa SQL Server 사용자 또는 sysadmin 고정 서버 역할의 구성원)로 로그인하고 SQL Server 쿼리 분석기를 사용하여 지정된 순서대로 이들 스크립트를 실행합니다.

Oracle 7.3 데이터베이스에 대해 이러한 스크립트를 실행하기 전에, 예제 스크립트는 USER_DATA 및 TEMPORARY_DATA 테이블 공간이 존재한다고 가정합니다. 이들은 보통 기본 Oracle 7.3 데이터베이스 설치 중에 만들어집니다. 이러한 테이블 공간이 없으면 이들을 추가하거나 제공된 예제 스크립트를 수정하여 다른 테이블 공간을 사용해야 합니다.

이러한 테이블 공간이 있는지 확인한 후 SYSTEM 계정을 사용하여 SQL*Plus에 로그온합니다. 암호가 기본값인 MANAGER가 아닌 경우 Oracle SQL 스크립트의 암호를 변경합니다.

이 응용 프로그램에 대해 아래와 같은 3개의 사용자 계정이 만들어집니다.

• STUDENT_ADMIN

  이 계정은 STUDENT 및 GRADE 테이블의 관리 소유자입니다.

• DEPT_ADMIN

  이 계정은 DEPT 및 CLASS 테이블의 관리 소유자입니다.

• ENDUSER1

  이 계정은 STUDENT, GRADE, DEPT 및 CLASS 테이블에 액세스할 수 있는 쿼리 전용 계정입니다.