Hala SQL Server 2000 Kullanmanın Nedenleri Nelerdir?

StackOverflow ve başka yerlerdeki sorulardan hala SQL Server 2000 kullanan insanlar olduğunu fark ediyorum. Dürüst olmak gerekirse, üzerimdeki en büyük etki, Ortak Tablo İfadeleri olmadan nasıl yaptığımızı hatırlamamız gerektiğidir.

Yine de, SQL Server 2000'i kullanmak için gerçek nedenler ("bozuk değil" dışında) olup olmadığını bilmek istiyorum. Örneğin, .NET 1.1 kullanması gereken insanlar olduğunu biliyorum çünkü Windows 2000 sistemleri. Bir SQL Server 2000 sistemini SQL Server 2008 veya 2005'e yükseltmemenin benzer, pratik nedenleri var mı?

İş zekası genellikle sizinkinden çok farklıdır. Daha fazla gelir elde etmeyecek, ancak yalnızca giderler (taşıma, yeniden eğitim vb.) Üretmiyorsa neden daha yeni bir şey kullanalım?

Düşünebileceğim en iyi neden şöyle devam ediyor "kırık değil" bir varyasyonu: SQL 2000 ile çalışan ancak SQL 2005 ile hatalar üreten bir iş uygulamanız var. Kuruluşunuz için doğru iş önceliği olmayabilir şu anda bu uygulamada kaputu açmak (kırılmamış) ve daha yeni bir veritabanı ile çalışmasını sağlamak.

Miras yardımı

SQL Server 2005, SQL Server 2000 ile geriye dönük olarak tam uyumlu değildir. Analysis Services'ın büyük uyumsuzlukları vardır. SQL Server 2005'e geçişin, regresyon testi ve portlamadan sıfır olmayan bir maliyeti vardır. Birçok kuruluşun hareket etme zorunluluğu yoktur, bu yüzden mecbur olana kadar hareket etmezler.

Çoğu DBMS satıcısı (MS dahil), DBMS'nin 10 yıl kadar bir sürümünü destekleyecektir - bu da diğer birçok yazılım türünden daha uzundur. Avuç içlerini gümüşle (yeterli miktarda) geçerseniz, daha uzun bir süre için desteği uzatmak için özel sözleşmeler de yapacaklardır.

Eski sürümlere sadık kalmanın diğer nedenleri, bilinen bir indirimli sürümden (örn. MySQL 5.1 veya SP3 öncesi SQL2000) kaçınılması veya sertifika veya uyumluluk sorunları gibi özel durumlardan kaynaklanmaktadır.

SQL Server 2000 üretim veritabanının bakımı

Çok fazla büyük değişiklik yapılmadan çalışan ve yaşam döngüsünün olgun bir aşamasında olan operasyonel bir sistem için, DBMS ana akım desteğinden çıkmadan önce yükseltmek için muhtemelen zorlayıcı bir neden yoktur. Ancak, bu olasılık için düzenli bir yükseltme planı planlamanız gerekir. Oracle, eski sürümlerde üretim sistemlerini koruyan insanlar için oldukça ünlüdür.

SQL Server 2000 kullanım ömrünün sonuna yaklaşıyor, bu yüzden üzerinde yeni geliştirme çalışmaları yapmak istemezsiniz. Ancak, bir üretim uygulamasının gerektiğinde hareket etme planı ile birlikte sürdürülmesi gerekir. Uygulamanız VB6 veya klasik ASP ile yazılmışsa, muhtemelen ellerinizde bir yeniden yazma olacaktır - ancak bu farklı bir sorun; -}.

Karşı dava

Bir greenfield projem olsaydı, DBMS platformunun en son sürümünü tavsiye ederim, çünkü size en uzun satıcı desteği penceresini verir. Hiç kimse yeni projeler için kurumsal bir standart olarak SQL Server 2000'e sahip olmamalıdır - EOL çok yakındır. Yeni bir proje için bu, daha yeni bir sürüme geçmenin en güçlü argümanıdır. Tasarruf konusundaki tartışmalar su tutmaz; şimdi SQL2000 üzerinde başlarsanız uygulama birkaç yıl içinde gereksiz taşıma maliyetlerine maruz kalacaktır.

Yeşil alan çalışması için kilit nokta, aşırı muhafazakar bir seçimin, bir yükseltme gerekmeden önce uygulamanın hizmet ömrünü kısaltmasıdır. Normalde bir DBMS platformunun mevcut sürümü için gitmemek için belirli bir neden gerekir.

Yükseltmiyoruz çünkü ona dayanan finansal yazılımımız var ve satıcı sadece son zamanlarda çılgın çocuklar blogunu duydukları bu yeni "SQL 2005" i desteklemeyi düşünüyor.

