All perguntas(dba)

Estou no Ubuntu 24.04.2 LTS (noble) e quero iniciar uma segunda instância de um servidor MariaDB na mesma máquina. Pensei em usar mariadb-multipara isso.

Nossa primeira instância de banco de dados funciona perfeitamente, acredito que tudo o que é necessário está instalado.
apt list --installed | grep mariadbretorna:

libmariadb3/noble-updates,noble-security,now 1:10.11.8-0ubuntu0.24.04.1 amd64 [installed,automatic]
mariadb-client-core/noble-updates,noble-security,now 1:10.11.8-0ubuntu0.24.04.1 amd64 [installed,automatic]
mariadb-client/noble-updates,noble-security,now 1:10.11.8-0ubuntu0.24.04.1 amd64 [installed,automatic]
mariadb-common/noble-updates,noble-security,now 1:10.11.8-0ubuntu0.24.04.1 all [installed,automatic]
mariadb-plugin-provider-bzip2/noble-updates,noble-security,now 1:10.11.8-0ubuntu0.24.04.1 amd64 [installed,automatic]
mariadb-plugin-provider-lz4/noble-updates,noble-security,now 1:10.11.8-0ubuntu0.24.04.1 amd64 [installed,automatic]
mariadb-plugin-provider-lzma/noble-updates,noble-security,now 1:10.11.8-0ubuntu0.24.04.1 amd64 [installed,automatic]
mariadb-plugin-provider-lzo/noble-updates,noble-security,now 1:10.11.8-0ubuntu0.24.04.1 amd64 [installed,automatic]
mariadb-plugin-provider-snappy/noble-updates,noble-security,now 1:10.11.8-0ubuntu0.24.04.1 amd64 [installed,automatic]
mariadb-server-core/noble-updates,noble-security,now 1:10.11.8-0ubuntu0.24.04.1 amd64 [installed,automatic]
mariadb-server/noble-updates,noble-security,now 1:10.11.8-0ubuntu0.24.04.1 amd64 [installed]

Porém, ao tentar executar mariadb-multi start 2(configurei a instância correspondente no arquivo conf), recebo o seguinte erro:

Command 'mariadb-multi' not found, did you mean:
  command 'mariadbd-multi' from deb mariadb-server (1:10.11.8-0ubuntu0.24.04.1)
Try: apt install <deb name>

Estamos esquecendo de algo que não entendo?

Sou bastante inexperiente com MariaDB, especialmente com replicação. No entanto, como estou de plantão, tenho um problema com isso hoje.

Parece que minha réplica está ficando para trás enquanto estou tirando uma mysqldumpcópia dela. Isso é um comportamento esperado ou há um problema com meu comando de backup abaixo?

mysqldump --defaults-file=$MYCNF -A --events --routines --master-data=2 | gzip -9 -c > ${BKPFILE}

Parece que estamos recuperando o atraso depois que o despejo terminar.

Tenho muitas consultas que retornam alguns dados estatísticos sobre um assunto em várias tabelas. O resultado inclui uma "classificação" que é uma de {"C","P","M"}. Quero que a consulta retorne as linhas na ordem {"M","P","C"}, ou seja, não é alfabética nem nenhuma ordenação interna.

Os dados são irrelevantes, mas digamos que eu queira consultar algo como a taxa de strike de um jóquei por essas classificações e ordenar o resultado por esses códigos nessa ordem. Espero que faça sentido?

