O objetivo principal dos bancos de dados contidos é facilitar a portabilidade do banco de dados para um novo servidor sem muitos andaimes. Com isso em mente, tratarei alguns problemas em potencial que dificultarão essa migração - e a maioria gira em torno do fato de que os bancos de dados contidos estão apenas parcialmente contidos no SQL Server 2012 (a contenção não é realmente imposta).
Strings de conexão
As cadeias de conexão com um banco de dados contido devem especificar explicitamente o banco de dados na cadeia de conexão. Você não pode mais confiar no banco de dados padrão do logon para estabelecer uma conexão; se você não especificar um banco de dados, o SQL Server não percorrerá todos os bancos de dados contidos e tentará encontrar qualquer banco de dados em que suas credenciais possam corresponder.
Consultas entre bancos de dados
Mesmo se você criar o mesmo usuário com a mesma senha em dois bancos de dados diferentes contidos no mesmo servidor, seu aplicativo não poderá executar consultas entre bancos de dados. Os nomes de usuários e senhas pode ser o mesmo, mas eles são não o mesmo usuário. A razão disso? Se você possui bancos de dados em um servidor hospedado, não deve ser impedido de ter o mesmo usuário contido que outra pessoa que esteja usando o mesmo servidor hospedado. Quando chega a contenção total (provavelmente na versão após o SQL Server 2012 nunca), as consultas entre bancos de dados serão absolutamente proibidas de qualquer maneira. Eu recomendo que você não crie logins no nível do servidor com o mesmo nome que os usuários de banco de dados contidos e tente evitar a criação do mesmo nome de usuário contido nos bancos de dados contidos. Se você precisar executar consultas que atinjam vários bancos de dados contidos, faça-o usando um logon no nível do servidor que possua privilégios apropriados (você pode pensar que sysadmin
sim, mas para consultas somente leitura, é CONNECT ANY DATABASE
e SELECT ALL USER SECURABLES
).
Sinônimos
A maioria dos nomes de 3 e 4 partes é fácil de identificar e aparece em uma DMV. No entanto, se você criar um sinônimo que aponte para um nome de 3 ou 4 partes, eles não aparecerão na DMV. Portanto, se você fizer uso pesado de sinônimos, é possível que você perca algumas dependências externas e isso pode causar problemas no momento em que você migra o banco de dados para um servidor diferente. Reclamei sobre esse problema, mas ele foi fechado como "por design" e não sobreviveu à migração para o novo sistema de feedback . Observe que o DMV também perderá nomes de 3 e 4 partes que são construídos via SQL dinâmico.
Política de senha
Se você criou um usuário de banco de dados contido em um sistema sem uma política de senha em vigor, pode ser difícil criar o mesmo usuário em um sistema diferente que possui uma política de senha. Isso ocorre porque a CREATE USER
sintaxe não suporta ignorar a política de senha. Eu registrei um bug sobre esse problema, e ele permanece aberto (e também não sobreviveu à mudança quando o Connect foi retirado). E me parece estranho que, em um sistema com uma política de senha, você possa criar um logon no nível do servidor que ignore facilmente a política, mas não possa criar um usuário de banco de dados que o faça - mesmo que esse usuário seja inerentemente menos risco de segurança.
Agrupamento
Como não podemos mais confiar no agrupamento do tempdb, pode ser necessário alterar qualquer código que atualmente usa agrupamento explícito ou DATABASE_DEFAULT
usá-lo CATALOG_DEFAULT
. Consulte este artigo da BOL para alguns problemas em potencial .
IntelliSense
Se você se conectar a um banco de dados contido como um usuário contido, o SSMS não oferecerá suporte total ao IntelliSense. Você terá sublinhado básico para erros de sintaxe, mas nenhuma lista ou dicas de ferramenta de preenchimento automático e todas as coisas divertidas. Eu registrei um bug sobre esse problema, e ele permanece aberto - e mais um que não sobreviveu à mudança.
Ferramentas de dados do SQL Server
Se você planeja usar o SSDT para desenvolvimento de banco de dados, atualmente não há suporte completo para bancos de dados contidos. O que realmente significa apenas que a construção do projeto não falhará se você usar algum recurso ou sintaxe que quebre a contenção, pois o SSDT atualmente não sabe o que é a contenção e o que pode quebrá-la.
ALTER DATABASE
Ao executar um ALTER DATABASE
comando a partir do contexto de um banco de dados contido, r Em vez de ALTER DATABASE foo
você precisar usá ALTER DATABASE CURRENT
-lo - é para que, se o banco de dados for movido, renomeado, etc., esses comandos não precisem saber nada sobre seu contexto ou referência externa. .
Alguns outros
Algumas coisas que você provavelmente ainda não deveria estar usando, mas devem ser mencionadas na lista de coisas que não são suportadas ou estão obsoletas e não devem ser usadas em bancos de dados contidos:
- procedimentos numerados
- procedimentos temporários
- mudanças de agrupamento em objetos vinculados
- alterar captura de dados
- rastreamento de alterações
- replicação
Dito isso, essas não são necessariamente desvantagens do uso de bancos de dados contidos, são apenas questões que você deve estar ciente e nem todas são explicitamente divulgadas na documentação oficial.
Você também precisará ter certeza de que, se um banco de dados contido for migrado ou fizer parte de um grupo de disponibilidade ou estiver sendo espelhado, todos os servidores de destino em potencial tenham a sp_configure
opção contained database authentication
definida como 1.
Você pode achar útil este post do blog , bem como este , mesmo que eles sejam anteriores à RTM.
Para quem estiver interessado em obter mais detalhes sobre bancos de dados contidos, recomendo que leiam este artigo http://www.sqlshack.com/contained-databases-in-sql-server/
O artigo aponta as principais vantagens / desvantagens do uso de bancos de dados contidos.
Desvantagens
Bancos de dados parcialmente contidos não podem usar recursos como replicação, captura de dados alterados, rastreamento de alterações, objetos vinculados ao esquema que dependem de funções internas com alterações de agrupamento.
Vantagens
Por outro lado, como já mencionado, existem alguns benefícios do uso de bancos de dados contidos, como:
pois não haverá problemas de usuários órfãos
O artigo também ajuda com:
fonte
Uma desvantagem é que um usuário de banco de dados contido não pode ser forçado a alterar sua própria senha como os logins poderiam (
MUST_CHANGE
). Os usuários não podem gerenciar sua própria senha, a menos que você conceda a eles uma permissão de usuário alterado e diga a eles como alterá-la usando uma instrução SQL. Em nenhum lugar é fácil gerenciá-lo por meio de interfaces de usuário ou pelo menos não sei como.Nota adicional é que, encontrei o uso inesperado e não documentado de metadados na cláusula "PIVOT" AND "UNPIVOT", que eu pensava que deveria estar apenas no catálogo do sistema (sys.tables / sys.columns / etc). Conforme documentado no msdn :
Mas eles não mencionaram que a cláusula "PIVOT" E "UNPIVOT" também usa os catálogos do sistema como um mecanismo de execução. portanto, produz um erro conflitante de agrupamento em qualquer lugar próximo ao uso da cláusula "PIVOT" E "UNPIVOT" durante a migração. aqui está uma repro:
Você também pode ver que os artigos sobre o banco de dados contido estão incompletos. então, decidir usá-lo precisa de uma improvisação muito boa.
fonte