Tenho um aplicativo que é multi-tenant. Então, um único banco de dados tem dados para todas as organizações que o usam.

Existe uma maneira de fornecer acesso ao banco de dados para que meus clientes possam se conectar a ele com qualquer ferramenta de análise, como o Power BI?

Há a tabela Org - onde posso especificar o PK dessa tabela que eles podem obter.

Depois, há a tabela Event, onde há um FK para a tabela Org.

E então uma tabela de inscrição (para o evento) que tem um FK para o evento e um FK para o usuário.

E o mais difícil é a tabela de usuários. Se o usuário estiver inscrito para um evento, então esse cliente pode obter esse usuário. O que significa que vários clientes podem ver essa linha da tabela de usuários.

Isto é especificamente SQL Server. Então eu precisaria criar alguma visão que determinasse quais registros de usuário um dado usuário pode visualizar. Enquanto eu poderia duplicar o Ord PK na tabela Event, o registro de usuário, como vários clientes podem obtê-lo - não funcionará com um FK adicionado.

Existe uma maneira de fazer isso?

Observei (e reproduzi) o seguinte cenário com o SQL Server 2022.

O padrão em uso

• o código é executado via sp_executesql (nenhum procedimento armazenado está envolvido)
• A primeira consulta seleciona dados em uma tabela temporária
• Uma instrução DDL cria então um índice clusterizado na tabela temporária. A tabela temporária definitivamente NÃO é armazenável em cache-- primeiro de tudo, isso não é um módulo (sproc ou função), mas também estamos criando um índice depois que a tabela temporária é preenchida. Então eu não esperaria que estatísticas deixadas para trás em um objeto temporário em cache estivessem envolvidas aqui.
• Uma consulta seleciona dados da tabela temporária. Esta consulta obtém otimização COMPLETA a cada vez (não é um plano TRIVIAL)

Este lote pode ser executado tanto para conjuntos de dados pequenos quanto maiores, de modo que a tabela temporária pode ter apenas uma linha ou milhares de linhas.

Esse comportamento normalmente ocorre em um secundário legível. Não há armazenamento de consulta gravável e nenhum plano automático forçando como um fator.

Verifiquei que posso reproduzir o comportamento também na réplica primária. (A correção automática do plano foi instruída a ignorar a consulta e confirmei que não há imposição de plano na primária quando reproduzida.)

Script de reprodução

• Script de configuração - Eu executei isso no SQL Server 2022 CU15. Isso desativa o armazenamento de consultas e usa o nível de compatibilidade 130.
• Consulta de reprodução - Tenho executado isso por meio do SQL Query Stress para poder executá-lo facilmente e simultaneamente em um ou mais threads
• Plan Generation Num e tabelas temporárias - Uma consulta muito simples para observar o plan_generation_num em sys query stats ("Um número de sequência que pode ser usado para distinguir entre instâncias de planos após uma recompilação.") e a lista atual de tabelas temporárias

O que normalmente acontece - e o comportamento que espero

Normalmente, alterar grandes quantidades de linhas na tabela temporária entre execuções de consultas causa automaticamente recompilações, e vejo que a consulta que seleciona os dados da tabela temporária tem uma estimativa de linha correspondente às linhas na tabela temporária.

Quando isso funciona como esperado, o desempenho é bom.

Com a consulta de reprodução : se eu limpar o cache do plano e executar a consulta de reprodução 40 iterações em um único thread no SQL Query Stress, o plan_generation_number acaba sendo 82. Ao amostrar planos de consulta com sp_WhoIsActive, as estimativas de linha que consultam a tabela temporária correspondem ao número de linhas na tabela temporária, conforme esperado.

O que às vezes acontece -- e parece um bug para mim

Em raras ocasiões, vejo que um plano está em uso onde há um plano de estimativa de 1 linha para a tabela temporária, mas uma quantidade muito grande de linhas está realmente na tabela temporária. MUITAS linhas foram alteradas, mas não recompilou automaticamente:

Isso leva a um desempenho muito lento porque o plano de estimativa baixa decide usar um loop aninhado sem pré-busca, o que o torna um queimador de CPU.

Com a consulta de reprodução : Se eu limpar o cache do plano e executar a consulta de reprodução 20 iterações em 2 threads no SQL Query Stress, o plan_generation_number acaba sendo menor que 82 — varia conforme a execução, mas pode ser 72 ou 59, indicando menos recompilações. Enquanto isso está em execução, também posso amostrar ocasiões com sp_WhoIsActive em que há uma única contagem de linhas estimada, mas muito mais linhas na tabela temporária. Captura de tela:

Só consigo reproduzir isso ao executar código de reprodução em várias sessões simultâneas

