Perguntas[database-internals](dba)

Estou em uma situação peculiar:

Eu tenho vários índices com expressões que usam uma função. Quero trocá-los para uma função diferente, onde posso garantir que a função se comporte da mesma forma (para que os valores indexados não sejam inválidos). Idealmente, não quero descartar o índice existente e reindexá-lo, porque isso requer mais sobrecarga de desenvolvimento.

Eu posso ver na pg_indextabela, há uma indexprscoluna, que contém a definição "interna" de um índice (a pg_indexestabela é uma versão muito impressa disso). Especificamente, acho que identifiquei os índices relevantes para ter um formato nos moldes de ({FUNCEXPR :funcid 870 :funcresulttype 25 :funcretset false...

Voltando funcid 870para o information_schema.routines, consegui correlacioná-lo no specific_name(que contém esse funcid) e pude determinar que é de fato a função específica que quero alterar.

Seria - teoricamente - possível substituir esse funcid pelo novo funcid e os índices então se refeririam à nova função? Como eu faria isso, já que esta coluna é do tipo pg_node_tree? Se não, existe uma maneira de atingir meu objetivo de uma maneira não hackeada?

Adendo: Provavelmente ainda farei isso da maneira "limpa", a menos que haja uma maneira segura e comprovada de fazer isso, mas isso despertou meu interesse o suficiente para fazer uma pergunta sobre isso.

Digamos que eu tenha uma coluna de tamanho fixo e estou SELECTpartindo dela, digamos 100 linhas. Ao ler diferentes linhas da coluna de comprimento fixo, o SQL Server verifica o comprimento da coluna para cada linha ou verifica uma vez e reutiliza essas informações para que as linhas subsequentes possam ser lidas mais rapidamente?

Por outro lado, para colunas de comprimento variável, o SQL Server precisa verificar o comprimento de cada coluna de comprimento variável para cada linha, usando a matriz de deslocamento.

Portanto, minha pergunta é: o SQL Server verifica o comprimento dos tipos de dados de comprimento fixo para cada linha (ou seja, após os bits de status A e B da linha)? Logicamente, quando ele precisa ler uma coluna de comprimento fixo, ele só precisa verificá-lo uma vez.

Essa sobrecarga é a razão pela qual os índices são melhores em colunas de comprimento fixo?

Não tentando resolver nenhum problema, apenas tentando entender.

Informações extras: em relação a que os índices são melhores em colunas de comprimento fixo: Toda essa questão começou para mim quando eu estava lendo este artigo Estratégias de indexação para desempenho do SQL Server . Em um ponto, ele diz: "Uma chave de índice clusterizado deve ser estreita, mas também usar um tipo de dados de largura fixa". Quais são as razões para esta afirmação? Só consigo pensar no motivo relacionado à minha pergunta, ou seja, colunas de comprimento fixo são mais baratas de ler, porque o comprimento só precisa ser verificado uma vez.

É meu entendimento, com base em várias fontes (incluindo esta: https://techcommunity.microsoft.com/t5/sql-server/migrating-sap-workloads-to-sql-server-just-got-2-5x-faster /ba-p/384910 ) que o SQL Server Trace Flag 715 deve ser equivalente à dica de consulta TABLOCK - com a diferença de que TF715 pode ser definido nos níveis de sessão e global, enquanto TABLOCK só pode ser usado como uma dica de consulta.

Meu problema é que testei no SQL Servers 2016 e 2019 Development Editions no modelo de recuperação simples e estou obtendo resultados diferentes entre o TABLOCK e o TF715, independentemente de qual servidor eu uso. O TABLOCK está funcionando conforme o esperado e o TF715 não. Especificamente, TABLOCK diz ao SQL Server para remover um bloqueio de tabela inteiro para operações em massa e registrar minimamente a operação .

Considere o código a seguir. Isso insere 10.000 linhas em um heap.

DROP TABLE IF EXISTS Test
GO

CREATE TABLE Test (t VARCHAR(100))
GO

INSERT INTO Test (t)
SELECT TOP (10000)
    x = ROW_NUMBER() OVER (ORDER BY s1.[object_id])
FROM       sys.columns AS s1
CROSS JOIN sys.columns AS s2

Agora, se você executar este próximo bloco de código, poderá ver que ele registrou 10.000 linhas.

SELECT 
    [Fully Logged Rows] = COUNT_BIG(*) 
FROM sys.fn_dblog(NULL, NULL) AS FD
WHERE
    FD.Operation = N'LOP_INSERT_ROWS'
    AND FD.Context = N'LCX_HEAP'
    AND FD.AllocUnitName = N'dbo.Test';

Ok, agora se fizermos tudo de novo usando a dica TABLOCK, você verá que se torna uma operação minimamente registrada (ou seja, a contagem de linhas totalmente registrada = 0).

DROP TABLE IF EXISTS Test
GO

CREATE TABLE Test (t VARCHAR(100))
GO

INSERT INTO Test WITH (TABLOCK) (t)
SELECT TOP (10000)
    x = ROW_NUMBER() OVER (ORDER BY s1.[object_id])
FROM       sys.columns AS s1
CROSS JOIN sys.columns AS s2

--0 Fully Logged Rows
SELECT 
    [Fully Logged Rows] = COUNT_BIG(*) 
FROM sys.fn_dblog(NULL, NULL) AS FD
WHERE
    FD.Operation = N'LOP_INSERT_ROWS'
    AND FD.Context = N'LCX_HEAP'
    AND FD.AllocUnitName = N'dbo.Test';

No entanto, quando tento habilitar o TF715 (e retirar a dica TABLOCK), ainda recebo 10.000 linhas totalmente registradas quando esperaria uma operação minimamente registrada.

--Enable TF715 on both a session and global level to cover all bases...
DBCC TRACEON(715)
GO
DBCC TRACEON(715, -1)
GO
DBCC TRACESTATUS
GO

DROP TABLE IF EXISTS Test
GO

CREATE TABLE Test (t VARCHAR(100))
GO

INSERT INTO Test (t)
SELECT TOP (10000)
    x = ROW_NUMBER() OVER (ORDER BY s1.[object_id])
FROM       sys.columns AS s1
CROSS JOIN sys.columns AS s2

--10000 Fully Logged Rows
SELECT 
    [Fully Logged Rows] = COUNT_BIG(*) 
FROM sys.fn_dblog(NULL, NULL) AS FD
WHERE
    FD.Operation = N'LOP_INSERT_ROWS'
    AND FD.Context = N'LCX_HEAP'
    AND FD.AllocUnitName = N'dbo.Test';

DBCC TRACEOFF(715)
GO
DBCC TRACEOFF(715, -1)
GO
DBCC TRACESTATUS
GO

O que estou negligenciando? Eu não deveria precisar reiniciar o SQL Server para habilitar TFs por meio de DBCC, correto...?

Agradeço antecipadamente.

No PostgreSQL, as sequências são projetadas para ter lacunas pelos motivos mencionados neste post https://stackoverflow.com/questions/9984196/postgresql-gapless-sequences . Minha pergunta é: as sequências não poderiam ser feitas quase sem intervalos verificando periodicamente (digamos uma vez por dia) quais números de sequência não são usados ​​e adicionando-os de volta à sequência a ser usada?

Suponho que atualmente o postgres implementa uma sequência como um contador que incrementa toda vez que é acessado. Em vez disso, pode ser implementado com uma lista de valores livres e um contador. A sequência funcionaria da seguinte forma:

# python style pseudo code

class Sequence:
    def __init__(self):
        self.free_numbers_set = []
        self.counter = 0

    def get_next_sequence_value(self):
        if not isempty(self.free_numbers_set):
            id = self.free_numbers_set.pop(0)
        else:
            id = self.counter
            id ++

        return id

    def add_free_numbers(self, column):
        for i in range(0:self.counter):
            if not i in column:
                free_numbers_set.append(i)
        free_numbers_set.sort()

Toda vez que precisamos de um novo id, executamos get_next_sequence_value()e periodicamente executamosadd_free_numbers(column)

Atualizações que abordam algumas das perguntas

1. Para colunas de identidade, obter os valores atualmente usados ​​seria trivial. Em outros casos caberia ao usuário fornecer uma lista de valores que já estão em uso.
2. A interação com o MVCC precisaria ser pensada. Pode-se implementá-lo de forma que, durante a atualização dos valores ausentes, a sequência seja padronizada para apenas incrementar o contador - isso evitaria conflitos.

Acredito que esta solução poderia fornecer sequências menos esparsas que permitiriam aos usuários usar tipos de id menores (int vs bigint) sendo compatível com versões anteriores com a implementação atual.

De acordo com meu entendimento, quando executamos um comando ou consulta, o cliente Postgres envia uma mensagem de front-end e, em troca, obtém a resposta no formato de mensagem de back-end.

Como faço para capturar e verificar essas mensagens em uma caixa Linux?

Por exemplo, digamos que estou executando o comando abaixo via psqlcliente

 psql --username=foo --dbname=mydb --password=foobar

Acredito que o cliente cria StartupMessage .

Existe uma maneira de rastrear essa interação? Considerando que o servidor e o cliente estão sendo executados na mesma máquina.

Depois de ler Unusual THREADPOOL Waits de Josh Darnell, um usuário do Twitter mencionou que há um sinalizador de rastreamento não documentado para evitar o corte de trabalhadores ociosos :

A ideia é que, uma vez que o SQL Server tenha criado threads suficientes para atender a carga de trabalho de pico, ele não deve aparar os threads de trabalho (liberando-os para o sistema operacional) após 15 minutos ou mais de não serem necessários.

Os threads de trabalho ociosos continuarão a usar recursos (por exemplo, memória), mas não haverá a explosão de THREADPOOLesperas quando mais trabalhos forem necessários de repente. Aparentemente, isso pode ser útil ao usar grupos de disponibilidade AlwaysOn.

O que é esse sinalizador de rastreamento não documentado e como ele funciona?

Eu entendo que, se o comprimento for > 255, serão necessários 2 bytes para armazenar o prefixo de comprimento. Só preciso verificar minhas suposições. Por favor, diga-me o prefixo de comprimento e o comprimento de string('abcd') para charsets(latin1, ucs2, utf8mb4). Para uma coluna varchar(20). A documentação diz:

[...] Para a string 'abcd', L é 4 e o requisito de armazenamento é de cinco bytes. Se a mesma coluna for declarada para usar o conjunto de caracteres de byte duplo ucs2, o requisito de armazenamento é de 10 bytes : O comprimento de 'abcd' é oito bytes e a coluna requer dois bytes para armazenar comprimentos porque o comprimento máximo é maior que 255 (até 510 bytes). [...]

^{Referência: 11.7 Requisitos de armazenamento de tipo de dados (Oracle | Documentos)}

Eu só não entendo por que para 'abcd' com charset 'ucs2' requer um prefixo de comprimento de 2 bytes mesmo depois de ser menor que 255.

Acabei de acessar alguns recursos dizendo:

extensões uniformes são de propriedade de um único objeto e extensões mistas podem ser compartilhadas por no máximo 8 objetos.

Mas não consigo entender o significado do insight, como qual é o benefício dessa estrutura? basicamente, eu sou novo neste campo, então se você pudesse fornecer alguns exemplos intuitivos e aplicações, seria muito apreciado.

Na mensagem de erro a seguir, o motivo fornecido é "Opção de proteção inválida". O que isso indica?

O SQL Server detectou um erro de E/S baseado em consistência lógica: opção de proteção inválida

Para os fins desta pergunta, não preciso saber nada sobre "como executar o DBCC" ou "verificar se há corrupção". Eu entendi. Estou apenas curioso sobre a parte da "causa raiz" e o que poderia causar esse sabor do erro de E/S baseado em consistência lógica.

Não vejo por que uma reconstrução de índice exigiria um bloqueio Sch-M no índice fornecido.