Newbie-DBA's questions

Estamos tentando resolver problemas de conectividade para um dos aplicativos que tenta extrair dados de um servidor sql muito seguro atrás do firewall. Não sou especialista em segurança, mas preciso de ajuda sobre como proceder na abertura de portas para esse aplicativo extrair dados do servidor sql por trás do domínio seguro.

Abrimos a porta na qual o sql server está escutando, digamos 12345, mas ainda sem sorte.

Como sei quais portas adicionais podem precisar ser abertas como udp 1434 default 1433 ou mirror como 5022? Existe uma maneira de encontrarmos essa informação?

Alguém pode me ajudar a descobrir se meu entendimento está correto no seguinte:

No AG Dashboard da minha réplica secundária legível, vejo:

• Tempo de recuperação estimado (segundos) - 4598
• Fila REDO - quase 24 GB

Então, o que exatamente significa se meu AG secundário precisa ir para nó/failover ou reinicialização do SQL como parte de uma atividade?

Isso significa que meu secundário levará 4.598 segundos para ativar esse banco de dados com a fila de redo de 24 GB?

Estou preocupado porque um dos nossos prod sec side tem a maior parte do tempo durante o dia refazendo o tamanho de 400 GB e o tempo de recuperação de quase 10 horas do painel AG. Isso significa que o chamado DR está comprometido?

Acabei de fazer um failover de teste e, como esperado, o DB foi para recuperação, conforme vejo nas mensagens de log de erros e vejo a conclusão em 1235 segundos. Apenas curioso, pois esse número de recuperação estimada estava longe. Isso é apenas para explicar aos meus usuários de negócios a ajudá-los de qual janela de interrupção estamos falando.

Estou confuso sobre a web reclassificando alguns scripts para calcular o tamanho do banco de dados e o espaço livre dentro do mesmo.

A maioria dos scripts na web usa sys.databases_files dmv para calcular o espaço livre como aqui e aqui

No entanto, se virmos um de sp_spaceused ou propriedades de banco de dados via GUI, a quantidade de espaço livre é diferente. Eu recebo o motivo de ser diff, pois possui filtro no tipo (0,2,4) que exclui o arquivo de log.

Mas não consigo entender qual está correto e por que o arquivo de log é excluído do sp_spaceused ou é que os scripts na web não estão corretos e mostram outra coisa?

Estamos enfrentando problemas com a flutuação da fila REDO, pois temos uma configuração secundária legível.

Com base no meu entendimento em versões mais recentes do SQL Server, os threads de redo foram tornados paralelos. A versão atual é o SQL Server 2017 em execução na VM com 64 núcleos.

Estou vendo problemas ao selecionar consultas na execução secundária no mesmo cpu/scheduler em que os threads AG estão sendo executados. Estou assumindo que o thread AG produz seu agendador e fica em segundo plano para permitir que outras consultas sejam executadas. E acredito que este seja o problema porque as consultas que chegam parecem estar atingindo o mesmo cpu_id onde os threads AG estão fazendo o trabalho de refazer.

Exemplo abaixo: spid 91 é uma consulta selecionada em cpu_id 6 e ao mesmo tempo spid 123 e 144 threads em execução para AGs conforme encontrado em sys.dm_exec_requests dmv. A fila REDO começa a se acumular quando 91 apareceu.

Não sei se existe algum processo que faça suas consultas irem para núcleos diferentes em vez de um em que o thread de AGs possa estar em execução.

1. Podemos controlar isso para que as consultas atinjam outros agendadores e não um em que o AG esteja trabalhando?

2. Vejo muitas esperas em PARALLEL_REDO_TRAN_TURN quando as consultas são executadas no secundário enquanto os threads AG estão suspensos. Pode rastrear a ajuda do sinalizador conforme mencionado aqui

3. Pode haver muitos outros agendadores disponíveis. Não consigo entender por que determinado processo está travado no slot do Numa. Eu acho que as versões mais recentes têm todos os numas suaves habilitados, então isso faz um balde de 8 numas suaves. 8*8 agendadores para 64 disponíveis. Desabilitar o numa soft é uma boa ideia aqui?

