All perguntas(dba)

Tenho uma dúvida sobre um cenário semelhante ao descrito aqui: SQL: Entidade pertence (muitos para um) a uma de duas entidades diferentes

Digamos que eu entenda a necessidade da Partytabela e todas as outras referências a ela. Mas estou curioso para saber na PartyTypetabela qual a necessidade da Namecoluna? Quer dizer, é só para manter o varchar “Pessoa” ou “Organização”?

Da mesma forma, na Partytabela, para que Nameserve a coluna?

E também, qual é a necessidade da PartyTypemesa? Quer dizer, é só ter um lugar para inserir todos os tipos e o mais importante garantir que na hora de inserir, se houver algo errado PartyTypeCd(não presente na PartyTypetabela) teremos um erro, certo?

Outra questão é: como você inseriria um Organizationou um Person? Vendo o esquema proposto, Organizationas Persontabelas possuem seus próprios ids ( PersonIde OrganizationIdrespectivamente) que fazem referência a ambos PartyIdna Partytabela. Então, isso significa que devemos inserir primeiro um novo Person(por exemplo), na Partytabela? Se for esse o caso, não deveria haver um AUTO INCREMENTna PartyIdcoluna da Partytabela, para termos certeza de que não obteremos Organização e Pessoa com o mesmo id?

Do jeito que está , PartyId não pode ser a única chave primária . A chave primária na Partytabela deve ser combinada entre PartyTypeCde PartyId.

Minha situação é semelhante, de certa forma, à da pergunta vinculada no topo. Apenas para referência, aqui está um pequeno exemplo de esquema.

Basicamente, tenho uma situação em que a Component(que tem suas próprias colunas, como component, and price) pode ser associada a a User_Brandou a a System_Brand( ambos têm suas próprias colunas e campos exclusivos , que excluí da captura de tela... então, mesclando- os em um tabela com uma typecoluna NÃO é uma solução ).

Temos uma coleção em nosso MongoDB onde, devido a uma alteração no caso de uso, uma consulta até agora pequena agora está muito lenta. O agregado em questão é mais ou menos assim:

db.collection.aggregate([
  {
    $match: {
      "_id": {
        $in: [ list of 1000 ids ]
      }
    }
  },
  {
    $unwind: "array_field"
  },
  {
    $match: {
      "array_field.sub_field": 123456789
    }
  }
])

Minha pergunta agora é: um índice como esse seria {"_id": 1, "array_field.sub_field": 1}levado em consideração aqui ou é necessário fazer com que os desenvolvedores movam o segundo $matchpara o primeiro?

Infelizmente, um retrabalho do modelo de dados não estará disponível em um futuro próximo.

Temos um SQL Server 2016 que possui 20 bancos de dados diferentes que são usados ​​por diferentes aplicativos e diferentes equipes da empresa. Existem grupos de usuários no Active Directory que reúnem funcionários que trabalham em determinados projetos. O problema é que um funcionário pode fazer parte de diversas equipes ao mesmo tempo. A mesma pessoa pode pertencer a vários grupos AD diferentes.

Um usuário reclamou que não conseguia acessar um determinado banco de dados. Quando ele estava tentando atualizar o relatório do Power BI que consulta esse banco de dados, ele recebeu uma mensagem de erro "Não foi possível autenticar com as credenciais fornecidas".

Aqui está uma imagem simplificada. Um servidor possui dois bancos de dados: DB1e DB2. Existem dois grupos AD App_Excel_Reportere DB2_Userdois logins correspondentes no SQL Server:

CREATE LOGIN [LegacyDomain\App_Excel_Reporter] FROM WINDOWS WITH DEFAULT_DATABASE=[master]

CREATE LOGIN [Domain\DB2_User] FROM WINDOWS WITH DEFAULT_DATABASE=[master]

Não tenho certeza se isso é importante, mas este servidor é um servidor legado que fazia parte de outra empresa adquirida pela empresa principal. Portanto, este computador SQL Server está no domínio LegacyDomain.

