개발자에서 엔터프라이즈까지는 괜찮을 것입니다. 프로세서 라이센스를 사용하는 경우 대상 서버에 모든 CPU를 포괄 할 수있는 라이센스가 있는지 확인하십시오. 그리고 SQL에서 숨기는 것만으로는 충분하지 않습니다. 물리적으로 컴퓨터에 연결되어 있다면 책임이 있습니다.
또한 더 낮은 빌드에서 더 높은 빌드로 갈 때 데이터베이스 버전이 증가합니다. 문제가 될 수있는 몇 가지 시나리오가 있습니다. 예를 들어 특정 2008 빌드에서 15,000 개의 파티션 지원을 사용하는 경우 2008 R2의 특정 빌드로 업그레이드 할 때 작동하지 않습니다. 또한 이전 빌드에서는 실제로 버그이지만 새 빌드에서는 수정 된 최적화에 의존 할 수 있으며 (해결 방법이 준비되어 있음) 성능이 저하 될 수 있습니다. 또한 소스에서 사용중인 추적 플래그를 검토하고 대상에서도 활성화해야하는지 결정해야합니다. 작업, 로그인 등을 신경 쓰지 마십시오.
물론 뒤로 갈 수는 없습니다. 나는 10.0.5512-> 10.0.5500과 같은 사소한 다운 그레이드를 시도한 적이 없지만 서비스 팩이나 버전에서 다운 될 수는 없습니다. 따라서 Developer Edition 인스턴스에 2012 데이터베이스가 있고 프로덕션 환경의 2008 인스턴스에 배치하려는 경우, 특히 2012 기능을 사용한 경우 작업이 잘릴 수 있습니다 ( 여기 및 여기 참조 ). .
그러나이 질문에 사람들을 착륙시킬 수있는 다른 경우를 다루기 위해 (예를 들어 누군가가 개발자-> 표준 또는 엔터프라이즈-> Express에서 가고 싶거나)
Express에서 지원되지 않는 기능을 사용한 경우 (예 : Enterprise 이외의 다른 버전에서도 동일하게 적용되는 경우) Developer-> Express 등의 다른 에디션-> 에디션 업그레이드가 있습니다. 하위 버전에서 사용할 수없는 기능의 일부 예 (이 경우 데이터베이스를 온라인 상태로 만들려고 시도 할 때 복원이 종료 됨) :
- 파티셔닝
- 데이터 캡처 변경
- 데이터 압축
- 투명한 데이터 암호화
.BAK 파일에서 직접 이것을 알 수있는 방법이 있는지 모르겠습니다 (어딘가에 페이지 헤더에서 추출 할 수있는 마술이 있거나 16 진수 편집기로 구울 주말이 있다면) 하지만 소스 인스턴스에서 데이터베이스는 그대로 유지하면서 항상 다음을 수행하여 사용중인 SKU로 인해 사용 가능한 기능을 사용하고 있는지 확인할 수 있습니다.
SELECT feature_name FROM sys.dm_db_persisted_sku_features;
SQL Server Audit가 해당 목록에 있어야하는지 잘 모르겠습니다. 해당 기능의 에디션 독점 성이 변경되었으므로 사용중인 작업에 따라 달라질 수 있습니다. 사용 중이지만 DMV에 표시되지 않는 다른 사항이 있습니다 (일부는 DMV에서 구문 분석하지 않는 코드에 있고 일부는 데이터베이스가 SQL Server 에이전트와 같은 외부 항목에 의존하기 때문에 DMV에 표시되지 않음) , Service Broker 등) :
- 미러링
- 특정 형태의 복제
- 로그 배송
- 데이터베이스 스냅 샷
- 온라인 인덱싱
- 업데이트 가능한 분산 분할 뷰
- 백업 압축
- 정책 기반 관리
- 계획 가이드
- 데이터베이스 메일
- 유지 보수 계획
- 전문 검색
파일 크기 제한으로 인해 Developer에서 Express로 이동할 수없는 경우도 있습니다 (Express 데이터베이스는 총 데이터 파일 크기가 10GB로 제한됨).
물론 경고하지 않을 다른 문제가있을 수 있습니다. 마이그레이션을 방해하지는 않지만 대상에서 성능이 크게 다를 수 있습니다. 예 :
- 대상 에디션 (또는 대상의 기본 운영 체제)에 대한 다른 메모리 / CPU 제한 2008 R2 Enterprise에서 2012 Enterprise (CAL)로 갔다가 서비스를 인위적으로 처음 20 개 코어로 제한 한 많은 사람들이 있습니다). 이로 인해 직접적인 성능 차이가 발생할 수 있습니다 (예를 들어, 쿼리를 만족시키기에 메모리가 부족하거나 병렬 쿼리 성능이 훨씬 느림). 더 미묘한 것에는 다른 기본 하드웨어로 인해 계획 선택이 포함됩니다.
- 소스에서 인덱스 된 뷰 일치와 같은 기능에 대한 의존은 사용할 소스 코드를 변경하지 않고 대상에서 자동으로 존중되지 않습니다
NOEXPAND. 또한이 기능으로 인해 쿼리 속도가 갑자기 느려지는 것을 알지 못할 수도 있습니다.
- 병렬 인덱스 작업과 아마도이 순간에 염두에 두지 않을 다른 최적화의 경우도 마찬가지입니다 (감사하게도 거의 엔터프라이즈 공간에서만 작업하므로 대부분의 경우 하위 버전의 한계에 대해 걱정할 필요가 없습니다) ).
이 복제본을 기반으로 업데이트 :
특정 버전에서 더 낮은 버전으로 (같은 버전에서도) 데이터베이스를 복원하려고 할 때 도움이되지 않는 오류가 발생하는 경우가 있습니다 .
서버 'server \ instance'에 대한 복원에 실패했습니다.
RESTORE가 'databasename'데이터베이스를 시작할 수 없습니다.
이것은 매우 직관적이지 않습니다. 그러나 SQL Server의 이벤트 로그를 자세히 살펴보면 더 유용한 오류가 나타납니다 (단 하나의 예).
현재 버전의 SQL Server에서 일부 데이터베이스 기능을 사용할 수 없으므로 데이터베이스 'databasename'을 (를) 시작할 수 없습니다.
이 버전의 SQL Server에는 파티션 함수 '_dta_pf__9987'이 포함되어 있으므로 데이터베이스 'databasename'을 (를) 시작할 수 없습니다. Enterprise 버전의 SQL Server 만 파티션 기능을 지원합니다.
이제는 사실이 아닙니다. Evaluation Edition 또는 Developer Edition으로 복원 할 수도 있지만 그 점이 중요합니다. 이 데이터베이스를 복원하기 위해 기본적으로 두 가지 옵션이 있습니다.
- 적절한 버전의 SQL Server로 복원합니다. 즉, 새 인스턴스를 찾거나 설치해야합니다.
- 원본 서버의 백업을 이름이 다른 새 데이터베이스로 복원하고 모든 Enterprise 기능을 제거한 다음 데이터베이스를 다시 백업 한 후 하위 버전에서 복원하십시오. (이 특정 경우에는 파티션 함수의 이름을 오류 메시지에 그대로 두었습니다. 어쨌든 이것은 버릴 수있는 것으로 보입니다. 이는 데이터베이스 엔진 튜닝 관리자에 의해 만들어졌으며 그렇지 않은 사람에 의해 수행되었을 수 있습니다. 그들이 무엇을하고 있는지 알고 있습니다. 항상 그런 것은 아닙니다.)
(2)의 변형은 소스 데이터베이스에서 파티션 및 기타 기능을 제거하고 다른 백업을 수행하는 것입니다. 하지만 파산하지 않으면 ...