Geliştirici'den Enterprise'a kadar iyi olacak, işlemci lisansı kullanıyorsanız, hedef sunucuda tüm CPU'ları kapsayacak şekilde lisanslara sahip olduğunuzdan emin olun. Ve onları sadece SQL'den gizlemek yeterli değildir, makineye fiziksel olarak bağlılarsa, siz sorumlusunuz.
Ayrıca daha düşük bir yapıdan daha yüksek bir yapıya geçtiğinizde veritabanı sürümünüz artacaktır. Bunun sorunlu olabileceği birkaç senaryo vardır - örneğin, 2008'in belirli bir yapısında 15.000 bölüm desteği kullanıyorsanız, belirli bir 2008 R2 yapısına yükselttiğinizde çalışmaz. Ayrıca, daha eski bir derlemedeki hatalar olan ancak yeni derlemede düzeltilen optimizasyonlara da güveniyor olabilirsiniz (ve yerinde geçici çözümlere sahip olabilirsiniz) ve bu durum daha kötü performansa neden olabilir. Kaynakta kullanılan iz bayraklarını gözden geçirmek ve hedefte de etkinleştirilip etkinleştirilmeyeceklerini belirlemek de önemlidir. İşleri, girişleri vb.
Tabii ki geriye gidemezsiniz. 10.0.5512 -> 10.0.5500 gibi küçük bir sürüm düşürmeyi hiç denemedim, ancak hizmet paketi veya sürümde aşağı inmek kesinlikle mümkün değil. Dolayısıyla, Geliştirici Sürümü örneğinizde 2012 veritabanınız varsa ve bunu 2008 örneğinizde üretime geçirmek istiyorsanız, işinizi sizin için kesmiş olacaksınız ( buraya ve buraya bakın ) - özellikle 2012 özelliklerini kullandıysanız .
Ancak, insanları bu soruya yönlendirebilecek diğer durumları kapsamak için (örneğin, birisi Geliştirici -> Standart veya Kurumsal -> Ekspres'ten ne almak istiyorsa)
Express'te desteklenmeyen herhangi bir özellik kullandıysanız (ve gerçekten Enterprise dışındaki herhangi bir sürüm için de geçerlidir), örneğin iyi gitmeyecek başka sürüm -> sürüm yükseltmeleri de vardır. Alt düzey sürümlerde kullanamayacağınız bazı özellik örnekleri (bu durumda geri yükleme, veritabanını çevrimiçi duruma getirmeye çalıştığı noktada ölecektir):
- Bölümleme
- Veri Yakalamayı Değiştir
- Veri sıkıştırma
- Şeffaf Veri Şifreleme
Bunu doğrudan .BAK dosyasından anlamanın bir yolu olup olmadığını bilmiyorum (eminim ki, bir yerde sayfa başlıklarından çıkarılabilecek bir sihir var veya bir hex editörü ile yazmak için bir hafta sonu varsa) , ancak veritabanı hala kaynak örnekte olduğu halde, bulunduğunuz SKU nedeniyle kullanılabilen herhangi bir özellik kullanıp kullanmadığınızı görmek için aşağıdakileri yapabilirsiniz:
SELECT feature_name FROM sys.dm_db_persisted_sku_features;
SQL Server Denetiminin bu listede olması gerekip gerekmediğinden emin değilim - bu özelliğin sürüm ayrıcalığı değişti, bu yüzden muhtemelen onunla ne yaptığınıza bağlı. Kullanabileceğiniz ancak DMV'de görünmeyeceğiniz başka şeyler de vardır (bazıları kodunuzda olduğu için DMV ayrıştırmaz ve bazıları veritabanınız SQL Server Agent gibi harici şeylere güvenir. , Hizmet Aracısı vb.):
- yansıtma
- belirli çoğaltma şekilleri
- günlük nakliye
- veritabanı anlık görüntüleri
- çevrimiçi indeksleme
- güncellenebilir dağıtılmış bölümlenmiş görünümler
- yedek sıkıştırma
- politikaya dayalı yönetim
- plan rehberleri
- veritabanı postası
- bakım planları
- tam metin araması
Dosya boyutu sınırlamaları nedeniyle Geliştirici'den Ekspres'e geçemeyeceğiniz durumlar da vardır (Express veritabanları toplam veri dosyası boyutunda 10 GB ile sınırlıdır).
Elbette, uyarılmayacağınız başka gotcha'lar da olabilir - göçü engellemeyecekler, ancak hedefte çok farklı performanslara yol açabilirler. Örnekler:
- Hedef sürümde farklı bellek / CPU sınırlamaları (hatta hedefin altında yatan işletim sistemi). Bu, 2008 R2 Enterprise'dan hizmetin yapay olarak ilk 20 çekirdekle sınırlı olduğu 2012 Enterprise'a (CAL) giden bir sürü insan. Bu, basit performans farklılıklarına yol açabilir (örneğin, bir sorguyu tatmin etmek için yeterli bellek veya çok daha yavaş paralel sorgu performansı); daha incelikli olanları, altta yatan farklı donanım nedeniyle yapılan plan seçimlerini içerir.
- Kullanılacak kaynak kodu değiştirilmeden, kaynaktaki dizine alınmış görünüm eşleşmesi gibi özelliklere güvenme otomatik olarak hedefe saygı gösterilmez
NOEXPAND. Ve bu yeteneğin, sorgularınızın neden aniden yavaşladığının farkında bile olmayabilirsiniz.
- Aynı şey paralel indeks işlemleri ve muhtemelen bu an akla gelmeyen diğer optimizasyonlar için de geçerlidir (neyse ki neredeyse sadece Enterprise alanında çalışıyorum, bu yüzden çoğu durumda daha düşük sürümlerin sınırlamaları hakkında endişelenmem gerekmiyor ).
GÜNCELLEME dayalı bu kopya :
Bir veritabanını belirli bir sürümden daha küçük bir sürüme (aynı sürümde bile) geri yüklemeye çalıştığınız durumlar olabilir ve daha az yardımcı olan hatalar alırsınız :
RESTORE, sunucu 'sunucu \ örneği' için başarısız oldu.
RESTORE veritabanı 'veritabanıadı' başlatamadı.
Bu çok sezgisel değil. Ancak SQL Server'ın olay günlüklerinde daha derin bakarsanız, daha kullanışlı hatalar görürsünüz (sadece bir örnek):
Veritabanı işlevlerinden bazıları SQL Server'ın geçerli sürümünde bulunmadığından, veritabanı 'veritabanı adı' başlatılamıyor.
'_Dta_pf__9987' bölümleme işlevi içerdiğinden, 'databasename' veritabanı SQL Server'ın bu sürümünde başlatılamaz. SQL Server'ın yalnızca Enterprise sürümü bölüm işlevlerini destekler.
Şimdi, bu tam olarak doğru değil - Değerlendirme Sürümü veya Geliştirici Sürümü'ne de geri dönebilirsiniz, ancak bu konunun yanında. Bu veritabanını geri yüklemek için temel olarak iki seçeneğiniz vardır:
- SQL Server'ın uygun bir sürümüne geri yükleme - yeni bir örneği bulma veya yükleme anlamına gelir.
- Kaynak sunucudaki yedeklemeyi farklı bir adla yeni bir veritabanı olarak geri yükleyin, tüm Enterprise özelliklerini kaldırın, ardından veritabanını yeniden yedekleyin ve daha az sürümde geri yükleyin. (Bu özel durumda, bölüm işlevinin adını hata iletisinde bıraktım, çünkü bu yine de kayda değer bir şey gibi görünüyor - Veritabanı Altyapısı Ayarlama Danışmanı tarafından oluşturuldu ve bunu tam olarak yapmayan biri tarafından yapılmış olabilir ne yaptıklarını bilmek. Bu her zaman böyle değildir.)
(2) 'deki bir varyasyon sadece kaynak veritabanındaki bölümleme ve diğer özellikleri kaldırmak ve başka bir yedek almak olacaktır. Ama eğer kırılmazsa ...