O isolamento de banco de dados é RCSI, mas não acho que isso importe aqui porque internamente ele foi alterado para instantâneo com base no design de secundários legíveis.

Recentemente, migramos da configuração do LogShipping standby/read-onlypara a configuração do Multi Subnet AG com secundários legíveis.

Geralmente, na configuração antiga, temos consultas selecionadas em execução por mais tempo, pois o banco de dados em questão tem mais de 20 TB e tem uma mistura de carga de trabalho de leitura e gravação no primário.

Depois de passar para a nova configuração do AG, começamos a ver bloqueios que não consigo entender. Por que as consultas selecionadas no secundário estão bloqueando outras consultas selecionadas em minha instância de réplica secundária legível, mesmo quando o banco de dados que está sendo consultado tem RCSI enabled?

Abaixo está o que eu capturei

• O bloqueador de leads é uma consulta de longa duração SELECTque não mostra nenhum tipo de espera específico como particular, digamos SPID129

• SPID 129bloqueia um ID de sessão 45(tenho certeza de que não é um ID de usuário) por quase 6 horas, o que depende do spid129 e o tipo de espera é LCK_M_SCH_M

• Aí vem o problema quando isso SPID 45apenas bloqueia todas as outras consultas selecionadas agora nessa duração de 6 horas.

Não estou conseguindo entender o que está acontecendo. Alguém pode me ajudar a solucionar problemas ou olhar na direção correta?

Recentemente, aumentamos a latência de gravação de disco relatada. Embora de nossa equipe de monitoramento não tenha sido confirmado de qual unidade, mas fazendo alguma consulta dmv, vejo tempdbcerca de 32 ms de espera na gravação. Além disso, durante o uso da semana tempdb, quero dizer que o espaço livre disponível caiu para menos de 50 GB de 300 GB.

Estou suspeitando que esse pico possa ser de tempdb. O ambiente é uma mistura de OLTP e pessoas do warehouse que consultam dados para grande seleção ao procurar dados em tempo real caso não estejam disponíveis no modo de espera LS.

Minha pergunta é como posso verificar o que tempdbse é teria causado esse pico?

Além disso, essas consultas selecionadas também podem contribuir para a tempdblatência de gravação? Essas consultas selecionadas são executadas em tabelas sobre TBs de dados e o usuário pode ter parte de consultas como ordenar por e agrupar pelo que vi. Mas não tenho certeza de como provar que eles estão contribuindo para o aumento repentino.

Eu sei que isso é mais discutido em vários fóruns: Eu entendo completamente que a resposta é não na maioria das vezes ou nos casos.

No entanto, quero saber se pode ser uma boa abordagem em qualquer cenário:

Vamos dizer para o banco de dados prod atual que no nosso caso tem mais de 30 TB e tem retenção de dados por 1 ano. As tabelas são principalmente compactadas e particionadas.

A equipe de desenvolvimento criou uma lógica em que eles não precisam de dados para permanecer até o ano e desejam alterar a retenção para 6 meses. Portanto, espera-se que os dados sejam reduzidos à metade após a eliminação e apenas com dados de 6 meses daqui para frente.

É aqui que fomos solicitados a trabalhar na redução de arquivos de dados para que esses LUNS com TB de espaço pudessem ser retornados ou, se migrarmos para uma nova versão do sql, estaríamos solicitando, digamos, alguns (aprox10) TB a menos que economizam algum dinheiro, supondo que mantenhamos 5 TB extras para crescimento no banco de dados no futuro.

Nesse caso, seria útil reduzir a redução em pequenos pedaços, assumindo que o bloqueio no horário de pico baixo pode ser aceito ou se a redução for executada por mais tempo pode ser cancelada?

Quanto vale a atividade de arquivo de dados de redução acima ou existe uma abordagem melhor?