Não consegui reproduzir esse comportamento com uma única sessão no SQL Server. A única maneira de reproduzir isso é configurar um bloco de código que:

• Executa pelo menos 1 iteração da instrução sp_executesql que tem 1 linha na tabela temporária
• Em seguida, executa 1 iteração da instrução sp_executesql que tem muito mais linhas na tabela temporária

Se eu executar isso em uma única sessão, não consegui reproduzir os problemas. Mas se eu executar isso simultaneamente em quatro ou cinco sessões, ocasionalmente poderei ter o problema "QUE NÃO RECOMPILA COMO DEVERIA" aparecendo. (Observação: usando o SQL Query Stress, posso reproduzir isso com apenas 2 sessões/iterações.)

Isso parece um bug para mim, estou curioso para saber se mais alguém viu. O comportamento de recompilação e estatísticas com tabelas temporárias é super complexo, então pode haver alguma nuance que estou perdendo com a forma como isso funciona com tabelas temporárias não armazenáveis ​​em cache.

PS: Eu acho que tabelas temporárias armazenáveis ​​em cache são geralmente melhores. Só estou tentando descobrir por que esse comportamento aconteceria em um cenário de tabela temporária não armazenável em cache neste momento.

Soluções alternativas

Após adicionar um option (recompile)à consulta, não consigo mais reproduzir a reutilização do plano de 1 linha consultando a tabela temporária. Isso é suficiente, mas estou intrigado sobre o porquê de ser necessário.

Tenho algumas tabelas que eram 1 TB+. As colunas last_autovacuum e last_autoanalyze em pg_stat_user_tables têm NULLs para essas tabelas. A proporção de n_dead_tup para n_live_tup é 0,0001. Algumas perguntas, posso confiar nos números n_dead_tup e n_live_tup? As tabelas têm um grande número de inserções e algumas atualizações, sem exclusões. Se eu aspirar e analisar manualmente essas tabelas, as colunas serão atualizadas? A versão do PostgreSQL é 13.5

Exposição

Digamos que nosso sistema tenha usuários e alguns jogos . Vamos chamar esses jogos de A , B e C.

Para simplificar, nossas tabelas iniciais ficam assim:

CREATE TABLE IF NOT EXISTS users (
    id SERIAL PRIMARY KEY
);

CREATE TABLE IF NOT EXISTS games (
    id SERIAL PRIMARY KEY
);

Problema

Sempre que jogamos esses jogos e os terminamos, temos que registrar estatísticas relacionadas ao jogo para o usuário específico. Por exemplo, para o jogo A, temos que registrar total_jumps e total_crouches porque a mecânica do jogo permite tal acumulação, no entanto, os jogos B e C podem exigir que registremos outros campos total_* (embora o prefixo total_ não seja necessário). Como armazeno essas informações?

Estou preocupado com a solução para esse problema. Eu criei 2 abordagens:

Solução 1

Tenha uma única tabela para isso:

CREATE TABLE IF NOT EXISTS statistics (
    user_id SERIAL REFERENCES users (id) ON DELETE CASCADE,
    game_id SERIAL REFERENCES games (id) ON DELETE CASCADE,
    fields JSONB,
    PRIMARY KEY (user_id, game_id)
);

Dessa forma, deixamos para o nível do aplicativo analisar dados arbitrários provenientes da coluna de campos .

Solução 2

Tenha várias mesas, uma para cada jogo:

CREATE TABLE IF NOT EXISTS A_statistics (
    user_id SERIAL PRIMARY KEY REFERENCES users (id) ON DELETE CASCADE,
    total_jumps INTEGER,
    total_crouches INTEGER
);

Pessoalmente, a solução #2 parece melhor para mim, mas... esse problema ainda me incomoda muito. Como se eu estivesse esquecendo de algo, porque nenhuma das opções torna a extensão (adicionar novos jogos) mais fácil? Digamos que adicionamos os jogos D , E e F . Ambas as soluções exigem que, de alguma forma, manipulemos campos específicos (no nível do aplicativo) necessários para esses jogos. Isso é algo com o qual eu simplesmente tenho que me conformar? Ou há uma terceira solução melhor para isso que eu simplesmente não vejo?

Tivemos um incidente recentemente que fez com que nosso serviço ficasse indisponível por alguns minutos.

Aqui está o script do liquibase que levou ao incidente:

<addColumn tableName="registration">
    <column name="retry_at" value="null" type="DATETIME"/>
    <column name="retry_counter" value="null" type="BIGINT"/>
</addColumn>

