SQL Server: Adlandırılmış ve varsayılan örnekler nedir?

Adlandırılmış ve varsayılan örnekler nedir? Aralarındaki fark (lar) nedir? Neden kullanılırlar?

Microsoft'a göre adlandırılmış ve varsayılan olarak

İstemci uygulamaları, bir SQL Server veritabanıyla çalışmak için bir Microsoft SQL Server 2005 örneğine bağlanır. Her SQL Server örneği, benzersiz ayarlara sahip olabilecek farklı servislerden oluşur. Dizin yapısı, kayıt defteri yapısı ve hizmet adı, kurulum sırasında tanımladığınız belirli örnek adını yansıtır.

Bir örnek, varsayılan, adsız örnek veya adlandırılmış bir örnekdir. SQL Server 2005, varsayılan örnekte kurulu olduğunda, istemcinin bağlantı kurması için örneğin adını belirtmesi gerekmez. İstemcinin sadece sunucu adını bilmesi gerekir.

Adlandırılmış bir örnek, bilgisayarın ağ adı ve yükleme sırasında belirttiğiniz örnek adı ile tanımlanır. İstemci, hem sunucu adını hem de bağlanırken örnek adını belirtmelidir.

Varsayılan olarak, bir örnek adı belirtmediğiniz sürece SQL Server varsayılan örneğe yüklenir. Ancak, SQL Server Express, kurulum sırasında varsayılan bir yüklemeyi zorlamadığınız sürece her zaman adlandırılmış bir durumda yüklenir.

Ayrıca yalnızca bir varsayılan (adsız örnek) yükleyebilirsiniz, ancak çok sayıda adlandırılmış örnek yükleyebilirsiniz.

Birçok üçüncü parti yazılım, genellikle bahsetmese de varsayılan bir örnek kullanır. Nedeni yukarıdaki cevaplardan açıkça anlaşılmaktadır. Standart sürümler varsayılan olarak adlandırılmamış bir örnek yüklerken, standart sürümler varsayılan olarak adlandırılmamış bir örnek yükler.

Bu perspektiften farkı bilmek önemlidir, çünkü çalışan 2 veya 3 DB Sunucunuz varsa, asla doğru sürüme bağlanamayabilirsiniz. Çünkü, üçüncü parti yazılımı, bağlanmaya çalıştığı SQLEXPRESS örneği olduğunu düşünürken varsayılan örneği arıyor. Adlandırılmış bir adsız örneğe nasıl bağlanacağınızı bilmiyorsanız, sorun giderme süresini önemli ölçüde artırabilir.

Dolayısıyla, Adlandırılmış veya Adsız Sürüm'e bağlanmak istiyorsanız, aşağıdaki yönergeleri kullanın.

MY-MACHINE-NAME\SQLEXPRESS  /* named version - correct */
MY-MACHINE-NAME             /* unnamed version (default instance) - correct */
MY-MACHINE-NAME\MSSQLSERVER /* unnamed version (default instance) - Wrong */

Varsayılan örneğin bir adı olmasına rağmen, ismiyle referans alınamayacağını unutmayın!

Brett G tarafından yayınlanan açıklamaya ek olarak, bunları kullanmanın nedenleri hakkında bazı nedenler:

• Farklı SQL sürümlerini kullanarak farklı örneklere sahip olabilirsiniz (örneğin, SQL 2008 kullanarak, örneğin SQL 2005 kullanarak adlandırılmış)
• Endişelerin ayrılması, uygulamanızla veya güvenliğinizle ilgili bir şey veya ne olursa olsun
• Farklı geliştirme ortamları
• Farklı uygulama ortamları (ör. Üçüncü tarafa karşı)

Bunları kullanmak için her türlü sebep. Yine de, her zaman iyi bir fikir olduğu anlamına gelmez: P

Yine bir başka pratik fark: SQL2005 ve üzeri, sistem başına 16 veya daha fazla örnek yüklemenizi sağlar. Lisanslama, fiziksel CPU başına, SQL sunucunun kurulumu başına (ve örneğin değil !) Olduğundan, bu, halihazırda olduğundan bir kuruş ödemeden 16 örnek SQL Server 2005 çalıştırabileceğiniz anlamına gelir.

CPU lisanslarının soket başına 15.000 ABD Doları (!) Çalıştırabileceği göz önüne alındığında, bu, 16 çekirdek ve 256 GB belleğe sahip büyük kurulumlar için sahip olunması gereken bir şeydir.

Ayrıca belleği kapatabilir ve örnek başına limit işlemci kullanımını atayabilirsiniz. Ayrıca, sistem yöneticisi ayrıcalıklarına ihtiyaç duyan satıcı yazılı uygulamalar için bir örnek oluşturabilirsiniz, böylece diğer uygulamalarınızı riske atmazsınız.

En iyi sebeplerden biri veritabanlarının ayrılmasıdır. Kendi uygulamanızı geliştiriyor ve onunla birlikte SQL Express'i paketliyorsanız, onu kendi örneğine yüklemek mantıklı olacaktır. Ek olarak, kullanıcıya bunu düşünse varolan bir SQL kurulumunu belirleme seçeneği sunar.

Başka hiç kimsenin erişemediğinden emin olmak istediğiniz kritik bir veritabanınız varsa, çok sınırlı bir güvenlik yetkisi ile kendi örneğine girebilir. Prodcution DB'niz olduğunu ve aynı sunucudaki ** yalnızca DB'ler için okunan raporlama DB'sine çoğaldığını varsayalım. Kullanıcı (yönetici) hatası, kullanıcıların üretim örneğindeki güvenlik gruplarını gerçekte kimin yalnızca birkaç kişiyle güncelleyebileceğini sınırlandırarak, üretim DB'sine yanlışlıkla erişebilmesinden kaynaklanır.

** İyi uygulama, raporlama sunucusunu ayrı bir makine haline getirme diyor, ancak bunu örnek olarak yapıyorum.