All perguntas(dba)

Tenho trocado certificados TDE em vários servidores para facilitar as restaurações - alguns tinham o nome errado, a impressão digital errada ou até mesmo ambos. Isso envolve a transferência de bancos de dados para um certificado temporário, a eliminação de certificados antigos, a criação do certificado pretendido (a partir do certificado e dos arquivos de chave) e a transferência de bancos de dados para ele. Tudo correu bem, exceto para bancos de dados em um servidor.

Ao executar DBCC CHECKDB(SomeDatabase) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY, recebo isto:

Msg 33111, Level 16, State 3, Line 106
Cannot find server certificate with thumbprint '<old removed thumbprint>'.
Msg 1823, Level 16, State 2, Line 106
A database snapshot cannot be created because it failed to start.
Msg 1823, Level 16, State 8, Line 106
A database snapshot cannot be created because it failed to start.
Msg 7928, Level 16, State 1, Line 106
The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.

Se for executado novamente com mensagens informativas, ele executa o comportamento esperado do CHECKDB posteriormente, de modo que parece obter o acesso necessário para off-line.

Os backups têm uma saída semelhante. Normalmente uso a UI do SSMS para backups ad hoc, que geram scripts como este comando: BACKUP DATABASE [SomeDatabase] TO DISK = N'some\path\SomeDatabase.bak' WITH DIFFERENTIAL , NOFORMAT, NOINIT, NAME = N'SomeDatabase-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10. Isto resulta em:

Msg 33111, Level 16, State 3, Line 108
Cannot find server certificate with thumbprint '<old removed thumbprint>'.
Msg 3013, Level 16, State 1, Line 108
BACKUP DATABASE is terminating abnormally.

A mesma coisa acontece com backups completos e somente cópia.

Observando o status da criptografia:

SELECT a.dbid, a.name AS DatabaseName
,b.encryption_state
,CASE b.encryption_state
WHEN 0 THEN 'No database encryption key present, no encryption'
WHEN 1 THEN 'Unencrypted - Encryption enabled, but not turned on'
WHEN 2 THEN 'Encryption in progress'
WHEN 3 THEN 'Encrypted'
WHEN 4 THEN 'Key change in progress'
WHEN 5 THEN 'Decryption in progress'
WHEN 6 THEN 'Protection change in progress (The certificate or asymmetric key that is encrypting the database encryption key is being changed.)'
END AS encryption_state_desc
,percent_complete
,encryptor_type
,key_algorithm
,key_length
,encryptor_thumbprint
,create_date
,regenerate_date
,modify_date
,set_date
,opened_date
FROM master.dbo.sysdatabases a
LEFT JOIN sys.dm_database_encryption_keys b
ON a.dbid = b.database_id
ORDER BY b.encryption_state desc,
DatabaseName;

Os bancos de dados com falha estão no estado 1 (chave de criptografia do banco de dados criada, mas a criptografia não está ativada) e mostram a nova impressão digital do TdeCert como encryptor_thumbprintcoluna. Existem alguns bancos de dados que estão no estado 3 (criptografados) e eles farão backup sem o certificado antigo. Se eu simplesmente colocar o certificado de volta no servidor, o CHECKDB/backups será executado com prazer - nenhum comando adicional no banco de dados será necessário.

Questões

• Por que ainda está tentando usar o certificado antigo? Achei que, como a chave de criptografia do banco de dados estava criptografada pelo novo certificado, não haveria mais necessidade do certificado antigo.
• Por que simplesmente colocar o certificado antigo de volta no servidor faz com que as coisas funcionem novamente? Eu esperava ter que mudar algo no banco de dados novamente.
• Por que não ocorre um erro quando removo o certificado antigo se algo o estiver usando?
• Existe um motivo provável para eu ter encontrado esse comportamento em apenas um servidor?

informações gerais

