Início / dba / Perguntas / 58170
Accepted
PseudoToad
Asked: 2014-02-04 13:32:33 +0800 CST

Servidores vinculados ao SQL Server e estatísticas remotas

  • 772

Estou tentando entender melhor como o SQL Server usa estatísticas em SQL Servers remotos (por exemplo, um servidor vinculado). Entendo que o usuário precisa dos direitos db_owner/db_ddladmin para poder usar as estatísticas na caixa remota. A princípio, isso parece muito direto com base no texto abaixo da Microsoft.

Para criar os melhores planos de consulta ao usar uma tabela em um servidor vinculado, o processador de consulta deve ter estatísticas de distribuição de dados do servidor vinculado. Os usuários que têm permissões limitadas em qualquer coluna da tabela podem não ter permissões suficientes para obter todas as estatísticas úteis e podem receber um plano de consulta menos eficiente e ter um desempenho insatisfatório. Se o servidor vinculado for uma instância do SQL Server, para obter todas as estatísticas disponíveis, o usuário deve possuir a tabela ou ser membro da função de servidor fixa sysadmin, da função de banco de dados fixa db_owner ou da função de banco de dados fixa db_ddladmin no servidor vinculado .

A parte que está me confundindo é a palavra "Usuário". Usamos um contexto de segurança padrão para todas as conexões, em vez do login do usuário. Este login/usuário possui as permissões necessárias conforme definido acima sobre os bancos de dados em questão. Além disso, não usamos representação.

Tentei executar consultas e capturar os rastreamentos em ambas as extremidades usando contas com e sem permissões elevadas no servidor de remoção. Parece-me que o servidor remoto não está coletando estatísticas, a menos que o usuário real (o cara no teclado) tenha os direitos elevados. Acredito que isso seja verdade porque só estou vendo chamadas para sys.sp_table_statistics2_rowset quando o usuário tem os direitos necessários.

Eu realmente espero que isso faça sentido.

Alguém tem uma compreensão de como isso realmente funciona no SQL 2008 R2 e abaixo?

sql-server sql-server-2008-r2

2 respostas

  1. Best Answer

    O que eu faço é este 'truque':

    Dê a leitura a este 'linkuser', tudo o que for necessário e ddl_admin privilégios, e execute o seguinte script para garantir que nenhum dos ddl_adminprivilégios possa realmente ser usado.

    Mas, por ser tecnicamente membro do ddl_adminusuário, agora pode ver as estatísticas no banco de dados remoto! (nota: a partir do SQL2012SP1 não há necessidade deste hack, as estatísticas estão visíveis como deveriam estar)

    DENY CREATE TABLE TO [LinkUser]
DENY CREATE VIEW TO [LinkUser]
DENY CREATE PROCEDURE TO [LinkUser]
DENY CREATE FUNCTION TO [LinkUser]
DENY CREATE RULE TO [LinkUser]
DENY CREATE DEFAULT TO [LinkUser]
DENY CREATE TYPE TO [LinkUser]
DENY CREATE ASSEMBLY TO [LinkUser]
DENY CREATE XML SCHEMA COLLECTION TO [LinkUser]
DENY CREATE SCHEMA TO [LinkUser]
DENY CREATE SYNONYM TO [LinkUser]
DENY CREATE AGGREGATE TO [LinkUser]
DENY CREATE MESSAGE TYPE TO [LinkUser]
DENY CREATE SERVICE TO [LinkUser]
DENY CREATE CONTRACT TO [LinkUser]
DENY CREATE REMOTE SERVICE BINDING TO [LinkUser]
DENY CREATE ROUTE TO [LinkUser]
DENY CREATE QUEUE TO [LinkUser]
DENY CREATE SYMMETRIC KEY TO [LinkUser]
DENY CREATE ASYMMETRIC KEY TO [LinkUser]
DENY CREATE FULLTEXT CATALOG TO [LinkUser]
DENY CREATE CERTIFICATE TO [LinkUser]
DENY CREATE DATABASE DDL EVENT NOTIFICATION TO [LinkUser]
DENY CHECKPOINT TO [LinkUser]
DENY ALTER ANY SCHEMA TO [LinkUser]
DENY ALTER ANY ASSEMBLY TO [LinkUser]
DENY ALTER ANY DATASPACE TO [LinkUser]
DENY ALTER ANY MESSAGE TYPE TO [LinkUser]
DENY ALTER ANY CONTRACT TO [LinkUser]
DENY ALTER ANY SERVICE TO [LinkUser]
DENY ALTER ANY REMOTE SERVICE BINDING TO [LinkUser]
DENY ALTER ANY ROUTE TO [LinkUser]
DENY ALTER ANY FULLTEXT CATALOG TO [LinkUser]
DENY ALTER ANY SYMMETRIC KEY TO [LinkUser]
DENY ALTER ANY ASYMMETRIC KEY TO [LinkUser]
DENY ALTER ANY CERTIFICATE TO [LinkUser]
DENY REFERENCES TO [LinkUser]
DENY ALTER ANY DATABASE DDL TRIGGER TO [LinkUser]
DENY ALTER ANY DATABASE EVENT NOTIFICATION TO [LinkUser]
    • 6

  2. Bem, realmente depende de como você configura o contexto de segurança do servidor vinculado, certo? Se o cara sentado ao teclado não tiver nenhum direito no servidor remoto, então como a conexão é feita: será cortada, usará o contexto de segurança atual ou representará um login específico no remoto servidor? Acho que é aqui que você precisa focar sua atenção. Em nosso ambiente PROD, configuramos um usuário que possui privilégios de administrador de leitura, gravação e ddl e todas as conexões são feitas usando o contexto de segurança desse login/senha remoto. Eu espero que isso ajude.

    • -2

relate perguntas