Como você pode ver, o changeset levou bastante tempo. Nossa equipe concluiu que o valor padrão definido como nullé o culpado aqui. No entanto, de alguma forma, isso não me parece certo.

Quando verifico as páginas 1 e 2 do Postgres , vejo que definir os valores como nulos não é diferente de remover o valor padrão completamente. Então, não vejo por que essa configuração de valor padrão causaria tais problemas. Em uma nota lateral, havia 12 milhões de linhas na tabela.

Como no título, minha pergunta é: definir um valor padrão causa esses tempos de inatividade?

Inicialização do aplicativo:

Started ApplicationKt in 289.989 seconds (process running for 290.727)

Alguns logs antes da operação do liquibase:

No Db2 v11.5 no Linux, eu gostaria de criar uma variável e então usar essa variável na instrução SELECT. Eu não quero criar um procedimento ou função no banco de dados, eu só quero fazer isso em SQL dinâmico do db2cmd ou alguma ferramenta de banco de dados.

Exemplo simplificado:

BEGIN
     DECLARE name VARCHAR(10);
     SET name = 'John';
     SELECT * FROM SYSIBM.SYSDUMMY1 WHERE name = :name;
END;

EDIT: Por que não quero criar um procedimento/função armazenado? Eu realizo auditorias a cada semestre para privilégios/autorizações de banco de dados em vários bancos de dados e não tenho privilégio de criar procedimento em alguns dos bancos de dados, devido a configurações de segurança rígidas. Na maioria dos casos, só tenho acesso às tabelas do catálogo do sistema, o que é perfeitamente suficiente para criar auditoria. Eu listo os usuários do banco de dados e, em seguida, para usuários "suspeitos", realizo verificações completas de permissão/autoridade executando vários SQL-s do catálogo do sistema. Até agora, para cada usuário, usei o editor de texto e usei localizar/substituir, o que é uma solução OK, mas a variável é uma solução melhor. Obrigado!

