SQL Server: O que são instâncias nomeadas e padrão?

O que são instâncias nomeadas e padrão? Qual é / são as diferenças entre eles? Por que eles são usados?

De acordo com a Microsoft sobre nomeado vs padrão

Os aplicativos clientes se conectam a uma instância do Microsoft SQL Server 2005 para trabalhar com um banco de dados do SQL Server. Cada instância do SQL Server é composta por um conjunto distinto de serviços que podem ter configurações exclusivas. A estrutura de diretórios, a estrutura do registro e o nome do serviço refletem o nome da instância específica que você identifica durante a instalação.

Uma instância é a instância padrão, sem nome, ou é uma instância nomeada. Quando o SQL Server 2005 está instalado na instância padrão, não é necessário que um cliente especifique o nome da instância para fazer uma conexão. O cliente precisa apenas saber o nome do servidor.

Uma instância nomeada é identificada pelo nome da rede do computador mais o nome da instância que você especifica durante a instalação. O cliente deve especificar o nome do servidor e o nome da instância ao se conectar.

Por padrão, o SQL Server é instalado na instância padrão, a menos que você especifique um nome de instância. O SQL Server Express, no entanto, sempre é instalado em uma instância nomeada, a menos que você force uma instalação padrão durante a instalação.

Além disso, você pode instalar apenas uma padrão (instância sem nome), mas pode instalar muitas instâncias nomeadas.

Muitos softwares de terceiros geralmente usam uma instância nomeada padrão, embora não possam mencioná-la. O motivo é claro nas respostas acima: as versões padrão instalam uma instância sem nome por padrão, enquanto a versão Express instala uma instância nomeada por padrão.

É importante saber sobre a diferença dessa perspectiva, porque se você tiver 2 ou 3 servidores de banco de dados em execução, poderá nunca se conectar à versão correta. Como o software de terceiros está procurando a instância padrão enquanto você pensa que é a instância do SQLEXPRESS à qual está tentando se conectar. Isso pode aumentar significativamente o tempo de solução de problemas, se você não souber como se conectar a uma instância nomeada versus não nomeada.

Portanto, se você deseja se conectar à Versão Nomeada ou Sem Nome, use as seguintes diretrizes.

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

Observe que, embora uma instância padrão tenha um nome, ela não pode ser referenciada por seu nome!

Além da explicação que Brett G postou, aqui estão alguns motivos para usá-los:

• Você pode ter instâncias diferentes usando versões diferentes do SQL (ou seja, padrão usando o SQL 2008, chamada instância usando o SQL 2005)
• Separação de preocupações, seja algo com seu aplicativo ou segurança ou qualquer outra coisa
• Diferentes ambientes de desenvolvimento
• Diferentes ambientes de aplicativos (por exemplo, caseiro versus terceiros)

Todos os tipos de razões para usá-los. No entanto, isso não significa que é sempre uma boa ideia: P

Outra diferença prática: o SQL2005 e versões posteriores permitem instalar 16 ou mais instâncias por sistema. Como o licenciamento é por CPU física , por instalação do servidor SQL (e não por instância!), Isso significa que você pode executar até 16 instâncias do SQL Server 2005 sem pagar um centavo a mais do que já pagou.

Dado que as licenças de CPU podem custar US $ 15000 (!) Por soquete, este é um item obrigatório para instalações grandes com, digamos, 16 núcleos e 256 GB de memória.

Você também pode limitar a memória e atribuir o uso limite do processador por instância. Você também pode criar uma instância para aplicativos escritos pelo fornecedor que 'precisem' de privilégios de administrador do sistema, para não colocar outros aplicativos em risco.

Uma das melhores razões é a separação de bancos de dados. Se você estiver desenvolvendo seu próprio aplicativo e empacotando o SQL Express com ele, faz sentido instalá-lo em sua própria instância. Além disso, oferece ao usuário a opção de especificar uma instalação SQL existente, se for o caso.

Se você tiver um banco de dados crítico que deseja garantir que ninguém mais tenha acesso, ele poderá entrar em sua própria instância com uma autorização de segurança muito limitada. Digamos que esse seja o seu banco de dados de produção e, em seguida, ele replica para o banco de dados de relatórios no mesmo servidor **, que é lido somente para pessoas. É menos provável que, apesar do erro do usuário (administrador), os usuários obtenham acesso acidental ao banco de dados de produção, limitando quem realmente é capaz de atualizar os grupos de segurança na instância de produção para apenas algumas pessoas.

** Boas práticas recomendam tornar o servidor de relatórios uma máquina separada, mas estou fazendo isso como um exemplo.