Editar --> Estamos migrando para a versão mais recente possivelmente SQL 2017 ou SQL2K19. As tabelas não são particionadas com base em grupos de arquivos, pois para esses bancos de dados todos os mais de 30 arquivos estão no primário. Eu sei, é apenas um design de banco de dados de fornecedor e não tenho muito na minha mão.

Eu tentei navegar em muitos links, mas não consigo obter muita ajuda, então estou postando esta pergunta que parece um pouco semelhante.

Temos algumas tabelas que estão sendo planejadas por nossa equipe de aplicativos para que eles parem de enviar dados nos próximos meses. Portanto, essas tabelas seriam boas candidatas para limpeza mais tarde.

No entanto, como posso encontrar, se houver uma maneira no servidor SQL, algum usuário adicional que não temos conhecimento pode estar usando essa tabela para operação XYZ.

Existe uma maneira disponível nativamente ou precisarei do XE para rastrear isso? Este é um servidor de banco de dados OLTP altamente ativo por toda parte, portanto, executar qualquer auditoria seria algo a ser testado.

Qual deve ser a abordagem e como lidar de forma prática com essa situação? Por favor sugira.

Obrigada!

Eu tenho a consulta SQL abaixo que é executada em avg. 40 segundos e preciso de alguma orientação onde posso melhorá-lo ou possivelmente reescrever:

   Declare @status_D INT,
      Declare @StatusIP INT,
      Declare @Status_F INT,
    
    SELECT @status_D = Id From Batchtablestatus (NOLOCK) Where desc ='Value1';
    SELECT @StatusIP = Id From Batchtablestatus (NOLOCK) Where desc ='Value2';
    SELECT @Status_F = Id From Batchtablestatus (NOLOCK) Where desc ='Value3'

BEGIN TRAN

 UPdate U
        SET 
         U.[id]= @StatusIP,
         U.[EnabledDate]= Getdate()
         OUTPUT deleted.col1,
         deleted.col2,
         deleted.col3,
         deleted.col4,
         Inserted.id

FROM (

SELECT TOP 5000 * FROM BatchChangeTable WITH (ROWLOCK,UPDLOCK)
WHERE [id] IN ( @status_D ,Status_F)
ORDER BY [ModifiedTime] )U;

  COMMIT TRAN 

Estou recebendo aviso do blitzcache como serialização forçada, classificação Expensive, non-sargable e Merge join "Mant to Many" = True

O único índice que tínhamos está em id, que é um índice NC com id como coluna de chave principal.

Vou tentar atualizar minha pergunta se plano de execução, se puder. A tabela no SELECT é de cerca de 100 milhões a partir de agora. Também tem PK/CI em col1.

Perguntei aos usuários por que fazemos * nesse TOP que puxa quase 50+ colunas, mas na atualização uso apenas menos, talvez esteja pensando errado, mas só veio à minha mente.

Adicionar índice ao tempo modificado também não parece ajudar.

Por favor, sugira o que mais pode ser verificado. Obrigado

plan- A busca do índice aconteceu no id do índice NC

Estou tendo problemas com um dos proc rodando muito lento por aproximadamente uma hora:

Por favor, perdoe, pois tenho que escrever o código inteiro fora do sistema para colar aqui. Estarei editando a pergunta com mais detalhes sobre o esquema e os índices da tabela à medida que copio essas informações:

SP é algo como abaixo

CREATE PROCEDURE [dbo].[testsp1]
@parameter1 VARCHAR(MAX),
@parameter2 DATETIME

AS

DECLARE @Today DATETIME =GETDATE()
IF @parameter2 IS NULL
 SET @parameter2 = Getdate()

SET @parameter2 = CONVERT(VARCHAR, @parameter2 , 101)

DECLARE @table1 TABLE ( tabletypeID BIGINT)

Insert into @table1
SELECT Value from stringsplit(@parameter1, '|')

UPDATE bigtable
    SET value1 = 33, statusdate = @today
