Nos documentos diz que podemos compartilhar varreduras de índice (varredura avançada). Agora, aqui eles usaram estatísticas e estatísticas de espera e eu não encontrei uma sessão de eventos estendida que pudesse identificá-la diretamente.
A questão é: como posso saber que uma varredura avançada foi usada? Eu sei sobre a propriedade falsa ordenada, mas isso apenas diz que ela não usou a ordem na chave de índice?
Tentei criar um procedimento para ajustar uma sequência de acordo com o valor máximo em uma coluna. Para obter o valor máximo da coluna e armazená-lo em uma variável, acabei usando um cursor "fictício". Imagino que haja uma maneira mais simples, mas não consegui fazer nenhuma delas funcionar. Alguma sugestão sobre como me livrar do cursor e ainda conseguir usar o valor máximo na instrução alter?
--#SET TERMINATOR @
CREATE OR REPLACE PROCEDURE Adjust_Sequence(
IN p_table_schema VARCHAR(128),
IN p_table_name VARCHAR(128),
IN p_column_name VARCHAR(128),
IN p_sequence_name VARCHAR(128)
)
LANGUAGE SQL
BEGIN
DECLARE v_max_value BIGINT DEFAULT 1;
DECLARE v_sql_stmt VARCHAR(1000);
DECLARE cur CURSOR FOR S;
-- Construct SQL to get the max value of the specified column
SET v_sql_stmt = 'SELECT COALESCE(MAX(' || p_column_name || '), 0) + 1 FROM ' || p_table_schema || '.' || p_table_name;
-- Prepare and execute the statement properly
PREPARE S FROM v_sql_stmt;
OPEN cur;
FETCH cur INTO v_max_value;
CLOSE cur;
-- Construct SQL to alter the sequence to restart with the new max value
SET v_sql_stmt = 'ALTER SEQUENCE ' || p_sequence_name || ' RESTART WITH ' || v_max_value;
-- Execute the sequence alteration
EXECUTE IMMEDIATE v_sql_stmt;
END @
--#SET TERMINATOR ;
O PostgreSQL é any_valuerealmente arbitrário ao usar ORDER BY?
A documentação afirma:
any_value ( anyelement ) → igual ao tipo de entrada
Retorna um valor arbitrário dos valores de entrada não nulos.
Consultas de exemplo:
-- nonsensical
WITH vals (v) AS ( VALUES (1),(3),(4),(3),(2) )
SELECT any_value(v ORDER BY v = 3 DESC) FROM vals;
-- more realistic example
SELECT any_value(username ORDER BY user_id DESC) AS a_username FROM users;
Eu vi que a documentação da versão 17 inclui a seguinte cláusula:
Embora todos os agregados abaixo aceitem uma cláusula ORDER BY opcional (conforme descrito na Seção 4.2.7), a cláusula só foi adicionada aos agregados cuja saída é afetada pela ordenação.
Mas não menciona se a saída de any_value é afetada pela ordenação.
Com base em alguns testes, parece ser determinístico. (provavelmente porque any_valueretorna apenas o primeiro valor não nulo e respeita a ORDER BY)
Como pergunta complementar, se não for arbitrário, seria "ruim" confiar nesse comportamento?
Tenho um BD corrompido, não sei a causa, é um BD de uma aplicação cujo distribuidor nunca teve esse tipo de corrupção.
Então tentei DBCC com REPAIR_ALLOW_DATA_LOSS conforme sugerido em:
Foi detectada uma inconsistência durante uma operação interna no banco de dados
mas não funciona.
O que mais posso tentar? Vi que existem ferramentas que prometem consertar o BD (primeiramente encontradas na pesquisa do Google https://www.stellarinfo.com/gdc/sql/sql-server-database-repair-tool.php ), mas me pergunto se devo delegar a um blackbox o destino do meu BD? Ok, posso fazer um backup, é claro, mas antes de comprar uma ferramenta em desespero, gostaria de pedir mais conselhos. Ou essas ferramentas simplesmente executam o DBCC e, portanto, são inúteis...
Esse é o tipo de erro DBCC CHECKDB('My_DB') WITH NO_INFOMSGS, ALL_ERRORMSGSshowsque me mostra (tenho muitos desses)
Msg 8939, Level 16, State 98, Line 7 Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 3759437827725787136 (type Unknown), page (13558:888026339). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -14.
Tentando reparar a perda de dados com
ALTER DATABASE TW SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
BEGIN TRANSACTION;
DBCC CHECKDB ('My_DB', REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE TW SET MULTI_USER;
COMMIT;
eu tenho:
Msg 8939, Nível 16, Estado 98, Linha 3 Erro de tabela: ID do objeto 0, ID do índice -1, ID da partição 0, ID da unidade de alocação -9222773885349068800 (tipo Desconhecido), página (15657:-1933734559). O teste (IS_OFF (BUF_IOERR, pBUF->bstat)) falhou. Os valores são 2057 e -4. O reparo desse erro requer que outros erros sejam corrigidos primeiro.
O que posso fazer?
Também percebi que ao consultar registros de tabela específicos, vejo que alguns BLOBs estão corrompidos. A exclusão de registros resolve esse tipo de problema?
Obrigado!
Estou tentando configurar um trabalho de agente SQL que só será executado se for uma réplica primária do Azure SQL MI de grupos de failover.
Estou tentando obter a réplica primária usando sys.dm_hadr_database_replica_stateswhere is_primary_replica =1, mas quando executo no SQL MI em uma região diferente, ele também retorna o valor 1.
Estou usando dbo.fn_hadr_group_is_primary(@AGName)=1a função para o ambiente local, então estou procurando algo semelhante para o Azure SQL MI.
Estou executando o MySql5.7 com o registro de consulta lenta habilitado, e o registro inclui mais metadados do que o mencionado nos documentos; estas três linhas são impressas antes de cada consulta:
# Time: 2025-02-18T14:25:16.286041Z
# User@Host: root[root] @ localhost [] Id: 261083
# Query_time: 3.677193 Lock_time: 0.001193 Rows_sent: 1 Rows_examined: 4334365
Os documentos explicam apenas a terceira linha:
cada declaração escrita no log é precedida por uma linha que começa com um caractere # e tem estes campos (com todos os campos em uma única linha):
- Tempo de consulta
- Tempo de bloqueio
- Linhas_enviadas
- Linhas_examinadas
Das outras duas linhas, a maioria dos campos são óbvios; mas alguém sabe o que o campo Id representa? Ele é diferente para a maioria das entradas no meu log lento, mas em alguns casos há vários que têm o mesmo Id.
Tenho essa configuração para MariaDB:
...
slow_query_log = /var/log/mysql/mysql-slow.log
long_query_time = 1
...
Tenho esses valores ao executar SHOW GLOBAL STATUS;a consulta.
...
| Slow_queries | 448152 |
...
Também notei mais de 30 consultas longas na última hora.
Qual é o motivo de não haver nenhum /var/log/mysql/mysql-slow.logarquivo?
-- Create a heap table of numbers from 1 to 100
SELECT TOP (100)
i = IDENTITY(int, 1, 1)
INTO #T
FROM master.dbo.spt_values;
-- Add a clustered primary key
ALTER TABLE #T
ADD PRIMARY KEY CLUSTERED (i);
Exibir 9% das linhas na ordem da chave primária:
SELECT TOP (9e) PERCENT
i
FROM #T
ORDER BY
i ASC;
DROP TABLE #T;
Por que o SQL Server classifica a coluna quando o índice clusterizado fornece exatamente essa ordem?
Se eu aumentar o número de linhas na tabela, obtenho um Eager Spool em vez de uma Sort e o índice é escaneado em ordem:
-- Create a heap table of numbers from 1 to 1,000
SELECT TOP (1000)
i = IDENTITY(int, 1, 1)
INTO #T
FROM master.dbo.spt_values;
-- Add a clustered primary key
ALTER TABLE #T
ADD PRIMARY KEY CLUSTERED (i);
-- 0.9% now
SELECT TOP (9e-1) PERCENT
i
FROM #T
ORDER BY
i ASC;
DROP TABLE #T;
Um banco de dados que eu suporte usa IndexOptimize para manter índices e estatísticas. Estatísticas de atualização automática estão desativadas neste banco de dados, então IndexOptimize é o único responsável por atualizar estatísticas.
Recentemente, notei várias estatísticas vazias em tabelas que têm linhas. A chamada para IndexOptimize está abaixo. Se eu alterar o parâmetro @OnlyModifiedStatistics de 'Y' para 'N', ele atualizará essas estatísticas vazias. No entanto, também fará com que ele atualize todas as estatísticas, o que não é desejado.
Existe uma maneira de fazer com que o IndexOptimze atualize apenas estatísticas modificadas E estatísticas vazias em tabelas com linhas?
EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = NULL,
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 2,
@FragmentationLevel2 = 5,
@MinNumberOfPages = 0,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y',
@StatisticsSample = 100,
@Indexes='ALL_INDEXES',
@LogToTable = 'Y',
@DatabaseOrder='DATABASE_SIZE_DESC',
@TimeLimit=61200,
@WaitAtLowPriorityMaxDuration = 5,
@WaitAtLowPriorityAbortAfterWait = 'SELF'
Tenho o seguinte SQL que gera uma lista bem formatada dos tamanhos de todas as tabelas em um banco de dados:
SELECT
schema_name,
relname,
pg_size_pretty(table_size) AS size
FROM (
SELECT
pg_catalog.pg_namespace.nspname AS schema_name,
relname,
pg_relation_size(pg_catalog.pg_class.oid) AS table_size
FROM pg_catalog.pg_class
JOIN pg_catalog.pg_namespace ON relnamespace = pg_catalog.pg_namespace.oid
) t
WHERE schema_name NOT LIKE 'pg_%'
ORDER BY table_size DESC;
Isso gera dados como os seguintes (alguns nomes e tamanhos foram alterados para ocultar dados, mas você entendeu a ideia):
schema_name | relname | size
---------------------+-----------------------------------------+------------
information_schema | log | 1024 kB
information_schema | collations | 1024 kB
information_schema | routines | 1024 kB
(30 rows)
Gostaria de ter os resultados de count() em cada tabela adicionados como uma quarta coluna aqui, mas não consigo descobrir como fazer isso. Estou usando o PostgreSQL 14, se isso especificamente fizer alguma diferença.