SQL Server 2000을 계속 사용해야하는 이유는 무엇입니까?

StackOverflow 및 다른 곳의 질문에서 SQL Server 2000을 사용하는 사람들이 여전히 있음을 알았습니다. 솔직히 말하면, 가장 큰 영향은 공통 테이블 식없이 작업을 수행하는 방법을 기억해야한다는 것입니다.

그래도 여전히 SQL Server 2000을 사용해야하는 실제 이유 ( "손상되지 않은"이상)가 있는지 알고 싶습니다. 예를 들어, .NET 1.1을 사용해야하는 사람들은 지원해야하기 때문에 Windows 2000 시스템. SQL Server 2000 시스템을 SQL Server 2008 또는 2005로 업그레이드하지 않아야하는 유사한 실제적인 이유가 있습니까?

사업 정신은 일반적으로 당신과 매우 다릅니다. 더 많은 수익을 창출하지 않고 비용 (마이그레이션, 재교육 등) 만 사용한다면 왜 더 새로운 것을 사용합니까?

내가 생각할 수있는 가장 좋은 이유는 다음과 같은 "손상되지 않은"변형입니다. SQL 2000에서는 작동하지만 SQL 2005에서는 오류를 생성하는 비즈니스 응용 프로그램이 있습니다. 조직에 올바른 비즈니스 우선 순위가 아닐 수도 있습니다. 현재 해당 응용 프로그램의 후드를 열어서 최신 데이터베이스에서 작동하도록하십시오.

레거시 지원

SQL Server 2005는 SQL Server 2000과 완전히 호환되지 않습니다. Analysis Services에는 큰 비 호환성이 있습니다. SQL Server 2005로 전환하면 회귀 테스트 및 포팅 비용이 0이 아닙니다. 많은 조직에서는 이사 할 필요가 없으므로 이사해야 할 때까지 움직이지 않습니다.

대부분의 DBMS 공급 업체 (MS 포함)는 10 년 정도 동안 DBMS 버전을 지원합니다. 이는 대부분의 다른 유형의 소프트웨어보다 더 깁니다. 손바닥을은으로 (충분한 양으로) 교차하면 특정 계약을 연장하여 특정 버전에 대한 지원을 연장 할 수 있습니다.

이전 버전을 고수해야하는 다른 이유는 실제로 알려진 릴리스 (예 : MySQL 5.1 또는 SP3 이전 SQL2000) 또는 인증 또는 호환성 문제를 피하는 것과 같은 특정 상황에 의해 결정됩니다.

SQL Server 2000 프로덕션 데이터베이스 유지 관리

많은 주요 변경 사항이 발생하지 않고 작동하고 수명주기의 성숙한 단계에있는 운영 체제의 경우 DBMS가 주류 지원에서 벗어나기 전에 업그레이드해야 할 강력한 이유가 없을 것입니다. 그러나 해당 상황에 대한 순차적 업그레이드 경로를 계획해야합니다. 오라클은 고대 버전에서 프로덕션 시스템을 유지 관리하는 사람들로 유명합니다.

SQL Server 2000의 수명이 다해 가고 있으므로 새로운 개발 작업을하고 싶지 않을 것입니다. 그러나 필요할 때 이동할 계획으로 프로덕션 응용 프로그램을 유지 관리해야합니다. 앱이 VB6 또는 클래식 ASP로 작성된 경우 아마도 다시 작성해야 할 것입니다. 그러나 그것은 다른 문제입니다;-}.

카운터 케이스

그린 필드 프로젝트가있는 경우 일반적으로 가장 긴 공급 업체 지원 기간을 제공하기 때문에 최신 버전의 DBMS 플랫폼을 권장합니다. 아무도 새 프로젝트에 대한 회사 표준으로 SQL Server 2000을 사용하지 않아야합니다. EOL이 너무 가깝습니다. 새로운 프로젝트의 경우, 이것은 새로운 버전으로 옮기는 가장 강력한 주장입니다. 돈을 절약하는 것에 대한 논쟁은 물을 보유하지 않습니다. 지금 SQL2000을 시작하면 몇 년 내에 앱에 불필요한 이식 비용이 발생합니다.

Greenfield 작업의 핵심은 지나치게 보수적 인 선택은 업그레이드가 필요하기 전에 응용 프로그램의 서비스 수명을 단축시키는 것입니다. 일반적으로 현재 버전의 DBMS 플랫폼에 적합하지 않은 특정 이유를 원할 것입니다.

