All perguntas(dba)

Dado que uso a seguinte tabela:

CREATE TABLE operations (
    asset_id varchar(255) NOT NULL,
    event_id varchar(255) NULL,
    updated_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP
);

e o seguinte índice:

CREATE INDEX idx
ON operations ( event_id);

Quando executo a seguinte consulta

WITH ROWS AS (
SELECT
    *,
    ROW_NUMBER() OVER (PARTITION BY asset_id ORDER BY updated_at DESC) AS row_num
FROM
    operations
)
SELECT
    *
FROM
    ROWS
WHERE
    row_num = 1
    AND event_id IN ('bb87d265b3c82098f7cd6913a4eb6df2', '4780d32075328c6f6f0ebe4e7fd48662')
    AND operation != 'DELETE';

o índice não é usado:

Subquery Scan on rows  (cost=7159.77..7909.77 rows=1 width=598) (actual time=48.159..48.160 rows=0 loops=1)
  Filter: (((rows.event_id)::text = ANY ('{bb87d265b3c82098f7cd6913a4eb6df3,4780d32075328c6f6f0ebe4e7fd48662}'::text[])) AND ((rows.operation)::text <> 'DELETE'::text) AND (rows.row_num = 1))
  Rows Removed by Filter: 20000
  ->  WindowAgg  (cost=7159.77..7559.77 rows=20000 width=598) (actual time=38.352..46.491 rows=20000 loops=1)
        Run Condition: (row_number() OVER (?) <= 1)
        ->  Sort  (cost=7159.77..7209.77 rows=20000 width=590) (actual time=38.343..39.519 rows=20000 loops=1)
              Sort Key: operations.asset_id, operations.updated_at DESC
              Sort Method: quicksort  Memory: 2911kB
              ->  Seq Scan on operations  (cost=0.00..467.00 rows=20000 width=590) (actual time=0.012..2.993 rows=20000 loops=1)
Planning Time: 0.144 ms
Execution Time: 48.436 ms

Se eu remover a condição row_num, o índice será usado. por exemplo :

WITH ROWS AS (
SELECT
    *
FROM
    operations
)
SELECT
    *
FROM
    ROWS
WHERE
    event_id IN ('bb87d265b3c82098f7cd6913a4eb6df3', '4780d32075328c6f6f0ebe4e7fd48662')
    AND operation != 'DELETE';\

Alguém pode explicar por que a primeira consulta não usa o índice?

Temos SQL Servers com versões SQL Server 2016 e SQL Server 2019. Já verificamos que podemos fazer failover no SQL Server 2019 sem listener mas não consigo testar no SQL Server 2016. Sabe se também é possível?

Estou fazendo um FDW (Foreign Data Wrapper) no PostgreSQL para mim usando C.
Parece estar funcionando rudimentarmente, mas tenho um problema.

Quando passo uma consulta como a seguinte via psql:

select * from FOREIGN_TABLE_A where COL1=1 and COL2=1;

...então o FDW ignora o segundo predicado de pesquisa (COL2=1).

Como posso fazer o PostgreSQL usar meu segundo predicado de pesquisa?

Tentei depurar, mas o PostgreSQL nunca retornou nenhum resultado útil.

Existem regras para permitir que o PostgreSQL use vários predicados em um FDW GetForeignRelSize()em GetForeignPaths()ou GetForeignPlan()?

Por exemplo, suponha que você execute as consultas abaixo.

UPDATE `user`
SET point=30
WHERE id=1;

SELECT nickname
FROM `user`
WHERE id=1;

Nesse caso, a segunda consulta SELECT deve aguardar o bloqueio da consulta UPDATE mesmo que não leia a coluna de pontos?

Em caso afirmativo, é um bom design separar a coluna de atualização frequente - ponto - em uma tabela separada user_point?

Faço parte da equipe de banco de dados da minha empresa e atualmente estou enfrentando um dilema em relação à otimização e desempenho de consultas. Sempre que alguns de meus colegas se deparam com uma consulta lenta, a solução padrão é criar um índice para acelerá-la. Isso resultou em algumas tabelas com mais de 70 índices!

Pessoalmente, tendo a abordar esta questão de forma diferente. Em vez de criar novos índices a cada vez, muitas vezes me pego modificando os índices existentes, como adicionar uma coluna incluída adicional, etc., para acelerar uma consulta. Contudo, nem todos os membros da equipe adotam essa abordagem, levando a um número crescente de índices em nosso banco de dados.