from 
    bigtable t
    INNER JOIN anotherbigtable t1 on t.id=t1.id
    INNER JOIN @table1 t3 on t.tabletypeid = t3.tabletypeid
WHERE
    t1.paydate <= @parameter2
    AND t.value1=32
    AND t1.payid =2

bigtable tem aproximadamente 800 M de linhas e foi agrupado como PK no id e NC no userid (1ª chave), tabletypeid (2ª chave)

anotherbigtable é aprox. 300 M linhas

@parameter2é na maioria das vezes recebido como NULL enquanto @parameter1 varia

plano em cache é algo como abaixo

Preciso de ajuda para entender a lentidão em uma das UPDATEdeclarações como abaixo: -

UPDATE TOP (100) xyz
SET xyz.flag = 1
OUTPUT inserted.Rcode, inserted.EDR, inserted.id, abc.EID,abc.CID,abc.ENID,abc.Cdate
FROM dbo.table1 xyz WITH (UPDLOCK, READPAST)
INNER JOIN dbo.table2 abc WITH (NOLOCK)
on xyz.id=abc.id
WHERE xyz.flag = 0

A Tabela1 tem aprox. 0,5 milhão de linhas e a Tabela 2 tem aprox. 5 milhões de linhas

Plano lento

O operador de fluxo distinto Hash Match mostra um alarme amarelo e a mensagem é:

O operador usou Tempdb para derramar dados para execução com nível de derramamento 4 com 1 encadeamento derramado"

Resíduos de construção:

database.dbo.table2.id como abc.id = database.dbo.table2.id como abc.id

Eu tirei uma captura de tela. Infelizmente, por motivos de segurança, não posso fornecer mais do que isso, nem mesmo um plano anônimo. Da minha estação de trabalho, não consigo acessar a Internet, portanto, não há como fazer com que o explorer de planos seja executado lá.

Geralmente, para um subconjunto menor de linhas, é menos de segundos, como quando temos apenas 10 mil linhas correspondentes ou algo assim. Mas com uma quantidade maior de dados, isso parece ser o ponto de inflexão e o aplicativo não pode permitir 1 minuto de tempo de execução. Do SSMS, recebo 30 segundos, mas do aplicativo, temos o avg. 50 segundos aprox. RCSI está em fase de testes.

Meu bom plano não tem o operador Hash Match Flow Distinct visível como mostrado na minha captura de tela, enquanto o restante do plano permanece o mesmo. Um bom completa menos de 3 segundos ou mais. Como visto, quase 16 segundos são gastos nesse operador. Podemos eliminá-lo por meio de indexação adequada ou reescrita de consulta?

Esquema da tabela

CREATE TABLE dbo.table1
(
    Recid  VARCHAR(128) COLLATE SQL_Latin1_general_CP1_CI_AS NOT NULL,
    Cdate DATETIME NULL,
    flag BIT   NULL DEFAULT (0),
    Rcode INT NULL,
    EDR VARCHAR(255) COLLATE SQL_Latin1_general_CP1_CI_AS NULL,
    id BIGINT NULL
);

CREATE TABLE dbo.table2
(
    ENID BIGINT IDENTITY(1,1) NOT NULL,
    EID VARCHAR(50) COLLATE SQL_Latin1_general_CP1_CI_AS NOT NULL,
    CID VARCHAR(350) COLLATE SQL_Latin1_general_CP1_CI_AS NOT NULL,
    CDate DATETIME NOT NULL DEFAULT(getdate()),
    id BIGINT NOT NULL,

    CONSTRAINT PK_ENID PRIMARY KEY (ENID ASC, EID ASC),
);

-- table1
CREATE INDEX ix_Cdate on dbo.table1 (Cdate) WITH (FILLFACTOR=100);
CREATE CLUSTERED INDEX ix_Recid on dbo.table1 (Recid) WITH (FILLFACTOR=80);

-- table2
CREATE INDEX ix_ENID_id on dbo.table2 (ENID,id) WITH (FILLFACTOR=100);

