All perguntas(dba)

Se você observar como alterar temporariamente as configurações do SQL Server para executar uma tarefa e, quando terminar, reverter, há uma maneira de salvar as configurações do SQL Server antes de habilitá-las, para que você possa desabilitá-las se necessário.

Aqui está o código (parcialmente copiado):

IF OBJECT_ID('tempdb.dbo.#Settings') IS NOT NULL
    DROP TABLE #Settings;

CREATE TABLE #Settings
(
    Setting VARCHAR(100),
    Val INT
)
INSERT #Settings (Setting, Val)
SELECT 'show advanced options', cast(value_in_use as int) from sys.configurations where name = 'show advanced options'
UNION
SELECT 'xp_cmdshell', cast(value_in_use as int) from sys.configurations where name = 'xp_cmdshell'
UNION
SELECT 'Ad Hoc Distributed Queries', cast(value_in_use as int) from sys.configurations where name = 'Ad Hoc Distributed Queries'

SELECT * FROM #Settings;

Isso funciona bem se você executar um procedimento por vez; no entanto, ele grava no log de erros do SQL Server, como você pode ver abaixo:

Existe uma maneira de evitar gravar alterações de configurações no log de erros?

No AdventureWorks2016 quando executo a seguinte consulta:

USE AdventureWorks2016

BEGIN TRAN;
SELECT 
    Sales.SalesOrderHeader.SalesOrderID
FROM 
    Sales.SalesOrderHeader
JOIN 
    Sales.Customer 
    ON Sales.SalesOrderHeader.CustomerID = Sales.Customer.CustomerID
OPTION (RECOMPILE, QUERYTRACEON 8605, QUERYTRACEON 8606, QUERYTRACEON 8607, QUERYTRACEON 3604);
COMMIT TRAN;
GO

Recebo uma varredura não agrupada no CustomerID ( o plano ), portanto, eliminação da chave estrangeira. Funcionou também com o esquema de compras ( o plano ), mas nesta consulta ( o plano ):

BEGIN TRAN 
SELECT P.ProductModelID
FROM Production.Product P
JOIN Production.ProductModel PM
ON P.ProductModelID = PM.ProductModelID
OPTION (RECOMPILE, QUERYTRACEON 8605, QUERYTRACEON 8606, QUERYTRACEON 8607, QUERYTRACEON 3604);
COMMIT TRAN 

Ou ( o plano ):

BEGIN TRAN 
SELECT P.ProductID
FROM Production.Product P
JOIN Production.ProductModel PM
ON P.ProductModelID = PM.ProductModelID
OPTION (RECOMPILE, QUERYTRACEON 8605, QUERYTRACEON 8606, QUERYTRACEON 8607, QUERYTRACEON 3604);
COMMIT TRAN 

Recebo varreduras com junções no meu editor de diagramas no SSMS 21:

(name)
FK_Product_ProductModel_ProductModelID
description
Foreign key constraint referencing ProductModel.ProductModelID.

Eu o reativei antes de postar a pergunta, ainda tinha o mesmo plano. A chave estrangeira é

• Confiável
• Não desabilitado
• Não permite nulos
• Não é um esquema diferente

A questão é: por que não estou eliminando a chave estrangeira?

Criei um banco de dados onde um dos campos de uma tabela é definido como enum('M', 'B'). A ferramenta que estou usando converte-o para um tipo variante . Gostaria de substituí-lo e tratá-lo como um caractere. Então a questão é, ele é armazenado como um caractere no banco de dados?

Existem dois níveis de dobramento constante, um na árvore de conversão e outro na fase de simplificação?

Se eu executar a seguinte consulta

SELECT 
    P.[ProductID]
FROM 
    Production.Product AS P
WHERE
    P.[ProductID] = 1 + 2 * 3
    OPTION (RECOMPILE, QUERYTRACEON 8605, QUERYTRACEON 8606, QUERYTRACEON 8607, QUERYTRACEON 3604);

Na árvore de conversão, encontro uma constante, então eu chamaria isso de dobramento de constante básica?

como Paul Holmes diz neste exemplo, mas se eu executar esta consulta de Paul White

use AdventureWorks2016
begin tran 
SELECT
    P.[Name]
FROM Production.Product AS P
WHERE
    P.[Name] LIKE 
        SUBSTRING(LEFT(CHAR(ASCII(CHAR(68))), 1) + '%', 1, 2)
