All perguntas(dba)

Tenho tabela particionada com vários índices, todos estão alinhados e apenas um não. Isso ocorre porque ele controla a exclusividade por meio de mais de uma partição:

CREATE UNIQUE NONCLUSTERED INDEX [ix_uq_fltr_IdTransazioneRettificata_BM] ON [dbo].[Transazioni]
(
    [IdTransazioneRettificata] ASC
)
WHERE ([id]>(10000000000.) AND [StatusFatturazione]<>(15) AND [IdTransazioneRettificata] IS NOT NULL)
ON [PRIMARY]

O erro ocorre onde faço uma exclusão simples:

select id
into #t
from billing_prod2.dbo.Transazioni
where DataInserimento = '20240229' 
and Data = '20240201'
--(162.321 rows affected)

alter table #t add primary key(id)

delete t
from billing_prod2.dbo.Transazioni t
     join #t tt
        on t.id =  tt.id

A saída do SSMS:

Msg 3624, Nível 20, Estado 1, Linha 11 Uma verificação de declaração do sistema falhou. Verifique o log de erros do SQL Server para obter detalhes. Normalmente, uma falha de asserção é causada por um bug de software ou corrupção de dados. Para verificar se há corrupção no banco de dados, considere executar DBCC CHECKDB. Se você concordou em enviar dumps para a Microsoft durante a configuração, um mini dump será enviado à Microsoft. Uma atualização pode estar disponível na Microsoft no Service Pack mais recente ou em um Hotfix do Suporte Técnico. Msg 596, Nível 21, Estado 1, Linha 10 Não é possível continuar a execução porque a sessão está no estado kill. Msg 0, Nível 20, Estado 0, Linha 10 Ocorreu um erro grave no comando atual. Os resultados, se existirem, deveriam ser descartados.

A saída do log de erros:

Erro: 17065, Gravidade: 16, Estado: 1. Asserção do SQL Server: Arquivo: <"cxrowset.cpp">, linha = 2026 Asserção com falha = 'cstePrefix >= 1' O intervalo está sem prefixo na coluna de ID da partição. Este erro pode estar relacionado ao tempo. Se o erro persistir após a nova execução da instrução, use DBCC CHECKDB para verificar a integridade estrutural do banco de dados ou reinicie o servidor para garantir que as estruturas de dados na memória não estejam corrompidas. Erro: 3624, Gravidade: 20, Estado: 1. Falha na verificação de declaração do sistema. Verifique o log de erros do SQL Server para obter detalhes. Normalmente, uma falha de asserção é causada por um bug de software ou corrupção de dados. Para verificar se há corrupção no banco de dados, considere executar DBCC CHECKDB. Se você concordou em enviar dumps para a Microsoft durante a configuração, um mini dump será enviado à Microsoft.

Há também um arquivo de despejo que é longo o suficiente, mas se isso ajudar, posso colá-lo também.

Nada disso diz claramente qual índice tem problemas.

DBCC CHECKDBnão diz nada,

dbcc checktable('dbo.transazioni') with NO_INFOMSGS, ALL_ERRORMSGS

não diz nada.

A única coisa que eu poderia imaginar seria um índice que não é usado com frequência, caso contrário mais erros seriam relatados no log de erros, então comecei com este, não alinhado e menos usado.

Depois de descartá-lo, o erro desapareceu, então o problema realmente estava naquele índice não alinhado.

Alguém pode explicar isso?

O banco de dados tem TDE habilitado.

Microsoft SQL Server 2019 (RTM-CU22-GDR) (KB5029378) - 15.0.4326.1 (X64) 18 de agosto de 2023 14:05:15 Copyright (C) 2019 Microsoft Corporation Standard Edition (64 bits) no Windows Server 2016 Datacenter 10.0 ( Build 14393: ) (Hipervisor)

Tenho muitos lugares em meu aplicativo onde os usuários estão fazendo algo que não deveria ser simultâneo em bases por usuário e namespace. Então isso significa que:

• Dois usuários podem pressionar o mesmo botão ao mesmo tempo
• Um usuário não pode pressionar o mesmo botão uma segunda vez até que o primeiro toque seja concluído
• Um usuário pode pressionar botões diferentes ao mesmo tempo

Quais soluções eu tentei:

1. Bloqueio consultivo com função hash no usuário uuid - tem colisões e esse bloqueio consultivo, mas o bloqueio bloqueia todas as interações do usuário - então ele não pode pressionar dois botões ao mesmo tempo
2. INSERT& SELECT FOR UPDATE- bom, mas preciso preencher previamente a tabela com linha "pendente" para poluir o esquema da tabela com colunas desnecessárias.
3. Deseja implementar: locktable. Então, o que quero dizer é criar uma tabela com bloqueios do tipo consultivo. Terá duas colunas namespacee id- chave primária composta. Cada vez que o usuário pressionar o botão nº 1, haverá INSERT& FOR UPDATEpara namespace= button#1e id= {userid}.