Dois grupos AD LegacyDomain\App_Excel_Reportertêm Domain\DB2_Userseus próprios conjuntos de usuários, mas um usuário Jack.Universalpertence a ambos os grupos AD.

Os usuários que fazem parte App_Excel_Reporterdevem ter acesso ao DB1. Os usuários que fazem parte DB2_Userdevem ter acesso ao DB2.

Nele DB1há um usuário mapeado para o login correspondente:

USE [DB1]
GO
CREATE USER [LegacyDomain\App_Excel_Reporter] FOR LOGIN [LegacyDomain\App_Excel_Reporter] WITH DEFAULT_SCHEMA=[dbo]
GO

Nele DB2há um usuário mapeado para o login correspondente:

USE [DB2]
GO
CREATE USER [Domain\DB2_User] FOR LOGIN [Domain\DB2_User] WITH DEFAULT_SCHEMA=[dbo]
GO

Quando um usuário Jack.Universaltenta atualizar o Power BI, ele está conectado ao Windows em seu laptop Domain\Jack.Universale vejo estas mensagens no log do SQL Server com o mesmo carimbo de data/hora:

Login succeeded for user 'Domain\Jack.Universal'. Connection made using Windows authentication, [CLIENT: <ip address>]
Error: 18456, Severity: 14, State: 38.
Login failed for user 'Domain\Jack.Universal'. Reason: Failed to open the explicitly specified database 'DB2'. [CLIENT: <ip address>]

Quando eu corro

xp_logininfo 'Domain\Jack.Universal', @option = 'all'

isto mostra

+-----------------------+------+-----------+-----------------------+---------------------------------+
|     account name      | type | privilege |   mapped login name   |         permission path         |
+-----------------------+------+-----------+-----------------------+---------------------------------+
| Domain\Jack.Universal | user | user      | Domain\Jack.Universal | LegacyDomain\App_Excel_Reporter |
| Domain\Jack.Universal | user | user      | Domain\Jack.Universal | Domain\DB2_User                 |
| Domain\Jack.Universal | user | user      | Domain\Jack.Universal | Domain\DB3_User                 |
+-----------------------+------+-----------+-----------------------+---------------------------------+

(sim, existem mais de dois bancos de dados e este usuário pertence a três grupos AD)

Se eu correr

xp_logininfo 'Domain\Jack.Universal'

sem a opção "todos", apenas a primeira linha será retornada:

+-----------------------+------+-----------+-----------------------+---------------------------------+
|     account name      | type | privilege |   mapped login name   |         permission path         |
+-----------------------+------+-----------+-----------------------+---------------------------------+
| Domain\Jack.Universal | user | user      | Domain\Jack.Universal | LegacyDomain\App_Excel_Reporter |
+-----------------------+------+-----------+-----------------------+---------------------------------+

Portanto, parece que quando um usuário do Windows Domain\Jack.Universalefetua login no SQL Server, o SQL Server escolhe o login LegacyDomain\App_Excel_Reporterpara permitir a entrada do usuário, mas quando tenta acessar um banco de dados, DB2essa tentativa falha porque o login LegacyDomain\App_Excel_Reporteré mapeado apenas para o usuário em DB1.

"o banco de dados especificado explicitamente" deve ser devido à cadeia de conexão do Power BI que especifica explicitamente DB2.

Como configuramos isso para que um usuário pertencente a ambos os grupos AD tenha acesso a ambos os bancos de dados? Os usuários que pertencem a apenas um grupo AD deverão ter acesso apenas ao banco de dados correspondente.

Não sou administrador de domínio, mas posso perguntar o que for necessário. A empresa não tem DBA, sou apenas um programador que sabe uma ou duas coisas sobre SQL Server.

Cavei um pouco mais fundo. Quando eu corro

EXEC xp_logininfo 'Domain\DB2_User', @option = 'members'

Recebo uma lista de usuários nesse grupo:

