Se um usuário do banco de dados do servidor SQL tiver public
permissão apenas server roles
para um banco de dados específico db_datareader
e public
permissão, ao tentar script index as CREATE To
a opção no SSMS, o script gerado não estará correto.
Quero dizer, se um índice tiver uma condição filtrada, essa condição filtrada não será exibida
Portanto, para um usuário que tenha permissão de proprietário, script index as CREATE To
será exibido
USE [test]
GO
/****** Object: Index [filtered] Script Date: 12/30/2013 18:54:19 ******/
CREATE NONCLUSTERED INDEX [filtered] ON [dbo].[Table_1]
(
[b] ASC
)
WHERE ([Table_1].[b] IS NULL)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
Para um usuário que só tem db_datareader
permissão script index as CREATE To
mostrará
USE [test]
GO
/****** Object: Index [filtered] Script Date: 12/30/2013 18:55:13 ******/
CREATE NONCLUSTERED INDEX [filtered] ON [dbo].[Table_1]
(
[b] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
Tudo bem se um usuário db_datareader
não tiver permissão para ver o script de um índice e mostrar um erro de acesso negado. Mas mostra script inválido. Além disso, se as propriedades do índice estiverem marcadas, apenas a condição filtrada não será exibida e outras propriedades do índice serão exibidas. Por que isso acontece?
É por design.
Posso entender por que pode ser confuso poder ver metadados parciais. No entanto, a ideia por trás da função de dados db_datareader é conceder ao usuário acesso de leitura aos dados do usuário, bem como às informações da coluna. (você não seria capaz de criar uma instrução SELECT se também não tivesse acesso aos nomes das colunas.)
Portanto, com isso em mente, mostrar apenas a parte da definição do índice que contém as informações da coluna estaria perfeitamente dentro dos limites da permissão do leitor de dados.
A cláusula de índice filtrado, no entanto, é considerada informação não coluna, portanto, você precisa de mais permissão para poder ver esta parte da definição também.
Você precisa da permissão VIEW DEFINITION naquele objeto, ou VIEW ANY DEFINITION para poder ver aquele bit extra de metadados.
Eu acho que seria bom se eles dessem um aviso quando você gerasse um script CREATE "incompleto".
Você mesmo pode testar:
É verdade que um db_datareader não pode confirmar diretamente o índice filtrado onde a cláusula (sys.indexes.filter_definition) e o SSMS não avisará um db_datareader que o script da definição do índice estará incompleto.
No entanto, há uma solução alternativa que um db_datareader pode usar para confirmar indiretamente o filter_definition: especifique uma dica de índice em uma consulta, com uma cláusula where para testar a cobertura pelo índice filtrado.
O MS-SQL lançará um erro se uma coluna ou valor especificado na cláusula where da consulta NÃO for coberto pela cláusula where do índice filtrado (sys.indexes.filter_definition).
Dessa forma, você pode pelo menos verificar se a cláusula where da consulta que você gostaria de usar está coberta pelo índice filtrado. Você não precisa usar a dica de índice na produção, depois de verificá-la dessa maneira.
Por exemplo, se um índice filtrado for criado por um db_owner como este:
Então, como db_datareader, posso confirmar que esta consulta funciona, então confirmei que
IsPrimaryCity = 1
está coberta pelo índice:Também como db_datareader, posso confirmar que esta consulta falha, então confirmei que
IsPrimaryCity = 0
NÃO é coberto pelo índice:A mensagem de erro retornada pelo MS-SQL é: