Oracle에서 SQL Server로 및 SQL Server에서 Oracle로 마이그레이션 가이드 - Pt. 삼

이 시리즈의 첫 번째 부분과 두 번째 부분에서는 트랜잭션 구현에 있어 Oracle Database와 Microsoft SQL Server 간의 차이점, 그로 인한 변환 함정, 일반적으로 사용되는 일부 구문 요소에 대해 설명했습니다.

이 마지막 기사에서는 Oracle 읽기 일관성의 개념과 이 개념을 기반으로 아키텍처를 Microsoft SQL Server 버전으로 변환하는 방법을 다룹니다. 또한 동의어의 사용(및 동의어를 사용하지 않는 방법)과 데이터베이스 환경 관리에서 변경 제어 프로세스의 역할에 대해서도 설명합니다.

Oracle 읽기 일관성 및 SQL Server에서 이에 상응하는 기능

Oracle 읽기 일관성은 단일 SQL 문에서 반환된 모든 데이터가 동일한 단일 시점에서 온다는 것을 보장합니다.

12:01:02.345에 SELECT 문을 실행하고 결과 집합을 반환하기 전에 5분 동안 실행한 경우 12:01:02.345를 기준으로 데이터베이스에 커밋된 모든 데이터(데이터만 포함)가 반환 세트에. 데이터베이스가 명령문을 처리하는 데 걸린 5분 동안 반환 세트에 추가된 새 데이터나 업데이트가 없으며 삭제가 표시되지 않습니다.

Oracle 아키텍처는 데이터에 대한 모든 변경 사항을 내부적으로 타임 스탬프하고 영구 데이터 파일과 실행 취소 세그먼트(또는 버전 10g까지 알려진 "롤백 세그먼트")의 두 소스에서 결과 집합을 구축하여 읽기 일관성을 달성합니다.

이를 지원하기 위해서는 실행 취소 정보를 보존해야 합니다. 덮어쓰면 악명 높은 ORA-01555: snapshot too old 오류가 발생합니다.

실행 취소 세그먼트 관리와 ORA-01555: snapshot too old error 탐색 방법은 제쳐두고 읽기 일관성이 Oracle의 실제 구현에 미치는 영향을 살펴보겠습니다. 또한 다른 RDBMS 구현의 경우와 마찬가지로 PostgreSQL을 제외하고는 지원하지 않는 SQL Server에서 미러링해야 합니까?

핵심은 Oracle 읽기 및 쓰기가 서로를 차단하지 않는다는 것입니다. 또한 장기 실행 쿼리 반환 집합에 최신 데이터가 없을 수 있음을 의미합니다.

비차단 읽기 및 쓰기는 Oracle의 장점이며 트랜잭션 범위 지정에 영향을 줍니다.

그러나 읽기 일관성은 데이터의 최신 상태가 없음을 의미하기도 합니다. 특정 시간에 대한 보고서를 생성하는 것과 같이 일부 시나리오에서는 완벽하지만 다른 시나리오에서는 심각한 문제를 일으킬 수 있습니다.

"더러운" 데이터 또는 커밋되지 않은 최신 데이터가 없는 것이 중요할 수 있습니다. 고전적인 시나리오는 호텔 객실 예약 시스템입니다.

다음 사용 사례를 고려하십시오. 두 명의 고객 서비스 상담원이 동시에 객실 예약 주문을 수락하고 있습니다. 객실이 초과 예약되지 않도록 하려면 어떻게 해야 합니까?

SELECT Server에서는 명시적 트랜잭션을 시작하고 사용 가능한 방의 목록(테이블 또는 보기일 수 있음)에서 레코드를 선택할 수 있습니다. 이 트랜잭션이 닫히지 않는 한( COMMIT 또는 ROLLBACK 에 의해) 아무도 선택한 동일한 방 레코드를 얻을 수 없습니다. 이는 이중 예약을 방지할 뿐만 아니라 다른 모든 에이전트가 서로가 예약 요청을 한 번에 하나씩 순차적으로 완료할 때까지 기다리게 합니다.

Oracle에서는 검색 기준과 일치하는 레코드에 대해 SELECT ... FOR UPDATE 문을 실행하여 동일한 결과를 얻을 수 있습니다.

