Lý do vẫn nên sử dụng SQL Server 2000 là gì?

Từ các câu hỏi trên StackOverflow và các nơi khác, tôi nhận thấy rằng vẫn có người sử dụng SQL Server 2000. Thành thật mà nói, ảnh hưởng lớn nhất đối với tôi là tôi phải nhớ cách chúng ta thường làm mọi thứ mà không có Biểu thức chung.

Tuy nhiên, tôi muốn biết liệu có lý do thực sự nào không (ngoài "nó không bị hỏng") vẫn sử dụng SQL Server 2000. Chẳng hạn, tôi biết có những người phải sử dụng .NET 1.1 vì họ phải hỗ trợ Hệ thống Windows 2000. Có bất kỳ lý do tương tự, thực tế nào để không nâng cấp hệ thống SQL Server 2000 lên SQL Server 2008 hoặc 2005 không?

Tâm trí kinh doanh thường rất khác với bạn. Tại sao sử dụng một cái gì đó mới hơn nếu nó sẽ không tạo ra nhiều doanh thu hơn, mà chỉ chi phí (di chuyển, đào tạo lại, v.v.)?

Lý do tốt nhất tôi có thể nghĩ là một biến thể của "nó không bị hỏng" như sau: Bạn có một ứng dụng kinh doanh hoạt động với SQL 2000 nhưng tạo ra lỗi với SQL 2005. Đây có thể không phải là ưu tiên kinh doanh phù hợp cho tổ chức của bạn tại thời điểm này để mở mui xe trên ứng dụng đó (không bị hỏng) và làm cho nó hoạt động với cơ sở dữ liệu mới hơn.

Hỗ trợ di sản

SQL Server 2005 không hoàn toàn tương thích ngược với SQL Server 2000. Dịch vụ phân tích có sự không tương thích lớn. Chuyển sang SQL Server 2005 có chi phí khác không từ kiểm tra hồi quy và chuyển. Nhiều tổ chức không có yêu cầu di chuyển, vì vậy họ sẽ không di chuyển cho đến khi họ phải di chuyển.

Hầu hết các nhà cung cấp DBMS (bao gồm MS) sẽ hỗ trợ phiên bản DBMS trong 10 năm hoặc lâu hơn - dài hơn hầu hết các loại phần mềm khác. Nếu bạn vượt qua lòng bàn tay của họ bằng bạc (với số lượng đủ), họ cũng sẽ nhập các hợp đồng cụ thể để mở rộng hỗ trợ trên một phiên bản cụ thể lâu hơn thế.

Các lý do khác để gắn bó với các phiên bản cũ hơn thực sự bị thúc đẩy bởi các trường hợp cụ thể như tránh việc phát hành bị lỗi đã biết (ví dụ: MySQL 5.1 hoặc SQL3 trước SP3) hoặc các vấn đề về chứng nhận hoặc tương thích.

Duy trì cơ sở dữ liệu sản xuất SQL Server 2000

Đối với một hệ điều hành hoạt động và đang trong giai đoạn trưởng thành của vòng đời mà không có nhiều thay đổi lớn đang diễn ra, có lẽ không có lý do thuyết phục nào để nâng cấp trước khi DBMS ra khỏi hỗ trợ chính. Tuy nhiên, bạn nên lập kế hoạch một lộ trình nâng cấp có trật tự cho tình huống đó. Oracle khá nổi tiếng với những người duy trì hệ thống sản xuất trên các phiên bản cổ xưa.

SQL Server 2000 sắp kết thúc vòng đời, vì vậy bạn sẽ không muốn thực hiện công việc phát triển mới trên nó. Tuy nhiên, một ứng dụng sản xuất nên được duy trì với một kế hoạch để chuyển đi khi bạn cần. Bạn có thể sẽ viết lại trên tay nếu ứng dụng của bạn được viết bằng VB6 hoặc ASP cổ điển - nhưng đó là một vấn đề khác; -}.

Các trường hợp truy cập

