Jon Seigel's questions

^{(Para o propósito desta questão, suponha que eu só precise oferecer suporte ao SQL Server 2008 e superior. Ou para preparar esta questão para o futuro, digamos versões recentes, atuais e futuras próximas.)}

A documentação da CREATE LOGINdeclaração diz (ênfase minha):

HASHED
Aplica-se apenas a logins do SQL Server. Especifica que a senha digitada após o argumento PASSWORD já possui hash. Se esta opção não for selecionada, a string digitada como senha é codificada antes de ser armazenada no banco de dados. Esta opção só deve ser usada para migrar bancos de dados de um servidor para outro. Não use a opção HASHED para criar novos logins. A opção HASHED não pode ser usada com hashes criados pelo SQL Server 7 ou anterior.

Não há explicação de por que essa opção não deve ser usada para criar novos logins e, se houver uma razão, não é óbvia (pelo menos para mim).

A documentação faz referência ao KB918992 , que, embora um pouco confuso, descreve as etapas que indicam que os hashes de senha herdados (2000-2008 R2) são atualizados automaticamente. Portanto, posso pegar um hash de senha gerado em 2000-2008 R2 e CREATE LOGIN ... WITH PASSWORD ... HASHEDem 2012 (+?) E converter o hash para o formato 2012 quando o principal fizer login pela primeira vez. Eu testei isso realmente funciona como descrito.

O próprio hash da senha parece ter um cabeçalho de assinatura/metadados de 6 bytes, consistindo no que eu acho que é uma tag/versão de 2 bytes e um sal de 4 bytes. Quando um hash é atualizado, a tag/versão é incrementada enquanto o salt permanece o mesmo.

A questão é então: se a Microsoft já criou esse tipo de compatibilidade futura (que presumo que precisará ser mantida daqui para frente), há alguma razão para que esse método não deva ser usado para criar novos logins?

Aqui está o código que estou usando para registrar um servidor vinculado ao SSAS:

USE [master];
GO

EXEC master.dbo.sp_addlinkedserver
    @server = N'ServerAlias',
    @srvproduct = N'',
    @provider= N'MSOLAP',
    @datasrc= N'ActualServerName',
    @catalog = N'DatabaseName';

Quando tento executar uma consulta MDX usando OPENQUERY, ou se uso o comando Test Connection no Management Studio após executar o código acima, recebo o erro:

Msg 7403, nível 16, estado 1, linha 1
O provedor OLE DB "MSOLAP" não foi registrado.

Isso é muito estranho, pois esse provedor é instalado como parte do SQL Server.

• Ele também falha em todas as outras instâncias na mesma caixa -- 5 instâncias totais de 2008 R2 RTM e 2008 R2 SP1. Não me lembro exatamente, mas 1 ou 2 das instâncias na caixa de problemas podem ter sido atualizadas de 2008 para 2008 R2 em algum momento.
• Ele teve sucesso em algumas outras caixas usando 2008 R2, incluindo uma caixa que tem cerca de uma dúzia de instâncias totais de 2005, 2008 R2 e 2012. Tentei 32 bits e 64 bits com sucesso.

Eu olhei para este artigo da Microsoft KB que descreve o problema exato; no entanto, não há uma resolução aplicável. Todas as outras instâncias desse erro que encontrei na Internet ocorreram devido a alguém definindo incorretamente o servidor vinculado, o que também não é aplicável.

Este é um servidor de desenvolvimento (felizmente), então praticamente todas as opções estão na mesa. Um reparo resolveria isso? Parece que algo está errado no registro.

(Estou pedindo orientação primeiro, pois não posso realizar nenhuma manutenção devido à falta de permissões.)

Nosso aplicativo Windows de atualização de banco de dados precisa transferir alguns dados entre dois bancos de dados como parte do processo para uma determinada atualização única. Escolhi o XML como intermediário para mover os dados.

O processo funciona selecionando um bloco de linhas da origem como XML, que é passado pelo aplicativo para o servidor de destino, onde é fragmentado em uma tabela temporária global. (Os bancos de dados de origem e destino podem estar em 2 instâncias diferentes.) Esse processo se repete até que todos os dados necessários estejam na tabela temporária da instância de destino. Por fim, os registros da tabela temporária são consolidados na tabela de banco de dados de destino real.

O problema que estamos tendo é que, em algumas situações, o segundo bloco é extremamente lento, com uso muito alto da CPU e simplesmente não leva a lugar nenhum. Conseguimos reproduzir o problema em nosso ambiente de hospedagem, mas não no desenvolvedor ou no controle de qualidade. Alguns de nossos clientes também estão tendo esse problema - um deles o deixou rodar durante a noite e finalmente o desligou na manhã seguinte, depois de rodar por 18 (!) horas. Nesse caso, não tenho certeza de quanto avançou; Não consigo passar da segunda parte da hospedagem depois de esperar cerca de 2 horas.

Este é o lote de instruções para o primeiro bloco:

SET NOCOUNT ON;

DECLARE @src xml;
SET @src = CAST(@P1 AS xml);

