Jakie są powody, aby nadal używać SQL Server 2000?

Z pytań dotyczących StackOverflow i innych miejsc zauważyłem, że nadal są ludzie używający SQL Server 2000. Szczerze mówiąc, największy wpływ na mnie ma to, że muszę pamiętać, jak robiliśmy rzeczy bez wspólnych wyrażeń tabelowych.

Mimo to chciałbym wiedzieć, czy istnieją rzeczywiste powody (poza „nie jest zepsute”), aby nadal używać programu SQL Server 2000. Na przykład wiem, że są ludzie, którzy muszą korzystać z .NET 1.1, ponieważ muszą obsługiwać Systemy Windows 2000. Czy istnieją jakieś podobne praktyczne powody, aby nie uaktualniać systemu SQL Server 2000 do SQL Server 2008 lub 2005?

Umysł biznesowy jest zwykle bardzo różny od twojego. Po co korzystać z czegoś nowszego, jeśli nie generuje to więcej przychodów, a jedynie wydatki (migracja, przekwalifikowanie itp.)?

Najlepszym powodem, dla którego mogę wymyślić, jest wariant „nie jest zepsuty”, który wygląda następująco: masz aplikację biznesową, która działa z SQL 2000, ale generuje błędy w SQL 2005. Może to nie być właściwy priorytet biznesowy dla Twojej organizacji w tej chwili, aby otworzyć kaptur dla tej aplikacji (która nie jest zepsuta) i sprawić, by działała z nowszą bazą danych.

Wsparcie dla starszych wersji

SQL Server 2005 nie jest całkowicie wstecznie kompatybilny z SQL Server 2000. Usługi Analysis Services mają poważne niezgodności. Przejście na SQL Server 2005 wiąże się z niezerowymi kosztami związanymi z testowaniem regresyjnym i przenoszeniem. Wiele organizacji nie ma obowiązku przeprowadzki, więc nie przeprowadzą się, dopóki nie będą musiały.

Większość dostawców DBMS (w tym MS) będzie obsługiwać wersję DBMS przez około 10 lat - dłużej niż większość innych rodzajów oprogramowania. Jeśli skrzyżujesz ich dłonie ze srebrem (w wystarczającej ilości), wejdą one również w określone umowy, aby przedłużyć obsługę określonej wersji dłużej.

Inne powody, dla których warto trzymać się starszych wersji, są tak naprawdę spowodowane konkretnymi okolicznościami, takimi jak unikanie znanej nieuczciwej wersji (np. MySQL 5.1 lub SQL Server wcześniejszej niż SP3) lub problemy z certyfikacją lub kompatybilnością.

Utrzymanie produkcyjnej bazy danych SQL Server 2000

W przypadku systemu operacyjnego, który działa i znajduje się w dojrzałej fazie swojego cyklu życia bez wielu poważnych zmian, prawdopodobnie nie ma ważnego powodu, aby dokonać aktualizacji, zanim DBMS przestanie być obsługiwany przez główny nurt. Należy jednak zaplanować uporządkowaną ścieżkę ulepszeń na taką ewentualność. Oracle jest znany z ludzi, którzy utrzymują systemy produkcyjne w starożytnych wersjach.

SQL Server 2000 zbliża się do końca, więc nie chciałbyś wykonywać na nim nowych prac programistycznych. Jednak aplikacja produkcyjna powinna być utrzymana z planem wycofania się, gdy zajdzie taka potrzeba. Prawdopodobnie będziesz miał przepisane na ręce, jeśli twoja aplikacja jest napisana w VB6 lub klasycznej ASP - ale to inny problem; -}.

Kontrakt

Gdybym miał projekt typu greenfield, zwykle polecałbym najnowszą wersję platformy DBMS, ponieważ zapewnia ona najdłuższe okno wsparcia dostawcy. Nikt nie powinien nadal mieć SQL Server 2000 jako korporacyjnego standardu dla nowych projektów - EOL jest zbyt blisko. W przypadku nowego projektu jest to zdecydowanie najsilniejszy argument przemawiający za przejściem do nowszej wersji. Argumenty o oszczędzaniu pieniędzy nie trzymają wody; aplikacja będzie powodować niepotrzebne koszty przenoszenia w ciągu kilku lat, jeśli uruchomisz teraz SQL2000.

Kluczową kwestią w pracy na polu jest to, że zbyt konserwatywny wybór skraca żywotność aplikacji, zanim wymagana będzie aktualizacja. Zwykle nie ma konkretnego powodu, aby nie wybierać aktualnej wersji platformy DBMS.

Nie dokonujemy aktualizacji, ponieważ mamy oparte na nim oprogramowanie finansowe, a sprzedawca myśli tylko o wsparciu tego nowego „SQL 2005”, o którym ostatnio słyszeli blog zwariowanych dzieci.