Nếu tôi có một dự án trường xanh, tôi thường sẽ đề xuất phiên bản mới nhất của nền tảng DBMS đơn giản vì nó cung cấp cho bạn cửa sổ hỗ trợ nhà cung cấp dài nhất. Không ai vẫn nên có SQL Server 2000 làm tiêu chuẩn chung cho các dự án mới - EOL quá gần. Đối với một dự án mới, đây là lý lẽ mạnh nhất để chuyển sang phiên bản mới hơn. Tranh cãi về việc tiết kiệm tiền không giữ nước; ứng dụng sẽ chịu chi phí chuyển không cần thiết trong vòng một vài năm nếu bạn bắt đầu sử dụng SQL2000 ngay bây giờ.

Điểm mấu chốt cho công việc của Greenfield là một lựa chọn quá bảo thủ sẽ rút ngắn tuổi thọ của ứng dụng trước khi cần nâng cấp. Mọi người thường muốn có một lý do cụ thể để không sử dụng phiên bản hiện tại của nền tảng DBMS.

Chúng tôi không nâng cấp vì chúng tôi có phần mềm tài chính dựa trên nó và nhà cung cấp chỉ nghĩ về việc hỗ trợ "SQL 2005" mới mà họ đã nghe blog trẻ em điên rồ gần đây.

Thành thật mà nói, tôi rất đau lòng khi có một hỗn hợp các thứ để hỗ trợ, nhưng gần như không gây hại cho mọi người trong công ty khi có vấn đề với hệ thống tài chính bật lên, và sau đó để nhà cung cấp phần mềm tài chính chỉ vào chúng tôi và cười khi chúng tôi yêu cầu trợ giúp và đề cập rằng các vấn đề bắt đầu kể từ khi chúng tôi nâng cấp lên SQL 2005 trước khi họ phê chuẩn.

Cũng có rất nhiều điều để nói về việc không sửa chữa mọi thứ nếu chúng không thực sự bị hỏng. Tôi muốn nâng cấp tất cả các máy chủ SQL của mình lên 2008 đôi khi ... Tôi thực sự làm được. Nhưng có rất nhiều thứ tôi có thể làm để thực sự cải thiện điểm mấu chốt của doanh nghiệp theo những cách dễ hiểu và có thể định lượng được cho người quản lý của tôi và người dùng ... điều đó luôn luôn được ưu tiên.

Bạn đề cập đến các nhà phát triển không thích làm việc với SQL 2000 khi trả lời câu trả lời của Mastermind. Tôi nghi ngờ một phương pháp xử lý đó sẽ là phương pháp mà ông chủ của tôi sẽ sử dụng cho tôi nếu tôi quyết định tôi "không thích" hỗ trợ SQL 2000: "Cảm ơn bạn đã dành thời gian làm việc ở đây, cánh cửa bên trái của bạn". Vào cuối ngày, tất cả chúng ta đều được trả tiền để làm cho công cụ hoạt động cho dù chúng ta có thích hay không.

Trong trường hợp của chúng tôi, đó không phải là trường hợp 'tại sao tiếp tục sử dụng 2000' so với trường hợp 'chi phí nâng cấp là bao nhiêu?'. Hầu hết các ứng dụng của chúng tôi không sử dụng bất cứ thứ gì cần bất kỳ tính năng cụ thể nào trong năm 2005, vì vậy không có lý do thuyết phục nào và có lẽ sẽ không có cho đến khi Microsoft ngừng hỗ trợ cho nó.

Giá cả.

Phần mềm mới hơn vẫn là phần mềm bổ sung, có chi phí bổ sung.

Đây có thể là, và thường là, một nền kinh tế sai lầm do nhiều mặt trái của việc sử dụng các hệ thống lỗi thời, nhưng đó là lý do thực sự duy nhất có ý nghĩa.

Giấy phép mới cho SQL Server 2008 (tiêu chuẩn) có giá thấp hơn 2.000 đô la cho 1 máy chủ với 5 CAL hoặc 6.000 đô la cho 1 giấy phép CPU. Tôi có thể nghe ông chủ cũ của tôi nói rằng "nó không bị hỏng, nhưng sẽ tốn bao nhiêu tiền để nâng cấp 2 máy chủ đó?" (tại thời điểm đó 2 x CPU kép yêu cầu giấy phép CPU).