참고: 방에 대한 액세스를 맹목적으로 잠그는 대신 "고려 중인" 방을 표시하는 임시 플래그를 설정하는 것과 같은 더 나은 솔루션이 있습니다. 그러나 이는 언어 옵션이 아니라 아키텍처 솔루션입니다.

결론 : Oracle 읽기 일관성은 "모두 좋음" 또는 "모두 나쁨"이 아니라 잘 이해해야 하고 플랫폼 간 코드 마이그레이션에 중요한 플랫폼의 중요한 속성입니다.

Oracle 및 Microsoft SQL Server의 공용(및 개인) 동의어

"공중 동의어는 사악하다." 내 개인적인 발견은 아니지만, 내 날, 주, 연도가 공개 동의어에 의해 저장될 때까지 나는 그것을 복음으로 받아들였습니다.

많은 데이터베이스 환경에서 작업할 기회가 있었지만 내가 설계한 Oracle 환경은 아무 것도 없었습니다. 모든 개체에 대해 CREATE PUBLIC SYNONYM 을 사용하는 것은 "항상 그렇게 해왔기 때문에" 일상적인 작업이었습니다.

이러한 환경에서 공용 동의어는 소유자를 지정하지 않고 객체에 대한 참조를 허용하는 단 하나의 기능만 가지고 있었습니다. 그리고 이것은 공개 동의어를 만드는 제대로 생각되지 않은 이유 중 하나입니다.

그러나 Oracle 공개 동의어는 매우 유용할 수 있으며 올바로 구현 및 관리되는 경우 모든 단점을 훨씬 능가하는 팀 생산성 이점을 제공할 수 있습니다. 네, 저는 "팀 생산성"이라고 말했습니다. 하지만 어떻게? 이를 위해 Oracle에서 이름 확인이 작동하는 방식을 이해해야 합니다.

Oracle 파서는 이름(예약되지 않은 키워드)을 찾을 때 다음 순서로 기존 데이터베이스 개체와 일치시키려고 시도합니다.

참고: 발생하는 오류는 ORA-00942: table or view does not exist . 또는 PLS-00201: identifier 'my_object' must be declared .

이 이름 확인 순서에서 개발자가 자체 스키마에서 작업할 때 공용 동의어와 동일한 이름을 가진 모든 로컬 개체가 이 공용 동의어를 숨긴다 는 것을 쉽게 알 수 있습니다. (참고: Oracle 18c는 "로그인 전용" 스키마 유형을 구현했으며 이 논의는 이에 적용되지 않습니다.)

확장 팀에 대한 공개 동의어: Oracle Change Control