• Versão: Microsoft SQL Server 2019 (RTM-CU27) (KB5037331) - 15.0.4375.4 (X64) ... Edição Padrão
• O TDE é configurado com chaves simétricas, sem cofres de chaves externos.
• Tudo está no local, sem fatores Azure/nuvem.
• Este é um servidor não-prod; todos os bancos de dados usam o modelo de recuperação SIMPLES (sem logs de transações).
• Esses erros ocorrem em trabalhos automatizados, bem como em instruções executadas diretamente no SSMS. Tanto eu quanto a conta usada para trabalhos temos sysadmin no servidor.
• Isso está acontecendo em um único servidor. Todos os outros servidores nos quais troquei certificados (incluindo aqueles da mesma versão) não tiveram esse problema e não consigo replicar esse problema em outros servidores.
• O certificado antigo tinha o mesmo nome do certificado que eu gostaria de usar. Eu não esperaria que isso importasse - não importava para outros servidores - mas dado que algo parece estar "travado", pode ser relevante.

Testes

• Falha: CHECKDB gera uma mensagem de erro e passa a funcionar offline
• Sucesso: Nenhuma mensagem de erro, os comandos são executados com sucesso

1. Ativar totalmente a criptografia (ALTER DATABASE SomeDatabase SET ENCRYPTION ON) - falha

2. Basta trazer o certificado antigo de volta, não alterar nenhum banco de dados - sucesso

   1. Mas assim que o certificado antigo for descartado novamente, ele voltará ao fracasso

3. Altere a chave de criptografia do banco de dados para outra coisa e execute CHECKDB

   1. Novo certificado temporário – falha
   2. Restaurando o certificado desejado e alterando o DEK para esse certificado - sucesso
   3. Transferir de volta para o certificado temporário enquanto o certificado restaurado ainda está presente - sucesso
   4. Descartar certificado antigo/restaurado - falha

4. Gerar novamente a chave de criptografia do banco de dados - falha

5. Livre-se do novo certificado TdeCert padrão e execute novamente o script de transferência - ainda uma falha

6. Elimine a chave de criptografia do banco de dados e execute CHECKDB - sucesso

   1. Crie uma nova chave de criptografia de banco de dados com qualquer certificado - sucesso

Itens relacionados que não resolveram meu problema

• Esta questão demonstra algo bastante semelhante, mas não parece relevante porque estou em uma versão diferente, vários lançamentos após a correção descrita.
• Este artigo da Microsoft descreve um erro em que ocorreu "Não é possível localizar o certificado do servidor" ao especificar as opções COMPRESSION e MAXTRANSFERSIZE. O comando de backup que estou usando não especifica essas opções e o problema descrito foi resolvido em versões mais antigas.
• Existem muitas perguntas e artigos por aí sobre a mensagem "Não é possível encontrar o certificado do servidor" ao tentar uma restauração, nenhum dos quais parece relevante, pois não estou fazendo uma restauração.

Bom dia,

Tenho um cliente fazendo pesquisa científica. O design atual do banco de dados (Azure postgres) é 3NF, mas muito poucas transações estão acontecendo. Existem vários "pipelines" que adicionam novos dados às tabelas e os cientistas podem fazer uma atualização em alguns dados ou "descartar" alguns dados como errôneos, mas no geral muito pouco está acontecendo em termos de transações.

No entanto, eles têm um aspecto de “relatório” no seu trabalho e é isso que os cientistas fazem a maior parte do dia. Observar os dados (coisas genéticas) e ver se essas mutações foram vistas antes ou quais são os marcadores de início e parada, etc.

Por exemplo, uma de suas páginas da web de "relatórios" ou análise de dados chama uma visualização. Essa visualização leva mais de 4 minutos para ser executada. Quando olho para essa visualização, basicamente estou reunindo todos os dados das diferentes tabelas 3NF e achatando-os em 1NF para depois exibi-los.

Então aqui estão meus pensamentos/perguntas:

As tabelas 3NF e 1NF poderiam existir no mesmo banco de dados e no mesmo esquema? Eu sei que você poderia literalmente fazer isso, mas isso seria sábio/problemático? É algum tipo de "antipadrão" misturar e combinar assim?

