blobbles's questions

Temos alguns servidores em um grupo de alta disponibilidade do SQL Server, um atuando como primário e o outro como secundário. Este sistema está funcionando bem e faz failover conforme o esperado (embora isso seja muito raro). No entanto, também queremos configurar a replicação transacional para outra finalidade, para permitir alguma integração com dados enviados por um dos bancos de dados no grupo HA. A integração gostaria que os dados fossem o mais em tempo real possível (portanto, transacionais, alguma latência é bom) e um Push unidirecional de um dos servidores no grupo HA.

Estou pensando em usar o secundário apenas para a replicação transacional e não fazer alterações no primário. O Secundário não é muito usado e, quando ocorre failover, corrigimos rapidamente o problema no Primário e fazemos o failback manualmente para o Primário. O Primário está sob uso razoavelmente pesado e é um pouco frágil, enquanto o Secundário tem muito menos uso, então usar o Secundário como o Publicador parece uma solução inteligente.

1. É possível usar o Secundário apenas como Publicador, sem alterações no Primário?
2. Supondo que isso seja possível, algo a ser observado ao usar essa abordagem?

Nós temos:

1. Um banco de dados local do SQL Server
2. Uma VM com o Integration Runtime instalado nela
3. Uma Data Factory compartilhando este IR, funcionando (de acordo com a interface ADF)
4. Logins armazenados no Key Vault para autenticação do SQL Server da fábrica de dados para fazer login no SQL Server por meio do IR

As propriedades da cadeia de conexão da conexão parecem ser o que eu quero, observe que a criptografia está desativada e trustservercertificate=true:

O IR relata como conectado e funcionando bem:

Testei a autenticação do SQL Server na VM com o IR instalado por meio da guia Diagnóstico do IR. Funciona bem:

Do Data Factory, testo usando os mesmos parâmetros de login no serviço vinculado conectado ao IR, que funciona:

Observe que usamos muitos parâmetros para definir as conexões, que também funcionam bem.

Configurei um dataset, usando as mesmas propriedades, teste a conexão funciona:

Agora eu configurei uma atividade de cópia fácil usando os mesmos parâmetros, usando o mesmo Dataset e o mesmo serviço vinculado:

Também visualizo os dados que quero, o que funciona, trazendo os dados de volta do servidor conforme o esperado.

Isso não faz sentido para mim, testei usando exatamente os mesmos parâmetros em cada etapa, mas uma atividade de cópia simples falha quando todos os outros testes de conexão foram bem-sucedidos. Alguem tem alguma idéia?

NOTA: Tentei definir os parâmetros de conexão do Linked Service: Encryption = True, o que às vezes significa que a conexão passa por OK. Novamente, isso faz pouco sentido.

Temos um servidor SQL Server 2012 que supera em muito um banco de dados SQL Server 2019 (até onde posso ver) na mesma infraestrutura. Estamos hospedando os dois bancos de dados em uma plataforma de nuvem com os mesmos SLAs. Ambos têm 180 GB de RAM e 16 processadores.

No entanto, existem algumas diferenças importantes.

1. O servidor de banco de dados de 2012 é Enterprise, o de 2019 é Standard. Até onde eu sei, isso não deve fazer diferença
2. O banco de dados de 2012 foi restaurado para o servidor de 2019 e sua versão foi alterada para 150 (2019)
3. MAXDOP no servidor de 2012 era 0, servidor de 2019 está definido como 8 conforme recomendado pela Microsoft e outros
4. Limite de custo para paralelismo = 5 no servidor de 2012, 20 no servidor de 2019

EDIT: Outra grande diferença que acabei de perceber - um é o Windows Server 2008, o outro é o Windows Server 2019. Também pode ser as configurações do lado do servidor ...

O tamanho da unidade de alocação é definido como 64kb para todos os discos SQL, o SQL tem as permissões certas para poder controlar os tamanhos dos arquivos. O servidor está definido para o modo de alto desempenho. Qualquer outra coisa que eu deveria estar mudando o lado do servidor?

Outras configurações do banco de dados não foram alteradas, portanto, as seguintes configurações são padrão em 2019, acredito:

• Estimativa de cardinalidade herdada = DESATIVADA
• Sniffing de Parâmetro = ATIVADO
• Correções do Otimizador de Consulta = DESATIVADO

Principalmente o tipo de consultas que fazemos são consultas grandes e complexas com várias associações realizando atualizações e inserções, com pequenas seleções ocasionais de usuários. Carregamos arquivos grandes no banco de dados e processamos os dados em consultas grandes, geralmente uma de cada vez. Entre essas grandes "cargas" temos usuários fazendo seleções em outras tabelas de banco de dados que não estão sendo carregadas/processadas em preparação para futuras etapas de carregamento/processo. Geralmente estamos obtendo entre 30% e 50% de redução de desempenho no processamento. Achei que isso era por causa da configuração MAXDOP, mas alterá-lo para 0 não fez diferença em uma série de execuções.

Nosso principal sintoma é que estamos obtendo tempos limite de bloqueio quando tentamos nos conectar ao servidor de 2019 enquanto ele está ocupado processando, enquanto o servidor de 2012 ainda atende conexões, apenas muito lentamente. Eu estava pensando em definir a configuração de tempo limite de conexão no servidor para um valor alto, mas suspeito que ainda não obteremos respostas do servidor. É como se estivesse bloqueando todas as novas conexões, mesmo que estivesse um pouco ocupada.

Existem outras coisas que eu deveria tentar? Vale a pena mexer nessas configurações de banco de dados?