Eu sinto que existem algumas pedras escondidas nesta (3ª) abordagem - alguém sabe disso? Você poderia gentilmente listar esses problemas?

Tenho certeza de que será pior em termos de desempenho do que os bloqueios de aconselhamento, mas será muito pior? Além disso, não consegui encontrar implementações dessa abordagem - parece que tive uma ideia estúpida que ninguém usa por algum motivo importante.

Confira esta conversa interessante em 2009 sobre este problema: https://www.postgresql.org/message-id/ [email protegido]

Por INSERT& FOR UPDATEquero dizer:

INSERT INTO adv_locks VALUES ('btn1', '123') ON CONFLICT ON CONSTRAINT adv_locks_pk DO NOTHING;
SELECT 1 FROM adv_locks WHERE namespace='btn1' and id='123' FOR UPDATE;

Dessa forma sempre haverá uma linha em uma tabela com esta tabela que pode ser bloqueada. (Ainda não me importo muito com o tamanho da mesa)

Entendo que uma ordem dessa pode ser quebrada (quero dizer, a solicitação nº 1 cria uma linha e a solicitação nº 2 seleciona a linha mais rapidamente), mas não é um problema para mim.

Tenho um banco de dados que existe há cerca de 10 anos, com centenas de tabelas, muitas das quais possuem vários milhões de linhas.

Não temos DBA e temos um número cada vez maior de consultas lentas. Estamos trabalhando para resolver essas dúvidas lentas, mas estou curioso sobre o ajuste do banco de dados em geral.

Você acha ANALYZE TABLEque nos traria algum ganho de desempenho? Isso é algo que os DBAs executam regularmente?

Prezada comunidade PostgreSQL, Estou tentando entender melhor os pontos de verificação do PostgreSQL internamente, então estava pensando neste cenário.

Digamos que temos checkpoint_timeout 15 minutos e checkpoint_completion_target 0,85. Agora, se enfrentarmos um caso em que um posto de controle, por algum motivo, leva, digamos, 20 minutos, por exemplo

13h00 - ponto de verificação 1 iniciado

13h15 O tempo limite do checkpoint foi acionado, mas o checkpoint1 ainda está em execução (o checkpoint2 aqui foi agendado)

13h20 - ponto de verificação 1 concluído

Minha pergunta é: o próximo ponto de verificação será acionado imediatamente às 13h20 ou será suspenso e iniciado às 13h30, conforme programado inicialmente? Presumo que dois pontos de verificação não podem se sobrepor. (Por enquanto não vamos discutir outros parâmetros que afetam como max_wal_size, que também podem ser acionados)

O ponto de verificação 1 grava TODOS os buffers sujos no disco, de modo que temos um estado muito limpo às 1:20, portanto não há necessidade de iniciar o segundo ponto de verificação? Pelo que entendi, o ponto de verificação antigo não tocará nas páginas que foram sujas após o seu início; portanto, neste caso, é necessário que o novo ponto de verificação seja acionado apenas após o término do antigo.

Além disso, o agendamento de checkpoint_timeout será alterado de alguma forma? Tipo programado para atrasar tanto quanto o anterior atrasou, ou não é alterável?

Ficarei mais do que feliz se você puder compartilhar mais detalhes sobre insights internos.

Só estou tentando ver se entendi direito :

Por padrão, qualquer erro que ocorra em uma função PL/pgSQL aborta a execução da função e da transação circundante

Tenho um procedimento que faz múltiplas operações de inserção em tabelas diferentes, porém no momento não as transformei em uma transação única. A documentação acima significa que, se ocorrer um erro, todas as operações executadas dentro do procedimento serão revertidas ou preciso capturar exceções e executar a reversão/confirmação manualmente?

Eu gostaria de calcular a divisão de duas contagens de linhas, algo assim:

(SELECT COUNT(*) FROM table WHERE col_name > crit) / (SELECT COUNT(*) FROM table)

No entanto, isso cria um erro de sintaxe quando tentei.

Como posso realizar o que quero?

Tentando restaurar o MSDB para um servidor substituto e recebendo esta mensagem:

Msg 3168, Nível 16, Estado 1, Linha 4 O backup do banco de dados do sistema no dispositivo e:\sqlbackup\2024-02-27_msdb_DEV.bak não pode ser restaurado porque foi criado por uma versão diferente do servidor ( 15.00.4335 ) do que este servidor ( 15.00.4355 ). Msg 3013, Nível 16, Estado 1, Linha 4 RESTORE DATABASE está sendo encerrado de forma anormal.

A definição de failback de acordo com os documentos da IBM é “o processo de retornar a produção ao seu local original após um desastre ou um período de manutenção programado”.