우리는 그것에 의존하는 금융 소프트웨어를 가지고 있기 때문에 업그레이드하지 않으며, 공급 업체는 최근에이 미친 "키즈 2005"를 듣고있는이 새로운 "SQL 2005"를 지원하는 것에 대해서만 생각하고 있습니다.

솔직히, 그것은 상처 나 지원 재료의 혼합물을 가지고 있지만 거의 많이 다치게하는 것처럼 회사의 모든 사람을 금융 시스템에 문제가있는 팝업, 그리고 우리의 금융 소프트웨어 공급 업체에 지점을 가지고 및 도움을 요청하고 비준하기 전에 SQL 2005로 업그레이드 한 후 문제가 시작되었다고 언급했을 때 웃었습니다.

실제로 파손되지 않은 경우 물건을 고치지 않는다는 말이 많이 있습니다. 언젠가 모든 SQL 서버를 2008로 업그레이드하고 싶습니다 ... 정말 그렇습니다. 그러나 관리자와 사용자가 이해할 수 있고 수량화 할 수있는 방식으로 비즈니스의 수익을 실제로 향상시킬 수있는 훨씬 더 많은 일들이 있습니다.

Mastermind의 답변에 대한 답변으로 SQL 2000 작업을 좋아하지 않는 개발자를 언급했습니다. SQL 2000을 지원하고 "좋지 않다"고 결정한 경우, 상사가 나에게 사용하는 방법 일 것입니다. "여기서 시간을 내 주셔서 감사합니다. 문 왼쪽에 있습니다." 하루가 끝날 무렵, 우리는 마음에 들든 그렇지 않든 일을 처리하기 위해 돈을받습니다.

우리의 경우에는 '업그레이드 비용이 얼마나 듭니까?'보다 '2000을 계속 사용하는 이유'가 아닙니다. 대부분의 앱은 2005 특정 기능이 필요한 것을 사용하지 않으므로 설득력있는 이유가 없으며 아마도 Microsoft가 지원을 중단 할 때까지는 없을 것입니다.

비용.

최신 소프트웨어는 여전히 추가 소프트웨어이므로 추가 비용이 발생합니다.

구식 시스템을 사용하는 데 따른 단점으로 인해 이는 종종 잘못된 경제 일 수 있지만, 이것이 합당한 유일한 이유입니다.

SQL Server 2008 (표준)에 대한 새로운 라이센스 비용은 CAL이 5 개인 서버 1 대에 $ 2,000, CPU 라이센스 1 개에 $ 6,000입니다. 내 상사가 "파산하지는 않지만이 두 서버를 업그레이드하는 데 비용이 얼마나 듭니까?"라는 말을들을 수 있습니다. (당시 CPU 라이센스가 필요한 2 x 듀얼 CPU).

7 년 동안 SQL2000을 사용해온 2005 년의 첫 경험은 VMWare ESX 환경이었습니다. 성능 저하 (ISP는 VMWare 전문 지식을 제공하고로드 테스트를 시작했을 때 서버뿐 아니라 경험에도 영향을 미치는 주요 문제가 있음을 발견했습니다.) 훨씬 빠르게)-업그레이드를 연기하는 것이 더 행복했습니다. 그런 다음 2008 릴리스를 기다리고 있었으므로 이제 2008로만 업그레이드하거나 일부 데이터를 MySQL / PostgresSQL로 마이그레이션하고 있습니다.

Microsoft는 작년까지 2000 년 동안 주류 지원을 계속하고 있었기 때문에 최근에는 업그레이드해야 할 더 강력한 이유가있었습니다.

소규모 기업에도 리소스 문제가 있습니다. 업그레이드 학습, 계획, 테스트에는 시간이 걸리고 다른 운영에 영향을 미칩니다. SQL Server에있는 다른 응용 프로그램을 동시에 업그레이드해야하는 경우 비용이 매우 많이들 수 있습니다.

한동안 우리는 오픈 소스로 전환하면서 유혹을했고, 그 동안 업그레이드에도 멈출 가능성이있었습니다.

왜 SQL Server 2008로 업그레이드하지 않으면 데이터 압축, 쉬운 유지 관리 및 성능 향상 (필터링 된 인덱스)으로 인해 실제로 비용을 절감 할 수 있습니까? 최근에 SQL Server 2000 설치를 업그레이드하고 디스크 공간을 75 % 절약했으며 성능이 크게 향상되었습니다.

또 다른 개선 사항은 SQL Server 2005에 도입 된 새로운 잠금 메커니즘으로 인한 동시성입니다.

하칸 윈터

