All perguntas(dba)

Tenho uma consulta propensa à sensibilidade de parâmetros e que sofre com seu parâmetro com valor de tabela. Sou preguiçoso e só quero resolver isso com dicas de consulta. Quando estou preguiçoso, consigo resolver a sensibilidade de parâmetros com OPTION (OPTIMIZE FOR UNKNOWN). Isso me gera três perguntas muito relacionadas:

1. Tem algum impacto em variáveisOPTION (OPTIMIZE FOR UNKNOWN) ​​com valor de tabela ?
2. Tem algum impacto nos parâmetrosOPTION (OPTIMIZE FOR UNKNOWN) com valor de tabela ?
3. Quais outras dicas de consulta podem ser usadas para influenciar estimativas de cardinalidade para parâmetrosOPTION(RECOMPILE) com valores de tabela ?

Tanto meus próprios experimentos quanto a documentação sugerem que essa é uma causa perdida. Parâmetros com valor de tabela estão sujeitos à detecção de parâmetros, mas tudo o que é detectado é a cardinalidade, então OPTION (OPTIMIZE FOR UNKNOWN)não deve fazer nada.

Quanto à questão de usar outras dicas de tabela, sei que posso alterar a estimativa para operações no parâmetro com valor de tabela (por exemplo, OPTION (USE HINT ('ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES')), mas não acho que as dicas possam influenciar a estimativa de cardinalidade para o parâmetro em si.

Para um exemplo de tabela rowstore...

CREATE TABLE T(Id INT PRIMARY KEY, C1 INT NULL, C2 INT NULL);

Existem vários métodos diferentes para recuperar contagens de linhas de tabela de metadados no SQL Server - como o abaixo

SELECT SUM(rows) 
FROM sys.partitions
WHERE object_id = object_id('dbo.T') AND index_id <= 1;

SELECT SUM(row_count) 
FROM sys.dm_db_partition_stats
WHERE object_id = object_id('dbo.T') AND index_id <= 1;

SELECT SUM(rows)
FROM sys.sysindexes
WHERE id = object_id('dbo.T') AND indid <= 1;

SELECT OBJECTPROPERTYEX(object_id('dbo.T'), 'Cardinality') 

Os planos de execução aparentemente mostram uma variedade de objetos diferentes sendo usados ​​- como o abaixo.

• sysrowsets OUTER APPLY OpenRowset(TABLE ALUCOUNT
• sysidxstats CROSS APPLY OpenRowSet(TABELA PARTITIONCOUNTS
• sysidxstats i CROSS APPLY OpenRowSet(TABLE INDEXPROP

O que está acontecendo aqui? O SQL Server realmente mantém esses metadados em vários lugares? Se sim, qual é o método mais confiável?

Se eu definir random_page_cost = 1.1no meu postgresql.conf, ele não será definido, nem após a reinicialização, nem após select pg_reload_conf();...
No entanto, ele será definido se eu o inserir no arquivo de configuração antes de criar um novo cluster.

Se eu atualizá-lo via ALTER SYSTEM SET random_page_cost = 1.1; select pg_reload_conf();, ele será definido corretamente.

Alguém pode me orientar sobre como descobrir POR QUÊ?

(Eu já comecei com -d 5, esperando encontrar algo interessante nos logs de inicialização, por que o valor está sendo ignorado, mas não encontrei nada.

Desde já, obrigado.

Atenciosamente,
Stefan

Seguindo as etapas em Failover manual do SQL Server DAG

Para verificar se ambos os Grupos de Disponibilidade estão prontos para failover, use a consulta T-SQL abaixo, executada no Modo SQLCMD:

:CONNECT TDPRD071  
SELECT ag.name, drs.database_id, db_name(drs.database_id) as database_name,  
       drs.group_id, drs.replica_id, drs.last_hardened_lsn  
FROM sys.dm_hadr_database_replica_states drs  
INNER JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;

:CONNECT TDDR071  
SELECT ag.name, drs.database_id, db_name(drs.database_id) as database_name,  
       drs.group_id, drs.replica_id, drs.last_hardened_lsn  
FROM sys.dm_hadr_database_replica_states drs  
INNER JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;

A captura de tela dos resultados da execução das consultas acima no primário global, conforme mostrado no artigo, mostra a conexão com cada AG no DAG.

No entanto, quando executo as consultas no primário global do meu DAG, os resultados que obtenho são apenas da conexão com o encaminhador. Portanto, os dois conjuntos de resultados exibidos são apenas da conexão com o AG02.

Entretanto, se eu executar as duas consultas individualmente (ambas do primário global), elas se conectarão corretamente ao AG01 ou AG02, conforme o caso.

Alguma sugestão sobre o motivo de eu estar tendo esse comportamento?

obrigado.

Atualmente, temos um único servidor MySQL 8 rodando em Oracle Linux. Ele roda em uma VM em um data center gerenciado no Texas.

Cerca de 95% do seu tempo é gasto em operações SELECT e cerca de 5% em INSERT e UPDATE.

Estamos trabalhando para adicionar outro servidor MySQL em um local separado (MO), principalmente para fins de redundância e recuperação de desastres.

Minha ideia é criar um túnel entre os dois locais e configurar a replicação do MySQL usando o local principal como mestre. Dessa forma, se ocorrer um desastre, eu poderia alternar as coisas para apontar para o servidor escravo. Uma desvantagem é que esse servidor escravo dedicado ficará parado, potencialmente sem trazer nenhum benefício, a menos que algo ruim aconteça.

Eu estava pensando em maneiras de utilizá-lo e talvez atualizar meu aplicativo para usar o servidor escravo para algumas das consultas/relatórios pesados.

Achei que era um ótimo plano até começar a ler sobre clustering MySQL. Na verdade, não temos condições de ter um terceiro servidor MySQL dedicado para configurar um cluster.

Minhas perguntas são:

Supondo que você tivesse 2 nós MySQL, em 2 locais, como você os utilizaria melhor?

Nossos servidores de aplicação executam tudo em contêineres Docker. Seria uma ideia maluca adicionar uma instância do MySQL (em um contêiner Docker) aos servidores de aplicação para construir um cluster MySQL em vez da replicação?

Se um cluster fosse realmente uma possibilidade (por meio de instâncias MySQL nos servidores de aplicação), meu entendimento é que as gravações podem ser potencialmente mais lentas, já que a gravação não é concluída até que todos os nós do cluster tenham escrito. Isso significa que ter os nós do cluster em vários locais pode realmente tornar as gravações significativamente mais lentas, já que haverá um pouco de latência entre os dois sites?

Qualquer conselho aqui é bem-vindo.

Talvez eu precise alterar as configurações de localidade de lc_messages, lc_monetary, lc_numeric e lc_time na minha configuração do PostgreSQL. No entanto, preciso saber o que elas afetam especificamente antes de fazer isso. A documentação do PostgreSQL fornece uma lista do que é afetado, mas ainda deixa muitas perguntas em aberto. Por exemplo, ela diz que as funções uppere lowersão afetadas. Isso se aplica a todas as configurações? Ou apenas a algumas delas? Ela também diz que to_char() é afetado. Como, exatamente?

Quero saber com antecedência se essa mudança exigirá alteração no código do aplicativo. Existe algum bom recurso para me ajudar a gerar uma lista de recursos/cenários para testar?

Na edição comunitária do servidor MySQL 8, aqui estão exemplos de uma consulta e comando SQL em :MySQL Shell

SELECT * FROM planet;
DESC planet;
SHOW DATABASES;
SHOW tables;

Como você pode ver, é obrigatório declarar o ;caractere (ou ambos \g, \Gconforme o caso) no final da frase.

Mas percebi por engano que é possível executar o usecomando para alterar o banco de dados sem ; .

Portanto, os dois comandos a seguir funcionam em paz:

use <datababase>
use <datababase>;

Só por curiosidade:

Pergunta

• usePor que o comando não precisa ;ser executado?

Para ser honesto, não tenho certeza se esse é o comando exclusivo dessa situação, mas por que ele é diferente dos outros?

Não consigo encontrar detalhes sobre como SNAPSHOT ISOLATIONfunciona. Testei a seguinte consulta no SQL Server 2019 (com o ADR desabilitado):

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRAN;
WAITFOR DELAY '00:00:20'; -- insert of one record to dbo.MARA_CT in different session
SELECT
    *
FROM dbo.MARA_CT AS mc;
WAITFOR DELAY '00:00:20'; -- insert of one record to dbo.Album in different session
SELECT
    *
FROM dbo.Album AS a;
WAITFOR DELAY '00:00:20';
SELECT
    *
FROM dbo.MARA_CT AS mc;
SELECT
    *
FROM dbo.Album AS a;
COMMIT;

Conforme observado no comentário, inseri uma linha em dbo.MARA_CTe, durante a segunda WAITFOR DELAY, inseri um registro em dbo.Album. De acordo com a documentação da Microsoft:

The term "snapshot" reflects the fact that all queries in the transaction see the same version, or snapshot, of the database, based on the state of the database at the moment in time when the transaction begins.

Os resultados que obtive da minha consulta são os seguintes:

1. dbo.MARA_CT contém o registro inserido durante o primeiro WAITFOR DELAY '00:00:20'.
2. dbo.Album não contém o registro inserido durante o segundo WAITFOR DELAY '00:00:20'.

Parece-me que o "primeiro contato" com qualquer tabela na consulta cria um "instantâneo" de toda a transação, em vez de capturar o estado do banco de dados no momento em que a transação começa. Em relação a isso SNAPSHOT ISOLATION, tenho perguntas adicionais:

1. O ISOLAMENTO DE SNAPSHOT armazena todas as versões desde o início da transação para todas as linhas do banco de dados ou apenas para as tabelas usadas na consulta? Como isso funciona?

2. Se o RCSI estiver habilitado e posteriormente habilitarmos o ISOLAMENTO DE SNAPSHOT, o SQL Server armazenará novos valores/versões no tempdb?

3. O objetivo do uso, SNAPSHOT ISOLATIONno meu caso, é testar novas versões de procedimentos e visualizações (novo esquema). Tanto os procedimentos novos quanto os antigos precisam retornar o mesmo número de registros e utilizar os mesmos dados, mesmo que as tabelas envolvidas passem por constantes inserções, atualizações e exclusões. Considerei usar um snapshot do banco de dados, mas agora vejo que SNAPSHOT ISOLATIONpode ser ainda mais vantajoso, já que o RCSI já está habilitado nos bancos de dados.

Na comunidade do servidor MySQL 8 para exportar a saída de uma consulta SQL é possível executar o MySQL Shellseguinte comando (o mais básico):

SELECT * FROM cientifico INTO OUTFILE '/var/lib/mysql-files/cientifico-data.txt';

E funciona como esperado

Mas para uma consulta não SQL como a seguir:

SHOW PROCESSLIST INTO OUTFILE '/var/lib/mysql-files/processlist.txt';

Lança o seguinte erro

ERRO 1064 (42000): Há um erro na sintaxe SQL; verifique o manual correspondente à versão do seu servidor MySQL para obter a sintaxe correta a ser usada perto de 'INTO OUTFILE '/var/lib/mysql-files/processlist.txt'' na linha 1

O mesmo que:

SHOW DATABASES INTO OUTFILE '/var/lib/mysql-files/databases.txt';

Dando

ERRO 1064 (42000): Há um erro na sintaxe SQL; verifique o manual correspondente à versão do seu servidor MySQL para obter a sintaxe correta a ser usada perto de 'INTO OUTFILE '/var/lib/mysql-files/databases.txt'' na linha 1

Portanto se for possível

Pergunta

• Como exportar a saída de uma frase de consulta não SQL?

Estou assumindo que a INTO OUTFILEsintaxe é apenas para sentenças SQL, mas e para sentenças não SQL?

Pelo que consegui encontrar na web, e neste site também, tentei todos os seguintes procedimentos (1 a 5) para recuperar a última data em que o SQL Server foi iniciado:

SELECT 0 as Id, SYSDATETIME() as DT
union
SELECT 1, sqlserver_start_time FROM sys.dm_os_sys_info  
union
SELECT 2, login_time FROM sys.dm_exec_sessions WHERE session_id = 1
union
SELECT 3, start_time from sys.traces where is_default = 1
union
SELECT 4, crdate FROM sysdatabases WHERE name='tempdb'
union
SELECT 5, create_date FROM sys.databases WHERE name = 'tempdb'

O resultado é:

0   2025-04-17 23:38:26.9364166
1   2025-04-13 19:09:42.2000000
2   2025-04-13 19:09:44.3166667
3   2025-04-13 19:09:46.5600000
4   2025-04-13 19:09:51.0900000
5   2025-04-13 19:09:51.0900000

O problema: iniciei a máquina (e o SQL Server com ela) há apenas uma hora. Eu esperava algo como 2025-04-17 22:38... e não 2025-04-13 19:09.

Este servidor SQL está instalado em uma caixa VMware.

Em outro SQL Server, mesma edição e versão, tenho resultados corretos:

Id  DT
0   2025-04-18 14:34:49.3442637
1   2025-04-18 14:34:03.4333333
2   2025-04-18 14:34:05.1233333
3   2025-04-18 14:34:09.7400000
4   2025-04-18 14:34:14.6100000
5   2025-04-18 14:34:14.6100000

Não consigo entender por que tenho resultados errados na máquina virtual. Eu inicio e desligo a máquina host e a VM convidada sempre que trabalho.

Estou esquecendo de alguma coisa aqui?

• SQL Server Dev Edition 2019