Mudanças

Alterações que fiz e alguns números:

• Adicionada dica OPTION (QUERYTRACEON 4138)- avg. execução 7 segundos abaixo dos 50 segundos originais, mas a equipe do aplicativo parece não ter acesso para fazer isso no código. Precisa verificar mais sobre isso.

• OPTION (ORDER GROUP)deu os mesmos resultados de avg. 50 segundos, então não há melhora.

• Índice adicionado conforme sugerido:

CREATE INDEX i ON dbo.table2 (id) INCLUDE (CID, CDate);

Não há muitas melhorias lá. Média 45 segundos e o plano era semelhante ao anexo nesta questão (plano superior).

Antes e depois de cada teste, verifiquei se o plano não foi gerado a partir do plano anterior em cache.

Plano rápido

Anexar o plano que é mais rápido e sem nenhuma alteração nos dados ou consulta ainda é rápido para a mesma quantidade de linhas em ambas as tabelas. A equipe do aplicativo envia continuamente a consulta acima ao longo do dia para concluir o lote, completando os TOP 100. Há uma mudança de plano com base em algum número de gorjeta e abaixo está a aparência do bom plano:

Edit : - Com tudo inalterado, nenhuma alteração de código ou qualquer índice sendo adicionado, como sugerido quando estou tentando adicionar dica (FORCESEEK) está me dando o erro abaixo

O processador de consultas não pôde produzir um plano de consulta devido às dicas definidas nesta consulta. Reenvie a consulta sem especificar nenhuma dica e sem usar SET FORCEPLAN.

Estou tentando entender o uso do DBCC CHECKDB com as configurações do MAXDOP-

Se eu executar DBCC CHECKDB com MAXDOP = 0 em uma instância SQL em que minhas configurações de MAXDOP são 8, o que está acontecendo na verdade? Todos os meus agendadores disponíveis, digamos, 98 seriam usados? ou ainda apenas 8? ou apenas alguns?

se eu executar DBCC CHECKDB sem MAXDOP diga um padrão com nível de servidor MAXDOP 8 , devo ver todos os 8 agendadores usados? ou pode ser inferior a 8

Por que estou levantando as perguntas acima é para as mesmas execuções de CHECKDB para alguns servidores, parece usar menos agendadores e alguns servidores com a mesma execução de todos os agendadores, causando 100% de picos de CPU

obrigada

Abaixo está mais para minha compreensão sobre como interpretar os dados dos meus contadores perfmon para 2 servidores de banco de dados com estrutura de aplicativo diff, mas tipo de carga de trabalho semelhante

O servidor A tem um total de 1 TB de RAM com bancos de dados de aproximadamente 10 TB com métricas abaixo por meio de configuração de nó de 4 NUMA

O servidor B tem um total de 1 TB de RAM com bancos de dados de aproximadamente 16 TB com métricas abaixo por meio de configuração de nó de 4 NUMA

O servidor B tem mais memória MAX atribuída a ele devido ao tamanho dos bancos de dados serem grandes. Sim, eu sei que as configurações de memória MAX podem ser melhoradas um pouco melhor, mas planejaria mais tarde se eu pudesse entender melhor os números acima para memória roubada e estrangeira.

O que esses números me dizem quando vejo que a memória externa parece ser de aproximadamente 50 GB para um servidor e roubada sendo 150 GB em outro servidor, onde a externa parece ser de 5 GB.

Desculpe pela minha falta de conhecimento aqui, mas alguém pode orientar sobre a melhor maneira de interpretar esses dados e quais possíveis alterações se pode pensar em ajustar aqui?

Vou configurar AG's pela primeira vez, portanto, com pouca ou nenhuma experiência, por favor, oriente-me no entendimento abaixo:

Se eu estiver configurando 4 nós AOAG com o cenário abaixo:

Node1 -NY Data Center - Réplica primária

Node2 -NY Data Center - Réplica secundária

Node1 --- Node2 modo síncrono