OPTION (RECOMPILE, QUERYTRACEON 8605, QUERYTRACEON 8606, QUERYTRACEON 8607, QUERYTRACEON 3604);
commit tran

e

begin tran 
SELECT
    P.[Name]
FROM Production.Product AS P
WHERE
    P.[Name] LIKE 
        'd%'
OPTION (RECOMPILE, QUERYTRACEON 8605, QUERYTRACEON 8606, QUERYTRACEON 8607, QUERYTRACEON 3604);
commit tran 

Não vejo muita diferença entre ambos em termos de árvores de conversão, então a dobra constante aconteceu aqui e suas árvores simplificadas têm os mesmos operadores?

Existem diferentes estágios no dobramento constante? Onde eles estão? O que eu fiz de errado aqui, então não vi na fase de simplificação?

Talvez essa seja uma pergunta muito básica, mas quero ter certeza. Estou atualizando um cluster RDS com uma implantação azul-verde. Eu estava verificando o cluster, seguindo as diretrizes da AWS, e vi um monte de conexões ativas.

psql -d postgres -c “SELECT * FROM pg_stat_activity WHERE (now() - pg_stat_activity.query_start) > interval ‘2 minutes’”mostra cerca de 60 consultas ativas.

Em uma das nossas primeiras etapas de atualização, temos que reiniciar a instância para uma alteração de grupo de parâmetros. Gostaria de saber se isso eliminará todas essas conexões ativas. A maioria delas é idle, e quase todas são SELECTinstruções, não DDL ou INSERT/UPDATEconsultas. Estou preocupado que, se as conexões não forem eliminadas, isso afetará o processo de replicação de alguma forma.

usar pg_upgrade quando você instalou a versão 'antiga' e a versão 'nova' em um sistema é bem direto. Eu tentei encontrar uma maneira de usar pg_upgrade com contêineres docker. Isso é um pouco mais complicado porque você precisa do 'antigo datadir', do 'antigo bindir' e do 'novo datadir' e do 'novo bindir' da versão 'antiga' e da 'nova' do postgres que você quer atualizar e atualizar para. Como os 'diretórios antigos' não estão presentes no contêiner docker da versão 'nova', você tem que montá-los no contêiner 'novo'.

Mas como o pg_upgrade parece esperar não apenas o bindir e o datadir 'antigos', mas também as bibliotecas 'antigas' (das quais o postgres depende) da versão mais antiga, você também precisa montá-las no contêiner da nova versão.

Então acabei executando um 'old-version-container', copiando o bindir, datadir e lib dir para o host docker local e montando-os no 'new-version-container'

ao vir do postgres-12, isso significa copiar o conteúdo de /usr/lib/ para o host docker local e remontá-lo para o 'new-version-container'

então montei o 'old-libdir' em /12-bindir/ e fiz

ldd /12-bindir/postgres para descobrir de quais libs o postgres depende. Depois de copiar o 'old-libs' para /usr/lib no 'new-version-container' todas as dependências puderam ser encontradas e eu consegui usar o pg_upgrade e realmente atualizar um banco de dados de (ou seja, postgres-12-alpine para postgres:15.10-bookworm)

então... funcionou... Então... a verdadeira questão é: porque funciona... devo fazer assim ou estou esquecendo de algo e fazendo algo estúpido ou bobo? Fico feliz com cada dica e opinião

Trabalhando em um script para remover bancos de dados .

Em alguns ambientes, nossos bancos de dados são restaurados regularmente do ativo, a replicação (mesclagem ou transacional) é estabelecida, os processos são executados e testados e, então, os bancos de dados precisam ser descartados, pois todo o desenvolvimento foi implantado no ativo. Agora, outro ciclo começa.

como parte da automação da eliminação do banco de dados até agora, criei este script abaixo:

select
DROP_DB_SCRIPT='use master;' + char(13) 
+ case when source_database_id is not null  -- this is a database snapshot
     then '' 
      else 
        ' alter database ' + name + ' set single_user with rollback immediate ' +              -- put db in single user mode 
        case when (sb.is_published = 1 or sb.is_merge_published = 1) 
             then 'EXEC sp_removedbreplication ' + '''' + name + ''''                           -- remove db from the replication 
             else '' 
        end +char(13) 
  end  +char(13) +
' drop database ' + quotename(name) +char(13) 

,*
from sys.databases sb
where database_id >= 5
and is_distributor= 0

O script acima não fará nada além de produzir um script que eu possa usar para excluir um banco de dados ou conjunto de bancos de dados desejado.