Szczerze mówiąc, boli mnie to, że mam do zaoferowania mieszankę różnych rzeczy, ale nie tak bardzo, jak to by zaszkodziło wszystkim w firmie, aby mieli problem z wyskakującym systemem finansowym, a następnie zmusić dostawcę oprogramowania finansowego do nas i śmiej się, kiedy poprosiliśmy o pomoc i wspomnieliśmy, że problemy zaczęły się od czasu aktualizacji do SQL 2005, zanim ją ratyfikowaliśmy.

Można również wiele powiedzieć o nie naprawianiu rzeczy, jeśli nie są one faktycznie uszkodzone. Chcę kiedyś uaktualnić wszystkie moje serwery SQL do 2008 roku ... Naprawdę. Ale jest o wiele więcej rzeczy, które mógłbym robić, które faktycznie poprawiają wyniki finansowe firmy w sposób zrozumiały i wymierny dla moich menedżerów i użytkowników ... cóż, to zawsze będzie na pierwszym miejscu.

W odpowiedzi na odpowiedź Masterminda wspominasz o programistach, którzy nie lubią pracować z SQL 2000. Podejrzewam, że jedną z metod radzenia sobie z tym byłaby ta, którą wykorzystaliby moi szefowie, gdybym zdecydował, że „nie lubię” obsługi SQL 2000: „Dziękuję za twój czas pracy tutaj, drzwi po twojej lewej stronie”. Pod koniec dnia wszyscy otrzymujemy wynagrodzenie, aby wszystko działało, czy nam się to podoba, czy nie.

W naszym przypadku jest to mniej przypadek „dlaczego nadal korzystać z 2000” niż „uaktualnienie kosztuje JAK Ile?”. Większość naszych aplikacji nie korzysta z niczego, co wymaga jakichkolwiek funkcji specyficznych dla 2005 roku, więc nie ma ważnego powodu i prawdopodobnie nie nastąpi, dopóki Microsoft nie przestanie go obsługiwać.

Koszt.

Nowsze oprogramowanie to wciąż dodatkowe oprogramowanie, które kosztuje dodatkowe pieniądze.

Może to być i często jest to fałszywa ekonomia z powodu wielu wad stosowania przestarzałych systemów, ale jest to jedyny prawdziwy powód, który ma sens.

Nowa licencja na SQL Server 2008 (standard) kosztuje nieco mniej niż 2000 USD za 1 serwer z 5 licencjami CAL lub 6000 USD za 1 licencję na procesor. Słyszę, jak mój stary szef powiedział: „To nie jest zepsute, ale to kosztuje ile kosztuje uaktualnienie tych 2 serwerów?” (w tym czasie 2 x podwójny procesor wymagający licencji na procesor).

Korzystając z SQL2000 przez siedem lat, moje pierwsze doświadczenia z 2005 roku były w środowisku VMWare ESX. Osiągnięta wydajność (ISP zapewniał wiedzę specjalistyczną VMWare i kiedy rozpoczęliśmy testowanie obciążenia, stwierdziliśmy, że mieli oni poważne problemy nie tylko z naszym serwerem, ale wpłynęli na nasze doświadczenie) i w połączeniu ze wszystkim, co zostało przeniesione / zmieniono jego nazwę (stary menedżer przedsiębiorstwa był bardzo znacznie szybciej) - z przyjemnością odkładaliśmy aktualizację. Potem czekaliśmy na wydanie 2008, więc dopiero teraz aktualizujemy do 2008 (lub migrujemy niektóre dane do MySQL / PostgresSQL).

Firma Microsoft nadal zapewniała wsparcie głównego nurtu na rok 2000 do pewnego czasu w ubiegłym roku, więc dopiero niedawno mieliśmy bardziej przekonujący powód do aktualizacji.

Małe firmy mają również problem z zasobami - nauka, planowanie, testowanie aktualizacji wymaga czasu i wpływa na inne operacje. Jeśli musisz zaktualizować inną aplikację, która jest jednocześnie zainstalowana na serwerze SQL, może to być bardzo kosztowne.

Przez pewien czas flirtowaliśmy z przejściem na open-source, i chociaż była to możliwość, zawiesiło także każdą aktualizację.

Dlaczego nie uaktualnić do SQL Server 2008, to faktycznie możesz obniżyć koszty, dzięki kompresji danych, łatwiejszej konserwacji i lepszej wydajności (przefiltrowane indeksy)? Niedawno zaktualizowaliśmy instalację serwera SQL 2000 i zaoszczędziliśmy 75% miejsca na dysku, a wydajność gwałtownie wzrosła.

Kolejnym ulepszeniem była współbieżność dzięki nowemu mechanizmowi blokowania wprowadzonemu w SQL Server 2005.

/ Håkan Winther