1a. Se você fizesse isso, modificaria os pipelines para colocar os novos dados recebidos diretamente nas tabelas 1NF ou ainda deixaria o pipeline ser inserido no 3NF e então teria um gatilho ou processo ETL, etc.

1b O pensamento aqui é que se uma tabela existisse em 1NF, poderíamos simplesmente fazer uma varredura a partir dessa tabela, em vez de todas as junções, cte, subconsultas, etc., que estão atualmente na visão de longa execução.

Devo migrar toda a operação para 1NF entendendo que as poucas transações existentes serão mais lentas, mas 90% de todo o resto (sp, vw, fx, etc) será menos complexo e mais rápido.

2a. Se eu migrasse tudo para 1NF, você ainda teria tabelas de "teste" nas quais o pipeline grava os novos dados recebidos e, em seguida, um processo ETL carregaria os novos dados nas tabelas 1NF?

No geral, estou querendo planejar soluções de longo prazo. Claro que posso reduzir essa visualização de 4 minutos no tempo, mas a longo prazo, no que devemos pensar, especialmente porque o volume de dados continua a crescer. (aumento de 20% só no ano passado).

TIA

Tenho uma editora Standard 2019 que atua como distribuidora própria, com cerca de 150 assinantes em todo o mundo. São 4 publicações, das quais apenas 2 estão ativas. As alterações de dados são muito limitadas (cerca de 5 gravações por dia). Os assinantes são todos da edição SQL Express.

Meu principal problema aqui é que muitas vezes algum agente de distribuição decide que não deseja iniciar corretamente; ou seja, o trabalho fica preso na execução do agente em um loop de nova tentativa. Quando olho para o monitor de replicação, a mensagem diz para procurar no histórico de trabalhos do agente. O histórico de tarefas do agente aponta para o monitor de replicação.

Já tentei aumentar o histórico e o detalhamento da saída, e enviar informações para o arquivo, para os agentes que estavam apresentando o problema, mas parece que isso só começa quando o agente passa da fase de inicialização.

Lendo on-line, encontrei um artigo antigo sobre o esgotamento do heap da área de trabalho, mas também parece que se refere ao WS anterior a 2016 (e estou executando o WS 2019), então não tenho certeza se isso realmente se aplica.

Pesquisas adicionais no Google não produziram nada de valor. Você conhece um método para depurar/solucionar esses problemas, exceto um ticket para a MS ou algum recurso para tentar seguir?

Edite conforme solicitado, aqui está uma cópia e colagem das mensagens que posso ver:

Monitor de replicação: Mensagens de erro:

• O agente 'PublisherName-PublicationName-SubscriberName-AgentID' está tentando novamente após um erro. 74 tentativas tentadas. Consulte o histórico de trabalhos do agente na pasta Trabalhos para obter mais detalhes.

Resultados de

SELECT jh.*FROM msdb.dbo.sysjobhistory jh
INNER JOIN distribution1.dbo.MSdistribution_agents da
   ON da.job_id = jh.job_id
WHERE da.name = ''
ORDER BY jh.instance_id DESC

(captura de tela apenas da iteração mais recente)

Em relação à consulta abaixo que executo em um servidor físico com SQL Server 2019:

SELECT
    memory_node_id,
    SUM(pages_kb) / 1024.0/1024 AS TotalMemoryGB
FROM sys.dm_os_memory_clerks
GROUP BY memory_node_id
ORDER BY memory_node_id;

pois memory_node_id = 0mostra mais memória do que a disponível fisicamente no nó NUMA. Como pode ser?

Como especifico que um usuário do banco de dados não pode editar a AspNetUserRolestabela no SQL Server? Atualmente, o usuário tem Membership-> db_ownerpermissão e pode fazer tudo.

Gostaria de controlar as permissões apenas manualmente do usuário administrador do SQL Server.

EDIT : com 'edit' estou me referindo à adição de uma linha na tabela.

Quero executar os comandos listados aqui: https://dev.mysql.com/doc/mysql-shell/8.4/en/check-instance-configuration.html