+-----------------------+------+-----------+-----------------------+-----------------+
|     account name      | type | privilege |   mapped login name   | permission path |
+-----------------------+------+-----------+-----------------------+-----------------+
| Domain\user1          | user | user      | Domain\user1          | Domain\DB2_User |
| Domain\user2          | user | user      | Domain\user2          | Domain\DB2_User |
| Domain\Jack.Universal | user | user      | Domain\Jack.Universal | Domain\DB2_User |
+-----------------------+------+-----------+-----------------------+-----------------+

E os usuários estão dentro Domaindo esperado.

Quando eu corro

EXEC xp_logininfo 'LegacyDomain\App_Excel_Reporter', @option = 'members'

Eu entendi isso:

+-----------------------------+------+-----------+-----------------------------+---------------------------------+
|        account name         | type | privilege |      mapped login name      |         permission path         |
+-----------------------------+------+-----------+-----------------------------+---------------------------------+
| LegacyDomain\user3          | user | user      | LegacyDomain\user3          | LegacyDomain\App_Excel_Reporter |
| LegacyDomain\user4          | user | user      | LegacyDomain\user4          | LegacyDomain\App_Excel_Reporter |
| LegacyDomain\Jack.Universal | user | user      | LegacyDomain\Jack.Universal | LegacyDomain\App_Excel_Reporter |
+-----------------------------+------+-----------+-----------------------------+---------------------------------+

Aqui o caminho da permissão está dentro LegacyDomaine o nome da conta também está dentro LegacyDomain, mas acima nos resultados do xp_logininfo 'Domain\Jack.Universal'nome da conta está dentro Domain, mas o caminho da permissão está dentro LegacyDomain.

Outra vez:

EXEC xp_logininfo 'Domain\Jack.Universal', @option = 'all'

+-----------------------+------+-----------+-----------------------+---------------------------------+
|     account name      | type | privilege |   mapped login name   |         permission path         |
+-----------------------+------+-----------+-----------------------+---------------------------------+
| Domain\Jack.Universal | user | user      | Domain\Jack.Universal | LegacyDomain\App_Excel_Reporter |
| Domain\Jack.Universal | user | user      | Domain\Jack.Universal | Domain\DB2_User                 |
| Domain\Jack.Universal | user | user      | Domain\Jack.Universal | Domain\DB3_User                 |
+-----------------------+------+-----------+-----------------------+---------------------------------+

EXEC xp_logininfo 'LegacyDomain\Jack.Universal', @option = 'all'

+-----------------------------+------+-----------+-----------------------------+---------------------------------+
|        account name         | type | privilege |      mapped login name      |         permission path         |
+-----------------------------+------+-----------+-----------------------------+---------------------------------+
| LegacyDomain\Jack.Universal | user | user      | LegacyDomain\Jack.Universal | LegacyDomain\App_Excel_Reporter |
+-----------------------------+------+-----------+-----------------------------+---------------------------------+

Deve haver alguma mágica no Active Directory que mapeie os usuários do domínio legado para o domínio principal.

Temos o SQL Server 2022 Enterprise (16.0.4131.2) na VM do Windows 2022 (8 núcleos de vCPU) e há um problema com o Query Store em um dos bancos de dados.

Abaixo está a sequência de etapas que posso seguir para reproduzir o problema em um banco de dados específico e as observações que fiz sobre ele:

1 - O servidor está em estado inativo com apenas uma pequena carga gerada pelo usuário e utilização insignificante da CPU como ponto de partida.

2 - O Query Store está desligado e vazio para o banco de dados problemático, conforme mostrado na consulta abaixo.

3 - Quando mudo o Query Store para o modo READ_WRITE, tudo fica perfeitamente bem por cerca de 10 a 15 minutos. No entanto, após esse período, a utilização da CPU do servidor aumenta repentinamente para 15-20%. Veja a captura de tela do Activity Monitor abaixo.