Então, há uma maneira de criar um Collation Postgresql que pode me ajudar ou há outra maneira? Note que há muitas consultas, então uma cláusula CASE complexa não é minha solução preferida, pois eu teria que colocá-la em cada consulta (em cada programa que pode até conter sua própria consulta como um literal.

Tenho uma tabela particionada com uma chave primária rowstore e um índice columnstore não clusterizado. A chave principal de ambos (não que a ordem das chaves importe para o columnstore) é a mesma. Ao atualizar estatísticas, o SQL Server opta regularmente por varrer o índice columnstore. Isso demora muito para o meu gosto, então tentei

UPDATE STATISTICS My_Table
WITH PERSIST_SAMPLE_PERCENT = ON, SAMPLE 3 PERCENT

Para minha surpresa, as atualizações de estatísticas ainda demoravam muito. Os planos de execução sugerem que o índice do columnstore está sendo escaneado da mesma forma que antes.

Então, tenho uma pergunta: ao ler um índice columnstore, PERSIST_SAMPLE_PERCENT é ignorado em UPDATE STATISTICS? As atualizações automáticas de estatísticas parecem compartilhar esse problema.

Atualização: Suspeito que o problema pode ser o bitmap excluído.

Tenho um cluster do SQL Server 2022 Enterprise Edition com vários AGs.

Dois dos AGs consideram diferentes instâncias primárias. Ambos consideram suas secundárias legíveis e estão corretos em pensar assim.

Além de estar nessa configuração secundária legível, nada torna nenhum dos bancos de dados em nenhuma das instâncias somente leitura. Eles não são Grupos de Disponibilidade Básica.

Aqui está o choque: quando executo DBCC CHECKCATALOGa segmentação de um banco de dados secundário legível enquanto estou conectado a uma instância que não é o primário desse banco de dados, a consulta falha assim

Msg 3906, Nível 16, Estado 8, Linha 1

Falha ao atualizar o banco de dados "DB NAME" porque o banco de dados é somente leitura.

mas DBCC CHECKDBfunciona muito bem!

Procurei muito, mas não encontrei nada útil sobre isso.

• Este problema no GitHub da Solução de Manutenção de Ola Hallengren é idêntico, mas não tem solução. Ola, em quem confio ser um especialista nisso, parece pensar que é um bug dele e não da Microsoft.
• Este commit do git sugere que seu autor, dan-andreistefan, já viu isso antes. Não encontrei nenhum problema ou PR correspondente. Dan surgiu do vazio e resolveu o problema .
• Além das limitações em BAGs, não consigo encontrar nada na documentação oficial do SQL Server sobre fazer verificações de integridade em AGs. Está apenas no guia de licenciamento.

Como posso depurar isso? Por que DBCC CHECKDB, que é um superconjunto de DBCC CHECKCATALOG, funcionaria onde DBCC CHECKCATALOGfalha?

Tenho uma consulta muito simples em que uso um UNION ALL+ ORDER BYem duas consultas que retornam dados pré-ordenados de seus respectivos índices. Por algum motivo, o SQL não usa um Merge Join (Concatenation)para isso, mas um Concatenation, seguido por um Sort. Qual poderia ser o motivo?

Aqui está um exemplo completo de reprodução. (As INDEXdicas são necessárias para que o SQL Server use o índice, apesar do baixo número de linhas na tabela.)

CREATE TABLE T1(
    SequenceNumber bigint IDENTITY NOT NULL,
    TenantId uniqueidentifier NOT NULL,
    Object1Id uniqueidentifier NOT NULL,
    Payload nvarchar(max) NOT NULL,
    OtherNumber bigint NOT NULL,

  CONSTRAINT PK_T1 PRIMARY KEY CLUSTERED (TenantId,SequenceNumber ASC)
)

CREATE INDEX IX_TenantId_Object1Id_OtherNumber ON T1(TenantId, Object1Id, OtherNumber)

CREATE TABLE T2(
    SequenceNumber bigint IDENTITY NOT NULL,
    TenantId uniqueidentifier NOT NULL,
    Object2Id uniqueidentifier NOT NULL,
    Payload nvarchar(max) NOT NULL,
    OtherNumber bigint NOT NULL,

  CONSTRAINT PK_T2 PRIMARY KEY CLUSTERED (TenantId,SequenceNumber ASC)
)

CREATE INDEX IX_TenantId_Object2Id_OtherNumber ON T2(TenantId, Object2Id, OtherNumber)

DECLARE @tenantId UNIQUEIDENTIFIER = NEWID()
DECLARE @object1Id UNIQUEIDENTIFIER = NEWID()
DECLARE @object2Id UNIQUEIDENTIFIER = NEWID()

SELECT OtherNumber, Payload FROM T1 WITH (INDEX(IX_TenantId_Object1Id_OtherNumber)) WHERE TenantId = @tenantId AND Object1Id = @object1Id
UNION ALL
SELECT OtherNumber, Payload FROM T2 WITH (INDEX(IX_TenantId_Object2Id_OtherNumber)) WHERE TenantId = @tenantId AND Object2Id = @object2Id
ORDER BY OtherNumber

DROP TABLE T1
DROP TABLE T2

E esta é uma captura de tela do plano de execução:

Quando adiciono a MERGE UNIONopção, o SQL Server pré-classifica explicitamente os resultados individuais da consulta (em OtherNumbere Payload, por algum motivo).

Agora, uma reviravolta interessante: quando adiciono uma restrição UNIQUE às OtherNumbercolunas, o SQL Server repentinamente escolhe o Merge Join (Concatenation)operador. Por quê?

Testei isso localmente no SQL Server 2016 e no Azure SQL.

Eu encontrei o que parece ser uma perda de precisão inesperada ao converter de float4diretamente para numericno PostgreSQL:

select 1079414::float4,
       (1079414::float4)::numeric(15,2) as float4_to_numeric, -- loses precision
       ((1079414::float4)::float8)::numeric(15,2) as float4_to_float8_to_numeric;

Isso produz:

   float4   | float4_to_numeric | float4_to_float8_to_numeric
------------+-------------------+----------------------------
  1,079,414 |          1,079,410 |                  1,079,414

A conversão direta de float4para numericinesperadamente produz 1,079,410em vez do esperado 1,079,414.

A documentação do PostgreSQL afirma : "Em todas as plataformas suportadas atualmente, o realtipo tem um intervalo de aproximadamente 1E-37 a 1E+37 com uma precisão de pelo menos 6 dígitos decimais." E percebo que são 7 dígitos decimais.

No entanto, a Wikipedia observa : "Qualquer número inteiro com valor absoluto menor que 2^24 pode ser representado exatamente no formato de precisão simples"

Como 1.079.414 é muito menor que 2^24 (16.777.216), eu esperaria que ele fosse representado exatamente.

Curiosamente, converter float8primeiro para e depois para numericpreserva o valor total, sugerindo que o PostgreSQL está armazenando a precisão total, mas de alguma forma a perde durante a conversão direta para numeric.

Esse comportamento é um bug ou há alguma razão subjacente para esse comportamento? O que está acontecendo durante a conversão de tipo que causa essa perda de precisão?

Vejo que já existe uma pergunta semelhante , mas esse exemplo usa decimais, enquanto este é sobre um número inteiro menor que 2^24.

Ao exportar meu banco de dados do MySQL versão 8, vejo esta linha, o que está me deixando intrigado.

É para uma coluna/campo virtual

 `Rego` varchar(12) GENERATED ALWAYS AS (concat(`Call_Sign`,_utf8mb4' ',`Vehicle`)) VIRTUAL,

Especificamente o que é esse artefato Call_Sign,_utf8mb4' dentro do concat?

A variável @SQL na declaração abaixo é sempre truncada quando eu "inline" uma variável. Se eu enviar a variável e imprimir, ela não trunca para 4000, no entanto, não consigo vincular a variável enviada em uma declaração USE [@DatabaseName]. Como contornar.

Isso funciona, no entanto, o nome do banco de dados é codificado na instrução USE

DECLARE @DatabaseName NVARCHAR(MAX) = 'MyDatabase'
DECLARE @Sql NVARCHAR(MAX)=
'
USE [MyDatabase]
PRINT @DatabaseName
SELECT
...<20,000 more chars
'

DECLARE @params NVARCHAR(MAX) ='@DatabaseName NVARCHAR(MAX)'
EXEC sp_executesql @SQL, @params,@DatabaseName

Isso gera uma exceção com a mensagem ' O banco de dados '@DatabaseName' não existe. Certifique-se de que o nome foi inserido corretamente .'

DECLARE @DatabaseName NVARCHAR(MAX) = 'MyDatabase'
DECLARE @Sql NVARCHAR(MAX)=
'
USE [@DatabaseName]
PRINT @DatabaseName
SELECT
...<20,000 more chars
'

DECLARE @params NVARCHAR(MAX) ='@DatabaseName NVARCHAR(MAX)'
EXEC sp_executesql @SQL, @params,@DatabaseName

Isso trunca a consulta para NVARCHAR(4000)

DECLARE @DatabaseName NVARCHAR(MAX) = 'MyDatabase'
DECLARE @Sql NVARCHAR(MAX)=
'
USE ['+@DatabaseName+']
PRINT @DatabaseName
SELECT
...<20,000 more chars
'

DECLARE @params NVARCHAR(MAX) ='@DatabaseName NVARCHAR(MAX)'
EXEC sp_executesql @SQL, @params,@DatabaseName

Também tentei usar N'string' sem sucesso

DECLARE @DatabaseName NVARCHAR(MAX) = N'MyDatabase'
DECLARE @Sql NVARCHAR(MAX)=
N'
USE ['+@DatabaseName+']
PRINT @DatabaseName
SELECT
...<20,000 more chars
'

DECLARE @params NVARCHAR(MAX) =N'@DatabaseName NVARCHAR(MAX)'
EXEC sp_executesql @SQL, @params,@DatabaseName

Acho que entendo por que isso USE [@Variable]não funciona, enquanto não sei como explicar por que USE ['+@Variable+']está sendo truncado para 4000 quando ambas as variáveis ​​estão no máximo, a menos que o SQL Server esteja fazendo a conversão para baixo sp_executesql.

De qualquer forma, alguém sabe de uma solução alternativa para fazer isso funcionar? Eu basicamente quero direcionar dinamicamente qualquer banco de dados com uma instrução sql maior que 4000 nchars.

Tenho a seguinte tabela:

CREATE TABLE transactions
(
    id                                    NUMERIC(20, 0)                           NOT NULL DEFAULT NEXTVAL('transactions_sequence') PRIMARY KEY,
    transaction_date                      TIMESTAMP      DEFAULT NULL              NULL,
    transaction_type                      VARCHAR(255)   DEFAULT NULL              NULL,
    merchant_id                           VARCHAR(255)   DEFAULT NULL              NULL,
    transaction_type                      VARCHAR(255)   DEFAULT NULL              NULL,
    -- Some more columns here
);

e o seguinte índice:

CREATE INDEX transactions_merchant_id_idx ON transactions (merchant_id, transaction_type, transaction_date DESC, id) WHERE merchant_id IS NOT NULL;

Tenho as seguintes dúvidas:

SELECT id, transaction_date
FROM transactions
WHERE merchant_id = 'some_merchant_id'
  AND transaction_type = 'a'
  AND transaction_date >= '2025-01-01'
  AND transaction_date < '2025-03-28'
ORDER BY transaction_date DESC
LIMIT 100

Essa consulta funciona perfeitamente e eu obtenho apenas uma varredura de índice:

Limit  (cost=0.29..7.47 rows=1 width=13) (actual time=1.119..1.120 rows=0 loops=1)
  ->  Index Scan using transactions_transaction_type_idx on transactions  (cost=0.29..7.47 rows=1 width=13) (actual time=1.118..1.118 rows=0 loops=1)
        Index Cond: (((transaction_type)::text = 'a'::text) AND (transaction_date >= '2025-01-01 00:00:00'::timestamp without time zone) AND (transaction_date < '2025-03-28 00:00:00'::timestamp without time zone))
        Filter: ((merchant_id)::text = 'some_merchant_id'::text)
Planning Time: 0.311 ms
Execution Time: 1.139 ms

No entanto, quando preciso de transaction_typeresultados independentes com:

SELECT id, transaction_date
FROM transactions
WHERE merchant_id = 'some_merchant_id'
  AND transaction_date >= '2025-01-01'
  AND transaction_date < '2025-03-28'
ORDER BY transaction_date DESC
LIMIT 100

Ainda recebo apenas a varredura de índice:

Limit  (cost=38.08..38.19 rows=44 width=13) (actual time=0.108..0.115 rows=47 loops=1)
  ->  Sort  (cost=38.08..38.19 rows=44 width=13) (actual time=0.107..0.110 rows=47 loops=1)
        Sort Key: transaction_date DESC
        Sort Method: quicksort  Memory: 27kB
        ->  Index Only Scan using transactions_merchant_id_idx on transactions  (cost=0.29..36.88 rows=44 width=13) (actual time=0.029..0.093 rows=47 loops=1)
              Index Cond: ((merchant_id = 'some_merchant_id'::text) AND (transaction_date >= '2025-01-01 00:00:00'::timestamp without time zone) AND (transaction_date < '2025-03-28 00:00:00'::timestamp without time zone))
              Heap Fetches: 0
Planning Time: 0.228 ms
Execution Time: 0.161 ms

Eu tenho uma lista de todos os valores potenciais de transaction_type, então inicialmente pensei que isso seria melhor:

SELECT id, transaction_date
FROM transactions
WHERE merchant_id = 'some_merchant_id'
  AND transaction_type IN ('a', 'b', 'c', ...) -- all the potential values here
  AND transaction_date >= '2025-01-01'
  AND transaction_date < '2025-03-28'
ORDER BY transaction_date DESC
LIMIT 100

mas em vez disso, dependendo do número de valores na INcláusula, posso obter um adicional filterno plano de consulta:

Limit  (cost=38.29..38.40 rows=43 width=13) (actual time=0.110..0.118 rows=47 loops=1)
  ->  Sort  (cost=38.29..38.40 rows=43 width=13) (actual time=0.109..0.112 rows=47 loops=1)
        Sort Key: transaction_date DESC
        Sort Method: quicksort  Memory: 27kB
        ->  Index Only Scan using transactions_merchant_id_idx on transactions  (cost=0.31..37.13 rows=43 width=13) (actual time=0.030..0.097 rows=47 loops=1)
              Index Cond: ((merchant_id = 'some_merchant_id'::text) AND (transaction_date >= '2025-01-01 00:00:00'::timestamp without time zone) AND (transaction_date < '2025-03-28 00:00:00'::timestamp without time zone))
"              Filter: ((transaction_type)::text = ANY ('{a,b,c,d,e,f}'::text[]))"
              Heap Fetches: 0
Planning Time: 0.340 ms
Execution Time: 0.142 ms

Então, mesmo se eu pular a transaction_typecoluna do meio, meu índice é usado. Mas com qual consulta eu sou melhor, com IN on transaction_typecom todos os valores potenciais ou sem nem mesmo o filtro? Como meu índice ainda é usado sem o filtro on transaction_type?