Duże organizacje są ryzykowne i ignoranckie, co prowadzi do niektórych naprawdę głupich decyzji. Kiedy robiłem rzeczy związane z Uniksem około 2003/2004, utknęliśmy w środowisku Solaris 2.5.1, które zostało wydane, gdy byłem w 10. klasie, ponieważ była to „sprawdzona” technologia i „uaktualnienie” było „zbyt drogie”.

Zbyt kosztowne jest często mówienie przez PHB za: „Byłem głupi w budżecie na uaktualnienie 1000 $ w projekcie za 10 milionów $”.

W przypadku oprogramowania stosowego Microsoft ludzie często nie są skłonni do aktualizacji, ponieważ nie chcieli poradzić sobie z trollem licencyjnym w firmie i kupili licencję OEM od Dell / IBM / itp. I nie mają ochoty zajmować się biurokratyczne obręcze zaangażowane w ulepszanie.

Nie kupuję argumentu „koszt początkowy”, ale niestety koszt początkowy jest czymś, co ma obsesję na punkcie wielu PHB, więc warto go utrzymać.

Dla mnie jedynym istotnym powodem byłyby aplikacje, które z niego korzystają. Na przykład, jeśli korzystasz z SharePoint 2003, nie ma ŻADNEGO SPOSOBU uaktualnienia do SQL 2005 lub 2008 bez przeprowadzenia aktualizacji do SharePoint, co nie jest trywialne.

W naszej organizacji wszystkie nowe prace rozwojowe powinny być oparte na SQL 2005/2008, ale mamy tak wiele starszych aplikacji 2000, że ich konwersja nie jest warta czasu / energii / pieniędzy.

Oprócz problemów ze zgodnością (DTS do SSIS jest dla nas największy), wdrożyliśmy również zestaw wytycznych / ograniczeń bezpieczeństwa w SQL 2005, których nie egzekwowaliśmy dla SQL 2000. (bez użytkowników dbo, tylko uprawnienia do schematu, itp.)

W naszej organizacji istnieje kilka powodów. Niektóre są dość specyficzne dla naszego przypadku, a inne nieco bardziej ogólne.

1) Niezgodności. Mieliśmy kilka przypadków, w których oprogramowanie napisane wewnętrznie dla SQL2005 ma problemy z instalacją na SQL2000. Przypadek, który ostatnio widziałem, był spowodowany jawnym zadeklarowaniem parametrów, które nie istnieją w 2000 r., Oraz różnicą w nazwie tabeli indeksów systemu. (sys.indexes vs sysindexes)

2) Szkolenie. Nasi programiści z pewnością znają rok 2005 i woleliby się nad nim rozwijać już od 2008 roku. Jednak zadanie utrzymania wszystkiego w działaniu spada na NOC, a nie na deweloperów. Nikt w naszym Narodowym Komitecie Olimpijskim nie odbył żadnego formalnego szkolenia SQL, a różnice między nimi, tylko z punktu widzenia narzędzia administracyjnego, są wystarczające, aby wziąć to pod uwagę.

3) Koszt aktualizacji istniejących produktów. Dla nas jest to duży problem. Nie mówię tutaj o kosztach licencji Microsoft. W naszym biznesie aktualizacja któregokolwiek z naszych istniejących produktów (nawet gdybyśmy nie ulepszyli wstecznie wszystkiego, co już jest w terenie) wymagałaby kosztownego i długiego procesu ponownej certyfikacji przez kilka różnych regulacyjnych i certyfikujących laboratoriów testowych. Budujemy nowe produkty na SQL2005, ale nie aktualizujemy starszych z tego powodu.

Proces certyfikacji oznacza również, że otrzymalibyśmy mieszankę nowych kompilacji, w których niektóre jurysdykcje otrzymywałyby SQL2000, a inne - SQL2005, w zależności od tego, czy zatwierdzenia zostały już otrzymane, czy nie. Z przyczyn nr 2 wolimy, aby nasze środowisko produkcyjne było jak najbardziej spójne.

4) Różnice ogólne. To naprawdę rozszerzenie nr 1. Jest wiele drobiazgów, które się zmieniły, a niektóre powodują u nas bóle głowy. Przykład: SQL2005 na Server2003 wymusi zasady haseł systemu Windows na kontach SQL. Nie jest to zła rzecz sama w sobie, ale psuje prawie całe nasze (i wiele stron trzecich) oprogramowanie ze względu na sposób interakcji z bazą danych.

Krótko mówiąc, bezwładność.

Dobre blogu , które już samo pytanie.

Wiem, że są ludzie, którzy muszą korzystać z .NET 1.1, ponieważ muszą obsługiwać systemy Windows 2000.

Zgodnie z tą logiką praktycznym powodem uruchomienia MSSQL 2000 jest to, że możesz obsługiwać systemy Windows NT 4!

Wierzcie lub nie, ale SQL Server 2005 działa w systemie Windows Server 2000.