Eu poderia mergulhar mais fundo e começar a olhar para DMVs, no entanto, isso parece estar perto de uma atualização de ambiente "like for like" com quedas consideráveis ​​no desempenho. Apenas verificando se não há mais nada que eu deva verificar antes de fazer uma investigação maior.

Configurei consultas de banco de dados elástico do Azure antes usando o seguinte nos bancos de dados PaaS do Azure:

No banco de dados da fonte de dados:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<encryption key>';
GO
CREATE DATABASE SCOPED CREDENTIAL CRED_Azure_Login
WITH IDENTITY = 'SomeUser', SECRET = '<Some password>'
GO

Esta execução, sem problemas e posso ver a credencial criada ao olhar para sys.database_scoped_credentials. Então parece que a fonte está boa.

No banco de dados de destino:

CREATE EXTERNAL DATA SOURCE Source_AzureDatabase
WITH
(
    TYPE=RDBMS,
    LOCATION='<DB location>.database.windows.net',
    DATABASE_NAME='SourceDBName',
    CREDENTIAL= CRED_Azure_Login
);

Isso costumava funcionar bem, mas recebo o seguinte erro:

Msg 46516, Level 16, State 26, Line 1
The specified credential cannot be found or the user does not have permission to perform this action.

Estou usando o logon de administrador no banco de dados de destino (alterei o logon de administrador por meio da página Visão geral do Portal do Azure para o banco de dados e fiz login novamente, só para ter certeza). A documentação diz que você precisa da permissão CONTROL no banco de dados, então isso não deve ser um problema. Como configurei com sucesso a chave mestra e a credencial dos bancos de dados de origem, vincular a ela não deve ser um problema.

Alguém pode tentar isso para ver se sou só eu? Outro DBA revisou o código e não encontrou nenhum problema. Parece que a Microsoft pode ter quebrado esse recurso - alguém pode verificar se pode fazê-lo?

Tenho um banco de dados no modelo de recuperação SIMPLES com 10GB livres.

O arquivo que estou tentando carregar por meio do carregamento em massa do SSIS é de 1 GB.

A tabela está vazia (truncada antes de cada carregamento), é um heap e não possui índices não clusterizados. É uma tabela de campos varchar(255).

Ao executar a tarefa de inserção em massa, posso observar o tamanho do banco de dados crescer de 2 GB para 12 GB (espaço máximo disponível), onde fica sem espaço e retorna a seguinte mensagem:

Erro [Bulk Insert Task]: Ocorreu um erro com a seguinte mensagem de erro: "Não foi possível alocar espaço para o objeto 'dbo.tablename' no banco de dados 'DBNAME' porque o grupo de arquivos 'PRIMARY' está cheio. Crie espaço em disco excluindo arquivos desnecessários, soltando objetos no grupo de arquivos, adicionando arquivos adicionais ao grupo de arquivos ou definindo o crescimento automático para arquivos existentes no grupo de arquivos.".

Em primeiro lugar, pensei porque estava no modelo de recuperação SIMPLES, o carregamento em massa não é registrado. Eu sei que é quando há dados na tabela E um índice clusterizado, mas nenhum dos dois é o caso aqui. Presumo que a Tarefa de Inserção em Massa esteja incluída nisso, pois deve usar o BCP. Estou errado?

Em segundo lugar, parece estranho que um arquivo de texto de 1 GB resulte em 10 GB nos campos varchar do SQL Server. Isso parece muito estranho. Os dados não estão sendo transformados, estão sendo carregados em massa em uma tabela. Por que está crescendo tanto?

SQL Server 2008 R2, mas o comportamento provável também é encontrado em todas as outras versões do SQL Server.

Isso pode parecer óbvio, mas para mim parece um bug.

A consulta a seguir fornece resultados inesperados, aqui está a configuração:

CREATE TABLE #Base (
Key1 int,
RefDate date
)


CREATE TABLE #JoinTable (
    Key1 int,
    RefDate date
    )

INSERT INTO #Base
SELECT 1, '2012-05-05'
UNION
SELECT 2, '2013-06-06'
UNION
SELECT 3, '2014-07-07'
UNION
SELECT 4, '2015-08-08'
UNION
SELECT 5, '2016-09-09'


INSERT INTO #JoinTable
SELECT 4, '2012-05-05'
UNION
SELECT 5, '2013-06-06'
UNION
SELECT 6, '2014-07-07'
UNION
SELECT 7, '2015-08-08'
UNION
SELECT 8, '2016-09-09'

A consulta a seguir é executada conforme esperado, retornando as 3 linhas que ocorrem apenas na tabela base:

SELECT * 
FROM #Base b
LEFT OUTER JOIN #JoinTable j ON b.Key1 = j.Key1
WHERE j.Key1 IS NULL

Agora, gostaria de restringir as linhas àquelas anteriores a 1º de janeiro de 2014. Pelo que entendi, posso seguir as duas abordagens abaixo, ambas devem ser perfeitamente viáveis:

SELECT b.*
FROM #Base b
LEFT OUTER JOIN #JoinTable j ON b.Key1 = j.Key1 AND b.RefDate < '2014-01-01'
WHERE j.Key1 IS NULL


SELECT b.* 
FROM #Base b
LEFT OUTER JOIN #JoinTable j ON b.Key1 = j.Key1 
WHERE j.Key1 IS NULL AND b.RefDate < '2014-01-01'

No entanto, apenas a 2ª consulta retorna os dados que desejo. O primeiro parece ignorar a condição de junção adicionada após o AND na linha de junção.

Por quê?

(link do SQL Fiddle aqui )