ele leva em consideração a replicação (você precisa remover a replicação separadamente) e se o banco de dados é um snapshot de banco de dados , o que é uma coisa diferente .

Não considerei o seguinte:

Um banco de dados OFFLINE deve ser DEFINIDO COMO EMERGÊNCIA antes de ser descartado?

a questão aqui é: há algo, alguma verificação, que você pode ver que eu deveria ter adicionado, mas não adicionei?

Eu lidei com duas coisas:

1. banco de dados é um instantâneo
2. banco de dados está envolvido na replicação

Eu não lidei com:

1. O banco de dados faz parte de um grupo de disponibilidade (nesse caso, eu precisaria removê-lo do AG primeiro)
2. mais alguma coisa que você possa ver?

Antes do SQL Server 2016, o particionamento de índices columnstore era considerado praticamente obrigatório porque os bloqueios tomados neles durante inserções/atualizações/exclusões eram extremos. No entanto, a partir do SQL Server 2016, os bloqueios tomados em índices columnstore são muito menos intensos . Por que, então, ainda é considerado uma prática recomendada particioná-los?

Estou ciente do truque onde você pode melhorar o alinhamento trocando uma partição, construindo um índice rowstore clusterizado, substituindo esse índice por columnstore e então trocando a partição novamente. No entanto, essa é apenas uma otimização de desempenho moderada que raramente sobrevive a uma reconstrução e foi amplamente tornada redundante pelos recursos de ordenação do SQL Server 2022 .

Tenho um arquivo /etc/mysql/mysqld_multi_cls.cnf com tudo o que o mariadb precisa para múltiplas instâncias de banco de dados.

Posso iniciar essas instâncias com o seguinte comando:

sudo mariadbd-multi --defaults-file=/etc/mysql/mysqld_multi_cls.cnf start  

 

Mas não consigo encontrar uma maneira (legal) de iniciar essas instâncias na inicialização.

Adicionar o arquivo .cnf na pasta /conf.d/ não inicia a instância, a menos que eu esteja fazendo alguma besteira sem saber. O banco de dados está rodando em um Raspberry pi5, Raspberry Pi OS, que é baseado em Debian. E eu sou bem desinformado/novato com Linux.

Após solicitação, aqui está o arquivo .cnf:

# Configuration Settings for mysqld_multi , as well as separate instances. 
#
[mysqld_multi]
mysqld       = /usr/bin/mariadbd-safe
mysqladmin   = /usr/bin/mariadb-admin

[mysqld2]
socket          = /tmp/mysql.sock2
port            = 3307
pid-file        = /usr/local/mysql/mdb2/ansible-host1.pid2
datadir         = /var/lib/mysql2
log-error       = /var/log/mysql2/error.log
log-bin             = /var/log/mysql2/mdb2-mysql-bin.log
server-id               = 2
expire-logs-days    = 72
sync_binlog              = 1
innodb_flush_log_at_trx_commit  = 1
innodb_flush_method = O_DIRECT      
binlog_format                 = mixed
gtid_strict_mode            = 1

[mysqld3]
socket          = /tmp/mysql.sock3
port            = 3308
pid-file        = /usr/local/mysql/mdb3/ansible-host1.pid3
datadir         = /var/lib/mysql3
log-error       = /var/log/mysql3/error.log
log-bin             = /var/log/mysql3/mdb3-mysql-bin.log
server-id               = 3
expire-logs-days    = 64
sync_binlog     = 1
innodb_flush_log_at_trx_commit  = 1
innodb_flush_method = O_DIRECT  
binlog_format       = mixed
gtid_strict_mode    = 1

[mysqld4]
socket          = /tmp/mysql.sock4
port            = 3309
pid-file        = /usr/local/mysql/mdb4/ansible-host1.pid4
datadir         = /var/lib/mysql4
log-error       = /var/log/mysql4/error.log
log-bin             = /var/log/mysql4/mdb4-mysql-bin.log
server-id               = 4
expire-logs-days    = 64
sync_binlog     = 1
innodb_flush_log_at_trx_commit  = 1
innodb_flush_method = O_DIRECT  
binlog_format       = mixed
gtid_strict_mode    = 1

R ⋈ (S ∪ T) = (R ⋈ S) ∪ (R ⋈ T) é válido para a semântica de bolsa de álgebra relacional?

Não sei se isso vale para a semântica de bag para join e union.