2008 R2보다 SQL Server 2012를 선호하는 객관적인 비즈니스 이유는 무엇입니까?

우리 회사는 새 데이터베이스 서버를 위해 SQL Server 2012 Denali 또는 SQL Server 2008 R2를 구입할지 결정하고 있습니다. 다른 것을 선택해야하는 객관적인 이유를 찾고 있습니다.

우리의 요구 사항 :

• 표준형 (재정상의 이유로 엔터프라이즈 기능이 필요하지 않음)
• OLTP 작업량 (새로운 윈도우 기능 및 열 저장소 인덱스가 필요하지 않음을 의미)
• 10-100GB의 데이터베이스 크기
• 비즈니스 인텔리전스 기능이 필요하지 않습니다. 관계형 엔진 만 필요
• 동기식 데이터베이스 미러링

현재 다음과 같은 이유가 알려져 있습니다.

SQL Server 2012 데날리

• 사용 가능한 최신 버전

SQL Server 2008 R2

• 입증 된 기술

나는 다른 것을 선호하는 많은 기술적 인 이유를 찾지 못하는 것 같습니다. 기본적으로 사용 가능한 최신 및 가장 큰 버전과 성공적으로 실행되는 입증 된 기술을 선택해야합니다.

결정을 내리는 객관적인 이유는 무엇입니까?

모두 AlwaysOn과 ColumnStore에 관심이 있지만 SQL Server 2012의 많은 이점은 고급 버전에만 국한되지 않습니다. 나는 대변인처럼 들리고 싶지 않지만 SQL Server 2012에 대해 많은 프레젠테이션을했으며 여러분에게 적합한 버전으로 제공 할 것이 많다고 생각합니다.

• 부분적으로 포함 된 데이터베이스 를 사용하면 몇 가지 덜 족쇄 (예 : 서버 수준 로그인 및 서버 데이터 정렬 종속성)로 서버 또는 환경간에 데이터베이스를 이동할 수 있습니다. 향후 버전에서는 연결된 서버 및 에이전트 작업과 같은 가시적 인 항목을 처리합니다.

• Management Studio 는 이제 Visual Studio에 맞춰 훨씬 나은 도구입니다. IntelliSense가 더 좋고 다른 많은 기능들이 편집을 더 쉽게 만듭니다. 이제 서버에 2008 R2를 설치하고 2012 버전의 SSMS를 사용할 수 있지만 라이센스 방식이 어떻게 작동하는지 잘 모르겠으며 일부 상점에서는 혼합 버전을 원하지 않습니다 (최신 도구를 선호합니다) 내 워크 스테이션은 하위 서버를 관리합니다). 아직 버그가 있었을 때 초기에 변경 사항에 대해 블로그를 작성 했으므로 RTM에서 대부분 또는 모두 수정되었으므로 부정적인 점을 무시하십시오. SSMS의 이전 버전을 사용해야 할 때 지금은 떨었습니다.

• 메타 데이터 향상 기능을 사용하면 개체 및 임시 쿼리의 결과 집합을 검사 할 수 있으며 쿼리 출력을보다 효과적으로 구성 할 수 있습니다.

• 사용자 지정 서버 역할을 사용하면 하나씩 부여 / 취소하거나 복잡성을주고 sysadmin을 부여하는 대신 역할 수준에서 사용자에 대해 훨씬 세분화 된 권한 집합을 정의 할 수 있습니다.

• FileTable을 사용하면 문서 테이블과 같은 폴더를 관리 할 수 ​​있지만 여전히 내용을 외부에서 제어 할 수 있습니다 (따라서 T-SQL을 사용하여이 작업을 수행 할 수 있다고 생각하고 cmd 또는 PowerShell에서 얼마나 어려운지 상상해보십시오 UPDATE C:\Docs\*.* SET ReadOnly = 1 WHERE Author = 'Bob' AND Created < '20100101';). FileStream이 WinFS를 충족하며 부팅에 약간의 유용성을 얻습니다.