Đã sử dụng SQL2000 được bảy năm, trải nghiệm đầu tiên của tôi năm 2005 là trong môi trường VMWare ESX. Hiệu suất bị giảm (ISP đã cung cấp kiến ​​thức chuyên môn về VMWare và khi chúng tôi bắt đầu thử nghiệm tải, chúng tôi thấy họ gặp vấn đề lớn không chỉ với máy chủ của chúng tôi mà còn ảnh hưởng đến trải nghiệm của chúng tôi) và kết hợp với mọi thứ được chuyển / đổi tên (người quản lý doanh nghiệp cũ rất ít nhanh hơn nhiều) - chúng tôi đã vui hơn để trì hoãn việc nâng cấp. Sau đó, chúng tôi đang chờ phát hành năm 2008 vì vậy chúng tôi hiện chỉ nâng cấp lên 2008 (hoặc di chuyển một số dữ liệu sang MySQL / PostgresQuery).

Microsoft vẫn đang cung cấp hỗ trợ chính cho năm 2000 cho đến một thời điểm nào đó vào năm ngoái vì vậy chỉ mới gần đây chúng tôi có lý do thuyết phục hơn để nâng cấp.

Các công ty nhỏ cũng có một vấn đề về tài nguyên - học tập, lập kế hoạch, thử nghiệm nâng cấp cần có thời gian và tác động đến các hoạt động khác. Nếu bạn phải nâng cấp một số ứng dụng khác nằm trên SQL Server cùng một lúc thì điều này cũng có thể rất tốn kém.

Trong một thời gian, chúng tôi đã tán tỉnh việc chuyển sang nguồn mở và trong khi đó có khả năng nó cũng đóng băng đối với bất kỳ nâng cấp nào.

Tại sao không nâng cấp lên máy chủ sql 2008, sau đó bạn thực sự có thể giảm chi phí của mình, do nén dữ liệu, bảo trì dễ dàng hơn và cải thiện hiệu suất (các chỉ mục được lọc)? Gần đây, chúng tôi đã nâng cấp cài đặt máy chủ sql 2000 và tiết kiệm 75% dung lượng đĩa, và hiệu suất tăng lên đáng kể.

Một cải tiến khác là sự tương tranh do cơ chế khóa mới được giới thiệu trong máy chủ sql 2005.

/ Håkan Winther

Các tổ chức lớn có nguy cơ bất lợi và không biết gì, dẫn đến một số quyết định thực sự ngu ngốc. Khi tôi đang làm công cụ Unix vào khoảng 2003/2004, chúng tôi đã bị mắc kẹt với môi trường Solaris 2.5.1 được phát hành khi tôi học lớp 10 hoặc hơn vì đó là công nghệ "đã được chứng minh" và nó "quá đắt" để nâng cấp.

Quá đắt thường là PHB-speak cho "Tôi đã không đủ khả năng ngân sách để nâng cấp $ 1000 trong một dự án $ 10 triệu".

Trong trường hợp phần mềm Microsoft stack, mọi người thường nâng cấp bất lợi vì họ không muốn đối phó với troll cấp phép trong công ty và mua giấy phép OEM từ Dell / IBM / etc và không cảm thấy thích giao dịch với hoops quan liêu liên quan đến nâng cấp.

Tôi không mua (ý định chơi chữ) đối số "chi phí trả trước", nhưng không may là chi phí trả trước là điều mà rất nhiều PHB ám ảnh vì vậy nó hợp lệ để cho phép nó đứng vững.

Đối với tôi lý do thuyết phục duy nhất sẽ là các ứng dụng sử dụng nó. Ví dụ: nếu bạn là nhà SharePoint 2003, KHÔNG CÓ CÁCH NÀO bạn sẽ nâng cấp lên SQL 2005 hoặc 2008 mà không thực hiện nâng cấp SharePoint, đây không phải là vấn đề nhỏ.