이제 동일한 데이터베이스에서 작업하는 100명의 개발자로 구성된 가상 팀을 살펴보겠습니다(이는 제가 경험한 것입니다). 또한 그들이 모두 개인 워크스테이션에서 로컬로 작업하고 데이터베이스가 아닌 빌드를 독립적으로 수행하고 모두 동일한 데이터베이스 개발 환경에 연결되어 있다고 가정해 보겠습니다. 데이터베이스가 아닌 코드(C#, Java, C++, Python 또는 기타)의 코드 병합 해결은 변경 제어 체크인 시간에 수행되며 다음 코드 빌드에 적용됩니다. 그러나 데이터베이스 테이블, 코드 및 데이터는 개발이 진행되는 동안 여러 번 앞뒤로 변경해야 합니다. 각 개발자는 이 작업을 독립적으로 수행하며 즉시 적용됩니다.

이를 위해 모든 데이터베이스 개체는 공통 응용 프로그램 스키마에서 생성됩니다. 애플리케이션이 참조 하는 스키마입니다. 각 개발자:

• 개인 사용자 계정/스키마로 데이터베이스에 연결
• 항상 비어 있는 개인 스키마로 시작합니다.
• 위에서 설명한 대로 공용 동의어에 대한 이름 확인을 통해서만 공통 스키마를 참조합니다.

개발자가 데이터베이스를 변경해야 하는 경우 (테이블 생성 또는 변경, 절차 코드 변경, 일부 테스트 시나리오를 지원하기 위해 데이터 세트 수정) 개인 스키마에 개체 복사본을 만듭니다. DESCRIBE 명령을 사용하여 DDL 코드를 가져오고 로컬에서 실행하여 이를 수행합니다.

이 순간부터 이 개발자의 코드는 다른 사람이 볼 수 없거나 영향을 미치지 않는 로컬 버전의 개체 및 데이터를 보게 됩니다. 개발이 완료되면 수정된 데이터베이스 코드를 소스 컨트롤에 체크인하고 충돌을 해결합니다. 그런 다음 최종 코드(필요한 경우 데이터)가 공통 스키마에서 구현됩니다.

그런 다음 전체 개발 팀이 동일한 데이터베이스를 다시 볼 수 있습니다. 방금 코드를 전달한 개발자는 개인 스키마에서 모든 개체를 삭제하고 새 할당을 받을 준비가 되었습니다.

여러 개발자를 위한 독립적인 병렬 작업을 용이하게 하는 이 기능은 공개 동의어의 주요 이점이며 과장하기 어려운 중요성입니다. 그러나 실제로는 "항상 그렇게 하기 때문에" Oracle 구현에서 공개 동의어를 생성하는 팀을 계속 보게 됩니다. 대조적으로, SQL Server를 사용하는 팀에서는 공용 동의어 생성이 일반적인 관행으로 확립되어 있지 않다고 봅니다. 기능이 있지만 자주 사용되지는 않습니다.

SQL Server에서 사용자의 현재 기본 스키마는 사용자 구성에 정의되어 있으며 "사용자 변경" 권한이 있는 경우 언제든지 변경할 수 있습니다. Oracle에 대해 위에서 설명한 것과 동일한 정확한 방법론을 구현할 수 있습니다. 그러나 이 방법을 사용하지 않는 경우 공용 동의어를 복사해서는 안 됩니다.

Microsoft SQL Server는 기본적으로 새 사용자 계정을 자체 스키마와 연결하지 않으므로(Oracle이 하는 것처럼) 연결은 표준 "사용자 생성" 스크립트의 일부여야 합니다.

다음은 전용 사용자 스키마를 생성하고 이를 사용자에게 할당하는 스크립트의 예입니다.

먼저 DevelopmentDatabase 라는 데이터베이스에 등록해야 하는 새 사용자에 대한 스키마를 만듭니다(각 스키마는 자체 배치에서 만들어야 함).

 use DevelopmentDatabase; GO CREATE SCHEMA Dev1; GO CREATE SCHEMA Dev2; GO

둘째, 할당된 기본 스키마를 사용하여 첫 번째 사용자를 만듭니다.

 CREATE LOGIN DevLogin123 WITH PASSWORD = 'first_pass123'; CREATE USER Dev1 FOR LOGIN DevLogin123 WITH DEFAULT_SCHEMA = Dev1; GO

이 시점에서 사용자 Dev1 의 기본 스키마는 Dev1 입니다.

다음으로 기본 스키마가 없는 다른 사용자를 만듭니다.

 CREATE LOGIN DevLogin321 WITH PASSWORD = 'second_pass321'; CREATE USER Dev2 FOR LOGIN DevLogin321; GO

사용자 Dev2 의 기본 스키마는 dbo 입니다.

이제 사용자 Dev2 를 변경하여 기본 스키마를 Dev2 로 변경합니다.

 ALTER USER Dev2 WITH DEFAULT_SCHEMA = Dev2; GO

이제 사용자 Dev2 의 기본 스키마는 Dev2 입니다.

이 스크립트는 Microsoft SQL Server 데이터베이스에서 사용자의 기본 스키마를 할당하고 변경하는 두 가지 방법을 보여줍니다. SQL Server는 여러 사용자 인증 방법(가장 일반적인 Windows 인증)을 지원하고 사용자 온보딩은 DBA가 아닌 시스템 관리자가 처리할 수 있으므로 기본 스키마를 할당/변경하는 ALTER USER 방법이 더 유용할 것입니다.

참고: 스키마 이름을 사용자 이름과 동일하게 만들었습니다. SQL Server에서는 이 방식일 필요는 없지만 (1) Oracle에서 수행되는 방식과 일치하고 (2) 사용자 관리를 단순화하기 때문에 선호합니다 처음에)—사용자의 이름을 알고 있고 자동으로 사용자의 기본 스키마를 알고 있습니다.