Apesar desses esforços, notei uma desaceleração em outras operações DML à medida que o número de índices aumenta. Parece um beco sem saída: sem o índice, a consulta fica lenta, mas com o índice, todo o resto fica um pouco mais lento.

Estou procurando conselhos sobre como navegar nessa situação. Quantos índices são geralmente considerados “demais”? Existem práticas recomendadas ou estratégias para equilibrar a necessidade de consultas rápidas com o desempenho geral do banco de dados?

Quaisquer insights ou recursos seriam muito apreciados.

Obrigado!

Atualmente estou brincando com fn_dbloga função do SQL Server e me deparei com um conceito que estou tendo dificuldade para entender. No resultado da função, há uma coluna 'ID da página' e uma coluna 'ID do slot', combinação correspondente a um único registro de log.

Minha pergunta é: isso significa que um registro de log só pode (no máximo) descrever a modificação de uma única linha?

Estou tentando obter uma compreensão mais profunda de como o SQL Server gerencia e representa modificações de dados, principalmente no que diz respeito à função fn_dblog, portanto, quaisquer insights ou recursos serão muito apreciados.

Tenho máquinas virtuais em dois tipos diferentes de hosts (vmware).

O host tipo A possui CPUs com velocidade de clock de 2,09 GHz
O host tipo B possui CPUs com velocidade de clock de 2,69 GHz.
Todos os outros recursos são os mesmos no nível da VM (número de soquetes de CPU/processadores virtuais, memória e disco).

Existem grupos de disponibilidade configurados entre as VMs no host tipo A (cada VM está em um host diferente). A mesma configuração com VMs no host tipo B, mas a diferença é que também existem grupos de disponibilidade distribuída configurados aqui (cada VM ainda está em um host diferente).

Notamos que algumas consultas são executadas mais rapidamente no host tipo A do que no host tipo B. Indo mais a fundo, encontrei este recurso de solução de problemas: https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance /solucionar problemas de consulta-perf-entre-servidores

Executei o T-SQL abaixo desse link (modificando o número de giros):

SET NOCOUNT ON 
DECLARE @spins INT = 0
DECLARE @start_time DATETIME = GETDATE(), @time_millisecond INT

WHILE (@spins < 2000000)
BEGIN
   SET @spins = @spins +1
END

SELECT @time_millisecond = DATEDIFF(millisecond, @start_time, getdate())
SELECT @spins Spins, @time_millisecond Time_ms,  @spins / @time_millisecond Spins_Per_ms

Resultados de exemplo para host tipo A: Spins = 2.000.000, Time_ms = 135517, Spins_Per_ms = 14
Exemplos de resultados para host tipo B: Spins = 2.000.000, Time_ms = 553587, Spins_Per_ms = 3

Os resultados do Powershell estão sempre muito mais próximos.

$bf = [System.DateTime]::Now
for ($i = 0; $i -le 20000000; $i++) {}
$af = [System.DateTime]::Now
Write-Host ($af - $bf).Milliseconds " milliseconds"
Write-Host ($af - $bf).Seconds " Seconds"

Resultados de exemplo do Host A: 18 segundos 704 milissegundos
Resultados de exemplo do Host B: 23 segundos 255 milissegundos

A utilização geral da CPU causada pela carga de trabalho normal é sempre menor nas VMs no host tipo B do que nas VMs no host tipo A antes, durante e depois da execução da consulta. O tempo de prontidão da CPU é aproximadamente 100-200 ms maior no VM Host A do que no VM Host B.

Informação adicional:

• As únicas VMs que apresentam desempenho lento do t-sql são as VMs que participam do DAG. Outras VMs em execução no Host tipo B que não estão neste DAG específico (incluindo todas aquelas configuradas em um DAG diferente) são muito mais rápidas que as VMs no Host tipo A.

• Uma VM no Host tipo B foi movida para Host tipo A, mas o desempenho permaneceu o mesmo.

• Falhei em todos os AGs de uma das VMs do Host B, a execução do t-sql ainda era a mesma (muito lenta).

• Com SET STATISTICS TIME, IO ON; Posso ver muitas entradas de ~ 15 ms para CPU durante toda a consulta para a VM no Host tipo B e 0 ms para CPU em quase todos os loops da VM no Host tipo A.

• CPU-z mostra a velocidade do clock da CPU estável, então não parece ser um problema de configuração “verde”.

• Pedi à equipe do servidor para dar uma olhada e eles não encontraram nenhuma diferença na forma como os hosts ou VMs estão configurados.

• A única diferença em termos de sys.configurations é que o Filestream está habilitado nas VMs no host tipo B.