Nó 3 - Réplica secundária do Michigan Data Center atuando como site de DR com sub-rede diferente com modo ASYNC

Nó 4 -- Secundário legível no data center NJ para fins de relatório usando o modo ASYNC

Dúvidas/Perguntas:

1. Na configuração de várias sub-redes acima, ainda posso usar um armazenamento diferente em 4 nós ou preciso usar a replicação SAN, pois li alguns blogs e fiquei confuso se isso é um requisito para o ambiente multisite

2. Qual deve ser a configuração de Quórum ideal? -- Posso ter isso no site NJ como testemunha de compartilhamento de arquivos?

Além disso, se houver um design melhor do que o acima, sugira, pois nunca implementei ou trabalhei no AOAG antes.

RPO/RTO para aplicativos críticos varia entre 2 horas a 4 horas

Enquanto para médio crítico é entre um dia e 2

Posso adicionar informações conforme necessário.

Obrigado

Apenas verificando para ver se alguém testemunhou o mesmo e tentou uma correção ou foi corrigido:

Problema :

Eu corri abaixo da consulta no stackoverflow2013banco de dados

select
   ParentId as [Post Link],
   count(id)
from posts
where posttypeid = 2 and len(body) <= 200
  and (body like '%hank%')
group by parentid
having count(id) > 1
order by count(id) desc;

e ao verificar o relatório do painel do SSMS para GrantedQueryMemory, o valor mostra cerca de 62 GB, o que não parece correto ao coletar o mesmo do dmv

De dmv mostra 62 MB

Pareceu-me um bug, então relatado aqui

Estou procurando aqui conselhos de especialistas sobre como gerenciar estatísticas de atualização para banco de dados muito grande, aproximadamente 18 TB.

Recentemente, começamos a enfrentar problemas de desempenho e acreditamos que isso se deve a estatísticas antigas.

Na verdade, temos um trabalho que executa exec sp_update stats e atualiza com taxa de amostragem padrão, no nosso caso 1,2%. Portanto, temos que atualizar manualmente as estatísticas e ver algumas melhorias.

Tenho certeza que agendar FULL SCAN seria um desafio. De acordo com meu conhecimento, estou comparando linhas com linhas amostradas. Por exemplo, em uma tabela com tamanho de 400 GB e mais de 100 milhões de linhas, posso ver que as linhas de amostra são cerca de 2 a 4 milhões. As grandes mesas são particionadas.

Estamos no SQL Server 2012 Enterprise Edition. O sinalizador de rastreamento 2371 não está habilitado.

Por favor, sugira como posso usar a atualização de estatísticas de uma maneira muito melhor para um banco de dados tão grande e como jogar com essa taxa de amostragem?

Vou tentar o meu melhor para descrever a situação, enquanto tentamos descobrir isso:

Temos este SQL Login [LA] que mostra uma conexão bem-sucedida no servidor principal nos logs de erros sql [conexão feita de vários aplicativos]. Este login também mostra uma conexão bem-sucedida em seu servidor espelho.

Agora, aqui está outro login [LB] que se conecta com sucesso no servidor principal, mas não consegue se conectar no servidor espelho. [mesmo aplicativo que o login acima LA se conecta]

Solução de problemas concluída:

1. execute sp_help_revlogin em ambos os servidores e correspondeu à senha com hash para login [LB]. Assim, a senha de confirmação é a mesma para este login em termos de login SQL para o principal e o espelho.

2. Os SIDs de login são os mesmos em ambos os servidores, portanto, isso também não deve ser um problema.

3. O aplicativo usa os mesmos creds para se conectar ao principal, que é um sucesso, mas mostra que o login falhou no servidor espelho.

Como algo está fazendo tentativas malsucedidas de login, o login continua sendo bloqueado.

O que mais posso verificar como DBA antes de passar isso como um problema de aplicativo para os proprietários do aplicativo?

Por favor, ajude-me a solucionar o problema para encontrar a causa raiz desse problema, obrigado.