• T-SQL 향상 기능을 사용하면 이전 버전에서 어려움을 겪었던 많은 작업을 수행 할 수 있습니다.

  • THROW (재입고라고 생각)
  • OFFSET/FETCH (더 간단한 ANSI 표준 페이징)
  • SEQUENCE (Oracle에서와 같이 중앙 집중식 IDENTITY 메커니즘)
  • 창 / 프레임 향상 (굉장한 총계 성능과 같은 다양한 요소)
  • IIF()/ CHOOSE()/ CONCAT()/EOMONTH()
  • VB DATETIMEFROMPARTS와 유사한 날짜 / 시간 생성자 (예 DateSerial:)
  • PARSE()/ FORMAT()- 자신의 .NET 대응 등
  • TRY_CONVERT()/ TRY_PARSE()- 반환 NULL하는 경우 CONVERT/가 PARSE실패

• 확장 이벤트 에는 구성 /보기를위한 향상된 UI가 있으며 추적 / 감사 기능 (보다 나은 인과 관계 추적 포함)을 완벽하게 포함합니다.

• 진단 및 성능 문제 해결을위한 많은 새로운 DMV , 시스템 절차 및 ShowPlan 향상. 또한 CSS가 " 블랙 박스 레코더 "라고 부르는 것을 살펴보십시오.

• Server Core를 사용하면 모든 UI 구성 요소없이 최소한의 서버에서 실행할 수 있습니다 (표면적이 작을수록 운영 체제의 적은 부분이 Windows Update의 영향을 받기 때문에 더 안전하고 유지 관리가 줄어 듭니다).

• 전체 텍스트 검색 은 의미 검색 (키워드 생각) 및 사용자 정의 가능한 근접성 / NEAR뿐만 아니라 중요한 기본 성능 향상 기능을 제공합니다.

• AWE는 더 이상 지원되지 않습니다 . 즉, 32GB RAM이있는 x86의 SQL Server 인스턴스는 4GB 만 사용할 수 있으므로 이전 32 비트 하드웨어를 벗어나려는 동기가 생깁니다.

다음은 요청 된대로 "새로운 버전의 첫 번째 버전에서 신뢰성에 대한 실제 증거"에 대한 몇 가지 예입니다. 이것은 완전한 분석이 아니라 연구하고자하는 것에 대한 제안입니다.

MSDN 웹 사이트에서 "SQL Server 2008 서비스 팩 1로 해결 된 문제 목록"및 "SQL Server 2008 서비스 팩 3으로 해결 된 문제 목록"을 Google에 표시 할 수 있습니다. 두 목록의 문제 수와 심각도를 비교하십시오. IMO 첫 번째 목록은 더 길며 다음과 같이 하루를 망칠 수있는 더 많은 항목이 있습니다.

• Windows Vista 또는 Windows Server 2008을 실행하는 클라이언트 컴퓨터에서 명명 된 SQL Server 인스턴스에 연결하면 오류 메시지가 나타난다
• 로그 판독기 에이전트가 트랜잭션 복제를 위해 실행될 때 로그 판독기 에이전트가 일부 트랜잭션을 건너 뜁니다.
• SQL Server 2008에서 외부 조인 작업과 관련된 쿼리를 실행할 때 오류 메시지
• SQL Server 2008에서 만든 클러스터형 인덱스가없는 테이블에서 업데이트 또는 삭제 작업을 수행하면 오류 메시지가 나타난다
• SQL Server 2008에서 여러 연결에서 동시에 쿼리를 실행할 때 매개 변수와 RECOMPILE 옵션을 사용하는 쿼리는 잘못된 결과를 반환합니다.

한 단계 더 드릴 다운하고 MERGE 명령 하나만 고려하겠습니다. 다음 링크에서 설명하는 몇 가지 문제와 함께 SQL 2008의 일부로 릴리스되었습니다.