결론 : 공용 동의어는 안정적이고 잘 보호된 다중 사용자 개발 환경을 구축하기 위한 중요한 도구입니다. 불행히도 업계에서 관찰한 결과 잘못된 이유로 더 자주 사용됩니다. 팀은 이점을 깨닫지 못한 채 공개 동의어의 혼란과 기타 단점을 겪고 있습니다. 이 관행을 변경하여 공개 동의어에서 실질적인 이점을 얻으면 팀의 개발 워크플로에 실질적인 이점을 가져올 수 있습니다.

데이터베이스 액세스 관리 및 변경 관리 프로세스

대규모 팀의 병렬 개발 지원에 대해 방금 이야기했듯이 변경 제어 프로세스라는 별도의 자주 오해되는 주제를 다룰 가치가 있습니다.

변경 관리는 "어제"가 아니라 "지금"이 아니면 모든 것을 제공하고자 하는 반항적인 개발자들이 경멸하는 팀장과 DBA가 통제하는 일종의 형식적인 형식이 되는 경우가 많습니다.

DBA로서 저는 항상 "내" 데이터베이스에 보호 장벽을 설치했습니다. 이에 대한 아주 좋은 이유가 있습니다. 데이터베이스는 공유 리소스입니다.

트위터

소스 제어 컨텍스트에서 변경 관리는 일반적으로 팀이 새롭지만 손상된 코드에서 오래되었지만 작동하는 코드로 되돌릴 수 있도록 허용하기 때문에 허용됩니다. 그러나 데이터베이스 컨텍스트에서 변경 관리는 DBA가 설정한 일련의 불합리한 장벽과 제한처럼 보일 수 있습니다. 개발 속도를 불필요하게 늦추는 것은 순수한 광기입니다!

이 개발자의 호언장담은 잠시 접어두자. 나는 DBA이고 나 자신에게 돌을 던지지 않을 것입니다! DBA로서 저는 항상 "내" 데이터베이스에 보호 장벽을 설치합니다. 이에 대한 아주 좋은 이유가 있습니다. 데이터베이스는 공유 리소스입니다.

모든 개발 팀과 각 개발자는 매우 구체적으로 정의된 목표와 매우 구체적인 결과물을 가지고 있습니다. 매일 DBA의 책상 위에 있는 유일한 목표는 공유 리소스로서의 데이터베이스의 안정성입니다. DBA는 조직에서 모든 팀의 모든 개발 노력을 감독하고 모든 개발자가 액세스하는 데이터베이스를 제어하는 ​​고유한 역할을 합니다. 모든 프로젝트와 모든 프로세스가 서로 간섭하지 않고 실행되고 있고 각각이 작동하는 데 필요한 리소스가 있는지 확인하는 것은 DBA입니다.

문제는 개발 팀과 DBA 팀이 각자의 상아탑에 갇혀 있을 때입니다.

개발자는 데이터베이스가 제대로 실행되는 한 데이터베이스에서 어떤 일이 발생하는지 모르고, 액세스할 수 없으며, 신경도 쓰지 않습니다. (그것은 그들의 결과물이 아니며 그들의 성과 평가에도 영향을 미치지 않습니다.)

DBA 팀은 데이터베이스를 가슴 가까이에 두고 "아무것도 모르는" 개발자로부터 데이터베이스를 보호합니다. 팀 목표는 데이터베이스 안정성이기 때문입니다. 그리고 안정성을 보장하는 가장 좋은 방법은 파괴적인 변경을 방지하는 것입니다. 이는 종종 가능한 한 변경으로부터 데이터베이스를 보호하는 태도로 이어집니다.

내가 본 것처럼 데이터베이스에 대한 이러한 상충되는 태도는 개발 팀과 DBA 팀 사이에 적대감을 불러일으키고 작업할 수 없는 환경을 초래할 수 있습니다. 그러나 DBA와 개발 팀은 공통의 목표를 달성하기 위해 함께 협력해야 합니다. 즉, 처음부터 그들을 하나로 모은 비즈니스 솔루션을 제공하는 것입니다.

개발자와 DBA 사이에 양쪽 모두가 있었기 때문에 DBA가 개발 팀의 공통 작업과 목표를 더 잘 이해할 때 문제를 쉽게 해결할 수 있다는 것을 알고 있습니다. 한편 개발자는 데이터베이스를 추상적인 개념이 아니라 공유 리소스로 보아야 하며, 거기에서 DBA는 교육자의 역할을 맡아야 합니다.