Este problema parece estar vinculado ao SQL Server. O que mais posso fazer para solucionar isso?

Estou experimentando índices clusterizados e não clusterizados no SQL Server e notei algo interessante.

Aqui está uma versão simplificada do meu código T-SQL:

IF OBJECT_ID('dbo.dept') IS NOT NULL DROP TABLE dbo.dept;
CREATE TABLE dept(id INT, name NVARCHAR(20), address NVARCHAR(50));
GO

INSERT INTO dept(id, name, address) VALUES (1, 'Dept 1', 'Sarjapur Road');
INSERT INTO dept(id, name, address) VALUES (2, 'Dept 2', 'Whitefield');
INSERT INTO dept(id, name, address) VALUES (3, 'Dept 3', 'Electronic City');
INSERT INTO dept(id, name, address) VALUES (4, 'Dept 4', 'Koramangala');
GO

CREATE CLUSTERED INDEX cl ON dbo.dept(id);
CREATE INDEX ncl ON dbo.dept(address);
GO

SELECT *, %%lockres%% lock, %%physloc%% physloc, sys.fn_PhysLocFormatter(%%physloc%%) formatted
FROM dbo.dept WITH (NOLOCK, INDEX (cl))

SELECT *, %%lockres%% lock, %%physloc%% physloc, sys.fn_PhysLocFormatter(%%physloc%%) formatted
FROM dbo.dept WITH (NOLOCK, INDEX (ncl))

E aqui está o resultado:

+----+--------+-----------------+----------------+--------------------+------------+
| id | name   | address         | lock           | physloc            | formatted  |
+----+--------+-----------------+----------------+--------------------+------------+
|  1 | Dept 1 | Sarjapur Road   | (de42f79bc795) | 0xB01F000004000000 | (4:8112:0) |
|  2 | Dept 2 | Whitefield      | (9d6bf8154a2a) | 0xB01F000004000100 | (4:8112:1) |
|  3 | Dept 3 | Electronic City | (052c8c7d9727) | 0xB01F000004000200 | (4:8112:2) |
|  4 | Dept 4 | Koramangala     | (1a39e6095155) | 0xB01F000004000300 | (4:8112:3) |
+----+--------+-----------------+----------------+--------------------+------------+

+----+--------+-----------------+----------------+--------------------+-----------+
| id | name   | address         | lock           | physloc            | formatted |
+----+--------+-----------------+----------------+--------------------+-----------+
|  3 | Dept 3 | Electronic City | (b64f1cd4ff4f) | 0x1800000003000000 | (3:24:0)  |
|  4 | Dept 4 | Koramangala     | (4471456166ef) | 0x1800000003000100 | (3:24:1)  |
|  1 | Dept 1 | Sarjapur Road   | (7948805432b9) | 0x1800000003000200 | (3:24:2)  |
|  2 | Dept 2 | Whitefield      | (584262fe5906) | 0x1800000003000300 | (3:24:3)  |
+----+--------+-----------------+----------------+--------------------+-----------+

Como você pode ver, o lock e o physloc para os dois conjuntos de resultados são muito diferentes. No passado, sempre acreditei que essas pseudocolunas revelavam informações sobre a dbo.depttabela (o índice clusterizado ou o heap), já que estou selecionando a partir dela. Mas estes testes parecem provar que mostram informações sobre como os dados são acessados. Meu entendimento está correto?

Ao tentar classificar alguns valores hexadecimais, obtive resultados diferentes para agregação MAX() e classificação ORDER BY desc:

with some_data as
(
    select '123A55' as hex
    from dual
    union all
    select '123255' as hex
    from dual
)

select max(hex)
from some_data
;

Result: 123A55

with some_data as
(
    select '123A55' as hex
    from dual
    union all
    select '123255' as hex
    from dual
)

select *
from some_data
order by hex desc
;

Result:
123255
123A55

No banco de dados MySQL dá 123A55 em ambos os casos.

Existem regras diferentes no ORACLE para ordem de classificação para MAX() MIN() e ORDER BY?

Em https://www.timescale.com/blog/best-practices-for-time-series-metadata-tables/ há uma declaração de função que procura sobreposições de intervalo de tempo com:

SELECT NOT isempty(
        tstzrange(rangeStart, rangeEnd) *
        tstzrange(series.ts_start, series.ts_end, '[]')
    );

Quando procuro tstzrange nos documentos do PostgreSQL, encontro apenas uma menção a ele como um tipo de dados e nenhuma como uma função.

O que esse []argumento está fazendo e está documentado em algum lugar?