Pela minha leitura das postagens da comunidade postgresql, colocar um servidor primário antigo online novamente após o failover como um modo de espera que segue o novo primário também pode ser considerado failover.

Isso pode ocorrer porque é amplamente aceito que ter servidores de banco de dados idênticos é uma prática recomendada. No entanto, esta opção não está disponível para mim.

Tenho 2 servidores: Costanza e Kramer. Costanza é um servidor de alto desempenho. Kramer não.

Aqui está o cenário que estou tentando otimizar, passo a passo:

1. Costanza está em modo de falha irrecuperável (típico)
2. Kramer é promovido a primário
3. Costanza está disponível novamente e o PGDATA está intacto
4. Sincronize Costanza e Kramer de forma que nenhum dado gravado em Kramer seja perdido
5. Promover Costanza de volta ao status primário
6. Estabeleça Kramer como reserva

Estou focado nas etapas 4 e 5.

Ao executar o pg_rewind para reproduzir arquivos WAL, parece que "as modificações que ocorreram no servidor de origem após o último ponto de verificação comum são ignoradas - elas serão recuperadas de qualquer maneira quando o servidor de destino se tornar um modo de espera do servidor de origem". - veja esta pergunta SO

Deduzo disso que simplesmente executar pg_rewind não sincronizará Costanza e Kramer (etapa 4) porque as gravações em Kramer podem ter ocorrido após o último ponto de verificação comum. Isso também é o que observamos ao perfurar failbacks.

Minha solução para a etapa 4 é:

4a. Execute pg_rewind para sincronizar cronogramas divergentes

4b. Estabeleça o Costanza como um standby do Kramer e permita que ele acompanhe o atraso de replicação (assumindo que existam pontos de verificação pós-WALs)

Então

5. Desligue Kramer e promova Costanza para primário (novamente causando divergência na linha do tempo)

6a. Execute pg_rewind com Kramer como alvo

6b. Estabeleça Kramer como um standby do Costanza e permita que ele acompanhe o atraso de replicação (novamente, assumindo que existam pontos de verificação pós-WALs)

Este é um cenário pouco frequente. Mas não sei quais modos de falha encontrarei e se o PGDATA estará intacto ou não.

Este é um banco de dados muito grande e quero evitar mover dados por meio de backup de base sempre que possível.

Essa abordagem parece ineficiente para mim porque devo executar o pg_rewind duas vezes e tenho que estabelecer o Costanza como um modo de espera apenas para aplicar as modificações que ocorreram no ponto de verificação pós-comum de Kramer.

Devo minimizar a perda de dados e esta solução parece fazer isso com transferência mínima de dados.

(Um aparte: devo me preocupar com a criação adicional da linha do tempo? Isso parece inevitável, assim como ocorre na promoção de um banco de dados para primário)

Existe alguma maneira de aplicar as modificações no posto de controle comum de Kramer para Costanza sem estabelecer Costanza como reserva de Kramer?

Existe um caminho mais curto para um resultado equivalente? Ou existe um caminho que você pode julgar "mais fácil" de seguir em um cenário de falha de banco de dados?

Se bem entendi esta resposta, a diferença entre with Indexon Is Unqiuee a Unique Keyé principalmente cosmética.

Na interface MSSQL, quando mudo para uma chave exclusiva, ela Ignore Duplicate Keysé desativada.

Estou entendendo algo errado? Eu gostaria de usar Ignore Duplicate Keysneste caso. Quais são as consequências quando faço um Indexwith Is Uniqueversus a Unique Key.

Digite Indexcom Is Unique(menu suspenso ativado):

Tipo Unique Key(menu suspenso desativado):

Estou no Azure SQL, adicionando particionamento mensal a algumas tabelas de arquivo histórico (criando uma segunda tabela com esquema/função de particionamento e despejando as linhas do original nela). Eu estava usando uma consulta para visualizar todos os números de partição e intervalos de datas e consegui ver tudo depois de inserir os dados na nova tabela, mas depois de adicionar a restrição PK, minha consulta parou de retornar linhas ou se eu comentar as junções na tabela sys.index e abaixo vejo apenas uma única partição. Não tenho certeza de quais modificações precisaria fazer na consulta abaixo.

DDL:

CREATE PARTITION FUNCTION [PF_YearMonthBiWeekly] (datetime)
AS RANGE RIGHT FOR VALUES 
(
    '2024-01-01', '2024-01-16', '2024-02-01', '2024-02-16', '2024-03-01', '2024-03-16', '2024-04-01', '2024-04-16', '2024-05-01', '2024-05-16', '2024-06-01', '2024-06-16', '2024-07-01', '2024-07-16', '2024-08-01', '2024-08-16', '2024-09-01', '2024-09-16', '2024-10-01', '2024-10-16', '2024-11-01', '2024-11-16', '2024-12-01','2024-12-16',
    '2025-01-01'
);
GO