SELECT
    n.x.value(N'field1[1]', 'uniqueidentifier') AS field1,
    n.x.value(N'field2[1]', 'smallint') AS field2,
    ... (8 more fields of various types) ...
    INTO [##target_2994] /*******/
    FROM @src.nodes('Rows[1]/Row') n(x);

E este é o lote para o segundo e subseqüentes pedaços, que é o problema:

SET NOCOUNT ON;

DECLARE @src xml;
SET @src = CAST(@P1 AS xml);

INSERT INTO [dbo].[##target_2994] /*******/
    SELECT
        n.x.value(N'field1[1]', 'uniqueidentifier') AS field1,
        n.x.value(N'field2[1]', 'smallint') AS field2,
        ... (8 more fields of various types) ...
        FROM @src.nodes('Rows[1]/Row') n(x);

Aqui está o que eu olhei até agora:

• Não é um problema de bloqueio: as estatísticas de espera são de 99% SOS_SCHEDULER_YIELDna INSERTinstrução.
• sys.dm_io_virtual_file_statsno alvo tempdbmostra que está basicamente ocioso, então não é um problema de E/S.
• Todos os dados têm apenas colunas de largura fixa, portanto, não há campos de texto muito longos.
• O tamanho do bloco de dados é atualmente de 25.000 linhas e podemos reduzi-lo, mas isso não explica a diferença porque testamos com alguns dos mesmos conjuntos de dados perfeitamente. A maior tabela necessária para ser transferida é de aproximadamente 725.000 linhas, o que testou bem.
• Os planos de consulta são idênticos* entre problema e sem problema (fiz uma comparação de arquivo do XML).
• As opções de sessão SETsão as mesmas entre problema e sem problema.
• A versão não parece ser um fator: a hospedagem é 2008 R2 SP1 Enterprise x64; testamos sem problemas em 2005 SP4+ Standard x64 até 2008 R2 SP1+ Developer x86. Os clientes com problemas são 2008 RTM/SP1 Standard/Enterprise x64 (até agora).
• A virtualização não parece ser um fator: hospedagem e controle de qualidade são virtualizados; dev é parcialmente virtualizado; clientes com problemas são físicos. MAXDOPnão está definido para nenhum dos nossos servidores (max = 4 processadores lógicos); Não tenho certeza sobre as configurações dos clientes.
• Os dois bancos de dados que estão no mesmo servidor versus servidores diferentes não fazem diferença.
• Executar o aplicativo de atualização em uma caixa TS versus localmente não faz diferença.
• As configurações do banco de dados Tempdb são idênticas.
• Os agrupamentos de instância e banco de dados são idênticos.
• Alterar o nível de compatibilidade do tempdb no servidor de destino para 90 não ajudou. (Por resposta de Mark )
• Não há diferenças significativas na configuração da instância. (Por resposta de Jimbo )

Alguém pode sugerir outras coisas para olhar?

_{* As expressões calculadas receberam nomes diferentes e houve uma diferença < 1% em um dos tamanhos de linha estimados, mas todo o resto foi o mesmo, incluindo as estimativas de custo geral.}

Temos um cliente distribuído geograficamente em comunidades remotas, com conectividade de rede/internet um tanto incerta entre cada um dos locais físicos. Há uma única localização central e 52 localizações de satélite.

Normalmente, nosso aplicativo é implantado como uma solução central onde há apenas um único banco de dados e todos os locais se conectam a um único banco de dados. Os dados em si são particionados por uma coluna de localização na maioria das tabelas (alguns dados são centralizados) e o aplicativo opera de forma que o toque nos dados em um local físico não toque nos dados em outro local físico, incluindo os dados centralizados (pelo menos, temos certeza de que não - se acontecer, provavelmente é um bug). Nosso cliente gostaria de fazer relatórios centralizados (que normalmente oferecemos suporte) e sincronização de várias tabelas de configuração centralizadas em toda a empresa (o mesmo, porque normalmente há apenas uma cópia das tabelas).

Cada local tem seu próprio centro de dados e é licenciado para SQL Server 2008 R2 Enterprise.

O objetivo é implantar nosso aplicativo de forma que a conectividade de rede/internet interrompida não impeça as operações locais de leitura/gravação, pois nosso aplicativo é de missão crítica.

Meu primeiro pensamento foi usar uma topologia ponto a ponto gigante que replicasse todos os objetos do banco de dados. Não consegui encontrar nenhuma documentação ou referência de nenhuma instalação dimensionada tanto usando esse método, então não tenho ideia se é tecnicamente viável e, em caso afirmativo, qual hardware será necessário. Isso funcionaria com um banco de dados de distribuição centralizado (para facilitar o gerenciamento)? Isso é mesmo uma boa ideia? Como as alterações do esquema do banco de dados serão implantadas? A manutenção do índice gera uma grande sobrecarga de rede?

Há também a opção de criar uma solução roll-our-own, que imagino envolver o envio de cópias separadas do banco de dados (cada local não central conteria apenas sua parte particionada dos dados) para o local central e, em seguida, usando uma ferramenta de fusão (que já temos) para criar um banco de dados de relatórios. As alterações na tabela de configuração seriam enviadas por algum outro mecanismo, possivelmente replicação de mesclagem, possivelmente uma solução homebrew.

Considerei e testei o uso da replicação de mesclagem em todo o banco de dados, mas exigimos muitas alterações/redesenho/etc do banco de dados e do aplicativo. para fazer isso funcionar corretamente, então já descartei isso devido a restrições de tempo. (Pensamentos sobre isso?)

O que estou procurando aqui é alguma orientação de pessoas com mais experiência. Obviamente, o planejamento para isso é fundamental . Estou no caminho certo? Existem outras opções? _^(URLT?)

Mesmo a Microsoft desencoraja o uso do modo de autenticação do SQL Server , mas nossos aplicativos exigem isso.

Eu li que é uma prática recomendada não permitir que os usuários usem o salogin diretamente, em vez disso, use a Autenticação do Windows e permita privilégios de administrador de sistema a essas contas (ou grupos de contas).

• Não é essencialmente a mesma coisa? Quais são as vantagens/desvantagens?
• Como a prática recomendada aumenta a segurança de minhas instâncias do SQL Server?
• Isso se aplica apenas às instâncias de produção ou também às nossas instâncias de desenvolvimento interno?