대기업은 위험에 무관하고 무지하기 때문에 정말 멍청한 결정을 내릴 수 있습니다. 2003/2004 년경에 유닉스 작업을했을 때, 우리는 내가 입증 된 기술이었고 업그레이드하기에는 너무 비 쌌기 때문에 10 학년 때 출시 된 Solaris 2.5.1 환경에 갇혀있었습니다.

너무 비싸기 때문에 종종 PHB의 말을 인용 할 수 있습니다.

Microsoft 스택 소프트웨어의 경우 사람들은 회사 내에서 라이센스 트롤을 처리하고 싶지 않고 Dell / IBM / etc에서 OEM 라이센스를 구매하지 않기 때문에 업그레이드에 불리한 경우가 많습니다. 업그레이드에 관련된 관료적 후프.

나는 "선불 비용"논증을 사지 않지만 (안타깝게도) 선불 비용은 많은 PHB가 집착하는 것이기 때문에이를 견딜 수있는 것은 유효하다.

나를 위해 유일한 매력적인 이유는 그것을 사용하는 앱이 될 것입니다. 예를 들어 SharePoint 2003 주택이라면 SharePoint 업그레이드를 수행하지 않고도 SQL 2005 또는 2008로 업그레이드 할 방법이 없습니다.

우리 조직에서는 모든 새로운 개발이 SQL 2005/2008을 기반으로하고 있지만 레거시 2000 앱은 너무 많아서 시간 / 에너지 / 돈을 모두 변환 할 가치가 없습니다.

호환성 문제 (DTS to SSIS가 우리에게 가장 큰 문제임) 외에도 SQL 2000에 적용하지 않은 SQL 2005에 대한 일련의 지침 / 보안 제한을 구현했습니다 (dbo 사용자, 스키마 권한 만, 기타.)

우리 조직에는 몇 가지 이유가 있습니다. 일부는 우리의 경우에 매우 구체적이고 다른 일부는 좀 더 일반적입니다.

1) 비 호환성. SQL2000 용으로 사내에서 작성된 소프트웨어에 SQL2000을 설치할 때 문제가있는 경우가있었습니다. 내가 최근에 본 사례는 2000 년에는 존재하지 않는 매개 변수가 명시 적으로 선언되어 시스템 색인 테이블의 이름이 다르기 때문입니다. (sys.indexes와 sysindexes)

2) 훈련. 우리 개발자들은 확실히 2005 년을 알고 있으며 이미 개발 중이거나 2008 년을 선호합니다. 그러나 모든 운영을 유지하는 일은 개발자가 아니라 NOC에 속합니다. NOC의 어느 누구도 공식적인 SQL 교육을받지 않았으며, 관리 도구의 관점에서이 둘의 차이점만으로도이를 고려할 수 있습니다.

3) 기존 제품 업그레이드 비용. 우리에게는 이것이 큰 것입니다. 나는 여기서 Microsoft의 라이센스 비용을 이야기하지 않습니다. 비즈니스에서 기존 제품을 업그레이드하려면 (현장에있는 모든 것을 소급하여 업그레이드하지 않더라도) 여러 규제 및 인증 테스트 랩을 통해 비용이 많이 들고 긴 재 인증 프로세스가 필요합니다. 우리는 SQL2005에 새로운 제품을 구축하고 있지만 이런 이유로 이전 제품을 업그레이드하지는 않습니다.

인증 프로세스는 또한 승인을 받았는지 여부에 따라 특정 관할 구역에서 SQL2000을 받고 다른 관할 구역에서는 SQL2005를 얻는 새로운 빌드에 대한 혼합을 의미합니다. 우리는 이유 2를 위해 프로덕션 환경을 가능한 한 일관성있게 유지하는 것을 선호합니다.

4) 일반적인 차이점. 이것은 실제로 # 1의 확장입니다. 변화된 작은 것들이 많이 있는데, 그 중 일부는 두통을 유발합니다. 예를 들어 Server2003의 SQL2005는 SQL 계정에 Windows 암호 정책을 적용합니다. 그 자체로는 나쁜 것이 아니지만 데이터베이스와 상호 작용하는 방식 때문에 거의 모든 (및 많은 타사) 소프트웨어가 손상됩니다.

요컨대, 관성.

이미 같은 질문을 한 좋은 블로그 게시물 .

Windows 2000 시스템을 지원해야하므로 .NET 1.1을 사용해야하는 사람들이 있다는 것을 알고 있습니다.

이러한 논리에 따라 MSSQL 2000을 실행해야하는 실질적인 이유는 Windows NT 4 시스템을 지원할 수 있기 때문입니다!

믿거 나 말거나 SQL Server 2005는 실제로 Windows Server 2000에서 실행됩니다.