Uma pergunta geral sobre o particionamento de tabela. Se você estiver particionando uma tabela em uma coluna Date com o RANGE sendo um período de 12 meses para cada uma.
Se você estiver inserindo em períodos de partição anteriores, você esperaria que o desempenho fosse mais lento em comparação com a inserção na partição atual?
Esta é uma continuação para esta pergunta há alguns anos dividindo partições existentes no SQL 2014 , onde agora há anos de partição para 2011 até 2021.
Preciso arquivar partições de 2011 a 2015 movendo os dados dessas partições para uma nova tabela/banco de dados e, em seguida, arquivar esse banco de dados e remover as partições de 2011 a 2015 da tabela de log original.
Estou movendo com sucesso os dados para uma tabela Log_Archive com a seguinte instrução.
ALTER TABLE dbo.Log
SWITCH PARTITION $PARTITION.pfYearlyPartition_Log('20120101')
TO dbo.Log_Archive PARTITION $PARTITION.pfYearlyPartition_Log_Archive('20120101');
O que não tenho certeza é como agora removo essa partição da tabela Log, pois ela ainda está lá, mas com 0 linhas dentro dela. Alguém pode aconselhar? Você pode ver abaixo que movi com sucesso os dados de Log para Log_Archive, mas fiquei com 0 linhas na tabela de log original que desejo remover.
Espero não precisar re-particionar toda a tabela, pois é muito grande.
Eu tenho a seguinte configuração de partição em uma tabela.
Estou querendo criar uma nova partição que começa em 2019-01-01.
É a maneira correta de fazer isso e pode ser executado agora para que esteja pronto para 2019?
ALTER DATABASE mydatabase ADD FILEGROUP [Year7FileGroup]
GO
ALTER DATABASE mydatabase
ADD FILE
(NAME = N'data_year7',
FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\DATA\data_year73.ndf',
SIZE = 5000MB,
FILEGROWTH = 500MB)
TO FILEGROUP [Year7FileGroup]
GO
ALTER PARTITION SCHEME psYearlyPartition_Log
NEXT USED Year7FileGroup;
ALTER PARTITION FUNCTION pfYearlyPartition_Log()
SPLIT RANGE('20190101');
Eu tenho uma tabela do SQL Server que contém mais de 20 bilhões de linhas, com 13 bilhões de linhas na última partição.
A tabela está atualmente particionada de 6 maneiras por um campo "Time":
2011
2012
2013
2014
2015
2016/2017/2018
A partição 2016/2017/2018 precisa ser dividida em suas próprias partições para que haja uma partição 2016, 2017, 2018.
Como isso pode ser feito e, no processo, evitando um crescimento massivo de arquivos de log? O banco de dados está em Simple Recovery e atualmente cada partição está em um grupo de arquivos separado em seu próprio conjunto de discos.
CREATE TABLE [dbo].[Log](
[RefNo] [nchar](7) NOT NULL,
[DevID] [nvarchar](7) NOT NULL,
[Time] [datetime] NOT NULL,
[summary] [float] NULL,
[staging] [float] NULL,
[position] [float] NULL,
CONSTRAINT [PK_Log] PRIMARY KEY CLUSTERED
(
[RefNo] ASC,
[DevID] ASC,
[Time] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = ON, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 96)
)
Eu li este artigo recentemente sobre os problemas de desempenho relacionados ao Functions.
Atualmente estou na fase de desenvolvimento de um novo banco de dados na plataforma Azure SQL Database. Ainda não será lançado por um novo mês. Estou usando uma variedade de funções de valor escalar, sendo uma delas converter UTC em data local, onde é especificado na tabela de configuração, por exemplo, AUS Eastern Standard Time
A função é chamada da seguinte forma:
SELECT
dbo.fnGetLocalDate(DateColumn) as DateColumn,
FROM
table
Alguém tem alguma sugestão sobre como evitar funções em casos como este? Acho-os úteis para reutilização de código e não sei como evitá-lo aqui.
Também estou me perguntando se com o vNext corrigindo os problemas de desempenho com o Functions na plataforma do Azure é melhor continuar trabalhando com funções.
CREATE FUNCTION [dbo].[fnGetLocalDate]
(
@DateToConvert datetimeoffset = NULL
)
RETURNS datetimeoffset
AS
BEGIN
DECLARE @TimeZone varchar(50)
RETURN
CASE
WHEN @DateToConvert is NULL then NULL
ELSE
CONVERT(datetimeoffset, @DateToConvert AT TIME ZONE (SELECT Value FROM LookUp.Config WHERE Property = 'TimeZone'))
END
END
Tenho a seguinte consulta:
ALTER PROCEDURE [dbo].[spSearchClient]
@SearchWords NVARCHAR(MAX) = NULL,
@LowerDate DATE = NULL,
@UpperDate DATE = NULL,
@UserCreated nvarchar(450)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @UserAccountID smallint
DECLARE @SearchWordCount int
SELECT @UserAccountID = dbo.fnGetUserAccountID(@UserCreated)
CREATE TABLE #SearchWords
(
ID int IDENTITY(1,1),
Word NVARCHAR(50)
)
INSERT INTO #SearchWords
(
Word
)
SELECT
value
FROM
STRING_SPLIT(@SearchWords, ' ')
WHERE
TRIM(value) <> ''
SELECT @SearchWordCount = @@ROWCOUNT;
SELECT
C.ClientID,
C.FirstName,
C.LastName,
C.FullName,
C.DateOfBirth,
G.GenderName,
G.GenderIcon,
C.VerificationCode,
V.LastVisitDate
FROM
Client C
OUTER APPLY (
SELECT MAX(StartDate) AS LastVisitDate
FROM Visit AS V
WHERE C.ClientID = V.ClientID
) AS V
INNER JOIN LookUp.Gender G on
C.GenderID = G.GenderID
WHERE
(
EXISTS( -- if we have words
SELECT *
FROM #SearchWords s
WHERE (c.FirstName LIKE CONCAT('%',s.Word,'%'))
OR (c.LastName LIKE CONCAT('%',s.Word,'%'))
OR (c.VerificationCode LIKE CONCAT('%',s.Word,'%'))
)
OR @SearchWordCount = 0 --if we don't have words
)
AND DateOfBirth BETWEEN ISNULL(@LowerDate,DateOfBirth) AND ISNULL(@UpperDate,DateOfBirth)
INSERT INTO UserSearchLog
(
SearchWords,
LowerDate,
UpperDate,
SearchResultsCount,
UserCreated
)
VALUES
(
@SearchWords,
@LowerDate,
@UpperDate,
@@ROWCOUNT,
@UserAccountID
)
DROP TABLE #SearchWords
END
O plano de execução é https://www.brentozar.com/pastetheplan/?id=BkGzfUeHz
A consulta funciona como deveria, mas leva de 3 a 7 segundos para ser executada e parece ser devido ao seguinte, que tem uma execução para cada linha na tabela Client:
WHERE
(
EXISTS( -- if we have words
SELECT *
FROM #SearchWords s
WHERE (c.FirstName LIKE CONCAT('%',s.Word,'%'))
OR (c.LastName LIKE CONCAT('%',s.Word,'%'))
OR (c.VerificationCode LIKE CONCAT('%',s.Word,'%'))
)
OR @SearchWordCount = 0 --if we don't have words
)
Quer saber se alguém conhece uma maneira melhor e mais eficaz de fazer isso que consumiria menos tempo?
Se alguns dados de exemplo forem úteis, por favor me avise.
Isso está fazendo minha cabeça, mas estou preso em tentar obter um Index Seek no agregado MAX dentro desta consulta.
Aqui está o plano de execução - e estou me perguntando o que estou perdendo aqui, pois atualmente a consulta leva 3/4 segundos para ser concluída, o que é muito lento. Eu indexei em StartDate, ClientID sem sorte.
CREATE TABLE #SearchWords
(
ID int IDENTITY(1,1),
Word NVARCHAR(50)
)
INSERT INTO #SearchWords
(
Word
)
SELECT
value
FROM
STRING_SPLIT(@SearchWords, ' ')
WHERE
TRIM(value) <> ''
SELECT
C.ClientID,
C.FirstName,
C.LastName,
C.FullName,
C.DateOfBirth,
G.GenderName,
G.GenderIcon,
C.VerificationCode,
MAX(V.StartDate) as LastVisitDate
FROM
Client C
LEFT JOIN Visit V on
C.ClientID = V.ClientID
INNER JOIN LookUp.Gender G on
C.GenderID = G.GenderID
WHERE
(
EXISTS( -- if we have words
SELECT *
FROM #SearchWords s
WHERE (c.FirstName LIKE CONCAT('%',s.Word,'%'))
OR (c.LastName LIKE CONCAT('%',s.Word,'%'))
OR (c.VerificationCode LIKE CONCAT('%',s.Word,'%'))
)
OR
(SELECT COUNT(*) FROM #SearchWords)=0 -- if we haven't any words
)
AND DateOfBirth BETWEEN ISNULL(@LowerDate,DateOfBirth) AND ISNULL(@UpperDate,DateOfBirth)
GROUP BY
C.ClientID,
C.FirstName,
C.LastName,
C.FullName,
C.DateOfBirth,
G.GenderName,
G.GenderIcon,
C.VerificationCode
Eu tive sp_BlizFirst rodando por alguns dias a cada 12 minutos para capturar as várias estatísticas.
O que eu percebi, porém, é que ele não parece reunir muitas estatísticas de desempenho relacionadas a arquivos além das paradas de E/S.
Há informações suficientes para tomar uma decisão sobre se a E/S é um problema ou não com base nas Estatísticas de espera e paradas de E/S? Não consigo encontrar nas tabelas Blitz nenhuma menção ao Disk avg. tempo de leitura, disco avg. tempo de gravação, méd. comprimento da fila de disco que eu pensei que deveria ser considerado também?
Alguém pode dar algum feedback sobre o abaixo? Minhas estatísticas de paralelismo definitivamente precisam ser analisadas adequadamente (CXPACKET), mas também estou curioso sobre o desempenho de minha entrada/saída de disco. As esperas do OLDEDB, acredito, estão sendo causadas por servidores vinculados e Idera SQL Diagnostic Manager monitorando a instância a cada 1 minuto.
De https://www.sqlskills.com/blogs/paul/are-io-latencies-killing-your-performance/ eu li o seguinte: Todo mundo tem sua ideia do que constitui latência de E/S boa ou ruim, e aqui está minha take: Excelente: < 1ms Muito bom: < 5ms Bom: 5 – 10ms Ruim: 10 – 20ms Ruim: 20 – 100ms Chocantemente ruim: 100 – 500ms UAU!: > 500ms
Se eu for por isso, estou na categoria Ruim.
Aqui estão minhas estatísticas de espera:
Servidor1
A parada de E/S de leitura média é 23,91
O MAX Read I/O Stall era 1162
A parada média de E/S de gravação é de 0,71
O MAX Write I/O Stall era 139
e aqui está o extrato completo.
Servidor 2
A parada de E/S de leitura média é 26,28
O MAX Read I/O Stall foi de 428
A parada média de E/S de gravação é de 2,60
O MAX Write I/O Stall era 667
Esta é uma pergunta um pouco embaraçosa, e eu não posso acreditar que eu perdi isso por tantos anos.
Eu tenho um banco de dados de terceiros que tem 401 tabelas de heap. Recentemente, comecei a usar os scripts e a configuração de Brent Ozar sp_BlitzFirstpara executar a cada 15 minutos para coletar estatísticas de espera etc.
O que ele descobriu foi que toda vez que ele passava por um período de 24 horas estava me dizendo para corrigir os registros encaminhados . O que provavelmente chocará alguns leitores que eu executei uma consulta nos DMVs e obtive algumas tabelas com mais de 150.000 valores de registro encaminhados.
Eu entendo que corrigir isso é ter um índice clusterizado na tabela ou como uma solução temporária para executar o ALTER TABLE [tablename] REBUILD.
O que não consegui encontrar, no entanto, é se isso deixa a tabela offline e se há outros problemas que eu deveria estar ciente antes de executar este comando.
Estou usando a Enterprise Edition de 2008 R2 e gostaria de saber se executá-la dessa maneira eliminará a necessidade de uma interrupção?
ALTER TABLE [tablename] REBUILD WITH (ONLINE = ON);
Alguém tem alguma experiência com isto?
Esta é uma continuação do que li em Existe algum motivo para interromper os backups do log de transações durante uma janela de manutenção? na resposta proposta por sp_BlitzErik.
Eu uso o script de indexação de Ola Hallengren e tenho as configurações especificadas conforme abaixo. Eu corro isso uma vez por semana através de um trabalho de agente.
@Databases nvarchar(max),
@FragmentationLow nvarchar(max) = NULL,
@FragmentationMedium nvarchar(max) = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh nvarchar(max) = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 int = 5,
@FragmentationLevel2 int = 30,
@PageCountLevel int = 500,
Eu sei que, além de uma reconstrução de índice, uma atualização de estatísticas é feita automaticamente, mas tenho as seguintes propriedades de banco de dados definidas em todos os meus bancos de dados que acredito que devem cuidar da atualização das estatísticas:
Auto Create Statistics = True
Auto Update Statistics = True
Auto Update Statistics Asynchronously = True
O que geralmente é a melhor prática aqui para essas configurações e atualizar as estatísticas regularmente? Você deve atualizar as estatísticas todas as noites? Não tenho certeza de como medir se as estatísticas devem ser atualizadas ou não, e é por isso que tenho essas propriedades do banco de dados definidas.
Eu vejo na resposta de sp_BlitzErik que ele menciona " Você ainda vai querer atualizar as estatísticas regularmente, e você pode fazer isso com este comando:"
com o seguinte comando, mas atualizar estatísticas regularmente é muito geral.
EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = NULL,
@FragmentationHigh = NULL,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y',
@StatisticsSample = NULL,
@LogToTable = 'Y';