CREATE PARTITION SCHEME PS_YearMonthBiWeekly
AS PARTITION [PF_YearMonthBiWeekly]
ALL TO ([PRIMARY])
GO

CREATE TABLE [dbo].[Table1]
(
    [ID] [bigint] IDENTITY(1,1) NOT NULL,
    [Test_ID] [int] NULL,
    [Metric_ID] [int] NULL,
    [Metric_Desc] [nvarchar](300) NULL  
    [Result_On] [datetime] NULL,
) ON [PS_YearMonthBiWeekly] ([Result_On]);

Insira dados, consulte funcionando e adicione PK:

ALTER TABLE [dbo].[Table1] 
ADD CONSTRAINT [PK_Table1] PRIMARY KEY CLUSTERED ( [ID] ASC )
WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, FILLFACTOR = 80, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]

Consulta de visualização de partição:

SELECT
    OBJECT_SCHEMA_NAME(pstats.object_id) AS SchemaName
    ,OBJECT_NAME(pstats.object_id) AS TableName
    ,pstats.partition_number AS PartitionNumber
    ,pstats.row_count AS PartitionRowCount
    ,c.name AS PartitionKey
    ,CASE 
        WHEN pf.boundary_value_on_right = 0 
        THEN c.name + ' > ' + CAST(ISNULL(LAG(prv.value) OVER(PARTITION BY pstats.object_id ORDER BY pstats.object_id, pstats.partition_number), 'Infinity') AS VARCHAR(100)) + ' and ' + c.name + ' <= ' + CAST(ISNULL(prv.value, 'Infinity') AS VARCHAR(100)) 
        ELSE c.name + ' >= ' + CAST(ISNULL(prv.value, 'Infinity') AS VARCHAR(100))  + ' and ' + c.name + ' < ' + CAST(ISNULL(LEAD(prv.value) OVER(PARTITION BY pstats.object_id ORDER BY pstats.object_id, pstats.partition_number), 'Infinity') AS VARCHAR(100))
    END AS PartitionRange
    ,pf.name AS PartitionFunctionName
    ,ps.name AS PartitionSchemeName
    ,ds.name AS PartitionFilegroupName
    ,CASE pf.boundary_value_on_right WHEN 0 THEN 'Range Left' ELSE 'Range Right' END AS PartitionFunctionRange
    ,CASE pf.boundary_value_on_right WHEN 0 THEN 'Upper Boundary' ELSE 'Lower Boundary' END AS PartitionBoundary
    ,prv.value AS PartitionBoundaryValue
    ,p.data_compression_desc AS DataCompression
    ,case 
        when i.[type] = 0 then 'Nonclustered Heap Index'
        when i.[type] = 1 then 'Clustered Index'
        when i.[type] = 2 then 'Nonclustered Unique Index'
        when i.[type] = 3 then 'XML Index'
        when i.[type] = 4 then 'Spatial Index'
        when i.[type] = 5 then 'Clustered Columnstore Index'
        when i.[type] = 6 then 'Nonclustered Columnstore Index'
        when i.[type] = 7 then 'Nonclustered Hash Index'
        else NULL
    end as index_type
FROM sys.dm_db_partition_stats AS pstats
INNER JOIN sys.partitions AS p 
    ON pstats.partition_id = p.partition_id
INNER JOIN sys.destination_data_spaces AS dds 
    ON pstats.partition_number = dds.destination_id
INNER JOIN sys.data_spaces AS ds 
    ON dds.data_space_id = ds.data_space_id
INNER JOIN sys.partition_schemes AS ps 
    ON dds.partition_scheme_id = ps.data_space_id
INNER JOIN sys.partition_functions AS pf 
    ON ps.function_id = pf.function_id
LEFT OUTER JOIN sys.indexes AS i 
    ON pstats.object_id = i.object_id 
    AND pstats.index_id = i.index_id AND dds.partition_scheme_id = i.data_space_id 
    --AND i.type <= 1 /* Heap or Clustered Index */
INNER JOIN sys.index_columns AS ic 
    ON i.index_id = ic.index_id 
    AND i.object_id = ic.object_id 
    AND ic.partition_ordinal > 0
INNER JOIN sys.columns AS c 
    ON pstats.object_id = c.object_id 
    AND ic.column_id = c.column_id
LEFT JOIN sys.partition_range_values AS prv 
    ON pf.function_id = prv.function_id 
    AND pstats.partition_number = (CASE pf.boundary_value_on_right WHEN 0 THEN prv.boundary_id ELSE (prv.boundary_id+1) END)
--WHERE pstats.object_id = OBJECT_ID('Table1')
--ORDER BY TableName, PartitionNumber;
GO