Estou tentando fazer um backup de um banco de dados de 1,2 TB em uma instância do SQL 2019. Em seguida, restaure o backup para uma instância do SQL 2014.
Eu sei que o SQL não permitirá isso via .bak ou anexando. Além disso, o tamanho do banco de dados torna improvável a geração de scripts.
Alguém sabe se o Redgate SQL Backup pode fazer isso? Ou qualquer outro software que valha a pena comprar.
Um dos nossos sistemas de produção de terceiros passou por uma grande atualização e com sp_whoisactive agora estou vendo muitas consultas - 1 transação profunda - que estão bloqueando qualquer uma das minhas tentativas de ler dm_db_missing_index_details.
Eu tentei definir o NÍVEL DE ISOLAMENTO DE TRANSAÇÃO e usar NOLOCK, mas o SQL apenas ri na minha cara.
Hannah Vernon conseguiu replicar esse comportamento aqui .
Alguém sabe como contornar esta questão?
Experimentamos alguns bloqueios estranhos com o sistema na semana passada e o Redgate Intellisense fazia parte da cadeia de bloqueio, existem outros DMVs que também têm o mesmo problema?
Eu tenho um banco de dados totalmente registrado que sofre apenas algumas alterações diariamente. E o backup do log de transações é feito a cada hora. Uma atualização de linha única (transação única) ocorre às 9h30, o VLF correspondente é truncado no backup de log das 10h.
Eu entendo que Truncado não significa excluído, o VLF permanece esperando para ser substituído.
O registro é então atualizado novamente às 10h30.
Então, minha pergunta é, se não houver mais transações no banco de dados, o VLF (ou dados dele) aparecerá no TRN do backup do Log das 11h?
ou seja, um histórico completo de ambas as atualizações pode aparecer no arquivo TRN das 11h?
Estou perguntando sobre isso porque estou tentando entender algo que estou vendo em algum software de leitura de log conhecido.
Obrigado
Encontrei um SP longo que está sendo registrado como gerando uma grande quantidade de total_worker_time em sys.dm_exec_procedure_stats. (Mas eu acho que pode ser um arenque vermelho)
O SP contém cursores e atualizações distribuídas em servidores MS SQL vinculados.
Quando uma consulta ocorre em um servidor vinculado, o servidor local registra o tempo decorrido no lugar do tempo de CPU ou o servidor remoto retorna o tempo real de CPU para o servidor local?
Estou analisando uma instância de 2008 que oferece suporte a um aplicativo de terceiros.
O aplicativo gerará o código SQL e o enviará ao banco de dados como uma consulta ad-hoc.
Estou usando esta consulta (com base em um script Glenn Berry):
SELECT
qs.creation_time
,qs.last_execution_time
,qs.execution_count
,qs.total_worker_time
,qs.total_physical_reads
,qs.total_logical_writes
,qs.total_logical_reads
,qs.plan_handle
,qt.text
,qt.dbid
FROM
sys.dm_exec_query_stats AS qs WITH (NOLOCK)
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
WHERE
qt.dbid >= 7
OPTION (RECOMPILE)
Meu problema é que estou recebendo milhares de planos para consultas muito semelhantes, ou seja,
SELECT * FROM customers WHERE name = 'bob'
SELECT * FROM customers WHERE name = 'bill'
(na realidade as consultas são muito grandes e até 3000 caracteres)
Está tornando quase impossível obter os dados em um formato ideal para análise de alto nível.
É possível comparar rapidamente 2 consultas SQL e ver se elas são praticamente a mesma consulta? Eu então escolheria uma das consultas aleatoriamente e agruparia toda a atividade em relação a essa consulta. (Eu tentei DIFERENÇA, mas é muito lento)
O SQL já armazena um valor semelhante ao MD5 Hash sql_handle que permite ver se duas consultas são semelhantes e consequentemente reutilizar o mesmo plano? (Se esse valor existir, eu o agruparia)
Não tenho esse problema com Stored Procedures porque o mesmo plano está sendo reutilizado. São apenas todos os ad-hocs semelhantes que quero agrupar.
Eu herdei um sistema legado que possui um procedimento armazenado que oferece suporte a um aplicativo da Web. Ele é executado milhares de vezes por dia. O aplicativo permite que um usuário insira detalhes parciais do cliente e o procedimento armazenado subjacente executará comandos LIKE para retornar uma lista restrita de possíveis clientes ao aplicativo Web.
Ele ainda permite a entrada parcial de um ID de cliente (valor inteiro), portanto, se o valor '123' for inserido no aplicativo, o procedimento armazenado deverá retornar todos os clientes com um ID contendo '123', ou seja, '612345' ou '222123 '.....sim, eu sei, louco, digitar '1' retorna um conjunto de dados enorme, mas não podemos alterar o App.
A pesquisa do ID do cliente é a parte mais lenta do procedimento armazenado. Eu "otimizei" o procedimento armazenado (em DEV) para que ele use menos E/S e menos CPU....
Veja como recriar o problema.
--CREATE TEST TABLE
CREATE TABLE dbo.Test(ID INT IDENTITY(1,1) PRIMARY KEY
, Val Float
, CodeVal CHAR(100)
)
GO
--GENERATE A FEW MILLION TEST RECORD
INSERT INTO dbo.Test
SELECT
RAND()
,CONVERT(varchar(255), NEWID())
FROM
sys.objects --Contains 639 Rows
GO 10000
--CREATE INDEX ON ID FIELD
CREATE UNIQUE NONCLUSTERED INDEX idx ON dbo.Test(ID)
A consulta existente executa um Parallel INDEX SCAN.
DECLARE @ID VARCHAR(20) = '123456'
--DROP TABLE #TMP1
CREATE TABLE #TMP1(ID INT)
INSERT INTO #TMP1
SELECT ID
FROM dbo.Test
WHERE CONVERT(VARCHAR(20),ID) LIKE '%'+@ID+'%'
Então percebi que, se um usuário inserir uma ID de cliente parcial de '123456', o conjunto de resultados nunca poderá conter um valor menor que '123456'. Então adicionei uma linha extra ao Código (veja abaixo), agora tenho um INDEX SEEK com IO reduzido e tempo de CPU reduzido. Mas, para meu horror, acabou Serial, então agora leva uma eternidade. Se isso for ativado, o tempo de espera do usuário saltará de 4 segundos para 20 segundos.
INSERT INTO #TMP1
SELECT ID
FROM dbo.Test
WHERE CONVERT(VARCHAR(20),ID) LIKE '%'+@ID+'%'
AND ID >= @ID --New line of code
Agora cheguei ao ponto em que estou codificando cegamente na esperança de que seja paralelo.
Alguém pode explicar por que isso está acontecendo (além da resposta de estoque de "o otimizador decidiu que era melhor")?
E alguém pode descobrir como fazer a consulta ficar paralela?
O sinalizador de rastreamento 8649 não é uma opção para mim.
E eu já li este artigo muito útil de Paul White .
ATUALIZAR:
Parece que o exemplo fornecido produz resultados variados dependendo de uma combinação de System Spec e Row count na tabela de teste.
Desculpe se você não pode recriar o problema. Mas isso é parte da resposta ao meu problema.
ATUALIZAÇÃO: (Plano de Execução)
Aaron: Desculpe por, por exemplo, ser frustrante se não funcionar no seu sistema. (Não posso compartilhar o plano de execução real da minha empresa por motivos de InfoSec)
Eu recriei o problema no meu sistema doméstico.
Aqui está o Plano de Execução, (vou fazer o upload completo para Post-the-Plan)
minha contagem de linhas atual de dbo.Test é 2124160, o índice não agrupado tem 2627 páginas e 0,04% de fragmentação, abaixo estão minhas informações de estatísticas.
SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 1 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 1 ms.
Table 'Test'. Scan count 3, logical reads 2652, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row(s) affected)
(1 row(s) affected)
SQL Server Execution Times:
CPU time = 688 ms, elapsed time = 368 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 2 ms.
Table 'Test'. Scan count 1, logical reads 1106, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row(s) affected)
(1 row(s) affected)
SQL Server Execution Times:
CPU time = 281 ms, elapsed time = 302 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
O procedimento armazenado é usado cerca de 5.000 vezes por dia pelo pessoal do Call-center que lida com os clientes. Uma espera maior de 16 segundos custará pouco mais de 22 horas por dia de funcionários esperando por um resultado. Em um turno de 8 horas, isso equivale a 3 funcionários em tempo integral, custando aproximadamente £ 36k anualmente. Lá se vai o dinheiro para atualizar para as licenças do SQL Sentry (grande fã), atualmente temos o Spotlight (ainda um bom produto) mas quero algo com maior profundidade.
ATUALIZAÇÃO: (Número Mágico)
Com 12.000 linhas, ambas as consultas eram seriais.
Com 2.124.160 linhas, uma consulta fica paralela.
Com 66.000.000 de linhas, ambas ficam paralelas.
Definitivamente, há uma regra/métrica que o otimizador usa, e é diferente se você tiver um Index Scan ou Index Seek. Isso significa que a conversão de uma consulta de Scan para Seek pode ter um efeito adverso em tabelas/índices de um determinado tamanho?
ATUALIZAÇÃO: (Solução)
Obrigado Joe, você acertou em cheio com o Grau Máximo de Paralelismo.
Eu usei:
OPTION (OPTIMIZE FOR (@ID = 1))
UNKNOWN não fez o truque para o meu ambiente.
Para quem estiver interessado, aqui está um artigo útil de Kendra Little .
Atualmente, tenho uma conexão lenta entre os data centers LIVE e DR (o novo canal está a 6 meses).
Os bancos de dados são enviados com logs a cada 15 minutos.
Meu problema é que no final de semana os BACKUPS COMPLETOS demoram 3 dias para copiar para o DR.
Estou tentando encontrar uma maneira de tirar os backups completos semanais diretamente do espelho de envio de logs.
Estou limitado a alternar os bancos de dados Mirror entre “No Recovery” e “Standby” e não posso colocar o Mirror DB off-line.
Alguém já descobriu como fazer isso sem interromper o Log-shipping? Eu estou supondo que ele precisa ter o banco de dados no modo de espera. Já experimentei “WITH COPY-ONLY” mas precisava que a base de dados estivesse em “recovery”.
Existe uma ferramenta de terceiros? Por favor ajude.