개발자가 아닌 DBA가 범하는 가장 일반적인 오류는 데이터 사전 및 코드 최적화 도구에 대한 개발자 액세스를 제한하는 것입니다. Oracle DBA_ 카탈로그 뷰, 동적 V$ 뷰 및 SYS 테이블에 대한 액세스는 실제로 중요한 개발 도구임에도 불구하고 많은 DBA에게 "DBA 권한이 있는" 것처럼 보입니다.

SQL Server도 마찬가지지만 한 가지 복잡한 문제가 있습니다. 일부 시스템 보기에 대한 액세스 권한은 직접 부여할 수 없지만 이는 SYSADMIN 데이터베이스 역할의 일부일 뿐이며 이 역할은 DBA 팀 외부에서 부여되어서는 안 됩니다. 이 문제는 SYSADMIN 권한으로 실행되지만 DBA가 아닌 사용자가 액세스할 수 있는 뷰와 저장 프로시저를 생성하여 해결할 수 있습니다(프로젝트를 Oracle에서 SQL Server로 마이그레이션하는 경우 해결해야 함). 이것은 새로운 SQL Server 개발 환경이 구성됨에 따라 개발 DBA가 하는 일입니다.

데이터 보호는 DBA의 주요 책임 중 하나입니다. 그럼에도 불구하고 개발 팀이 데이터 관련 티켓 문제 해결을 위해 필터링되지 않은 프로덕션 데이터에 대한 전체 액세스 권한을 갖는 것은 매우 일반적입니다. 이들은 데이터 구조, 즉 그들에 의해 또는 그들을 위해 생성된 구조에 대한 액세스가 제한된 동일한 개발자입니다.

개발 팀과 DBA 팀 사이에 적절한 작업 관계가 설정되면 좋은 변경 제어 프로세스를 만드는 것이 직관적이 됩니다. 데이터베이스 측 변경 관리의 특성과 과제는 데이터베이스의 경직성과 유동성을 동시에 갖는 것입니다. 구조는 경직되고 데이터는 유동적입니다.

데이터 정의 언어 또는 DDL과 같은 구조 수정에 대한 변경 관리는 잘 확립되어 있는 반면 데이터 변경은 변경 관리 방식에 거의 또는 전혀 없는 경우가 종종 있습니다. 정당화는 간단합니다. 데이터는 항상 변경됩니다.

그러나 이것을 더 자세히 살펴보면 모든 시스템에서 모든 데이터가 애플리케이션 데이터와 사용자 데이터의 두 가지 범주 중 하나로 분류된다는 것을 알 수 있습니다.

응용 프로그램 데이터 는 응용 프로그램의 동작을 정의하는 데이터 사전이며 모든 응용 프로그램 코드만큼 해당 프로세스에 중요합니다. 이 데이터에 대한 변경은 다른 애플리케이션 변경과 마찬가지로 엄격한 변경 제어 프로세스를 거쳐야 합니다. 애플리케이션 데이터 변경에 대한 변경 제어 프로세스의 투명성을 생성하려면 애플리케이션 데이터와 사용자 데이터를 명시적으로 분리해야 합니다.

Oracle에서는 응용 프로그램 및 사용자 데이터를 각각 고유한 스키마에 배치하여 수행해야 합니다. Microsoft SQL Server에서는 각각을 별도의 스키마 또는 훨씬 더 나은 방법으로 별도의 데이터베이스에 배치하여 수행해야 합니다. 이러한 선택은 마이그레이션 계획의 일부여야 합니다. Oracle에는 2단계 이름 확인(스키마/소유자 – 개체 이름)이 있는 반면 SQL Server에는 3단계 이름 확인(데이터베이스 – 스키마/소유자 – 개체 이름)이 있습니다.

응용 프로그램과 사용자 데이터를 올바르게 분리하면 DBA 팀이 두 번째로 중요한 문제인 사용자 데이터 보안을 해결할 수 있습니다. 사용자 데이터가 별도로 상주하므로 필요에 따라 사용자 데이터 액세스를 위한 Break Glass 절차를 구현하는 것은 매우 간단합니다.