As estatísticas de espera mostram um grande aumento nas esperas SOS_SCHEDULLER_YELD e PREEMPTIVE_OS_QUERYREGISTRY - elas saltam para os principais tipos de espera do servidor nesse período.

A utilização da CPU gerada parece ser gerada por um processo interno em segundo plano (SPID < 51) relacionado a uma atividade do Service Broker no banco de dados do usuário problemático. O recurso Service Broker não está ativado no próprio banco de dados.

4 - A alta utilização da CPU, as esperas mencionadas acima e a atividade SPID mencionada acima são apresentadas continuamente até que o Query Store no banco de dados seja desligado.

Não há sinais de qualquer "auto-recuperação" potencial, se eu mantiver o Query Store ativado. Uma vez desligado, a utilização da CPU diminui, as esperas desaparecem e o SPID para de gerar a carga e fica "hibernando". Mudar o Query Store para o modo READ_ONLY não ajuda. O Query Store deve ser desativado para eliminar o problema.

Não há nenhuma quantidade significativa de dados no Repositório de Consultas quando o problema é acionado – veja abaixo (consultas feitas após o QS ser desativado).

Outras observações relacionadas

• Se eu ativar (READ_WRITE) o Query Store e mantê-lo funcionando por apenas um tempo, mas não o suficiente para acionar o problema, mude para READ_ONLY, o problema não será acionado no período de 10 a 15 minutos conforme descrito acima. No entanto, ele será acionado quase instantaneamente se eu mudar o Query Store para READ_WRITE a qualquer momento posteriormente.

• Quando a carga do usuário aumenta no momento em que o problema é acionado, pode-se observar que o uso de consultas no banco de dados que levam alguns milissegundos para serem processadas nas condições padrão começa a ficar mais lento e também mostra esperas PREEMPTIVE_OS_QUERYREGISTRY não desprezíveis (conforme sp_WhoIsActive mostrado abaixo). Essas consultas definitivamente não fazem consultas ao registro do Windows.

• Temos o mesmo banco de dados (ou seja, a mesma estrutura) em várias outras instâncias do SQL Server com o mesmo padrão de carregamento (e volumes de dados e consultas ainda muito maiores) e o Query Store funciona perfeitamente bem lá. Parece que algo está quebrado no Query Store apenas para este banco de dados específico.

• Pode ser importante que o Repositório de Consultas desse banco de dados esteja originalmente cheio e o "processo de limpeza baseado em tamanho" tenha sido acionado e o SQL Server (provavelmente) reiniciado durante esse período. Desconfio que haja algo quebrado no QS daquele banco de dados em relação a isso... Tentei também a procedure sys.sp_query_store_consistency_check , mas sem sucesso.

• Depois que o problema é acionado e "suspenso" ao desligar o QS, quando o QS é ligado novamente (sem limpeza prévia), parece que o problema é acionado novamente quase instantaneamente.

O Query Store fica completamente inutilizável para o banco de dados nessas condições. Alguma idéia de como consertar isso?

ATUALIZAÇÃO 01/08/2024

Com base na dica do comentário de Paul White, fiz alguns experimentos com a opção de escopo do banco de dados CE_FEEDBACK e parece ser o verdadeiro gatilho. O comportamento é descrito abaixo:

Tenho o Query Store não limpo de tentativas anteriores (apenas algumas centenas de consultas de captura) como ponto de partida.

• Quando defino CE_FEEDBACK = OFF e coloco o QS em READ_WRITE, o problema não é acionado.
• Quando defino CE_FEEDBACK = ON e coloco o QS em READ_WRITE, o problema é acionado quase instantaneamente.
• Quando defino CE_FEEDBACK = OFF e coloco o QS em READ_WRITE, o problema não é acionado. Então (com o QS em execução) eu alterno CE_FEEDBACK = ON. O problema é novamente desencadeado instantaneamente. O interessante também é que quando eu configurei CE_FEEDBACK = OFF novamente, não é suficiente para resolver o problema. O QS também deve ser desligado para pará-lo.