• 재미있는 합병 버그 ,
• SQL 서버 2008 RTM 병합 버그 및 수정 ,
• 외래 키 제약 조건이 비 클러스터형 인덱스 (2008RTM)에 생성 될 때 버그를 병합 ,
• INSERT / 사용 및 인덱스를 필터링 삭제할 때 문 버그 병합 ,
• MERGE 쿼리 계획은 FK 및 CHECK 제약 조건 위반을 허용합니다 .
• MERGE 문은 참조 무결성을 무시합니다 .
• 매개 변수화 된 DELETE 및 MERGE는 외래 키 제약 조건 위반을 허용 합니다.

따라서 SQL 2008의 최초 릴리스 당시에는 MERGE를 사용하지 않기로 결정했습니다. 2008 R2에서 현재 MERGE를 많이 사용하고 있으며 이것이 정말 훌륭한 기능이라고 생각합니다.

편집 : 다음은 최근 수정 된 SQL 2012의 결함 목록입니다 . 도움이 되길 바랍니다.

또 다른 편집 : 나는 매우 중요한 개선이기 때문에 더 자세한 분석을 위해 MERGE를 선택했습니다. 실제로 이는 Oracle을 따라 잡기위한 주요 단계이며 생산성을 향상시킵니다. 따라서 MERGE는 SQL 2008 릴리스 당시에 많이 판매되었습니다. 그러나 처음 출시 될 때 심각한 프로덕션 시스템에서 사용할 준비가되지 않았으며 프레젠테이션 / 기사 / 블로그 게시물 등에서 쉽게 알 수있는 방법이 없었습니다.

마찬가지로 스냅 샷 격리는 작동하는 멋진 새 기능이지만 CHECK 제약 조건에서 스칼라 UDF를 호출하는 것은 모든 경우에 작동하지 않으므로 데이터 무결성이 필요할 때 프로덕션에서 사용해서는 안됩니다. 그러나 "SQL xxxx의 새로운 기능"프레젠테이션과 서적, 기사 등에서 비슷한 열정을 가진 새로운 기능이 모두 권장되었습니다.

우리는 새로운 기능에 매우주의를 기울여야합니다. 모든 기능이 유용 / 신뢰할 수있는 / 성능이되는 것은 아닙니다.

여기에 언급되지 않은 한 가지 점은 기능 세트와 완전히 관련이 없습니다. 새 빌드를 수행하는 경우 데이터베이스 업그레이드를 약간 더 오래 연기 할 수 있으므로 마이그레이션 비용이 절감됩니다.

그린 필드 프로젝트의 경우 버그를 해결하고 공급 업체에 버그를 제기 할 수있는 약간의 호흡 공간이 있으므로 완전히 통제되지 않은 프로세스는 아닙니다. RTM에 갔을 때 SQL Server 2005의 첫 번째 데이터웨어 하우스 프로젝트 중 하나에 참여하여 그 데이터를 제거했습니다.

2008R2의 기능 세트가 원하는 작업을 수행 할 경우 업그레이드 / 업그레이드주기를 연기해야하는 가치 대 버그 / 해결 방법의 위험에 대한 결정이 내려집니다.

새로운 제품을 구매할 때 선택은 업그레이드를 고려할 때와 크게 다릅니다. 새로운 제품을 구입하면 항상 최신 버전을 구입해야한다고 생각합니다. 2008 버전은 더 이상 2012 버전보다 훨씬 이전에 지원되지 않습니다. 이 백엔드를 오랫동안 사용하게되므로 최신으로 시작하는 것이 좋습니다.

첫 번째 서비스 팩에 대한 필요성은 알기 전에 제공 될 것이며 새로운 개발을 수행하고 있기 때문에 수정하는 문제는 수백만 개의 레코드가있는 레거시 데이터베이스만큼 영향을 미치지 않을 것입니다.

이제 새로운 서버를 받고 있지만 오래된 데이터베이스를 사용한다면 업그레이드 할 대상이 무엇입니까? 데이터베이스가 이미 2008 데이터베이스 인 경우 동일한 버전을 사용하는 것이 훨씬 덜 위험합니다. 업그레이드하는 경우 버전에서 2012로 직접 업그레이드 할 수 있는지 확인하십시오.