Açıkçası, destekleyecek bir şeyler karışımına sahip olmak beni incitiyor , ancak şirketteki herkesin finans sistemi ile ilgili bir problemi olması ve daha sonra finans yazılımı satıcısının bize işaret etmesi ve yardım istediğimizde güldük ve problemlerin onaylanmadan önce SQL 2005'e yükselttiğimizden başladığını belirtti.

Ayrıca, gerçekten kırılmamışlarsa şeyleri düzeltmediği için söylenecek çok şey var. Bütün SQL sunucularımı 2008'e yükseltmek istiyorum ... Gerçekten. Ama yapabileceğim çok daha fazla şey var, bu aslında işin alt satırını yöneticilerim ve kullanıcılar için anlaşılabilir ve ölçülebilir şekillerde geliştiriyor ... bu her zaman önce gelecek.

Mastermind'in cevabına verdiğiniz cevapta geliştiricilerin SQL 2000 ile çalışmayı sevmediğinden bahsediyorsunuz. SQL 2000'i desteklemeyi "beğenmediğime" karar verirsem patronların üzerimde kullanacağı yöntemle başa çıkacağından şüpheleniyorum: Burada çalıştığınız için teşekkürler, kapı solunuzda ". Günün sonunda, ister beğenip beğenmesek de işlerin çalışması için para alıyoruz.

Bizim durumumuzda, 'neden 2000'i kullanmaya devam etmeliyiz', 'yükseltme maliyetleri ne kadar çok?' Uygulamalarımızın çoğu 2005'e özgü özelliklere ihtiyaç duyan hiçbir şey kullanmaz, bu nedenle zorlayıcı bir neden yoktur ve muhtemelen Microsoft destek verene kadar olmayacaktır.

Maliyet.

Daha yeni yazılımlar hâlâ ek yazılımdır ve bu da ek ücrete tabidir.

Bu, modası geçmiş sistemlerin kullanılmasının birçok aşağı tarafı nedeniyle yanlış bir ekonomi olabilir ve çoğu zaman mantıklıdır, ancak mantıklı olan tek gerçek nedendir.

SQL Server 2008 (standart) için yeni lisans, 5 CAL içeren 1 sunucu için 2.000 $ 'dan biraz veya 1 CPU lisansı için 6.000 $' dan biraz daha düşüktür. Eski patronumun "bu kırılmadı, ama bu 2 sunucuyu yükseltmenin maliyeti ne kadar?" Dediğini duyabiliyorum. (o zaman 2 x çift CPU, CPU lisansı gerektirir).

SQL2000'i yedi yıldır kullandığım ilk 2005 deneyimim VMWare ESX ortamındaydı. Performans emildi (ISS, VMWare uzmanlığını sağladı ve yük testine başladığımızda, sadece sunucumuzla değil, deneyimlerimizi de etkilediğini gördük) ve her şeyin taşınması / yeniden adlandırılması (eski işletme yöneticisi sooo çok daha hızlı) - yükseltmeyi ertelemekten daha mutlu olduk. Daha sonra 2008'in yayınlanmasını bekliyorduk, bu yüzden şimdi sadece 2008'e geçiyoruz (veya bazı verileri MySQL / PostgresSQL'e taşıyoruz).

Microsoft, geçen yılki zamana kadar 2000 için ana akım destek veriyordu, bu nedenle yeni sürüme geçmek için daha zorlayıcı bir nedenimiz oldu.

Küçük şirketlerin de bir kaynak sorunu var - öğrenmenin, planlamanın, yükseltmenin test edilmesinin zaman alması ve diğer işlemler üzerindeki etkileri. Aynı anda SQL Server üzerinde oturan başka bir uygulamayı yükseltmeniz gerekiyorsa, bu da çok pahalı olabilir.

Bir süredir açık kaynağa geçmekle flört ettik ve bu bir olasılık olsa da herhangi bir yükseltmeye de bir dondurucu koydu.

Neden sql server 2008'e yükseltmiyorsunuz, o zaman veri sıkıştırması, daha kolay bakım ve geliştirilmiş performans (filtrelenmiş dizinler) nedeniyle maliyetinizi düşürebilirsiniz? Son zamanlarda bir sql server 2000 kurulumunu yükselttik ve disk alanının% 75'ini koruduk ve performans önemli ölçüde arttı.

Bir diğer gelişme, sql server 2005'te tanıtılan yeni kilitleme mekanizması nedeniyle eşzamanlılıktı.

/ Håkan Winther

Büyük organizasyonlar risk olumsuz ve cahildir, bu da gerçekten aptalca kararlara yol açar. 2003/2004 yıllarında Unix işleri yaparken, 10. sınıftayken piyasaya sürülen ve "kanıtlanmış" teknoloji olduğu ve yükseltilmesi "çok pahalı" olduğu için yayınlanan bir Solaris 2.5.1 ortamına takıldık.

