SQL Server: que sont les instances nommées et par défaut?
Que sont les instances nommées et par défaut? Quelle est/sont la (les) différence (s) entre eux? Pourquoi sont-ils utilisés?
Selon Microsoft concernant le nom par rapport au défaut
Les applications clientes se connectent à une instance de Microsoft SQL Server 2005 pour fonctionner avec une base de données SQL Server. Chaque instance de SQL Server est composée d'un ensemble distinct de services pouvant avoir des paramètres uniques. La structure du répertoire, la structure du registre et le nom du service reflètent tous le nom d'instance spécifique que vous identifiez lors de l'installation.
Une instance est soit l'instance par défaut sans nom, soit une instance nommée. Lorsque SQL Server 2005 est installé dans l'instance par défaut, il n'est pas nécessaire qu'un client spécifie le nom de l'instance pour établir une connexion. Le client n'a qu'à connaître le nom du serveur.
Une instance nommée est identifiée par le nom de réseau de l'ordinateur plus le nom d'instance que vous spécifiez lors de l'installation. Le client doit spécifier à la fois le nom du serveur et le nom de l'instance lors de la connexion.
Par défaut, SQL Server s'installe dans l'instance par défaut, sauf si vous spécifiez un nom d'instance. SQL Server Express, cependant, s'installe toujours dans une instance nommée, sauf si vous forcez une installation par défaut lors de l'installation.
Vous pouvez également installer une seule instance par défaut (instance sans nom) mais vous pouvez installer de nombreuses instances nommées.
De nombreux logiciels tiers utilisent généralement une instance nommée par défaut bien qu'ils ne le mentionnent pas. La raison est claire à partir des réponses ci-dessus, les versions standard installent une instance sans nom par défaut tandis que la version Express installe une instance nommée par défaut.
Il est important de connaître la différence de ce point de vue car si vous avez 2 ou 3 serveurs DB en cours d'exécution, vous risquez de ne jamais vous connecter à la bonne version. Parce que le logiciel tiers recherche l'instance par défaut pendant que vous pensez que c'est l'instance SQLEXPRESS à laquelle il essaie de se connecter. Cela peut augmenter considérablement votre temps de dépannage si vous ne savez pas comment vous connecter à une instance nommée ou non nommée.
Donc, si vous souhaitez vous connecter à une version nommée ou sans nom, utilisez les instructions suivantes.
MY-MACHINE-NAME\SQLEXPRESS /* named version - correct */
MY-MACHINE-NAME /* unnamed version (default instance) - correct */
MY-MACHINE-NAME\MSSQLSERVER /* unnamed version (default instance) - Wrong */
Notez que même si une instance par défaut a un nom, elle ne peut pas être référencée par son nom!
En plus de l'explication publiée par Brett G, voici quelques raisons pour lesquelles les utiliser:
- Vous pouvez avoir différentes instances à l'aide de différentes versions de SQL (c'est-à-dire par défaut à l'aide de SQL 2008, instance nommée à l'aide de SQL 2005)
- Séparation des préoccupations, que ce soit avec votre application ou votre sécurité ou autre
- Différents environnements de développement
- Différents environnements d'application (c.-à-d. Faits maison vs tiers)
Toutes sortes de raisons de les utiliser. Cela ne signifie pas que c'est toujours une bonne idée, cependant: P
Encore une autre différence pratique: SQL2005 et plus vous permettent d'installer 16 instances ou plus par système. Étant donné que la licence est par CPU physique , par installation de serveur SQL (et pas par instance!), Cela signifie que vous pouvez exécuter jusqu'à 16 instances de SQL Server 2005 sans payer un cent de plus que vous ne l'avez déjà fait.
Étant donné que les licences CPU peuvent atteindre 15 000 $ (!) Par socket, c'est un must-have pour les grandes installations avec, par exemple, 16 cœurs et 256 Go de mémoire.
Vous pouvez également limiter la mémoire et attribuer une limite d'utilisation du processeur par instance. Vous pouvez également créer une instance pour les applications écrites par les fournisseurs qui ont besoin de privilèges d'administrateur système, afin de ne pas mettre vos autres applications en danger.
L'une des meilleures raisons est la séparation des bases de données. Si vous développez votre propre application et que vous empaquetez SQL Express avec, il est logique de l'installer dans sa propre instance. De plus, donnant à l'utilisateur la possibilité de spécifier une installation SQL existante s'il le souhaite.
Si vous avez une base de données critique à laquelle vous voulez vous assurer que personne d'autre n'a accès, elle peut aller dans sa propre instance avec une autorisation de sécurité très limitée. Supposons qu'il s'agit de votre base de données de production, puis elle se réplique sur la base de données de rapports sur le même serveur ** qui est en lecture seule pour les utilisateurs. Il est moins probable que, si une erreur utilisateur (administrateur) entraîne un accès accidentel à la base de données de production, en limitant à seulement quelques personnes qui est réellement en mesure de mettre à jour les groupes de sécurité sur l'instance de production.
** les bonnes pratiques recommandent de faire du serveur de rapports une machine distincte, mais je ne fais que cela à titre d'exemple.