Eu adicionei o pacote MySQL mais recente mysql-apt-config_0.8.30-1_all.debpara instalar, mysql-cluster-8.4-ltsque funciona.

Eu segui as instruções daqui para instalar o mysqlsh 8.4: https://dev.mysql.com/doc/mysql-shell/8.4/en/check-instance-configuration.html

Isso envolve reconfigurar o pacote para apontar para a versão 8.4 que não é do cluster, a fim de obter acesso ao mysqlsh 8.4.

Ao executar recebo o seguinte erro:dba.checkInstanceConfiguration('[email protected]:3306')

ERROR: 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'dba.checkInstanceConfiguration('[email protected]:3306')' at line 1

Depois de fazer algumas experiências, parece que COMPRESSION lz4não tem nenhum efeito nas JSONBcolunas (ao contrário de JSON, e TEXT). É realmente esse o caso? Se sim, por que isso acontece?

Eu poderia mergulhar nas listas de discussão e/ou no código-fonte do Postgresql para tentar encontrar a resposta, mas espero que alguém que já saiba a resposta possa intervir.

Existe uma maneira de listar todos os usuários/hosts que receberam acesso a um banco de dados? Eu sei que posso fazer isso:

> show grants for someuser;
+------------------------------------------------------------------------------------------------------+
| Grants for someuser@%                                                                                   |
+------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `someuser`@`%` IDENTIFIED BY PASSWORD '*XXXXXXXXXXXXX' |
| GRANT ALL PRIVILEGES ON `a_database`.* TO `someuser`@`%` WITH GRANT OPTION                           |
+------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

Ou isto:

> show grants for someuser@afqdn;
+-----------------------------------------------------------------------------------------------------------------------+
| Grants for someuser@afqdn                                                                                   |
+-----------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `someuser`@`qfqdn` IDENTIFIED BY PASSWORD '*XXXXXXXXXXXXX' |
| GRANT ALL PRIVILEGES ON `a_database`.* TO `someuser`@`afqdn`                                             |
+-----------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

Existe uma maneira de fornecer o banco de dados na solicitação? E então obter todos os usuários diferentes que receberam acesso a esse banco de dados de uma só vez? Nos exemplos que usei, ele começa com um determinado nome de usuário (e para meu caso de uso específico eu tenho o nome de usuário), mas que tal listar todos os usuários de uma só vez, em vez de adivinhar usuário por usuário / fqdn por fqdn?

Estou tentando entender o conceito de bifurcações de recuperação no SQL Server, principalmente em relação à visualização sys.database_recovery_status. A documentação menciona diversas colunas relacionadas aos forks de recuperação, como:

• recuperação_fork_guid
• first_recovery_fork_guid
• fork_point_lsn

No entanto, estou lutando para encontrar explicações claras sobre o que isso significa e seu significado. Minhas perguntas específicas são:

• O que exatamente é um fork de recuperação no SQL Server?
• Como os garfos de recuperação se relacionam com os processos de recuperação de banco de dados?
• Quais cenários normalmente levam à criação de uma bifurcação de recuperação?

Pesquisei online, mas parece haver poucos artigos que introduzam ou expliquem esse conceito em profundidade. Quaisquer insights ou explicações serão muito apreciados, bem como indicações para quaisquer recursos abrangentes sobre este tópico.

Uma das tabelas centrais do meu banco de dados possui uma varchar(25)coluna chamada EmployeeID.

Esta coluna é usada em um índice composto e é provavelmente o índice mais usado em nosso sistema.

Recebemos uma solicitação de melhoria do lado comercial que exigiria que ampliássemos essa coluna para varchar(75). Os 200 milhões de linhas existentes não seriam atualizados e seus EmployeeIDs ainda teriam menos de 25 caracteres. Estaríamos apenas adicionando alguns milhares de novas linhas que podem ter EmployeeIDs excedendo 25 caracteres.

Minha pergunta é, neste caso, o alargamento da coluna EmployeeID teria impacto no desempenho deste índice?