Midhun C N's questions

Alguém pode me ajudar se houver uma maneira de consultar um banco de dados SQL do Azure usando openrowset com uma conta autenticada por SQL com "aspas simples" em sua string de senha. Minha declaração se parece com a abaixo

(Estou consultando o banco de dados do Azure no local)

SELECT a.*  
FROM OPENROWSET('SQLNCLI11', 'SERVER=sqlserver.database.windows.net,1433;DATABASE=testDB;Uid=admin;Pwd=Fj'C(D=JJ&'XE6vx};','select * from table1 with (nolock)')a

Eu tentei as soluções abaixo

solução 1 - SQL dinâmico

declare @string varchar(max)
set @string=
'SELECT a.*  
FROM OPENROWSET(''SQLNCLI11'', ''SERVER=sqlserver.database.windows.net,1433;DATABASE=testDB;Uid=admin;Pwd="Fj'''+'C(D=JJ&'''+'XE6vx}";'',''select count(*) from dbo.table1 with (nolock)'')a'

exec (@string)

Solução 2 - Passando a senha como parâmetro

declare @string varchar(max)
declare @pwd varchar(max)
set @pwd = 'Fj'''+'C(D=JJ&'''+'XE6vx}'
set @string=
'SELECT a.*  
FROM OPENROWSET(''SQLNCLI11'', ''SERVER=sqlserver.database.windows.net,1433;DATABASE=testDB;Uid=admin;Pwd='+@pwd+';'',''select count(*) from dbo.table1 with (nolock)'')a'

exec (@string)

Todos eles resultam no mesmo erro (aponta para a senha)

Msg 102, Level 15, State 1, Line 16 Sintaxe incorreta perto de 'C'.

usar uma conta autenticada SQL sem qualquer "aspas simples" em sua senha funciona absolutamente bem.

Eu poderia facilmente alterar a senha para corrigir esse problema, mas ainda gostaria de saber se existe uma solução para isso.

Eu estou querendo saber como o SQL Server pode gerar um plano de consulta com "Auto create statistics" definido como "off".

Eu tropecei no contexto abaixo no link abaixo enquanto procurava uma resposta (Desculpe, eu procurei, mas não consegui encontrar nada melhor).

https://www.simple-talk.com/sql/performance/execution-plan-basics/

As variáveis ​​de tabela nunca têm estatísticas geradas sobre elas, então elas sempre são consideradas pelo otimizador como tendo uma única linha, independentemente de seu tamanho real

Embora o acima seja aplicável apenas para variáveis ​​de tabela, pensei que o SQL Server usaria o mesmo princípio para derivar um plano de consulta para uma tabela e decidi fazer um pequeno teste.

Limpei o cache PROC e executei a consulta abaixo em uma tabela com 1 milhão de registros

Meu teste provou que eu estava errado e o SQL Server relatou estatísticas ausentes (como esperado), mas apresentou o número estimado de linhas como 31622 (eu esperava que fosse 1) quando não há estatísticas. Como o otimizador de consulta chegou a esse valor sem estatísticas?

Eu enfrentei um fenômeno estranho hoje. Executei a consulta abaixo para localizar todas as solicitações com espera diferente de BROKER_RECEIVE_WAITFOR

select * from sys.dm_exec_requests where session_id > 55 
and wait_type not like ('BROKER_RECEIVE_WAITFOR') 

A consulta funcionou bem, mas falhou ao listar qualquer solicitação com No waits, ou seja, com wait_type como NULL (havia muitas consultas em execução sem nenhuma espera neste momento).

Por que isso está acontecendo, não deveria listar todos os registros com wait_type diferente de 'BROKER_RECEIVE_WAITFOR' incluindo nulos?

Estou executando o SQL Server 2008R2 SP3.

Recentemente, enfrentei um problema em que o servidor SQL 2012 hospedado em um cluster de failover de 2 nós falhou ao iniciar. E como o log de eventos do cluster e do Windows não ajudou muito, comecei a verificar o log de erros do servidor SQL, que apresentava o erro abaixo toda vez que tentava iniciar a função do servidor SQL no gerenciador de cluster de failover

Falha de login para o usuário 'NT AUTHORITY\SYSTEM'. Razão: Não foi possível encontrar um login correspondente ao nome fornecido. [CLIENTE: ]

então criei o login NT AUTHORITY\SYSTEM e também o adicionei à função Sysadmin. e funcionou!,

Agora estou cético se o que fiz é certo ou não em termos de segurança.

1. Ouvi dizer que criar NT AUTHORITY\SYSTEM no servidor SQL não é seguro. Se for esse o caso, devo alterar meu serviço de cluster para uma conta de domínio? Isso afetará alguma coisa?
2. Eu adicionei NT AUTHORITY\SYSTEM à função Sysadmin - Isso é realmente necessário ou posso fornecer apenas a permissão necessária explicitamente para o login

Estou tentando obter as páginas usadas por um índice clusterizado na tabela1 em uma caixa SQL2008 R2 DEV usando a consulta abaixo.

dbcc traceon(3604, -1) 
go 
dbcc ind (0, 'dbo.table1', 1) 
go

mas ainda exibe a saída abaixo e não exibe os resultados. O que estou fazendo de errado aqui?

Além disso, a mensagem abaixo é registrada no log do servidor SQL

Mensagem DBCC TRACEON 3604, ID do processo do servidor (SPID) 59. Esta é apenas uma mensagem informativa; Não é necessária nenhuma ação do usuário.

Como o SQL Server 2012 ainda funciona depois de alterar a conta de serviço para uma conta de domínio ou mesmo uma conta local. Por exemplo: conforme mencionado no MSDN

https://msdn.microsoft.com/en-us/library/ms143504.aspx#VA_Desc

Esta pasta Instid\MSSQL\datatem privilégios de controle total para a conta virtual NT service\MSSQLSERVER. Mas estou confuso sobre como o servidor SQL ainda inicia após alterar a conta de serviço para um domínio ou conta local, pois essa nova conta de serviço não terá privilégios para essa pasta específica, a menos que a forneçamos explicitamente. E pelo que testei, o SQL Server falha ao iniciar se você remover as permissões NT service\MSSQLSERVERda Instid\MSSQL\datapasta.

Isso significa que qualquer conta que seja uma conta de serviço do servidor SQL é adicionada automaticamente ao NT service\MSSQLSERVERgrupo? , Como é que isso funciona?