Eu executei o comando abaixo e consigo encontrá-lo no diretório, ele está lá. Mas consultando `select * from dba_tablespaces' não consigo encontrá-lo. Estou tentando criar um novo esquema neste tablespace, mas estou lançando o erro tablessoace não existe. Qual é o meu erro?

CREATE BIGFILE TABLESPACE ESC_SCHEMA_DATA DATAFILE  '/datafiles/CDB1/O19/ESC_SCHEMA_DATA.DBF' SIZE 536870912000 AUTOEXTEND ON NEXT 1073741824 MAXSIZE 33554431M LOGGING ONLINE PERMANENT BLOCKSIZE 8192 EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT  NOCOMPRESS  SEGMENT SPACE MANAGEMENT AUTO

Temos um SQL Server 2019 CU18 onde descobrimos um problema estranho com o querystore. Normalmente, o tamanho médio do logbackup por hora é de 40 MB, mas assim que habilitamos o querystore, o tamanho médio do logbackup é de 2,5 GB.

Há (de acordo com o querystore) 140.000 consultas executadas/hora. Isso é cerca de 40 execuções/segundo.

Esta é a configuração do nosso querystore:

ALTER DATABASE [db_name]
SET QUERY_STORE = ON
    (
        OPERATION_MODE = READ_WRITE
        ,CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 45)
        ,DATA_FLUSH_INTERVAL_SECONDS = 900
        ,MAX_STORAGE_SIZE_MB = 2048
        ,INTERVAL_LENGTH_MINUTES = 30
        ,SIZE_BASED_CLEANUP_MODE = AUTO
        ,QUERY_CAPTURE_MODE = AUTO
);

Quando abro um arquivo de logbackup tão grande, fn_dump_dblogvejo que várias transações acontecem no mesmo segundo. Todas as transações têm o nome 'SwapPage'.

A unidade de alocação aponta para plan_persist_runtime_stats.

Após um comentário de Paul White, configurei um Evento Estendido para capturar query_store_index_rebuild_startede query_store_index_rebuild_finished. Para minha surpresa, o querystore estava fazendo reconstruções de índice. Estes são os resultados deste rastreamento:

Parece que a reconstrução do índice foi iniciada em torno de 874 MB, o tamanho máximo do querystore está definido como 2048.

Também incluí o stacktrace do query_store_index_rebuild_startedevento no Evento Estendido.

sqllang!XeSqlPkg::CollectClientHostnameActionInvoke sqllang!XeSqlPkg::CollectDatabaseIdActionInvoke sqllang!XeSqlPkg::CollectDatabaseNameActionInvoke sqllang!XeSqlPkg
::CollectNtUsernameActionInvoke sqllang!XeSqlPkg::CollectSessionIdActionInvoke sqllang!XeSqlPkg::CollectTSqlStack<XE_ActionForwarder> sqllang!XeSqlPkg::CollectTSqlStackActionInvoke qds!XeQdsPkg::query_store_index_rebuild_started::Publicar
qds!CDBQDS::ReclaimFreePages
qds!CDBQDS::DoSizeRetention
qds!CDBQDS::ProcessQdsBackgroundTask
qds!CQDSManager::AcquireGenericQdsDbAndProcess<<lambda_e51628d7833f66b5a045fa5bf2d27953>>
qds!CDBQDS::ProcessQdsBackgroundTask
sqldk!SOS_Task::Param::Executar
sqldk!SOS_Scheduler:: Executar tarefa sqldk
!SOS_Scheduler::ProcessTasks
sqldk!SchedulerManager::WorkerEntryPoint
sqldk!SystemThreadDispatcher::ProcessWorker
sqldk!SchedulerManager::ThreadEntryPoint
KERNEL32+0x17AC4
ntdll+0x5A8C1

Eu esperava descobrir o que está acionando a reconstrução do índice, mas não tive sorte.

Após algumas dicas do Zikato, adicionei alguns eventos extras relacionados ao querystore ao meu trace. Isso mostra que a reconstrução do índice só é acionada se um query_store_size_retention_cleanup_startedevento tiver ocorrido.

Sem reconstrução:

Reconstruir: Toda vez que a limpeza é executada, 0 KB é excluído, mas aparentemente uma reconstrução é necessária. O que me confunde é a aparência do evento de limpeza. Pensei que isso só seria acionado quando o querystore atingisse 90% do tamanho máximo de armazenamento. Aumentar o tamanho máximo do querystore não faz diferença.

Alguém passou pelo mesmo problema ou pode explicar o que está acontecendo? Outros bancos de dados na instância não têm esse problema.

Tenho dois servidores no SQL Server 2019 que decidiram aleatoriamente parar o serviço do SQL Server Browser. Ao tentar reiniciá-lo, ele desliga-se imediatamente. Usando o prompt de comando abaixo para iniciar no modo console no servidor host do banco de dados para obter mais feedback, vejo que ele está iniciando com sucesso, mas chega ao ponto "Não foram encontradas instâncias do mecanismo SQL instaladas -- não escutando no SSRP." que é onde ele desliga-se novamente.

C:\Windows\system32>"C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe" -c
SQLBrowser: starting up in console mode
SQLBrowser: starting up SSRP redirection service
SQLBrowser is successfully listening on ::[1434]
SQLBrowser is successfully listening on 0.0.0.0[1434]
SQLBrowser: Found no installed SQL engine instances -- not listening on SSRP.
SQLBrowser: Both SSRP and OLAP redirection services are disabled. Shutting down browser service

A única informação que consigo encontrar sobre isso faz referência à chave de registro ausente ou desabilitada para SSRP, que já verifiquei que está corretamente instalada.

HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\90\SQL Browser\SSRPListener

A chave é definida para um valor de 1. Para validar, eu a defino para 0, ponto em que o SQL Browser não inicia de forma alguma. Retornando para 1, ele retorna ao comportamento original de iniciar com sucesso e então desligar-se imediatamente.

Enquanto isso, os bancos de dados em si são acessíveis, então eu sei que de fato HÁ instâncias de mecanismo SQL instaladas que devem estar visíveis/escutando, e estou completamente perplexo sobre como prosseguir aqui. Qualquer migalha de ideia seria apreciada.

Editar para adicionar captura de tela, o lado esquerdo é o SQL Server 2019, onde ele quebrou, com o SQL Server 2014, onde ele ainda está funcionando como esperado, à direita.

Tenho 2 bancos de dados MSSQL que não fazem parte do mesmo cluster, mas são sincronizados manualmente (sem espelhamento de banco de dados configurado)

Quero que meus aplicativos cliente tentem se conectar ao primeiro host de banco de dados. Se falhar, ele deve se conectar ao segundo host de banco de dados.

Criei uma string de conexão (em Java) que se parece com isto:

        String connectionString = "jdbc:sqlserver://<IP_ADDRESS_SERVER_1>:1433;"
            + "database=<DB_NAME>;"
            + "user=<USERNAME>;"
            + "password=<PASSWORD>;"
            + "encrypt=true;"
            + "trustServerCertificate=true;"
            + "failoverPartner=<IP_ADDRESS_SERVER_2>:1433;";

Ele se conecta corretamente à instância primária do banco de dados, mas se eu desligá-lo e a conexão for redirecionada para a segunda instância do banco de dados, a conexão será bloqueada. (conectar esta instância como primária funciona)

A conexão redirecionada depende de espelhamento?