TIPO DE CARGA DE TRABALHO

Como o problema parece estar relacionado também ao tipo de carga de trabalho, tentarei descrevê-lo aqui, pois o padrão é bastante direto. É quase 99% ad hoc com os seguintes padrões de consulta:

• Cerca de 85% das consultas executadas durante o experimento são uma simples junção à variável da tabela. O número de linhas passadas para a variável varia de +/- 10 a +/- 500. A tabela do banco de dados de origem varia entre as consultas, mas o padrão do plano de execução é o mesmo mostrado abaixo.

• O restante da carga de trabalho são consultas que seguem o padrão abaixo. O problema com esta parte é que devido a uma alta variabilidade dos parâmetros (o número de parâmetros muda frequentemente), então é capaz de preencher um armazenamento de consultas de 2GB em poucos dias com consultas "únicas", mas não é o caso para o cenário atual

Posso imaginar que provavelmente a primeira parte da carga de trabalho possa ser problemática para o CE_FEEDBACK.

Criamos uma sessão de Eventos Estendidos para capturar erros com gravidade 16 ou superior:

CREATE EVENT SESSION [Error_Reporting] ON SERVER 
ADD EVENT sqlserver.error_reported(
    ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_server_principal_name,sqlserver.sql_text,sqlserver.username)
    WHERE ([severity]>(15)))
ADD TARGET package0.event_file(SET filename=N'https://storageaccount.blob.core.windows.net/logs/Errors.xel',max_file_size=(10240), max_rollover_files=1)
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

Agora podemos consultá-lo executando:

select cast(event_data as xml), timestamp_utc
from sys.fn_xe_file_target_read_file('https://storageaccount.blob.core.windows.net/logs/Errors_0_133667581914690000.xel', NULL, NULL, NULL)

A coluna event_dataé do tipo nvarchar, mas contém valores XML, que representam uma tabela.

Pergunta :

Como event_dataa coluna pode ser convertida (dividida) em várias colunas (como UserName, Error_number, Categoria, Destino, Mensagem e assim por diante), quando consultada no editor de texto no SSMS?

Exemplo de dados XML: https://pastecode.io/s/tjg7jo40

Criei uma procedure no Postgres que irá criar uma tabela com o conteúdo de outras três tabelas (SELECT com JOINS). Em seguida a tabela resultante será alterada adicionando duas colunas que não existiam antes e finalmente dentro do mesmo procedimento criei 3 triggers que serão aplicados nessas três tabelas então sempre que uma nova escrita acontecer em qualquer uma delas, a mesma entidade será gravada na nova tabela

Eu sei que o procedimento em si é atômico e transacional em seu próprio escopo, mas o procedimento não tem como saber nada sobre as três tabelas. Receio que no tempo entre a criação da nova tabela e a criação dos gatilhos, algumas gravações nas tabelas existentes possam ocorrer, dessincronizando assim a nova tabela, que não registrará essas gravações. Isso não pode acontecer.

Meu procedimento de criação de tabela/criação de gatilho é assim:

CREATE OR REPLACE PROCEDURE myschema.table_creation()
LANGUAGE plpgsql
AS $procedure$
begin
create table newtable as
SELECT * FROM myschema.session a NATURAL JOIN (SELECT * FROM myschema.message b NATURAL left JOIN myschema.data) as d;
ALTER TABLE myschema.newtable ADD created_at timestamp;
ALTER TABLE myschema.newtable ADD source text;
CREATE TRIGGER mytrigger
after INSERT
ON myschema.session
FOR EACH ROW
EXECUTE PROCEDURE myschema.trigger_proc();
CREATE TRIGGER mytrigger
after INSERT
ON myschema.messages
FOR EACH ROW
EXECUTE PROCEDURE myschema.trigger_proc();
CREATE TRIGGER mytrigger
after INSERT
ON myschema.data
FOR EACH ROW
EXECUTE PROCEDURE myschema.trigger_proc();
end;
$procedure$
; 