Trong tổ chức của chúng tôi, tất cả sự phát triển mới được cho là trên SQL 2005/2008, nhưng chúng tôi có rất nhiều ứng dụng 2000 cũ, nó không đáng để tốn thời gian / năng lượng / tiền để chuyển đổi tất cả.

Ngoài các vấn đề về khả năng tương thích (DTS to SSIS là vấn đề lớn nhất đối với chúng tôi), chúng tôi cũng đã triển khai một bộ hướng dẫn / hạn chế bảo mật trên SQL 2005 mà chúng tôi đã không thi hành cho SQL 2000. (không có người dùng dbo, chỉ có quyền sử dụng lược đồ, Vân vân.)

Trong tổ chức của chúng tôi, có một số lý do. Một số khá cụ thể cho trường hợp của chúng tôi, và một số khác chung chung hơn một chút.

1) Tính không tương thích. Chúng tôi đã có một vài trường hợp phần mềm được viết trong nhà cho SQL2005 có vấn đề khi cài đặt trên SQL2000. Trường hợp tôi thấy gần đây nhất đã kết thúc là do các tham số được tuyên bố rõ ràng là không tồn tại vào năm 2000 và sự khác biệt trong tên của bảng chỉ mục hệ thống. (sys.indexes vs sysindexes)

2) Đào tạo. Các nhà phát triển của chúng tôi chắc chắn biết năm 2005 và muốn phát triển trên đó hoặc 2008. Tuy nhiên, công việc giữ mọi thứ hoạt động thuộc về NOC chứ không phải các nhà phát triển. Không ai trong NOC của chúng tôi đã có bất kỳ khóa đào tạo SQL chính thức nào và sự khác biệt giữa hai loại, chỉ từ quan điểm của công cụ quản trị, là đủ để xem xét điều này.

3) Chi phí nâng cấp các sản phẩm hiện có. Đối với chúng tôi, đây là một trong những lớn. Tôi không nói chi phí giấy phép từ Microsoft ở đây. Trong doanh nghiệp của chúng tôi, việc nâng cấp bất kỳ sản phẩm hiện có nào của chúng tôi (ngay cả khi chúng tôi không nâng cấp hồi tố mọi thứ đã có trong lĩnh vực này) sẽ yêu cầu một quy trình chứng nhận lại tốn kém và lâu dài thông qua một số phòng thí nghiệm kiểm tra và chứng nhận khác nhau. Chúng tôi đang xây dựng các sản phẩm mới trên SQL2005, nhưng không nâng cấp các sản phẩm cũ hơn vì lý do này.

Quá trình chứng nhận cũng có nghĩa là chúng tôi sẽ kết thúc bằng một hỗn hợp trên các bản dựng mới, trong đó các khu vực pháp lý nhất định sẽ nhận được SQL2000 và các cơ quan khác sẽ nhận được SQL2005, dựa trên việc các phê duyệt đã được nhận hay chưa. Vì lý do số 2, chúng tôi muốn giữ môi trường sản xuất của chúng tôi nhất quán nhất có thể.

4) Khác biệt chung. Đây thực sự là một phần mở rộng của # 1. Có rất nhiều điều nhỏ đã thay đổi, một số trong đó khiến chúng ta đau đầu. Ví dụ, SQL2005 trên Server2003 sẽ thực thi các chính sách mật khẩu của Windows trên các tài khoản sql. Bản thân nó không phải là một điều xấu, nhưng nó phá vỡ hầu hết tất cả các phần mềm (và nhiều bên thứ ba) của chúng tôi do cách chúng ta tương tác với cơ sở dữ liệu.

Tóm lại, quán tính.

Một bài viết blog tốt mà đã hỏi cùng một câu hỏi.

Tôi biết có những người phải sử dụng .NET 1.1 vì họ phải hỗ trợ các hệ thống Windows 2000.

Theo logic đó, thì lý do thực tế để chạy MSSQL 2000 là vì bạn có thể hỗ trợ các hệ thống Windows NT 4!

Dù bạn có tin hay không, nhưng SQL Server 2005 thực sự chạy trên Windows Server 2000.