Çok pahalı PHB-konuşmak için "Ben 10 milyon dolarlık bir projede 1000 $ yükseltme için bütçe aptal yaptım".

Microsoft yığın yazılımı söz konusu olduğunda, insanlar genellikle şirket içinde lisanslama trolüyle uğraşmak istemediklerinden ve Dell / IBM / etc'den bir OEM lisansı satın aldıklarından ve yükseltmeye katılan bürokratik çemberler.

Ben "açık maliyet" argümanı satın almak (cinas), ama ne yazık ki açık maliyet PHB bir sürü takıntı yapmak bir şey olduğunu, bu yüzden ayakta durmak için geçerli.

Benim için tek zorlayıcı sebep, onu kullanan uygulamalar olurdu. Örneğin, bir SharePoint 2003 eviyseniz, önemsiz bir konu olmayan bir SharePoint yükseltmesi gerçekleştirmeden SQL 2005 veya 2008'e yükseltmeniz YOK YOKTUR.

Kuruluşumuzda, tüm yeni geliştirmelerin SQL 2005/2008'de olması gerekiyordu, ancak çok fazla eski 2000 uygulamamız var, hepsini dönüştürmek için zaman / enerji / paraya değmez.

Uyumluluk sorunlarına ek olarak (SSIS'den DTS bizim için en büyük olanıdır), SQL 2005'te SQL 2000 için uygulamadığımız bir dizi yönerge / güvenlik kısıtlaması uyguladık. (Dbo kullanıcısı yok, yalnızca şema izinleri, vb.)

Organizasyonumuzda çeşitli nedenler var. Bazıları bizim durumumuza oldukça özgüdür ve diğerleri biraz daha geneldir.

1) Uyumsuzluklar. SQL2005 için şirket içinde yazılan yazılımın SQL2000'e yüklenirken sorun yaşadığı birkaç durumumuz var. En son gördüğüm durum, 2000 yılında var olmayan parametrelerin açıkça bildirilmesi ve sistem dizin tablosunun adında bir farklılık olması nedeniyle ortaya çıktı. (sys.indexes vs sysindexes)

2) Eğitim. Geliştiricilerimiz kesinlikle 2005'i biliyor ve üzerinde ya da 2008'de geliştirmeyi tercih ediyorlar. Ancak, her şeyi çalışır durumda tutma işi geliştiricilere değil NOC'ye düşmektedir. NOC'mizde hiç kimse resmi bir SQL eğitimi almamıştır ve sadece bir yönetim aracı bakış açısından ikisi arasındaki farklar bunu dikkate almak için yeterlidir.

3) Mevcut ürünleri yükseltme maliyeti. Bizim için bu büyük bir tane. Burada Microsoft'un lisans maliyetinden bahsetmiyorum. İşimizde, mevcut ürünlerimizden herhangi birinde bir yükseltme (sahada zaten olan her şeyi geriye dönük olarak yükseltmesek bile), birkaç farklı düzenleme ve onaylama test laboratuarı aracılığıyla pahalı ve uzun bir yeniden sertifikalandırma süreci gerektirecektir. SQL2005 üzerinde yeni ürünler geliştiriyoruz, ancak bu nedenle eski ürünleri yükseltmiyoruz.

Sertifikasyon süreci aynı zamanda, onayların henüz alınıp alınmadığına bağlı olarak, bazı yargı bölgelerinin SQL2000 ve diğerlerinin SQL2005 alacağı yeni yapılarda bir karışımla sonuçlanacağımız anlamına gelir. 2. nedenden dolayı üretim ortamımızı olabildiğince tutarlı tutmayı tercih ediyoruz.

4) Genel farklılıklar. Bu gerçekten # 1'in bir uzantısı. Değişen, bazıları başımıza neden olan birçok küçük şey var. Örneğin, Server2003 üzerindeki SQL2005, sql hesaplarında Windows parola ilkelerini zorunlu kılacaktır. Tek başına kötü bir şey değil, ama veritabanımızla etkileşime girme şeklimiz nedeniyle neredeyse tüm (ve çok sayıda üçüncü taraf) yazılımımızı bozuyor.

Kısacası, atalet.

Bir iyi blog yazısı zaten aynı soruyu sordu.

Windows 2000 sistemlerini desteklemek zorunda oldukları için .NET 1.1 kullanması gereken insanlar olduğunu biliyorum.

Bu mantığın ardından MSSQL 2000'i çalıştırmanın pratik bir nedeni, Windows NT 4 sistemlerini destekleyebilmenizdir!

İster inanın ister inanmayın, ancak SQL Server 2005 aslında Windows Server 2000'de çalışır.