Como posso bloquear as gravações nas tabelas existentes para adiá-las até que todo o procedimento table_creation seja concluído? Caso contrário eu teria uma condição de corrida e algumas entidades seriam perdidas na nova tabela. não acho que meu procedimento em seu estado atual tenha qualquer proteção contra gravações

Este gatilho ações na criação do banco de dados - mostra um exemplo de um gatilho do lado do servidor que é acionado quando alguém cria um novo banco de dados.

Esta outra pergunta - Gatilho para alterar o agrupamento do banco de dados na criação - também mostra um exemplo de gatilho do lado do servidor que é acionado quando alguém cria um novo banco de dados.

Tenho aqui um exemplo de gatilho do lado do servidor que evita que os usuários descartem logins:

USE [master]
GO

--======================================================================
-- example of a server trigger - does not allow a login to be dropped
--======================================================================
create trigger [no_dropped_logins]   on all server   
for drop_login   
as     
insert into ##LOGIN_WATCH       
select r.*, s.login_name, s.host_name,        
EVENTDATA().value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvarchar(max)') AS 'CmdText'       
from sys.dm_exec_requests r          
inner join sys.dm_exec_sessions s          
on r.session_id = s.session_id          
where r.session_id = @@SPID

Minha pergunta é:

como posso evitar a criação de um servidor vinculado no sql server usando gatilhos do lado do servidor?

É um prazer conhecer todos vocês.

Esta é a primeira vez que posto aqui, então sinta-se à vontade para me avisar se estiver errado.

Estou fazendo algumas pesquisas sobre o recurso Transparent Data Encryption. Quero validar a capacidade de extrair dados sem fazer login na instância do banco de dados e antes da criptografia, lendo o arquivo .dbf diretamente com HexEditor, Notepad++ ou algo equivalente.

O problema está no tipo de dados VARCHAR2; o valor é texto simples, o mesmo que retorna quando faço uma consulta na instância. Mas com NUMBER, DATE ou qualquer coisa que não seja VARCHAR2, não consigo encontrar texto simples no .dbf

Tipos de dados de colunas

O retorno quando faço uma consulta na instância

O Editor Hex retorna texto simples com dados do tipo de dados VARCHAR2…

… mas não com dados do tipo de dados NUMBER

Pesquisei bastante na Internet, mas parece que não há uma resposta clara nem uma demonstração do conteúdo dos arquivos de dados antes e depois de usar o TDE. Por que é assim? E mais, acho que o Oracle armazena tipos de dados não VARCHAR2 em formato binário para economizar armazenamento e tipos de dados VARCHAR2 para retornar facilmente na consulta, estou correto?

Obrigado por qualquer orientação!

Vu Hoang.

Eu tenho uma tabela com cerca de 100.000.000 entradas, em sua maioria ordenadas por data de criação (sem fusos horários e algumas entradas <0,01%, a chave primária e a ordem correta seriam idênticas).

Um caso de uso comum é selecionar as n entradas mais recentes por meio de alguma instrução where arbitrária que é lenta.

Um grande gargalo é manter a ordem, classificando por: date=>x1, id => x10, not at all => x100

Existe uma maneira de aproveitar o fato de minha mesa estar quase ordenada?

Eu tenho uma consulta como esta:

SELECT
  cs1.id,
  cs1.uid,
  cs1.title,
  cs1.description
FROM related_chat_session rcs1
INNER JOIN chat_session cs1
ON cs1.id = rcs1.related_chat_session_id
WHERE
  rcs1.chat_session_id = $1 AND
  cs1.discoverable = true
ORDER BY random()
LIMIT 10

No momento, ele retornará o resultado sempre em ordem aleatória. No entanto, quero ajustar a lógica de forma que a aleatoriedade seja estável com base em uma semente, onde a semente é (por exemplo) o dia da semana.

ou seja, o resultado seria que os resultados de segunda-feira fossem listados em uma ordem, os de terça-feira em outra, etc.

Como eu faço isso?