결론 : 변경 제어 프로세스는 모든 프로젝트에서 중요합니다. 소프트웨어 엔지니어링에서 데이터베이스 측의 변경 관리는 데이터가 "너무 유동적"인 것으로 보이기 때문에 종종 무시됩니다. 그러나 데이터가 "유동적"인 동시에 "영구적"이기 때문에 잘 설계된 변경 제어 프로세스가 적절한 데이터베이스 환경 아키텍처의 초석이 되어야 합니다.

코드 마이그레이션 도구 사용에 대해

표준 자사 도구인 Oracle Migration Workbench 및 SQL Server Migration Assistant는 코드 마이그레이션에 도움이 될 수 있습니다. 그러나 고려해야 할 사항은 80/20 규칙입니다. 코드가 80% 올바르게 마이그레이션되면 나머지 20%를 해결하는 데 마이그레이션 노력의 80%가 소요됩니다.

마이그레이션 도구 사용의 가장 큰 위험은 단연코 "은색 총알"이라는 인식입니다. 어떤 사람은 "그것은 일을 할 것이고 나는 단지 약간의 정리와 정리를 해야 할 것입니다."라고 생각하고 싶은 유혹을 받을 수 있습니다. 그런 태도로 인해 실패한 프로젝트를 컨버전팀과 기술리더로부터 목격했습니다.

반면에 Notepad++의 대량 교체 기능을 주 편집 도구로 사용하여 중형 Microsoft SQL Server 2008 시스템(약 200개 개체)의 기본 변환을 수행하는 데 4영업일이 걸렸습니다.

지금까지 내가 다룬 중요한 마이그레이션 요소 중 어느 것도 마이그레이션 도구로 해결할 수 없습니다.

물론 마이그레이션 지원 도구를 사용하지만 이는 편집 지원만 제공한다는 점을 기억하십시오. 결과 출력 텍스트는 프로덕션 가치가 있는 코드가 되기 위해 검토, 수정 및 일부 경우 다시 작성해야 합니다.

인공 지능 도구의 개발은 미래에 이러한 마이그레이션 도구 결함을 해결할 수 있지만 그 전에는 데이터베이스 간의 차이가 흐려지고 마이그레이션 프로세스 자체가 불필요해질 것으로 예상합니다. 따라서 이러한 유형의 프로젝트가 필요한 한 우리는 구식 인간 지능을 사용하여 예전 방식으로 수행해야 합니다.

결론 : 마이그레이션 지원 도구를 사용하는 것이 도움이 되지만 "은상"이 아니며 모든 변환 프로젝트에는 여전히 위의 사항에 대한 자세한 검토가 필요합니다.

Oracle/SQL Server 마이그레이션: 항상 자세히 살펴보기

Oracle과 Microsoft SQL Server는 엔터프라이즈 환경에서 가장 많이 보급된 두 가지 RDBMS 플랫폼입니다. 둘 다 ANSI SQL 표준을 기본적으로 준수하며, 코드의 작은 부분은 수정을 거의 하지 않거나 있는 그대로 이동할 수 있습니다.

이러한 유사성은 두 플랫폼 간의 마이그레이션이 간단하고 간단한 작업이며 한 RDBMS 백엔드를 사용하여 다른 RDBMS 백엔드로 동일한 애플리케이션을 쉽게 채택할 수 있다는 기만적인 인상을 줍니다.

실제로 이러한 플랫폼 마이그레이션은 결코 사소한 일이 아니며 각 플랫폼 내부 작동의 미세한 요소와 무엇보다 데이터 관리의 가장 중요한 요소인 트랜잭션에 대한 지원을 구현하는 방식을 고려해야 합니다.

내 전문 지식의 핵심인 두 개의 RDBMS 플랫폼에 대해 다루었지만 "비슷해 보인다고 해서 똑같이 작동하는 것은 아닙니다."라는 동일한 경고가 다른 SQL 호환 데이터베이스 관리 시스템 간에 코드를 이동하는 데 적용되어야 합니다. 그리고 모든 경우에 가장 먼저 주의해야 할 점은 트랜잭션 관리 구현이 소스 플랫폼과 대상 플랫폼 간에 어떻게 다른지에 대한 것입니다.